Philosophy on Design Progression and Balance - Railgun

Image from Railgun Twitter page.

(This post was first drafted and published here.  Updated and reposted with permission.)

I'm working as the associate Game Designer on Railgun, an action shooter for Windows PC, built using Lua scripting and Blueprint-like Flow in Autodesk Stingray.  Levels and some of the gameplay systems are my forte.

Here's how I go about designing things:

Bottom-Up Balance

Image from Battle.Net.

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:

1. If the base weapon and unit are not fun, we have a problem.
2. If a new weapon or ability isn't fun with the base unit, we have a problem.
3. 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.

Copy-Pasta Templates

Image from RailgunGame.com.

Dictating parameters in a way that can be quickly replicated is a (glorious) feature of Visual Scripting, something Stingray and the more well-known Unreal Engine 4 take to heart.  Each node exposes only the necessary variables needed for design - K.I.S.S. and YAGNI reduce option-overload for non-designers, designers, and even the original background-code developer of the node.

After overcoming the psychologically debilitating selection of choices in Flow, I increase the speed of level generation by copying-and-pasting more complex code structures that only require first-time setup.  Time is then only required to tweak parameters for a given level to fit my progression modeling.

Not Designing in the Dark

Artists and writers often face detriment when it comes to the blank space of a page.  The same happens to a designer facing an empty level: What goes where?  Is it too tough?  How many rewards is the player going to get?  Does a story fit here?  Should it?

That's where abstract prediction algorithms come in.

At the earliest opportunity, get a visual representation of the game over time/space.  Even a back-of-the-envelope sketch of how difficulty, progress, and other measurable aspects guides the design process without doubt as to if the designer is going beyond their means.  This will guide design throughout the product lifecycle, projecting expected outcomes once the game gets to players.

It's important to prototype what is going on in-game before diving into the editor to see how things look on a spreadsheet (stereotypical friend of the designer).  Paper prototyping (or putting in ready-made assets into a blank, digital level) delivers what the base game could feel like, thereby outlining a point about which to escalate in difficulty.

Image from RailgunGame.com.

As for starting to put in units and objects into a level, a general rule-of-thumb is to keep the first few minutes of the game educational (AKA the tutorial).  I involve one, at most two opponent types (these can be puzzles or similar obstacles in other genres) with enough change in the space of the level to encourage using nearly all the controls available to the player.

In 8 short steps:

1. Paper-prototype game timeline/progression.
2. Develop prediction algorithm.
1. Compile game telemetry data to determine trends.
2. Play the base set (unit, weapon, etc.) of the game repeatedly, plugging in the aggregate data (deaths, points, play time, etc.) into a tool such as Google Sheets, and deriving a value from that.
3. Create basic first level.
4. Apply prediction algorithm.
5. Repeat processes three and four (approximately) to game design completion.
1. By "completion", this means that there's content in every level, every unit/weapon has been implemented in code.
6. Play the game; refine the algorithm's parameters, unit stats, and level design based on the firsthand experience.
7. Get others play the game; observe performance, ask what players don't like, and never blatantly implement a solution offered by an outside party.
1. Solutions to problems is the role of the game makers; players also tend to be biased towards fixes that benefit their style of play.
8. Repeat steps six and seven to and through launch.

Image from Railgun Twitter page.

Conclusion

With simple rules and graphical projections to guide development, putting together levels and gameplay systems can be significantly sped-up while also decreasing the tweaks needed to balance the experience.  Railgun is one case study where this is working to great effect.

Look for more news from Railgun soon.  Check in again when new programs, designs, and insights are released here on Make Better Games!