The Binding of Isaac

Super Meat Boy

Gish

- Jon Jones
Founder, GamePitches.com

Here is yet another really cool online resource we're happy to feature by reposting one of their more popular design pitch documents here on GameDev.net for everyone to check out. There's plenty more over on GamePitches.com and new ones are being added constantly. It used to be that design documents were the popular thing to post online for budding developers to read through and see how a professional game was organized on paper, but once you get the hang of that how to you seek out financing from a publisher to produce your game? Now you can see how well-known studios have convinced people to give them money to make their now well-known games. Learn by example with this great resource!

- Drew Sikora
Executive Producer, GameDev.net

Irrational Games - Bioshock Pitch Document

• Strategy: A plan of action intended to accomplish a specific goal. An elaborate and systematic plan of action. Synonyms include "plan" and "scheme".
• Tactics: A procedure or set of maneuvers engaged in to achieve an end, an aim, or a goal. An expedient for achieving a goal; a maneuver.

• Long-range goals (besides simply winning). All games are meant to be won. That is what makes them "games", per se. For strategy games, long-range objectives should be required in order to win. Things like "capture the queen" or "fortify my current position". These goals are a level higher than manipulating specific game units or variables, but do not represent the entire game itself (winning).
• Forethought to achieve those goals. Based on our description above, the classic strategy game Chess appears to be more of a game of tactics. Each move is critical, Each piece is valued. And yet, it is widely recognized as a game of strategy. Good Chess players are not playing individual pieces however. They are playing an overall position on the board and think several moves ahead in order to gain an advantage. Playing each move at face value is the mark of a novice player. Therefore, strategy games emphasize forethought.
• Minimizing the impact of specific actions when compared to the overall strategy. Strategy should win a strategy game, not tactics. While a game may include giving orders or moving game units specifically, the game as a whole should not emphasize any particular action. Making a good or bad "move" should not automatically determine whether or not you have won or lost the game. Some games in particular make the player feel they must restart if they don't get a good "starting position". This could indicate a design flaw (or a player obsession).
• Relative unimportance of individual units or functions as they relate to the whole. The impact of losing a game unit or a conflict is lessened in a strategy game. This is not to say that some key units, battles, or tactics are unimportant. However, in the larger scheme of things these specifics should not win or lose the entire game. For instance, again in Chess, the Queen is a very important piece. But losing the Queen does not mean the game is lost or that that player is doomed. In fact, loss of this "unit" may even be part of the strategy.

• Negative Feedback - Negative feedback is when a game gives a special rule to help players that are losing or to punish players for getting too far in the lead. It keeps the game more balanced towards neutral where nobody wins or loses by too much. Negative feedback slows down the game pace. This can make the game feel more lively since it may not be clear who will win until the end. Many board games have a social kind of negative feedback loop wherein players may attack or refuse to deal with another player who is clearly in the lead or about to win, slowing the leader's progress.
  
• Positive Feedback - Positive feedback is when a game rewards winners or punishes losers. Examples are when the game makes it easy for a losing player to get further taken advantage of, or if it gives increased leverage to a player who is already clearly winning. Positive feedback makes the game grow exponentially or even spiral out of control. Use positive feedback mechanisms to quicken the game pace. Basic Monopoly gameplay is an example of a positive feedback; more hotels and houses makes you more money which allows you to buy even more hotels and houses...

• Inclusive Play - Inclusive play requires that all players remain in the game until it ends. Inclusive play is usually a good choice for strategy games with multiple human players. This is simply to keep everyone involved in the game. With single-player computer games, keeping other players happy isn't an issue.
• Exclusive Play - Individual players drop out of the game ("lose") individually until only a winner or winners are left remaining. Virtually all 4X-style computer games have exclusive play.
• Cooperative Play - Players can cooperate with each other in a variety of ways:
  • Against the computer - Players cooperate against AI opponents or a specific "boss" opponent.
  • In a team - Players arranged in teams may compete against other teams but cooperate with each other. Team play can also take the form of permanent or temporary alliances.
  • Against the clock - Players race the clock to complete a victory condition for all players before time expires. This is usually an "everybody wins" type of game.
  • With a common goal - Players cooperate to achieve a common goal or solve a common puzzle. This is usually an "everybody wins" type of game as well.
• Competitive Play - Players can compete directly with each other or can be arranged in teams. Players can also compete with AI opponents in computer games. Competitive play can be temporary or permanent (using alliances or game-required temporary cooperative play)

• Elimination - Win by eliminating, destroying, moving, or removing opponents, obstacles, targets, or non-playing characters. Elimination can require a player to remove everything or a specific percentage or number of things.
• Acquisition - Win by acquiring something or a certain level of something: money, resources, cards, tokens, opponents, or items on map. Victory by acquisition could also be called victory by conquest.
• Points - Victory by high score is a lot like victory by acquisition, but so much greater because "points" are an abstract representation of value. Points can be awarded for anything. Additionally, different amounts of points can be awarded to players for different things. Players are then assessed by their overall skill level in the game and not by any specific skill. This encourages mastery of all the game's elements. Points are so flexible that you can even subtract or multiply points if so needed. Points can also be adjusted if the game is unbalanced.
• Physical Goal - Win by getting to a location or several locations. This victory requires a game space to play in; Not all games have a game space. This victory could also be a victory by travel, discovery, or exploration. RoboSport (by Maxis) had a clever game mode called "baseball" where the player had to move units to four corners of a map to win.
• Abstinence - Win by not doing something or by doing something efficiently. You might consider not losing something the player already has, going "out of balance", going out of bounds, losing resources, spending resources, or trying not to receive points. Victory by abstinence can also be victory by efficiency (like golf).
• Riddance - Win by getting rid of something. Players may start with an item or items that need to be played out of the hand (like a card game), placed on a map, spent (like money), traded away, or destroyed. Victory by riddance provides the intriguing concept of giving opponents something they don't want as a hindrance (as opposed to not giving them something they do want) and of "going out" to win.
• Spacial Dominance - Win by possessing or controlling an amount of physical area on a map. You will need to decide what constitutes "controlling." Victory can be attained by total domination, however a shorter and less player-exclusive game can be played by making the goal be a certain percentage of space or number of areas instead.
• Key Target - Win by removing, destroying, creating, acquiring, or converting a key target or targets. Chess is won by capturing the King, not by capturing other pieces (this minor detail escapes many beginners). Key targets can be per-game (one target for all players), per-player (each player has a different target), or inter-player (each player has a target to defend against the others, e.g. "capture the flag").
• Diplomacy - Win by social means. This can include winning by default (lack of other players), resignation of opponents, or a declaration of a draw or tie. Players could also vote for a winner (such as in Master of Orion), or periodically vote for a loser (think Survivor). There may also be multiple winners where a person wins by being allied with a winner (or loses by being allied with a loser).
• Time - Rarely used in strategy games, but listed here regardless. Victory is given to the player who deals with a scenario in the fastest time.
• Combinations - Win by completing multiple simultaneous victory conditions. This is not a victory condition, per se, but interesting to explore. Consider Physical Goal + Riddance. This requires the players to get everything out of something or away from something. Or consider Points + Abstinence, possibly requiring the player to win with the most points in the least moves (or while using the least resources, losing the least number of units, etc).
• Variable - Win by completing one of several different victory conditions. This allows multiple paths to victory which allows for a wider style of play.

• Elimination - End the game by removing all players or competitive forces from the game. This could also be called "last man standing".
• Acquisition - The game ends when a specific number or percentage of items or resources have been collected.
• Points - End the game by scoring a number of points. This requires that score be actively kept during play as opposed to scoring after the game's end. A scoring end condition can be further restricted by only permitting a specific score to end the game with no overage or underage allowed.
• Physical Goal - The game ends when one or more players reach a specific physical goal (like a race) or after all players have reached the goal.
• Riddance - End the game by getting rid of something.
• Spacial Endings - The game ends when all space or a specific portion of space is used up, controlled, or owned, either by players in general or by a specific player. For example, play may end and the game won by a player controlling 50% of the available area; or the game may end (but victory not determined) when 100% of the available area is controlled by all players in general or when no more moves can be played in it.
• Key Target - The game ends when a specific target (or targets) is captured, destroyed, or collected.
• Diplomacy - Players decide when the game is over. This can be a popular vote for a winner, a resignation, or a decision to draw or tie.

• Combinations ("And" Endings) - The game ends when two or more ending conditions are met. For example: a Canasta hand is over when a player has both the necessary number of plays made and gets rid of all their cards. This player may not end the game if the required plays have not been made.
• Variable ("Or" Endings) - Allow any number of multiple conditions to end the game. Variable end conditions usually go with variable victory conditions.
• Exhaustion - End the game by exhausting an available resource. This could be a stack of cards, money, game tokens, collectible items, etc.. The game can end with the exhaustion of a specific resource or all resources combined.
• Inability to Play - The game can end either when one or all players cannot make a legal play. Some games end after a player cannot play and all other players get "one last turn."
• Time - The game ends when a time limit expires. Time limits are not related to a time victory condition, which is more like a race.
• Random - What ends the game is randomly determined before the game starts. This forces more variety in play style.

The first, of course, is that some people, especially many video gamers, prefer interactive puzzle “games” that have no human/psychological component, while other people strongly prefer games involving two or more people in opposition. In fact, “multiplayer” in the tabletop game hobby doesn’t mean “more than one player”, it means “more than two, and more than two sides”. A two-player game provides some human/psychological interaction, but it’s the more-than-two-sided games where the human element, not the puzzle-like challenges set by the video game designer, becomes paramount.

Classical and Romantic

The Classical player tries to know each game inside-out. He wants to learn the best counter to every move his opponent(s) might make. He takes nothing for granted, paying attention to little details which probably won’t matter but which in certain cases could be important. The Classical player does not avoid taking chances, but he carefully calculates the consequences of his risks. He dislikes unnecessary risks. He prefers a slow but steady certain win to a quick but only probable win. He tries not to be overcautious, however, for fear of becoming predictable. A cliche among football fans is that the best teams win by making fewer mistakes, letting the other team beat itself. So it is with the Classical gamer, who concentrates on eliminating errors rather than on discovering brilliant coups.

The idea of managing risk doesn’t lend itself to single-player video games that have just one solution. In some of these games that involve no chance element (everything is set by the designer), something like game theory calculations of the “perfect strategy” don’t come into play. There is what is called a “saddle point” or dominant strategy, a perfect way to play that will win every time. If you make the right moves in, say, arcade Pac-Man, you will go all the way through all 255 levels every time without a single death, because there is no random element. (See Inside Pac-Man.) On the other hand, if the single-player game includes randomness that changes with each play, the player must manage risk, and the game becomes quite Classical. In general, single-player games are going to tend toward the Classical unless the “opposition” approaches a human in complexity.

The Romantic looks for the decisive blow which will cripple his enemy, psychologically if not physically on the playing arena. He wishes to convince his opponent(s) of the inevitability of their defeat; in some cases a player with a still tenable position will resign the game to his Romantic opponent when he has been beaten psychologically. The Romantic is willing to take a dangerous risk in order to disrupt enemy plans and throw the game into a line of play his opponent is unfamiliar with. He looks for opportunities for a big gain, rather than to maximize his minimum gain. A flamboyant, but only probable, win is his goal. He may make mistakes, but he hopes to seize victory rather than wait for the enemy to make mistakes. The Romantic is more likely to try to “get into the head” of his opponent, to divine which strategy the opponent will use and play his own strategy that best counteracts it.

In the standard single player interactive puzzle video game, there is no human opponent to “psyche out” or to fool. Yet some of the more sophisticated modern games are designed to provide a “computer opponent” that behaves in some ways like a human, and clever players figure out ways to take advantage of the programming to “fool” the opponent. When playing a multi-sided game such as Civilization or Warcraft III against several computer opponents you can find ways to “make the opposition look foolish”: in fact, this may be easier than when playing against good human opponents. A political victory in Civilization, in effect persuading the computer players to give up, can be seen as a Romantic goal. Further, real-time games tend toward the Romantic simply because there isn’t time for the Classical player to make careful calculations. Under great time-stress some people will still try to play Classically, it will simply be harder for them to do so effectively.

In the single-player video game with no chance element, the Romantic very likely has no opportunity to “take the path less trodden” in order to fool the computer.

Here’s a simple comparison of these two types of players. The Classical player, in Tic-Tac-Toe, will always play to the center square when playing second if his opponent doesn’t take it—and will always take the center if he moves first. The Romantic may try to fool his opponent into playing badly by making a less-than-optimal play, in order to try for a win rather than accept the otherwise-inevitable draw.

To further generalize, playing against the computer tends to encourage the Classical, playing against people tends to encourage the Romantic. However, when the stress of limited time is introduced, it becomes difficult or impossible to play Classically as you have less and less time to calculate risks.

Many good players depend on intuition rather than study and logic to make good moves, yet the moves can be either Classical or Romantic. A Romantic player can also be a very cerebral or intellectual player who happens to prefer the Romantic style. Nonetheless, the Classical player tends to use logic while the Romantic tends to use intuition. Some people would refer to Classical players with derision as “mathematical” players. It is true that Classical players are concerned with odds and expected losses and saddle points (though this alone doesn’t identify or qualify a person as a Classical player). Nonetheless, Classical players do quite well in non-mathematical games.

Games sometimes tend to favor one playing style over the other. Chess is clearly a Classical game. Single-player video games are often Classical. Poker tends to favor Romantic play, because so much depends on bluffing. Most shooters (the frenetic kind) are Romantic, while stealth shooters tend to be Classical, as far as you can categorize single-player games. A game like two player Street Fighter can be played either way. It seems that the very best players, though, play Street Fighter Romantically, somehow reading their opponent’s intentions and beating them to the punch, the ultimate in playing the opponent rather than playing the game. For more about this see David Sirlin’s book, Playing to Win: Becoming the Champion (http://www.lulu.com/content/205476) (http://www.sirlin.net/ptw/).

Diplomacy, though without any overt chance factor, is a good game for both Classical and Romantic players. The negotiations and alliance structures give both types plenty to work with. The Classical player tends to be better at tactics and strategy; he prefers long alliances to continuous free-for-all, for there are too many risks and incalculable factors inherent in a fluid situation. The Romantic tends to prefer the fluid state, and his big weapon is the backstab.

It’s hard to say whether an extreme form of Classical play, in a typical one-player video game, would involve rare resort to reloading a saved game, or would involve frequent saves and attempts at all kinds of different tactics to find out which one is best. I tend to be a Classical player, and I prefer the former, but I’m not going to make the mistake of assuming I’m typical!

While “Minimaxers” are usually Classical players, I have known gamers who apply minimax methods to characters or unit mixes, to more or less tactical concerns, but play the overall game Romantically. “Yomi” is David Sirlin’s term for reading the opponent’s mind; the best Romantic players probably have “Yomi”, but this is not necessarily so, and it’s possible that a Classical player may be able to read opposing intentions but still relies on attaining the minimum maximum gain.

Nonetheless, you’d expect most Classical players to be mimimaxers, and most Romantic players to rely on Yomi.

Reaction to Chaos and Randomness

• the “Planner”,
• the “Adapter” (who tends to represent the middle ground) and
• the “Improviser”

The “Improviser” does not like to plan ahead. He wants to react to circumstances at the time he makes his play, and he doesn’t mind at all if circumstances change drastically between one play and the next, or in a short time (in a real-time game). Games with limited information availability aren’t going to bother him, while games with perfect information aren’t likely to be attractive. Such players tend to be Romantic, obviously.

The “Adapter” likes to impose order on chaos, he wants to be able to see ahead a couple moves (or a short while in real-time) and then adapt to them, that is, arrange to “take control” of what’s going on. As you can see, this falls somewhere between the other two.

Once again, some games favor one of the three styles or another. Team video games, if the team actually tries to plan and work together, can be for Adapters. Real-time strategy games may attract Adapters, who can plan ahead some, having gained some information about what’s going on. Two multi-sided boardgames that fit the “Adapter” mindset are Vinci and RoboRally. Vinci is a game with perfect information, and with little overt chance, yet you can’t plan far ahead because the rise and fall of empires and selection of new empire capabilities results in great changes on the Europe-like board in a few turns. RoboRally requires players to program movements of their Robot in a violent race through several checkpoints in a bizarrely-dangerous factory. Each player is dealt nine movement cards, and must lay five face down to be executed in order one at a time. You can plan a route, but you won’t always get the cards you need. Chaos sometimes results from player mistakes, yours and mistakes of others.

Civilization (board or video) tends to be a game for the Planner. Card games tend to be for the Improvisers, though some can favor the Adapter. Poker is a game for Improvisers, except that there can be long-term bluffing plans that are characteristic of a Planner.

Diplomacy could attract Planners, Adapters, or Improvisers, depending on how it’s played.

In Tetris, if you’re just reacting to each shape as it appears, you’re playing as an Improvisor; if you’re trying to calculate which shapes will go well, so that you’ll know where to put one when it shows up, you’re playing more as an Adaptor. Because of the time stress and uncertainty about what will appear soon, it’s hard to play Tetris as a Planner.

Because arcade Pac-Man is ultimately predictable, a Planner may have been the first to notice the patterns and find ways to take advantage of them. Insofar as video games tend to conceal a lot of information, they’re not fruitful ground for a Planner, rather encouraging Improvisation.

Platformers reward short-range planning of the kind common amongst Adaptors. Some RTS games (the ones that are short on time-stress and long on strategy) are good for Adaptors. Survival Horror games with limited ammunition available are good for Adaptors. But something like Left4Dead, with practically unlimited ammo and a Director that increases the challenge as necessary, fits an Improviser point of view.

Depending on circumstances, a Planner or Adaptor should be a good leader in a team deathmatch or capture the flag using maps that are well-known.

Race games can favor any type depending on how much information is known to players when the race begins.

Role of Chance

If there are few dice rolls or equivalent, and some are very important while many are not, then chance is very hard to manage. Randomness is largely unmanageable chance. The Planner doesn’t like randomness, while the Improvisor won’t mind at all. Adapters like some fluidity as a result of what other players do, but don’t much like randomness. Classical players tend to hate randomness, while Romantics may welcome it.

In general, games that provide difficulty by requiring quick reactions tend to favor the Improvisor style and make Planning difficult. You don’t have time to plan a lot in Halo or Combat Arms; you can in the “stealth” shooters such as many Red Storm games like Rainbow Six. Real-time games tend to be better for Improvisors, turn-based games for Planners. Games with most information hidden from the players make Improvising much easier than Planning, hence the AAA video games that usually use “fog of war” (hidden information, even the map is hidden to begin with) tend to be games for Improvisors more than Planners.

In other words, “traditional” one-player video games tend to favor the Improvisor rather than the Planner. But this will gradually change over time: as the market for video games continues to expand, many new players will dislike being time-challenged, they’ll want to relax while they play their games, they’ll want to play a little bit (one turn) at a time. The trend is already obvious in casual games.

These are only three spectra of game-playing styles, out of many. For example, I know someone whose main pleasure in playing games is in helping someone else win! I suspect this is such a tiny minority view that designers need not worry about it—though cooperative games have become quite popular this year--but it helps illustrate how many different “favorite ways to play” exist among game players.

(Parts of this were originally published in Dragon magazine, September 1982, and in revised form in The Games Journal, February 2005, and revised again on GameCareerGuide, 26 November 2009. This represents the latest revision)

Kismet: The Big Picture

FIGURE 9.1 This simple Kismet sequence would teleport a player when he comes in contact with the trigger.

The sequence shown in Figure 9.1 could be written out in English as follows:

Kismet is the backbone of level interactivity, as it provides a way for artists (the non-programming type, that is) to create complicated scripts to power the levels that they have designed. The purpose of this chapter is to get you quickly in tune with how Kismet works, and enable you to create a series of gameplay-based sequences. As we progress, the tutorials you complete become more and more complex, enabling you to see how to create sequences ranging from extremely simple to moderately elaborate.

Accessing Kismet

Kismet is most directly accessed by clicking the Open Kismet button located in the middle of the toolbar. You will also be able to access Kismet from within the UI Editor system, which we do not cover in this introductory text.

FIGURE 9.2 The Kismet interface

Okay, you know generally what it is, where to find it, and a bit of what it looks like, so let’s get our hands dirty and create an actual Kismet sequence! In TUTORIAL 9.1, you create a simple light switch using Kismet.

TUTORIAL 9.1: Triggering Lights with Kismet

Step One

Step Two

Immediately open the Properties window for this new actor (by double-clicking it or pressing F4). Within the Display category, set the bHidden property to False by un-checking its checkbox. This enables us to see the trigger while play testing the level (see FIGURE 9.4).

Step Three

1. From the Unreal Editor main menubar, choose View > Browser Windows > Actor Classes.
2. From within the Actor Classes browser, expand Light > Point Light and select PointLightToggleable (see FIGURE 9.5).

3. 
   FIGURE 9.5 The pertinent classes have been expanded to show the PointLightToggleable actor.

4. In the Perspective viewport, right-click on the opposite corner of your level away from the trigger, and choose Add PointLightToggleable Here.
5. Use the Translation Widget to move the light up from the floor of the level (see FIGURE 9.6).
6. Open the Properties window for the light, and under the Light category, expand LightComponent and uncheck the bEnabled property. This causes the light to be switched off when the level starts.

FIGURE 9.6 Place the light above the opposite corner from the trigger.

Step Four

Step Five

Step Six

Step Seven

1. In the Perspective viewport, select the PointLightToggleable created earlier.
2. Back in the Kismet window, right-click in a blank area of the Sequence Window beneath the Toggle object and choose New Object Var Using PointLightToggleable_1. This creates a variable that is tied directly to the PointLightToggleable actor in your level (see FIGURE 9.9).

3. 
   FIGURE 9.9 You now have a new object variable that designates the PointLightToggleable actor.

4. On the Toggle object, you see a small pink input box underneath the word “Target.” Drag a wire from that input and connect it to the PointLightToggleable_1 variable. The Toggle object is now connected to the light, and is able to turn it on and off (see FIGURE 9.10).

Step Eight

Drag a wire from the Touch output of the Touch object, and connect it to the Turn On input on the Toggle object (see FIGURE 9.11).

Step Nine

Try out your new trigger by testing the level. You may click the Play In Editor button located on the right side of the toolbar (we’ve already placed a PlayerStart for you), or right-click on the floor and choose Play From Here.

Your level begins with very dim lighting. When you run your character into the trigger, the light switches on. However, at this time, the light only turns on once and remains on indefinitely. Later, in TUTORIAL 9.2, we change the Touch event so that it can be fired multiple times, as well as reprogram the sequence to turn off the light when we are no longer in contact with the trigger. We also take a look at triggering sound effects when our trigger is touched and “un-touched.”

Anatomy of a Sequence Object

Sequence objects can also have many outputs along their right side as well. Such sequence objects typically handle different sets of sequences, and the multiple outputs enable you to choose which sequence is fired. For example, a Condition sequence object can compare two values, and use one output if Value A is greater than Value B, or another output if Value B is greater than A (see FIGURE 9.13).

Along the bottom of a sequence object, you can also find a series of inputs and outputs.However, the inputs and outputs found along the bottom of a sequence object allow for interaction with variables, not with other sequence objects. These inputs and outputs can be differentiated from one another by the shape of the connector. An input always has a square-shaped connector, whereas an output has a triangular shape (see FIGURE 9.14).

Types of Sequence Objects

Events

Actions

Variables

Variables can also be written to in a sequence. By using the outputs found along the bottom of an action or event, you can store a given value in a variable for use later.Variables are color-coded as to what types of data they can store (see FIGURE 9.17). The color-coding is as follows:

• Boolean values: Red
• Integers: Cyan
• Floats: Blue
• Objects: Pink
• Strings: Green
• Vectors: Yellow
• Union (typeless): White

Conditions

Matinee

Kismet Sequence Flow

The most important aspect to understand about Kismet sequence flow is that all actions must be “fired” by something, usually by an event. An action sitting by itself is never activated, and therefore never affect the level. This demonstrates the vital importance of the In and Out connections on the left and right side of actions and events.

As a fun little analogy, you can think actions as explosives, events as detonators, and the lines connecting them as the wiring between the two. By itself, an action, or explosive, does nothing. When you wire it to an event, or detonator, you get an interesting effect.When you wire a detonator to a series of explosives that in turn ignite other detonators and explosives, you get a glorious effect that can truly bring the house down (see FIGURE 9.19)!

In TUTORIAL 9.2, we see how we can supplement our original sequence we created in TUTORIAL 9.1 by simultaneously playing a sound when we toggle the light on and off.

TUTORIAL 9.2: Repeated Triggers and Firing Simultaneous Actions; Playing Sounds While Toggling Lights

Step One

Step Two

1. Click the Open Kismet button to open the Kismet Editor.
2. Select the Touch event. In the Properties window of the Kismet Editor, set the MaxTriggerCount property to 0 (you may have to scroll the properties area down to see it). This effectively removes the maximum number of times the event can be fired (see FIGURE 9.20).

3. 
   FIGURE 9.20 Here you can see the Properties window of the Kismet Editor. Notice that the MaxTriggerCount for the Trigger object has been set to 0.

4. Drag a wire from the UnTouched output of the Touch event to the Turn Off input on the Toggle object. This means that when our player is no longer in contact with the trigger, the light automatically switches off (see FIGURE 9.21).

Step Three

Step Four

Step Five

1. In the Kismet Editor, right-click on a blank area of the sequence window directly above the Toggle object. In the Context menu, choose New Action > Sound > Play Sound. This creates a new Play Sound sequence object (see FIGURE 9.23)

2. 
   FIGURE 9.23 Place this first Play Sound object just above the Toggle object.

3. Go to the Generic browser, and within the Chapter_09_KismetContent.upk package, expand the SoundCues group. Select the scue_lightOn sound cue object.
4. Back in the Kismet Editor, select the top Play Sound object. In the Properties window of the Kismet Editor, click on the Play Sound property and then click the Use Current Selection in Browser button. This should place the scue_lightOn sound cue into the property. NOTE: When playing sounds using Kismet, you can only use SoundCue objects—not WAV files.
5. Drag a wire from the Play input of the upper Play Sound object to the Touched output of the Touch event. The lightOn sound now plays when we touch the trigger. Note that we did the wiring backwards this time (see FIGURE 9.24).

6. 
   FIGURE 9.24 The Play Sound object has been wired into the Touch object.

7. Using the same process described previously, create a new Play Sound object, placed below the Toggle object. Connect the scue_lightOff sound cue to this Play Sound object, and connect its Play input to the UnTouched output of the Touch event. This causes the lightOff sound to play when we break contact with the trigger (see FIGURE 9.25).

Step Six

Conclusion

We start by showing how you can change a material parameter during gameplay through the use of Material Instances. Although this example is fairly simple, you can use it in conjunction with what you learned in the chapters over materials to control a variety of different material effects. For more information on materials, please see Chapter 6, “Introduction to Materials.”

In TUTORIAL 9.3, we show how to use Kismet to affect materials in your levels during gameplay.

TUTORIAL 9.3: Using Kismet with Simple Material Instances

Step One

Step Two

Step Three

Set the MaxTriggerCount property for this event to 0. Then, uncheck bAimToInteract. This keeps players from having to look directly at the trigger when it is used, enabling them to watch the sphere instead (see FIGURE 9.28).

NOTE: This level requires the Chapter_09_KismetContent.upk package, included with the files on the DVD for this chapter. If the sphere appears gray instead of red, locate and open this package, and then reload the level.

Step Four

1. Right-click in the Sequence window to the right of the Used event, and choose New Action > Material Instance > Set ScalarParam from the Context menu (see FIGURE 9.29).

2. 
   FIGURE 9.29 Place the new Set ScalarParam object just to the right of the Used object.

3. In the Generic browser, open the Chapter_09_KismetContent.upk package and select the mat_RedBluePulsar_inst material instance constant. Once selected, you can close the Generic browser.
4. Select the new Set ScalarParam object, and in the Properties window of the Kismet Editor, select the MatInst parameter and click the Use Current Selection in Browser button. NOTE: If nothing appears when you click the Use Current Selection in Browser button, it is possible that you selected the parent material instead of the material instance. If this is the case, make sure to go back into the Generic browser and open up the material instance constant.
5. Click on the ParamName property, and type redblue for its value. You will notice its case change to say RedBlue. This is an indication that Unreal recognized the parameter’s name (see FIGURE 9.30).

6. 
   FIGURE 9.30 Here you can see that the RedBlue parameter has been entered into the ParamName property.

7. Set the ScalarValue property to 1.
8. Drag a wire from the Out output of the Used event to the In input on the Set ScalarParam object (see FIGURE 9.31).

Step Five

1. Duplicate the existing Set ScalarParam object by using Ctrl-W. TIP: Kismet objects may be duplicated by using Ctrl-W, but you can also copy/paste them with Ctrl-C, Ctrl-V!
2. Move this duplicate to the right of the original, leaving enough room for another sequence object to be placed in between (see FIGURE 9.32).
3. Set the ScalarValue property of this new Set ScalarParam to 0, which changes the color back to red.

4. 
   FIGURE 9.31 The Used object has now been wired to the new Set ScalarParam object, enabling us to change the color of the material

   
   FIGURE 9.32 You can now see the duplicate of the Set ScalarParam. We use this new object to set the color of our material back to red.

5. Right-click between the two Set ScalarParam objects and choose New Action > Misc > Delay from the Context menu. Place this new object directly in-between the two Set ScalarParams (see FIGURE 9.33).

6. 
   FIGURE 9.33 The new Delay object causes a timed delay to take place between when the material is changed to blue and when it automatically resets to red

7. Select the new Delay object, and in the Properties window of the Kismet Editor, set the Duration property to 2.
8. Drag a wire from the Out of the first Set ScalarParam object into the Start input of the delay. Then, drag another wire from the Finished output of the delay in to the In input of the second Set ScalarParam (see FIGURE 9.34).

Step Six

1. Right-click on a blank area of the Sequence window and choose New Event > Level Startup (see FIGURE 9.35).

2. 
   FIGURE 9.35 Place this new Level Startup object above the main sequence

3. Drag a wire from the Out output of this event into the In input of the second Set ScalarParam, which is currently at the end of your previous sequence (see FIGURE 9.36).

FIGURE 9.36 Connect the Level Beginning’s output to the input of the second Set ScalarParam object.

In this way, you are reusing an existing sequence object to reset your color, rather than creating a new one. You are, of course, welcome to use a new Set ScalarParam object if you like, which may help with readability of the sequence.

Step Seven

Simple Kismet Sequences

An object list is a type of object variable that, instead of storing a single object, contains a list of many objects. You can use a series of actions to populate, control, and clear this list throughout your sequence. Using an object list can have great advantages over creating many different object variables, especially when spawning new objects into the level.

TUTORIAL 9.4 demonstrates two important concepts for using Kismet. The first is the spawning of actors,which enables the designer to add objects into a level during gameplay.We also show how to log information during a Kismet sequence, which can be crucial when trying to debug errors in your Kismet sequences.

TUTORIAL 9.4: Spawning Actors with Kismet and Logging Sequences

Step One

Step Two

Set the MaxTriggerCount property to 0, and uncheck bAimToInteract.

Step Three

Step Four

1. Right-click in a blank area to the right of the Used event for Trigger_0, and choose New Action > Actor > Actor Factory.
2. Connect the Out output of the Used event for Trigger_0 to the Spawn Actor input of the Actor Factory. This causes a new actor to be spawned every time the player uses the trigger (see FIGURE 9.38).

FIGURE 9.37 Both Used events have now been created.

Step Five

1. Select the Actor Factory, and in the Properties window, locate the Factory property, and click the Add New Object button. From the Context menu, choose ActorFactoryRigidBody. A list of new properties appears for the rigid body (see FIGURE 9.39).

2. 
   FIGURE 9.39 Here you can see the Context menu that appears when you click the Add New Object button.

3. Locate the StaticMesh property, and use the Generic browser to set the property to the sm_simpleSphere mesh, included in the KismetSpawn package.

Step Six

1. With the Actor Factory selected, go to the Properties window and find the SpawnPoints property.
2. Click the blank area next to the property, and then click the Add New Item button ten times to create ten different spawn points.
3. Enter the following information into each index for the spawn points (see FIGURE 9.40):
   • [0]: TestPlaceableActor_0
   • [1]: TestPlaceableActor_1
   • [2]: TestPlaceableActor_2
   • [3]: TestPlaceableActor_3
   • [4]: TestPlaceableActor_4
   • [5]: TestPlaceableActor_5
   • [6]: TestPlaceableActor_6
   • [7]: TestPlaceableActor_7
   • [8]: TestPlaceableActor_8
   • [9]: TestPlaceableActor_9

FIGURE 9.40 Your fully populated spawn points list should appear like so.

Step Seven

1. Right-click to the right of the Actor Factory object and choose New Action > Object List > Modify ObjectList from the Context menu.
2. Connect the Finished output of the Actor Factory to the Add To List input of the Modify ObjectList sequence object (see FIGURE 9.41).

3. 
   FIGURE 9.41 The Modify ObjectList is now attached to the Actor Factory sequence object.

4. We now create the list itself. Right-click beneath the Modify ObjectList sequence object and choose New Variable > Object > Object List from the Context menu. Connect the ObjectListVar output to this new variable (see FIGURE 9.42).
5. We now need to provide an object that we can place into the list. Right-click beneath the Actor Factory object and choose New Variable > Object > Object. Connect the Actor Factory’s Spawned output to this new vari- able, and connect the Modify ObjectList’s ObjectRef input to it as well (see FIGURE 9.43). NOTE: You’ll see three question marks (???) located within the new object variable. This is because we have yet to assign it a value in Kismet. However, you’ll also notice that the Spawned output uses a triangle instead of a square, meaning it is outputting a value. The result of all of this is that the Actor Factory actually sends the name of the object into the blank object variable, and the Modify ObjectList object then reads that name andapplies it to the list.

FIGURE 9.42 Our object list variable is now in place.

Step Eight

1. Right-click in a blank area to the right of the Modify ObjectList sequence object, and choose New Action > Misc > Log.
2. Connect the Out output of the Modify ObjectList sequence object to the In input of the Log (see FIGURE 9.44).

3. 
   FIGURE 9.44 The Log object sends information to the screen during gameplay. It is most often used for debugging purposes.

4. We need to create a new Int variable to store the number, but this time we’re going to use a shortcut. Right-click on the small teal triangle beneath the List EntriesCount output of the Modify ObjectList sequence object. From the Context menu that appears, choose Create New Int Variable. You can do this with any color-coded output!
5. Now we need to send this information to our Log. However, if you look closely, you will notice that the Log currently has no inputs that accept Int data. We need to expose it.

   Right-click on the Log and choose Expose Variable > Int – Int* from the Context menu. You will see an Int input appear on the bottom of the Log.

6. Connect this new Int input into the Int variable (see FIGURE 9.45).

FIGURE 9.45 With our variables in place and connected, we can now output the number of rigid bodies in the list to the screen

Step Nine

1. Right-click to the right of the Used event for Trigger_1. In the Context menu, choose New Action > Actor > Destroy.
2. Connect the Out output of the Trigger_1 Used event to the Destroy’s In input.
3. Connect the Destroy’s Out output to the Empty List input on the Modify ObjectList sequence object.
4. Connect the Destroy’s Target input to the object list variable (see FIGURE 9.46)

Step Ten

1. In the Kismet Editor, select the Actor Factory and look under the Factor properties Find the DrawScale3D properties and set the following:
   • X: 0.5
   • Y: 0.5
   • Z: 0.5

FIGURE 9.46 Your completed network should look something like this.

Step Eleven

Infamous starts players off in a well-sized chunk of city with, primarily, standard methods of movement and a few primary missions to undertake as it slowly introduces players to the world. Prototype and Spider-Man: Web of Shadows both start players off at a point in the game much later than the actual "starting point" and give their players a taste of what kind of super-powers they'll have towards the end of the game before they properly start and wipe the slate clean. Both Prototype and Spider-Man both have one singular thread of missions that players can embark on to actually advance the story (along with narrative-independent optional side-missions). Red Faction: Guerrilla leaves the entire world open (and destructible, but that's irrelevant here), but progression through anything other than the primary cities is generally difficult. Skate 2 leaves the entire world open, provides players with a few "key activities" for progression, but also allows players to discover new activities and challenges purely through exploration.

The one game I have played in memory that had a truly open-world approach to both narrative and gameplay was Realtime Worlds' Crackdown. This is a game where the player is given the task of eliminating three major crime organizations, with each organization calling a major section of the game's city their territory. The player, then, has completely freedom to decide how this problem is tackled.

Crackdown's structure is completely different from the likes of Grand Theft Auto 4 where, essentially, the structure is that of a linear game taking place in a large sandbox. It seems that this is the standard approach taken to open-world games: very directed narrative with traditional mission beginnings and endings where the gameplay is executed in specific locations of a large world. This allows designers to craft a traditional story while attempting to keep the gameplay open, varied, and unique by virtue of everything unfolding in a large sandbox.

Befitting of its topic, this discussion will be a bit more wide-open with room for people to discuss the narrative and gameplay benefits of the open world game structure. This means that contributions could be purely design observations on different approaches to sandbox gameplay, gameplay stories that illustrate a particular point, comparisons of different formats, or whatever else. This may be a hard topic for me to make a summary article out of, but I'm sure I'll figure something out. I realize the subject this time around is huge, non-specific, and has a ton of room for a variety of topics, but I'm sure you guys and gals will make something out of it. That said, here are some particular questions to start things off:

Relevant questions that may be good to tackle in this discussion:

• What are the benefits of a fully free-form open world progression in open world games?
• Conversely, what are the benefits of methodical, directed progression in an open world game structure? Is the structure of a line of primary missions (missions which advance the game's core storyline) along with a host of side-missions/objectives an ideal case for open world games?
• How does the wide-open nature of gameplay in an open world game impact gameplay and a designer's approach to creating missions?
• "Should" open world games strive to present the same types of stories as traditional games do or should the focus be on providing a toolset for player-born narratives? (This is the heart of emergent game design)

Observing Open Worlds

[...] With sufficient complexity sandbox games also have the advantage that the experiences they present are, by their modular nature, are often unique (or at least highly individual) when taken as a whole. This can make a player feel that the adventure he or she has had is truly their own, rather than something carefully scripted by the designer.

Of course this strength is also a great weakness and is one of the hardest challenges I'm dealing with at the moment in my own design. If the world is open and you're free to assemble experiences as you will, what's to stop you (by your actions) from assembling mediocre or bad experiences and thus having a mediocre or bad game? I'm talking about closure and what makes the sum of your activities meaningful.

Linear games excel in this area, and although it's annoying to me as a sandbox fan it's also no surprise to me that many recent sandbox games have been trying to incorporate linear gameplay. Linear gameplay allows a designer to craft a series of singular, significant experiences that culminate in an emotionally resonant whole precisely because they happen one and only one way. Unlike in a game like Morrowind, where you can stumble on the end of a good storyline (and ruin it) just by wandering into the wrong place, a linear series of missions can surprise the player and mold their perceptions in a way that makes the end result satisfying.

That said, I hate linear content in a sandbox world unless it's completely optional. But I'm also not a big fan of player created stories (for reasons mentioned previously). I guess I prefer the linear storytelling straight-jacket all the way on (as in FPS games where I tend to check my brain at the door) or all the way off, and half-linear measures leave me feeling that the designer is somehow taunting me or assuming I'm too stupid to take care of myself in their world. My gold standard for sandbox games is the venerable Binary Systems classic Starflight from the 80s. Their approach to storytelling was to scatter the narrative about an immense universe and challenge the player with putting it together. There were no missions per se, but the player was driven to overcome the sandbox world's limits in order to learn more; if they failed, the universe was eventually destroyed (and although they could keep playing, without closure the experience was ultimately meaningless). Starflight, to me, embodies the core element of what makes a sandbox game with a story good: You have immense freedom, but it comes with responsibility. The designer doesn't coddle you through the world, constantly remind you of what needs doing or provide waypoints that lead you by the nose. Nor does he gate content, assuming you can't take a few knocks. Instead, he relies on you to use your brain and put the narrative elements together.

Maybe it's an ethic that's out of fashion in our current quick-fix culture, but I think the meaning you get from such an experience is far more rewarding than meaning that's handed to you through linear missions.

The first of John Judnich two posts raises two great points:

A completely open world would have no pre-written plot at all; the plot would emerge from the simulation. Obviously, linear plots are implemented typically because the kind of dynamics (social, political, etc.) for the story style desired would be far too complex to implement in a fully dynamic simulation in most cases.

[...]

Note that while human-written "plots" (linear events that must happen) are counter to a sandbox game design, a fully open world can still have human-written "stories" in that the game simulation and AI strategies / characters themselves can be carefully crafted in such a way that the situation encourages a certain type of plot to emerge. Obviously, even if a game has a 100% realistic simulation, it would be no different from real life and therefore there would not be much motivation to play it. This is where the emergent game design comes in; rather than writing exciting linear plots, you write exciting environments, situations, and AI dynamics.

A subsequent post Clinton Myers makes pretty much the exact opposite claim [Note: I am re-ordering his post a bit]:

[...] I believe that the best form of an open-ended game is one that offers the player a wealth of optional non-critical missions - missions not pertaining to the main story arch - where each of these missions are involved and linear in nature. Furthermore, I believe that the core story arch should be as equally optional as these supplementary missions.

[...]

Consider Elder Scrolls IV: Oblivion. Nearly everything in the aforementioned game is optional, including the main quest. The player can spend well over a hundred hours simply reaping enjoyment from entirely optional sub quests, some of which are large enough to be fit into a separate game in and of themselves. Though the quests are linear, the player is still empowered with the ability to choose which quests to complete (or not to complete) which creates a strikingly powerful illusion of choice. This feeling of choice instills in the player a deeper attachment to the world and character at hand, and thus keeps them immersed and actively involved in the game. Reinforcement of progression of the main story arch (nagging the player to follow the main quest) is not necessary due to the large wealth of supplementary material that can keep the player interested. Notice how the availability of many sub-missions is the sole factor that makes Oblivion open-ended. Remove this extra material and we still have the game (the main storyline) but now we have a totally linear story that the player is thus forced to play (as there would be nothing else to pique the player's interest.)

What we have here are the two completely different opinions that get to the heart of the primary issue with open-world game design: keeping the game open while making the story as befitting the format as possible while still motivating players to actually experience and progress through the game. John Judnich's reply, while idealistic and largely hypothetical, makes a very compelling point:

A true open world is a world where, like I said in my other post, the rules of the simulation determine the story and the plot. Once you realize how a simulation and AI can be designed to make an infinite number of interesting dynamic plots happen under your (the designer) rules, you'll see I think that a game's story "backbone" doesn't have to be derived from good predefined linear plots - it can be derived from good characters, good environments, and good interactions. And the immersion factor increases exponentially because the virtual world actually does become much more "real" this way.

The ideal open world is one which takes a player's unique approach to a given game and responds to it in ways that both make sense and are equally unique for that player. Despite the number of games which seem to do this, the idea behind an open-world design should not be the molding of a traditional game into a design that's more current with a "hot trend" in gaming. If we, as designers, consider a gameplay progression format a neat way to present old ideas, then we're not taking advantage of the format. In the initial post for this round table, I mentioned Spider-Man: Web of Shadows as a game I had been playing recently and while the open-world the game employed fit its source material well, its actual implementation failed to present any compelling reason for an open-world aside from swinging around. The story was a linear trek through a series of missions with "optional side-missions" being MMO fare (kill x number of y dudes for z experience). The exploration was handled through a scattering of collectable power-ups which tasks a player with the obsessive compulsive urge to collect things rather than truly motivating a player to explore.

And along these lines, Christian Arca presents a particularly noteworthy open-world game experience in Grand Theft Auto: Chinatown Wars:

I think that Grand Theft Auto: Chinatown Wars is a beautiful example of an open world environment. In fact, I think I have never had the pleasure of playing an open-world environment that was as much fun as that one. While I was doing the main story-line missions, every single time I was driving by I would see something which I had the option to explore, and not only that, but I wanted to! There was this secondary design to the world which enticed me and rewarded me to explore the city. Maybe it was because without selling drugs I would be flat out broke and without money, but the side missions / exploration I was doing was so good that I was afraid of finishing the game.

This approach to the open world design is not new or original, but it seems to be one of the most effective ways of approaching the format while still adhering to traditional progression and story-telling methods. I call this approach the Saints Row 2 method -- which is by no means an intelligent moniker (nor is the source game the first to take this approach), but it's a game which approaches this type of open world game design with such intelligence that it deserves to have a term coined from it.

Saints Row 2 is a game which blatantly riffs off of the earlier Grand Theft Auto games. It is un-apologetically about gangs, cars, violence, drugs, and mass mayhem. Saints Row 2 is, however, very well aware of the absurdity of all of these factors thrown into a single game and, as such, chooses to make the most of the cocktail and throw in so many mini-games, side-quests, and parallel main storyline missions that it essentially assaults the player with such a variety of things to do that the open-world sandbox becomes a sandbox filled with every toy a child could ever want. Saints Row 2 takes the approach that an open-world is an area to be explored and that every action a player wants to engage in should yield an enjoyable result. This does not create a coherent, immersive gaming experience necessarily, but it provides players with an incredibly fun series of gameplay events within an open-world setting.

Open-world focused games are currently being explored in a huge number of retail games. There is no real "proper" approach to the handling of such a gameplay structure, but it is a worthwhile endeavor to attempt to decipher what certain games bring to the format that others like and vice versa. The Grand Theft Auto series is still the most popular -- both critically and commercially -- open-world game to be released and there's certainly a reason for that success. But what does Grand Theft Auto's handling of the format mean for the future of games in this vein? Due to the wide exposure of GTA, do players expect open-world games that follow to retain a similarly rigid structure?

I'll leave that question open (!).

Recently, games have been experimenting with achievements as an actual in-game economic unit for progression or earning new items; the best example of this being Valve's Team Fortress 2. When Valve started rolling out major game updates which completely revamped and updated existing classes with new items, balancing, and a huge host of achievements, the dynamic of Team Fortress 2 changed completely. When the Medic class update was rolled out, suddenly players were joining achievement farming servers where they could game the system to unlock achievements as fast as possible so that they weren't "behind the curve" when it came to playing in a proper Team Fortress 2 match. This put any TF2 players who wanted to earn achievements in a more natural, casual way at a huge disadvantage. This system persisted through the Pyro and Heavy class updates, but as of the most recent update, Team Fortress 2 has a new unlock system. This new unlock system, essentially, removes the need to farm achievements for the new items and instead relies on a tuned system of "random drops" for items. This both allows and promotes a more enjoyable behavior for gamers to get achievements (in a natural, non-competitive way).

Achievements which are completely separate from any primary game mechanics can still lead to undesired behavior, though, especially in the multiplayer arena. Halo 3 had an achievement which required gamers to get three sword kills immediately in a row and, as a result, I knew friends who would go into multiplayer games with no other goal than to get a sword and try to get that achievement despite the fact that this style of play was in no way conducive to the goals of the team-focused gameplay mode that he was in engaged in. Is this a problematic side-effect of achievements?

The current model of achievements allow for game designers and developers to implement a relatively simple, persistent way of rewarding players for in-game activities. That said, do achievements promote an undesirable play style (in single- and/or multiplayer)? How should achievements be paired with in-game mechanics and economies (if at all)?

Achievement Unlocked

Once the intrinsic value of a game has been exhausted, gamers come up with their own way to play a game. This is one of the principle of emergent game design (encouraging players to play their own game and be constantly rewarded for it with new experiences) being applied to games which are definitively linear or scripted. One of my personal favorite games of all time is Max Payne. I played Max Payne through about two or three times but, by the time I started my fourth play-through of the game, I had the goal of beating the game without ever using the bullet time functionality. It's a difficult endeavor, but one that encouraged me to experience the gameplay in a completely new way. And, sometimes, I've altered the way a game is meant to be played in an effort to play the game how I thought I'd find more enjoyable during a first play-through. This is how I approached Bioshock on PC when I discovered that it was a bit easier than I generally prefer so, in an effort to challenge myself a bit more than the game would have liked me to, I opted to never use a single Vita-Chamber (so, when I beat the game, in the game's eyes I beat it without dying once).

It's out of this sense of player-set goals, challenges, and meta-games that achievements were likely born. But, having written about this before, I'll now turn the focus over to this Game Design Round Tables' contributors for further discussion (and more commenting by me sprinkled throughout).

Luke H. Thompson writes about his grievances with games which give achievements for "just playing the game:

I'm not sure I really care for achievements that you get just for playing the game. The Lego Indiana Jones game that came with the Xbox seems to give an achievement for each level/area of the game, something you're supposed to be doing in the first place as part of the game. However, it also rewards achievements for being a "True Adventurer", getting so many of the lego currency thingies per level/area, something that can be difficult to do in later areas. FarCry 2 seemed to have some good achievements. Accessing every safe house. Having entered every km of the map. Etc. Still, it offered achievements for performing routine/required gaming actions. IIRC, each mission completed for either of the opposing sides, something requird to advance the story, would warrant you an achievement. I suppose, though, that these are a "side effect" of MS, since they likely wouldn't want a handful of achievements dishing out a couple hundred points each. As for replay value, I think it could work nicely. If there are mutually exclusive branches for certain areas of the game(one of which must be taken), then rewarding an achievement for the branch, despite it being "just for playing the game" doesn't seem quite as bad to me. You're still going to have to play through the game again, or at least up to that point

• Achievements that can be earned by playing the game the way it's designed to be played. (Standard Progression)
• Achievements which require players to play the game, exploring a little bit and doing some side-quests or some such. (Optional Progression along a Standard Progression)
• Achievements for completing specific, hard-to-come-by challenges along the Standard Progression. (Challenges)
• Long-term achievements for just playing a multiplayer game in a standard way. (Multiplayer Standard Progression)
• Achievements for completing specific, hard-to-come-by challenges in multiplayer. (Multiplayer Challenges)
• Achievements done in good spirit or humor that memorialize gameplay occurrences. (Awesome)

Simon Ferrari continues the thread with a superb, detailed, and very well thought-out post that covers a lot of ground. The quote I'm choosing to highlight doesn't really do his contribution proper justice, but it expresses a great use of achievements:

[...] [G]ood achievement structures can be double-edged swords. My third favorite 360 game, achievement-wise, is Halo 3. I loved unlocking armor pieces to customize my avatar with (although I wish they had more-than-aesthetic affects on gameplay)—I was the only person I knew with the Security gear for a really long time, huge nerd cred. As [Trent] shared in his anecdote, though, the multiplayer achievements encourage farming and cheating. Bungie has gone through phases where they crack down on this behavior, but in the early days of the game or after a new expansion it's hard to find a match where half the players aren't trying to boost in some way. I've never played a public Grifball match where one of the eight players didn't start asking if they could farm for a Killionaire and end up team-killing out of anger. Following Petrie's comments on Mega Man 9, I prefer in-game MP challenge systems such as CoD4's; these allow designers to craft elaborate achievement structures without giving players the incentive to boost just to show off their sum Gamerscore to others. I think multiplayer global achievements are possible, but they need to be designed around aspects of play that can't be easily exploited (win x# matches with x class or weapon, for instance).

Farming servers and matches are lame, I agree, but I don't necessarily see a problem with the sword example in the OP. Because of the achievement, he used a weapon and play-style that he might not normally use and therefore got a little bit of extra replay value out of the game. He also made the match slightly more interesting (at least for the other team). Maybe he jumped around like an idiot for the entire match and died repeatedly, but potentially he could have also saved the team by swording everyone in the back. The point is he tried something different. I think that's the main attraction of achievements: encouraging different gameplay. Combined with restrictions on the environment in which you can earn them (to prevent farming) and in-game incentives (different armor ala Halo 3, or 'Perks' ala CoD4), they're worth having.

I have minor issues with achievements tied to multiplayer aspects of a game [...] Achievements tied to multiplayer components of the game are also tied to the success of the game. By which I mean, if the game flops, or is just not wildly popular, it may be very difficult to get into a multiplayer game, let alone a game with the parameters required to earn some achievement -- this hurts players, and further harms and already failing multiplayer community since it encourages farming. Anybody have the World Domination achievement for the XBLA port of Marathon? If so, let me know, we need to set up a game. If pressed I would say that I think multiplayer achievements are not a good idea, or at least that they haven't been done to my satisfaction yet. This is a pity because the multiplayer environment offers an order of magnitude more options for creating clever achievements due to the dynamics and interactions involved in having other humans involved.

One good use of achievements is to memorialize extraordinary moments. The Xbox Live Achievements I enjoy most are the ones that reward lucky, odd, and crazy things. Crackdown has an Achievement for using the harpoon gun to pin three or four people to the same car. It also has an Achievement for leaping from the top of the tallest skyscraper and falling (harmlessly) into the bay below. Those aren't just accomplishments. Those are memorable moments. Trophies and Achievements can help preserve such fond memories.

It's not that achievements are bad but that they are limiting (in their current form). They are a set, finite, and objective account of a player's experience in a game. Some Gamedev posters mentioned that achievements could lead them to act in the game differently than what they normally would have done; for instance, Simon stated that the achievement to "complete Ravenholm using only the gravity gun" was something he would have never done without knowing about that achievement. But does the fact that he only completed that achievement because he knew about the achievement diminish the act of attempting to use only the gravity gun in the level? Should Half-Life 2 have made it clear enough where Simon would have been motivated to attempt that achievement regardless if there was a reward for it or not?

This is why the Call of Duty 4's unlockable system was so awesome. First, all the multiplayer achievements were only rewarded in-game and not on a meta or global level. They asked you to basically display battle prowess in every way possible while avoiding things like Halo 3's Steppin' Razor that Trent cites. While the CoD4 perks gain in power as one's level progresses, the strength of the weapons you unlocked actually decreases (on average; some were superior). In order to gain experience faster you're encouraged to get X amount of kills with every weapon, which leads you to use the less powerful unlocked weapons. Then they rounded the whole system off with the prestige level that asked you to remove all your unlockables in return for a new rank and bragging rights. Really well-designed system there. I do wish that some of the milestones in prestige level were shown on as global achievements, but I understand why they did it (was a fairly risky move, as by the time the game came out many players were already saying they preferred games that awarded them with achievement points).

Growing up playing video games, we used to do achievement type stuff anyway. How many points can you score in Super Mario Bros in 60 seconds, play a round of golf using only a 9 iron, or (my personal favorite) can you really play this level with your eyes closed? That kind of stuff was fun because we were trying to find new ways to play with a toy. Kinda like an exercise in creativity. When I encountered achievements that were like, "Run from point A to B in X seconds," I remembered doing that sort of stuff with games when I was a kid. I took a couple shot at one or two of the achievements, thought hey that was a fun idea, and then set the remaining achievements on the list aside so I could complete the game. And I still like doing the sort of thing where I think of stuff on my own. Fallout3, I decided I wanted a library in my home so for awhile I was determined to collect every book I could find. Eventually I got bored of this self induced quest and moved on. In Elder Scrolls III, it was shoes. Good times.

The Death of Death

Denial and reward can encourage the formulation of a rich experience. In designing paths of travel, try presenting users a view of their target -- a staircase, building, entrance, monument, or other element -- then momentarily screen it from view as they continue their approach. Reveal the target a second time from a different angel or with an interesting new detail. Divert users onto an unexpected path to create additional intrigue or even momentary lostness; then reward them with other interesting experience or other views of their target. This additional 'work' will make the journey more interesting, the arrival more awarding. -- Matthew Frederick, 101 things I learned in architecture school

Losing the three lives are three non-fatal failures to the player, and it communicates the simple rule of thumb: If at first you don't succeed, try harder. If you don't succeed at the second attempt, try even harder. If you don't succeed at the third attempt, give it up. There's no need to make a fool of yourself

I think this topic ties strongly in with difficulty within a game. It is all about balance. I'll use two extremes to explain my point. In the first game, there is no punishment for failure. Death (or equivalent) is simply not possible as you have infinite health. In game B, if you die once, which is perfectly possible, the game resets. You have to start again, your save wipes. The problem with the second one is fairly obvious. If you played a game for more than about 20 minutes and you had to do all that again, you simply wouldn't. The problem with the first one is there is no challenge. If there is no challenge, there is no reward. Not only do you lose all sense of realism, and hence, immersion, the game ceases to be tense in any way. You no longer feel connected to the world or your character. If you can't fail, there is no point in succeeding. [...] So, like difficulty, it is about balance. In Fable (2), I feel no fear when rushing in, as I know I can't die. I don't think this is a straight out bad thing - your meant to be a super powerful hero whose going to save the world, I would find it very difficult to believe that some small time criminal can take me down. Indeed, any death breaks immersion because, in real life, you can't die then try again. For me, the answer is that the player should constantly fear death (depending on the game, but as a general rule) but never actually experience it [...]

[...] there's nothing immersive about dying either. Death will, pretty much by definition, always destroy immersion. No matter how you handle it. [...] Go and watch a typical action movie. The hero regularly screws up, experience setbacks and so on, but they don't die. They might have to start over from scratch, get booted out of the police force or whatever else. They get punished, sure, but they don't die. Perhaps games should do the same thing. Rather than killing the main character every time they screw up (and then ending up in a situation with no realistic/immersive way out), just let them, well, screw up.

One of the things we must overcome is what we define as a challenge. Do we really need death in order for a game to be perceived as challenging? The most common challenge in games today is the avoidance of death. While this works for many games, this does not mean that we cannot think beyond this. Challenges and the difficulty of a game can become more grey instead of just a black and white, 'do-or-die' situation. Puzzles, World navigation, character modifications are all examples of challenges that don't necessarily need to involve death.

Tetris is challenging because you are trying to avoid 'death' (the playing area filling up), world navigation is challenging because you have to avoid certain situations that risk death, and character modification is challenging in that it affects your ability to avoid death. Most games quantify player progress in the form of resources - be it gold earned, stats/levels, or just time. Challenge is synonymous with Risk, and the player can only risk resources - challenge then is allowing the player to be deprived of resources, a mechanic commonly called 'death'. We can of course call it something other than death, and disguise it however we choose, but the core Risk/Reward mechanic remains.

Death is just one motivator that can be used in game’s design. It’s a state of failure and the player has to work to avoid it. You can call a failure state something else and wrap it up in a pretty bow but it’s the same concept at its core. The player knows they will be punished if they fail to succeed at some part of game. Yes, the type and extent of the punishment varies, but its punishment none the less. This motivates them to achieve the game’s goals while giving the player a sense of risk. Since, risk is often associated with fear & adrenaline (and hence excitement), well introduced punishment mechanics like death can make games more exciting while motivating the player to advance. The other powerful motivator in games, reward, can motivate the player but seems to lack the element of risk. A game that doesn’t use death (or punishment in general) has to rely on the player seeking some sort of reward to motivate them to continue advancing. This reward could be something in game like completing a quest and getting gold or it could be personal satisfaction at completing a puzzle, etc. Getting a reward can lead to satisfaction and excitement (especially with random rewards like finding a rare item in a game) but still lacks risk and the feeling of danger about it. Personally, I don’t like dying and having to repeat some section of a game. It lessens the impact, not because I “died”, but because I’m now going through the motions I just went through simply because I made a mistake. I’ll now defeat the challenge of the game but not because I played better as much as I simply know what’s going to happen. Everyone’s tolerance for death and having to replay parts of the game is different so I don’t think there’s a right answer but I think in the perfect (unachievable) world the threat and risk of death would exist but the game would keep the player on the cusp of death, always teetering over the edge of the cliff but never letting them fall.

Fable [2] still actually punishes the player for dying (albeit relatively lightly), whereas in Bioshock there's zero consequences for dying - you're simply resurrected in the nearest vita chamber, which is never more than 30 seconds walk away. You lose no experience, ammunition, status or kudos other than the personal frustration of not hitting "heal" quick enough. Personally I'm not a fan of having death have minimal or zero side effects - not only does it make a mockery of people who actually play the game skillfully, but because it can mean a player can force their way through a game without really understanding it. I've witnessed this first hand when a friend was trying to play Bioshock like they'd play Quake 3 - run around frantically while shooting everything that moves. The result is that they miss the subtler stuff (like listening out for enemies or security cameras), and fail to learn how to use the weapons or environment properly. They end up dying repeatedly (and frequently) but because they're making slow (but painful) progress they never stop and realise that they're missing the point of the entire game, and end up dismissing it as too frustrating to be fun.

Interesting points, and Bioshock is a good example. My counter argument is this; in Bioshock the point of the game, for lack of a better phrase, is to explore and discover the cool under-water world. If the game was continuously challenging, the player would end up focusing on the combat and ignore the story. In a game like Halo, I focus on the combat, so I haven't collected any of the skulls, I don't explore the world, because I don't find that to be the focus of the game. By making death so irrelevant, they allow the player to explore the world fully without constantly worrying about dying and having to repeat an entire section. Without this mentality, many players wouldn't explore, as dying miles away from where you are supposed to be is worth than dying a few feet away.

The problem how I see it is that death [of the player character] is usually not an interesting gameplay event, mostly because it's usually is paired with a save system which makes it meaningless. Take an example. Assume a game, any game really, with the added game mechanic that periodically forces you to press some specific button, failure to do so within some reasonable time would lead to a reset of the game with the associated loss of progress. I think it's not far fetched to consider that particular game mechanic to be detrimental to pretty much any game. It's similar to functions such as eating or sleeping that get left out of other games because they add nothing valuable to game experience, and are instead implied to be performed automatically behind the scenes. This is analogous, although admittedly far-fetchedly so, to the save mechanic of modern games. "Death" means that the player is forced to resume from the last saved game. So as in previous example, why should you get punished for not pressing the quicksave button every 10 minutes instead of saving being done automatically behind the scenes? And if it is done automatically, popping the player back to the last safe position upon "death", why bother to model it is as death at all since it's quite clearly not the permanent end it implies? Then on the other hand, there are scenarios where death is a fundamental gameplay mechanic. Any multiplayer deathmatch game is a good example. There your death means the success of the opposing player[s], which is in itself interesting. It's not hard to come up with other scenarios either. Tetris for example, here the "death" mechanic is interesting because it marks an end of the game. The challenge, a meta-game in a sense, is to see whether you are able to play better next time.

The normal campaign has an insane amount of checkpoints, so that you never have to do a large part twice, but broke up the challenges is small parts, that you did have to complete in one go. However in the speed run/time trail is where the game really shines. If you die, it is almost impossible to achieve the target times for the levels (because dying takes a little time). You can however still finish it the level.

There have been a couple people that have pointed this out in some way or form. A player's strategy is devised in response to the rules and goals of a game. A light death penalty will cause the player to create different strategies than if there is a harsh death penalty. A light death penalty might cause a player to develop strategies that are more focused on the completion of the game at any cost. This may even involve leveraging the effects of death to accomplish a particular goal if it is expedient. Take for example a room that is filled with deadly traps. Instead of the player taking their time to locate the traps, they may die repeatedly in order to discover the locations of the traps or bypass them using brute force if they are instantly revived every time they die. A harsh death penalty might cause a player to develop strategies that are focused on survival. This would include doing things like hoarding resources, building impenetrable defenses, or putting more consideration into the effects of their actions in different situations.

What is particularly interesting about this point, and identified in OrangyTang's player-story, is the failure of death as a game mechanic to actually force a player to adjust their play style. It is interesting because death as a mechanic is applied broadly across all methods of failure. A player who charges in recklessly receives the same response from the game as a player who runs out of ammo at a bad time. Which begs the question: Are some of the issues resulting from death as a mechanic a failure of a mechanic, or a fault of the broad application of it? Should we be applying separate mechanics based on the conditions of failure?

Round Table Topic -- Regenerative Health

GiantBomb has the first occurrence of regenerative health in Wolverine Adamantium Rage (Genesis, SNES; 1994). The mechanic's first mainstream appearance, though, was in its devolved form in Halo (Xbox; 2001) which had fully rechargeable shields which absorbed most of the player's damage. Once the shields were out of energy, though, Halo still relied on a more traditional health system which included requiring players to find health pick-ups. Halo 2 took this concept a step further with a fully regenerative health system, tasking the player with only managing the ammo and type of his/her weapons. The net result of the widespread adoption (in games like Resistance 2, Killzone 2, Call of Duty 2-4, and so on) of this mechanic into modern action games of all types is that players are no longer thinking of their health some arbitrary number or percentage in the middle of a heated combat encounter.

Does this mechanic simplify action games in a good way? Is the reduction in manageable resources a boon or detriment to players? Are the hit-and-run (to cover) tactics that regenerative health systems not only encourage but often demand beneficial to most of the games that this mechanic is employed in?

No More Health

The concept of the health bar is one that the "core gamers" -- the kinds of video game players that have been around for years -- all understand perfectly, but the attempt to concretely display an abstract concept isn't a particularly elegant solution for conveying player stability and well-being. And along those lines, the necessity to replenish a health bar yields some realism-breaking gameplay conventions: floating health supplements (medicine packs, wall-mounted rejuvenation centers, etc.) that games generally have players walk over to either be added to an inventory or be instantaneously consumed for additional health. Putting aside for a moment the lack of realism inherent to this gameplay practice, such a system also tasks a player with an additional layer of resource management. This is typically an additional resource to whatever weapons, ammunition, and other items that a player has in action games, though as Aaron Miller points out this is not necessarily a bad thing:

The search for health can be a very interesting diversion in an FPS. It can flavor encounters, making some situations more desperate or requiring stealth or diversionary tactics. It can also, as it was in Doom, be a source of meta gameplay in and of itself, requiring players to risk environmental hazards or rewarding them for quirky exploration.

[...] a system with health pickups can lead to interesting situations where a player makes a mad, basically suicidal run into a group of enemies with the goal of reaching a health pickup just before death, or where a weakened player can be tempted into navigating difficult environmental obstacles.

However, in a game were resource management is part of the experience, I believe regenerating health would be a detriment. Imagine if Left 4 Dead used the health generating mechanic. Most likely the zombies and special infected would have to hit much harder to be any threat to the players. So, rather than experiencing maps where the players literally limp across the finish line, pleased with the way they managed to pull through as a group, most maps would be either the players getting shredded by the infected or flying through the map with no problem.

If a concrete, or non-regenerative, health system is some form of resource management, then a regenerative health mechanic is a means of enforcing certain player behaviors and game flow. As Josh Petrie says it:

[Regenerative health systems] almost necessarily cause gameplay to be sliced up into reasonably short, controlled encounters of at least some minimum intensity. A regenerative health system basically gives the player a damage threshold: get through an encounter under this threshold, you live and can move on to the next encounter. Otherwise you die. Killing the player is accomplished by overloading this threshold in a short period of time, which means you can't build suspense in the player via prolonged needling little encounters that keep them at low health [...].

You're in the middle of a skirmish with a group of enemies. You are blasting away at them as they quickly bring your down to the 'dying' stage. You dive for cover and a few moments are back to full health. You now return to the blasting away part and them subsequently returning you to near death. This cycle continues until either all of the enemy are dead or a lucky shot from the enemy drops you to 0. There isn't much suspense unless you willingly run into the midst of the enemy. [...] For me, if a game designer wants to implement a regenerating health bar, it should a a [sic] large chunk of time to fully recharge. Using a slow health regen, enemies are more likely to start hunting you down rather than just using suppression fire, which would increase the pressure for the player to do more than just pop in and out of a hiding place.

Personally, I feel that the system has it's merits. In a game that warrants quick encounters with equally matched opponents (e.g Call of Duty 4 multiplayer), wherein the player has the potential to be eliminated reasonably quickly, giving the player the ability to regain their health prevents them from suffering immediate game-impacting permanent health loss if they are glanced early after spawning - and thus they are also not immediately forced to predictably move to locate health pickups. It serves in some respect to assist in leveling the playing area in an often sprawling, maze like arena, and prevents lucky or random shots from killing outright, but with a lower player health, a misjudgment or tactical error can easily lead to death.

[...] However, such a system certainly has no place in some competitive arenas. Consider Unreal Tournament 2004, and the common one-on-one death match. Ultimately, a regenerative health system could only detract from the nature of the game. Experienced and veteran players are very much familiar with the strategic and tactical nature of determining one's path through the chosen environment, denoting that damage and health critical pickups are only available at certain intervals. Failure to adopt an appropriate means to control these power-up points and deny them to the opponent is a very prominent emphasis in what would otherwise be a much more bland and imbalanced game; since otherwise the player could not be encouraged to move; since they can find a suitably strong position to sit in, and remain within it, given that they are able to always regenerate their health. Without the ability, they can occupy this position, but will be forced to abandon it should they take damage - and in the case of many a good level design, health pickups are in the more vulnerable and frequently passed through areas of the map.

I think that regenerative health systems are definitely a step in the right direction when it comes to simulating firefights in action games. This is because in many circumstances those systems are fantastic at simulating the real life feeling of being fired AT but not being hit which makes up the majority of 20th and 21st century combat. [...] In a real firefight (disclaimer - I've never been in a real firefight) many more bullets are fired into walls, the ground, the air than actually hit a target. The oft quoted statistic is that in the current US wars the US is firing a quarter of a million bullets for every insurgent they kill. All these bullets are getting fired in order to scare the shit out of the targets, and get them to not move or fire back while the US figures out how to safely kill them. It usually works because getting shot at is FUCKING SCARY. They also fire so many bullets because it is really REALLY hard to shoot someone. If you've ever shot a gun, you know that it's a little bit harder in real life than it is in games to get an accurate head shot at 50 yards.

However, getting shot at (not hit) in a game is a non-issue. It doesn't really phase most gamers because it's just a game. With their music up, they may not even know that a bullet just zipped over their head. It doesn't feel scary because you're not punished for almost getting hit. So how can a game properly simulate the feeling of getting shot at, of needing to be behind cover, that makes first and third person shooters look and feel realistic? You can do it by make it a lot easier for the bad guys to hit the player, but allowing the player to respond to getting shot without a long term punishment. Against 5 or 6 enemies the player will stick his head out of cover but quickly be overwhelmed at the volume of fire and duck back down - not because he was afraid of the amount of bullets being shot at him, but because his health was getting low due to being hit.

Additionally, and perhaps more importantly, it is extremely difficult to communicate to the player exactly what circumstances will cause him to be shot. If I stick my head up will I have 3 seconds to fire, or will I be shot immediately? If I am shot immediately, does that mean I am never allowed to poke my head up at that spot, or is it just the randomness of the AI's fire that caused the shot to land so quickly? The player has no idea, and because he needs to find a health pack every time he makes a mistake he is discouraged from experimenting in order to find out more about the combat systems.

Action Quake, an older NRH game which everyone interested in FPS game design should check out, has a bleeding/crippling/bandage system which could easily be adapted to a RH game. When you are shot (anywhere but on armor), even a very minor hit like 5hp from grenade shrapnel, you start continuously bleeding health - slow or fast depending on how serious the initial wound was. To stop the bleed, you must bandage yourself. This takes several seconds, cannot be cancelled and leaves you defenseless. So there is an awesome trade-off and mindgame that follows from one player being wounded; they have to bandage, eventually, and if you catch them at that moment you win. But they know this, so they can wait (and bleed) long enough to ambush the other player following their blood spatter tracks, and then bandage. There is also a leg damage mechanic which cuts the runspeed to half or so when you recieve a hit to the legs, also curable by bandaging. This makes for viable tactics like taking one fast shot at the enemy at long range, inflicting the bleed and leg damage, and then stalk the slow, bleeding enemy while staying out of sight. You can even use a shotgun for this as the initial shot only needs to hit the legs, not do real damage. [...] You could do regenerating health the same way, requiring the player to go defenseless for a while, etc.

There is no correct way of handling the concept of a player's life and longevity in a video game; there is no genre in which this is more true than in the fast-paced action of a typical first-person shooter (or a similarly-designed third-person action game like Gears of War). The varying means by which shooters achieve intensity and encourage players to adopt certain play styles is, in a lot of ways, entirely dependent on the way it handles its health system. As a number of the discussions and points made throughout the round table discussion illustrate, there are benefits to both an abstract health system where a player's life is largely up to his interpretation of interface/screen cues (regenerative health) and that of a more traditional, concrete health system that relies on life bars, numerical values, and in-world health replenishment. There were some absolutely great contributions to this sort of test run of the Game Design Round Table -- a name which I admit sounds incredibly pompous and pretentious but I think reflects the goals of the discussion pretty well. Before I wrap up, though, I want to point to a post made by Nick Halme which I couldn't figure out a way to integrate into this article but, also, made a number of very poignant design points through Halme's own past design project.

The next Game Design Round Table will be posted to the GameDev.net Round Table, with some revised guidelines, on Tuesday, April 21st. If anyone has comments regarding my first attempt at handling this whole thing that they want to direct personally to me, feel free to e-mail me trentp@gmail.com. I plan on doing this every two weeks (this may turn to three, as preparing this took a decent chunk of time) with the first week being a discussion of the posted topic and the second week being the eventual posting and discussion of the aggregate/argumentative article written by whoever organized the current topic. I'll probably keep doing this for a few more times and refine the guidelines and eventual article format as I go along, but if anyone would be potentially interested in spearheading a later iteration of this feel free to e-mail me.

Thanks to everyone who contributed to this, the discussion was great, and I'm sorry if I couldn't work every post into this piece.

Gather resources. Buy some units. Construct a building. Gather more resources. Buy more units. Construct more buildings. Now, do it all again. Rinse and repeat. Eventually, amass a huge mob of units. Drag-select them all and attack the enemy base. Does this sound familiar?

Hello. My name is Alex Kutsenok. I am the lead designer of Space War Commander, a new real-time strategy game by Dreamspike Studios. Space War Commander has just gone gold, and I feel like this a perfect time to share some of my thoughts on game design.

The formula described above has appeared in almost every real-time strategy game in the last 15 years. Players have mined gold with peons and built millions of little towns with 8 or more buildings. But why? How many strategy gamers actually boot up an RTS and say, “Boy, I really want to gather corn today!” Probably, none. Who wants to collect resources over and over? Who wants to build buildings and countless upgrades for an hour just to get to the “good part” of fielding an awesome army? In this article, I discuss how game designers can change how resource gathering is handled and also do away with base-building to make RTS games more engaging and original.

Diversify the Way Resources are Earned

Rather than make a grueling resource gathering system more interesting, some designers may argue that it can somehow be made better by having the AI handle as much of the process as possible. For example, a map may have six different resources that must be collected at six different places, all at the same time. Since most players either don’t want to or can’t handle so much work, one may think it would be logical to program one or more AI assistants to automate these tasks. However, this is not the answer because it doesn’t address the fundamental problem. If a game component is so not fun or so difficult that the designers have to make the AI do it, why have it in the game at all? Why waste the time and resources to implement something that the player will not appreciate or even take part in?

A different response to the problem of boring resource gathering is to eliminate it entirely. A few RTS games (like Myth the Fallen Lords and World in Conflict) completely abandoned money as something to be collected. These games provide the player with a fixed number of units or a finite amount of money that can be spent. However, I feel that it is still possible to make acquiring money a fun and original experience. The key is to have several completely different ways to earn money.

For example, in Space War Commander, we came up with the Big Three. That is, three unique and viable ways to make money:

• Control of planets and asteroids
• Trading of cargo
• Scavenging from destroyed enemy ships

Trading cargo involves sending Freighters between planets and asteroids to buy/sell goods. The player must invest in a fleet of Freighters to make trade runs. These runs take a while to execute but can yield large pay-offs. Furthermore, these runs may involve subtasks like protecting one’s trade fleet as it passes through contested sectors or places where Pirates are found.

Finally, the player can buy Scavenger ships and make a lot of money simply by hunting vulnerable enemy ships. Of course, these ships must be tracked and caught, which requires a small fleet of ships devoted to this task. The hulls of destroyed enemy ships are sold for scrap to earn the player money.

Notice how each of the Big Three involves a completely different kind of gameplay. Controlling resource means one has to fight for their possession and devote ships to holding them once they are won. On the other hand, trading involves thinking about the supply and demand of various planets and asteroids, while deciding which trade paths are shortest and least dangerous. Finally, Scavenging is all about noticing vulnerable enemy ships and pursuing them when the opportunity presents itself. On some maps, a player might end up doing all of the Big Three, while other maps only make it desirable to pursue just a single one.

Please note that as a strategy game, SWC doesn’t let the player simply do whatever he/she wants. It is not a “sandbox game.” Each map has characteristics that encourage certain strategies and not others. Making too many incorrect decisions results in a loss, so the player is forced to explore all three methods of making money and figure out which is best for a particular situation. Thus, we force the player to diversify his method of earning cash, which makes the game more interesting.

This approach of “weaving together” several viable and truly unique ways of making money is central to making resource gathering fun and engaging for the player. I am sure that there are countless resource gathering processes beyond our Big Three that could make future RTS games a lot more enjoyable. For example, one completely different idea is to have a collectible resource model where the player must seek out a few very specific resources to form a set. The big idea is to make the process of acquiring resources something challenging and thought-provoking. So let’s stop mining gold all the time and get creative with how money is made!

No More Base-Building

My second point is that base-building should be done away with completely. By “base-building”, I refer to the laborious process of building structures and upgrades in order to make more money and gain access to additional units. An original concept in the days of Dune and Warcraft, the base-building component has been copied by countless RTS games in the last 15 years. In fact, many designers probably see base-building as an integral part of any RTS and a permanent fixture in the genre. However, I argue that combat-oriented RTS games should not force players to play Sim-City within their game. Strategy is about moving around units, taking territory, and interacting with other factions. Why does the player need to also be a city-planner at the same time? Designers should let the player be a ‘commander’ as soon as the game starts.

One likely criticism of the no-base-building approach is that a single game would not last very long. In fact, a single game of Space War Commander can take anywhere from 10 to 20 minutes. However, what if a game takes 15 minutes to play instead of a whole hour? What’s so bad about that? Short games encourage players to replay maps that they lost because their time-investment was so small. They can jump back into the fun part right away, without having to build up a base from scratch a second time. A second advantage of bite-sized individual games is that they attract a wider audience, including people who may not be able to devote an hour or more at a time to a single game session. Finally, shorter games have that addictive “just one more game” appeal that an hour-long game simply can’t match.

A second possible criticism of removing base-building is that it could leave games shallow. In other words, if there is no base-building, then what is left? My answer is that what’s left is the good part! Instead of focusing time and energy into developing yet another economical infrastructure based on a building/upgrade hierarchy, game designers can delve deeper into the activities of individual units and the interactions between factions. In games with military settings, there should be no shortage of new gameplay experiences the player can partake in. Here are just a few of the things we implemented for players to do with their time in SWC:

• Save one enemy from destruction, so that it can harry an even bigger enemy.
• Cut off an enemy’s supplies, so that it has no money to buy new ships
• Run a blockade to get to a resource
• Set up an ambush to prevent an enemy convoy from finishing a big trade route.
• Lure one enemy into a place where it will be attacked by another
• Escort one’s own vulnerable Freighters
• Intercept dangerous bombers before they reach your base
• Carry out a long but lucrative 5-stop trade run with one Freighter while keeping oneself afloat with quick, little 2-stop trade runs by another Freighter.

It is important to note that all of these are emergent activities that can freely occur on any given map. The player is never forced to engage in them or somehow informed that one is desirable on a particular map. These are simply possibilities that exist within the game world. By presenting this list, I hope to convey the idea that removing base-building does not mean dumbing-down the game. There are a lot of interesting things to do in a strategy game, and in SWC we’ve only explored the tip of that iceberg. The complex environments of real-time strategy games offer countless opportunities for new activities, and we just need to free ourselves from the drudgery of base-building to see them.

Thought my list of activities is heavily based on military themes, there are plenty of new non-combat ideas out there as well. For example, a strategy game can make exploration and navigation a lot more interesting than just pushing units into a fog of war to dispel it. How about the need to collect map fragments and piece them together to find ways to get to places? Another idea is to explore personalities of units and have possible conflicts within one’s set of units that must be resolved. Imagine having to deal with a mutiny because certain units with rebellious personalities came across each other? As you can see, there are plenty of new military and non-military themes that real-time strategy games can explore as replacements for the city-management component.

Conclusion

Alex Kutsenok is the president of Dreamspike Studios, an independent game development company. He was the lead designer of Space War Commander, an original real-time strategy game. Prior to forming Dreamspike Studios, Alex conducted research in artificial intelligence at Michigan State University and also published a graphical role-playing game, The Quest. Direct questions or comments to alex@dreamspike.com.

The postmortem that follows is a reflective look at the development process, obstacles and successes for a game project undertaken by a group of students at Bloomfield College. Located in Bloomfield, New Jersey, the college has run a very successful game development program for the past 4 years, and coordinates both programming and design tracks in a collaborative, experiential learning environment. It is built on long-standing programs in graphic arts, animation, digital video, multimedia, audio engineering, and computer information systems, and collaborates with other disciplines such as English, humanities, and the social sciences.

Students from both tracks come together during their final year to work on a substantial game project. The goal of the project is not necessarily to complete and entire game, but to create at least 15 minutes of highly polished and fun gameplay. Very often this results in a functional demo piece for larger game concepts, but can produce a complete game for smaller, more casual games. When they are done, the students should have a top-notch portfolio piece that they can hand to a potential employer that can be played for 5-10 minutes and that will showcase the specific skills of the student. They can say “I did X, Y, and Z on the game. What do you think?”

While the idea of creating a demo piece doesn’t sound like a serious project to some people, these are in the very least slices of a complete game, and require a significant amount of time and effort to complete. Just think of what it would take to create just one complete level of a game you’ve played recently. The typical project is a group of five people working for eleven months through 3-5 development cycles. And they have to deal with many of the same development obstacles experienced by professional developers. All while finishing up their final year of coursework, which often includes an intensive Internship as well. This culminating experience is a true test of the students’ abilities, and the projects have all been extremely impressive. This postmortem is from one the best groups to graduate from the program.

Tom Toynton
Assistant Professor of Game Development
Creative Arts & Technology Division
Bloomfield College
Bloomfield NJ, 07003
http://www.bloomfield.edu/about/
http://www.bloomfield.edu/cat/gamedev.asp

Introduction

Lori Cerchio, Producer

This was the first game for the Dark Utopia team and we all approached it with some fresh and new ideas. At our first design meeting in the summer of ‘07, there were several genres we had talked about. Making a Massively Multiplayer Online Game would be too much work in the little time we had and working in all 3D was too advanced and “hardcore” for us. Eventually, we decided on a 2D side-scroller action game, with some key elements in 3D. But it wasn’t always easy as pie to make and there were many things that went right and wrong.

There are five of us on the team: Thomas, the programmer, was in charge of coding and was basically the backbone to our game. He used a game engine already built so he had more time to work on the gameplay itself; Mario was the artist and he came up with the concepts and drew every background. He worked long hours and many days to get the right look and feel to each of the levels; Cory was the 3D modeler and was also in charge of the music and sound effects. He modeled the main character, along with the boss character, in 3D to give it some substance in the 2D world. He also created sound loops that play in the background of every level and the title screen; Josh was in charge of promoting our game and designed the plushies and t-shirts that we gave away; Then there is me, I was in charge of making sure everyone did their tasks on time so we weren’t behind on any of the work. I updated the production schedule and game design document every week that we met.

What Went Right

1. Artistic Feel

We knew that if anything changed throughout the programming or storyline, that the art of the project would drive us home. Mario did such a great job with the look and feel of the whole game that players wouldn’t need to know the storyline to finish the game. By just playing the game, you can tell the setting (medieval) and understand what kind of environment the main character, Percival, is in.

Throughout each level, the look and feel has been the same. It is still medieval but in some cases, with a variety of different backgrounds to it, such as a dungeon, towns square, and an eerie lake. To get this look, Mario had to do a lot of research. He researched online for medieval castles, weapons, people, landscapes, and even clothing. We tried to be as accurate as we could with the timeframe we had, making sure this wasn’t just a big “fantasy” game.

2. Clear Goals

There were many changes we had to make in order for us to get this game done on time. Not only did we need to have clear goals, but the adjustment of changes was key to finishing any aspect of the game. There were originally three different bosses and two different locations we took out of the game. There were many reasons for this; for one we felt like we wanted to polish up the three levels we had instead of making five levels that were sub-par. Secondly, we basically couldn’t finish all that work in the given amount of time we had. By having three polished locations and one final boss, we are excited to show it off, even if it is a demo for the larger version.

Since we did make a lot of changes to the game, the production schedule and Game Design Document had to be updated constantly. Even issues we didn’t take into account, such as marketing and the Behind-The-Scenes video (which can be found here, along with the game) were last minute. Originally, we were going to put a dream cinematic in the beginning of the game to help move the storyline. This got replaced by the Behind-The-Scenes video because it was a quick and easy project to do. The dream sequence would require a lot of 3D and art time taken away from the game, which we weren’t willing to sacrifice.

3. Presentation Display

One last hurrah before our game came to a complete finish was to decorate our presentation display in the art gallery for the final demo night. We had so much fun picking out decorations and what merchandise to hand out, at times we focused more on this than the actual game. Some of the merchandise such as the plushies, t-shirts, and swords we planned on handing out to people that have played our game. I also ordered some decorations to spice up the area by purchasing medieval decor for an old fashioned look. We took a lot of the game elements and added them into our space. Stand-ups of Percival, the hero and Astaroth, the demon lord, will be on each side of our display to give people a 3-D look of our game. If we had character costumes, which were mentioned, we would definitely have been the talk of the night.

Personally, out of everyone’s display, we had gone above and beyond the look and feel of the game and really made people feel like they were there in the medieval times. It might not sound like much but I will try my best to describe the display. Our section was in the corner of the room and we had two walls to work from. One wall was covered completely by a stone wall “look-alike” plastic covering. We needed this to cover up the existing white cement-looking wall on that side so instead of feeling like you are in a school, you are in a castle. On top of the stone wall covering, we added in big pictures of a dungeon door and windows. (Side note: I had purchased a medieval set of decorations so we put most of them on display.) Half of the other wall was covered by a big black sheet which displayed some pseudo-torches and our game’s t-shirt. The other half was blank (all white) and here is where we displayed our game posters and landscaped screen shot of the city’s background. Cattycornered between the two walls was a table with two computers on it. Our game was playable on one computer and our Behind-the-Scenes video was on the other. In-between, there was room to put our design document and art bible for people to browse. To top it off, we had two cardboard stand-ups on each side of our display, one of Astaroth and one of Percival.

What Went Wrong

1. Slow Start

We first met as a group in the summer of 2007 and thought we had made clear goals for ourselves. With many people not having time that summer to work on it, we initially started the game the following September. The start of the whole project was very slow, we figured we had enough time to get everything done. With this being my first project as a Producer, I set realistic goals in the beginning of the semester. I didn’t know anyone’s level of talent or how far they can be pushed. I put a lot of the work to be finished within the first semester, knowing that if nobody did their part then we would be in crunch time in the Spring. However, some aspects of the game I knew would have to wait until we were almost done in May (such as Marketing) and that things kept getting pushed back in the schedule.

Initially, I decided nothing can get pushed back for more than two weeks since we had a lot to do in a little amount of time. In the beginning of the Fall semester, things were working out as planned but soon after that in the January ’08 break, projects took longer to complete. We had a solid game to present for the mid-term in February but we wanted as much of our initial vision to be complete. Even though we had taken some levels out of the game, I am proud to show what we have accomplished for our final display back in May.

2. Not Enough Beta Time

During the Alpha stages of the game, we found a lot of glitches and issues that needed to be worked out before we could call it complete. The Production Schedule had testing scheduled in it but it slowly got replaced by more features getting placed into the game. Third parties rarely played our game and every time they did, we found more problems to fix. There weren’t enough players to test the game as I would have liked but it was enough to find and fix the glitches. Also, since the players’ testing time was limited due to class schedules, they couldn’t give in-depth feedback and only focused on the surface of the game.

3. Different Schedules

One of the major issues that our group faced is the scheduling of meetings. If it weren’t for our weekly meeting, we would rarely see each other and solely rely on online communication. With everyone doing internships and their commitments to other classes, weekends used a big chunk of time to work on the project. This is why the Production Schedule was crucial to our objective in finishing the game. I made it clear so that each member kept a close eye on it and they knew what needed to get done in what amount of time. Of course, there were times when members didn’t show up to our weekly meeting. This threw everyone off course because we each rely on one another and it would seem that week was a complete waste.

Occasionally, working outside of the classroom has also helped. For instance, we did a presentation for a local chapter gathering of the International Game Developers Association, showing them (professionals in the industry) our game and pitch. The feedback we got was phenomenal and has helped us improve our presentation and speeches. If we all weren’t there, I don’t think we would have done such a great job. Back when we presented the game at the meeting, it was pretty much a solid game that was almost finished. Looking back, there were a lot of changes I would have made regarding scheduling and input into the game but all in all, I love what we did and how it turned out.

The whole project took about a school year to complete. It started in September 2007 and we finalized everything May 2008. With five people in my group and that amount of time, I figured we would be able to get a lot more stuff completed. But one thing that really slowed down the development process was that everyone had other priorities and kept putting this game on the back burner. If we had to start over with the same resources and time, I would have pushed for a casual game. There practically is a guarantee that it will be completed and polished way before the deadline. But since I can’t turn back time, I hope this post mortem will help others making games so they can learn from our mistakes. It isn’t easy to develop a game but you can have fun doing it.

In our quest to find gems of game design wisdom in the vast mines of MAME, we've turned to the genre of wacky sports. There are a lot of sports games on MAME and we've played an embarrassing number of them. Most of them fall into the sim category, and most of them just aren't that interesting. The old sports sims aren't as realistic as modern sims, and their gameplay isn't as good as old titles from other genres. Furthermore, we don't play or watch any sports. In fact, even the rules are often a mystery to us.

Luckily, there's a genre for the people who don't know all the rules for managing a baseball goal or scoring a football point. That genre is wacky sports. As Mario Kart is to racing, these games are to the traditional ball sports. They are a fantastic example of how to take an established design and give it new life and broader appeal.

Before we go further, what's good about sports? They're one of the basic forms of play. They're an opportunity to play with other people, both competitively and cooperatively. In modern society, a tremendous number of rules, traditions, and a huge quantity of pomp and circumstance go with most professional sports. But at their core, it's about two sides competing for some goal.

The sim market for sports games is huge and successful. Madden is the prime example, but the inclusion of rules, rosters, and stats excludes a lot of people, including all the nerds reading and writing this article.

With that - on to our first game, Power Spikes 2.

Figure 2 - Power Spikes 2 knows how to sell games.

Wacky sports games change the setting of traditional sports for broader appeal, but it's not just a matter of taking a sim and reskinning it. Power Spikes 2 (1994 Video System Co.) is a perfect example of the failure of the reskin approach. It only changes the graphics, and the result is less than compelling.

A brief history lesson: Power Spikes (1991 Video System Co.) the original was a mediocre volley ball game without any real distinguishing characteristics or fun gameplay. Power Spikes 2 is exactly the same game with slightly tweaked controls and some optional flashy powered armor graphics. When we say optional, we mean there's a mode where you can play volleyball sans robot armor, and it's the same gameplay.

Power Spikes 2 does have a few things going for it. It has head to head multiplayer, which immediately adds a lot of potential fun. It has some stylin' future arenas to battle in. And no matter how pathetically the other team fails to make a point, your team always celebrates with a dance sequence. Even if you miss the serve and the ball falls straight to the ground, your opponent's team will celebrate with the same glee that they would give if they had made a well-timed spike.

Figure 3 - Failure to innovate.

Unfortunately, even these elements can't make up for the mediocrity that thoroughly pervades this game. The ball moves like it's filled with helium. Your gameplay options are very limited, distilled down to picking one of perhaps three maneuvers. And despite the fact that you can outfit your team in robotic future suits, they move the same speed, jump the same height, and do the same moves. Apparently, the armor is so heavy that jet thrusters are required to jump a normal height. What benefit does the armor provide? Is small arms fire a danger in the future sports arena?

Although Power Spikes 2 was disappointing, we ran across many more wacky sports games that were fun.

Figure 4 - In the future, buttons are scarce.

The first of these is Super Baseball 2020 (1991 SNK/Pallas, review here). Although SB2020 is, superficially, a reskinned baseball game, in contrast to Power Spikes 2 the developers run with the futuristic theme. Additionally, the basic game behind the theme is well done. Gameplay is straight up traditional baseball. You pitch, bat, toss the ball around, make runs, and so forth. But they add a few extra elements. First, if you hit someone with a pitch enough times, they're teleported away by a flying ambulance and replaced by a robot. You can do this an unlimited number of times, until the entire opposing team is made up of robot replacements.

Second, they modify the field slightly. Without going into too much detail, the home run zone is smaller, and most of the crowd is covered by glass so that a ball that would normally go over the wall rolls back into play. This works very well because you're still rewarded for hitting the ball further (in that you get more time to run until the ball rolls back into play), while home runs are even more rewarding because they're a bit more rare. These changes are subtle and well balanced.

Finally, as the game progresses, they add futuristic "crackers" to the field. "Crackers" would be known in our "modern" society as antipersonnel mines. What game wouldn't be better with arbitrary explosives? This element adds a lot of chaos and fun to fielding - in addition to running from point A to point B, you have to dodge bombs.

Figure 5 - These people are playing basketball.

Punk Shot (1990 Konami) takes the notion of wacky sports a little further. It is a basketball game, insofar as there are two hoops and you have to put the ball in one of them. From there, things get extreme, dude. For instance, there's no steal button. Instead, you have the option to punch, tackle, or pile drive your opponent. And what game wouldn't be better with arbitrary pile driving?

Each period takes place in a different level that has a unique set of NPCs and obstacles to keep things interesting. The obstacles are matched to the theme of the level; not only are there holes in the ground, crates overhead threatening to drop on you, and birds blocking the hoop, but you also risk catching fire and falling into the ocean!

Punk Shot is at its during best multiplayer matches. We played it co-op against the AI, and mainly got our asses handed to us. The AI is really cheap, but we were able to come up with some strategies that worked out pretty well - well enough to give us a comfortable victory in at least one period. To avoid having to spend a solid week "researching" this article, we ultimately had to cheat our way through the game, and discovered something interesting: there's nothing more to the game after the first match. The winning screen is the same as the losing screen except that the word "WINNER" is next to your dudes. No new bad guys or levels at all.

Figure 6 - Experiencing bitter defeat.

And this reveals the key to the game. Punk Shot is a game of pure competition. There's just one three-part level, but the game remains highly replayable. Why? By finding new (human) opponents and developing new strategies within the already-familiar framework of the game . This concept plays out in all multiplayer games to one degree or another. Having a regulation-size field or a standard multiplayer map like de_dust keeps the focus on the gameplay, not on the content. With a fixed, unchanging world, everyone's attention is on the strategy and the interaction between players.

Figure 7 - A semblance of football.

Pig Skin 621 AD (1990 Midway) is a great game by Konami competitor Midway, and the wackiest of the games we've discussed so far. The "Pig Skin" in the title is there to communicate that you will be carrying a football-like object towards an end zone. The game is strictly competitive, with just two levels: a grassy playing field and an in-door arena littered with medieval crap, one for each half. Within these arenas, two teams of burly men fight to score the most points.

The basic controls are very much like your run of the mill football game - you can pass, tackle, or change plays. Punching is another, non-standard option. But the contents of the game world are really what make this game stand out. Every level is full of obstacles that will get in the way of making a goal by making you trip, slip, or generally lose control of the ball. This adds a bit more complexity - which is good because, let's face it, a football field is boring! It's literally just a field with lines on it! Add some stumps and mud puddles and trap doors and statues of chicks and you really have something.

The obstacles add interest because they affect both teams equally. Planning your route to the goal is vital to success. They also make it easier to catch someone who has broken away, because there are good odds that that person will run into something before they make the goal. This maintains hope for the loser, keeping the game fun for everyone.

Figure 8 - Hiring Halberd Guy.

This is taken further with the NPCs that are brought out over the course of the game. If one side falls behind, they're given an additional teammate to keep things competitive. The first helper is a guy with a halberd who's not that much help. He's just an extra obstacle that favors one team. But the next team to fall behind gets to "SEND IN THE TROLL!" Trolls are awesome - big, fast and green. The crowd cheers for them, and so did we. As the balance of points favors one team or another, more trolls are dispensed to keep competition fierce throughout each match.

Figure 9 - Send in the troll!

These two factors - the obstacles and the NPCs - work very well. They fit the theme of the game, and provide crucial balancing forces. For a multiplayer game, the risk is that one guy is going to be massively better than the other and as a result the game won't be fun for either player. At a certain point it stops being fun to beat on newbies. Bringing out the troll is a hilarious and effective way to bring balance to the game.

This is a technique that's seen play in other games, most notably a certain racing game. Mario Kart applies a similar technique, in the form of the blue shell. To a lesser extent, the weighted items distribution - where players in the back of the pack get better stuff than the guys in first - works the same way. It can be cheap, but it keeps the pack tight and the game fun.

Figure 10 - Experiencing sweet victory. (See fig. 6)

Computer games have complete freedom to do anything you, the developer, can implement. Many things that are impossible in real life become easy, and things that are easy in real life become very difficult indeed.

Sports are especially well suited for this because they're a frame of reference everyone on your continent is familiar with. It's like a starter set for your game design. But while replicating a real life sport exactly has some plusses, we think better and more accessible games are to be had using a sport as a jumping off point and going in a unique, digital-only direction with it. Once you stop trying to make a sim, you can start addressing the gameplay problems that lead to a negative player experience. For instance, because players can't die in the game, a lot of rules dedicated to keeping players safe can be discarded.

Keep these points in mind if you decide to enter the wonderful world of wacky sports:

• Wackiness can't just be a veneer. Power Spikes 2 shows us that if you're going to put your volleyball players in mechs, there had better be a big shift in gameplay. Players want a believable world.
• You have to run with your theme. Believability means that if everyone is running around in tanks (or power armor), the stakes had better be a lot higher than they when both teams are in short shorts.
• Stick with a framework people know. Punk Shot is a great game, but it wouldn't be nearly as appealing if it weren't based on basketball. Because we already know the basics of the sport, the designer could add a lot of additional complexity without overwhelming anyone.
• Multiplayer games need good gameplay, not lots of content. Look at Team Fortress 2. Look at Counter Strike. Look at Super Baseball or Punk Shot or Pig Skin 621 AD. All are fun. (OK, maybe TF2 is a little better than decade old arcade games. ;) None of them have more than five levels that people frequently play. Get some content, make sure it's good, then refine the heck out of your gameplay.
• Keep hope alive. Setbacks should be temporary. One player should never be able to put another player in a situation where they're screwed, but have to keep playing. Ever been juggled for five minutes by an expert Tekken player? That's what I'm talking about.
• Balancing forces can be good. Trolls, blue shells, and obstacles all serve to minimize the difference between the best and the worst players. If you're looking for dominance, this can be frustrating. But if you want a fun game - keeping victory challenging for everyone, and within reach for everyone, is a good idea.

Well, that's all we've got. We hope you find this useful! And remember to check out our last article on learning from MAME games if you want dig up your own game design gems.

Ben Garney and Eric Hartman are both unemployed. Ben Garney (coderhump.com) spent the last five years at GarageGames working as the Torque Technologies Director. Eric Hartman (badspot.us) develops Blockland in his spare time, which is copious.

Developer: RAS Ltd.
Initial Funder: Iranian High-Tech Industries Center
Project Status: Unfinished due to lack of continued funding

It is never easy to write a post-mortem, especially not when it is for a cancelled project. The fact that you cannot play a final version of your game after almost two years of hard work, even if it is just for reasons of nostalgia, is heart-breaking. Writing about what went right is easy, but we learned a lot more from what went wrong, and so I have decided to publish this document, in the hopes that it will be useful for all aspiring developers out there.

Before I begin to talk about the pitfalls and the lucky strikes of our development process I would like to introduce our game and some of the unique circumstances it was created under. Five years ago I and a number of my freshly-graduated friends interested in game development started fleshing out a game project proposal (basically an extended pitch) for an RPG set in the ancient epic mythology and poetry of the “Shahnameh” (also known as “The Epic of the Kings”) and the Zarathustrian Religion. As we resided in Iran, a country where game publishing companies and even development houses were unheard of, we decided to pitch our idea to private investors and governmental agencies (mainly in the culture and IT sectors).

Well… after we got no positive answers during the next year, we parted ways, and each went off to earn some badly-needed cash. We kept our contacts alive though. Having worked in a manufacturing plant as a control systems engineer (I do have some “real” education as an electrical engineer you know! It’s not just all games!) and in oilfields and on oil-rigs in the Persian Gulf, I was informed that a governmental agency would fund our project. I decided to leave my *real* job and start with our game project.

The original project budget we had estimated was around 350K USD (which is quite low due to lower wages here), but government agencies are king when it comes to budget cuts, and we could only secure 110K USD (Just consider that Iran has had an annual inflation rate of almost 20% for the past few years!). As a result, many game features had to be cut; a painful decision indeed. With our tight budget, we figured that we will need a tight team, picked from the best of their respective creeds, on a tight schedule. Writing the world back-story (50 pages), main storyline (70 pages) and preparing concept sketches with our newly-hired Lead Artist took about 3 months. During this time, I acted as the designer and preliminary producer because I am the kind of person who knows a wee bit of everything (mythology, writing, game design, 3D and 2D graphics and art, programming, etc) and I shared project management and financial responsibilities with a friend (we were only 3 on the team and it was easy at the time). Once the money flowed in, we hired two artists, a 3D graphics programmer and our support staff.

Following an initial period of researching available technologies, we decided to go for a .NET implementation based on the open-source IrrLicht engine coded in C#. The engine would require a heavy overhaul, but that wasn’t a strategic problem: our programmer was confident of knowing the ins and outs of IrrLicht, which is a very clean and neat little graphics engine by the way. 3D Models and animations were to be created in 3DS Max and ZBrush, and 2D art was mainly done in Photoshop. Within another few months, a team of ten wildly enthusiastic people were working on the title which we had named “Age of Pehlivans” (“Pehlivan” is the Persian word for hero). Everyone was absolutely sure that we would create a revolution in game development in our country (Ok! There really wasn’t anything going on that was supposed to be revolutionized at the time, but you get my meaning). Those were good times of hard work, brilliant ideas for workarounds, and late-night CoD tournaments, but all good things have come to an end, sometimes too soon.

What went right

Quite early on we noticed that 2D concept art can be outsourced efficiently, at low costs and with great quality. The concept artwork for our game was stunning, well, at least to us. Artists can do great things from a corner in their bedrooms once they are briefed about the back-story and character descriptions. The same goes for sound production and dialogs. Outsourcing sound and voice assets to an established director (in the animation or movie industries) can create great results, and it turns out that many voice-over artists owe directors favors and will provide their services at minimum cost.

Our decision to create a small team of highly-skilled and intelligent developers must be the reason we could actually get on with the work. Professionals in the game development area are non-existent in Iran, but looking back at what my comrades achieved with so little funding still astonishes me. Our team “gelled” and it was a lot of fun watching them at work.

One situation we were extremely afraid of was that the government agency we had been funded by would cut the funds at any stage, due to their lack of understanding of the game development process (i.e. you get to see very little functionality in the beginning.) Much to our delight, however, we could impress them with our concept art and technical confidence (which they were probably mistaking for competence ;) ), at least in the beginning. The fact that they had little knowledge of games and weren’t keen on meddling helped the money flow, and yet the lack of oversight caused thereby, might have hurt the project, as none of us were really adept at game development management. Lesson learned: Lack of managerial oversight from your funder/publisher is only positive if you are an experienced and very professional developer.

Another thing that went right was our choice to use an open-source graphics engine. It allowed us to develop extremely user-friendly level and model editors (I have yet to see a level editor accompanying any commercial game that is as easy to use as ours) and create levels efficiently. The other tools we created, such as our event-based story editor and our rule editor were little fiascos of their own, but we shall revisit that subject later. We also added any and all shaders and post-effects we liked, and at any given moment we were able to extend our tools to do whatever we wanted them to do: a designer’s dream! There were many other things that went right…but let me depart here…and move to the painful part of this writing.

What went wrong: Programming

1. Right from the beginning, and mainly due to financial limitations, we had employed too few programmers, who were dividing their time among far too many tasks. We had one 3D programmer who was handling the engine code and all the tools, along with the game mechanics, level loading, etc. Another was coding the GUI and event scripts, and our lead programmer was making sure everything is on track and was doing high-level code architecture design and maintenance. The work load on our 3D programmer was too high, and deadlines were often not met as a result.
2. User interface art was developed very late into the project (the last few months) and placeholders are simply not good enough to give you a feel for the shortcomings of the interface. We should have iterated the GUI design, but we didn’t.
3. As our environment was very “outdoorsy” we had created over 80 types of grass, bushes, trees and shrubs. We couldn’t afford fancy tools like SpeedTreeRT, and we had to create, place/paint and performance tune all of that stuff by hand. This started to turn into a major challenge on our level which was almost 10 SqKm large. In hindsight I believe we could have found an easy way to place all the flora with automated code.
4. We started with the LoD (Level of Detail) and scene management optimization very late into the project. That made our engine and development tools unwieldy once the level started to get populated. (We don’t have access to dual quad-core machines with quad SLI graphics in Iran you know!) IrrLicht is in no way optimized for a huge level, and we had left major optimization for later stages. A big mistake…one that we came to regret once we started serious work on the level with our WYSIWYG editor which had to handle all that the engine was fed and then some! On a different note…maybe we should have kept our levels simpler. ;)
5. Particle effects programming was a LOT more important than we had thought initially. Particles were badly underused compared to meshes in our levels. And while our graphic cards were burning hot, the average CPU was happily running at 50%. Once we recognized what a few strategically placed particle effects can do to add some magic to our level, we were already in the dreaded crunch mode.
6. We animated the full cycles of movement and combat for every character. If we had come up with a clever way to use generic code to control some of the behavior of the character bones, we might have saved ourselves a lot of head-ache, and the transitions between animations might have been tighter and smoother.
7. Save/load functions should have been available in the game right from the beginning. Although it is hard to maintain those functions in-sync with data structures that are changing from one day to another, we still should have done it. Our game was compile-able and playable at the end of every day, and yet the save/load capability was missing until testing really started. This was a major cause of problems, as we could not check every asset we inserted along the way, simply because it took too long to get to that point in the game (and yes, we did have development cheats, but that was not enough, and overuse of cheats has a way of not letting you see the real problems!).
8. Our event-based story editor was a huge messy business. Setting zillions of events and commands in a user-unfriendly environment is the last thing a designer wants to do, and it was indeed the last I did, with terrible results. In hindsight, we really should have hired another designer who knew some easily integrate-able LUA or Python. Visual mapping of the game events and story would have been another way to go, but we simply had too few programmers, and were tight on the budget.
9. This might sound controversial, but I believe that our game rules should have been hard-coded from the start, instead of wasting time on trying out all kinds of hand-made semi-scripting tools. Because the rules didn’t really change much, and because there weren’t too many of them (and we weren’t going to re-use them anyways) we should have simply hard coded them (which we did in the end, and with good results).
10. Our initial design called for a huge city in the middle of the map. The result: hundreds of thousands of polygons on the screen, and so many objects, that even our most aggressive culling routines seemed not to be making a difference. The GPU was badly overloaded. This could have been avoided if we had just changed that design decision early on. A lot of painful optimization could have been circumvented in this way, at least in the beginning of the project cycle, when programming resources were so tight. This might be seen as a design problem, and it is one, but it also affected the programming cycle in a negative way…which brings us to the next part…

What went wrong: Design

1. I said earlier that I started out on the project as the designer and producer. In the beginning it made sense to do both jobs, because we were a tiny team, and because the number of produced assets was small. The original planning called for a full-time producer a few months into the project. But then something nasty happened. Something that we should have foreseen: An exception turned into a rule: funding came 3 months late! We had no money but that which we paid our team with. We started taking out loans to keep things going…and in the midst of this, we forgot to hire the producer! We figured we could do it a bit later, but by then, production had tuned into a full-time job for me and the design was lacking the attention it required. Disaster struck a few months later, when we actually did bring in a producer: the assets were so many and so varied, that the producer simply couldn’t handle the hand-over. He was stuck with zillions of files and formats he wasn’t familiar with, and I was stuck with micro managing every single asset. Game production can do wonders for your memory you know! At some point I was able to quote the exact computer and folder where the last version of a file was located from among 40000+ files. In my case, more memory simply meant less brains and creativity, which was poison for my design tasks. You see…producers are meant to be extremely un-flexible. They must set standards…rules… Designers on the other hand need to be extremely flexible, always ready to cast out their beloved design features and replace them for more *fun* ones. For a big project, a designer-producer simply isn’t feasible, or…at least I wasn’t.
2. Another major problem I faced as the designer was the scope of our project. RPG’s are among the more cumbersome projects to handle. Gamers want them to be huge and beautiful and varied…and so do the designers (who are avid gamers more often than not). You might question our sanity when considering our budget (110k USD), that we even went for an RPG…and you might be right. I have no rationale to offer for our decision, except that “We wanted to do it with our hearts and souls, because we all loved RPG games!” However, even with an RPG, the scope of the project still could have been reduced. This kind of feature-pruning should really happen in the first half of the development cycle, but we lost sight of the scope early on, and the pruning process reared its nasty head during crunch-time! A developer under pressure, forced to cut a feature they have come to love is not a nice sight. He cries and writhes and shouts and curses…Strangely enough, now that I think about it, those moments of destitute were the ones that brought everyone on our team closer to each other like no success ever could. We went through the pain together…great moments for all of us.
3. OK, I am drifting off…this document was meant not meant to turn into a cheap drama script! One thing we noticed, unfortunately too late, was the fact that for our RPG game, side quests which were loosely tied to the main quest could have been very easy to execute. There were almost none of these types of quests. The world could have used a lot more open-endedness and simple side-quests (e.g. one to three level side quests, meaning one to three visits to various NPC’s/Locations are enough to solve the side-quest). Most of our efforts were spent on fleshing out the main quest, and that restricted the player a lot.
4. This might sound as if I have joined the “Tolkien-esque” school of RPG design, but IMHO our game should have featured more mini-levels, dungeons, caves and teleports to weird locations. Dungeons are fun to play, and can be a good excuse for rewarding the player with lots of goodies. The fact that dungeons can be created as tiny sub-levels helps the artists, and level-designers to be more focused when working on them. It helps with the frame-rate, as features can be distributed in many smaller levels and locations instead of just one huge map. It also could have solved our “huge-city” problem, which I mentioned earlier.
5. Initially, our story called for 50 unique NPC’s, 20 generic characters and around 15 beasts. Late into the game I started to think we could have distributed our resources for better re-playability and more fun. 25 unique NPC’s, 25 generic characters and 35 types of beasts would have been the way to go, and it wouldn’t have cost us a dime more. Unique NPC’s have to be modeled, animated, voiced-over, etc…and they cannot be re-used too often, while beasts can be lots of fun to kill. You might argue that the latest RPG’s have hundreds of unique NPC’s, and you would be right, except for the fact that our budget was only a tiny fraction of theirs.

   
   Aop Sample Screenshot: There were probably too many
   unique characters in the game (as compared to beasts)

6. Communication problems within the team are a standard complaint in post-mortems. Well, here is one variation you probably haven’t encountered before: one of our problems was that I wrote all the design documents in English, assuming that any gamer/developer, even in Iran, would probably know some English, or be willing to learn English really fast! That didn’t turn out to be true, and although I tried to make sure the team understood all the technical details they needed, a few did not understand nearly as much as they pretended to. It was shocking to find out at the end of the project that one of our artists had created great environment art without having understood a single word of our back-story. A great indicator of his brilliance, and my false assumption indeed!

What went wrong: Visual Arts

1. Our Lead Artist, although great at creating concept art, lacked technical knowledge of programming and the 3D asset creation pipeline. Unfortunately, at the time it was near-impossible to find an artist who has the necessary leadership skills, along with creative ability and technical knowledge required for game development so we had to make a compromise. Although our 3D artists were tech-savvy, the lack of leadership in the art department could still be felt. Maybe it would have been better to divide the role of the lead artist into those of a lead 2D artist and a technical art director. Unfortunately, we will never find out if that would have worked
2. Because all of our 3D assets and animations were created in 3DS Max, we were in dire need of a good .X exporter. That is hard to come by in the freeware market, and we didn’t possess the resources to code our own exporters. That led to time consuming tweaking and multiple trials for each exported object/animation. What we could have done to alleviate the problem was to put strict restrictions and export rules in place before starting the work, but those were developed later, when a lot of time had been wasted already.
   
   AoP Sample Screenshot, You might not notice it in this
   screenshot, but those two characters actually shambled with the same gait.
   That looked horrible!
3. One way to lower a game budget is to re-use models and textures. If done cleverly, this not only doesn’t reduce the appeal of the game, but surprisingly gives it a unified look and feel. This is a lesson we learned too late in the production cycle, when many redundant models and textures had been created already. Those strained the graphics memory and wasted many artist-man-hours. On the other hand, I must admit that we did try to re-use some of the animations, which turned out looking disastrous. When a beautiful queen NPC of ours started to lurch around like a dazed thief we knew that enough was enough! As much as we liked it to happen, reuse of animation was almost impossible except for the most generic of characters

What went wrong: Production

• Managers’ lack of experience and oversight on the development process, allowing for and not catching any of the development mistakes of the other teams, which also led to a lack of management credibility.
• Managers’ lack of knowledge about the game development process also led to their inability to break down the project into meaningful, fixed and tangible pieces of work (mini-milestones), in part, leading to disorientation, loss of motivation and delays.
• Project time was first set at an unrealistic 12 months and then extended again and again to 20 months. This led to skipping many real problems, and redoing a lot of work at later times (sometimes it was simply too late!). Rescheduling wastes a lot of time!
• Lack of regular progress reports, schedule sheet updating and too few progress meetings left everyone wondering where the project priorities and problems were, effectively disabling them to catch problems before they showed up.
• Website/Boxing/Advertising art development should have been outsourced entirely, saving the internal team valuable time in the last months of development.
• Miscellaneous mini-projects not related directly to our game during development, in addition to adding over two months to our development time, left the team disoriented and led to a lot of recovery down-time. These projects included pitches for future games, technology demos, and art books that were only meant to showcase the capabilities of our artists to possible future investors.
• Mainly due to lack of funding, staffing was messy, inadequate and bad at best, leading to constant extended development time and schedule shifts.
• Lack of ability to provide a good development infrastructure (Rooms, network, data security and availability, standards, internet connectivity, air conditioning, cleaning, etc.)
• Bad time management for team members, allowing for some extreme overtimes (sometimes with no additional pay), while others were having extreme under-times. This contributed to demotivation of the team at the end of the project.
• Different payment methods (hourly, fixed minimum, fixed pay) which did not address team member productivity in any justifiable way.

• Marketing and capitalization efforts for the game were not focused and directed, resulting in a total deadlock in both marketing AND capitalization. This was the main managerial failure which put the lid on the coffin for this project.

Conclusion

So what really happened? Why did the project not get funded? That is an issue I could discuss for many pages, but the gist is that we learned that governmental funding in a third developing country is not something you can really count on to run a dynamic project such as game development. This kind of project needs investors with know-how, and a passion to protect their investment. Government employees are famous for not possessing any of those factors. The delays caused by untimely payments, and the compounding of all our own mistakes, didn’t help in the process either. Then there was the problem of copyrights too…see…in Iran there are no copyright laws, nor is there any enforcement of IP rights, therefore it is near impossible to get a return on investment for a computer game (that was one reason we opted for governmental support in the first place). Long story short: the project was cancelled, because our own company couldn’t take the risk of losses.

Concluding, I must admit that many mistakes were made, and I am definitely responsible for some of them, but writing a post-mortem seems to be the best thing you can do in order to unwind after a taxing project. If anything, it is an attempt to raise everyone on the team to a higher standard of work and professionalism. The recent years have been dark years for the budding game industry in Iran. With all the political games surrounding Iran, and all the sanctions against it, the priorities have shifted from technology and entertainment towards military applications. Sadly, this is foretelling the demise of many start-up companies in this field, but there will always be an enthusiastic few who will try to build a world of their own, with thousands of lines of code and many great artistic ideas.

Creating a computer game is a great project to learn life-skills in and develop a professional attitude towards work, be it programming, art or management, and I have found that those who seriously invest their time in creating games are some of the most interesting people in our to hang around with. I hope this post-mortem was useful, and I hope that my next post-mortem (believe me…there will be more!) will end in a more up-beat tone.

My best wishes for your projects,

Babak.

P.S. I will put a more detailed post-mortem up on my website during the next month or so…( www dot gamedesignideas dot com ). If you are interested you might want to visit.

Figure 1 - King Of Fighters '99 teaches an
important lesson about family planning.

So you downloaded MAME and purchased licenses to every ROM for it. Now you have three thousand games, give or take a thousand. Infinite fun, right? Not exactly, but you do have access to a resource for learning some valuable lessons about game design.

Try playing through a set of games. For instance, all the ones in a given genre (brawler, fighter, puzzle, etc.) or all the games released in a given decade. This may take some time since there's an average of a hundred games in each genre. Go on - give it a try. We'll wait.

As you play, you may notice some patterns developing. For instance, many listed games are direct clones of others. Trimming these out may reduce the number of games to 2500 or so. Learning to spot direct clones will save you a lot of time and pain.

There are also variations of the same game - different ROM dumps, re-releases in different geographic regions, etc.

There are 47 (really - we counted!) different "Street Fighter 2" games , but by the time you weed out variants and direct clones, you get down to maybe five that have any discernable difference, and really only three that are worth playing.

Even once you've trimmed things down to this point, there are STILL a lot of games available under MAME. Still a good time, right?

Most arcade games are awful. In some cases this is because you're playing it without the input devices it came with. In others it's because the emulation isn't correct. The novelty of things moving on screen has worn off these days. And when you emulate, you have infinite money, so getting the most out of your quarter isn't a factor.

You already know most of the good arcade games. But there are some pearls of knowledge to be gleaned from the mountains of decades-old fetid oysters available in MAME.

If You Enter a Genre, Know The Norms

A brawler based on a comic book license. Could be good. Could be bad. Actually, it was both!

Spider-Man: The Videogame (Sega 1991) was a thoroughly mediocre brawler with platformer elements. There's not much here. You can't dash, you'll find a lack of weapons, and there's nothing to break that's full of VCRs, gems, or meat. It does have a pretty cool voice chip in it. There's a "trade health for super move" ability, but not much else.

Figure 2 - Remember that time when Spiderman beat up Shy Guys?

Oh, and you can put in more money at any time for more health. That's just the kiss of death to game play. Sorry, Gauntlet fans.

Hardware and graphics wise, Spidey is a solid game. Good art (because they licensed it from real artists), and great hardware - 416x226 display and 16k colors running on a 24MHz of combined CPU power. The sprites scale, move smoothly, and the world looks good.

The Punisher (Capcom 1993) is a much better game built on slightly worse hardware. It runs at 384x224 with 4096 colors, on only 20MHz of combined CPU power.

Figure 3 - In The Punisher, Kingpin is large enough you could hollow him out and use him as home. Awesome.

Capcom knows brawlers, and it really shows in Punisher. There's lots of stuff to smash, varied enemies and weapons you can pick up and use. There's meat hidden in almost everything, ready for you to eat to regain health. They make good use of The Punisher license to enable new gameplay - if enemies have guns, you can pull your own gun and blow them away. The second player can play as Nick Fury, super spy. The art is more clearly defined in The Punisher (see identical scenes above). On the left everyone is just chilling - maybe they're in a jazz club. On the right it's pretty clear that there's whuppin' about to go down.

The first room in Punisher is better than the first three levels of Spiderman combined. It's a bar room with a pool table and bags of money everywhere - which you can take with you. Inside the room are:

• Three chairs.
• A barrel, which contains a pizza you can get health from.
• Plants.
• An arcade machine with $1000 in cash inside it.

All of these things you can either pick up and beat people with, or just smash open with your fists.

What's the upshot from all this? What makes this more than just a case of bad design vs. good design?

Well, they didn't HAVE to design anything. All they had to do to make a pretty good game was copy what came before and change what they needed to make their game unique. It's not plagiarism to copy good design. No one gets sued for making round wheels.

Final Fight is the quintessential brawler, and Capcom released it in 1989. Final Fight defined the brawler. The concept of a brawler is you're a dude out to kick some ass, from left to right. In Final Fight, you could pick stuff up, break it on people, use it as a weapon, smash it open to get the delicious prizes inside. You could grab people, hurl them around, and there were different moves you could do to break up the monotony of punching.

So if you're going to release another game in that genre, you'd better have a good reason not to match the features that made the last one good. In Spiderman, it seems like they were just lazy - in the case of Final Fight, those features make the difference between an OK game and a great one. Spiderman is just OK.

But the Punisher pays attention to the lessons of Final Fight, and it shows.

Let's apply this to the modern gaming world. Consider Doom - the game that defined the FPS genre. Fast action, over-the-top violence, and solid game play. Frequently claustrophobic and very dark. Wildly enjoyable.

Serious Sam evolves the FPS genre by switching from maze-like levels to a linear progression of arenas and upping the enemy count by an order of magnitude. The developers stay true to their game's FPS roots by keeping the game play focused on mowing down hordes of bizarre enemies. It's clear that the developers understand the genre and are consciously choosing what to adopt and what to reject in making their game. And the game is still fun to play today.

Doom 3, however, is in the same boat as Spider-Man. When they designed Doom 3, it's as if they looked at Doom and said "hey, let's make a game like that." But the result is only similar in appearance. It misses the key game play elements - you spend basically zero time in clean confrontation with enemies; instead you get whacked in the back of the head by enemies you don't have a chance to see, and spend the rest of your time skulking around in pitch black corridors. Perhaps Doom 3 is a good example of another genre - but it's unclear what that would be, and its namesake (and perspective) condemns it to be a FPS .

If you're going to make a genre game, know the norms. Realize there's a precedent set by past games, and pick and choose what you're going to match, and where you're going to innovate. Where developers fail is when they enter a genre, but they don't build on what came before.

Business Model Does Affect Gameplay

The mechanism at work is this: as technology advances, it enables new kinds of games. These new games are cool, so people make them. The old business models often don't work with these new kinds of games. As a result, new business models are introduced to support them. The temptation of maximizing these new business models can pathologically affect game play design.

In the beginning, hardware wasn't advanced enough to have more than one screen worth of game. As a result, successful games optimized for a compelling one-shot experience that you would want to do again and again from the start. The business model leveraged this - it cost one token to play the game once. Pac-man, Asteroids, and Robotron are all good examples of this approach - they take very limited art resources and build rich, infinitely repeatable gameplay.

Figure 4 - Note there are more bullets on the screen in DonPachi than there are enemies on screen in Galaxian. 1942 forms a pleasant middle ground.

Galaxian (Namco 1979) is a classic, single-token-per-play shoot 'em up. When your game is over, you restart from the beginning. Although there are multiple levels, they're all just repeats of the first one at increased difficulty.

As technology advanced, it was possible to put more content into games. 1942 (Capcom 1984) has 32 levels that you fly through; different levels have different enemies moving in different patterns. There's also a finite amount of game - once you clear the levels, you've won. When your game is over, you can put in another quarter to restart the level you died on.

This means it's possible to complete the game in a (long) arcade play session, and that each level has to remain defeatable on a single quarter, but that it's also possible to extract more money from the player. The limit on each level's difficulty means that gameplay is unaffected by the business model - it's still necessary that it be possible to defeat each level within three lives.

DonPachi (Atlus 1995) was one of the first manic shooters, which means that in some cases there are more bullets on screen than empty space. In DonPachi, you may continue whenever you die and when you continue, you reappear immediately with a full load of bombs. Because it's no longer necessary to beat a level within a finite number of lives, there's no built-in limit of difficulty - the game can be infinitely hard, and sometimes is, because you always have the option of pounding through enemies with an avalanche of quarters.

And this has parallels in nearly every other genre of arcade game.

We see similar feedback loops happening in the modern game industry. MMOs are subscription based because of the overhead of maintaining server farms. The subscription business model is optimized when people play as long as possible. Therefore, gameplay is stretched out, resulting in the infamous level grind.

Downloadable content has recently become practical, and many games are already taking advantage of it. Micro transactions are one business model being developed to support this new content type and we can see its potential to affect design. There is rampant speculation about portions of games being held back so they can be sold via microtransactions later, like the horse armor in Oblivion. There are also more legitimate examples of being able to buy additional content, like the level expansion packs in Halo. We can also see microtransactions' effect in MMOs and web-based games, where, sometimes unofficially, you can short circuit your advancement by purchasing game items for real cash.

Will microtransactions cause a slump in the PC and console industries comparable to the mid 90s arcade slump? Only time will tell.

Gradation Of Skill

How do you differentiate skill when you can buy life with a quarter? Have the game recognize when you do something awesome.

An example - the POWs in Metal Slug 2 (SNK 1998). As long as you stay alive, POWs you've rescued will accumulate. At the end of the level, you're rewarded with a list of the names of the POWs you saved, as well as bonus points. There is also a combo effect at work here - getting all of the POWs is worth much more than getting most of them. Completing the level while still in a vehicle is an even bigger bonus. The game rewards 100% success much more than it does 99% success, and this is the motivation to replay the game until it is fully mastered.

Figure 5 - Two different ways of rewarding skill.

A more subtle example is the music in Gradius 3 (Konami 1989). Whenever you die, the music restarts. As a result, only the truly masterful player gets to experience the entire song - less talented players are stuck with just the first few bars because they're always dying.

The gradated approach is a win on both ends of the skill spectrum. Beginners can experience and enjoy the game without having to contend with a steep skill curve. Experts have a way to differentiate themselves from the rest, and long-term goals to strive for that encourage repeat play. In either case, they're putting lots of quarters in the machine, so the game developer is happy, too.

Good Controls Are Always Worthwhile

June 1987. The arcade industry had recovered from a slump early in the decade. Atari was one of the top game companies. Out Run, Sky Shark, and Roadblasters are taking in quarters like mad. Rampage, Gauntlet, and Super Mario have all been out in the market for a few years.

Also released this year in Japan was Wonder Momo (Namco 1987). You're a Japanese magical girl. You fight things on stage and transform. Standard fare. Unfortunately, the controls bar you from enjoying the game. It's just unresponsive. This is especially bad since Mario has been out on the market for years. At this point in history, the problem of running around and jumping has been solved by mankind.

Figure 7 - Good ideas, bad execution.

Dragon Buster (Namco 1985), which predated Zelda 2 by a solid year, had the potential to be a true classic. It had tons of innovative features, like magic spells, one of the first life bars, branching levels, an overworld map, and even different moves like double jumping, downthrusts, and more. But its movement model suffers from poor transitions between walking and jumping, weird speed-related glitches, and no air control - which is especially bad because you frequently get juggled by enemies. The game is actually pretty good, but you have to overlook the fact that moving is pure pain. Although it's been ported a few times (most recently to the PSP), it never enjoyed the fame it deserved.

How do you make a game with compelling controls? The best approach is to make the most out of as little as possible. The Punisher, like many brawlers, has only a directional input and two buttons, yet there are upwards of a dozen moves you can execute. Almost every combination of input results in something different happening. And all this is pretty intuitive.

Contrast this with any arcade fighting game, which will have on average six buttons, and in which to do anything you have to combine one to three button presses with a series of directional moves. To actually be any good, you have to memorize lists of coded moves - which aren't displayed in the game and have to be learned from peers or magazines. And on top of this, really you only want to ever do like five different moves - fewer moves than there are buttons!

If you're going to add depth to a game, do it by making full use of a small number of inputs rather than adding more. Games like Dragon Buster and Wonder Momo had good concepts, but failed to execute on the basics, which cost them in the marketplace. Games like Final Fight, Punisher, and Outfoxies succeed because they respond well to basic input and make good use of the different combinations of those inputs.

Conclusion

MAME is an incredible opportunity for any budding game designer to really study their craft. Just the experience of playing through a bunch of games to find a fun one can be highly educational (as this article demonstrates).

What rewards are there for those who can stomach playing through hundreds of stinkers (and the odd pornographic Mah-Jongg game) to find the few bits of wheat amongst the chaff? They will gain an encyclopedic knowledge of the arcade industry, the ability to answer their own questions about game design with hard facts, and insights into the longevity of novelty.

Figure 8 - The credits from Zombie Raid. Why is this guy called Meat Bacon Apple?