2Lecture Overview Intro, Overview and High Concept Special Case LDSystemic LDPros of Systemic LDCons of Systemic LDSummationI’ll be including a number of examples and I’ll be taking questions at the end.Systemic Level Design

3What 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

4What Today’s Talk ‘Is’ Related to LD content creation tasks and tools.Advocates gameplay implementation:According to (systemic) global patternsInstead of (special case) localized patternsThe 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

7Deus Ex: Goals Spy fiction Realistic environmentsImmersive environmentsGenre mixPlayer-driven experienceSince 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

8Deus Ex: Where We Ended UpConspiracy TheoryGlobe-hopping, Real World LocationsImmersive Sim – Shooter HybridMultiple Solutions to ProblemsHere’s the game we ended up making.Systemic Level Design

10High ConceptLevel designers can establish gameplay systemically or on a special case basis.Systemic implementation enablesMore intentional, less scripted playDecreases the learning curveMakes bug fixing easierObviously, 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

11Special Case Level Design DefinitionSpecial 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

13Special Case: PlanningExample—Team discusses:Fictional setting of a given level“Look and feel”Placement of units (monsters or characters), weapons, tools or resourcesSpecific puzzles or scripted sequencesDiscussed, but implementation is not detailedNot practicalDifferent designers, different styles/techniquesSystemic Level Design

14Special Case: Tools & Content CreationProperties and parameters for many game elements reside on a per instance basis:Objects with tweaked parametersUnique moving geometry (movers)Special triggersAll cobbled together by each LD individuallySystemic Level Design

15Special Case: Tools & Content CreationExamples:Generic (highly configurable) triggersMoving geometry (generic “movers”)Different LD’s create visually identical “crushing block” puzzles that function differently, with subtle variations.Many editors have hybrid toolsDX1 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

17Special Case: Bug FixingExample—Playtest determines that crushing blast doors add fun.Because each door was set up manually, each door must be visited individually:Takes timeLikely to introduce bugsSystemic Level Design

18Systemic Level Design DefinitionSystemic 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

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

21Systemic: Tools & Content CreationGame 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

22Systemic: Tools & Content CreationExample—Door behavior (3 classes) stored in object property treeNot entered for each of 500 doors by handInformation entered and managed centrallyLD’s select proper door and drop into placeNew door types are added when neededAll doors inherit properties from archetypesObviously, 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

23Systemic: Bug fixingPlaytest 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

24Systemic: Bug fixingExample—Playtest complains that medium doors are not always destroyed by grenades:Medium door strength is lowered globallyNote: 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

27Consistency: Plan FormulationConsistency 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

28Consistency: Plan FormulationExample—LD’s set up blast doors w/ different properties:Crush, Move Speed, Sound VolumeAfter 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

29Consistency: Intuitive BehaviorIf 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

30Consistency: Intuitive BehaviorSystemically 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-characterBurns catBurns dogExample: 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

31Consistency: Learning CurveIf the behaviors of game elements stay consistent:Player spends less time learning the gamePlayer spends more time playing the gameIf 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

32Emergent Gameplay Consistency Emergent Gameplay EfficiencySpecial Case = Per instance basisSystemic = Class-to-class basisEfficiencySpecial 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

33EmergenceEmergent 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

34Emergence DX1 Monsters were more systemic than characters:Monsters were dropped in placeCharacters’ properties were tweakedUrban context: Run when shots firedWarzone context: Crouch when shots firedDX1 Monsters provided more comprehensible, useful emergenceAs 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

35Emergence Example 01Players 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

36Emergence 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

37Consistency Emergent Gameplay EfficiencyA 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

39EfficiencyExample—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

41ShoehorningTwisting 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 visionSometimes needed for player expectationThe 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

42Special Case Squad Mate ExampleDesigners (and testers) wanted a “squad mate” for cell breakIdea made total sense, in contextDX1 lacked “Squad Mate AI”We hacked it in anyway with a bunch of manually placed triggersWhile 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

43Ladies and Gentlemen…MiguelIt met expectation and provided colorIt broke often and was lameSpecial 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

44Systemic Arrow/Pyre ExampleDesigner takes abstract idea and warps it to work with some of the core game systemsPlanting spots become pyresSeeds become water arrowsStealth is employedCore context/fiction is employedThe 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

45UncertaintySystemic 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

46Prox Mine UncertaintyProx mines behaved according to globally consistent rules about relationships between classesPlayer could attach/un-attach prox minesProx mines were physical objectsPlayer could collide w/ physical objectsPlayer didn’t detonate his ownPlayer could climb walls w/ prox minesDegenerative 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

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

48Special Case Prox MineProx 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

49Systemic Prox MineProx 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

50Prox Mine Model ComparisonSystemic 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

51Designer 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

52Designer Perception: Loss of PowerLD 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

53Designer 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

54Designer Perception: Consistency Is BoringGames 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

55Systemic Vs Special Case: Player PerceptionDoug Church:Playing the Game Designer versus Playing the GameOkay, 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

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

57Playing the Game Can be particularly satisfying:Fewer logical breaks in consistencyEnvironment feels rationalPlayer feels free to experimentPlayer feels less manipulatedPlans fail or succeed comprehensiblySurprise: “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

58Some Benefits of Special Case LDVariationOutside Scope of Core MechanicsUnique MomentsStory AdvancementClearly, 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

59Systemic and Special Case ExamplesHeart of DarknessGTA3Platform GamesThese are some interesting examples of games that use one or both forms of gameplay implementation.Systemic Level Design

60Heart of Darkness Great Game Every scene totally special caseAmazing ArtShort Play-timeSimple InterfaceFunEvery scene totally special caseHeart 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

62Heart of Darkness Constant guessworkSometimes up arrow means “climb wall”Sometimes up arrow means “jump”Very narrow range of emergent interactionThe 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

63Heart of Darkness Fun is still possibleHeart of Darkness has different (not inferior) valuesSystemic Level Design

64Grand Theft Auto 3 Game of the Year‘Sandbox’ freedom through simulationPedestrian TrafficVehicle PhysicsDynamic MissionsDamage ModelGoal CompletionEven 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

66GTA3 Cartel Example Goal Completion MethodologySniper Rifle OnlyMust Wait For 8-ballMISSION FAILEDContrasts w/ Goal CompletionThere 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

67Platform Games Games like Mario64, SonicMade up almost entirely of systemic elementsLD’s create gameplay patterns by combining elementsPlatform 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

68Summation: High ConceptLevel designers can establish gameplay systemically or on a special case basis.Systemic implementation enablesMore intentional, less scripted playDecreases the learning curveMakes bug fixing easierObviously, 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

69Summation: Last ThoughtsDesign 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