Feature Requirements in Games

Industry Identity Crisis

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

The short answer is no. (The longer answer is ‘yes in some ways, no in others.’) More accurately, the games industry is in the business of entertainment. Your job as a game maker 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 have tangible rewards (story progression, beautiful art, nice cutscenes.)

Meanwhile, if you look at a word-processing software like Microsoft Word, it has a bunch of functions that allow you to type in something such as a book report. And then it has functions that (1) save the data you input into a file and (2) transmit the data into an output device, like a printer.

Software development is about building something that fulfills a definite purpose. You do not need to create data for the software unless it’s a help document. The end-user creates the data — book reports, inventories, invoices, user accounts, digital art, and so on.

The point here is that video games have a really abstract function: fun. And to fulfill this elusive human desire, we have to make some software as tools and make the content of the game for the person to play with.

1. You need the tools (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 play it.

A very, very simplified chart of what we do.

This post is about feature 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

Feature requirements change all the time. You start out with one feature – say, a battle feature – and pretty soon you may have an item system, maybe the battle has changing environments, maybe the environment modifies the abilities of some player character type, and so on.

For the purposes of this post, I'll be drawing some points from the project I'm working on, which is a PVP, battle-oriented mobile game called Monster Roller. To illustrate how different a game can be from initial conception, here are 3 mockups all of the same core battle system:

The screen on the left was the earliest, but we finally ended up with the screen on the right. The current iteration was made to be easy to understand: pick an action mode (the numbers 2-1-1 next to the monster avatars) and the monster performs an action related to that mode after you flick the roller. 1 is the attack mode, 2 is an ability mode that varies from monster to monster, dependent on role.

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.’

“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 powerups, 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 at NO PAY into 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.

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 feature requirements evolve:

We start by prioritizing based on how core the feature is to the game. Then we make prototypes based on what we think we’ll be putting into the game, with sample data. For this last part of the article, we’ll go over the battle system’s components. 

The Monster Roller Team had several functions we wanted to do, at the very beginning:

• The gameplay would be a lot like an RPG but mixed with some card game balancing
• We would have the slot machine reel, of course
• Which would net bonuses based on jackpots (4 of a kind back then)
• We considered bet multipliers
• ‘Holding’ — keeping a slot from spinning (you would have to pay to do this)
• Switching out monsters during your turn
• Using items on monsters (that was the ‘obvious’ thing to do, wasn’t it?)

That is not a list of feature requirements. That’s just a wishlist. Feature 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 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?

… And so on. The document that answers those questions will then be the feature requirements doc.

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

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 feature requirements changed between then and now.

Top Row Old:

Top Row New:

They both have a gold 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 would suck to be waiting for a long time for your enemy from around the world to decide how to attack.

Battle Screen Old:

Battle Screen New:

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 monster!) 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:

Lots of changes here. Let’s look at the cherry bar first. The cherries were to be earned for every round in battle, filling up slowly. The other way to gain them was to roll 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 — This affects 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 feature requirements) so we added one in to make the game more intuitive — just press the damn button!

Bottom Menu: Old

Bottom Menu: New

And now we get to the last segment: the bottom menu. You’ll see the price for the items and theswitch out action available in the old version, which was simplified down to autoplay and switch out.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 at the crossroads of entertainment and software. In addition to developing a software, other disciplines combine to solve the problem of 'what is fun?'
2. Ditch the mentality of clinging to a certain set of feature requirements. They change, a lot, in ways that will surprise you.
3. Games are made of true and iterative innovation.
4. Defining feature 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 feature 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.