Blog Posts

Funky Future Music: Part 1

In my last post I mentioned that I’d soon be posting about the music in Chuck Jones: Space Cop of the Future. In case you hadn’t already guessed by the title this post is about music, specifically the funky kind. So lets begin.

When I first came up with the idea for this game I knew that the music had to be funk. Chuck is a cop that comes to the future from the 1970s, his image being crafted after classic crime films from that era, it made perfect sense that to accompany the game I would need some killer grooves. However being a DOS game, this funk would need to be synthesized by old school 90s era sound chips.

Funky 70s Music

So now that I’d decided on the music’s aesthetic I had to think about how I could achieve this. Being the kind of guy I am and being a bit of an amateur musician, I of course decided the best thing to do was write all the music myself, something I now admit I may have been initially ill prepared for. What I had to do at this point was surround myself with some groovalicious music. Specifically big my big influences were Herbie Hancock, Sly and the Family Stone, Emuir Deodato, Stevie Wonder, Steely Dan, Johnny Guitar Watson and Curtis Mayfield.

SuperFly Poster, amazing Curtis Mayfield Soundtrack

But lets go back for a second, earlier I mentioned that all this music had to come from 90s era sound chips. Just like classic DOS era games this leaves me with a few choices for sound, mainly: FM synthesis cards, the PC speaker or MIDI. If you are unfamiliar with 90s era PC games you may have heard FM synthesis in games for the Sega Genesis or perhaps via the classic Yamaha DX7 keyboard, the most popular option for PC was the sound blaster card. The PC speaker was a very limited device that was built into every PC and only makes beeps and boops. MIDI opened up your PC to use external sound modules such as the popular MT-32. All three main devices are supported by Chuck Jones: Space Cop of the Future and all music must be composed to sound reasonably good on all of them.

The YM3812, a classic FM synth chip

Of course because of this I would need to take a look at some classic game tracks too and of course no post would be complete without mentioning The Secret of Monkey Island, for which composer Michael Land made some truly excellent “Pirate Reggae”. Other games I drew upon include Battletoads and Double Dragon (Sega Genesis),  Ghouls n’ Ghosts (C64), Jill of the Jungle (DOS) and Police Quest II (DOS).

Now at this point you’re probably wondering what this all sounds like put together, as you’re probably also sick of my rambling by now I shall leave you with an excerpt of some music from the game:


How do you make a game for DOS in 2017?

MS-DOS 5.0 Screenshot

Lets start with a bit of history. Before Windows, PCs ran on MS-DOS, and in the late 80s and early 90s DOS reigned supreme. Some of the greatest games of all time were written for DOS. In order to capture the feel of games from this era I decided the best way to do so was to make a game the same way games were made then, so I wrote Chuck Jones: Space Cop of the Future for 16-bit DOS. However DOS had some serious limitations, a maximum of 640k ram, low-res low color graphics and often running on slow CPUs.

I’ve recently been getting some questions about my process such what tools I use or how I work. Seeing as I haven’t written a super technical article in a while I figured that this month I would dive in and explain all that, step by step. So buckle up and lets go. How does one make a game for DOS?

Step 1: Decide on what kind of game you want to make

This is extra important to do first for a game that will run on DOS as hardware choice will impose some limitations on you, for example a cutting edge first person with a big complex open world and multiplayer is probably not a realistic choice for MS-DOS. I decided I wanted to make an adventure game, seeing as there were countless examples of excellent adventure games for DOS, I decided it would be a feasible idea.

Step 2: Choose a Programming Language

There is probably no issue among programmers that is more contentious than ones choice of programming language. However if you are intent on making a game for DOS your choice of language is incredibly important. You will need to be doing lots of hardware level programming, and as such JAVA, Python, C# or Ruby are probably not going to be suitable. Unsurprisingly to anyone who knows me, the language I chose was C++. Although C is also a good choice and many people swear by Pascal. Depending on the type of game you choose, pure Assembly Language could also be the right choice, this will require a lot more time to write, however for a fast paced action game with simple rules where performance is key, this might be the best choice. Any game for DOS will require probably at least some Assembly Language even if you choose another as you main language, this comes down to performance, high level languages simply cannot express what is needed for optimal performance on older hardware.

Step 3: Get some tools

2017-08-31 (7)
OpenWatcom Compiler

Although Chuck Jones is written for DOS, I must confess it is not developed on DOS. It is 2017 after all and I take advantage of that by using a modern Windows 10 PC for development. As I was intent on using a modern OS for development I had to ask myself, is there a C++ compiler that runs on Windows 10 and produces code that runs on 16-bit DOS? Well there is, OpenWatcom! Watcom was highly successful in the 1990’s and is still being developed under the Open-Source project OpenWatcom V2. While I can’t say enough positive things about OpenWatcom, there are some other options such as Digital Mars which I have not tried yet and then there are a few that run on DOS, such as DJGPP (32 bit only) or Borland Turbo C++ if you wanna go old school.

Visual Studio 2017

Now you’re gonna need an IDE, OpenWatcom comes with one but I prefer something more modern. My choice is Visual Studio 2017 but any IDE of your choice will work.

Pro-Motion NG

Of course there’s more to a game than just code. One necessity is a good image editor for making sprites and backgrounds and a game for DOS needs some special attention here. DOS games are usually limited in terms of colors and often use a 256 color palette. Naturally you will need a program that gives you control over this, I use Pro-Motion NG which has some excellent tools for working with indexed images and it’s dithered gradients. Tools like Photoshop or GIMP are also useful for a great deal of the work, but I always bring the image into Pro-Motion for finishing touches. If you want to go the DOS route you can also use good ol’ Deluxe Paint, which was used for many classic games in the 90s.


There’s one more aspect that needs special attention and that is music. Making music for obsolete sound chips is a bit too involved for this post and will probably be the subject of my next post. So see you then!


July Update: Being a programmer and Solo Game Developer

Future Los Angeles

In case anyone didn’t know yet, I’m the only working on Chuck Jones: Space Cop of The Future. When you work on a game as a solo developer there will doubtlessly be parts which you are not great at or don’t enjoy doing. I’m a programmer primarily and whilst I have a variety of interests such as Music or Film-making, I’ve always been best at programming. This month something very interesting and challenging happened, I pretty much ran out of code that needed writing. I found that I was spending a lot of time optimizing or refactoring my existing code and not really adding anything new, while this is incredibly important in itself, it was getting in the way of something more important: the rest of the game.

What is the rest of the game?

Art, Music, Writing and Gameplay. The adventure game genre is actually fairly inefficient in it’s use of these and requires a lot more art then some other genres in order to tell the story. Unfortunately making art is definitely what I’m the least efficient at. Nonetheless I have been productive this month so for those who are interested I will summarize what I’ve done this month.

I did some Play-testing:

This is really important for any game and should be done at every stage of development and as early as possible. For a game in progress this can really help give direction and weed out potential issues. Play-testing is only really useful when the player isn’t working on the game and best when the player has never played the game before.

I made lots of new art

This is kinda hard to go into detail about without giving away too many plot details but I’ll give you an example of an animation I did:

Walk Cycle

Animations are something I’m not terribly good at so if any real animators see this I would appreciate some pointers.


I can’t really talk very much about this at all because solving them out is the main aspect of most point and click adventures. I can talk however about how I make them. The process of which I mostly stole from the great Ron Gilbert.

I use Puzzle Dependency charts. Basically its a hierarchical chart that lets me visualize all the puzzles in the whole game and how they depend on each other, allowing me to make the game nonlinear and interesting while avoiding the possibility of dead ends or placing the player in an unwinnable situation. To make these charts I use a program called yEd shown below.

My puzzle dependency chart in yEd (edited to remove spoilers)

Once I decide on what should be in a puzzle it is implemented as a script for the Chuck Machine, which I described in a previous post.

Wrapping up:

This month as I’ve begun to move on from mainly coding I’ve had to learn alot of new stuff and constantly tweak my work flow. But slowly things are starting to fall into place and I’m excited for what I’ll have to show next month.

The importance of Coffee in Game Development

WARNING: this article is a work of humor, do not take this seriously.


Many have heard of the creature known as the Real Programmer. This creature is often considered a relic of times passed, in fact I have even heard rumors that the real programmer has gone extinct. In reality there are still a few real programmers around but sometimes they hide in plain sight. They don’t usually use FORTRAN anymore, but they sure as hell write assembly language, not because they need to but because they want to, they enjoy it and they don’t trust the compiler to do it for them. In fact there is only one thing a real programmer enjoys more than writing assembly language code:



To the real programmer this is the only meaning of the word JAVA. The real programmer enjoys coffee in any form. When the real programmer stumbles out of bed at 11:00 AM, the first thing he does is get a cup of coffee, maybe two or three. Once sufficiently caffeinated the real programmer sits down in front of his IBM model M keyboard and drinks usually one more cup before starting.


Whether you consider yourself a real programmer or not, coffee is an essential ingredient for any creative pursuit, especially game development and some attention should be payed to how you get it. Personally I drink espresso or cappuccino but a good ol’ cup of black drip coffee works just as well. It has been said that a programmer is an organism capable of converting caffeine into code, but in the world of game development, caffeine is converted into all sorts of things such as music and art as well as code. Truthfully I don’t know if I could get anything done without it.

Creating a Custom Scripting Language For In-Game Events

DEC PDP-10 mainframe

Let’s start by going back to the late 1970s, shortly after Chuck Jones himself was frozen. In 1977 a bunch of guys at MIT were working on the groundbreaking text adventure game ZORK. ZORK was written originally for the big mainframe computers at MIT such as the DEC PDP-10. Eventually these guys decided to form a company called Infocom in order to sell their games, but they had one big problem: There were very few mainframe computers in the world and the people who owned them were generally not interested in buying Video Games. If Infocom wanted to sell games, they would have to make them run on the small personal computers that were entering the consumer market at the time. However this presented an interesting challenge: the mainframe version of ZORK required 1MB of memory (1 MB = 1024 KB) but the personal computers of the day often had less than 32KB of memory, so how on earth were the going to get the giant world of ZORK on a personal computer!? The answer: A custom scripting language! The guys at Infocom were some seriously smart dudes and realized that most of the core logic of the game could be broken down into a series of game specific instructions such as move object to room, write message, etc. each one of these in game instructions could correspond to tens or even hundreds of machine code instructions making the game tiny. They essentially created a Virtual Machine, which they called the Z-Machine which was highly specialized for playing text adventures. The program to execute the Z-Machine instructions could be very small, and it being the only part of the game that was specific the computer it was running on, made conversions of the game to other systems a breeze. Because writing Z-Machine instructions by hand had many of the drawbacks of assembly code, Infocom also created a compiler for a Z-Machine high level language which made it easy to implement new games.


Now what does ZORK have to do with Chuck Jones? Well everything actually. In Chuck Jones: Space Cop of the Future, I use the exact same approach. I created a Virtual Machine which executes byte-code that is specifically designed to play graphical adventure games and in doing so I save time, memory and disk space. I call this somewhat unimaginatively: The Chuck-Machine! On top of this I built a high level but specialized language for controlling what happens in the game. Well at this point, if you’re brave enough, we’d better dive into the implementation details.


The above diagram gives a simplified overview of how my interpreter is structured, we have several processes each with their own set of registers which are cooperatively juggled on the single CPU that the game is running on. Additionally the interpreter maintains a global list of objects, rooms and sounds that are dealt with by the scripts as well as provides 128 global registers for inter-process communication. Now lets move on to the language itself.


Here’s a screenshot of me editing one of the scripts in the wonderful Notepad++ editor. The language is very much like a structured BASIC but with quite a bit of influence from C and C++. Because of the design of the underlying Chuck-Machine the language manages to compile to usually one or two byte-code instructions per line (with the obvious exception of macros and procedure calls), this is because complex operations can be built into the Chuck-Machine itself as special instructions.


Once a script is written it is compiled using the somewhat confusingly named BASM tool (the Bytecode ASseMbler), because this tool is actually a compiler and not an assembler. BASM is written in C++, when I wrote BASM I was moving really quickly and as such it’s pretty inelegant and is a bit of a hack. Despite this it works.

In summary creating a custom language doesn’t have to be that complicated and you can save yourself a lot of time and memory if you do it right.


What I’ve been working on

While I intended to post the second part of my article about VGA programming I regret to inform you that I haven’t finished writing it as its not the easiest thing to explain. Don’t fret however as it’s on the way. Instead I have decided to give an update on the stuff that I’ve been working on instead of writing that article.

In addition to working on art, designing puzzles and composing music, which occupies the bulk of my development time as I do all of those tasks myself, I have:

Overhauled the music system


Original Adlib card

Before this, the game played MIDI music and only supported the original Adlib music card and it’s Yamaha OPL2 sound chip, and the game engine mapped a single midi channel to each of the Adlib’s six melodic voices (the other 3 of 9 were taken up by the drums). The problem with this is that it limits all the music to six instruments and none of those could play chords.

This has been replaced with a more MIDI centric system where each of the 16 MIDI channels are mapped on the fly to a free voice on the Adlib card, replacing the oldest note if a free channel is not available. This allows the system to play chords and juggle 16 channels pretty well among a smaller number hardware voices. An interesting result of this is that now if I give the playback engine more voices, say 18, I could make more complex music sound even richer. This is exactly what happens with the OPL3 chip, used on the SoundBlaster Pro 2, SoundBlaster 16, Adlib Gold etc. The OPL3 chip supports stereo music, 18 hardware voices and more complex timbres.

Additionally I have added support for the much loved Roland MT-32 synthesizer/MPU-401, This works by just pumping all the MIDI events through the MPU401 card and is slightly more efficient than the voice juggling that happens with the OPL cards, this is offloaded to the external MIDI module.

Of course if you’re using a modern system don’t worry if you don’t have this hardware as it will be emulated by DOSBox which will be bundled with the Windows, Mac and Linux versions of the game. If you are using a vintage system don’t have any of this hardware I am working on adding PC speaker support 😉


Felix McKnight: lead singer/guitar player of the funk band Felix McKnight and the SoundBlasters

Made save game actually work

Anyone who has had to implement this feature probably understands that It’s actually a miracle that you can save your game and pick up exactly where you left off. There’s just so much in a game that you need to find and stick into a file and then make sure you can actually load that data back in at any point without crashing the game. As you might imagine many games cheat at this and don’t offer a perfect load/save. As I don’t use save states as a game mechanic (like a Sierra game were you need to save your game every 5 seconds because Roberta Williams is trying to kill you) it’s probably not that important but I really wanted to get it right because it makes testing easier.

Added an inventory view

Up till now Chuck (and every other character) had an inventory and the game would keep track of it but you the player could not look at it or use items in it. If Chuck had an item that he needed for a puzzle he would automatically use it. Now you can press the “i” key at any time to see the items you are carrying and interact with them, each inventory item having a unique icon. This allows for some more interesting puzzles as well as encouraging players to pick things up.

Optimized sprites and lower Memory usage

Explaining how I did this is probably too long for this post but the memory usage was basically improved using better data structures and paging things in and out from disk but in such a way that it actually helps to allow the game to run off floppies by optimizing for locality to minimize disk swapping (disk swaps are most likely to occur when travelling between planets and between acts of the game).

Generally the engine has become far less buggy, more optimized and the scripting language has become more powerful as needed for implementing certain puzzles. I always make sure that as I add new content that I also keep disk usage down. When I ship this game in a box I don’t want it to be on a ridiculous number of floppies.

If anyone has any questions about anything regarding this game (except spoilers) I’d love to answer them.

Lets talk VGA, Part 1

When I say VGA, most people these days will think about that funny blue connector that used to be so common for connecting computers to display devices.

That thing on the back of my monitor next to the HDMI port?

Why would I wanna talk about that you might wonder? Well I won’t really be talking about that. What I’m talking about is the Video Graphics Array, a graphics card standard introduced in 1987 by IBM, the connector pictured above was only one part of that standard. VGA was important, really important. Before VGA, PCs could only display 16 colours on screen at a time and most of the time programmers and artists had no choice what those colours were. With VGA you could have 256 colours on screen at the same time! Not only that but you could also pick those colours from a massive set of over 200 thousand colours, this was truly groundbreaking. Since the a VGA card would have been the most common type of thing to see in PCs in the era Chuck Jones targets (around 1992), this is what I have chosen to support. Lets get down to the nitty gritty then shall we?

VGA Graphics Modes

For the uninitiated graphics programming for DOS can seem quite daunting, there’s no API, you just write data directly to the address of the video memory as if its just one big array. The mode you choose determines how that data is interpreted. Most games that used VGA used its 320×200 pixel 256 colour mode (mode 13h). Mode 13h is really fast and dead easy to program, one byte is one pixel and the next pixel is at the address of that pixel plus one. You might wonder then why Chuck Jones doesn’t use it, in fact it doesn’t use any documented mode at all. Chuck Jones uses what is commonly known a Mode X, popularized by the genius programmer and talented writer Michael Abrash (he describes how to use it here).

The Planet Orlokis in glorius 320×240

I don’t use mode 13h because it has a couple drawbacks, firstly the pixel aren’t square so drawing art using a modern image editor would be tough. The second thing is that the VGA card has a minimum 256k of ram but 13h only gives you 64k of that (just enough for 320×200 pixels) meaning that the pixels you write to are always the same ones that are being displayed so the user is gonna see terrible tearing all the time, unless of course you manage to make all your changes to the screen during the vertical retrace (the time it takes for an electron beam in a CRT to go back to the top at the end of a frame, retained in LCDs for compatibility). In practice most games managed this alright but there was no way to guarantee that tearing would not occur. Mode X allows a technique called page flipping where you can write the next frame to a part of the video memory that is off screen and then point the graphics card to that at the end of the current frame. Mode X also gives a resolution of 320×240 which is slightly higher and has square pixels.

Mode X isn’t perfect however, to understand why you’ll need to understand why mode 13h only gives you access to 64k of video memory. The VGA card organizes it’s memory 256k of memory into 4 64k planes, each pixel on the plane having a 16bit address (216 = 65536 = 64k). In order for mode X to give you 320×240 it actually has to put the screen across multiple planes, meaning that the next pixel isn’t the next byte in memory, its actually on the next plane! This complicates things more than a little bit. You actually need to not just write to the pixel you want (actually pixel address / 4) but actually select which planes you want to write to. Notice how I said planes and not plane? Well the interesting thing is that you can actually write to multiple planes at the same time. I’ll talk more about this and how this has some interesting performance characteristics when I talk about my code in Part 2.