I’m working as the associate Game Designer on Railgun, an action shooter for Windows PC, built using Lua scripting and Flow Visual Scripting in Autodesk Stingray. Levels and some of the game play systems are my forte, here’s how I go about designing things:
Companies such as Blizzard typically start their design balancing from the bottom-up. Starcraft was made by first balancing the starting worker and warrior characters: Terran Marines, Zerg Zerglings, and Protoss Zealots are fine-tuned with each other before other units hit development. I apply similar principles to the evaluation of Railgun’s systems in these ways:
- If the base weapon and unit are not fun, we have a problem.
- If a new weapon or ability isn’t fun with the base unit, we have a problem.
- If a new unit isn’t fun with the base weapon, we have a problem.
These tenets make it easy to develop scenarios for different aspects of the game. Though there can be exceptions (after close analysis), generally removing ambiguity simplifies the testing process and the communication that needs to happen with other members of the team (i.e. explaining design philosophy).
100 of a unit, the weapon choice for the player, and leaving everything else the same further allows for standard algorithms to be generated in predicting the outcomes of play (more on this below). Repeated tests can refine prediction variables, but they get designers working with something decently accurate to the final outcome quickly.