“From the Vault” features old pieces I wrote for previous projects and employers. This article was originally published on Gamasutra here (and here for the web archive with photos). It was intended for Gamasutra’s audience of game developers, with prior knowledge of the terms and mechanics common to the industry. It has been edited and rewritten here for clarity and depth.

Industry Identity Crisis

Quick question: are you in the software industry if you make games?

The short answer is no. (The longer answer is “it’s complicated,” as all things are.) The games industry in practice resembles the broader entertainment industry — after all, games are compared to movies and music, but not to bitcoin or payment processing.

Given this, a game maker’s job is to entertain people. Make them feel better about themselves. Reduce the complexities of the world into a pixel-perfect, enjoyable experience. Games have objectives that beget rewards (story progression, beautiful art, nice cutscenes.) A game may be a piece of art, it may offer interactions that change a player’s perspective — but it’s likely going to propel the player towards whatever transcendent experience it offers by entertaining the player in some way.

On the other hand, software such as Microsoft Word has functions for typing in book reports, technical documents, reports, etc. You can save your file and print it out. Traditional software development is about building something that fulfills a definite purpose. In contrast, video games have a really abstract function: fun. And to fulfill this elusive function, game developers have to make the following:

  1. The tools and game engine (software) to craft an interactive experience
  2. You need the data — player classes, enemies, the story — that the user manipulates for fun
  3. You need to make sure the data and the software it uses is optimized so that people can access the game and keep playing

Note the decoupling of the game engine and tooling from the data (text, art, etc.) Another way that games stand apart from good old software is that there is a specialized subset of labor making the content that comprises the game. Devs and designers working for Twitter don’t provide the user with tweets — the users themselves do. Neither does WordPress write the blog for the end-user. Game development has dedicated level designers, writers, and directors as part of the development process, typically scripting in content that the user then manipulates.

A very, very simplified chart of what we do. The BUILD is the endpoint.

Today’s design log is about functional requirements in games. While it sounds pretty straightforward to have a list of features and the parts needed to fulfill that feature, it can get hairy pretty fast.

Making games is a mess

Functional requirements change all the time. You start out with one feature, such as a typical RPG turn-based battle feature, and pretty soon you may have an item system, maybe the battle feature has changing environments, maybe the environments modify the abilities of some player character type, and so on. We’re currently developing a slot-based battling game called Monster Roller, and the before-and-after photos of the battle screen paint two different games.

The knee-jerk reaction at first for a game with an RPG-looking battle system is, “Of course your game needs an item system, power-ups, a store, and so on.” However, over the course of development we dropped the item system. That meant deleting weeks spent coding the item system, the interfaces for it, the balancing, the names and effects of items.

“Why didn’t you figure out you’d need all this?”
“Why didn’t you figure out that you DIDN’T need all of this?”

Making games is a mess, because true innovation is a mess. The other kind of innovation is ‘iterative’ — building on known formulas. Games are made of a combination of both, in varying degrees. While developers may get tied to certain formulas (a racing game needs these kinds of tracks, these kinds of power-ups, and so on), at the end of the day, you can’t serve a mojito like everyone else’s mojito in an industry where so many are willing to give eight or usually more hours with no pay to finding the holy grail of fun.

Making games is a humbling experience. You start out thinking you know what this game is going to be.

But it’s a tower on the verge of being unbalanced, all the time. Maybe it turns out that it’s too derivative, or the mechanics were too different to be meshed together, or it is hard to get into, but fun. A certain degree of experience mitigates this, of course, and a veteran will likely have a better idea of the pitfalls, but the true creation of something is always… unexpected. That’s what being new and innovative is about.

How functional requirements evolve

Priority is based on how core the feature is to the game. For a monster slot-machine battling game, we made the monsters and the battle scene (with rollers) first. Then we made layouts (UI, wireframes) based on what we thought we’d be putting into the game, with sample data. Mechanics such as hatching came later. For this last part of the article, we’ll go over the battle system’s components. We had several functions we wanted to do:

  • We would have the slot machine reel, of course
  • The slots would make up whether an attack landed, missed, or was critical (similar to a dice roll)
  • Which would net bonuses based on jackpots
  • We considered bet multipliers
  • Holding’ — keeping a slot from spinning (you would have to pay in some form of currency to do this)
  • Switching out monsters during your turn
  • Using items on monsters (that was the ‘obvious’ thing to do, wasn’t it?)

But a list by itself is not a functional requirements doc. Functional requirements may include things like a proper description of what’s going to be in it (the data), how it’s going to be presented (UI), and success criteria if it’s working the way it should be working.

Let’s look at the items system for example:

  1. What would be an item’s scope? Would they be used on the player’s party, or enemy party, or both? Can they have a turn duration? What variables can these items act upon? HP? Attack? Heal value? In percents or wholes? And so on.
  2. Could they be reused after the battle, or are they consumable per battle?
  3. Do they have a cost to use them? How is this cost implemented? Is it the number of turns in a battle (time cost) or some other metric? Do you have to buy them in a store? Hardccy or softccy?
  4. How would it look?

The document that answers those questions will then be the functional requirements doc.

Now, as to the evolution of all those systems and functions, let’s take a look at battle.

Phew. There’s a lot going on in here.

The left mockup was made by yours truly almost half a year ago. The one on the right was made by a real artist, and is how battle looks now. Let’s go over what we see on the screen to find out how the functional requirements changed between then and now.

Old top row:

Elements: Softccy, autoplay, and settings

New top row:

Elements: Timer, Softccy, lights, and settings

They both share a gold / softccy indicator and a settings button. The prototype’s Autoplay moved to the bottom row in the latest version (see below.)

The biggest change is the addition of lights around the frame that change based on what’s happening, and the timer. We added the timer because the game is PVP — it isn’t fair to have to wait for a long time for an opponent to make their move.

Old battle scene:

Elements: Enemy monsters & health bar

New battle scene:

Elements: All 6 active battling monsters, health bar, target selection, de/buff indicators

You’ll notice the original mockup failed to account for selection indicators (the arrows on top on the left), or showing things like negative/positive status effects (look at the super tiny octopus on the left screen!) There’s also the difference of seeing your monsters in battle. The other major change was simplifying from 4 monsters to 3 monsters. We did this to speed up the pace of battle and to make it easier to gain a jackpot.

Rollers and Avatars, Old & New:

Elements: cherry bar (mana pool), roller slots, roller behavior such as jackpots, etc.

Lots of changes here. Let’s look at the cherry bar first (bright blue on the left side). The cherries were to be earned for every round in battle, filling up slowly. The other way to gain them was to roll for them. These cherry points could be spent to use an item, or switch out characters, analogous to mana or energy in card games. However, the item system and the cherry points were both later removed.

We didn’t add in the cherry points because “it was what everyone was doing,” either. We added them in because having that choice made the game less about luck and more about strategy — choosing the ‘right’ action. Do I use THIS item or switch out THIS monster? We had a definite reason for having items and costs.

Why then was the system scrapped?

If you look at the variables of a battle game, there are plenty of factors that can be controlled without adding another system:

  1. Targeting — Will you auto-target or focus on one?
  2. Abilities — Attacking, De/buffing, Defending, Healing, Elemental strengths and weaknesses
  3. Combos — Three of a kind jackpots, monsters that can ‘buff’ other monsters’ abilities
  4. Lineups — Monster lineups affect the chance to get combos
  5. Time Limit — you have this much time to decide what your strategy will be

It’s tempting to add in a feature at the beginning of development. This is because it’s difficult to visualize how features interact with each other and how it impacts the gameplay. It’s easy to think, “this is not enough,” because we haven’t yet created content. Prototyping helps greatly in killing that feature bloat temptation. Considering all of the above variables, the item system would have been another thing to balance — not only for the devs, but for the player as well. The idea is to make each of those variables above relevant to winning the game, not to add another feature.

Amazingly enough, there are two other variables we could spend all day talking about, compressed in this section of the UI: how the roller behaves and what goes into the reels. (Does the slot machine have a ‘hold’ function? How does it process a jackpot? If a monster is stunned, how does the roller react? How are slot compositions made? Do all slots have some kind of 3 of a kind jackpot? Etc.) For now, a passing mention of all these variables is enough to illustrate the evolution of the function.

The last change in this segment is the Let’s Roll button. Although originally we were thinking it would be fun to flick the reels, quite a few playtesters looked for a button (playtesting is an excellent way to determine functional requirements) so we added one in to make the game more intuitive — just press the damn button!

Old bottom menu:

Elements: “roll” button (notice how it’s not prominent or obvious), item button, and “switch out”

New bottom menu:

Elements: autoplay, “Let’s Roll!” button, “switch out” button

And now we get to the last segment: the bottom menu. You’ll see the price for the items and the switch out action available in the old version, which was simplified down to autoplay and switch out. The item menu was scrapped entirely. Another reason for careful pruning of systems, apart from the great number of things the user has to keep in his or her head, is real estate on the screen. The language in Monster Roller is already quite dense with the icons, jackpots, elements, and targeting. Adding another visual language is another set of things for the user to memorize.

Phew. That was a pretty long post.

Quick recap:

  1. Game development is closer to the entertainment industry.
  2. Ditch the mentality of ‘clinging’ to a certain set of functional requirements. They change, a lot, in ways that will surprise you.
  3. Games are made of true and iterative innovation.
  4. Defining functional requirements is more complicated than just writing down a wishlist. Ask yourself how this feature interacts with other features, and list down all possible ways of implementing this feature.
  5. Prototype the core feature based on the functional requirement and prepare to tune/tweak as needed.
  6. You’re not done until it’s fun.

Congratulations for making it this far. Here is a picture of bacon.

Until the next post!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.