Round Table Topic
When I was coming up with a topic for this round table, I realized that I quickly went back to thinking about all of the games I have been playing over the last few weeks: Spider-Man: Web of Shadows, Red Faction: Guerrilla, Infamous, Prototype, and Skate 2. All of these games have a unique approach to how they tell a story, introducing gameplay elements, and the handling of progression through the game. It’s strange to see so many similarities between some general mechanics between these games, but to see each one handle certain components so completely differently.
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:
The most prominent issue in this round table was related to the design and consumption of open-world games and how fine a line is drawn between too open and overwhelming players and being too linear and not allowing for much free progression. This is really the heart of the problems inherent with designs which hinge on open worlds. How do we, as designers, create a gameplay experience which allows players to essentially design their own experiences through gameplay without allowing them to unintentionally create poor experiences for themselves? Aaron Miller’s superb post covers this problem:
[…] 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.
Aaron raises a number of great points in this; my favorite of which is the notion of players essentially “earning” their experience and it being more worthwhile for the effort that they put into it. There is never a single situation where we, as designers, ever want our players to have a bad gameplay experience. This is not something that I personally consider to even be a possible debate; there is simply no reason for a given game design to even allow for players to come away with a negative gameplay experience because a certain format enforced certain inputs. I’m actually kind of disappointed that more of the contributions that followed in this Round Table didn’t seem to pick up on or build upon aspects of Aaron’s post. The open-world format seems to be an ideal situation for a design focused on emergent gameplay, but given the combination of these two factors the possibility of allowing for negative gameplay experience is almost inevitable.
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.
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 (!).
Everyone likes candy. Diabetics or people on a strict diet may nay-say such a statement but, for the rest of us, a bit of candy here and there is a little treat composed solely of sugar and happiness. Achievements in video games are similar class to a piece of candy. Players can gain achievements for beating a level in a normal progression of the game, beating a hard boss without using certain items, completing an entire play-through of a game without dying, or, in the case of the recently released Mega Man 9, beating the entirety of the game five times within twenty-four hours. Once these achievements are earned, gamers can wear them as a nerdy badge of honor for others to gaze in awe upon. Or something. When done correctly, achievements are a source of positive reinforcement that encourage forms of player behavior or, better still, can foster an entire metagame with the potential to drastically increase the amount of time players can get out of a single game.
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)?
It is often a habit for young gamers — or those who simply don’t buy many video games and get a abnormal amount of play-time out of a single game — to set arbitrary goals for themselves to increase the value that is extracted from their games. Can I do this whole level without dying once? Can I do this whole game without dying? Can I beat this racing game using the worst car available?
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).
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
I am not sure how I feel about this. First, though, I’m going to attempt to categorize/generalize the kinds of achievements I’ve seen in most of the games I’ve played. This is not a formal list, and one I’m coming up with in an off-the-cuff manner (as a response to the above post), so it’s by no means a definitive list, but here we go:
And, riffing off of this list, most games that I’ve played on the Xbox 360 — a system which has a very strictly adhered-to policy when it comes to achievements — mix up their achievements across a number of these various categories. Typically, a game will give somewhere in the range of 30-40% of its achievements to players who manage to play through the entirety of a given single-player game and leave the rest of the achievements to those players who want to endure certain challenges or master the multiplayer arena.
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).
And Mark Kalvelage wrote a good counter-argument to the one I expressed in the introduction to this Game Design Round Table regarding the Halo 3 sword-based achievement:
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.
One of the first contributions of the thread came from Josh Petrie at ArenaNET and covers a very interesting perspective on multiplayer-focused achievements aside from condoning a certain, perhaps undesirable (or desirable) play-style:
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.
Aaron Miller wrote a succinct, well-worded post about the benefit of achievements as a means of commemorating designer-anticipated “cool moments” in gameplay:
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.
Ben Medler has a very insightful take on achievements that I, and others in the industry, have discussed before: does the institution of achievements actually diminish the experience and creativity of players? Are players less imaginative in ways to play through a game as a result of achievements than they would have been otherwise?
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?
Taking the discussion in another direction, Simon Ferrari makes a return to the thread to talk more about the excellent example of Call of Duty 4 which ties a number of its challenges (most of which are not Xbox-live recognized achievements) to gameplay and the game’s persistent character development:
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).
To close out this Game Design Round Table, Kelly Helfenstein recounts the days when he instituted ad hoc achievements to enrich his playing of games that were already familiar to him. This is, likely, the impetus for the creation of a standard, persistent achievement system in the first place, and the most important aspect of achievements to keep in mind when designing them for your own games.
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.
Thanks for another great thread of discussions guys (and I am really thinking about relenting on my choice to not partake in these while they occur). If this edition of the Game Design Round Table interested you, check out the actual thread. I have some craziness with starting a new job and moving to Salt Lake City going on over the next few weeks, but hopefully the next Game Design Round Table will be posted in three-four weeks time.
There has been a slow and steady progression of the role that death plays in video games since the days of Ghouls and Ghosts and Super Mario Bros. No longer are most games tied to the old tenet of providing a player with an arbitrary number of lives, typically three for some reason, before the player is sent back to a previous spot in the game. This was a particularly brutal practice back in days of arcade games (which the aforementioned Ghouls and Ghosts and Super Mario Bros. were no doubt influenced by) where the goal is to punish the player and, more to the point, convince the player to insert an additional quarter or so. There were also extra lives given to players along the way to sort of feed the mini-addiction that these arcade-inspired games needed to feed in order to get players to cough up more change.
This practice has persisted in the industry for ages to the point where designers still treat death and the process of player punishment much the same as we have for ages. Game developers and designers have largely abolished the system of giving players a finite number of tries or lives in a game, but so many games still cling to the concept of a player having a “life” to work with. This approach to handling the mortality or failure cases for the player can often lead to frustration (oh hey look at that) and that, for most titles, is not a desirable trait to aim for. There will always be the occasional Ninja Gaiden that will be released where designers very intentionally challenge player’s skills. These kinds of games rely on a failure case as a means of reinforcing the lack of player skill or, alternatively, enforcing a certain in-game aptitude.
There have been a handful of recent AAA games which attempt to make death less deadly. One of which is Lionhead Studios’ Fable 2 which allows the player to die but then instantly resurrects him/her with permanent aesthetic scars applied to the player’s avatar (also a minor experience loss). This mechanic still allows players to die and experience a failure case but it does not impede their progress through the game or, really, make for much player frustration (faux-challenge). The most recent and notable game which attempts to make its players think about death differently is Ubisoft Montreal’s Prince of Persia. Prince of Persia treated death as a mere “misstep” and, essentially, gave it players an incredible number of mini-checkpoints that they would be restored to in the event of failure.
Should games continually rely on death as a means of enforcing player skill? Is “death” the best way to do that? Is the current system of dying and returning to some designer-specified game checkpoint the best way of managing a player’s progress through a game? Dying isn’t fun, but is overcoming what caused a player to die before fun (and worth the annoyance of repeating a gameplay segment)?
A game is often defined by its rules. If every game was played like Calvinball then there would be no common understanding of the game for people to play. Games without rules would play out like they were written by Kafka; one person would seemingly understand everything that is going on while another may feel constantly lost amidst faux-procedure. For a game to have any real comprehensible significance to its players, then, it needs to have some set of rules. And for these rules to have any gravity or meaning attached to them, the players of a game need to feel that the rules are there for a reason. This is the kind of “fact of life” that any child hears repeated throughout his or her life.
If rules exist for a reason then it stands to argue: what if the rules are violated? If a rule of a game is that a player needs to keep himself above zero health in order to progress through the game, then something has to happen to reinforce the importance of this rule to the player. Or, in a similar fashion. And then there is the condition of gameplay where a player may want to just break the game rules as he sees fit for the fun of it. There isn’t a game player in the world who doesn’t at some point wonder: what happens if I do this? What should be the recourse for some sort of failure to obey (or, more generally, a failure case)? The role of these failure cases coupled with a reward (progression, character development, winning the game, etc.) forms the basis for the primary psychological structure fundamental to games: risk and reward. And like a lot of other design concepts, this is not one that is exclusive to games:
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
The role of death in games is, in the general case, the game designer’s primary form of denial and reward. A traditional action game, for instance, may employ the occasional puzzle but its primary frictional force to hinder player progression through the game is the use of enemies and combat. Making a player invulnerable for combat encounters would allow for a guaranteed progression through the game, but the player may struggle to find meaning in the killing of enemies or toppling of non-mental obstacles along the way. Death is our answer to this. By allowing a player an easily-conceptualized form of punishment, we work to reward their eventual triumph and make the forthcoming activities more meaningful by that virtue. And, as a lot of the contributors to this round table surmised, death is less about any concept of “death” and more about the relationship of a number of universal gameplay concepts that designers must battle with in the development of any game across any genre: failure cases, challenge, and the symbiotic relationship between risk (or denial) and reward.
Tobias Hoffmann starts out this topic’s discussion with what he feels is a solid rule of thumb regarding the three life rule:
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
It’s a cute rule, but it’s one that simply doesn’t apply to modern games save for those that intend to evoke the feelings of the days of platformers on the NES. Thomas Kiley shares a well-written summary of his feelings about the relationship between failure cases (death), challenge, and the balance that must be struck between them:
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 […]
Spoonbender attempts to argue the inherent problems with death in games:
[…] 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.
In an attempt to frame the discourse of the conversation in such a way as to allow everyone to work off of the same definition of death and challenge (spoiler: most didn’t work off of it), Tyler McCulloch gave a concise post on just that:
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.
Tyler’s point received a very well-worded counter-argument by Tristam MacDonald a few posts later (the emphasis is mine):
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.
The last sentence is one of the most poignant posts made in the entire thread and summarizes a lot of what this discussion is about while also pointing towards gaming’s reliance on a profound failure case (death) to make up the “risk” portion of the risk/reward relationship. This is a concept that Gary Hoffman delves into:
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.
Riffing off of the example games I listed in this round table’s description, Orangy Tang takes on Bioshock’s death mechanic (or lack thereof):
Fable  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.
This discussion yielded a very important point, if a very tangential one: what happens when there is a major, if understandable, difference between a player’s intent with the game and the one of its designers? Bioshock is a game that had some of the most gorgeous architecture, interesting level design, and brilliantly-handled atmosphere in the history of the gaming medium, but it’s also a game that, in my mind, ended up focusing far more on combat than I would have expected (or wanted). Its choice to allow players an infinite number of “lives” (resurrections through nearby vita-chambers) with no real punishment other than a minimal amount of backtracking and the chance that some enemies may have found a way to regain some health in the mean time was one that enhanced its players ability to make their way through the game. For players who may have been more focused on the game’s aesthetic design and narrative than its combat and difficulty, then, playing through the game was more tolerable than, say, the Ninja Gaiden and God of War games of the world.
Johannes gets the discussion back on track, or is simply kind of a conversational downer, by bringing us back to death:
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.
This is a concept worth exploring: if death/rebirth is instantaneous and very little is lost in the process of dying, is the “punishment” of allowing another player to succeed enough? In a competitive game, the sole goal is generally not to get one kill (unless the player is really awful at the game) — no, the goal is to win. Every death in a deathmatch game means that a player is further from winning than he/she was before, and in the realm of competitive multiplayer, that may be enough on its own accord. Most competitive games make death more punishing still through the removal of a player’s previous weapons and, maybe, a “time out” period that they must wait in order to be resurrected, but the primary punishment is allowing others to pull ahead.
GerardL brings up the topic of Mirror’s Edge as a game that handles death well by splitting it into, as Thomas Kiley writes it, “compulsory punishment” and “optional punishment.” GerardL makes this division by saying:
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.
This is a bit of a flawed example in practice as, in Mirror’s Edge, the time trials are only unlocked by playing through the entirety of the game’s campaign. While playing the story mode of a game may not seem like a poor activity to ask a player with, as it’s the focus of Mirror’s Edge in theory, in practice it is incredibly painful. The divergence of gameplay across two modes which enact the risk/reward model differently for the player, though, is a great concept that is definitely worth further discussion.
Jacob Ensign writes one of the closing contributions to the threads which discusses the importance of “death” as a means of influencing player strategies and play styles through adaptation in a way that is beneficial to the integrity of a game’s gameplay and mechanics:
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.
Are death and failure the best way to encourage a player to create unique and entertaining play strategies, though? At this year’s GDC, Clint Hocking gave a presentation on influencing player strategies through a combination of intentionality and improvisation. These two high-level concepts formed the two tiers of a player’s play style: one is, essentially, a strategy that a player has going into a scenario (intention) and one is a strategy that forms dynamically in response to a failed execution of that strategy (improvisation). The Far Cry 2 team encouraged this method of play through a series of gameplay systems that occurred while a player was fighting and none of the strategy-altering ones would, necessarily, cause a player to die, just to adapt his/her strategy; however, death was certainly a possibility of a failed strategy, but the team also gives a player a sort of “cushion” against death by allowing an in-game buddy to come and rescue the player. This gives a player an immediate second attempt at executing a combat strategy before he/she dies in the more traditional manner (having to reload from a saved game).
I’d like to close out The Death of Death with a post made by Jason Kozak who, instead of providing lengthy arguments, made a very insightful observation regarding Orangy Tang’s earlier post and chose to pose a few very insightful questions:
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?
In the end, how a game implements its fundamental denial (or risk) and reward structure is completely dependent on that specific game. There is never going to be a concrete set of rules by which a designer can know the best way to make a player constantly feel as if he is performing a set of activities that are bordering on just the right amount of challenge to be meaningful for that player. What the concept of death in games really comes down to is how much of a punishment needs to be attached to a failure case? What kind of stakes should a player have to keep in mind whenever he is playing a game and how much caution does a designer want to impose on a player’s style of play? This is a topic that is being experimented more in games in the last couple of years and, while there is no perfect definition, seeing non-standard takes on failures cases in games like Bioshock, Prince of Persia, Fable 2, and even a game like The Path, is great topic for further discussion in the field of game design.
I don’t have any original thoughts that can fill out an entire piece this week, so this is going to just be a combination of various things I’m doing. Most notably to anyone that’s visiting this site and had permanent links to my old gallery: it’s broken. The database seemed to randomly go all corrupt over the weekend and I am in the process of uploading everything to a new location and this is both time consuming, bandwidth intensive, and my larger galleries cause my host to get angry with me and put my site on a CPU Quota Exceeded time-out. All of the old game screen shots will all be back in their place eventually, though. And eventually I’ll go through all of my old articles (at least the ones that get the most hits) and update the screen shot links. If that sounds fun it’s entirely by accident.
Regarding Magnetic Butterfly, I love the project dearly but the only time I can devote to the project is when I’m away. Whenever I make progress, though, I upload a build to its temporary home. I’ll write a more detailed piece about the design of the game and some of the ways I plan on encouraging a player to take chances in the scope of the game soon. My current task is implementing some of the more aggressive forces that will work against the player in the course of a game; my current plan is to make a single game of Magnetic Butterfly a rigidly-timed experience in an attempt to regulate the way a player experiences the gameplay. I’m not sure how, exactly, that will work out but it’s the intention I’m currently working under.
Over the last few months I’ve been getting back into level design through, primarily, Call of Duty 4 and Unreal Tournament 3. This is something I haven’t done full-time (and, scarily enough, I do enough of it in my spare time now to almost qualify as full-time) since DOOM 3 and Half-Life 2 were new, but it’s still as enjoyable as ever. I put up a level design page a few weeks ago that I update pretty regularly with new links, screen shots, and videos. The first release is the unfinished alpha of a multiplayer for Unreal Tournament 3 (gameplay video here) designed around the concept of an urban area surrounding a lab containing some kind of alien artifact. The map turned out alright for my first shot at UnrealEd, but it ended up a bit rougher than I would have liked. My primary effort, though, is a mission for Call of Duty 4 designed around a player who was taken captive by random CoD4 terrorists and wakes up in a small holding cell where someone has unlocked and opened the cell door and left a handy silenced USP pistol on a table. The first leg of gameplay is intended to be a short “stealth” sequence (early gameplay video here) as the player escapes the building he is being held in and then the level will escalate encounters from there. CoD4Radiant, the map editing tool that Infinity Ward has released for public use, is pretty archaic when compared to something like UnrealEd, but it’s still incredibly usable. The hardest aspect of working on single-player content for Call of Duty 4, though, is by navigating around the incredibly undocumented scripting system (a custom language primarily influenced by C), but it’s been pretty easy to pick up purely through contextual use through the scripts for the game’s retail missions.
One of my most enjoyable pursuits over the last few weeks is reading up on some of the basic fundamentals of architectural design. Classical Greek and Roman architecture was something I studied a bit in college, but reading up on more modern design fundamentals has been absolutely fascinating. One of my favorite resources thus far is Architecture: Form, Space, and Order which is an incredibly visually detailed introduction to fundamentals of architecture. The other was informally recommended by Tom Armitage in a guest post to Offworld: 101 Things I learned in Architecture School. This short, concise book is by no means a detailed or comprehensive introduction to architecture, but what author Matthew Frederick does is to introduce readers to a number of most important fundamental maxims of Architecture through a combination of visuals and a short text passage. You can check out some of the sample pages from the book at Frederick’s site for the book. If anyone has any other recommended architectural texts I would absolutely love to hear them, this is probably the most interesting and beneficial topic I’ve gotten into in a while.
Finally, my article for the test run of the Game Design Round Table got posted to GameDev.net and it looks so fancy and special over there. It’s also here where it looks so fancy, special, and blue! You can also take part in this week’s Game Design Round Table which discusses the role that death mechanics and failure states play in gaming and game design. After a mere thirty-six hours the thread is already at fifty-three replies; this means that my task for making an article out of the contributions next week will be… Time-consuming. I made a point early on to not contribute to the discussions since I had such a hand at starting (and ending) them, but the one occurring as I write this is pretty fantastic.
Over the last couple of months I’ve been nurturing an idea to hold a sort of casual attempt at a game design round table where I (or another organizer) would present a topic (and some basic information and potential arguments) to a group of independent or professional game designers. Everyone involved would then be let loose to sound off on their opinions on the topic at hand, argue with each other, and so on. The goal was to provide a format and location that would encourage designers to discuss topics in game design intelligently and thoroughly throughout the duration of the seven weeks that the topic is left open. Once the seven days of discussion were finished, the person who initiated the event would both write a piece which compiled original thoughts and combined them with arguments and perspectives of everyone who contributed to the discussion. Originally, I was planning on doing this by setting up a mailing list and slowly getting more and more people involved but then I realized that the Game Design forum at GameDev.net would be a near-perfect locale for this. With this in mind, I started up the first attempt at the Game Design Round Table (it’s a metaphorical table) entitled No More Health.
Round Table Topic — Regenerative Health
Regenerative health systems are actually a pretty simple one that have radically changed the way that first-person shooters and a number of third-person action games are played. The idea behind regenerative health is that players can take a finite amount of damage in a short span of time before they are sent into a “dying state” — which is typically indicated by a pulsating red screen — and if they take more damage beyond that then they will die. If a player does not take any more damage when they are in a dying state, though, and instead seek cover and avoid enemy confrontation and fire, they will slowly return back to their normal state. The concept of player health is now entirely dynamic and up to player interpretation via some sort of interface cue, red tinge, or other full-screen indicator. The effect of this mechanic is that it abstracts the older method of requiring players to manage their health and pick-ups, something that most players inherently understand (mortality), into a very streamlined and intuitive experience.
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
A health bar is one of the most iconic interface features in the history of video games. Children of the 1980s to the early 1990s have that grown up with a concept of health as being integral to their gaming experiences. For those of us with that gaming history, unless a game designer attempts to trick us, we know what a red bar on user interface means or what a numerical value next to a cross or heart or similar icon represents. That interface feature tells gamers one thing: how safe they are. A low health value or a slim portion of a life bar means that a player is going to play things as carefully as he/she can; no chances taken means that a player can reach his destination, doing something brave or stupid means that a player has little to no chance of surviving a given stretch of gameplay. A full health bar gives a player the sense that they’re safe, they can screw around — maybe get a little explosion happy — and still have room to breathe.
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.
And as Jason Adams adds this can create for a sort of exigent mid-combat tactic on its own:
[…] 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.
While both of these points are absolutely valid reasons to adhere to the more time-tested approach of a concrete health-based method of conveying player well-being and sustainability, are any of the aforementioned points actually necessary? While the presence of in-world health gives players a reason to move about the battlefield when they are near a death state — which is an inherently tense gameplay scenario — the same behavior can be demanded of a player through weapon and ammunition scarcity and management. More than just the management of health, though, a concrete health system enforces a certain type of play style, one of which is that of a strategy of long-term survival as gxaxhx points out:
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.
While specifically referring to the style of gameplay that a non-regenerative health mechanic promotes or enforces, gxaxhx’s argument actually goes back to the treatment of health like an in-game resource. So long as health is a player-managed resource, the player’s actions and carefulness, based on current game events, will be directly related to the scarcity of health in the game world.
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.
And Luke Parkes-Haskell writes a superb post that begins with praise about regenerative health systems while bringing up what he feels are complications when the system is carried over into the competitive arena:
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.
My favorite contribution to the thread comes from Drew Marlowe (a designer on Full Spectrum Warrior: Ten Hammers, Mercenaries 2, among others):
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.
The concept of a player experiencing and understanding the distinction between the danger of shot at compared to the consequences of being shot is fascinating. The influence that a game’s health system can have on such an experience is arguable, but the benefits of allowing players to experience a sort of “warning shot” that does enough damage to cause some visual/interface/post-processor effect but doesn’t incur any long-term damage (that would be almost inherent to a more concrete health system) seem worth looking into (in theory, if not practice). Drew goes on to illuminate one of the most notable difficulties of simulating such a experience by saying:
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.
Stroppy Katamari went back to the days of Action Quake to illustrate the benefits of a sort of hybrid health system that merges some aspects of a concrete health system with those of a regenerative one:
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.
As a number of the people who contributed to this first attempt at this kind of project and discussion noted, the usefulness and enjoyment that can be derived from a given system are entirely dependent on the specific game which employs it. This is, of course, an incredibly valid point, but one I’d like to encourage further round tables to worry less about. The goal of these discussions is to attempt to get developers and designers to communicate with each other about certain issues in game design; this requires a knowledge of gaming trends, for one, but more importantly it requires designers to make intelligent arguments with one another. Making an argument isn’t as simple as posting a quote from a famous designer or citing an excellent game which had a certain design but, rather, making an argument and supporting it with a combinational of practical examples/experiences and general theory. A discussion about games is generally impossible to boil down to pure empirical data and concrete facts, so I would encourage contributions to think a bit about their own arguments and, if necessary, feel free to generalize into theory rather than relying on an obvious fact like “this all depends on implementation” or “this only works in this specific game.” There are lessons that can be extracted from specific examples and that’s, ideally, what I’d like to have people take from their discussions with one another in the future.
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 email@example.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.
For anyone that wants to contribute to further discussion for this piece (casual comments can be kept here), I recommend visiting this post’s entry at GameDev.net.
So, yeah, I realize I absolutely fail at updating my own site; luckily, though, I’m excellent at updating other peoples’ sites. Like GameDev.net where I can be found writing news entries that have been described as distinctly me (which works out well).
Anyway, here are links to the last nine as of the night of this posting.
I’ve been playing a very time-intensive game of musical chairs with various three-dee engines over the course of the last two-and-a-half weeks in an attempt to find the one that would be best suited to my particular development style and the kind of game I want to create. And I can safely say that, tonight, I have reached the ultimate solution. That’s right, after toying around with things like TorqueX, Torque Game Engine Advanced, OGRE, Irrlicht, Nebula3, and, finally, PowerRender. The latter two of the list appeared to have the most potential, with PowerRender being the closest thing to what I was looking for, but the most recent iteration of the engine is still under heavy development and, what was the most troublesome, seems to be getting very infrequent updates. So, after all of the wasted time, I decided that I was going to dig out my old C++/D3D9/D3D10 framework and just rip out the D3D9 parts for use in a new framework which I could use in the future.
I got exactly an hour-and-a-half of work done on that last night before I realized that it felt way too much like the kind of engine work I do at my job every weekday. So now, and for realsies, I’m back with XNA. I’ll be releasing Asplode! this weekend in its terribly-performing state (and open source) and, hopefully, everything I learned in the development of that will help me create a far more useful toolset this time around as far as memory management is concerned. The most important lesson I have with me that I learned from Asplode! is that the most important thing about memory within a managed environment isn’t necessarily the allocation of memory so much as it is the deleting of it. Apparently the garbage collector is a wicked beast that must be appeased in order to maintain stable gameplay performance. I don’t know. I’m still getting the hang of the intricacies of C#. When I was working on Asplode! — and this will be readily apparent in the source if people peruse it — I didn’t know anything about C#. I simply coded as if I would code a game using C++ and, when code didn’t compile, I read up on why the error occurred and what I needed to do/learn in order to fix it. Hopefully, this time around, I’m a bit more well-prepared. It also helps that Drilian and I are teaming up for some of the more game-independent stuff.
As a random note, I beat Final Fantasy 7: Crisis Core earlier this week. While I have the same issues with it that I do most RPGs (that the combat becomes asininely annoying by the end of the game), the game did the Final Fantasy 7 universe — and FF7 is the only JRPG I’ve ever enjoyed (and loved) — absolute justice. The story was incredible and provided a lot of great depth on Zack, the inner workings of SOLDIER, and the root for Cloud’s identity disorder. And seeing Sephiroth function in more “normal” times and take actual solace in communication with friends/peers was cool. I’m just waiting for my copy of Advent Children to arrive so I can re-watch that. Now it’s back to Wipeout Pulse, AoE3: The Asian Dynasties, and more Rock Band. And GT5: Prologue. Grand Theft Auto 4 can come out anytime now as well.
Anyway, yeah, that’s about it. I hope everybody has been The Daily GameDev.net news pieces I’ve been posting every weekday morning. They’re almost asininely fun to write up but they do tend to take the place of dev journal updates at times, so if this thing has become a bit more stagnant than usual then that’s probably the reason.