Reviewing a year in the Chuckiverse

Hello everyone,

Yes, I know I’m about a week late but it seems that’s just how I roll. Approximately a week ago we completed 2017, the first full year of development on Chuck Jones: Space Cop of the Future (Development began in 2016, just in case anyone was wondering). I figured I may as well give an update on what was done in 2017 and hopefully give an idea of where the game stands as of now.

p1030221.png
some early notes

Back at the beginning of 2017 the game consisted of no more than a single room, some animations and an El Camino inside of a partially functional adventure game engine and a huge stack of design notes. The engine had a glitchy sprite system, an incomplete scripting language and could make some irritating noises on an adlib card.

chuck_039.png
Chuck Jones circa 2016

For the rest of the article, I won’t be able to cover everything, but I’ll go over a few things I found particularly interesting then try to sum of the current state of the game.

Firstly I wanna talk about the engine cause its pretty much done (finally). I did two things in 2017 that really made a difference: I started using version control and a bug tracker. Even for solo development and small projects these two things are incredibly important, the ability to keep track of all your changes and revert them if necessary is invaluable. Some new features added to engine were:

  • A full midi based music system with support for multiple classic sound cards
  • A memory manager to make the most of 640k of ram
  • Massive speed improvements on slower hardware like the 286
  • A Vastly improved scripting language
  • A much improved editor

Next lets take a look at the art. As you can hopefully see compared to the 2016 screenshot, I’ve learned a heck of a lot about making art for games.

chuck_041
Some more recent art

 

Additionally I’ve finally nailed down my process for music creation in the game and I’m really excited to keep working on new compositions.

So where do we stand then? Well the engine is feature complete, as in I cant think of anything else to add so I’m gonna call that 98%. About 75% of the planned locations have been created as pixel art and a few more consist as sketches. About half of the music has been written and the rest is coming along. Finally everyone probably wants to know when I’m gonna be done, well… I can’t tell you quite yet but I will say I hope not to be writing a second new year post for this game.

Chuck Jones on Android, or how the game will play in the 21st Century

Well as of a few days ago, Chuck Jones is now working on Android and iOS is in the works. Lets talk about how we got here.

People often ask me that since I’m writing a game for an ancient OS, how will they play it? A couple of weeks ago I began trying to tackle an important problem: How to package the game in a way that it can be played easily by people in the 21st Century. As the game runs on DOS natively, the obvious solution would be to do what GOG.com does and bundle DOSBox with an optimal configuration file. This is a pretty good solution but as good as DOSBox is, it has some issues. In my opinion DOSBox’s scaling is not very good, you will usually not get sharp pixels (not everyone’s preference but this is the way I want Chuck Jones to look), especially not on a modern 1080p monitor, this makes sense because most DOS games had non-square pixels which can’t usually be sharply scaled. Another issue is the lack of V-Sync which makes sense because most DOS games run at 75Hz and most modern Monitors refresh at 60Hz. One more thing needs to be addressed, DOSBox has no official port to mobile devices and the unofficial ones that exist are unsuitable for distributing my game.

So how did I tackle this? Easy. I forked DOSBox and modified the code to make a version that is designed specifically to run one game. Because Chuck Jones runs at 60Hz and has square pixels due to some tricks I described previously, I was able to add the features I wanted as well as making the experience of launching the game as smooth as possible. The average player will probably not realize that the game is not a native game for their platform (assuming the don’t recognize the DOSBox splash screen). In order to get the mobile version working I modified DOSBox to use the SDL2 Library which has better mobile support than SDL1.2 which DOSBox was using before. The way I improved the scaling was pretty simple. I first do a scale with no interpolation from the games native 320×240 resolution to the nearest integer multiple which is smaller than the display. For a 1080p display this is 1280×960 and from there it scales up to the monitor’s resolution bilinearly. I have been pretty happy with the results, its not quite a pixel perfect scale (unless you have a monitor with an integer multiple of the source such as 1280×1024, height doesn’t matter because it will letterbox).

As for the process of porting, it was not without trouble as the Android development tools are not the best (a slight understatement), especially for C/C++ which I needed to use to compile DOSBox but are my goto languages anyways. I used Visual Studio as my IDE for both Windows and Android which it doesn’t have perfect support for but I found it far less painful than Android Studio. Something that seems obvious first, converting between touch input to the mouse input in Chuck Jones, is not. A touchscreen tap happens at an absolute position while mice actually function by reading relative motion, the absolute position of the mouse is an illusion created by your OS (try moving your mouse to a point on your desk, move it away, then move it back, it should be in a different position on the screen now). Basically the code I wrote to translate taps only works if it knows were the game has the mouse initially and uses some math from there, since Chuck Jones always starts with the mouse at the center of the screen this is no problem. The next step is to add some buttons to the app to replace the keyboard keys in the PC version and then our next stop is iOS.

So now I have a cross platform solution to run the game on at least 6 operating systems (MS-DOS, Windows, Linux, Mac OS, Android and iOS) using a single binary, ensuring a consistent experience across devices. I’d say that’s enough to ensure that pretty much any 21st century player should be able to play Chuck Jones: Space Cop of the Future.

Extra bit for nerds:

My Fork of DOSBox on GitHub: https://github.com/pgrAm/DosBox-for-Chuck-Jones-Space-Cop-of-the-Future

Funky Future Music: Part 2

P1030149
Jammin’ out

First things first, I know this post is a day late, I usually try to post on the last day of every month, but I figured people might be too busy with Halloween to read a gamedev blog post. So, I hope you had a good Halloween and lets get started. Last time I talked about the music in Chuck Jones: Space Cop of the Future, this time I’m gonna get technical and explain how I make that music. But before we start I’ll give you another sample from the game.

P1030166.png
My ancient Drum Machine (with the worst LCD in history)

Right, so let’s get down to the nuts and bolts. Pretty much all the music in the game starts with me jamming out on several instruments in the analog realm, usually a guitar, bass or keyboard of some kind. When I discover an idea that I like I try to create a basic drum part for it, as I’m not a drummer/a very bad one, this usually involves messing around with my ancient drum machine until I come up with something I like. When I get to this stage I usually have a pretty good idea of what I wanna do with the song, so I head to the computer.

spg
Drum Editing in Voyetra Sequencer Plus Gold

I usually start building the track in a program called Voyetra Sequencer Plus Gold for DOS, this is the software used by Bobby Prince for much of his excellent work for Id software. Using such an old program lets me hear things through a real Sound Blaster as I work. Once I lay down a drumbeat I start playing each part on a midi keyboard and recording it. Recently however I’ve been experimenting with using a guitar and some pitch to midi plugins, which is extremely helpful for some parts which don’t feel quite right with the keyboard. Usually I also check each part on an MT-32 as well as the Sound Blaster.

2017-11-01 (2)
Jumping ahead 20+ years

Once I get my basic tracks down it’s time to jump forward 20 years. I transfer a MIDI file exported from Voyetra via floppy disk, or LAN depending on the DOS machine I’m using, to a modern PC. Once on the modern PC I bring the file into my DAW (Reaper) and my performances are edited. I also use this opportunity to work out the final structure of the song. What I’m left with at the end is a type 0 MIDI file that can play back within the game.

Playback in the game can happen on Sound Blaster or through a MIDI interface to a device like an MT-32. On the Sound Blaster a special “.ibk” patch file is used to control the timbre of each instrument in the game (Thanks, Wohlstand for making this easy with OPL3BankEditor). On modern systems the game music is heard through a Sound Blaster emulator provided by the wonderful DOSBox project. All that’s left to do is sit back play the game and enjoy some righteous funk.

I hope you enjoyed this foray into the music of Chuck Jones: Space Cop of the Future. Hope to see you next time.

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.

covers.png
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.

halfsheet195-2
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.

ym3812_01
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?

doshot
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.

vs2017.png
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.

pmotion
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.

kb

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

chuck_024.png
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:

postal.gif
Walk Cycle

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

Puzzles

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.

yed.png
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.

P1020049

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:

Coffee

P1020114

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.

P1020091

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.