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!

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!