Learning NES

This month's Mini-Ludum Dare has a theme of Low Level. The idea being that the game created should be created in a language like C so that the developer can learn something about how computers work. I figure the learning part is the key to this challenge so developing a game in C/C++ wouldn't really teach me anything. Then I thought about creating a game for a platform I haven't worked with before. This immediately got me thinking about the NES. I like 6502 assembly language so figured it would be a fun challenge.

The last few days I have spent my evenings researching the NES. There is a surprisingly large amount of info on it, most of it poor. I suppose this is not too big of a surprise considering that the big N didn't want anybody programming their platform without their blessing so most information was the result of  hobbyists digging into the system on their own and learning how it worked by disassembling existing games. There are some really good tutorials and tools available, but a lot of the stuff is old DOS tools. I ended up finding NESAsm for my 6502 assembler and YY-Chr for editing the 2-bit tile-based graphics.

I have put together a simple skeleton (a title-screen and gamepad controlled spite screen) that I will use as my starting code for this weekend. the link is http://blazinggames.com/gamejams/minild45/miniLD45.php and while it is far from the best assembly code I have written, it isn't too bad for first-project code.

The sad thing is that I was expecting it to be programmed more like the C64. With that you simply had a range of memory that the graphics unit used so simply wrote to that ram like it was regular memory. On the NES, the PPU's (Picture Processing Unit) memory is separate so you have a small number of addresses that you use to communicate with it. You set the address of PPU memory you want to write to by writing to a register with the hi then the lo (which is strange as the 6502 is lo-hi for addressing) then write or read from another register which increments the address that you are looking at.  The way colors are selected is also over-complicated. You have 4 palettes of 4 colors that are chosen from 64 colors. Sprites have another 4 sets of 4 palettes but each of the 64 sprites have their own choice of colors. For background tiles, 2x2 blocks share the same palette. This isn't overly convoluted, so to make things more confusing the attribute byte for selecting the palette is grouped in 2x2 blocks of the 2x2 tile blocks (which probably explains why mario seemed to be broken into 4x4 chunks of tiles).

The gamepads for me were the strangest thing. They have 8 buttons so you would assume you simply read a gamepad port and get back a byte with each bit being the state of a button. Nope. You first have to strobe an address to get the gamepad to start transmitting bits. You then have to read each of the 8 bits separately.

Even if I don't finish my game, I have certainly learned a lot from this challenge so consider it a success. If nothing else, it reminded me of how different similar-looking things can be.

Apple Harvest Postmortem

For the August Ludum Dare #27 I released a simple game called apple harvest. The game was simpler than I would have liked due to what went wrong but it was finished and isn't too bad of a game all things considered. Here is my postmortem of the game.

What went wrong

Unfortunately Ludum Dare #27 happened to take place the same weekend as one of my cousins' was getting married. This meant that instead of having 48 hours to work on a game I only had about 8. This greatly reduced both my options for what type of  games I could develop and the amount of polishing that could be applied to the game. As I really need to work on my polishing skills, this was disappointing.

What went right and wrong

I have been moving away from Flash preferring HTML 5 solutions as they do not require plug-ins. Right now my choice is to use Dart, but depending on what happens with ECMAScript 6 this could change. Still, when there is a limited amount of time, Flash is a bit faster to work with. Part of the reason that Flash is more efficient is simply due to the fact that the art/animation tools are built right in so you are not switching between multiple tools and writing code to load the various assets into the game as that is all handled automatically for you. While I would have preferred a HTML 5 solution, using Flash allowed me to finish the game at a relatively reasonable time so I wasn't overly tired for the Wedding.

What went right

The first thought that I had when I read the theme was a money booth type game. The kind radio shows like to have where you have a short amount of time to grab as much money as you can. Playing around with air dynamics would have been great fun but probably would have taken me more than 8 hours so I had to apply a  Keep It Super Simple approach. I replaced harvesting money with apples. Why apples? I wanted some type of motion to the harvesting and falling apples is what came into my head so I just went with it. The apple life cycle was fairly simple with a flower, then a growing green fruit then a transition to a mature fruit. The transitions had a per-frame probability of  happening adding a slight random element.  Spawning new blossoms was also easy as I just pick a random spot on the trees. If there are no apples near enough then it takes otherwise, no spawning happens that frame. The simple artwork for the apple also got co-opted into the buttons for the menus.

Conclusion

For a very rapid game I think it turned out good. If I do revisit the game I would add multiple levels with quotas per level, and possibly different types of fruit trees.