Prototyping Your Original Game Idea

---

Now that you have some experience creating and modifying prototypes, it’s time to take one of your game concepts and create your own original prototype. The first step is to pick one of the ideas that you brainstormed in the previous chapter. If you skipped Chapter 6, go back and read it now. Once your idea and concept treatment are done, you’ll be ready to make your first prototype. But before we dive into the mechanics of constructing the prototype, make sure you’ve clearly articulated the core gameplay that will be created.

A Good Mod Kit For First Time Level Designers: The Neverwinter Nights Aurora Toolset

by Trent Oster, Producer, BioWare, Inc.

The Neverwinter Nights Aurora Toolset extends a frontier in game development by encouraging and supporting the creation and sharing of user created content on a massive scale. Although the PC mod community has an amazing track record developing original new content from released game titles, much of this development work has historically been limited to “amateur” mod-makers with significant technical skills. When developing Neverwinter Nights, BioWare planned from the outset to create an environment that would open the mod community to the average player. Our vision was to enable a Neverwinter mod building community that numbered in the tens or hundreds of thousands.

Although the Neverwinter Aurora Toolset is designed to be accessible to the average person, it still supports all the detail required for professional game story creation. The toolset is based on a simple tile-painting area creation scheme, which allows for fast and easy implementation of environments and quick placement of creatures and items. A powerful and flexible scripting language allows the advanced user extensive control of adventure development while the scripting system supports sharing of custom scripts for the less technical user.

Bioware is a company of determined game players and creators. We often use ourselves as an image of our target market, and as such we create concepts that we believe will appeal to our fans and ourselves. The concept for Neverwinter Nights grew from a discussion comparing the relative strengths and weaknesses of massively multiplayer versus single-player games. Neverwinter Nights was created to blend the strengths of both formats while at the same time using the Internet itself as a model for distribution and content sharing. By empowering end users to create and host adventures we could create a game that spanned a large cross culture of gamers. In fact, looking at the current Neverwinter Nights community, you can easily spot a huge variety of gameplay themes and settings that were not commercially or critically feasible for us to develop. Through the sharing of the toolset, Neverwinter Nights has become more than one game; it has become a framework in which users can share varied game experiences.

We have been extremely pleased with the results to date—almost 3,000 community-developed modules are providing Neverwinter players a huge variety of adventures, allowing for diverse play styles and storylines that satisfy a range of player preferences. Using the tools, fans have created modules that include everything from the campy “Sex and the Single Sorceress” to a remake of the classic computer game, Ultima IV. This large and vibrant mod-making community has extended the lifespan of Neverwinter Nights and provided fans a broad range of rich content that could keep the experience fresh for years to come.

Author Bio

Trent Oster is a nine-year veteran of the videogame industry. Through that period he has worked as a development studio owner, an artist, a programmer, and finally a project director. After working on the titles Shattered Steel and Baldur’s Gate, he led the development of Neverwinter Nights from concept to completion. Trent is currently completing the second expansion pack to Neverwinter Nights, The Hordes of the Underdark.

Neverwinter Nights Aurora Toolset (game type: role-playing game)

Visualizing core gameplay

If you try to design the entire game at once, you may become confused and overwhelmed. There are so many elements in a typical game that it’s difficult to know where and how to start. What we recommend is that you isolate the core gameplay mechanism and build out from there.

The core gameplay mechanism can be defined as the one action a player repeats most often while striving to achieve the game’s overall goal. Games are repetitive by nature. While the meaning and consequences of what a player does may change over the course of game, the core action tends to remain the same from beginning to end. For instance, in chess, the core action is moving your pieces on a grid in an attempt to capture your opponent’s pieces. That single action defines the entire game. Once you understand that, the overall structure for chess becomes apparent. You can then start to play with other variables and redesign the game. For instance, should certain chess pieces have different attacks or defenses? What should be the size and shape of the grid? What if each piece was assigned health points and damage? How would that change the game?

Suddenly, it becomes clear how to grow the game. By starting from the center and working outwards, you can see the possibilities unfold. This not only works for boardgames like chess but also for videogames. Take the first-person shooter prototype that we created. The core gameplay mechanism was the ability for players to move about simultaneously while attempting to shoot one another with their weapons.

Here are some examples of popular games and their core gameplay mechanisms:

• WarCraft: Players build and move units on an overhead map in real time with the intent of engaging opposing units in combat and destroying them.

• Monopoly: Players roll two dice and move around a board with the goal of buying up properties and charging rent to anyone who lands on them.

• Diablo: In an attempt to amass treasure and become more powerful, a player moves his character about an overhead map, battling any monsters or enemies it comes into contact with.

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

As you can see, all of the previous descriptions are a single sentence. This is because the core game mechanism should be simple. If you can’t write up your gameplay in a single sentence, it means you have a problem. It’s extremely difficult to design a game that cannot be articulated concisely. Failure to isolate the core mechanics indicates that the game itself isn’t fully thought out or is overly complex.

Exercise 7.8: Understanding Core Gameplay

Define the core gameplay mechanism for five games not described in the previous section.

Now try to answer the following questions about your game. Your treatment from Chapter 6 on page 156 should give you a huge head start with this. If you get stuck on a question, however, just take your best guess. The answers to these questions are going to evolve as you prototype and revise your game, so don’t let them slow you down here at the beginning.

Building the physical prototype

Now let’s get our hands dirty. Here are four steps that will help you build a physical prototype efficiently.

1. Foundation

   Build a representation of your core gameplay. Get some arts and crafts materials such as cardboard, construction paper, glue, pens, and scissors. Draw a board layout or rough map if you want and cut pieces out of the cardboard and paper.

   As you do this, questions will come to your mind. How many squares should a player be allowed to move? How will the players interact with one another? How is the conflict resolved? Do not try to answer all these questions as once. In fact, place the questions on the backburner and focus on the core gameplay.

   Designing the basic game objects (physical setting, units, resources, etc.) and the key procedures for the game (those repetitive action cycles that keep the game in motion) are the heart of the foundation stage.

   Try playing your core mechanic on your own—it may not be much of a game, but you will be able to see if the basic concept is worth pursuing. Once you have your foundation in place, the system takes over and begins to ask you questionsyou’ll want to answer. But watch out. Try to test the game without expanding the rules at this point. If you have to add a rule to make the mechanic playable, then add it, but only do this if it’s absolutely necessary. Your goal should be to keep the core gameplay mechanism down to as few rules as possible.

   
   Figure 7.13: Physical prototype examples

   In the FPS prototype, the first element that we fleshed out was simultaneous movement, because this is the core mechanic of the game. The idea that all players should reveal an action card at the same time to simulate real-time movement was conceived. This was a foothold to build upon. From there, the next logical question was: what are options on the action cards? The answer was: move, turn, or shoot. Other ideas for action cards popped up as well, such as: stand, crouch, go prone, etc. However, we decided to keep the options as simple as possible at first. These lead us to the next stage of our prototype: structure.

2. Structure

   Once the foundation is in place and seems to function, it’s time to move on to structure. The best technique for doing this is to prioritize what is most essential to the game. In our FPS prototype, some structural elements we added were our three action options—(1) number of spaces a unit could move, (2) procedures for turning, and (3) hit and miss rules for shooting. Our army men were moved and turned on the table, as mock units using the rules.

   These experiments solidified some ideas about moving and shooting and caused other ideas to be dismissed, which resulted in a very crude system for simultaneous movement and the basics of shooting. We also considered adding rules about movement and starting points, as well as assigning a turn order to the players.

   Think of it this way: you’ve built the foundation, and now you need to build the framework for your game. It’s not a matter of what you think is coolest or most saleable; it’s about constructing a skeletal structure that can support the rich and varied feature set that will be your finished game. What you need to do first is decide which rules are essential and which are features that those structural elements have to support.

   List every idea you have in your head on a piece of paper, and then rank each one according to what you deem its overall value to the game. If you’ve ranked them according to their true value in making the game function, the ones at the top should be your essential elements, while the ones at the bottom are your peripheral features.

   Now, methodically work down the list. At this point when we were building the FPS prototype, the movement and shooting foundation begged for the structure of a scoring system and unit hit points. As we added these elements, our crude movement and shooting system was re-tested with them in place. The tests illuminated problems that could only be seen with the system in motion. The whole system was revised to address the problems. At this point the system was still messy and ill-defined. Nothing had been written down. There were open questions everywhere. However, the system was basically functional.

   When working through this, keep in mind the distinction between what are features and what are rules. Features are attributes that make a game richer, like adding more weapons or new vehicles or a nifty way to navigate the space. Rules are modifications to the game mechanics that change how the game functions, such as winning conditions, conflict resolution, turn order, etc.

   You can add rules without adding features, but you can never add a feature without changing or adding rules. For example, if you added a new type of laser gun to your game, the rules would dictate how this gun could be used, what damage it would do, and how it relates to all aspects of the game. One new feature may introduce ten or more new rules to support it. As you modify your game, you’ll be constantly tweaking the rules to enhance gameplay and accommodate a growing feature set.

   Your best strategy for adding structure is to focus on rules first and features later. Rules, by their very nature, tend to be inextricably linked to the core gameplay, while features tend to be peripheral. That’s a generalization, but if you keep it in mind, it will help you to structure the development of your game.

3. Formal details

   The next step is to add the necessary rules and procedures to the system to make it into a fully functional game. Focus on what you know about formal elements to decide what your game needs. Is the objective interesting and achievable? Is the player interaction structure the best choice? Are there rules or procedures that you wanted to add, but they weren’t part of the core mechanic? The trick is to find an appropriate level of detail to add. Beginning game designers typically add too much. The art of game design often involves paring a bunch of feature ideas down to a small, important set.

   At this point in the development of the FPS prototype, we added the hit percentage, health, and scoring. Many other ideas were discussed including: mines, shields, vehicles, mechanisms for hiding, and more. However, we scrapped all of them and focused on rules affecting the central gameplay, rather than a set of new features that we believed would create the most interesting game. How did we decide on some elements and not others? It was a creative judgment, backed by input from our playtesters.

   
   Figure 7.14: Physical prototype with procedures outlined

   One way to add formal details efficiently is to isolate each new rule and test it individually. If you feel the game cannot function without this rule, then leave it in the game and add another rule. But don’t overuse this privilege. Not every rule is critical, and the less you add, the cleaner your skeleton. A lot of what you consider to be rules are probably features. Try to draw a clear distinction, and keep your core rule set as clean as possible.

   Test each rule, then remove it, and add another rule, and test it. It will be clear that some of the rules are optional and others must be included in the game if you are to continue to expand the gameplay. This is a litmus test. If you can continue to build out the game without a specific rule, no matter how amazing that rule seems, you should leave it out. You can always add it later, but itshouldn’t be included at this early stage.

4. Refinement

   At this point in the process, the prototype is a playable system, although it may still be somewhat rough. By experimenting and tweaking, the play system will become more refined. The play experience created by the game will flow. Instead of questioning the fundamentals of the game (and possibly thinking it will never work), you will switch to questioning the smaller details, and of course, the big question: is your game fun? If not, what will make it fun? This process of refinement may continue for a number of iterations.

   During refinement is also the time to add all those great ideas for features that have come up while testing but were not really essential. We went back to those ideas about mines and teleport pads for our FPS at this point. Again, be careful not to get ahead of yourself. It’s tempting to slap on five new features, create a bunch of rules to support those features, and then start playing, but this blurs your view of the game. It becomes difficult to tell which features are making the game more fun to play and which are causing problems.

   To avoid this, rank the features in terms of necessity. Then introduce and test each one. Test how it affects overall gameplay, and then remove it. This may seem cumbersome, but it will keep your game structure from getting convoluted. If you muck up your game with a bunch of features and rules too early, you’ll find yourself losing your grasp on what the game is about. We’ve seen this happen over and over again, and this is why we caution all designers to postpone the pleasure of creating the ideal game from the outset, and instead recommend that they focus on what’s needed step by step.

   As you do this, you’ll discover that some rules and features that seemed like great ideas actually diminish the playability, while others that appeared dull add a whole new dimension to the game. You can only know this by testing each one in a controlled environment without the interference of other features. After testing each new twist, write down an analysis. Be sure to use you playtesters and incorporate their feedback into your analysis. They are your eyes and ears. You may love a rule or feature so much that you’re blind to its flaws. Trust your testers.

Exercise 7.9: Prototype Your Own Game

Use what you’ve learned to create a paper prototype of the game idea you described in Exercise 6.9 on page 156. This is a hard task. Break it down into the iterative steps described on pages 174–178 (i.e., Foundation, Structure, Formal Details, Refinement). If you get stuck on a step, just take your best guess and move on. With prototyping you always have room to iterate.

---