No DS coding today. Not even any thinking about DS coding. Just a quick post to note that the MenuDS demo got linked on DS-Scene, which is a site I have actually heard of and visit fairly regularly. It garnered two comments. The first decried MenuDS as being “useless and boring”; well, duh, it’s a demo of a menu system. Please pay attention at the back. The second pointed out that it’s a developer tool. At least someone gets it… Anyway, now that the peripheral stuff’s taken care of, I can move onto the game. Whilst I’m thinking about this, I’ll just jot down some structure ideas:
- Need a base sprite class that’ll handle drawing the sprites to the screen, collisions, positioning, etc;
- Either need a base enemy class that inherits from the sprite class (and enemies inherit from that), or a single enemy class with a “type” member (not a clean solution), or (even better) a single enemy interface, and a set of enemy classes that inherit from the sprite class and implement the enemy interface (though I’ll need to check that C++ supports the concept of interfaces);
- Need a player’s ship class that inherits from the sprite class;
- Probably need a player class, that contains things like score, lives, etc (unless I just stick all of this in the ship class - why make things more complicated than they need to be?);
- Need a “game” class, that acts as a single external interface/entry point to the game and runs all of the other code (good idea to keep player stats separate from the game class in case I decide to try and implement a simultaneous WiFi two player mode, or something daft like that - with this in mind, I wonder if it’s worth putting all of the joypad-handling code in the game class, rather than in the player class?);
- Need a map class;
- Need a bullet class that inherits from the sprite class.
I think that’s everything I’ll need. The complicated bit will be learning how the PALib sprite system works and writing the sprite class. Everything else should be pretty easy.
The time-consuming parts will be grabbing the images from the Amiga game (I wonder if there’s a Blitz sprite to IFF converter on the Aminet somewhere? I could write one if there isn’t - maybe that’d save some time) and grabbing the sound samples. The Amiga samples are very low quality, and don’t convert very well to the DS. Alternatively I could go back to the original source (via MAME) and grab the sounds myself, but the problem with this is that I don’t have MAME for the Mac, and it probably won’t perform very well in Parallels.
Another hugely important and time-consuming aspect of the game will be tweaking the way it plays until it’s enjoyable. This is where I hope the original Blitz code will prove most useful.