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.
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.â
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:
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:
âŚ 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:
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.
Congratulations for making it this far. Here is a picture of bacon.