Viewpoints

 < Day Day Up > 



Now that you know how to prototype, playtest, and revise your prototype, it’s time to take a look at some of the underlying issues that you’ll face when building out your design for a digital platform. If you’ve begun with a physical prototype, you’ll need to translate that core gameplay to a digital format. The main tasks in doing that are envisioning your gameplay using the input and output devices of your digital platform. This means designing for control systems like keyboards, mice, proprietary controllers, etc. It also means visualizing your gameplay in the form of a digital interface.

This doesn’t mean starting from scratch—your physical prototype helped you to formalize and test the essence of your game, the essence of what you will be visualizing. The understanding of your game gained from this experience will breathe life into the designs for your controls and interface. It will inform the decisions you make and give you ideas you would otherwise have never thought of.

Controls

What are controls? And as a game designer, how do they impact your job? By controls, we mean whatever input hardware allows the user to affect the game. When videogames were first invented, they were limited in terms of controls. Steve Russell and several other students at MIT programmed Spacewar in 1962, often credited as the first digital game,[1] and in doing so, they found the toggle switches built into the front of their DEC PDP-1 to be too cumbersome, so they built their own special controller to go along with the game. Spacewar had only four controls: rotate left, rotate right, thrust, and fire.

Controls have come along way since the 60s. If we ask you to do a quick impression of a person playing a videogame today, chances are you’ll hold your hands out slightly, palms facing each other, and start twiddling your thumbs wildly. Your grandmother may not get the impression, but any teenager will.

Today’s controls include the keyboard, mouse, joystick, steering wheels, plastic guns, gloves with embedded sensors, virtual reality helmets, and more. You name it, someone has thought of it. Not all of these are practical, and most designers only consider a couple of controls when developing their games. The most popular controllers today are simply more elaborate variations on the same directional arrow/selection button design that marked the very first consoles.

click to expand
Figure 11.1: Spacewar on the DEC PDP-1 and custom controller

click to expand
Figure 11.2: Counterclockwise from top left, controls for: Atari 2600, NES, PlayStation 2 and Xbox

There have been a number of interesting forays by arcade companies into the development of radical new types of controllers, including motorcycles you can ride, cars you can drive, the footpad stage of Dance Dance Revolution, and the motion sensor frames of Mocap Boxing.

But unless you’re an arcade game designer, you’ll probably forgo the more inventive control systems in favor of the tried and true control pad (for console games) and the mouse/keyboard (for PC games). This is because every time you design for another controller, it costs the production time and money, and unless the optional controller is deemed a key selling feature of the game, it usually isn’t included in the schedule or budget.

The first thing you need to do when conceiving your game is make sure that you understand the standard controller for the platform you are designing to. This means knowing what your audience expects each button to do. These expectations are usually determined by previous games. Ifyou’re a rebel and go against the grain, you’ll only wind up confusing and frustrating your customers. It’s best to stick to normal behavior patterns instead of trying to foist some new scheme upon your users.

That said, this type of decision-making on the part of designers tends to mean that a lot of games will play exactly the same. How many games have you played that use the control button or the spacebar to fire a weapon? Why? Because that is how the designer of the last game did it. We challenge you to be creative and experiment. Don’t just fall in line with other games. But when you do venture out and try something different, make certain that the controls work intuitively. Test them on a variety of users, and if your playtesters agree that your design isn’t exasperating, maybe you’re onto something.

click to expand
Figure 11.3: Race cars, light guns, and motion capture boxing controls

The article by designer Eric Zimmerman of gameLab on page 312 describes how his team’s desire to create an interesting new control idea scheme led to the idea for their game Loop. In this case, they created a digital prototype of the core mechanic—the “looping” control—and tested that thoroughly to make sure it was intuitive and fun before progressing further with the idea.

Once you understand the input device, you need to think about how your game can best utilize it. You need to decide this in conjunction with your interface design, which we discuss next. Here is a good way to begin: look at the list of procedures for your physical prototype. These procedures need to be translated into a set of digital controls. For example, in our first-person shooter prototype, we had procedures for moving forward, back, turning left, right, etc. We also had procedures for firing weapons, changing weapons, etc. Each of these will need to be mapped to a control. If you have a highly detailed set of controls, you will probably wind up grouping them under a menu system or other visual device that can be accessed using a single control or set of controls.

Once you’ve decided how the controls will work, create a control table to make sure you’ve thought of everything. In one column, list the controls, and in next column, list the game procedure taken when that control is activated. If your game is complex, you may have to make several tables, each representing a specific game state. For the purposes of controls, a new game state exists each time the controls change.

For instance, if it’s a game where you can drive a car, fly a plane, or ride a bike, there will be three game states. In this case, the designer should try to keep the controls as similar as possible between the three states to avoid confusing the player.

Exercise 11.1: Original Game Controls

start example

Define a control scheme for your original game. For example, if your game is intended for a game console, such as the PS2, make sure to label every button on the controller. If a button has no function, then label it as “non-functional.”

Designing controls, like designing gameplay, is an iterative process. Your first attempt may not be as intuitive as you believed. The only way you’ll truly know if the controls work is to test them.

end example

Your goal should be to make the controls as effortless as possible. Gamers don’t want to think when they’re playing. They want the controls to feel intuitive. In this case, less is more. You’ll find that adding too many control options frustrates the average user. For expert players, these detailed controls may come in handy, as will custom control schemes, but it’s not worth scaring off novice players.

A wise designer will keep the controls limited to around seven inputs. Most people can’t handle more. You can have fifty or more advanced options, but a player should be able to get through the game only having memorized about seven actions. If you can do this, you’re designing a game that will appeal to the broadest possible audience.

click to expand
Figure 11.4: Simple control table

Exercise 11.2: Control Design

start example

The following exercise is given to prospective employees by game developer Pandemic Studios in Los Angeles. Pandemic requires applicants to complete exercises like this as a way of assessing their capabilities. As William Henry Stahl, the designer of this exercise, pointed out, there are no “correct” answers, and the exercise is just part of the evaluation process for applicants. Complete the exercise yourself.

end example

Control design exercise

As part of a team, you are creating a squad-based, tactical-action game for the PlayStation 2. Entitled Bravo Leader, the game places you in the role of a U.S. Army squad leader engaged in contemporary military operations all over the world. It is your responsibility to achieve mission objectives through the skillful deployment and use of four elite U.S. Army riflemen (including yourself).

After an initial series of meetings with the publisher, you have established some basics. The publisher would like to market the game toward an older (18–30), casual-gaming audience. The game should be played primarily from an over-the-shoulder perspective. It will be mostly exterior combat, placing the player in wartime combat situations right away (the publisher would like to steer away from stealth and infiltration objectives).

The core mechanic of the game is the ability to control a team of soldiers and their tactics in combat. The player must be able to issue orders to his team as a group or individually. The most important orders deal with managing the movement of the team so you’ve been asked to do a first-pass controls mockup that allows the player to do the following in the game:

  • Select a single soldier or the entire squad

  • Designate a location for that soldier or squad to move to

  • Issue a movement order to that soldier or squad

The exact type and number of movement orders the player can issue to his soldiers has yet to be finalized; however, it is safe to assume that there will be more than one. Some suggestions that came out of the design meeting are:

  • Check Position: Issuing this order causes the soldier or soldiers to approach the designated location cautiously and low to the ground. Should the soldiers encounter the enemy they will stop and engage.

  • Double-Time: Issuing this order causes the soldier or soldiers to run to the designation. The soldiers will disregard engaging an enemy until it reaches the designated location.

  • Patrol: Issuing this order causes the soldier or soldiers to casually walk to the designated location. Should the soldiers encounter the enemy they will engage but continue to move to the designated location.

Map out your controls for the “movement orders” feature described earlier using this diagram and control table. You can use as many or as few buttons as you like.

  • Main control table

  • Left thumb-stick

  • Right thumb-stick

  • Directional pad

  • Triangle button

  • Circle button

  • X button

  • Square button

  • L1 button

  • L2 button

  • R1 button

  • R2 button

  • Start button

  • Select button

Next, write out your design for the “movement orders” feature in detail. Describe how the system functions. Describe how it affects or utilizes othersystems—the camera or the HUD (heads-up display) for instance. Include examples of the controls in practice. Feel free to expand or reduce the feature in any way you like. Take as little or as much space as you need but be as thorough as you would be were this an actual design specification.

click to expand
Figure 11.5: Sony PlayStation 2 controls

  • Left thumb-stick

  • Right thumb-stick

  • Directional pad

  • Triangle button

  • Circle button

  • X button

  • Square button

  • L1 button

  • L2 button

  • R1 button

  • R2 button

  • Start button

  • Select button

Summary

The preceding example gives you a good idea of the type of thinking game companies are looking for when they hire someone. It also illustrates the importance of understanding controls in today’s videogame industry. It’s a good idea to play a wide variety of games and take notes on how each system uses the controls. Make sure to remark on schemes that work and ones that don’t. This will help you when it comes time to think through your own designs.

When people talk about the art of editing in films and television, they often call it an “invisible” art, commenting that if you noticed the editing while you were watching the film, it wasn’t done well. Designing controls for your game is like editing in this way. If players can sit down and start playing, without referring to a manual, your game is well-designed.

[1]William Higanbotham is also a contender for this honor. His two-player tennis game, built on a small analog computer and oscilloscope, was created in 1958 at the Brookhaven National Laboratory.



 < Day Day Up > 



Game Design Workshop. Designing, Prototyping, and Playtesting Games
Game Design Workshop: Designing, Prototyping, & Playtesting Games (Gama Network Series)
ISBN: 1578202221
EAN: 2147483647
Year: 2003
Pages: 162

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net