Presentation is loading. Please wait.

Presentation is loading. Please wait.

Harvey Smith witchboy@ionstorm.com Systemic Level Design Harvey Smith witchboy@ionstorm.com Systemic Level Design.

Similar presentations


Presentation on theme: "Harvey Smith witchboy@ionstorm.com Systemic Level Design Harvey Smith witchboy@ionstorm.com Systemic Level Design."— Presentation transcript:

1 Harvey Smith witchboy@ionstorm.com
Systemic Level Design Harvey Smith Systemic Level Design

2 Lecture Overview Intro, Overview and High Concept Special Case LD
Systemic LD Pros of Systemic LD Cons of Systemic LD Summation I’ll be including a number of examples and I’ll be taking questions at the end. Systemic Level Design

3 What if Frank Lloyd Wright Built Doom Levels?
Not a visual aesthetics or architecture talk. Not a level design ‘chokepoint’ or ‘flow’ talk. Today I’ll be talking about a particular approach to gameplay implementation from the level designer’s perspective. Systemic Level Design

4 What Today’s Talk ‘Is’ Related to LD content creation tasks and tools.
Advocates gameplay implementation: According to (systemic) global patterns Instead of (special case) localized patterns The idea is to allow level designers to implement gameplay according to globally consistent systems, rather than by building a bunch of special case puzzles controlled by manually placed triggers. Systemic Level Design

5 Intro: Ion Storm (Austin)
An EIDOS Studio Studio Head – The GREAT Warren Spector ™ Titles to date – Deus Ex (PC and PS2) In development – Deus Ex 2, Thief 3 Focus on Immersive Simulations The immersive sim perspective informs much of my speech and my opinions in general. Systemic Level Design

6 Intro: Harvey Smith Deus Ex 2 (Project Director)
Deus Ex (Lead Designer) FireTeam (Lead Designer) Technosaur (Project Director/Designer) CyberMage (Associate Producer) Ultima VIII CD (Tester/Design Assist) System Shock (Lead Tester) Super Wing Commander 3DO (Tester) I’ve worked on games professionally for the last 8 years. My project responsibilities on Deus Ex (and on FireTeam previously) revolved largely around mission and map construction, including the set-up of gameplay elements like rewards, obstacles and channels through the playing field. Systemic Level Design

7 Deus Ex: Goals Spy fiction Realistic environments
Immersive environments Genre mix Player-driven experience Since I’ll be alluding to the game throughout the lecture, let me give you a quick overview of Deus Ex. Without knowing exactly how to achieve all this, we had some creative and technical design goals: Systemic Level Design

8 Deus Ex: Where We Ended Up
Conspiracy Theory Globe-hopping, Real World Locations Immersive Sim – Shooter Hybrid Multiple Solutions to Problems Here’s the game we ended up making. Systemic Level Design

9 Deus Ex: Systemic/Special Case Hybrid
Multiple Solutions (Player Expression) Player-expression via game systems, emergence and simulation (Systemic). Player-expression via LD-driven puzzles and situations (Special Case). The desire to give this talk today was largely fueled by seeing both approaches used in Deus Ex. Systemic Level Design

10 High Concept Level designers can establish gameplay systemically or on a special case basis. Systemic implementation enables More intentional, less scripted play Decreases the learning curve Makes bug fixing easier Obviously, aside from any involvement in the planning phases, a lot of the level designer’s work happens in the latter two steps: Content creation and bug fixing. Systemic Level Design

11 Special Case Level Design Definition
Special case level design is the creation of gameplay out of the notions of a particular designer, as needed for a specific, localized occurrence in the game. Special case level design has limited awareness of global game patterns. Systemic Level Design

12 Special Case Level Design
All about the ideas of a given level designer: What is consistent What is fun (and rewarding) Consistency is possible, but improbable: Requires vigilant manual effort Single cardboard box in DX contained something useful Systemic Level Design

13 Special Case: Planning
Example—Team discusses: Fictional setting of a given level “Look and feel” Placement of units (monsters or characters), weapons, tools or resources Specific puzzles or scripted sequences Discussed, but implementation is not detailed Not practical Different designers, different styles/techniques Systemic Level Design

14 Special Case: Tools & Content Creation
Properties and parameters for many game elements reside on a per instance basis: Objects with tweaked parameters Unique moving geometry (movers) Special triggers All cobbled together by each LD individually Systemic Level Design

15 Special Case: Tools & Content Creation
Examples: Generic (highly configurable) triggers Moving geometry (generic “movers”) Different LD’s create visually identical “crushing block” puzzles that function differently, with subtle variations. Many editors have hybrid tools DX1 trip lasers had default properties, but could be tweaked, causing problems. Trip laser traps had default properties related to associated sound effects, damage or the duration of an alarm stimulus. However, LD’s would, after setting up a trip laser trap, sometimes alter the properties to meet the needs of some specific location in the game. This caused minor variations in the base functionality of trip lasers that were not obvious to the player. Systemic Level Design

16 Special Case: Bug Fixing
Testing finds problems and often each instance of a gameplay element must be visited and reconfigured manually: Each scripted scene All triggers controlling specific state changes All unique movers Et cetera Systemic Level Design

17 Special Case: Bug Fixing
Example—Playtest determines that crushing blast doors add fun. Because each door was set up manually, each door must be visited individually: Takes time Likely to introduce bugs Systemic Level Design

18 Systemic Level Design Definition
Systemic level design is the creation of gameplay out of combinations of existing game elements with globally defined, consistent characteristics and behaviors. Systemic level design has an awareness of global game patterns. In the systemic LD model, games are made up of elements from an object hierarchy, defined globally. As opposed to games made up of elements built (or configured) by hand on a case by case basis, defined per instance. Systemic Level Design

19 Systemic: Planning Team discusses:
Same stuff as in Special Case planning (fiction, look and feel, game element placement, specific sequences) Rules governing behaviors of game elements Specific methods for implementing types of situations (according to agreed upon patterns) Systemic Level Design

20 Systemic: Planning Example—Team plans 3 door classes:
Light doors easily destroyed and do not inflict damage Medium doors only destroyed by explosives and inflict light damage Heavy doors cannot be destroyed and inflict heavy damage Systemic Level Design

21 Systemic: Tools & Content Creation
Game element properties and parameters reside at a higher level, rather than on a per instance basis. Tools for adding game elements are streamlined, calling upon archetypes, rather than specific instances of any given game element. Systemic Level Design

22 Systemic: Tools & Content Creation
Example—Door behavior (3 classes) stored in object property tree Not entered for each of 500 doors by hand Information entered and managed centrally LD’s select proper door and drop into place New door types are added when needed All doors inherit properties from archetypes Obviously, doors usually need properties such as movement speed, resistance to damage, associated sound effects and damage inflicted when closing upon another object or game unit. Systemic Level Design

23 Systemic: Bug fixing Playtest determines that a given gameplay element behaves inappropriately. A change is made to the object property tree storing the behaviors of the game element archetype. Systemic Level Design

24 Systemic: Bug fixing Example—Playtest complains that medium doors are not always destroyed by grenades: Medium door strength is lowered globally Note: If a special case door is needed, hopefully a new type of door is added to the object hierarchy, so that this door can inherit some of the behaviors of the other doors. The systemic model does allow for a one-of-a-kind door, if such a door is needed. Systemic Level Design

25 Consistency Emergent Gameplay Efficiency
Systemic: Advantages Consistency Emergent Gameplay Efficiency I’ll detail each of these and cite examples. Systemic Level Design

26 Consistency Breakdown
Plan Formulation Intuitive Behavior Learning Curve Emergent Gameplay Efficiency There is some overlap here. Systemic Level Design

27 Consistency: Plan Formulation
Consistency rewards strategic plan formulation. Once the behaviors of game elements can be predicted, the player is empowered to make assumptions. Success or failure are understood. Player feels a sense of agency. The player is more likely to have a sense that he is in control of the experience if he can form plans based on the information he has, if those plans have a chance of succeeding and if it’s clear to the player why he failed or succeeded in trying to execute a plan. Systemic Level Design

28 Consistency: Plan Formulation
Example—LD’s set up blast doors w/ different properties: Crush, Move Speed, Sound Volume After encountering first blast door, player makes assumptions about second blast door. Plans fail. Player feels like he is uncovering an arbitrary path set out for him by the designer. Example: Designer One sets up a particular type of door mover to crush units when it closes. Designer Two sets up an otherwise identical door mover to push units aside when it closes. Having already encountered the door set up by Designer One, the player might attempt to exploit the behavior of a door set up by Designer Two by using it to crush an enemy. But this plan could fail because the door behaves completely differently than the player expected. If the player is moving from area to area in a game, trying to figure out the correct key-lock puzzle solution in each area, he is likely to end up with the feeling that he is merely uncovering following a path laid out for him by the game designer. Systemic Level Design

29 Consistency: Intuitive Behavior
If game elements are implemented with systemic consistency: The player is more likely to develop an intuitive understanding of game elements. Variations of game elements are likely to be understood even if the player is encountering them for the first time. Systemic Level Design

30 Consistency: Intuitive Behavior
Systemically implemented fire damage model: If campfire burns player-character once, it is likely to burn him twice. If player encounters a second form of fire (like a fire barrel), it is likely to behave intuitively: Burns player-character Burns cat Burns dog Example: If fire is implemented systemically, the game has the potential to seem more rational to the player. If a campfire burns the player-character once, another type of fire encountered later is also likely to burn the player-character. If a campfire burns one form of organic creature (like a dog), another type of fire encountered later will burn a second type of organic creature (like a cat). Systemic Level Design

31 Consistency: Learning Curve
If the behaviors of game elements stay consistent: Player spends less time learning the game Player spends more time playing the game If elements behave consistently, the learning curve is less intimidating. Once encountered, as element can be trusted to behave as understood. If elements behave in some new way each time encountered, the learning curve is perpetual—the player can never fully learn the game. Systemic Level Design

32 Emergent Gameplay Consistency Emergent Gameplay Efficiency
Special Case = Per instance basis Systemic = Class-to-class basis Efficiency Special case LD equates to more per-instance interactions. In other words, game elements interact more on a one-to-one basis. Systemic LD equates to more general interactions. In other words, game elements interact more on a class-to-class basis. Systemic Level Design

33 Emergence Emergent gameplay can arise from the interaction of simple rules, making the whole of the game experience greater than its parts, allowing for second order consequences. Systemic Level Design

34 Emergence DX1 Monsters were more systemic than characters:
Monsters were dropped in place Characters’ properties were tweaked Urban context: Run when shots fired Warzone context: Crouch when shots fired DX1 Monsters provided more comprehensible, useful emergence As with most games, the units (characters or monsters) in DX1 were fairly systemic. The team decided upon their functionality, and they existed as part of an object hierarchy. In placing a unit, the LD would generally select it and drop it. If this unit was a character, a lot of settings often had to be tweaked to account for attitudes toward other units within the level (like, do these thugs hate the player or the local civilians) and for the context of the level (do these people flee when they hear gunshots, as in a city block, or do they crouch, as in a war zone). These character units provided many times more bugs than the more systemic monsters. If the unit was a monster, with a clearer relationship toward the player, it was often dropped in place without any tweaking. Even though our tools allowed for per-instance (or special case) modification of monster stats, we rarely did that, assuming that if we did players would not be able to make effective strategic judgments about the monster. Systemic Level Design

35 Emergence Example 01 Players discovered deeper layer of interaction than we had planned: Locked Containers: Opened w/ resources. MiB Unit: Explodes upon death. Emergent Strategy: Players used MiB’s to open locked containers. Good surprise: “Oh, wow, of course.” Bad surprise: “What the hell?!?” So consistent systems capable of emergence are more likely to provide the player with emergent strategies. The player can formulate plans beyond those conceived of by the development team. And the game will sometimes surprise the player by providing some interesting, indirect outcome. Game interactions can be surprising in two different ways: Rationally and irrationally. A surprising moment that is perceived as rational is likely to cause the player to say, “Oh, wow, of course…” If an unexpected outcome causes the player to say, “What the hell,” it probably means that the game has behaved irrationally. The former is more likely to be perceived by the player as rational or intuitive, the latter tends to frustrate players—the world has behaved in a way that does not make sense. Systemic Level Design

36 Emergence Example 02 Transform: Convert organic into mech.
Command Bolt: Steal enemy mech. Player can upgrade then steal enemy organic units. Normally, making an enemy more powerful is not something you’d want to do. However, if he has access to it, this player can then use another game power—one that steals enemy mech units—to cause the now-more powerful, now-mechanized enemy soldier to switch sides. The first card—normally played on a player’s own units to enhance them—does not have an explicit relationship with the card that steals mechs, but they work well together if the player sees and exploits this emergent strategy. Systemic Level Design

37 Consistency Emergent Gameplay Efficiency
A great deal of time was spent on DX1 doing things that I consider stupid and wasteful. A large portion of many work days was spent doing things like tearing apart and rebuilding specific door movers (just to adjust the texture on the door or some other aspect of the mover), visiting each instance of some game element within each map to make a small change (like touching all the thousands of lights in the game, for instance), setting and re-setting unit alliance parameters on a per character (or monster) basis, etc. This kind of work was tedious, costs money and had little positive impact on the gameplay experience. There’s a significant opportunity cost involved in this type of work; time that could have been spent tuning the experience to make it more fun is instead spent grinding away at little special case maintenance tasks. Then, when it came time to fix bugs, we basically had to do all of this again. Any time a general observation about the game was made, the level designers often had to touch dozens of manifestations of the problem in order to address the observation. Systemic Level Design

38 Efficiency Systemic Level Design: Plan-and-drop efficiency
Global bug fixes Designers spend less time on tedious map-monkey tasks and more on gameplay Systemic Level Design

39 Efficiency Example—A change made to TripLaser_red in the global object hierarchy changes all red trip lasers. Worth noting: Part of the DX1 problem was the lack of a LD tools support programmer. If gameplay is implemented systemically, time is saved. The fundamental approach to DX1 LD tools was special case in nature—most game elements existed on a per instance basis. Better tools would have made re-texturing a door quicker and more efficient, but at a core level part of the problem was that each door in the game was a completely unique entity. In DX2, we have an object hierarchy where door types exist and can be plopped down repeatedly. Systemic Level Design

40 Systemic: Disadvantages
Need for Shoehorning Introduction of Uncertainty Designer Perception Loss of power Consistency is boring Systemic Disadvantages Systemic Level Design

41 Shoehorning Twisting an idea to make it work with core gameplay systems. A restriction on creative impulse in exchange for the benefits of systemic level design. Sometimes needed to meet creative vision Sometimes needed for player expectation The special case level designer would attack the problem by setting up a series of manual triggers. On one hand, this is powerful, since it means the designer is capable of adding elements to the game that are outside the scope of the core gameplay systems. On the other hand, any new elements added in this way have the tendency to act counter-intuitively, to break (or thwart player expectations) unless the designer has covered every possible outcome, and to require more time implementing and bug-fixing. Systemic Level Design

42 Special Case Squad Mate Example
Designers (and testers) wanted a “squad mate” for cell break Idea made total sense, in context DX1 lacked “Squad Mate AI” We hacked it in anyway with a bunch of manually placed triggers While working on Deus Ex, one of the designers wanted to create a scenario in which the player could rescue a character from a holding cell within a underground base. The idea was that this character would then follow the player through the underground base, fighting alongside the player. Systemic Level Design

43 Ladies and Gentlemen…Miguel
It met expectation and provided color It broke often and was lame Special case tools are powerful (maybe in a bad way) This situation led to a host of problems: Players immediately wanted to “equip” their new squad mate, which required a new specialized type of conversation. Once equipped, the squad mate needed to travel from level to level, which would have been fine, except that “squad mate level transition” created a new series of problems. (Since this was a feature that did not exist elsewhere in the game, there was no code that allowed allies to change maps and maintain their inventory, as equipped by the player.) Systemic Level Design

44 Systemic Arrow/Pyre Example
Designer takes abstract idea and warps it to work with some of the core game systems Planting spots become pyres Seeds become water arrows Stealth is employed Core context/fiction is employed The systemic level designer’s concession here is to shoehorn the idea into the project’s core gameplay systems. Example: A mission designer working on Thief 3 has considered a series of mid-level gameplay goals involving planting special seeds in multiple spots through a map. These seeds would have no other use in the game, except as ‘keys’ for this one puzzle—the player would be able to use any of the seeds on any of a series of special case sod areas. This is fine and could provide some interesting color to the game. However, with a small amount of shoehorning, the special case sod areas could become perpetual religious pyres (similar to the one dedicated to John F. Kennedy). Then, using elements that are already a part of Thief’s core gameplay systems, the player could sneak around patrolling religious guards who watch over the pyres and he could use water arrows to extinguish the pyres. So, instead of a mission goal like, “Plant the seven seeds,” the designer could set up, “Extinguish the seven religious pyres.” This is just an example where, if the designer wanted, he could make a small concession that would require less special case work. Note: We could alternately use the DX2 power box example. Or I could just cut this slide. You *could* implement this gameplay systemically or in a special case fashion. The point is that the designer could shoehorn the idea into something more intuitive for the player—something requiring less feedback (or teaching of new features), less new art assets, new code, etc. Systemic Level Design

45 Uncertainty Systemic LD is more likely to allow for emergent events within the game. Emergent behaviors are often too subtle (or too numerous in permutation) for the team to effectively predict, introducing uncertainty. Turning the player loose in an environment made up of general purpose, globally consistent rules is likely to allow for some interesting emergent exploits. Time has to be allocated to analyzing the impact of these exploits. Systemic Level Design

46 Prox Mine Uncertainty Prox mines behaved according to globally consistent rules about relationships between classes Player could attach/un-attach prox mines Prox mines were physical objects Player could collide w/ physical objects Player didn’t detonate his own Player could climb walls w/ prox mines Degenerative emergent exploit. No one on the team foresaw this exploit, or even noticed it until after the game shipped. By taking an approach to gameplay implementation that did not explicitly establish all the behaviors associated with prox mines (and instead taking a more rules based approach that was more conducive to second order consequences or emergent behaviors), we introduced uncertainty into the game that led to an unfortunate exploit. So, as a disadvantage, systemic level design could be said to introduce uncertainty that either requires more time to troubleshoot or (if the exploits are not found) causes potentially game-breaking exploits. Systemic Level Design

47 Prox Mine Climbing Note: Due to systemic implementation, this bug would have been easy to fix, had we caught it in time. Systemic Level Design

48 Special Case Prox Mine Prox Mine (red dot) is linked manually to other game elements (green dots). Prox Mine has no relationship w/ some game elements (black dots). The red dot is the prox mine. The green dots are things that interact with the prox mine. The black dots are things that do not interact with the prox mine. The hollow green dot is an entire class of objects. By going with the Special Case approach, we only cover interactions that we want. Systemic Level Design

49 Systemic Prox Mine Prox Mine (red dot) is linked to object class (hollow green dot). Prox Mine has relationship w/ all game elements (green dots). The red dot is the prox mine. The green dots are things that interact with the prox mine. The black dots are things that do not interact with the prox mine. The hollow green dot is an entire class of objects. By going with the systemic approach, we cover interactions that we had not considered. Systemic Level Design

50 Prox Mine Model Comparison
Systemic LD involves linking interactions on a class to class basis, where possible. Instead of linking interactions between individual unique game elements on a per instance basis. Systemic Level Design

51 Designer Perception: Loss of Power
“A foolish consistency is the hobgoblin of little minds.” – Ralph Waldo Emerson, Special Case Level Designer (and Poet) The systemic approach to level design is sometimes met with hostility or distrust. It often begs a couple of questions that the following slides will deal with: “Does the LD lose creative power?” and “Isn’t consistency boring?” Systemic Level Design

52 Designer Perception: Loss of Power
LD loses some specific narrative/flow control. LD gains: Tools that can be combined and trusted. Power to contextualize the world. Power to empower the player. The LD ends up with a set of more systemic tools that can be combined and can be trusted to behave consistently. The LD is freed to figure out how to contextualize the world for the player, knowing that the player will be fully empowered in that space. When working from a Special Case perspective, the LD may be free to craft crazy specifics, but they are then massively constrained in terms of what is supported by the game environment—in this case, the LD will be constantly trying to second guess the player and trying to specifically support (or script) a bunch of possible outcomes. Systemic Level Design

53 Designer Perception: Consistency Is Boring
“Consistency is contrary to nature, contrary to life.” – Aldous Huxley, Special Case Level Designer (and Depressing SF Writer) The second question often asked when LD’s are considering a more systemic approach is this: Doesn’t consistency equate to boredom? Despite the fact that people have been talking about the advantages of consistency for years, designers often come into a game project convinced that consistency unilaterally equates to tedium. Consistent behaviors can more often be predicted by the player. This allows the player to make assumptions about game behaviors. On the simplest level, when the player goes to fire his rail gun, he’s making assumptions based on the range, refire rate, accuracy, etc. If this game tool acted inconsistently—if all its parameters changed from shot-to-shot—players would find this extremely frustrating, in that it would completely thwart their plan formulation, their strategic intentions. Systemic Level Design

54 Designer Perception: Consistency Is Boring
Games with emergence are often surprising (in a good way). Players often perceive open-ended game environments as providing more freedom. “Anything can happen.” Systemic games encourage the player to experiment. Within games based on consistent rules, meaningful emergence is more likely. The additional complexity afforded by second order consequences are often seen by players as interesting. Emergence can be really exciting, not boring. When the behaviors of game elements are consistent and rules-based, players are more likely to feel empowered to experiment with the system. Systemic Level Design

55 Systemic Vs Special Case: Player Perception
Doug Church: Playing the Game Designer versus Playing the Game Okay, that’s the end of the systemic disadvantages. Another way to frame this discussion is in terms of player perception. As Doug Church has been ranting for several years, game players often deconstruct their experience, conceptually, in one of two ways: “Me versus the Game Designer” or “Me versus the Game.” Systemic Level Design

56 Playing the Designer Often much more frustrating:
Some arbitrary force is foiling the player Behaviors change, instance to instance Environment inconsistent or incomplete Plans often fail for inexplicable reasons Surprise: “What the hell???” Tends to anger players, makes them cynical about the game and breaks their sense of immersion. Systemic Level Design

57 Playing the Game Can be particularly satisfying:
Fewer logical breaks in consistency Environment feels rational Player feels free to experiment Player feels less manipulated Plans fail or succeed comprehensibly Surprise: “Oh, cool…of course” The system does not care—it has no agenda. The system does not care—it has no agenda. Systemic Level Design

58 Some Benefits of Special Case LD
Variation Outside Scope of Core Mechanics Unique Moments Story Advancement Clearly, players enjoy games that are not systemic. Adventure games are puzzle based and are usually completely special case, with the rules changing from one lush scene to the next. There’s nothing wrong with making games like this. Systemic Level Design

59 Systemic and Special Case Examples
Heart of Darkness GTA3 Platform Games These are some interesting examples of games that use one or both forms of gameplay implementation. Systemic Level Design

60 Heart of Darkness Great Game Every scene totally special case
Amazing Art Short Play-time Simple Interface Fun Every scene totally special case Heart of Darkness is the ultimate special case level design game. I’m not exactly sure what the LD tools were like, but from scene to scene, anything was possible, as determined by the whims of the LD. Systemic Level Design

61 Heart of Darkness Constant variation
Player constantly sees something new Any interaction is possible Systemic Level Design

62 Heart of Darkness Constant guesswork
Sometimes up arrow means “climb wall” Sometimes up arrow means “jump” Very narrow range of emergent interaction The downside is that in a scene where the player felt he might like to jump, if this was not the solution that the LD had planned, jump suddenly didn’t work. And, in a later scene, if the player saw some more vines and wanted to climb them, this might not work, depending upon the LD’s creative control of the scene. The game was mostly fun, but it was one piece of guess work after another for the player, and virtually nothing was possible within the game space that had not been played out by the LD. Systemic Level Design

63 Heart of Darkness Fun is still possible
Heart of Darkness has different (not inferior) values Systemic Level Design

64 Grand Theft Auto 3 Game of the Year
‘Sandbox’ freedom through simulation Pedestrian Traffic Vehicle Physics Dynamic Missions Damage Model Goal Completion Even in trying to accomplish a mission objective, the game often brilliantly allows the player to solve the mission however he can—in these cases, the game rewards for goal accomplishment, not for the specific way a goal is accomplished. (One of the goals we had for DX.) For instance, if the player undertakes a mission related to killing a particular street thug, when the game is at its best it does not care how the player goes about killing him—if the player can figure out a way to drive a car off of a roof onto his head, the player still gets credit for accomplishing the mission. Systemic Level Design

65 Grand Theft Auto 3 Mostly systemic: Sometimes special case:
Drive off roof Sometimes special case: Play it our way Suffered when Systemic and Special Case contrasted Systemic Level Design

66 GTA3 Cartel Example Goal Completion Methodology
Sniper Rifle Only Must Wait For 8-ball MISSION FAILED Contrasts w/ Goal Completion There are times when the player must accomplish a mission in a specific way. Players—accustomed to GTA3’s amazing level of freedom—are often extremely frustrated when they hits points like this one. Suddenly they have to start thinking in terms of “Player versus Game Designer” instead of “Player versus Game.” Systemic Level Design

67 Platform Games Games like Mario64, Sonic
Made up almost entirely of systemic elements LD’s create gameplay patterns by combining elements Platform games, like Sonic or Mario, are made up almost entirely of systemic elements. The games are sets of components which LD arrange to meet the needs of the level. There are a number of special interactive elements (springs, power-ups, so on) which are combined to form levels. They all always behave in exactly the "expected" way, hence they are, essentially, systemic. No designer can make the spring that doesn’t spring, for instance. Systemic Level Design

68 Summation: High Concept
Level designers can establish gameplay systemically or on a special case basis. Systemic implementation enables More intentional, less scripted play Decreases the learning curve Makes bug fixing easier Obviously, a lot of game projects (and a lot of game editors) allow for both the systemic and special case poles of gameplay implementation. Many editors, for instance, allow people on the project to drop enemy types or weapons which have had their parameters established at a higher level, while also allowing level designers to drop more generic entities, like multipurpose triggers. And other disciplines, like software engineering, have spent a lot of time trying to convince themselves that taking an object oriented approach to production is a good idea. So the point of this talk was not to expose some new secret of game development, but to make formally embracing this sort of level design an option. Systemic Level Design

69 Summation: Last Thoughts
Design object behaviors by type, rather than by instance. This is central to designing a behavior system rather than a set of puzzles. Too often, people don’t think about their approach enough before generating content; everyone is so excited by the act of content creation, they rush in and start setting up triggers and movers on a case by case basis. Some time dedicated beforehand to consideration of global patterns in your game has the potential to dramatically improve your chances of creating a compelling experience for the player. Systemic Level Design

70 Goodbye and Good Luck Thanks Special Thanks: Ion Storm Austin, Marc LeBlanc, Warren Spector, Tim Stellmach, Ricardo Bare, Brian Sharp, Kent Hudson, Clay Hoffman and Doug Church Systemic Level Design

71 Systemic Level Design Harvey Smith (witchboy@ionstorm.com)
The End (Note: DX2 screenshot, shown at GDC, removed.) Systemic Level Design


Download ppt "Harvey Smith witchboy@ionstorm.com Systemic Level Design Harvey Smith witchboy@ionstorm.com Systemic Level Design."

Similar presentations


Ads by Google