My tools are the Tools of Lizard
I'd like to show you the tools I use to make Lizard.
One of the first things I did was write myself an application to build the graphics and world data for the game. It's not built to look fancy, or even have all the features I think would be convenient; it just has to be good enough for me to finish the game with. When working with the tool, if I find myself doing something repetitive I usually make a mental estimate of how much time I'll waste doing it the "long" way, and how much time I'd waste programming the tool to do it for me. It's a lot different perspective than trying to make a tool for others to use.
When I open lizard_tool.exe, I give it a command line to open a "package" file, which is essentially just a list of all the graphics content in the game. This is a collection of:
- Palettes: a collection of 4 colours selected from the gamut of colours that the NES can produce. To display anything on the NES, it needs to have a set of colours to use.
- CHR tiles: a collection of 8x8 pixel tiles. These tiles are used to draw both the background and sprites, and will be coloured using the palettes.
- Sprites: a collection of CHR tiles, palettes, positions, that come together to make up a character on the screen. Almost everything that moves will be represented with a sprite.
- Rooms: A background, and a list of objects (known in my engine as "dogs"), and other things that make up one playable screen in the game.
From this main pane, I can open any of these pieces of data. For selecting a room, I often use a separate map selector that lets me select a room visually by location rather than by name.
Each piece of data can be edited in its own window. Here I have a few jellyfish sprites open, but also the related CHR tile set and palette.
Each sprite is made up of a list of tiles. CHR tiles used in sprites can have one of 4 palettes, and can be displaced or flipped. The sprite editor lets me piece it all together.
Here you can see everything that goes into a single room. It has a tiled background, a collection of 4 CHR sets for background, and 4 for sprites, as well as 4 palettes for each of these. I also choose music, and link rooms together via "doors". Finally, all the things you can interact with are called "dogs".
All of the source data gets saved as text files. I do this because it works well with source control. If I make changes to a room, for example, I can review what I did just by reading the differences in subversion. It's also very easy to inspect, and can be edited by hand. If my data set was much larger, I would probably not want to deal with the inefficiencies of text, but for the scope of an NES game I find it quite convenient.
Source control is an essential tool for programming, by the way. To have a history of changes to a document is incredibly useful when you make a mistake, or even just want to look at something you had earlier. At the same time, using source control continually makes an online backup of your work, protecting you from data loss. I do almost all my work now (programming or otherwise) with source control, and I can hardly believe that I managed to get anything done without it when i was younger.
Music and sound effects are written in a separate program called FamiTracker. FamiTracker is a fantastic tool for making authentic NES music, and it's been around for many years now. I was very happy I didn't have to make my own tools for composing on this project.
To get the music into the game, I wrote a python script to process a text export from FamiTracker into code that can be compiled into my game. I actually wrote the text export feature for FamiTracker with this game in mind. (I am not the developer of FamiTracker, but he thankfully let me contribute this feature to it.)
The first iteration of everything is done as a C++ application, developed for Windows with Visual Studio Express 2013. When the thing I'm working on is more or less settled, I begin porting its code to the NES...
I write code for the NES in assembly language using Notepad++ (it's a good text editor). I then assemble the ROM using the cc65 assembler, and typically test and debug using the FCEUX emulator. I often try other emulators, or run it on my PowerPak on my NES to make sure it still runs fine there (since no emulator is perfect), but for the most part FCEUX is sufficient, and it has a really great debugger.
So, this was a little tour of the tools I use to make Lizard. We've almost reached my minimum funding goal, and I'm really grateful to be able to make this game for you. Thanks, everyone!