Robotron is one of the finest videogames ever produced. I’ll accept no argument on that score.
So of course, back when we did the Eugenius issue of Way of the Rodent (we’re not dead, we’re just sleeping) celebrating the highs and very highs of the career of Eugene Jarvis, I foolishly thought it would be a jolly idea to try and write a clone of Robotron for the NGPC in a week. It was originally intended to a) allow me to waffle on about the game for a bit as well as b) give me something to aim at on the NGPC and c) show some “props” to the original developers (or for that matter anyone who ever actually manages to finish a game)
Anyway, that version of the game has been available for ages on various sites now, and, well, it’s a bit basic.
There’s a lot of the DNA of Robotron in there, the grunts zone in on the player, the family are all present and intact, and the base mechanisms for the game are largely there, but it was never going to set the world on fire like that.
But those 7 days weren’t the end of Robotron on the NGPC. I carried on developing it for a while as and when I could, and well, when I found my source code recently there it was. So, I thought it was about time I “finished” it. It’s not perfect, far from it, but it is functionally complete, playable and available for public download for the first time.
A little bit better, I hope you agree…
After sitting through the tutorial, I thought it would be worth having a deep-dive into a completed game. So, the full source is available on the download link at the bottom of the article.
I won’t bore you with a full code listing here, but a few things to watch out for.
Firstly main.c is not the main program. This “merely” contains the bootstrap and a relatively light loop which mainly checks for game over and level progression.
The main game logic is all held within robotron.c/h. All game objects are encapsulated in a series of structures:
- Sprite
- Generic sprite structure, shared between player, shots, family and the Robotrons
- Laser, extends the generic sprite structure for the player’s shots
- Player, extends the sprite for information about the player, including score and shot counters
- Robotron, extends the sprite for information about your enemies, the evil Robotrons
- Level, includes all enemy information for the current level
- Game, contains meta information and parameters about the game itself
These objects are created as variables in rtDrawLogo(), rtCreateLevel() and rtCreatePlayer()
The Player, including all input and shot collision detection is handled in rtMovePlayer()
All Robotron movement, including the human family is handled by rtMoveRobotrons(). This branches out to enemy-type specific routines such as rtMoveGrunt(), rtMoveHlk() etc where applicable. Some of the individual robotron movements aren’t fully realised yet (Brains are a bit stupid, and Progs don’t want to move for some reason, so I’m still working on those)
All collisions between the Robotrons, Human Family and the player are handled in rtRobotronCollision(). This is probably the single piece of code that needs a little bit of explanation… Basically, I wanted to lock the game to as close to the VBLANK() as possible and there are a lot of potential collisions in Robotron:
- Collisions between a shot and the Robotron
- Collisions between a Robotron and the player
- Collisions between certain Robotrons (Hulks and Brains) and the Last Human Family
The first two of these are pretty straightforward and relatively limited (one player, four or five shots at most) so even with a brute force collision method of testing every Robotron on screen against them you’ll only be spending a relatively consistent 300 distinct tests to figure out whether you’ve hit something.
The problem comes when you try and test Robotrons against the Family (or against each other in the cast of Electrodes) – there can be as many as 50 of these that need to be tested against each other – so at worst we could have 25×25=625 distinct brute force “have ‘these two’ things collided” tests.
So, what we do is to lock the collision detection into a single VBLANK, and attempt to pick up the collision detection loop on the next blank if we haven’t quite got round to it. It appears to work.
The controls also need a bit of explaining – unlike the arcade original, which requires a twin-joystick that the NGPC simply doesn’t have, the game will auto-fire. You move using the joystick and rotate the angle of fire by 45 degrees clockwise or counter-clockwise using the A and B buttons.
This is still a work in progress, but it’s playable, mostly functional and generally feels quite like Robotron. Which considering the limitations of the NGPC (specifically with the controls) I’m quite pleased with. Full source is available here and if you just want to play the game in an emulator of your choice you can grab it from here
Chris Ahchay 