Pixel Art Extravaganza!

Well, its March and the great Canadian winter has started to subside (for now), I figured it was as good a time as any to talk about Pixel Art! Specifically of the 256 color VGA variety. I’ve talked a little bit about this in the past but I think it deserves a dedicated article.

Most of the time I hear that letting a programmer make art will lead to disaster, but somehow I couldn’t deter myself. Despite being a programmer I was very lucky to grow up in a house where art appreciation and technique was instilled in me from a very young age, my mother is an oil painter and she taught me everything I know about light, shadow, perspective etc. All essential concepts for making 2D art.

The art of an adventure game is particularly important, great art in a game can even make up deficiencies in other areas. It’s one of the reasons I still love Sierra games despite them making me want to throw my computer out a window because Graham just got killed AGAIN with no warning and I have to reload my savegame! The style I decided to go with was something inspired by Monkey Island 1, specifically the VGA version. I thought it was a good compromise between the impressive but limited 16 Color EGA games like Space Quest III and Loom, and the more “painterly” hand drawn style of Monkey Island II and the Sierra games after Kings Quest V, that I don’t think would suit Chuck Jones: Space Cop of the Future.

wannabuyamap.png
Monkey Island VGA, I absolutely adore this style, with its bold palettes, wonky perspective and lots of dithering

This means that art would be drawn primarily in the computer pixel by pixel with a paint program. What paint program is that you ask? Well I actually use two, I usually start with GIMP because I’m very used to it and can work very quickly. However GIMP falls apart a bit when you start working with true 256 color VGA art. When I need to mess with palettes or draw dithered gradients I switch to Pro Motion NG. Pro Motion is and excellent program for working with genuine 8 bit indexed images that picks up where programs like Deluxe Paint left off in the 1990s.

polstn.png

In the picture above you can see both of these at work, I started by drawing the basic outline with GIMP, using a 3d Model I had prepared as reference for perspective (something I’ve always struggled with). The image was then brought into Pro Motion to do things best done in a true 8bit image editor, such as defining the 8bit palette and fill in the basic colors and shading, with liberal use of dithering. The image was brought back into GIMP where I worked on the fine details such as anti-aliasing around the text.

HLD-camp-parallax.jpg
Some fantastic modern-style pixel art from Hyper Light Drifter

If you are unfamiliar with the technical aspects of old school pixel graphics you might be wondering why I keep stressing the fact that I’m talking “true” or “genuine” 8 bit graphics. The reason of course is that most modern pixel art games while often containing some great art don’t share any of the same limitations with as the games they try to emulate, they usually have a relatively low resolution but they’re not held to any specific limit and they tend to use whatever and as many colors as they please. I will also stress that this is a perfectly valid way of making game art and it is practiced by many artists much more talented than myself.

Landing on Orlokis
Even less than 256 colors!

CJ: SCotF on the other hand is a true 16bit game that runs natively on hardware from the 80s. The graphics are truly 8bit (8bits per pixel, 256 colors). When I make graphics for the game I’m limited by hardware constraints to a resolution of 320×240 and 256 colors, that’s it.

So now that I’ve given you an overview of what I’m working with and talked about drawing static backgrounds, lets talk about moving pictures, animations, the realm of the real Chuck Jones! Going with the whole 16bit DOS game thing, animations can’t have very many frames due to memory limitations. Although the timing of a frame is variable, most animations in CJ: SCotF run at around 8 jiffies per frame (1 jiffy = 1/60 seconds) which works out to the ridiculously low rate of 7 frames per second! While it seems like that would suck, I kinda like the result and its very much in line with the way things were in the early 1990s. Animations in the engine are simply just a list of frames with offsets and timing information, I usually make them by drawing layers in GIMP similar to the cels in traditional animation. These get exported to a custom image format and then I prepare a frame list kinda like this:

left:
    chuck/left/chuck0.l4b -5 0 8 t
right:
    chuck/right/chuck0.l4b -4 0 8 t
leftwalk:
    chuck/left/chuck0.l4b -5 0 8 t
    chuck/left/chuck1.l4b -6 0 8 t
    chuck/left/chuck2.l4b -7 0 8 t
    chuck/left/chuck3.l4b -7 0 8 t
    chuck/left/chuck4.l4b 0 0 8 t
rightwalk:

This gets converted to an internal engine representation and then we’re good to go. We are then treated with this walk cycle:

Well I suppose that’s all I have to say about that, if you wanna know more about adventure game art and pixel art in general (and I hope you do), I highly recommend this 2016 GDC talk by the legendary Mark Ferrari:

Revisiting the Chuck Machine, more on custom scripting languages

Earlier in the development of Chuck Jones: Space Cop of the Future I talked a bit about the scripting language that makes the game possible. I discussed how adopting a custom language and running it in a virtual machine could, if properly implemented, save memory and make writing game-play code much easier. As time goes on things change and ideas grow, luckily this idea has grown into pretty nice and very useful little language. So, lets talk about the language itself.

Chuckscript
An older iteration of the Chuck-Machine Language

The last time I showed off the language on this blog, you could be forgiven for mistaking Chuck-Machine code for a bastardized dialect of FORTRAN. At this point the language has evolved into something a bit more elegant (when I say elegant I might mean closer to C):

procedure update
{
	var thisIsAVariable = 0

	var character = current_player

	var object = 5

	//we got loops
	while thisIsAVariable < 5
	{
		//We got expressions
		var x = thisIsAVariable - 10 + get_object_x character

		thisIsAVariable += 1 //assignment add
	}

	say_lines character
	{
		"Wow this is a contrived example!"
		"I really wish I could use
		some real game code"
		"but then you might see some spoilers!"
	}

	if character has object
	{
		say_lines character "I have object 5!"
	}
}

As you can see the most obvious change is that the begin/end type syntax has been replaced with a C-like curly brace style making the code much more readable. There are now proper arithmetic expressions and multiple operators can be used on one line. Perhaps the most important change however has been the specialized structures for writing dialog, much of the auxiliary code has been removed allowing be to write dialogue by just "writing dialogue". This very much reflects the design philosophy behind the Chuck-Machine language.

The machine language had a few very simple design goals:

  • Must be easy to read
  • Must be quick to write
  • Must elegantly express the concept associated with a point&click adventure game
  • Must be relatively easy to parse
  • Must correspond well to the generated byte-code

Additionally I defined what was definitely outside the scope of the language

  • Expressing complex mathematical ideas
  • Processing large sets of data
  • Writing standalone applications

The language is by no means flexible and really that’s the entire idea, it’s utility comes from it’s specificity. It is has no variable types (really one type) and about 80% of the builtin functionality is related to manipulating object in an adventure game.

Now that we have an idea of what the language looks like, lets talk about how it’s implemented. I won’t really talk about the interpreter because that’s pretty straightforward although interestingly probably contains enough GOTOs to make Edsger Dijkstra cry (I guarantee you this is not my normal practice, however I assure you that sometimes GOTO is indeed necessary however rarely).

The utility that compiles the scripts into bytecode however is more interesting. The utility called BASM was written in C++ and implemented in a way that no sane person would probably try. Had I been thinking sanely that day I would probably have used Yacc or Bison to generate a parser for my language potentially saving me a lot of work. Instead what I did was to create a “one pass compiler”, this is usually considered to be a bad idea. Luckily due to the simplicity of my language and virtual machine this did not turn out to be a big of an issue as it could have been. Another result of my language design decisions was how simple the compiler was able to be, the entire thing is only about 1,500 lines of C++ (keep in mind I use Allman formatting). Another bonus is how quick the compilation process is which any game-designer will know is great for fast iteration.

2018-01-31.png
Fast BASM compiles make iteration quick

So I think I’ve said pretty much everything I wanted to on this subject, if you can’t already tell, this is an aspect of the game that I’m pretty proud of, I’ve always wanted to design my own programming language. I think I’ll leave you with one more example from the game itself demonstrating the “Movie Script” style dialogue syntax I’ve added:

procedure goto_room
{
	hide_cursor

	set_animation		current_player	10
	wait_for_animation	current_player
	set_animation		current_player	8

	var dr_klein = 29

	say_lines
	{
	current_player
		"Whoa, my head hurts ..."
		"Must've been quite a night"
	dr_klein
		"Ahem ..."
	current_player
		"Where the HELL did YOU come from!?"
	dr_klein
		"Allow me to introduce myself"
		"I'm Dr. Klein,"
		"You've actually been out
		for quite a while"
		"You see ..."
		"You were cryogenically frozen"
	current_player
		"So I'm in the future?"
	dr_klein
		"Well not exactly ..."
		"Technically its the present now"
		"You're currently on a
		space station orbiting
		Excellon V"
	current_player
		"?"
	dr_klein
		"Well anyway,"
		"We did unfreeze you for a reason"
		"The POLICE COMMISSIONER
		will explain everything"
		"You can find him in the
		GALACTIC POLICE headquarters
		on this station"
	current_player
		"Well then,"
		"I'd better have a talk with him"
	}

	show_cursor
}

 

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.

Home Brew Video Game Tools

P1030289

Hey all,

You might be wondering what the glass of beer in the image above is all about, this a blog about game development right? Well specifically that is a glass of homebrew, something I began making around the same time I began work on Chuck Jones: Space Cop of the Future. Take a look at the list of projects for CJ: SCotF, notice how only one of them is labelled “Game”, well what are the other ones?

solution

Well, when you make a game you need tools and in this case they need to be, just like the beer, home made. I figured I might go through all these tools and explain what they do and why I made them.

Adlib  Host

Those of you who follow me on Twitter or frequent the Vintage Computer Forum may already be aware of this one. It’s a tool to help me compose music for FM synth cards such as the Adlib and SoundBlaster by allowing a properly equipped DOS PC to behave as an external MIDI module, using the same sound engine as the game. This lets me make use of it’s FM synth capabilities in my modern sequencer so I can compose while hearing exactly what the final tune will sound like. This also allows me to use my MT32’s MIDI thru, send the module’s output into my mixer and be able to swap between FM and MT32 soundtracks just by adjusting a fader!

For those interested I have made this tool available for download.

Bytcode Assembler (aka BASM)

I’ve discussed this one in previous posts, but for those who are unfamiliar, it is the compiler (not assembler) for my custom scripting language. It is a command line tool that reads in text scripts and outputs binary byte-code to be interpreted by the game engine.

disBASM (Bytecode Dissasembler)

2018-03-31.png
An example of a script and it’s disBASM output

This one is kinda cool, it mostly exists for the purpose of testing and debugging BASM and the interpreter. As you might imagine this program reads in a compiled script file and outputs a textual representation of the interpreter opcodes for it.

EditorExtensions

2018-01-31 (2)
Using the in-game editor while modifying a script

This is a collection of Perl scripts that perform a few functions to make editing the game a bit easier, for example the allow me while running the in game editor in DosBox to press a key combination and have the Chuck Machine script file for the selected game object open in Notepad++ on Windows and then run BASM to recompile the script after editing, I can then Alt+Tab back into DosBox where the object will be reloaded and I can continue editing with the modified script. Needless to say, this can save a ton of time.

Image Compressor

This little program is quite straightforward, it simply convert’s image files of various types into a custom .l4b file that is used by the game. These files are specially optimized for use in the game and are quite compact, utilizing the LZ4 compression algorithm. I’d like to thank Jim Leonard (trixter), for the idea for this one, as well as providing a fantastic well optimized decoding implementation, as it has cut the size of the game down considerably (great for a floppy disk release).

Sprite Converter

This tool is used for specifying animations for the engine. I went into a little detail about it last time, but the basic idea is that you create a list of frames and the tool spits out a binary .spr file which the engine uses to play animations.

Sysex Generator

I wrote this one for generating sysex commands for the MT32, I don’t really use it because I vastly overestimated the number of Sysex commands I would need to create. I ended up doing the entire thing in another tool (I think it was Midi-OX).

Well I hope I’ve given some insight into the less obvious bits about developing games. I’d like to thank everyone for reading, I’ve recently been getting quite a bit more traffic on this blog and I’m really glad that people are interested in the game and its development!

PS: For those of you who are noticing a lot of tech heavy posts, it’s because I sometimes have trouble coming up with creative post ideas. If anyone would like to, feel free to comment with suggestions for the next blog post or questions you’ve been wondering about and I’ll do my best to address them. If I get a lot of replies, perhaps I’ll do an FAQ.

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: