I’ve been asked a few times what I use to develop my C64 games, so here goes!
First of all, I’m probably mad or crazy, but I do love to code my own stuff. I started programming back in the 80s, and I haven’t stopped since. As a result, over the years I’ve gained a lot of knowledge, and I’ve coded a lot of tools for various platforms.
Like most people at the time, back in the early days I wrote my own character and sprite editors, largely because there was no internet to download tools from. You either bought it, or created your own.
Even working for various companies I’ve built my own tools. At Core Design I coded a graphics converter tool that looked a lot like DPaint, and that ended up being used by others to grab sprites and backgrounds for not just the Megadrive, but also the Master System.
I do have my own PC engine at home, although I haven’t used it for game in years. My home code base also has a code library for making Windows based editors, and I use that today for building all my PC based tools.
So when I started getting back to some C64 programming, the first thing I needed was a 6502 assembler. Since I love to code stuff, and knowing I was quite likely to want to add custom assembler directives, I coded my own. 6502 is a simple assembly language, so it’s not as hard as it might sound. My assembler is integrated into the build system I use today:
My build system can generate all that I need, so not only will it build complete cartridge images (8k, 16k, or 512k GMod2), it will also build .d64 disk images.
My assembler can also spit out code overlay files, meaning I can assemble the whole game in one go, with every module spat out as a separate code overlay file able to access any other part of the code. I use this for my Briley Witch RPG a lot, especially for the script files. Each script file can have 6502 code embedded within the data, and the code can call to any function and access any memory location within the game code. Other people might like to do things differently, but I like the way my system works. For Briley (a 512k cart game), my system automatically assigns the files an ID, and builds the include files to access them. But for disk images it takes the given name and adds each file to the disk image.
My build system used keyboard shortcuts, so as with Visual Studio, I use [Ctr]+[Shift]+[B] to build everything, then [F5] to run the emulator. I’m using VICE as my emulator of choice, my system running it as a background process. I don’t have much in the way of debugging support, other than using [Alt]+[M] inside VICE to bring up the debug monitor, and using the load symbols command to load a symbol file generated by my assembler. Debugging is something I’ll take a look at in the future, but it’s not a major issue right now.
When I started making my C64 games, I used existing tools, namely CharPad and SpritePad. Pretty early on I knew I wanted to code my own character/map editor, so I did that, and for some reason (don’t ask), named it SJFX… I’m glad I did as my editor does loads I need for my games, and I can make it export the data in precisely the formats I need. It too has keyboard shortcuts, so I can load in a file and just use [Ctrl]+[E] to export the data.
Future projects will need more functionality, and one thing will be to give it the ability to build a charset for a flip-screen multi-colour hires game I’m thinking of coding… With a multi-colour hires screen, there can be any 3 colours per character, so I’ll need to modify SJFX to allow that.
For a while I used SpritePad for making my sprites, but did hit some serious limitations. For Briley, I needed a sprite editor that could manage multiple overlay sprites at once. And so I coded my own editor, one I call SprEd. SprEd can use up to 4 hires overlay sprites, and can even edit more than one at a time. I’m using this for the in-game portraits, as in the following image:
I’ve even coded my own bitmap editor (BitmEd), something pretty basic that I use just to edit bitmap images. It can save/load Koala format, with my build system able to load and convert them to the formats I use.
For music and sound I again coded my own tool, being dissatisfied with everything else I had tried. I needed something that would run on a Windows PC, and most editors either run native on a C64 (hardly ideal), or run on a PC in DOS mode. So I coded an editor I named SJTracker, a full Windows based editor using reSID as its SID emulation:
Having my own editor means I can add anything to it I need, plus means I can export straight from the editor and into a format my games need.
There has been some interest in SJTracker, so when I feel comfortable about it, I would like to release it to the world…
And That’s It!
So there you go, an insight into all the tools I use to create my games. With all the tools I now have, I can make many more games, and I plan on doing just that. I’m having fun with this, so expect a diverse variety of stuff from me in the future. Best thing is, whatever tools I need, I can just go ahead and code them.