Mega Man 2600 post mortem

Entry posted by djmips May 4, 2007

1,265 views

Mega Man 2600 post mortem

It was cool how Mega Man 2600 blew up on the Internets.

It was very fun and hearkens to a time when I thought game programmer was going to be something like rock star. I distinctly remember hero worshiping the Kitchen brothers. The benefactor of this game (iam8bit) had assured me of a modicum of notoriety and it was certainly part of the attractiveness of the project. It was a paying project though, but certainly not the 'big bucks'. It was a lot of fun and so the money wasn't so important.

I also enjoyed very much the opportunity to work through the basic control and 'physics' of a game like this. I've never really done the control portion of such a game (although I've worked on it after the fact) and although it is straight forward it was nice to have worked through all the problems myself and have produced a solid result.

While researching, I became quite proficient at Mega Man in a way that I'd never thought possible. Mega Man was always just a little too hard and frustrating for me. But after all the 'research', I realize that I now posses the ability to finish the game if I so desire.

The research was made all the easier by the huge mountain of data available on the Internet via posted video and data related to time attacks (speed runs).

I used the disassembled code from the original Mega Man to aid me in areas where sheer pondering had left me with some mental road blocks that solving them would have taken too much time.

It's interesting, doing a project such as this where I was drawing upon all my capabilities, (excluding music where I had help). I had to do the disassembly, code design, coding, debugging, planning, level design, art and label art.

I like the quote that paraphrased says that first states that debugging is twice as hard as coding. If you design your code as clever as you can, then by definition you will not be able to debug it.

I found debugging to be the hardest part of this project as usual. I think that this is clearly where I am able to pull something like this off and where many others will fail.

This project was made at the fastest speed imaginable. I thought about it for some time did a fair amount of pre production (AKA procrastinating) on the control and physics and display. When I actually went to code, I didn't have time to work on the display, I coded as fast as I could type, and I coded for many hours without lifting. It is amazing to be in that kind of zone.

I was originally just playing around in Batari Basic, with prototyping the basic Mega Man control but I soon made the decision that I wouldn't have the time to re-code the work in assembler and that there would be no way I could tackle the display issues and so I went forward with making the entire game in Batari Basic with the basic kernel.

The code didn't always work but I iterated and debugging was greatly assisted by the fact that I was using a personal copy of Perforce. If it wasn't for Perforce, I would have become frustrated and given up (which takes a lot for me). I don't use Perforce so much for 'source control' as for another level of 'undo'. It comes in very handy after you've been coding and adding features for several hours and then suddenly the game doesn't work anymore. If you've checked in working version frequently, you can just go back to the previous working version, or diff against the previous working version and see where your code has turned to mud.

I think I have a pretty solid engine for platforming games, and on the 2600 as well! Now I can realize my dream of making Sonic.

The Boss Fight (with Elec Man) was originally coded as a seperate file. I branched the code from the basic game and then I essentially duplicated the Mega Man control/physics/display code to become Elec Man. The Elec Man AI is actually controlling Elec Man via a virtual 'joystick'. This is actually a very common technique in video game (VG) programming and VG AI.

After everything was stable in the boss fight, I folded the code back in. An alternative approach would have been to just combine the binaries at the command prompt, something I did with the Amiga Boing 2.0 cart. The data and code were generated seperately and combined with copy /b

I did make fairly regular use of the Stella Debugger although not nearly as much as I did on LEDhead/BLiP Football. I hate to admit it but it's probably because of the use of Batari Basic which nudged me away from using esoteric bit packed data structures. Remeber the quote, if you are too clever in your coding, you will pay in the debugging.

Things that I would have liked to have done better.

- Full height resolution sprites - Standard kernel Batari Basic is limited to half vertical resolution on sprites. I wish I had noticed that was on the box when I bought it! I had to redraw all my basic set of sprites around this limitation! I grew to like it in the end though because the pixels are closer to square.

- More colors on sprites, 4 color flickered sprites ( Background, ColorA+ColorB, ColorA+Background, ColorB+Background) and color changing per line

- A better display. The Metroid Kernel was something that Bob let me look at and use (very grateful) but I didn't have time to try to design or incorporate a better display kernel.

- Sound effects. Strange that I don't have any because usually I am very much into SFX (sometimes I do them first, before anything else!)

- More enemies, enemies always take more time than you imagine to code.

- Ladders. No way to display them, so I left them out.