Updating a 22-year-old game brought Andrew Gillett face to face with some very poor coding practices. Read more about it in this brilliant guest article from the latest issue of Wireframe magazine.
In 1998, at the age of 17, I was learning how to write games in C. My first attempt, the subtly titled DEATH, was not going well. The game was my take on Hardcore, a 1992 Atari ST game by legendary game developer and sheep enthusiast Jeff Minter, which had been released only as an unfinished five-level demo.
A series of ultrabombs blowing up a snake.
The player controlled four gun turrets on the outside of a square arena, into which enemies teleported. While the original game had been enjoyable and promising, my version wasn’t much fun, and I couldn’t work out why. Making a decent game would also have involved making dozens of levels and many enemy types, which was looking like too big a task, especially as I was finding it hard to understand the intricacies of how the enemies in Hardcore moved.
So I abandoned that game and decided to replicate a different one – 1994’s MasterBlaster, a Bomberman-style game on the Commodore Amiga. MasterBlaster didn’t have a single-player mode or bots, so there was no enemy AI to write. And the level was just a grid with randomly generated walls and power-ups – so there was no real level design involved. With those two hurdles removed, development went fairly smoothly, the biggest challenge being working out some of the subtleties of how character movement worked.
The game, which I named Partition Sector, was finished in mid-1999 and spent the next 18 years on my website being downloaded by very few people. In late 2018 I decided to do a quick update to the game and release it on Steam. Then I started having ideas, and ended up working on it, on and off, for two years.
One of the biggest hurdles I came across when writing my first games was how to structure the code. I knew how to write a basic game loop, in which you update the positions of objects within the game, then draw the level and the objects within it, and then loop back to the start, ending the loop when the ‘game over’ criteria are met or the player has chosen to quit. But for a full game you need things like a main menu, submenus, going through a particular number of rounds before returning to the main menu, and so on. In the end, I was able to come up with something that worked, but looking back on my old code 20 years on, I could see many cases of absolutely terrible practice.
“I started having ideas, and ended up working on it, on
and off, for two years”
While most of my time was spent adding new features, a lot of time was spent rewriting and restructuring old code. I’m going to share some examples from the original code so you don’t make the same mistakes!
This is just a snippet of Andrew’s brilliant monster-sized tutorial, which you can read in full in the latest issue of Wireframe magazine. No subscription? No problem! You can read the rest of this post in full for free in PDF format.
Website: LINK
