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!

Multiplayer Learning with Banjo-Tooie

(Games of Taste - Comments from late '12 after varied game competition.)

Banjo-Tooie Multiplayer

Image from Banjo-Kazooi Wiki.

• + Unique library of weapons to use.
• + Distinct character features to fit multiple play styles.
• - Useless melee ability.
• A fix: Decrease cool-down times in attacking while increasing the effective range of the attack.
• - Unintuitive effects from weapons.
• A fix: Define all the effects of an attack in the first pull of the trigger.
• - Clumsy controls in aiming and movement.
• A fix: Keep sensitivity of aiming at a moderate scale, while only keeping movement on one control (not both the directional pad and analog stick); don’t use inverse controls by default.
• - Level design is absent - like a cake missing something sweet.
• A fix: Make levels have high and low areas, while also placing weapons in locations that naturally draw players together.

This past weekend was another Olympic LAN party.  A few games were played, but I felt Banjo-Tooie’s multiplayer needed special mention.  As you can see by the list above, it was… unimpressive.

The game provides a unique library of weapons to use.  Mines, bombs, rockets, and machine gun rounds are all in the form of eggs shot out of a bird.  Special, right?  It is, but all for the wrong reasons.  Mines explode when placed anywhere near another mine, machine guns do zilch, and the difference between higher-damage rounds can’t be told just looking at them.

Speaking of weapons, the melee would be better if it didn’t exist.  When the melee button is hit, the in-game character goes into a dreadfully long animation to do essentially nothing.  That time makes the player a sitting-duck, readying them for cheap-shots in multiplayer matches.  Attacking hand-to-hand is a death wish.

Image from Wikipedia.

There is a fun set of familiar Banjo game characters.  Each one is either fast, average, or slow in movement.  However, the controls make every character feel like they are either antique tanks or sliding on a greased floor.  Turning to aim at an opponent is nigh futile; the prevailing strategy is to shoot like a madman in the general direction of foes.  Maybe then a hit will be landed, but it won’t make up for very touchy controls.

Finally, multiplayer levels lack a lot of what modern games take for granted.  Modern games have elevation levels, ‘safe’ and ‘prospect’ places, and flow to direct players into confrontation.  Banjo-Tooie misses these things by a mile.  To summarize, encounters are random, and players can easily get lost in the cramped depths of the multiplayer arena.

In essence, Banjo-Tooie is a game to learn from.  Being a spearhead of 3D gaming, there are both good things, and terrible things, in the game’s multiplayer design.  Good differences are present in character traits and weapons, but poor weapon instruction, excruciating controls, and no level design leave the game lacking.  May we all learn from Banjo-Tooie’s multiplayer to help make better games in the future!

Windows Insight App

Summary

The Windows built-in Task Manager program is good.  It's my go-to when needed to verify performance, garner information about a program, or kill a pesky process.  At times, it doesn't do enough.

To cover the bases and add the deep-dive functionality that Task Manager lacks, there's now this application:

Screenshot of the Insight App, taken by itself.

Windows Insight App - a program designed to deliver user manipulation and performance data on a targeted process.

Here's how it works:

• On launch, the program finds all processes running on the computer, removing background apps that are more low-level.
• From the list of running processes, clicking the name of the process will populate the name and computer title of the program, further populating other data fields on the Main and Diagnostics tabs.
• Resolution can be changed, screenshots taken, and unlisted (background) processes manually entered.

As it's yet to be optimized and there are a number of features I'd like to add, the program's not yet ready for download.  It'll be up on my GitHub with a link updated here when publicly available.

Considerations / Specs

The Windows Insight App (WIA from here) is made as a Windows Presentation Foundation (WPF) program in C# utilizing the Model-View-View Model (MVVM) framework.

A positive in the development of WIA is how much control over diagnostic information can be given:

A few data-points about a program and the system it's running on.

A current negative aspect about the program is that it checks target processes repeatedly, which can snag a few MB of RAM, more than I'm comfortable with.  Additionally, the program has fallen into the trap of using Object Oriented Programming classes as merely namespace controls (therefore, no longer resembling the original OOP).

Future

Additional options and exposing diagnostic features (read: checkboxes) to users are planned TODOs.  Further, allowing users to change more aspects of their target process and the WIA itself is coming.

In short, optimize and scale.  Get the project's source up on GitHub.  I'll likely stay away from a complete refactor (something I plan to do repeatedly with another tool, Turn Timer), but may come back to clean-up the many redundant classes and re-apply OOP methodologies.

Check in again when new programs, designs, and insights are released here on Make Better Games!