Low-Fidelity Prototype

• Requirements
• Estimated Time to Completion
• Dificulty

 

Objective

On the last two tutorials, we went from a rough idea to a clearer (not definitive) one, while we created two documents very common in the game design process. The good news is that in this tutorial we will not delve again in the realms of documentation, so uncanny to some brave men. The bad news is that we shall transverse the path of prototyping, which is feared and hated by (I risk a guess here) even more. Just to make it clear: I’m not a fan of prototyping. But a man’s got to do what a man’s got to do!

On this tutorial, we’ll create a low fidelity prototype for our game. With this prototype, we will test the game’s essential mechanics, and assert if we should continue the process to what will (hopefully) be a complete game.

As usual, there will be a lot of theory, which will make a short tutorial extend for more pages than needed. Because this is my website, and I write as I want!

 

Keywords

Game Design, Communicating Ideas, Game Development, Game Prototyping, Paper Prototype, Game Mechanics.

 

Prototyping / Physical Prototyping / Game Prototyping

Prototyping allows an early creation of a model or representation of a product under development. For instance, if we look at buildings’ models, used in architecture, we have a broader look of how the building will finally come out, without needing tons of concrete, heavy machinery, and hairy and sweaty construction workers showing their asses’ cracks every time they bend to pick a brick from the floor. Besides preventing unwanted body displaying (in the given example), prototyping allows to test the feasibility of an idea, and make changes to it on an early stage. It also allows to test the product’s users (and other stakeholders) acceptance without too much work done. There are different types of prototypes, like physical prototypes, visual prototypes, video prototypes, software prototypes, etc, and they can all be used in the same project. To test our game, we will use a type of physical prototype in this stage. It is probable that we must use other types in the future.

A physical prototype is a type of prototype built by using materials like cardboard, paper, pens… pretty much anything you can get your hands on that you think is going to be needed (watch Wii U’s gamepad example here). This type of prototypes are low fidelity, meaning they do not resemble (nor should) the final product. Creating this type of prototypes allow for the designers to focus on the function and not on the form and also allows non-technical people to participate in the design. Above all, this type of prototypes are fast, easy and cheap to develop, being easily discarded and redone as much times as necessary until a satisfactory design is reached.

You create a game prototype to test some aspect of the game you’re designing. A prototype should be focused on answering a question about the game. For instance: “Is this game playable at all?”; “How big should the board be?”; “How many players can the game have?”. It is normal that while you prototype your game, new ideas appear. It is just a matter of testing them in another prototype, and evaluate if you should stick with them or discard them now. To be true, you should make yourself think about alternatives to your design, and problems that may arise. This step can be the heart of the design process, since you’re working with something which “exists” and not simply some “imagined game”.

What I really want to point here is that prototyping is important. And no, YOU SHOULD NOT SKIP THIS STEP!!! Have you noticed the caps lock and three exclamation marks? I do this when I’m dead serious about something. When I use only one exclamation mark I may also be serious, or I may be just joking!

Down the road in this tutorial we will create a prototype for our game. But not just yet. For now, we need to make a quick stop somewhere named “THE CORE” (suspense theatrical music played here).

 

The truth lies in the core

Tracy Fullerton’s “Game Design Workshop – A Playcentric Approach to Creating Innovative Games” (link) is a highly recommended book about Game Design. Read it, please. If you do this, and take the time to do the proposed exercises on it, you might just well end with the game design for a good game. But only do this IF you have the time to do both Tracy’s exercises AND my tutorials. In case of doubt, chose my tutorials, please, for I have abandonment issues! Anyway… on this book, if you read the chapter about prototyping, you’ll see the concept of ‘Core Gameplay’.

Core Gameplay represents the most common actions the player executes while trying to achieve the game’s goal. For instance, in Pac Man, we can say the core gameplay is pretty much avoiding ghosts, and eating “dots”.

Defining your game’s core gameplay is an important step when prototyping, for modeling your entire game could be overwhelming. By identifying the “essential” actions in your game, you can start your prototype from there, and build on top of it.

Besides that, identifying core game mechanics also allows you to identify and correct any eventual feedback loop that throws the play out of balance. You may use some sort of diagram (in the book, Tracy introduces some examples) and it can be as simple as a hand-made sketch, or a brief description, like the ones I stole from the supra-cited book:

• WarCraft: Players build and move units on a map in real time with the intent of opposing units in combat and destroying them.
• Monopoly: Players buy and improve properties with the goal of charging rent to other players who land on them in the course of play.
• Diablo: Players battle monsters, seek treasure, and explore dungeons in an attempt to amass wealth and become more powerful.
• Super Mario Bros.: A player controls Mario (or Luigi), making him walk, run, and jump, while avoiding traps, overcoming obstacles, and gathering treasure.
• Atomic Bomberman: Players move their Bombermen around a maze and drop bombs next to their opponents in an attempt to blow them up.

Even better than a textual description, or a sketch, would be to have both. Of course we’ll have both!

 

‘Evacuate, princess!’ ‘ s Core Gameplay

First, we need a short textual description of our core gameplay. Even if there seems to be changes in meaning and consequences of player’s actions, the fact is that (at least for most games I know – and for this one also) the possible actions are limited and repetitive. In our game, they would be something like this:

 

The player chooses one of three princesses, and controls her escape from the castle. The princess can run, jump, and use toilet paper and a rope to overcome obstacles and avoid enemies.

 

This pretty much sums it up. Of course for someone without an extent understanding of the game, this would seem pretty dumb. But not to us! We know better, don’t we? We know this game is going to be LEGEN… wait for it…

The representation of core gameplay in a visual manner describes not only the player’s actions, but also the “game world” and the simplified “economics” in the game. For our game, and for the time being, it’s about this:

Explaining the arrows, the player runs, jumps and uses the rope and toilet paper to avoid foes and overcome obstacles. He picks power-ups in the world which give his princess special abilities. The player’s actions convert into points which may be used to unlock rewards.

This pretty much sums it up. Now we may build our prototype.

 

‘Evacuate, princess!’ ‘ s Paper Prototype (AKA Game Designer’s Version of Art Attack)

Tracy Fullerton describes 4 steps to build a physical prototype efficiently, and we will follow those steps. You’ll see as our core gameplay translates into a prototype capable of emulating the mechanics of our game. It can also transform on a complete abomination: I was never good at art classes.

The first step is THE FOUNDATION. On it, you build a physical representation of your gameplay. You can use cardboard, scissors, other games’ pieces, paper, bacon, glue, etc. What matters is that you design the basic game objects and procedures for the game. Here, you should ignore questions that arise that will need more than “essential” actions to test. You should try to keep the gameplay mechanism down to as fewer rules as possible, only adding any rule if it is needed to make the mechanics playable.

I started the prototype development by drawing a game level in Microsoft Excel. I had the care to make every section in the level fit into an A4 sheet. This way I can change parts of the level by changing the correspondent sheet. I also bought a magnetic A4 board. Magnetic boards are cool, because with them you can easily simulate movement on the screen by using magnets for characters, foes, booby-traps, etc.

Talking about movement, when using this prototype, the player can’t simply move the magnets on the level as he wishes and jump as he wants, for it would completely remove the “puzzle” characteristics of the game. So in order to limit this, I bought some acetate sheets, I cut them in smaller pieces, and used an adequate pen to draw lines and scopes representing possible running distances (horizontal lines), jumps (slopes) and the usages of ropes and toilet paper (the “shot” position, the “hit” position and the movement line). Two little details: the movement and jump transparent sheets are numbered and have a correspondence between them. With this I can simulate the needed speed for a player to make a jump. The other detail was inserted in the sheets representing the usages of toilet paper IN THIS GAME (not the usages in real life that we all know about – that’s just crappy). On each sheet, I wrote a little number representing the “resources needed” for that usage. This way I can simulate an important trait of this puzzler: the need for the player to use its resources wisely.

To simulate the resources I have cards (small ones, to save trees) which represent 1 “resource unit” of toilet paper. The player gives them to me when he uses a move with toilet paper (the number of cards being equal to the needed resources) and I give them to him when he gets some more resources (they’re spread around the level). I also have 3 cards in shapes of hearts, simulating the player’s lives.

At this point I had a first prototype, simulating the essential procedures. While I was developing it, one question arose: if I want the levels to have multiple paths, how to balance them so none is too easy, and avoid dead ends. It will be a problem. But it has nothing to do with the foundation, so it will be something to think about later (maybe during level design). Yet another problem concerns the “meaning” of having toilet paper and rope. If you remember, this “toilet paper and rope” idea came from the lateral thinking process explained in the first tutorial of this series. I like the utterly nonsense of it, but nonsense is not everything. So having toilet paper and rope is only justifiable if there are different uses for them. In the first version of the prototype, I had different obstacles. But it didn’t seem enough to justify both objects. If nothing changes, one must go. Something to care about in other step of prototype creation.

Problems aside, I now had a prototype with the foundation all set. Although far from finished, I suppose it wouldn’t hurt to show it to one or two friends before any more work. Maybe you can get some feedback, or find any problem you didn’t notice. On the worst case scenario, you get nothing from it and you are now owing your friends a favour.

Now the foundation is ready, is time to pass to THE STRUCTURE. With structure, you add the rules that define your gameplay. Do STRUCTURE and FOUNDATION sound similar? They shouldn’t! Phonetically they are two completely different words, dummy! Their definition, however, may seem similar. As a disambiguation, look at them the way I do: Foundation defines (mostly) the mechanics of ‘your type’ of game. Structure defines the mechanics of ‘your’ game. If we were prototyping Mario and Sonic, their foundation could end up basically the same. Their structure, however, ought to be significantly different.

Tracy defines the structure as “the framework you need to build your game. (…) a skeletal structure that can support the rich and varied feature set that will be your finished game.” She also points the importance of the distinction between rules and features, whereas features are defined as “attributes that make a game richer” (more weapons, new vehicles) and rules are “modifications of the game mechanics that change how the game functions” (winning conditions, turn order). Adding new features demands adding new rules (a new weapon would need rules defining how it can be used), but new rules can be added without changing the existent features (you can change the number of hits a player can get before dying without changing any game feature). Because of this, during this stage of prototype creation, you should concentrate on rules first, letting the features for latter (if possible).

To add structure to the game, I´ll add the rules defining the height of a “deadly fall” and the different usages of the toilet paper. I find this necessary to prototype the puzzle elements of the game, and the meaningful choices the game needs. Also related to this, I will need to ignore Tracy’s advice, and add a new feature and corresponding rules: foes. Foes will add a usage to the toilet paper and a way to make some segments of the level easier or harder, according to the toilet paper the player has on him and is willing to spend. Explaining a little further:

To define the maximum height a princess can fall, I add a new acetate piece with a vertical line. That is the maximum height for the princess to fall without being hurt. More than that, she’ll lose a life. I know it is a little extreme if we think of it in the real world (if I fall from the second floor, it will be like nothing happened to me. If I fall from the second flood AND ten more centimeters, I’ll die), but for now, and for a matter of simplicity, let consider it like this. Also, I’ll only consider the vertical movement. This means that a player simply drops from a higher point in the level, or making a run and then letting herself drop (having horizontal movement) is absolutely the same in the maximum deadly height calculus. If a player runs to the border of a platform and jumps, then falling, the maximum height of the jump is considered to the calculus.

I add different usages of toilet paper to increase the types of challenges the user faces, to add choices on whether to use the paper to surpass the obstacle or save it for later, and to differentiate the types of obstacles where the player can use the rope, and where he can use toilet paper. The starting point to imagine these different obstacles was thinking of ways the princess would have to leave the lasso behind. Imagine she ties the lasso to some column, and use it do descend from a wall avoiding a dead drop. When she is finally on the ground, she will be unable to untie the lasso, and she must leave it there. These are the types of situations she’d have to spend some toilet paper. She could also use it to slide from one platform to other. And since I’m adding foes, I also added the ability to use the rope as a whip, and toilet paper as a “gun” (throwing toilet paper balls – don’t ask how does the princess gets them wet). To simulate both the “rappel movement” and the “vertical climb” I use vertical lines drawn in the acetate. The difference is that for the rappel, it has an associated “paper cost”, signed as a number. To represent “slides”, the same applies, only now it is a horizontal line. The “shooting lines” are horizontal lines, with the indication they are “shots”. Each costs 1 unit of paper. The Whip is also a “smaller” horizontal line, with no costs associated, of course.

Foes are “magnets”, like the player. However, they have a limited area of action. This means that in order to simulate this area, each foe as an associated acetate sheet placed in the level, below the foe. This sheet is separated in “walking segments”. These “walking segments” will be separating the “horizontal movement’s sheet” to the player. Now, for every “step” a player moves, the foes move one step in their referential. Using this we can make different “speeds” for the foes. For instance, faster foes can move two units for each unit the player moves. They can also move one unit every time the player moves two units (hence being slower than the player). Also, by using longer or shorter “walking segments”, we can simulate different speeds. Each foe as 2 associated numbers, representing the number of “paper shots” required to kill them, and the number of whips. While shot or whipped, the monster still moves. If the princess is touched by a monster, she loses one life. For now, we will only consider monsters moving in the horizontal referential.

That’s pretty much all about Structure.

 

 

 

 

Before going further into this tutorial, I sense it is becoming too big and too verbose. So to set you in the mood as I teach you more about the dark art of prototyping, I’ll wake you up with a joke and a photo of a naked chick. Ready? Scroll down!

 

 

 

 

 

 

“What do you call a princess-themed reality show?”

“Royal housewives!”

 

AH!

Back to the tutorial now!

 

After the Structure it’s time to add FORMAL DETAILS. Formal details add rules and procedures to make your prototype a fully functional game. At this point you should add the appropriate level of detail to make the objective interesting and achievable, the best possible player interaction and add the rules and procedures which you think are important, even if they are not part of the core mechanic.

While adding formal details, you must decide which of the ideas you have for the game should be included in the prototype for they are ”better”, and which ideas should be left aside. One good decider here is to focus on the rules affecting the central gameplay. Other is to get some input from playtesters. Ultimately, trust your creative judgment (AKA drink until you’re wasted, and pick “whatever”). Tracy states that one way to add formal details efficiently is to isolate each new rule and test it individually, and only leave it if you feel the game cannot function without the rule. If you feel the rule is not necessary to continue building your game, you should leave it out, no matter how amazing it seems. You always have the possibility to add it later.

To our game, at this point, I simply formalize the previous ideas in an outstanding table (and you know when there’s tables, sh*t’s about to get serious). Of course that for this tutorial’s sake, I didn’t bother anybody with playtesting, so this table is pretty much a result of my “creative choice”.

So as you can see, in this 14 rows I summed up the prototype up to this point. It is almost done. But prototyping is a fine art… so it is time for refinement.

REFINEMENT is the stage on which you take your – already playable – system and focus on making it compelling. This process can extent through several interactions. In this stage, you can also consider the inclusion of those ideas you left behind, because they weren’t essential, but you know are just “really cool” ideas.

During this stage, you should rank your ideas in terms of necessity, then introduce and test each one, accessing on how do they influence gameplay, and remove the idea. Doing this, you’ll see how ideas you thought were amazing actually diminish the playability, and how ideas which seem dull add a new dimension to the player experience. Only by testing the ideas individually you can access their influence in the game. Write analysis as you test the prototype, and access it with your playtesters. You may love a rule so much that you’re unable to evaluate it clearly. Trust your testers!

On this stage, I decided to leave the prototype “as is”. For now, I have two ideas “left behind”: power ups and booby-traps. For both of these ideas, I didn’t think enough on how to include them in the game (besides the regular “touch here and die, get power up and kill”). So for now, they’re staying out, and let’s tell ourselves the game is already perfect in its current state. If you don’t believe it the first time, keep repeating it to yourself until you start believing your own lies. You are now ready for politics! Thank me later!

 

Taking things a step further

We have a physical prototype emulating our game!  Now, after thousands of interactions, and playtesting (let’s imagine I did this), the prototype is playable and fun.  This would be the time to start all over again. There is always a way to improve your game, and turn a good game into a brilliant one.

Of course I will not do this, because I’m actually getting SIIIIIIICK of this tutorial, and want to start working on the next one. But you, the creator of the next big success, and future millionaire, should really turn your “self-criticism plug” on. Let your prototype rest for a couple of weeks, and play through it again. Is there something unclear? Is your game fun and enjoyable? Do you have any new outstanding idea? Don’t be afraid to try new things.

After you’re satisfied with your physical prototype, have a beer! Now, and probably for the first time ever, you’ve actually got a glimpse of what it means to be a game designer. But the fact is that we’re talking about video games, so we still have to include the “video thingy”. When switching from a physical prototype to a digital one, and although you maintain the core mechanics of the game, the way the player controls the princess will change (according to the device you’re prototyping your game), and you’ll have to design a visual display of the game environment for the aimed device.

 

Conclusion

By prototyping your game, you are creating a model of it, which allows you to try your ideas early in the development. Physical prototypes are the first prototypes created, for they allow you to focus on game mechanics, without becoming distracted by the production and programming process. During this stage you should not be afraid to try new features or rules. You should not be afraid of throwing some work away, or even start from the beginning. It’s better to do it now than latter in the process. What’s really important here is that by the end of the process you have a playable game, with its essential features, which is also enjoyable and fun. And equally important, now the development team has a clear understanding of what game will be made, saving a tremendous amount of time.

 

… DARY! LEGENDARY!