This article originally appeared in Dev.Mag Issue 13, released in April 2007.
Overseer Assault is a freak of nature. Now that statement may seem harsh, especially coming from the game’s creator, but it’s true – Overseer Assault is a game that shouldn’t work, but through some dark and twisted means just does. One need only look at the description to understand: OA is a hybrid top-down shooter/turn-based strategy game. It also happens to be the first game that I ever made. Ambitious? Absolutely. Flawlessly executed? Not entirely…This is an overview of the Making of Overseer Assault, and new developers would do well to heed the painful lessons contained herein.
…And ne’er the twain shall meet
One hot rocket coming right up!
Overseer Assault was conceived for Game.Dev Competition 12, where the aim was to build a multiplayer game that could be played on a single computer. I wanted to build a game that simultaneously pitted players against each other in the opposing roles of attacker and defender, as a way for both to exercise their tactical skills from two separate viewpoints and play styles. The original plan was to have a real-time split-screen game with both players fully mobile, one equipped with powerful offensive weaponry in order to kill the other, who was loaded out with cunning snares and traps to deter the pursuer. This idea quickly evolved into OA as it is now – turn-based with a fully mobile, powerfully armed attacker tasked with destroying a stationary opponent with the ability to place defensive turrets to protect itself. Initially I dismissed the whole idea as unworkable. It was an ambitious project for a newbie who had only ever coded in VB6, and I was only just starting to get the hang of programming in Game Maker (the framework/IDE used to build OA). Nonetheless, an annoying little voice in the back of my head urged me on, and the result was… Interesting. The moral: think big!
The almighty firebomb wipes out another bank of turrets
Seeking Balance (What went right)
One thing that I realized from the outset was that OA would have to be meticulously balanced if it was going to work, and to my great joy balance was one of the main areas of praise for the game. Now, I wish I could say that I sat down for hours on end mapping the interrelationships between weapons and sides on a spreadsheet, but I put far less effort into balance than one may think. This was due to my core design philosophy: no one side should overpower the other. By keeping this “mantra” in mind when conceiving the weapons and game mechanics I was able to easily implement the balancing with very little effort (even for last-minute additions). In fact, I spent less time tweaking the game balance than anything else, and the two sides still worked together beautifully. The lesson is simple: determining and keeping to a core philosophy/philosophies for your gameplay in the design phase can reap great rewards when it comes to actually building the game!
Aaaagh! They’re everywhere! (What went very, very wrong)
As some may be aware, the original version of OA was overrun with bugs. It was suggested that this was due to the scope of the game but, alas, I knew better… The attention that I paid to the game mechanics wasn’t duplicated when it came to the code. Code was unplanned and hacked out at the spur of the moment with the sole aim of getting the game to function as I had initially designed it, and with a complete disregard for any future modifications.
Well, the game did work, until I tried to change it! A good example was how the code for all the turrets was lumped into a single object, something that would give any self-respecting programmer a seizure. The code ended up being so convoluted that adding a single new weapon or turret to the mix was an exercise in misery and frustration, and resulted in some truly game-obliterating bugs due to the single-object structure of the turrets. Eventually I was so lost in my own code that I considered trashing the whole lot and starting from scratch, but with a competition deadline looming it would be certain suicide. So I cleaned up what I could and submitted it with bated breath.
OA ended up winning second place in the comp due to its concept and balancing, but it became a shallow victory when the judges mentioned the bugs. My own lazy coding practices had killed a potentially great game.
An Overseer fends off a dual prong attack
Redemption is nigh!
Fortunately, Competition 13 came along, and I resolved to turn OA into something I could be proud of. The aim of Competition 13 was, quite conveniently, to polish an existing game to the point that it could be sold. Out came the pen and paper: OA’s code was ripped apart and, where necessary, rewritten. Turrets were given a fully Object Oriented makeover, which in itself killed about half the game’s bugs in one fell swoop and made the game much easier to modify. The code that handled timing and player turns was refined, the graphics were spruced up, and sloppy design was rectified. In short, the game was rebuilt to play the way it should have. The code still isn’t stellar, but compared to the original version it is much improved, and the game finally plays as beautifully as I intended.
In the end, OA turned out a game that I could be proud of, and ended up winning Comp 13, which was as gratifying as it was surprising. I also learned why a game’s code structure needs to be designed solidly from the outset, a lesson that I’d like to shove down the throats of all the other newbie game devvers reading this. As for OA, it’s a concept I’d like to expand on sometime in the future. It was mentioned that the game could do with a graphical overhaul, and I’m looking into that.