Search the Community

Showing results for tags 'game design'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Design
    • Projects
    • Design Discussion
    • Tools & Tutorials
  • Off Topic
    • Games Discussion
    • General Discussion
    • Site Support & Feedback

Categories

  • Articles
  • NLD Originals
  • News
  • Projects

Categories

  • Articles
  • NLD Originals
  • News
  • Projects

Blogs

  • NLD Dev Blog

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


About Me

Found 47 results

  1. WAYWO has landed. This is one giant leap for Level Design, one giant leap for Video Games. Or anything else you all deem appropriate to discuss in here, since it is traditional to go way, way, WAY(wo) off topic.... 😉
  2. Review This is one part in a series of articles that attempts to explain how I think when I design. The purpose of these articles is not as much to provide a hands-on practical approach – just to explain how I do stuff. Once I finish this series, I’ll focus on some more practical applications. (Link to Part 4) Important Point from a Previous Article Principle #1: As a game designer, your job is to ask your players Questions. The players’ job is to answer those questions using the Tools you give them. Last Time Last time we identified major weapon, enemy, and terrain Archetypes – some of which we will use in this article. This Time We’re going to talk about how I use the combat Archetypes we made in the previous article to create a series of enemy “Setups.” Note: We’ll talk about how I chain setups together with increasing complexity to form “Ramps” in the next article. Archetypes According to Google, an Archetype is “a very typical example of a certain person or thing,” and that’s how I want to use the term here, but with one difference: Archetype: A very typical example of one of the extreme boundaries of your game’s design. In the following diagram, each of the black dots represents an Archetype. You can see how they all exist at the extreme boundaries of our enemy’s possible powers (Health, Range, and Damage). Note: If these diagrams don’t make sense, check out the last few articles – that’s where we created these. A lot of people ask me why I choose only the extremes, and don’t make “jack of all trades” type enemies. According to Principle #1, our job is to ask players Questions. It’s vital that the player understand what question they’re being asked, otherwise I’ve made it impossible for them to play my game the way I want them to play it (if at all). The closer you get to the extremes of your design space, the clearer players will be on what they’re being asked to do: an enemy that takes 10 hits to kill is MUCH different than one that takes 1, or 5 hits to kill, and so prompts a different response from the player. Example Archetypes I’m going to use four enemy Archetypes, three weapon Archetypes, and all four terrain Archetypes that we went over in the previous two articles. I hope to show how these 11 Archetypes, as representatives of the extremes of your design space, work together to create a series of Questions and Tools that you can ramp up in difficulty over the course of a Path. (We’ll go over Ramps and Paths in later articles). Enemies Four enemy Archetypes: Swarmer – Low Health, Low Damage, Close Range Heavy – High Health, High Damage, Far Range Far – Low Health, High Damage, Far Range Near – High Health, Low Damage, Close Range Our example Archetypal enemies, as found in various games Weapons Three weapon Archetypes: Blaster – Long Range, Direct, Low Damage Flamethrower – Short Range, Direct, High Damage Bomb – Short Range, High Damage, Indirect. Where our four weapon archetypes fall on the view diagram we made in the last article I chose these three as examples because they overlap very nicely with the terrain and enemy archetypes, as I’ll show you later in the article. Terrain Four terrain Archetypes: Flat Gap Ledge Cover Examples of our four major terrain types, based on our “enemy placement” choice field from the previous article Creating an Enemy Setup Using Archetypes An enemy Setup is just a variously sized group of enemies of different Archetypes, placed on varied terrain. Each Setup should ask the player a question. In the combat system we’re creating, every setup asks the same two questions: “Who do you want to attack first and what weapon will you use to do it?” For example, using the Example Archetypes from above: Simple Setup: [2 Near enemies on flat ground] Who do you want to attack first? This setup is basic. It doesn’t really matter which enemy the player attacks first (except that the player may wish to shoot the closest one or target both). What weapon will you use to do it? The bomb or flamethrower may be able to hit both for high damage, so the blaster isn’t as great in this area. Combined Setup: [2 Near enemies on flat ground backed up by 2 Far enemies on ledges.] Who do you want to attack first? The player has to dodge high-damage shots from the Fars while fighting the Near enemies. Because the Far enemies have low health, the player might normally attack them first — but in this case, the ledges they’re on make them less accessible than the two nears. You can see how these questions begin to overlap to create options for the player to choose a weapon. What weapon will you use to do it? The two near enemies have lots of HP, so you’ll want to hit them with the flamethrower or the bomb. The far enemies have little HP, but are inconvenient. The player is encouraged to use a weapon like the bomb (area damage) or the blaster (range) to take them out. Note: If we had ammo in this system, the weapon choice could be even further influenced by how much ammo players have left for each gun when they arrive at this setup. Complex Setup 1: [5 Swarmers backed up by 1 Far enemy with cover and 1 Far enemy on a ledge.] Who do you want to kill first and what weapon will you use to do it? I combined the two questions here because it’s starting to get difficult to describe the answer to one without considering the other. Because they are small fast targets, Swarmers aren’t easily killed with the Blaster. The player would probably want to get all of them with the Flamethrower. The bomb might also be a good pick, if it has enough area of effect to get all the swarmers. Half of the leftmost Far enemy is obscured, making him a harder target for the Blaster, while the one up on the ledge is exposed and would be an easy target for that weapon. The bomb is probably a good pick for the Far enemy behind cover – it can arc over the cover and there’s plenty of floor behind the enemy for the bomb to land and catch the enemy in its area of effect (assuming the bomb has that, of course). You could use the bomb to attack the Far enemy on the right, but as there’s no wall near it and you can’t see the floor, so you’d have to be very accurate with a relatively inaccurate weapon. The blaster is probably best there. Complex Setup 2: [5 Swarmers on flat ground in front of 2 Heavies across a gap. Between you and the swarmers are 2 Near enemies. 2 Far enemies stand on ledges shooting down at you.] Who would YOU attack first? With what? Who do you want to kill first and what weapon will you use to do it? Personally, I’d whip out the Flamethrower and try to take out the Nears and the swarmers, then switch to the blaster to wipe out the Fars. Then I’d run up on the ledge where one of the Fars are standing and fire bombs down at the heavies – but you can see how many options have arisen from these 11 simple tools. Conclusion Once you understand your game design’s extreme edges (which we’ve been working on for the last few articles) you can begin to define archetypes for the various parts of your game like enemies, weapons, terrain, and so forth. By combining the archetypes together, like using letters to form words, you end up with a complexity and depth of meaning that defies the simplicity of the method. (Link to Part 6 - To be Updated) *Note: This article is published with permission from the author, and in accordance with Creative Commons guidelines. Source: http://www.chaoticstupid.com/trinity-5-setups/ Follow Mike Website: www.ongamedesign.net/ Website: http://www.chaoticstupid.com/ Twitter: twitter.com/MikeDodgerStout Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0Dp
  3. Intro This is one part in a series of articles that will attempt to explain how I think when I design. The purpose of these articles is not as much to provide a hands-on practical approach – just to explain how I do things. Once I finish this series, I’ll focus on some more practical applications. (Link to Part 3) Important Points from Previous Articles The Big Principle: A game is fundamentally a conversation between the designer and the player. Principle #1: As a game designer, your job is to ask your players Questions. The players’ job is to answer those questions using the Tools you give them. Principle #2: When the designer creates a challenge to ask the player a Question, the designer must also create Tools for the player to answer it. Game mechanic: A game mechanic is the meeting point of two design ideas: a Question the designer asks the player, and the Tools the player has for answering that question. Choice Field: A collection of spectra all of which describe a single game mechanic. Spectrum: Any two opposing concepts which are the same in nature, but differ in degree. Dimension: A single spectrum inside a choice field. Last Time Last time we looked at a game mechanic that described one possible relationship between Enemy Placements and Weapons: Range vs Horizontal – Weapons that have good Range will solve Horizontal enemy placement problems (gaps), but not necessarily Vertical ones (ledges or cover). Directness vs Height – Indirect weapons are usually very good at solving Vertical enemy placement problems (cover, a ledge, flight). This Time I’m going to talk about the limitations of the choice field drawings I’ve been making – specifically that they do not represent complex relationships between game mechanics very well. I have some diagrams that are great for that, called Chen Diagrams, but I won’t get to those for a few weeks, when we start to talk about meta-game stuff. So for this article, I want to show you how spectra (a plurality of spectrums) relate within a choice field, and how one can view that data in different ways by opening little “windows,” or views into the field. Chromaticity diagram for the CIE 1931 xy. Because spectrum. It’s my hope that by the end of this article, a few of the concepts I’ve been working on for the last few articles should gel together and make sense as a whole. First off Before I can get into the meat of this article, I have to add one more spectrum to the choice field we’ve been building up since last article (the choice field describes a combat system similar to those found in Skylanders or Ratchet and Clank games): HP vs Damage – The player generally wants to use a high damage weapon to take out a high HP enemy. Conversely, the player wants to avoid getting hit by high-damage enemies but can afford to suffer several low damage hits. Note: I’m not describing specifics of our HP or damage systems here. For example, this could describe both a Halo-style “regenerating” health system or a Quake-style “hit-points and health pickups” system. It doesn’t really matter yet, though it will matter a lot later on. For this article we can safely avoid the topic. The important thing is that damage removes HP from players or enemies until they reach 0 HP, then their avatar dies. The Spectra, Unconnected So now we’ve built a rudimentary combat system out of six spectra. For a moment, let’s ignore how they link together dimensionally and just focus on them as separate things: These six spectra make up the combat choice field we’ve been constructing Each of these spectra reveals a potentially interesting aspect of the game’s design. Ideally we’d be able to combine all of these into a nice image that shows us all the extents of our choice field… but there’s a wrinkle. One of the limitations of the diagrams I’ve been using thus far is that drawing a four-dimensional choice field is not really a simple thing to do (just look at these hypercube illustrations as an example of how hard it is). Just adding on a single dimension as we did with 2 and 3 dimensional fields doesn’t work very well, as you see from this image that tries to display all the information we have about weapons: Figure A: This diagram may seem useful, but because directness and damage don’t overlap at all, the diagram is missing all four extremes dealing with both damage and directness. This gets even worse as you add more dimensions. Fortunately, this limitation doesn’t present too much of a problem, since you rarely need that much information at any given time. By regarding two or three of the spectra at a time, we can create “windows” or views into game mechanics that can give us a ton of information. For example, this is one possible view into weapons (notice it’s half of figure A, minus directness): The above diagram shows us eight of our possible weapon archetypes (one per dot). The most obviously useful info we get are the eight archetypal weapons we can create – but it gets better. The important thing I’m trying to show here is how the overlapping of all these spectra create new and interesting choice fields. Each choice field comes with a selection of archetypes (the dots), which represent the extremes of your system. Each weapon is made to answer a question, so by knowing the answer you also can know the question the weapon is built to counteract. This shows us our weapons and enemies are related opposites (Principle #2). By knowing eight possible weapon archetypes, we also know eight possible enemy archetypes. These archetypes don’t represent the full richness of our choice field since many things are missing, but eight weapons and eight enemies is a hell of a start in getting there. I don’t think I’ve ever created a combat game that needed more than four or five enemy archetypes at one time, and three axes tend to be more than enough to give ideas for interesting enemies or weapons. Usually you spread the full richness of your choice field out over the course of your game, so this one choice field view diagram gives you enough information to start creating enemies and weapons. If you create another view into the choice field, for example, to represent the other half of Figure A, it can look like this: Another view diagram that shows more of the weapon choice field — this time we get the missing info about directness. With this data, you can start to see some archetypal ways that weapons can interact with enemy placement (high, low, far, near). I talk a lot about these enemy/environment interactions in my GDC Talk on Skylanders (language warning). This gives you more than enough information to start designing combat setups and even more enemies because you know what tools you’re allowed to use to ask level-design questions in combat: flying enemies, enemies behind cover, enemies on ledges, enemies across gaps, etc. (Link to Part 5) *Note: This article is published with permission from the author, and in accordance with Creative Commons guidelines. Source: http://www.chaoticstupid.com/trinity-4-spectra/ Follow Mike Website: www.ongamedesign.net/ Website: http://www.chaoticstupid.com/ Twitter: twitter.com/MikeDodgerStout Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0Dp
  4. Intro This is one part in a series of articles that will attempt to explain how I think when I design. The purpose of these articles is not as much to provide a hands-on practical approach – just to explain how I do stuff. Once I finish this series, I’ll focus on some more practical applications of this stuff. (Link to Part 2) Important points from the last article The Big Principle: A game is fundamentally a conversation between the designer and the player. Principle #1: As a game designer, your job is to ask your players questions. The players’ job is to answer those questions using the tools you give them. Choice Field: A collection of spectrums all of which describe a single game mechanic. Spectrum: Any two opposing concepts which are the same in nature, but differ in degree. Binary choice: Any two opposing concepts that differ in nature, but are the same in degree. Dimension: An individual spectrum or binary choice within a choice field. Game Mechanics The focus of this article is going to be game mechanics, which I was pretty vague about last time. “Game mechanic” is a term I use a lot differently than some other people who write about game design. I tried to make up a new word, but it made reading and writing this impossible – so I’m going to stick with game mechanic. I’m not trying to say my way of using it is better or anything, just when you hear me say it – this is what I mean. First off, a definition: Game mechanic: A game mechanic is the meeting point of two design ideas: a Question the designer asks the player, and the Tools the player has for answering that question. Each game mechanic contains at least two choice fields – one for the Question and one for the Player Tool that answers it. wrenches… cuz game mechanics!! Another way of saying it is that the Question and the answering Player Tool are two sides of a coin, and the coin’s metal is made out of “game mechanic.” For example, let’s examine one of the game mechanics from the combat system in games like Skylanders: Spyro’s Adventure and Skylanders: Giants or Ratchet and Clank. There are several overlapping mechanics that all affect combat in these systems, but for this article I’m going to focus on just one so you can see how a mechanic’s two choice fields are related to each other Mechanic: Enemy Placement VS Weapons The game mechanic I’m describing here focuses mainly on the interaction between A) where enemies are placed in the game world in relation to other obstacles (Question) and B) the player’s weapons (Tools). Hopefully from this example you can see how both of these are two sides of the same coin – and how both inform each other. Question: Enemy Placement This question asks the player “how do you want to attack me.” By placing the enemy across, on, or behind obstacles – enemies gain an advantage that the player can overcome with good weapon choice. The choice field attached to this game mechanic looks like this: Spectrum #1: Horizontal (near/far) Spectrum #2: Vertical (low/high) Each dot in the diagram represents a type of terrain variance that is an example of the extremes we’ve built into this choice field Flat Terrain (low/close) – Control case. Everything is effective on a flat plane, given no other wrinkles. Horizontal Gap (low/far) – Blocks movement but not projectiles. Ranged enemies placed across gaps have an advantage the player will need tools to overcome. Vertical Ledge(high/close) – Enemies up on a ledge are hard to hit unless the player can get up on the ledge, or has tools to overcome that advantage. Line-of-fire-blocking Cover (high/far) – Blocks some projectiles and affects movement. Enemies placed behind cover are immune to horizontal attacks unless the player moves around it, or has a tool. Each of these represents a question the designer is asking – which requires that the designer give the player tools to handle it. Tools: Weapons In this example, I’m ignoring a number of spectra that exist in this combat system and focusing mainly on two: Range and Directness. Range is how far away the enemy can be from a player before a weapon gets useless. Directness is whether the shot travels directly at the target or takes another indirect route. The choice field attached to this game mechanic looks like this: Spectrum #1: Range (near/far) Spectrum #2: Directness (direct/indirect) Each dot in the diagram is a category of weapon we used in the design of Skylander characters. We chose the categories because they offered players a tool to solve the extremes of enemy placement questions. Note: If you’ve seen my Skylanders GDC talk (link), this might start to sound familiar. EXAMPLES: Close (Short/Direct) – Weapons that do damage very near to the player, like a knife or sword. These are good on a flat plane, or when close to an enemy behind cover. Weird (Short/Indirect) – These attacks usually affect large parts of the combat area with damage coming from nowhere in particular – like flaming skulls raining from the sky. Because this is obviously very powerful, we usually limit it with extra rules: e.g “You have to stand still to use it” would make it worse against close-range enemies. I’ll get into how that works, later in this article series, hopefully. Straight-ahead (Long/Direct) – Weapons that fire projectiles at range. The projectiles fly straight in the direction they’re fired until they hit a wall or a target. These fly over gaps, but are usually bad at hitting guys on ledges or behind cover. Lob (Long/Indirect) – Weapons that fire projectiles in an arc, or otherwise along a non-direct path. These are good for getting up on ledges or behind cover, but may arc over closer enemies. Principle #2: Put Them Both Together Together, these two choice fields make up a single mechanic from a combat system like those in Skylanders, Ratchet, or God of War. There are far more mechanics, which I hope to get into next time, but for now what I want you to see is how the two halves of a mechanic relate to each other. This leads us to Principle #2: When the designer creates a challenge to ask the player a Question, the designer must also create Tools for the player to answer it. The task of designing the one IS the task of designing the other. The player’s abilities and the challenges you create to test those abilities are two sides of the same coin. “Game Mechanic” is the term I’m using to show how the two combine to become basically the same thing. It is possible to design each half of the coin separately, and I hope to explain how to split things up like that later in the series, but for now I just want you to know that it’s pretty difficult if you aren’t careful. (Link to Part 4 - To be Updated) *Note: This article is published with permission from the author, and in accordance with Creative Commons guidelines. Source: http://www.chaoticstupid.com/trinity-part-3-game-mechanics/ Follow Mike Website: www.ongamedesign.net/ Website: http://www.chaoticstupid.com/ Twitter: twitter.com/MikeDodgerStout Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0Dp
  5. Intro This is a part of a series of articles that will attempt to explain how I think when I design – my system, in a way. I’ve somewhat arbitrarily nicknamed it Trinity, and hopefully by the end of the series I’ll be able to explain why I picked that name. The purpose of these articles is not to create a formula, to create a rigid system, or even to suggest that my system is better than another. The whole purpose is just to try to explain, in writing, how I think when I design games. (Link to Part 1) Important points from the last article In the previous article, we went over two important principles: The Big Principle: A game is fundamentally a conversation between the designer and the player. Principle #1: As a game designer, your job is to ask your players questions. The players’ job is to answer those questions using the tools you give them. A Disclaimer At the end of the previous article, I mentioned a concept I call “choice fields.” In this article, I’m going to attempt to explain these to you, but I have to say this first: The subject is really complex, and I’m probably not going to be able to explain every facet in one article. A “Choice” Field. Get it? Eh? Eh? Why do I bother? “Emergence” In order to understand what a Choice Field is for, first I need to explain a decade-old concept: Emergence. In 2002-ish, after Grand Theft Auto 3 (GTA3), the most popular buzzword in the video game business was “emergence,” often in the context of “emergent gameplay.” The term was coined mainly to describe the kind of open-world, “sandbox-y” gameplay that GTA3 was the first to really do well. The term got its name from the way brand new gameplay objectives seemed to “emerge” from the overlapping of small sets of rules and abilities. Play styles that are not part of the game objectives seemed to come out of nowhere, and players found themselves spending tons of time creating goals in the game world for themselves and spending more time doing those than actually finishing the critical path missions. Choice Fields In thinking about how to design Emergence into a game, we can’t think about what kinds of things we “want” to emerge (because then we’re just designing them into the game). Instead, we need to think about how to create the overlapping sets of rules and abilities (questions and answers) that create the environment from which emergence springs. That overlapping set of rules and abilities is what I refer to as a Choice Field. More specifically, though: Choice fields are a collection of spectrums all of which describe a single game mechanic. Game Mechanics Basically a game mechanic is any arbitrary set of “things” in your game. If you can imagine being assigned to work on a thing by your boss, it’s probably a game mechanic. I’m using the term “Game Mechanic” here in an odd way on purpose – since I’m not really looking to get too specific in to what’s inside a game mechanic yet. Example Game Mechanics: An enemy, the player, the level design, the metagame design, the vehicle system… You’ll notice that mechanics can contain other mechanics. This is cool. I really just need a word so I don’t have to keep typing “that thing the choice fields are connected to” over and over again. Spectrums “Spectrum” here refers to any two “opposite” concepts which are the same in nature, but differ in degree. For example, long and short are both measurements of “range” (their nature) but completely opposite in degree. Examples of spectrums: High / Low (Health) Long / Short (Range) Cheap / Expensive (Cost) Fast / Slow (Speed) I want to differentiate spectrums from “binary choices.” Binary choices are two opposites that differ in nature, but are the same in degree. Examples of binary choices (generally avoid these in Choice Fields) Left/Right Yes/No Right/Wrong Binary choices are less useful than spectrums and produce much more limited results. You only get all of one or all of the other. They do not define a spectrum, but rather a fork. When working with Choice Fields, binary choices are useful in certain rare situations, but should generally be avoided. “Dimensions” Each individual set of spectrums in a choice field is called a “dimension.” Choice fields can have any number of dimensions, but they generally have between one and three. I’m not even going to try to explain this without pictures, so I’m going to go through examples of the first three dimensions below, and hope you get the idea. Choice Field Examples 1-Dimensional Choice Fields The simplest choice field is a “one-dimensional” field. Basically it means it only contains a single spectrum or a single binary choice. (This is one exception to the “no binary choice” rule of thumb I mentioned above.) As an example, let’s take the mechanic “Enemy” and the mechanic “Player” and attach a single binary choice to each one: Game Mechanic: Enemy Binary Choice: Alive or Dead Game Mechanic: Player Binary Choice: Alive or Dead Let’s pretend these two resultant choice fields are the only ones in the whole game: An Enemy that kills a Player in one hit, and a Player that can kill an Enemy in one hit. The game designer is asking the question: “Do you want to attack this enemy or not?” The Player has an ability that allows it to kill an enemy. Note: This doesn’t get much more interesting if you substitute spectrums for the binary choices. 2-Dimensional Choice Fields One-dimensional choice fields aren’t super interesting most of the time, so you don’t see them used a lot. More often you’ll see two-dimensional Choice Fields. In a two-dimensional choice field, you take two spectrums and splice them together. This is much easier to see than to describe. Using the same example as above, you end up with a choice field that looks something like this: Game Mechanic: Enemy Spectrum #1: Min HP to Max HP Spectrum #2: Min Damage to Max Damage A Two-Dimensional Choice Field representing an Enemy game mechanic Each dot on the diagram represents an Enemy that is an example of the extremes we’ve built into this Choice Field. Max HP, Min Damage – “Defender” Max HP, Max Damage – “Heavy” Min HP, Max Damage – “Attacker” Min HP, Min Damage – “Swarmer” The designer is now asking the question, “Which of these Enemies do you want to attack first,” and the Player must be supplied with abilities (Weapons) to deal with all four Enemies created by this diagram. The choice field for the player’s Weapon mechanic might look something like this: Adding ammo allows us to differentiate our weapons from each other Each dot on the diagram represents a Weapon that is an example of the extremes we’ve built into this Choice Field Game Mechanic: Weapon Spectrum #1: Min Ammo to Max Ammo Spectrum #2: Min Damage to Max Damage EXAMPLES: (Ammo is represented in these examples as “breakability” – number of times it can be used before it breaks) Max Ammo, Min Damage – “Whiffleball Bat” Max Ammo, Max Damage – “Sword” Min Ammo, Max Damage – “Chainsaw” Min Ammo, Min Damage – “Fragile Stick” So if we assume these two Choice Fields are the only ones in the game, our game now looks like this: We have four Enemies, each of which has different health and damage values. The player has access to four Weapons (A, B, C, and D), each of which has different damage and ammunition values. The player will want to use a high-damage weapon to kill a high-hit point enemy and vice-versa. The addition of the ammunition spectrum makes sure that you can’t use every weapon all the time, and keeps them in balance with the Enemy choice field. You can see how the Enemy and the Player develop their choice fields in parallel. This is done deliberately. You can start with either, but they are both dependent on each other. 3-Dimensional Choice Fields There are a lot of times where a two-dimensional choice field is exactly what you want (I’ll hopefully get into that in later articles), but often you’ll want things to be a bit deeper. I’m imagining that most of you read the description of the game assembled in the previous section and thought something was missing, or felt imbalanced. What was missing is a third dimension. I’ll get right into examples. Let’s take the Enemy mechanic from the previous example and add another dimension to it: Range. Game Mechanic: Enemy Spectrum #1: Min HP to Max HP Spectrum #2: Min Damage to Max Damage Spectrum #3: Min Range to Max Range When you add range, things get more interesting You can see that adding this one dimension once again doubled the number of dots in the diagram. As before, each dot is an example of the extremes we’ve built into this Choice Field. We get four new Enemies out of this (A, B, C, and D) which are the same as the enemies from our two-dimensional example but with the ability to strike at range: Max HP, Min Damage – “Defender” Max HP, Max Damage – “Heavy” Min HP, Max Damage – “Attacker” Min HP, Min Damage – “Swarmer” Again the game would be asking, “Which enemy do you want to attack?” The player would need the ability to deal with Enemies at range, so now there are four more possible weapons in our Weapons mechanic, each capable of striking at range: Max Ammo, Min Damage – “Shotgun” Max Ammo, Max Damage – “Gatling Gun” Min Ammo, Max Damage – “Sniper Rifle Min Ammo, Min Damage – “Pistol” You can see how adding just that one dimension to each of our Choice Fields immediately enriched the available options we have for designing challenges for the player. Caveat Just because there’s a dot in a diagram above, doesn’t mean it’s a good idea to use it. I’ve found the sweet spot is to make a three-dimensional choice field, like examples above, and only use 3-4 of the 8 dots in it at a time (e.g. 3 enemy types per level). You get lots of variety without overwhelming the player with complexity. I’ll explain more in later parts of this series, how I choose which “dots” to keep for a given section of a game. (Link to Part 3) *Note: This article is published with permission from the author, and in accordance with Creative Commons guidelines. Source: http://www.chaoticstupid.com/trinity-part-2-choice-fields/ Follow Mike Website: www.ongamedesign.net/ Website: http://www.chaoticstupid.com/ Twitter: twitter.com/MikeDodgerStout Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0Dp
  6. I love watching Conan O’Brien’s ‘Clueless Gamer’ series. The lovable talk-show host plays the role of video game troglodyte to perfection as he ribs on the needlessly complex pretentiousness of many best-selling games. He rolls his eyes through long cutscenes, chuckles at often juvenile storylines, and hilariously struggles with the game controls. And he kind of has a point. Although not a problem for gaming enthusiasts, the litany of games with high production values, sequels-to-prequels, and story-heavy RPGs are difficult for casual gamers to just pick up and play. The tutorials comprise of walls of text or entire levels that teach you the button combinations and timing needed to conquer that dungeon or find that lost city. And there’s nothing wrong with any of that. But it’s just not conducive to casual play. In this post, we’ll look at a level that serves as a game tutorial with understated brilliance: Level 1–1 in Super Mario Bros. This game is from a time where console wars and Let’s Plays were definitely not part of everyday life. It thus had to be very easy to pick up and play while also being challenging and hard to master. Super Mario Bros. walked that tightrope with elan. Without further ado, letsa go... /// The Opening Screen As soon as you start the game, this is what you see: Pretty standard stuff, right? While it seems quite simple, a deeper look reveals the beads of design sweat poured into this screen: Firstly, the opening screen is devoid of any danger, allowing the player to experiment with Mario’s basic controls and get a feel of what the game is about. This is far removed from, say, the Uncharted games where Nathan Drake usually starts the game hanging from a derailed train, battling pirates on boats, or in bar fights. Awesome as these games are, there’s something calming about starting the game simply and allowing players the freedom to mess around. Secondly, the screen positions Mario on the left with lots of empty space on the right. These design choices help create an affordance and subtly tell the player to move right. Note: Affordance refers to the possibility of an action on an object or the environment. For example, a sidewalk presents the affordance of standing, walking, and running. The fact that Mario stays on the center of the screen for the rest of the game makes his opening positioning on the left even more pronounced. Mario stays in the center of the screen for most of the game… …except in the opening screen It should also be noted that video game budgets weren’t the bottomless pits they are now, and the common elements used for both the bushes and the clouds speaks to Nintendo’s resourcefulness. Boxes and Goombas As Mario plows forward, he is greeted by things both intriguing and intimidating: Once again, there’s much more going on beneath the surface. The properties assigned to each element help differentiate friend from foe in the player’s mind: Let’s look at the box first. It’s stationery and suspended in the air, piquing curiosity rather than raising haunches. It’s also glowing and emblazoned with a huge question mark. These are signifiers that scream: interact with me, I have a surprise for you. And since the player has already used the left and right touch pad controls, the next logical control to use is the up button to make Mario jump into the box and reveal a coin. Note: Signifiers are signals that communicate the methods of interaction possible with an object or the environment. In a way, affordances are assumptions (stemming both from our past experiences and the object’s design) of what interactions are possible, and signifiers are explicit clues that either validate, invalidate, or enhance those assumptions. From the sidewalk example, a sign reading ‘No Running’ is a signifier indicating that the sidewalk is only for standing and walking. Signifiers are also majorly at play when we look at the Goomba. Unlike the stationery box, the Goomba is traveling towards the player. Unlike the glowing question mark that generates curiosity, the Goomba has an angry face that marks it as a potential threat. And just like with the box, the most obvious mode of interaction to vanquish the Goomba is to jump on it. And if the player doesn’t get this, runs into the Goomba, and dies: not much of a problem. The game is restarted to a point just a few screens before, and this time the player is wiser about the course of action. This short cycle of engagement allows the player to learn the basic controls quickly without inducing frustration. And don’t get me wrong, Mario can be a frustrating game at times. But the player has already learned the basic mechanics by that time. It’s as if the game is saying: okay, now that you know what I’m about, show me what you can do. It’s a frustration that makes the player more eager to beat the game, as opposed to making the player rage quit. The joy and inevitability of mushrooms Once the Goomba has been dispensed with and the player knows what to do with boxes, the game delivers its next surprise: Mario creator Shigeru Miyamoto said that he chose a ‘suspicious mushroom’ to make Mario bigger as he thought it was a symbol that would be globally understood. While the signifiers here are a bit more muddled, there are still enough teaching points for the player to imbibe. First, unlike the Goomba that moved towards the player, the mushroom goes right, perhaps giving the impression of getting away from the player and automatically making it more attractive. Second, it falls down from the platform, teaching the player that gravity affects some objects (like Mario and the mushroom) and doesn’t affect others (the boxes and platforms). Third, it hits the green pipe and comes towards Mario, an early lesson in how objects interact with each other in this world. If the player learns this quickly, he/she won’t be surprised to see enemy patrols bookended by pipes later on in the level. This is an early lesson… …to teach this Now, as the mushroom comes towards Mario, the players have two choices, right? Either read the signifiers and run into the mushroom, or give into distrust and jump over the mushroom. But no, the game only gives the illusion of choice here. Whatever the player’s feelings about the mushroom, Mario will run into it. If the player tries to jump over the mushroom, Mario will still bounce off the underside of the platforms and fall into the mushroom. Every single time. If Mario tries to jump over the mushroom… …he will fail And once Mario falls into the mushroom and becomes bigger, the player knows for sure that these particular mushrooms are friends, not foes. The level design here makes up for the questionable signifiers and ensures that players get the benefit of mushrooms and experience the joy of powering up. Teaching through safe training The last point we’ll look at in this post is how Super Mario Bros. teaches players its mechanics by first having them practice it in a safe environment before upping the ante. This is a recurring trend in many levels, and indeed many future Mario games. For example, there’s a series of pipes of increasing length in the first level. This section teaches the player that holding the jump button for longer makes Mario jump higher. And if the player takes time to learn this, fine. There’s solid ground between the three pipes instead of the gaping ravines that follow. There’s minimal punishment for taking time in learning the controls. Teaching Mario how to jump higher Almost immediately afterwards, there are two pyramid-like objects that Mario has to jump over. If the player fails, there’s solid ground between the objects and the exercise can be repeated. Once the player learns this skill, the two pyramid-like objects are repeated, but this time with a pit in between them. Failure will be costlier now, and that’s okay. The rules are on the table and skills are being tested now. That’s what makes the game fun but not frustrating. Learn here… …before applying it here There’s so much more to learn from each Mario level, but this post is already prohibitively long so I’ll end it here. Let me know if I’ve gotten anything wrong (I’m learning too, after all) and share any other examples of great game tutorials that you can think of! References (for some screenshots as well as content ideas): Extra Credits: https://www.youtube.com/watch?v=ZH2wGpEZVgE Eurogamer: https://www.youtube.com/watch?v=zRGRJRUWafY nesplay: https://www.youtube.com/watch?v=ia8bhFoqkVE Source: https://medium.com/@abhishekiyer_25378/the-perfect-game-tutorial-analyzing-super-marios-level-design-92f08c28bdf7 Follow Abhishek Twitter: https://twitter.com/Nickspinkboots Medium: https://medium.com/@abhishekiyer_25378 Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0Dp
  7. Pascal works as a freelance game designer and creative director since 1995. He was commissioned by major studios and publishers including Activision, SCEE, Ubisoft and DICE. In particular, he was Lead Level Designer on the multiplayer versions of both Splinter Cell - Pandora Tomorrow and Chaos Theory, lead game designer on Alone In The Dark - The New Nightmare and Creative Director on Wanted – Weapons of Fate. Leveraging his console design experience, he is also working on mobile games, including freemium ones. His first game for mobile platforms, The One Hope, was published in 2007 by the publishers Gmedia and received the Best In Gaming award at the 2009 Digital Media Awards of Dublin. Proximity, responsiveness, relevance... these are the watchwords of efficient playtests. In the previous installment of this article, I had explored the reasons for the rising importance of playtests in game development. In an industry where games represent increasingly high financial risks for publishers, playtests have come to function as a strong guarantee for quality gameplay. I will share with you today my experience regarding the methodology employed in preparing and conducting them. Heeding the Clients: The Design Teams Foremost, one must be aware of a fundamental say: the role of playtests is not to redo the design in place of the design teams -- for either game or level design. They are instead conducted to help them. This observation is crucial, because it drives the entire approach to playtests. Firstly, we must respect the hard work of the design teams. Having had my own responsibilities in game and level design, I know how difficult it is to make "a good game". We must respect those who put their whole hearts into building the best game possible; we must not scorn or undervalue their work. Secondly, playtests must adapt to the needs of the design teams. Good tuning for maps or gameplay mechanics is often the result of trial and error. Knowing this, designers should require experimentation; playtests can afford them the opportunity to test out their hypotheses regarding design issues, and must therefore adapt to particular needs as they arise. Lastly, playtest results must be made available to the concerned parties as soon as possible, as time allotted for game development is always short. Preparing a Playtest Campaign A playtest campaign generally requires around one month of preparation. We must first define its objectives, because they will determine what types of playtesters we shall have to recruit, the scale of the sessions (1, 2, 4, 8, 12 players), and their duration (from half a day to a full week). We will also have to attend to the logistics as well as the legal framework (non-disclosure agreement, eventual monetary compensation for playtesters when sessions last over a half-day, etc.) And we must, of course, prepare the design teams to effectively utilize the playtests. One does not grow the best crops in dry land; a playtest's effectiveness is rooted in the playtesters themselves. Half the battle in running an effective playtest campaign lies in wisely choosing playtesters, which requires investment of time, energy, and perhaps a bit of money and patience. Recruiting takes time: we must not only hire as many candidates as possible (in order to have a solid pool of playtesters). We must also evaluate them. The purpose of evaluation is obviously to judge the candidate's gaming competence, but also his ability for analysis and self-expression. Evaluation may take several forms. An initial selection can be done through a more or less thorough questionnaire, to be completed by the candidate. The true evaluation, however, must be done during the sessions themselves, where we can observe the candidates at play. We must establish a protocol for obtaining the most consistent results possible. There is no "all-purpose" evaluation protocol; we must also be able to adapt to specific circumstances as the situation mandates. When I built a playtest structure at the Bucarest Ubisoft office, I encountered an interesting problem: we needed playtests for console games, but all the players we could find locally were exclusively PC gamers. I had to set up a specific protocol to evaluate the ease with which our Romanian candidates could adapt to console gaming. Ubisoft's Splinter Cell: Chaos Theory The protocol consisted of briefly explaining the gameplay controls of a complex game (the multi-player mode in Splinter Cell: Chaos Theory), and then setting them loose in the game in order to gauge the speed at which they adapted to the gameplay. This selection method proved to be quite efficient. Candidate selection must therefore be done according to a given playtest campaign's objectives. We may have need of only extremely skilled players who have already mastered the genre, or we may require novices, if the objective is to playtest the accessibility of the game. Communication regarding playtests also takes time. Before candidates can turn up on your doorstep, they must first be made aware of your need. In my experience, while recruiting through generic classified ads will yield a high number of candidates, many will be too young (careful of those labor laws!), and most will be only casual gamers. A good way to recruit experienced players is to make use of forums, gaming clans or specialized stores. It takes much more time but I always got great playtesters this way. In playtesting, quality matters more than quantity! Organizing the Sessions I shall address three aspects of playtest organization: the composition of the team, the preparation of the playtest protocol, and its logistics. Recruiting must start at least four or five days before the session itself. At this stage, the playtest manager already has access to a database of candidates that have already been evaluated or, at least, identified. He can thereby choose his playtesters according to the session's theme. Invites are sent by e-mail. At this point, we realize the importance of having a great number of candidates, since most are not available at will. We must therefore engage in mass-mailing to ensure sufficient availability of playtesters come session day. It is also best to invite at least one more playtester than necessary, since last minute withdrawals are commonplace. It is also usually a good idea to ask playtesters to confirm their presence via e-mail. Protocol setup is an important part of session preparation. Some playtests are organized near the end of the development cycle, to tune up maps or the game system. The protocol for this type of playtest is often straightforward: we must allow the playtesters to play for a maximum of time, note game statistics, and organize open Q&A sessions. The time when playtests are most useful, however, is during earlier stages of the development cycle, when the game system and maps are still in gestation. Let us not forget that the earlier we detect any issues, the easier and cheaper it will be to correct them. During the development of maps for the multiplayer version of Splinter Cell: Chaos Theory, I had organized playtests to evaluate the structure of the then still-embryonic maps. I specifically remember the Aquarius map: By having it tested by highly experienced playtesters, we -- including the level designer who had built the map -- quickly realized that the map was far too large. Having noticed this problem, he immediately rebuilt his map, which took little time as the map was still just a prototype. It took him a few iterations to downsize his map to the optimal size. In the end, Aquarius became one of the game's most popular maps. Ubisoft's Splinter Cell: Pandora Tomorrow Playtests allow us to shed light on many problems and to validate (or invalidate) hypotheses set by the design team. During the development of the multiplayer version of Splinter Cell: Pandora Tomorrow, specific playtests were undertaken with the purpose of tweaking the characteristics of certain pieces of equipment, such as the smoke grenade. The latter is one of the most-used accessories by the spies, since its cloud slows down the spy's opponents (the mercenaries), and it can even put them to sleep if they stay too long in its area of effect. Tuning the smoke grenade's parameters was not so simple -- if its range was too wide, it would be an unstoppable weapon for the attackers (they would simply need to employ a single grenade in a corridor to block any access by their opponents). On the other hand, if the grenade's effect zone were too small, the weapon would be completely useless (defenders have vision modes allowing them partial visibility through the cloud). Finding the right values took us a lot of time. Lastly, to be relevant, protocols must adapt to problems encountered in previous sessions as well as to the test requests put forth by the design team. This commensurability with the development team's needs is one of the hallmarks of a successful playtest. I shall address this point later on. Let us now talk about logistics. Good playtests require a stable build of the game without too many bugs. When directing playtests in the middle of the development cycle, this may be easier said than done. Regardless, the game must be sufficiently stable, and maps must be rid of the most detrimental bugs (such as the inability to climb a ladder, for example). A game delivery protocol must be set up with the development team. The latter must deliver a playtest-ready version of the game to the internal debug team, which will rapidly review the game to ensure that the version is playtestable. When issues arise, cooperation between the debug and development teams will allow for swift corrections of issues, and subsequently the production of a stable version suitable for playtests. Such organizational finesse requires a lot of discipline from all of the teams involved. Another good practice is to prepare a checklist for the level and graphic designers, so that they can make sure that their own maps are free of blocker bugs. Finally, the playtest session manager himself must make sure that the version is indeed playable. Playtest Sessions Playtests are especially instructive when design team personnel attend the sessions; indeed, a game or level designer will base his work on ideas he will formulate upon observing the behavior of the players. However, players do not always react as expected, and we must take their diversity into account. By seeing with his own eyes how real players use equipment or navigate a map's topology, and by asking them the reasons for their behavior at the end of the session, the designer can rapidly make optimizing adjustments -- a demonstration is always more efficient than a long speech! It is thus highly recommended to encourage the designers to attend the playtests. That's why I strongly recommend that playtests should be conducted on the premises of the development studio itself. Remote playtests are valuable for tweaking map and system settings, but less so for playtests on an embryonic game. Obviously, playtest observers must follow certain rules: they must not voice their comments or ask any questions until they are authorized by the playtest session manager, in order to preclude influencing the game session or the playtesters' judgement. If it is desirable for designers to attend the playtests, it is simply essential that the playtest session manager does so. He must not simply organize the session and ask his questions at the end; he must actually watch the playtesters at play. The reason is as follows: early playtests often have a limited number of playtesters, and the problems found are liable to be numerous. This fact is likely to affect the relevancy of feedback received, rendering it inconsistent at best and flat-out contradictory at worst. The manager must take all of this into account, evaluating the relevance of the feedback himself. Note, however, that the involvement of the playtest manager can be cause for controversy. In some cases, a playtest manager must simply behave as a mere observer; in fact, this is generally the best attitude to have during playtests occurring later in the game development, when it is time to fine-tune game system settings. The objective at this point is to collect a maximum of statistical data from a high number of playtesters. By contrast, during early playtesting meant to evaluate the strengths and weaknesses of embryonic maps or game systems, the comparatively low quantity and greater heterogeneity of the collected data require a more aggressive, reactive, and direct involvement on the part of the manager. At this point, he must necessarily "get his hands dirty", as he'll be working with incomplete data. While there is a risk of error here, my experience has shown me that playtest results are actually more concrete at this stage, and thus more useful. My experience amidst one of the best development studios in France has taught me that the playtest manager must be wholly invested in the final quality of the game, and must not be content with being a mere observer. This conclusion once again indicates the need for a close relationship between the playtest and the development teams. Debriefing We thus arrive at the final result of a playtest session. The general idea is to bring the playtest conclusions as quickly as possible to those who most need it -- generally the designers and project leaders. Debriefing may take several forms. First, design team members who observed the playtests may put their most pressing or immediate questions to the playtesters. They often leave the playtesting room with some strong ideas burning in their mind. Then comes the report, which must make a clear distinction between the facts (statistics etc.), opinions from the playtesters, and the manager's own observations and conclusions. Raw data must be provided so that the designers know on which bases the manager drew his conclusions. Putting all the cards on the table is a good way to establish trust with the ones who will read the report. Let us not forget that the purpose of playtests is to improve the game, and not to settle scores. A full-fledged report takes time to compile and to write so a shorter, intermediary debriefing might be needed if the needs for crucial feedbacks is urgent. As a final note, I'll mention that I had begun to experiment at the Milan Ubisoft studio with a protocol allowing a remote office (in another city or even another country) to obtain a hot report on a map playtest. Named D3 for "Debrief Dynamique à Distance" (Remote Dynamic Debrief), this protocol consists in quickly establishing a list of the main open issues, and organizing an online session where the concerned designers (at the development office) and the playtest session managers (at the playtest office) can log on. They can then explore the maps while the playtest team explains the issues with much precision, and all can work together in developing possible solutions. A playtester may even join them, contributing further to the dialogue. Source: https://www.gamasutra.com/view/feature/132377/the_silent_revolution_of_.php Follow Pascal Website: https://www.gamedesignstudio.com/ Twitter: https://twitter.com/pascal_luban?lang=en Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0Dp
  8. Intro This is the first of a series of blog posts which will try to convey my overall design methodology, which I’ve nicknamed Trinity for now. It’s a big task, and I’m not sure how many posts it will take to get there – we’ll have to see as we go. There are two ways I could write this: I could start big and zoom in, or start small and zoom out. If I start big, I start in the realm of abstract principles and, over the course of the series, drill down to show how those principles are applied in practice. The other way (which is the way I’m going to write it) is to start with specifics and, by the time the series is finished, show how all the specifics are just applications of a few generic principles. I like the second way best because I don’t like having arguments, and generic principles are argument magnets. Arguments are hard to avoid without a huge amount of preamble – and so I will start with the preamble and move on over time to the “amble”. The kinds of games I’m discussing There is one overarching principle, though, that I have to state at the beginning. These posts will all grow out of the idea that “a game is fundamentally a conversation between a game’s designer and the game’s players.” I state this not because I believe that is the One True Definition™ of games, or because I think that is the only way a game can be made – but because I am limiting the scope of this series to games which are that way. I’m sure someone can come along and make a great game that doesn’t meet these criteria – and that’s cool. What I’m going to talk about in these articles might even apply to that game, but I have no idea if it will. All the games I’ve ever made or played fit this definition, as far as I’m concerned, so just know all that going into this and take everything with a grain of salt. I hope to demonstrate how it is true at some point, but until then just keep this in your mind as you read the rest of this series and try to see how it applies: A game is fundamentally a conversation between designers and players. Principle #1: Games ask questions, Players answer them Trinity all begins with what I’m calling Principle #1 (not because it’s most important or anything, but because I happened to write it first). As a game designer, your job (in a very practical sense) is asking the players questions. The players’ job is to answer those questions using the tools you give them. I think this is what legendary Game Designer Sid Meier meant when he said that games were a series of interesting choices, only I want you to see it from a slightly different angle: Instead of focusing on the choices, I want to focus on the questions the game asks that cause players to make the choices. It may seem like a small difference, but focusing on choices has a number of knock-on effects. Sid Meier's Civilization IV Focusing on Choices Before I talk about questions, let me give you a couple examples of what I mean by “focusing on choices.” Hopefully this will give you an idea of the knock-on effects I’m trying to avoid by phrasing Principle #1 (designers ask questions and give players tools to answer them) this way. Normally when I see designers approach mechanic design by designing a series of interesting choices, I see something like this: “Do you want to go left, or go right?” The designer here wants players to make choices about their path through a level – ideally choices that result in varied gameplay. Imagine a linear level that forks off two ways, and you have to choose one. Or you’re given dialogue choices between good and evil, etc. There’s nothing really wrong with doing it this way, but I find the results end up being expensive to make, and the player only sees half of the game this way. Even worse, I’ll sometimes see things like this: “Do you want to do it the right way or the wrong way?” Imagine an enemy that can be damaged by two different attacks. Attack A does more damage to the enemy than Attack B. Sure, the player can “choose” between them, but only one is correct – so it’s not really a choice, it’s just rope to hang the player with. There are many other pitfalls I see all the time because a designer focuses more on the choice than on the reason the choice is there in the first place. Focusing on Questions & Answers (AKA Game Mechanics) Think of it this way: The game presents a problem, the player uses a countermeasure. Our job is to design both the problem (question) and the countermeasure (answer) that solves it. You can start with either, but eventually you’ll need to design both. Before I close this first post, I want to walk you through what it’s like to design this way. It’ll become more obvious as the series goes on, but this should give you enough context to make it through to the next post. Let’s take the same problem of the multi-vulnerable enemy I mentioned above. We want the players to have choices in dealing with this enemy, so the enemy needs to ask a question that prompts each answer. The easiest, most used form of this is the enemy with vulnerability states (e.g. When the enemy turns red, Attack A is most effective. When the enemy turns blue, Attack B is most effective). This is very common, but there are other answers too. For example, the enemy could ask a single question, but the best attack to use against it at any given time is based on the context the enemy exists in. Let’s say you have a 1 HP 1 Damage enemy called “Bob” which stands still and shoots at the player. The player has three attacks: One shoots bullets straight ahead (Magic Missile), one does damage over time to everything in a short cone (Cold Spray), and one lobs a projectile into the air that explodes on landing (Fireball). The attacks may have other differences, but for now let’s just consider the range. If the player encounters Bob on a flat plane, any of the three attacks are a good answer. If Bob is behind cover, though, Magic Missile and Cold Spray are useless unless you run around and get a new angle. Fireball, though, could arc over the cover so it’s the best option. If Bob is up on a ledge, the player could aim and shoot with Magic Missile, or try to jump and lob a fireball. If there are two Bobs close together, Cold Spray and Fireball will hit both of them, but Magic Missile will only hit one. The enemy is still asking one question “what’s the best way to attack me” but now we’ve added a meta-question: “Given the terrain, what’s the best way to attack me?” You keep stacking questions and meta-questions on top of each other until your game feels like the player has enough choices in every circumstance. A few things to notice: The goal isn’t to create individual choices, but rather to create a “choice field” (or “design space,” as I’ve heard it called). I’m going to go into these more later, just keep them in mind. The questions and answers can all be very simple. When layered together with other questions (like those asked by a level design’s gaps, ledges, and cover), new answers begin to emerge based on context. I started this example with the attacks and questions already decided to make Principle #1 more clear, but usually you have to decide on these things yourself. In later posts I’ll try to illustrate how I come to decisions like that (it’s complicated) but just remember that the foundation of it all will rest on Principle #1 (designers ask questions and give players tools to answer them). (Link to Part 2) *Note: This article is published with permission from the author, and in accordance with Creative Commons guidelines. Source: http://www.chaoticstupid.com/trinity-a-game-design-methodology-part-1/ Follow Mike Website: www.ongamedesign.net/ Website: http://www.chaoticstupid.com/ Twitter: twitter.com/MikeDodgerStout Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0D
  9. Pascal works as a freelance game designer and creative director since 1995. He was commissioned by major studios and publishers including Activision, SCEE, Ubisoft and DICE. In particular, he was Lead Level Designer on the multiplayer versions of both Splinter Cell - Pandora Tomorrow and Chaos Theory, lead game designer on Alone In The Dark - The New Nightmare and Creative Director on Wanted – Weapons of Fate. Leveraging his console design experience, he is also working on mobile games, including freemium ones. His first game for mobile platforms, The One Hope, was published in 2007 by the publishers Gmedia and received the Best In Gaming award at the 2009 Digital Media Awards of Dublin. There is nothing new about asking testers for their feedback on a game in development. However, the practice of managing playtests by following near-scientific protocols, and of integrating them very early in the development cycle, is a more recent trend. The spread of real playtests in the game development cycle is probably part of this silent revolution; a revolution profoundly affecting the development environment. How? Playtests force game development to center around the players instead of the hopes of the development team. Let's look at the effects of this shifted focus: Playtests allow the identification of gameplay or level design flaws that could elude the grasp of normal testers. After all, testers are always seasoned gamers who are not necessarily representative of the target audience. Who better than a casual gamer to pinpoint issues related to the difficulty curve or the overall understanding of the game? Playtests fulfill a moderator role in situations of disagreement or controversy within the design team. A series of playtests can quickly settle a contested issue by resolving almost any counter-argument or dispute, thereby preventing the disagreement from spiralling into an impasse. Playtesting is also a management tool. The partnership between playtesting and design can be very constructive. For example, it can be quite instructive for game and level designers to observe gameplay during playtesting, allowing them to immediately determine whether or not particular aspects of their design work as planned. Playtests executed on pre-prod mock-ups allow the anticipation of problems very early on, as well as timely corrections of said problems (the faster a problem is corrected in the development cycle, the less expensive it is). Game development can therefore become truly "player-centric". According to the playtest protocol and the selection of playtesters (hardcore, casual, etc.), playtests allow the examination of a specific aspect of the game with heightened acuity: game balance, navigation, understanding of the game objectives, etc. We all have the opportunity to play games that display high production values but nonetheless suffer from obvious flaws: erratic difficulty curve early in the game, navigation issues, overly complex interface, and so on. Such flaws could often have been easily avoided if they had been identified early enough. Major names in the industry understand this quite well, such as Ubisoft, which possesses qualified teams and invest lot of resources in this aspect of game development. What kind of problems might we fix or prevent with playtests? Some examples include: Accessibility and ease of use (interface, navigation within the game, etc.). Identification of sure-fire-wins, i.e. strategies allowing a player to easily overcome any challenge created by the designers and therefore remove any interest in the game or the current mission. This issue is especially sensitive for multiplayer maps. Fine-tuning of the game system: experience has shown me that the intensity of use of game features (weapons, equipment, actions, etc.) tends to vary considerably according to a number of factors. These include player profiles, the time a given player spends on familiarizing himself with the game, and of course the game tuning itself. Only through long-term playtests with relevant samples of players can we ensure that the game tuning maintains its balance and relevance even after long hours of gaming. Analysis of the early reactions of different categories of players during their first session. This will highlight their first impressions and initial frustrations. Some game demos have probably had a negative effect on the marketing of games they were meant to promote because of accessibility and tuning issues that could have easily been spotted during playtesting. For multiplayer games, the robustness of the game system and the potential of maps. I have had several opportunities to delve deeply into playtest management. I built the playtest structure from scratch at the Ubisoft Annecy studio, where the successful multi-player "versus" modes of Splinter Cell: Pandora Tomorrow and Chaos Theory were developed. I set up the recruiting methods, playtest protocols, and the debriefing methods employed in this program. I also set up a playtest cell at the Ubisoft Bucarest office and led playtests there myself. Playtests have changed the way I perceive my job as creative director, so I feel the need to share my experience with everyone. Let us start with a definition. Playtests consist in analyzing the reactions of a representative pool of players toward gameplay in order to improve the final game and to make sure it matches their expectations. Some will argue that game testing is nothing new. True, but real playtests have nothing to do with the debug testing executed at the end of the development cycle. Traditionally, game designers ask testers for their opinions. Testers are often excellent players and are therefore not always representative of the targeted demographic which is often made up of mainstream gamers. Moreover, testers generally get to know a game so deeply that their knowledge of it strengths and weaknesses profoundly influences the way they play. Therefore, they do not play as someone who discovers the game for the first time. Well-executed playtests allow us to evaluate gameplay strengths and weaknesses with great accuracy since they rely on two solid principles: The careful selection of playtesters. The use of ad-hoc protocols. The Selection of Playtesters Just as a peasant needs fertile ground in order to ultimately obtain the best yields, good playtests require a group of carefully-selected playtesters. I could never insist hard enough on the importance of the recruitment and evaluation of the playtest candidates. What are the recruiting criteria? This depends, of course, on what kind of playtests we are planning. We may need hardened gamers, beginners, console-only gamers, multiplayer fans, and so on. The candidate's gaming proficiency and overall game culture represent the first criteria. The second is the candidate's ability for analyzing and drawing conclusions from their gaming experience. Note, however, that it is not mandatory that a playtester should possess a high level of competence on both criteria. Again, the type of playtests will determine the requirements. I have the utmost respect for the playtesters I have worked with. Their good will and enthusiasm are boundless. Many came to Annecy from distant cities like Lyon, Grenoble, or Belfort simply for an unpaid half-day session! This generosity and enthusiasm are characteristics of our industry; let us nurture these characteristics by treating playtesters with the gratitude and respect that they deserve. The Use of Ad-hoc Protocols The protocol is the unifying thread of the playtest session, defining the objectives, allocation of resources, and especially the methods of collecting and parsing information for a given playtest. The playtest protocol needs to adapt to the specifics of the challenge at hand (game system tuning, navigation, map concept, etc.). During the playtest campaigns that I led, I would prepare a different protocol for each session. Indeed, an important part of those playtests involved multiplayer maps under construction or game system tuning. Each session revealed specific problems to be analyzed in the subsequent session. I shall conclude this first part by repeating that a playtest campaign must be directed with a true scientific rigor if it is to be of any use; one does not conduct playtests simply by bringing over one's buddies for a few hours of fun followed by a session of easygoing Q&As. Each aspect of the session must be carefully tailored in order to best realize the objectives at hand. Managing the session itself requires constant attention, not only because one can learn much by watching the playtesters in action, but also because things do not always go as planned! I shall address concrete aspects of playtests in the second part of this article. Source: www.gamasutra.com/view/feature/132355/the_silent_revolution_of_.php Follow Pascal Website: https://www.gamedesignstudio.com/ Twitter: https://twitter.com/pascal_luban?lang=en Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0Dp
  10. Recently through the mysterious and tenuous connections of social media, I was asked a few questions about the game design of Halo multiplayer. Yes, the first Halo. Combat Evolved. Yes, I know that game came out when dinosaurs still roamed the Earth, but there are still a few things about the development process that might be interesting to designers. One question in particular caught my attention: “Was quick-camo intentional?” Paraphrased, I read the question this way: "When the player picks up the Active Camo powerup, they turn invisible. If they shoot while they're invisible, they become visible for a while. But some weapons seem to make the player fade in and then back out of view faster than others. Was that intentional?" The answer is related to one of my Universal Truths of Game Design. The Universal Truths are rules that I have figured out throughout my career in game development. I know they're true, because I have followed these rules and succeeded, and I've ignored them (or just been ignorant of them) and failed. In this case, the answer comes from; UNIVERSAL TRUTH #3: You must create a mental model That means that, as a designer you must create a theoretical model that describes how the systems in the game should act with each other. Game data design and balancing is an incredibly complex task. As anyone who has ever opened up a set of modern game tools knows, there are an overwhelming number of places where a designer can change numbers that can affect how the in-game systems behave. Here’s an example picture of an open game toolset that I grabbed off the web: It’s a pretty typical screenshot of a set of development tools. There are windows that allow the designer to place objects in 3D space, and along the right side of the screen there are a bunch of folders that hold different types of data that you can fiddle with. And adjusting any of the numbers will change what happens in the game. I’ve seen it happen many times, a good game designer is tasked with making the game more fun and, faced with the complexity of that job, gets overwhelmed and doesn’t know what to change to make the gameplay better. At best, a designer stuck in that situation is ineffective. At worst, the game sucks because of them. In my process, I make a mental model of how I think the system should work. It gives me a place to start figuring out what numbers to change, and in what ways I need to change them. From there, I adjust the data values to suit that model. And the more rigorous I am with my mental model, the more confidence I have when I'm adjusting the sea of numbers in front of me. Let me give you an example. As we were working on Halo, the team lead’s first choice was to make the guns work the exact same way in single player and multiplayer. The responsibility for balancing all those numbers had been given to a senior designer on the project, but the general feeling was that his changes were not making the game more fun (see above). I talked things over with Jason Jones (the creative genius at the core of Bungie) and he and I agreed that somebody with more experience in game balance needed to take over the job. Initially, Jason volunteered to handle it all himself. As the man behind the game balance of Myth, and the Marathon series of shooters he was more than capable of the job. But I pointed out that multiplayer would have very different needs for the guns than the single player team. Weapons in the hands of dumb AI bad guys need to provide fun challenges for the player to overcome, but weapons in the hands of a player are a different matter. As a quick demonstration, think about the gunfights in Halo. In most cases, encounters have multiple bad guys shooting at you at one time. Each gun can be adjusted to be a little bit weaker in enemy hands so that player (the hero of the story) doesn't get overwhelmed. But in multiplayer, most decisive fights are one on one. Guns needed to be unique and powerful. I also pointed out that if we just used one set of data, as I was changing the gun data for multiplayer I might be damaging the overall balance of the single player game. Jason agreed, and we decided to "branch" the data and create two versions of the numbers, one for single player and the other for multiplayer. So starting out, I had a handful of guns with some data already attached to them based on the single player game. I had the freedom to change whatever I wanted. All I needed to do was figure out how to make the fighting fun. I needed a roadmap to follow. A mental model. But where to start? Follow this link to read this section of the article: https://www.gamasutra.com/blogs/HardyLeBel/20150105/233483/Universal_Truth_Number_Three_pt1.php But just making the Halo multiplayer weapons respect their roles in the matrix really wasn’t enough. That’s kind of “first-person shooter design 101.” In a first-person shooter, weapons are the stars of the show. They need to look good, and sound good. They need awesome animations. They need to be effective in their roles and they have to make the player feel powerful and competent. But perhaps most importantly, they need to reward player mastery. To accomplish that, the design needed depth. Universal Truth Number Three (Part 2) I characterize depth as game systems or balance details that are included to enrich the experience of the player, but that are not necessarily explained or documented. They’re meant to be discovered and exploited as players’ expertise with the game grows. There are lots of great examples of what I’m talking about in all types of games, but I will offer up a couple of made-up examples for illustration: Example Game 1 is Wizard Warts, a fantasy role-playing game about a cabal of magical toads set deep in a haunted swamp. Pollywogs evolve into acolytes - able to hop, swim, wear armor and use weapons. But once they grow strong enough in the shallow waters around their home, they can quest deep into the swamp to find and eat one of the legendary magic Dragon-Flies. Four different types of Dragon-Fly swarms live in the swamp: Fire, Ice, Poison/Acid and Love. Once a toad gobbles one of them up, the acolyte evolves into a Toadzard, and can thereafter belch spells powered by the type of bug-dragon they gobbled. It’s important to note that an acolyte toad can only gobble one type of magic Dragon-Fly in their life, and the choice (and the evolution into Toadzard) is irreversible. The swamp is filled with a variety of magical monsters. They are all dangerous and hostile, but we can use the data of the game to add more depth to the gameplay. For example there are Plant type monsters are more vulnerable to Fire magic and take x3 damage from any source with that description, while Undead creatures are immune to Poison spells. Notice that one of the Dragon-Flies has two “type” descriptions – Poison/Acid. I chose to include the "acid" description as part of that spell group because of the depth that I wanted to include in the design. Acquiring spell powers and evolving into a Toadzard would be a big part of the fun in the game. But if the player chooses "poison" spells and finds that they are literally useless against undead monsters, and "poison" was the only type of damage in that spell category, it could leave an entire class of Toadzard useless in some situations. That’s a very un-fun outcome to players who chose to build that type of character, and it might make the game unexpectedly difficult. Consider the example of player who decided to make their Toadzard Poison/Acid and then had to take on a tough mission against Undead bad guys. A player running into that situation might have so much difficulty that they abandon the game, and who could blame them? Dropping some "acid" in helps solve these problems. "Acid" spells could still damage undead, leaving us the freedom to make "poison" spells useless against them. At this point you might reasonably ask; "Why fight so hard to preserve that part of the design at all?" The answer is that there is a lot of potential drama in the design that occasionally makes spells useless. It aggressively forces the player to adapt their comfortable play patterns, and it might encourage players to explore more of the content in the game. Imagine the player who finds themselves in a scary predicament when the spells and strategies that they've previously counted on suddenly stop working entirely. But, as they dig into the fullness of the spell systems they find that there is a way for them to adapt to the game situation without having to start over from the beginning. A less aggressive way to achieve a similar effect would be to extend the Fire example above, and only give the monsters vulnerability to some types of spells. So for example we could include Hate type monsters that were vulnerable to Love magic and Lava type monsters that were vulnerable to Ice magic. Anyone familiar with the Pokemon series of games will recognize this precise design. It doesn't penalize players as harshly as the proposed design above, but it's also not as dramatic in the player's experience. Follow this link to read this section of the article: https://www.gamasutra.com/blogs/HardyLeBel/20150112/233956/Universal_Truth_Number_Three_pt2.php The interesting, and sometimes wildly frustrating thing about depth in a design is that some players never become aware of the underlying nuances. In fact there are countless examples where depth is built into games, but players don’t understand it or take advantage of it. Multiplayer games suffer the most from this kind of mismatch in player expertise, because the parts of their community that grasp the deeper elements of the design and use them often have a significant advantage over the less-knowledgeable. This can lead to all sorts of hard feelings. (if you’re a League of Legends fan, last hitting creeps should spring immediately to mind) As I mentioned earlier, depth in the game balance can exist without being documented anywhere else. Players will feel the effects as they play and hopefully they’ll pick up on the subtleties and learn how to exploit the design. But for that to work well the design needs to make some kind of intuitive sense to the player. In the Wizard Warts example, the player would glean that Fire is extra dangerous to plants. That's a common trope in games and of course; wood burns. But the underlying logic that "poison" wouldn’t have an effect on the Undead since they don’t have a working nervous system or circulatory system is less obvious, and so might never make sense to the player base. If the game is popular enough, the players will learn how the numbers work and "play around" them, but they're liable to think there's some kind of a bug in the game. So to recap: We need a mental model with an underlying design for depth which is (hopefully) intuitive to the player. Which brings me back to the multiplayer weapons design process for Halo. I’ll explain how it all connects in my next post! Universal Truth Number Three (Part 3) I wanted the Halo weapons to have depth, so I began thinking about all the guns that were in the matrix. I needed to understand what they were, and how they fit into the design. The Human weapons were easy to understand. I’m a Human, and I know what we use guns for. But the weapons used by the aliens of the Covenant were another matter. The easiest place to start would be to simply say that the alien guns were simply analogs to the Human weapons on the matrix. The pistols, assault rifles etc. could be basically the same, only with different visual presentation. Easy, yes. But that seemed like a huge missed opportunity to add depth and richness to the game. So I started thinking why would the Covenant choose these particular weapons in the first place? We (Humans) have guns. And once guns were developed, Humans developed systems to protect people from bullets (bullet proof vests, riot shields etc.) And then in the relentless march of progress, people invented ways to kill other people inside of their body armor (armor piercing bullets etc.) Remember that at the time there wasn't a lot of settled "lore" about the game story. I decided that in my model, Human Spartan armor was created as a desperate response to the Covenant attacks. It had similar functions, like a personal shield, but was based on different technology. So how about the Covenant? There were some notes about the bad guys and their guns, but the honest truth was that the aliens shot light-up bolts of energy because they looked a lot more visually impressive coming towards the player on screen. If the bad guys shot nearly invisible bullets and you couldn't see them coming at you, it would be a total drag every time you died. But just knowing that they were colored lights wasn't going to help me balance my combat data. Clearly they had guns. And they had an equivalent to our body armor – personal energy shields. I could imagine Covenant warriors facing off against enemies across the universe with their plasma weapons blazing. Or more specifically, their Plasma Rifles. As an poor man's analog to the Human pistol, the Plasma Pistol was a pretty dull thing, only useful as a desperation choice for one of the two gun slots you were limited to. I stared at the various data fields in the Halo toolset for quite a while, trying to imagine what to do with the Plasma Pistol to make it cool. And then a question occurred to me: What if the Covenant had to fight an enemy with shields like their own? Or what if they had to fight themselves? They’d need their own armor-piercing capability. In the Halo tools, every projectile had a “shield damage” value. Most were set so that they would damage shields at a rate that matched the damage that their bullets would do to the player's health bar. None of the projectiles were really aggressively balanced against shields. And you know how I feel about data balance in a matrix! I started to experiment with making Plasma Pistol bullets designed to specifically shred shields. It was a snap to make a projectile that blew them off quickly, but then it seemed overpowered to also make those bullets do good levels of “body” damage as well. Then it occurred to me: maybe the shield-shredding effect could be assigned to a different bullet. The one assigned to the secondary fire-mode for the gun – the overcharge. This proved to be very fun. In my early playtests, I'd grab the Plasma Pistol and use the overcharge specifically to blow up the shields on enemies that I ran across. But it was frustrating when I missed the overcharged shot (full disclosure: I am a much better designer than I am a player) So to compensate, I gave the shield-busting projectile a terrifying amount of magnetism so that it would track towards whatever I shot it at. I loved it – I could overcharge the Plasma Pistol and let the shot fly, and it would whip around corners and blast targets, stripping off their shields just as I came running in behind and mowed 'em down! In the short term, I won a lot of playtest games. Unfortunately, once this tactic became known to other players, battles essentially started with “overcharged salvos” of tracking shots whipping across the battlefield. The only thing you could do was hunker down in cover and wait as the first round of supercharged shots came whipping overhead before you started moving. It was interesting to see how these data adjustments changed player behavior during our playtests, but a bunch of auto-tracking missiles wasn’t very true to the spirit of the Halo combat model which rewards player skill, fire and movement. So alas, the “super tracker” overcharged shots had to go. But I did keep some tracking, to help reduce the frustration of a player using the overcharge trick but missing the shot entirely. So my mental model of bullets/armor/armor piercing was working to create fun combat. But what else could it do for the game? Follow this link to read this section of the article: https://www.gamasutra.com/blogs/HardyLeBel/20150120/234625/Universal_Truth_Number_Three_pt3.php I made one other change under the hood of the Human weapons, which many people don't even realize exists at all. Jason Jones had designed the Human pistol to be the weapon of choice for players at medium/long range. The accuracy, high damage and the limited sniper zoom on the pistol made it a powerful choice for dropping enemies right at the edge of their "AI awareness" bubble, enabling players to pick off one or two targets as the enemies startled into their alert state and then came charging into battle. But it was strong. Damn strong. Frankly, it was too strong for multiplayer. I toyed with damage settings that made the multiplayer pistol weaker than it's single player counterpart. But to be honest, once it was "nerfed" it became a pale shadow of it's single player cousin and using the pistol became a lot less fun. Still, I felt that turning the full power of the pistol loose on the Halo multiplayer "sandbox" unaltered would be opening the door to endless criticism, so I decided to made a subtle change. The single player version of the pistol is "autofire" - meaning that if you hold the trigger down the weapon will repeatedly fire at the precise point you're aiming at. But... that's not true with the multiplayer version of the pistol. I wanted to at least challenge the skill level of players a little more. So the multiplayer version of the Pistol has shot spread. What that means is that, if you simply hold the trigger down and let the pistol automatically fire over and over, each bullet will deviate from the point that you're aiming at. And the amount of deviation will increase with every bullet. I wanted to make it so that players could still use the badass pistol, and it could retain the fun feeling that it had in single the single player game, but only if the player could master the technique of actually pulling the trigger with each individual shot. I still believe that this was a "righteous fix" - meaning that it was justified and the solution was (in my humble opinion) elegant within the restrictions of the established game play. Unfortunately, I lost my nerve a little bit. After all, this was a huge change from the behavior of the single player version of the Pistol. I was worried that players might have to re-train themselves to use the multiplayer version of the gun, which again might lead to huge volumes of outrage from players. So I didn't make the pistol deviate enough while auto-firing. Oh, the shots will spread if you hold the trigger down, but not so much so that you might not still get the head shot that you were aiming at. To this day, not adjusting the spread rate of auto-fire on the multiplayer pistol is one of my regrets. I wasn't aggressive enough! But hey, people still seemed to like the game. One of the things that I’m proudest of is how my mental model for Human and Covenant technologies had profound impacts on the single-player game. For example, the high camouflage ping rate of the Human weapons meant that, even late in the campaign, Human guns were ideal for exposing Covenant bad guys that were cloaked in Active Camouflage shields. A second impact was on the AI development of the game. When the mighty Chris Butcher (AI programmer for Oni and Halo) saw the changes to the Plasma Pistol, it gave him the idea to have the Jackals use the Plasma Pistol in it’s overcharged mode, along with their shields, to greatly differentiate them from the Grunts wielding Plasma Pistols and grenades. I’d like to take a moment here to talk about why I keep using the term “mental model”. You might ask “Shouldn’t the design document cover all of this?” And my answer would be that my design documents have never captured all the details of the game. I find documents valuable in helping me codify my own thinking, and they can occasionally be good tools for communicating a design to the people that are responsible for implementing it. But I've never encountered a game development team that religiously read every document produced by the game designers. And when you're actually knee-deep in making the game, you rarely have the time to fiddle around with keeping all your design documents up-to-date. So my own process has evolved to be very fluid and organic. I start with some clearly stated intentions as to what I want to accomplish with a design, and then start to build it. But along the way, I watch the design evolve and continually evaluate that process. As things happen I’m constantly deciding, “How is thing coming together? Are we going in the right direction, or should we be going another way?” So my paper specs get me started, but beyond that my mental model is constantly evolving. I once read a quote from Tim Schaffer, that I'm going to have to paraphrase heavily because I can't seem to find the original quote. He described the process of making a video game as building a puzzle out of pieces falling in slow motion. But the pieces fall at different speeds and the shape of the puzzle changes, depending on which pieces you get, and which fit. That is a very poetic and accurate description of what my process looks like: I like to toss the pieces up, and every day take a look to see what’s coming together, what’s falling behind and what shape the final form is going to take. (I apologize, but I can't find the quote out there on the web. If you find it please add it to the comments section and I'll edit this post!) So that brings us full circle, back to the one-sentence blurb question that I got via Twitter: was quick camo intentional? Yes; entirely intentional. All of the camouflage behaviors are a product of my mental model for Human and Covenant weapons, and my desire to add depth to the gameplay model for players to discover and exploit. Did it work? As I said before: often players will never know all the details included to add depth to a game. The fact that a person on Twitter was asking about that feature proves that, although my mental model was thorough and effective, it wasn’t so intuitive that players completely understood it, even after a decade of playing the game. But here’s the thing: even if an audience doesn’t understand all of the influences that shape their experience with a work of art, those influences still resonate in their mind at some level. That’s called subtext. When I watch a performance of Cirque du Soleil, I don’t know exactly what’s happening in the overall story of the performance. But I know there is a story. And my experience as an audience member is all the richer for it. There are large sections of the above article omitted here. We strongly recommend you read the articles in full via these links: www.gamasutra.com/blogs/HardyLeBel/20150105/233483/Universal_Truth_Number_Three_pt1.php www.gamasutra.com/blogs/HardyLeBel/20150112/233956/Universal_Truth_Number_Three_pt2.php www.gamasutra.com/blogs/HardyLeBel/20150120/234625/Universal_Truth_Number_Three_pt3.php Follow Hardy Youtube: www.youtube.com/channel/UCRTexStRSiHNR21y4hdx4Yw/videos Twitter: twitter.com/RazdByBears Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0Dp
  11. This article is the first of a two-part series covering theories behind level design, establishing some rules for level creation. The intention is to aid those new to the field who want to design levels for pleasure or pursue a career in level design. Introduction Level design is the data entry and layout portion of the game development cycle. A level is, for all intents and purposes, the same as a mission, stage, map or other venue of player interaction. As a level designer, you are chiefly responsible for the gameplay. This article will give you insight into developing good levels for any type of game, whether they are military missions for your horde of tanks, aerial encounters for a flight simulator, a dungeon for a role-playing game, a board for a puzzle game, or a map for a world conquest god-simulator. I will present some theories behind level design, starting with an exploration of what good level design means. Then it delves into the non-electronic roots of computer game design from chess to GI Joe action figures, and how we can learn from their success. Finally it takes a thorough look into the theories behind storytelling and how we can apply them to level design. Escapism A player buys a game to escape from his or her reality. Good levels and hence good games will immerse the player and suspend their disbelief. From the moment the title screen comes up, you have their full attention. From that point on, they should see and do nothing that reminds them that they are anywhere but in the world you have them in. You must furnish a setting and actors that meet the players’ expectations. That is, you need to design a map that not only looks like it could fit inside the world they are playing in, but contains elements that help to draw that reality in the players’ heads. A player’s sense of escapism and suspension of disbelief can be ruined by a variety of common errors. These include bugs such as graphics glitches or crashes, but from a design standpoint, these also include inappropriate content. For example, a McDonald’s Golden Arches on the skyline of a medieval town is obviously out of context. Similarly, if a player is told by a character to hit control-T on his keyboard to teleport, then it would remind him that he’s typing at a computer and not in some fantasy realm. Generally, to maintain the players’ sense of escapism all content should be appropriate to what would be seen, said or done in the game setting. Challenge – Testing the Players’ Mettle Players buy games to be challenged. If there is no challenge, they might as well be interacting with their word processor or spreadsheet software. Challenge should always come in the form of testing the players’ skills at the core gameplay. A shooter should test their aim and reflexes. A wargame should test their tactics. A strategy game should test their strategic sense. Some games successfully combine forms of gameplay to offer a variety of challenges, such as Command & Conquer, which has both planning/building and tactical gameplay. Command & Conquer Challenge comes from difficulty. The trick to good level design is to present challenges that are difficult enough to merit the players’ attention and make their heart or mind race, but not so difficult as to always leave them failing and disappointed. It’s a delicate balance based on what is perceived as the median player skill, and it is a variable constantly adjusted up until the game ships. Entertainment Like a good television show or book, the game must maintain a player’s interest. The introduction of conflict, the revelation of the setting or back-story, the acquisition of new assets, the display of new art, and the increase in difficulty must all be deliberately spaced to keep the player interested and looking forward to the next level. One boring level can be the kiss of death to a game, especially if it’s one of the first few levels. Game reviewers and most players only give a game that much time before they praise or trash it. Good level designers have learned to be objective about their own creations and when asking themselves, "Is this fun?" The hard part for many designers is that what they find fun may not be what the target market finds fun. As a level designer you need to understand the core gameplay, which is part of the vision expressed by the producers and lead designers. You need to try to understand and become that target market. Something that helps designers tremendously is to play competitors’ games. Often producers and lead designers will name successful games that they are trying to emulate. Play and study those titles. Make sure your levels entertain, thrill and excite you as well or better than the competition’s levels. Frustration can also kill a game. Players stop being entertained when they encounter technical problems like slowdowns or graphics glitches. The level designer can avoid a lot of these bugs if they pay attention to technical limitations and to the instructions of the artists on how to place the art. Designers can, of course, create their very own frustrating bugs, like broken AI scripts or door triggers that never trigger, or missions that don’t always end when they are supposed to. Even worse, designers can create what are commonly called "show stoppers". Show stoppers are unbeatable missions or unsolvable challenges or unavoidable traps that frustrate players. A good level designer can spot these problems and resolve them with careful and rigorous play testing before consumers get their hands on it. Uniqueness Follow the link at the end to read this portion of the article The Roots Of Computer Game Design Follow the link at the end to read this portion of the article Board, Paper & Dice Games Games predate civilization. Some of our oldest games still survive to this day, like mangala (or stones), dice, checkers, tic-tac-toe and chess. What gives them their lasting power? What can we gain from them as designers of complex computer games? Simplicity and elegance. These games keep the gameplay and the rules simple. Almost anyone can grasp them and quickly perceive the strategies and skills necessary to achieve victory. Elegance comes from years of refining the rules and components to maximize and balance the gameplay, and provides lasting entertainment value. Simplicity and elegance should be your goal in level design. So many designers (I being one of them), have fallen into the trap of creating complex games and levels that make it difficult for players to grasp the rules, objectives, strategies and indeed the fun. Designers often fail to play test their level enough to uncover any unbalancing factors and make improvements. So keep it simple, and submit your level to a lot of play testing so you can polish it. There’s a lot more that can be learned from non-computer games, such as the value of symbolism, statistics, and role-playing, but this goes beyond the scope of level design and should be left for a future article on computer game design. Toys – Train Sets, GI Joe and Barbie Follow the link at the end to read this portion of the article Storytelling Follow the link at the end to read this portion of the article Thesis, Antithesis and Synthesis Follow the link at the end to read this portion of the article Understanding and Developing the Thesis in Level Design Follow the link at the end to read this portion of the article Introducing and Refining the Antithesis in Your Level Follow the link at the end to read this portion of the article Synthesis – Making Your Levels End in a Satisfying Tone Follow the link at the end to read this portion of the article Worthwhile Content Stories maintain your interest by presenting worthwhile content. People don’t buy a book or see a movie just to hear characters talk about the weather, unless the weather itself is the villain (as in disaster movies like Twister). All the details that a well-written story contains are those that render the setting, develop the characters or move the plot. While books can get away with including an awful lot of detail, films cannot. Films are aimed at short-attention span people who want to experience the whole story in 90 minutes or less. Films try to focus on the most important details and these usually are the ones involving character interaction. The same can be said with level design, except that you have an even shorter amount of time to tell your story. As a result, you must focus even harder on character interaction details, especially those that involve the player. Everything the player sees or does must further the story. All of the players’ accomplishments should move them toward the completion of the story or pull them further into the conflict with the villain. As the game is played, players should discover more about themselves and their opponents. This can be achieved when players develop new talents, find new weapons or upgrades, gain insight into strategy, or encounter new enemy tactics and new enemy types. All of these suggestions may sound obvious to you, but you would be surprised how often designers make the mistake of spending a lot if time working on setting details that are rarely, if ever, seen by the players. Spending a lot of time working on non-interactive details can be a waste of time and resources, although it’s important to put some effort into it because the player will pay some attention to it. For example, it’s ludicrous to spend a day creating the details of a farm that a player will pass in three seconds on his way to a tank battle. It’s better to just take a minute to sprinkle a few objects that give the player the feel of a farm, like a farmhouse, barn, silo and a few cows. Even if you have all the time in the world to create all sorts of non-interactive details, it’s still not a good idea. Players get distracted and suffer sensory overload from too many details. They also can get frustrated as they try in vain to interact with non-interactive details. Duke Nukem: "Come get some" It would be even better to make all the details of the setting interactive somehow. Duke Nukem did an excellent job of this. Even the toilets had some purpose, if only to give a little humor. The bar had a working pool table and the arcade had a Duke Nukem machine that prompted you to say, "Hmm, I don’t have time to play with myself." The extra effort it took was well worth it. The interactive setting created a great allure and set this game apart from all the other Doom clones. Verisimilitude – When to Stay within the Realm of Probability Verisimilitude is the technical term used by writers to describe the readers’ acceptance of the facts and events within the story. When the story steps out of the realm of probability, the readers get frustrated. Works of fiction must suspend the readers’ disbelief if they want to keep the reader. Readers are only willing to accept so much. How much varies with the reader, which often separates the readers of classical fiction and literature from those of fantasy and science fiction. Computer games have it easy because their target market is much more likely to be readers of science fiction and fantasy. Though the so-called "break through" titles which establish new genres of games often go beyond the sci-fi and fantasy market. Titles like Sim City, Tetris, Civilization, Deer Hunter, and sports games of all types don’t make any grand leaps of logic or fantasy, and they entice players who’ve never shot a single alien. Even so, sci-fi and fantasy oriented games are the vast majority of games made today. Sim City So assuming you are working on a sci-fi or fantasy game, you do have certain latitude (or indeed, a certain obligation) to extend the realm of possibility for the players. But it’s important to know when and where and how far to stretch reality. Players like the realm of possibility extended more for themselves than for other characters. While this seems one-sided, it’s what players want. Players feel cheated if the AI enemy kicks their ass by doing something amazing and beyond their capabilities. They prefer to have their butt kicked by an opponent who’s limited to what they can do. Then they can at least be impressed and comprehend that it is just a skill issue. On the other hand, players enjoy pulling off amazing feats beyond the scope of the AI capabilities and romping the AI for a spell. So give the players what they want. Let them enjoy themselves with a little god-like power. But be aware that giving that ability to players all the time can lead to a dull, unchallenging game. The trick is to balance it so that players don’t always have that edge, either by limiting the use of the ability or by countering it with enemy powers. In an ideal level, the players will face overwhelming odds and overcome them by leaping beyond the apparent realm of possibility. That way they can feel like they have done the impossible and that they’re real heroes. Armed with this understanding of level design theories, you can begin creating your own levels with greater confidence and a clearer insight into what will make them successful. Read the full article here: https://www.gamasutra.com/view/feature/131736/beginning_level_design_part_1.php Read Part 2 of this series next here: Follow Tim Twitter: https://twitter.com/firemuse Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0Dp
  12. The following is a portion of an article called 'The Fundamentals of Game Design', by Raph Koster. Raph is a veteran game designer and creative executive who has worked at EA, Sony, and Disney as well as run his own company. The lead designer and director of massive titles such as Ultima Online and Star Wars Galaxies, he’s also contributed writing, art, music, and programming to many other titles. He is the author of the classic book A Theory of Fun for Game Design. In 2012, he was named an Online Game Legend at the Game Developers Conference Online. Follow the link at the end to read the complete original article. Often people have trouble when conceptualizing a game. The idea, after all, is often the easy part. It’s actually making it, and figuring out where to start, that is the hard part. The Components of a Game The first thing to understand is that games are made out of games. A large game is actually composed of minigames. Even a small game is built out of very very simple small games. The smallest games are ones that are so simple and stupid, you can’t lose. You can think of this as “game atoms,” if you like. For example, in the classic puzzle game Tetris, the basic game is beating your high score. To beat that game, you have to master the game of forming lines. There’s actually multiple variants there, because you have to learn the games of placing all the different sorts of blocks. And finally, the simplest game is rotating a block, which is just a button and hard to screw up. So games are built out of games. This brings us to key piece of advice #1: Advice #1: Design One Game at a Time Even if you are making a complex game, built out of many “game atoms,” each atom is a game in its own right, and has to feel fun and satisfying. Even the stupid ones with no challenge have to feel good. Imagine how poor a game Tetris would be if the stupidly trivial game of “press a button and watch the block spin” wasn’t satisfying. Many games are ruined at this very fundamental level by poor design. For example, a bad designer might have decided that a random chance of the block not rotating would make sense. After all, we use random chance in gambling, board games, and roleplaying games, right? But it would make Tetris unplayable. OK, so you’re going to design one of the game atoms. Luckily, every game atom has the same characteristics: A player does something. The opponent (which might be the computer) calculates a response The player gets feedback. The player learns from this feedback, and gets to do something again. You can think of these steps in very abstract terms: Input Model Feedback Mastery Really, that is it. Let’s apply it to our Tetris example again. At the trivial “rotate a block” level, we have A player hits a button. The computer calculates that this means rotate the L counter-clockwise. The player is given the feedback of the block in its new position. The player figures out “I bet I can do this with other sorts of blocks too. And there’s probably a rotate clockwise button somewhere. Rotating is my goal!” Advice #2: Make Sure The Controls Match Up Well To What The Player Is Attempting To Do At a more advanced level we have A player can rotate left, right, drop a block, glance at the next block, etc. Lots of choices. The computer is going to take its turn and move the block further down regardless, or spawn a new block of a random shape if there isn’t one. The block moves down. Maybe it completes a line, maybe it doesn’t. The player says “aha! Completing lines is my goal, and different shapes help or hinder that!” Notice that if any of these four steps is poorly chosen, the whole game sucks. A player moves the mouse. The computer figures this means rotate a block. The player is not shown the block, but instead a stock quote. The player is baffled and quits. Advice #3: Make Sure The Player Can Actually Learn From The Feedback You Give Them Advice #4: try to stop thinking about what your game looks like, for a moment, and think about what it is actually modeling. Advice #5: check this list for every goal, every objective, every button press, every action a user can take, every decision they make. Advice #6: watch others play your game – you’ll quickly see where you didn’t provide enough feedback, or where they can’t figure out the underlying model. Fundamentally, never forget that if you want to design, you have to just go do it. The only way to get better at it is to keep doing it, because gamemaking is in itself a great and varied game to play. Read more about 3-5 on Raph's Website: https://www.raphkoster.com/2010/10/12/the-fundamentals-of-game-design/ Follow Raph Website: https://www.raphkoster.com/ Twitter: https://twitter.com/raphkoster Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0Dp
  13. The Nature of Order in Game Narrative by Jesse Schell This 2018 GDC talk from Jesse Schell is inspired by the work of Christopher Alexander. He suggests that the wisest way to look at space is with our hearts. Follow Jesse Twitter: https://twitter.com/schellgames Youtube: https://www.youtube.com/user/SchellGamesTV Website: https://www.schellgames.com/ Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0Dp
  14. I want to talk about some problems with player versus player games. In abstract, these problems are difficult to describe, so I want to talk about them through two matches of Halo multiplayer. These are matches where I played with a group of friends against unknown opponents through Halo’s matchmaking system. The specifics of these matches bring the problems of PvP into focus. Derelict Our first match was on “Derelict,” a two-tier octagonal map with a central tower and walkways connecting to an outer ring. Together, the tower and walkways occlude the lower floor into quadrants. The only routes up are through teleports, which deposit the player 45 degrees offset from their entrance, relative to the center. The teleport entrances and exits are in the open, with the best cover being the teleport itself. Green lines indicate teleport paths In the Team Slayer mode where kills equal points, all of the powerups spawn on the top floor. The overshield in the top center is the most important, and also the easiest to contest since the walls around it allow players on the bottom floor to bank grenades. Players who rush the teleports to the top floor have long sightlines down the walkways and past the overshield to the far side. In a coordinated attack, anyone by the overshield is doomed. View from the top floor Most of the player respawn points are on the bottom floor, and Halo’s respawn system favors being near allies rather than away from enemies. This system means that once a team is all on the top floor, dead allies will respawn on the top floor. However, if anyone on a team is on the bottom floor, dead allies are likely to spawn there. With the combination of the item placement and the respawn mechanics, the dominant strategy of “Derelict” is to control the top floor and kill the enemy players as they rush the teleports. Even in Team Slayer, “Derelict” plays like King of the Hill. View View from the bottom floor A final note before I get into the match’s specifics: in Halo, players spawn with an ineffective assault rifle equipped and have to switch to their secondary weapon, the pistol, to have a chance in a fight. This weapon swap means more than a second of vulnerability where the newly-spawned player can’t pressure an attacker to back off. Altogether, these systems turn Team Slayer on “Derelict” into a grinding slog. Match 1 In this specific match on “Derelict,” two of our four opponents dropped from the game within the first minute. By that time, my friends and I had started to control the top floor and the powerups. With only two opponents remaining, this imbalance guaranteed our map control, but this also slowed my team’s score per minute and drew out our inevitable win. After this match, we looked up our opponents’ stats and saw that they were new players with only a few matches of experience. My team’s attempt to efficiently end the match (and get on to something better) may have spoiled Halo 1 to these players. But because there are no easy systems for communicating across teams in Halo, the entire experience was an anonymous cruelty. When players are outnumbered in these situations, some choose to give up the match or “deny” it by preventing the other team from having fun. These players may set the controller down and walk away until the game ends as a passive rejection of the match. Or, in a more active rejection, they may kill their allies, jump off the map, or frag themselves on spawn. This behavior extends the game time, since it slows the rate at which the stronger team can score points, but it is a way for the losing team to control the pace of the game and reject the systems that put them there. Some of the behavior we commonly label toxic play or poor sportsmanship may stem from bad systems design. Even on Halo’s best maps, 4v2 matches are common. In The Master Chief Collection, the queue for Team Slayer lets players vote on a random map from each game in the Halo trilogy, and the original Halo is divisive. Unlike Halo 2 and 3, Halo: CE’s levels are difficult to learn, which adds to the gap between experienced and new players. There are no maps like “Derelict” in Halo’s sequels. As soon as this skill and knowledge difference between the teams becomes apparent, the players on the losing team are stuck in a bad situation. If they leave too many games, they will face an automatic deserter penalty and may also face Xbox Live’s player reporting systems for desertion or bad sportsmanship. As a player, it isn’t clear what many of these systems do. As a designer, it seems to me that the blame should fall on the systems that insisted a 4v2 match play to its end. Even before the match became a 4v2, the blame should fall on the matchmaking instead of the less experienced players. But there’s only so much that matchmaking algorithms can do on a small player population without dividing player parties. In designing these systems, we should ask ourselves who these systems are supposed to serve. Longest After this lopsided victory, our next match went to “Longest”, a small map with two parallel hallways and elevated rooms to either side. There are no rocket launchers or sniper rifles on “Longest”, but the standard grenades and pistols are more effective in the narrow gameplay space. The green lines indicate jump routes between platforms on the second floor At either end of the hallways are a red and blue base, a health pack, and an enclosed ramp up to the second floor. These bases are where the players spawn. Aside from walking the long halls, the only other route is jumping across platforms on the second floor. Up here in the middle there is a powerup on either side, swapping between overshield and active camo after each use. This jump route is outside the lethal range of grenades on the floor below, but Halo’s floaty jump makes these players exposed to pistol fire. A view from blue base down the hall toward red. The overshield is in the top center platform As a result of this structure, the map plays like a teeter-totter of balance swaps. At the start, both teams fight down the long hallways and push toward the far side. The team that wins the fight in the halls can continue the push into the enemy base, and if they kill all of their opponents there, the spawns will swap so that red team now spawns in blue base and blue now spawns in red. This spawn swap resets the fight, giving both teams a chance at a new push. This spawn-swapping property, which emerges as an interaction of the level design and the respawn system, makes “Longest” more forgiving than a map like “Derelict”. Even after a bad start, the losing team on “Longest” has a chance to recover. The limited items also reduce how far ahead the winning team can be. The grenades and health items on the map are only useful to recover to the starting amount. Match 2 Even though “Longest” is a more balanced map, our second match started much like our match on “Derelict”. Within the first minute, two of our opponents left. However, instead of another frustrating victory, I persuaded my teammates to stop shooting and to only use grenades and melee. The grenades are still effective, but players are limited to four, and must then find more grenades in the dangerous midfield, or must charge the enemies in melee combat. There is also friendly-fire, so our over-use of grenades turned the map into a hilarious chaos. Red base, and an exploding grenade, for scale Despite our numbers advantage, by applying our own rule modifier, the opposing team was in the lead until the last few kills at which point we resumed standard play. Our opponents also appeared to join in on our grenade-happy shenanigans, with one of them scoring 10 grenade kills in the match. Most importantly, the opposing players remained active despite the odds, rather than turning to fun-denying strategies. However, across the silent gulf of Xbox Live, I don’t know what our opponents thought, or if they recognized that we had changed the rules of the game to keep it fun. On our side, a few of my teammates saw the rule adaptation as a way to humiliate instead of merely win; perhaps this is how our opponents felt. Without means to communicate across teams, it is unclear whether our rule modification improved the situation. Problems Those with power in a match define its pace. Power here may mean having a numbers advantage, not just being the more skilled group of players. The responsibility falls on the dominant group to adapt their play for everyone’s enjoyment. Reinforcing feedback loops or “snowballing” in level design, where the team that takes the lead can easily maintain it. Rigid PvP systems that don’t match the players’ goals. Rigid multiplayer that lacks communication tools for players to negotiate their goals and restructure the match. Real World PvP With each of these problems, we should compare the situation to real world player versus player games. That is, if we played this matchmade game on the greens of a public park, would we play the game to its end without modification? If not, then this is a case where the rigidity of a digital game’s multiplayer systems does not serve the players’ needs. With these specific examples from Halo, imagine instead if the 8 of us were playing a game of soccer and two players had to leave. In the real world, the game is a servant to its players and will flex to accommodate their needs. The moment two players leave, the remaining 6 can decide if they want to continue with the game, and how they want to restructure the team if so. Or, if the match was more serious, the players can negotiate a rematch for the future. In digital games, the rules are too often inflexible. There aren’t systems in Halo to negotiate a rule change part way through a match. This negotiation could include a mode change, or a team restructure. In both of the 4v2 matches above, Halo could have prompted a vote to make the game free for all, to scramble the teams, to end the match early, or to seek players to join in progress. Existing Solutions? Match join-in-progress. Depending on how quick the enemy team’s numbers can be refilled, and how much of a lead the winning team can take on the map, this solution may come too late to fix the problem. This approach works best where the server persists across multiple matches. Player-controlled voting. In Counter-Strike’s casual servers, players can vote on a map change, on a team scramble, and on player kicking at any point. Most MOBAs let players vote to surrender. However, players can abuse these systems, whether or not the vote-calls are anonymous. Other Solutions? Discourage competitive motivations through the game mode design? Make the match about the kind of play that emerges in player versus player games instead of about winning. Treat PvP as a kind of cooperative play. (Regardless of how the game communicates this, competition is still a motivation players will bring to the game. There may be only so far we can push this solution.) Matchmake by player intent, rather than skill? If a player signals that they don’t care about winning, prioritize matches with others in that category of play-motivation. (Depending on implementation, some players will find ways to abuse this.) Add systems for nonverbal communication between teams? The first step of a negotiation between teams should be to identify and agree upon the problem. Acting upon that problem, such as a calling a vote, should follow from negotiation. Let players leave casual matches without punishment. If too many games are ruined as a result of players leaving, then there are problems in other systems that we need to fix. As a closing note, there is an experiment I want to run. In a game that is otherwise traditional PvP, I want to create an environment with no explicit goals or teams but provide tools and toys for various forms of play. This environment would have bases and flags, hills to be king over, as well as toys like exploding barrels and jump pads. This environment would allow players to set their character color mid-match to form teams. This environment would share voice chat across the entire group, allow the easy formation and dissolution of “team” communication channels, or use proximity-based communication. Better still, this environment would offer tools for players to communicate without relying on the disclosure of voice chat. My hypothesis around this experiment is that we would see healthier player interaction, and we would see player needs rise in priority above competition. Ideally, this experiment would reduce the toxicity that drives players away from PvP gaming. However, it may also be that denying players’ competitive motivations through these systems reduces player engagement and retention. This is an area I hope to investigate further in the future. Thanks for reading! Source: https://andrewyoderdesign.blog/2017/12/28/inflexible-pvp/ *Note: This article is posted in full on Next Level Design with permission from the author Follow Andrew Website: https://andrewyoderdesign.blog/ Twitter: https://twitter.com/Mclogenog Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0D .galleria, .galleria-container { height:480px !important }
  15. Jenova a.k.a. Xinghan Chen or 陈星汉 is the visionary designer of the award-winning games Cloud, flOw, Flower, and most recently Journey. He's also the founder of thatgamecompany. *Note: The following is only a portion of the full article. We highly recommend you follow the link at the end to read the full piece. Video games as a media can be reviewed as two essential components: Game Content - The soul of a video game; a specific experience the game is designed to convey Game System - The body of a video game; an interactive software that communicates Game Content to the players through visuals, audio and interactions When treated as content, the definition of Flow is too broad. However, if applied properly, it can literally happen in every game. In order to make a game special, it requires content that is more sophisticated than Flow experiences. But when treated as a system Flow explains why people prefer certain games more than other games and how they become addicted towards these games. If a game meets all the core elements of Flow, any content could become rewarding, any premise might become engaging. [Sweetser & Wyeth 2005] From the simplicity of Tetris to the complexity of Civilization IV, video games have already proven to the world that anything can be fun if players can access Flow. Expand the Flow Zone Assume the content is attractive to the audience. Designing a video game is very much about how to keep the player in the Flow and eventually be able to finish the game. Therefore, the game system needs to maintain different players' experiences inside the Flow Zone. In Figure 2, the red curve represents an actual experience a player gained through playing one segment of a video game. The player may feel a certain part of the game experience is a little bit harder or easier than their expectation. But he can still tolerate and maintain his Flow experience inside the safe zone. If the actual experience gets too far away from the Flow zone, the negative psychic entropy like anxiety and boredom will break player’s Flow experience (see Figure 3 below). Unfortunately, like fingerprints, different people have different skills and Flow Zones. A well-designed game might keep normal players in Flow, but will not be as effective for hardcore or novice players (see Figure 4 below). For example, a simple action to an FPS player such as shooting, might be an extremely difficult task for a casual gamer just starting a game. Even though the rest of the game might be something that casual gamers enjoy a lot, the harsh beginning just turns them off. In order to design a game for broader audiences, the in-game experience can’t be linear and static. Instead, it needs to offer a wide coverage of potential experiences to fit in different players’ Flow Zones. To expand a game's Flow Zone coverage, the design needs to offer a wide variety of gameplay experiences. From extremely simple tasks to complex problem solving, different players should always be able to find the right amount of challenges to engage during the Flow experience. These options of different gameplay experiences need to be obvious, so that when players first start the game they can easily identify the corresponding gameplay experience and delve into it. Passive Flow Adjustment The biggest dilemma on Flow adjustment is whether or not to create a system to adjust the gameplay for the player. Under this kind of passive system, players can enjoy the Flow experience fed by the system. Much research centers around designing a system that adjusts the difficulty based on the player's performance. This kind of system-oriented DDA works under an iterative adjusting loop. The loop consists of four fundamental elements: Player - Create raw data inside the game through playing Monitor System - Choose critical data reflecting player’s Flow state and pass it over Analysis System. Analysis System - Analyze player's Flow state and notify the Game System about what needs to be changed Game System - Apply changes to the gameplay based on the request from Analysis System Theoretically, this system should be able to maintain player's Flow by constantly reacting to the feedback collected from him. [Bailey & Katchabaw 2005] However, there are still several key unsolved problems , which makes this type of passive flow adjustment hard to implement. No direct data - Video games do not read what player thinks yet. Up until today, the most common connections between players and video games are still going through game controllers. With limited inputs, the possibility to sense player's Flow state directly is very low. Although there are biofeedback devices on the market, people still lack the knowledge for imaging data into Flow and emotions. Most of the measurements are still based on assumptions and incomplete statistics. Performance does not mirror Flow - Video game designers and researchers have figured out ways to estimate player's performance through sampling limited data like “Total Kill”, “Accuracy” and “Headshot”. However, performance is objective while Flow is subjective. When a player is in the Flow of just jumping around in Super Mario Bro but not finishing any level, the DDA system will have trouble to sense that. Analysis based on assumptions - Assumptions never work for mass audience. When a player enjoys performing a suicidal stunt in Grand Theft Auto, it would be ridiculous for a DDA system to assume that the player's skill is too poor because of the death count. Changes are based on rigid design – The way a system adjusts its difficulty is pre-determined by the designer. Different designers use their own preferences when deciding how many changes should be applied; however, the individual preferences of a designer will never represent the preferences of a mass audience. [Costikyan 2004] In addition to the portions included here, Jenova proposed methods of implementing 'Active Flow Adjustment', discusses the impacts and takeaways of playtesting, and shares his thoughts on 'Embedding Choices into Gameplay' as a method of determining a players flow state. Read the full article here: http://jenovachen.info/design-flow Follow Jenova Website: http://jenovachen.info/ Twitter: https://twitter.com/jenovachen?lang=en Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0Dp
  16. One of the really neat things about my job is that I get a lot of time to dissect things that I know intuitively. When I go to help other developers, my job is generally to try to explain why the changes I’m suggesting will make a game better. It’s one thing to intuitively know how something is done, but it’s completely another to explain why. It’s kind of like knowing what a word means and then being asked “why does it mean that?” In the process of teaching myself how to explain the “why” of something, I often learn a whole bunch of new things about it. Most recently, I’ve been thinking hard on the subject of “games as questions.” In a very real way, a game is a series of questions that the game’s designer is asking you (as the player). Because I’m been thinking about it this way, most of my explanations recently have been couched in terms of these “questions from the game to the player” and, interestingly, each question that I come up with can be easily broken down into more and more questions. It’s recursive, or fractal, or whatever… really it’s just that I could easily get lost for a long time thinking in those terms. So I wanted to write some of it down here, so that hopefully I won’t get AS lost. The hard part about that is that I want things I post here to make sense to readers other than myself. To achieve that, I have to lay an awful lot of pipe so that what I’m saying even makes any sense. I have what the author of Zen and the Art of Motorcycle Maintenance would call a “platform problem.” Before I can make any sense of my thoughts to any outside viewer, I have to build a common Platform that we can all stand on to look at those thoughts. If I don’t do that, people look at them from all kinds of angles, the perspectives get messed up, and BAM! Confusion! Creating the Platform is a straightforward thing to do, but very difficult — it’s what makes writing the articles I’ve written so hard, and what makes the topics I can tackle in them so narrowly defined. I want to try and get this stuff out of my head, so I’ll work to make the Platform as solid as I can without driving myself crazy with extra work. If you find that something I’m saying doesn’t make sense to you, or seems weird — it’s probably because I didn’t do a good enough job establishing the Platform, so always feel free to bring up questions in the comments if you want. Okay, disclaimers aside… Recently, the topic I’ve been mulling over a lot is enemy encounter design. It’s the topic I gave a talk on in Canada last week, and it’s been on my mind since. The prep work for the talk once again taught me a whole lot more about it, but this time I’ve also continued to think deeply about encounter design, even long after my speechifying was done. When I examine encounter design in terms of “questions the game asks the player,” I often find myself getting kind of Socratic about it, so let’s call one part of my internal dialogue “Socrates” and the other “Me” (because why the fuck not?): Hopefully the above kind of gets you onto a Platform to view the topic with me. If a game is made up of questions, and the actual ATTACK doesn’t seem to ask a question, that either means that my concept of “a game is a series of questions” needs further examining or that the attack itself asks a question and I need to figure out what that is. Rest assured, I’ll be mulling it over in the days to come. Of course, once I figure that out, then I’ll be need to break all of that down further and start looking at the sub-questions there: If an encounter is a question made up of enemies which are questions made up of “attack questions” and “defense questions”, what questions are each of those made up of? (Did I say the word “question” enough, there?) It’s enough to drive a man sane, I can tell you, but if I ever discover that games are made out of 1-dimensional slices of a 2-dimensional membrane vibrating in 11-dimensional space, then screw that, Socrates — you win! I’m throwing in the towel. I’ll let you know if I get there. Source: www.ongamedesign.net/stuff-im-thinking-about-now/ *Note: This article is shared on Next Level Design with permission from the author. Follow Mike Website: www.ongamedesign.net/ Website: www.chaoticstupid.com Twitter: twitter.com/MikeDodgerStout Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0Dp .galleria, .galleria-container { height:480px !important }
  17. Seth Marinello presents a framework for designing levels or games from square one, from idea generation to blockout. Follow Seth Twitter: https://twitter.com/sethmarinello?lang=en Website: http://www.altereddreams.net/ Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0Dp
  18. Follow Jim Brown Twitter: https://twitter.com/entropicdev?lang=en Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0Dp
  19. The following video series created by Riot Games, maker of League of Legends, covers some of the essential aspects of making a video game. Do You Wanna Make Games? Then watch this series. Here's an overview of the episodes, listed in order: Intro to Game Art Concept Art Character Art Environment Art Technical Art Character Animation Game VFX Sound Design User Interface Design Game Design Episode 1: Intro to Game Art Episode 2: Concept Art Episode 3: Character Art Episode 4: Environment Art Episode 5: Technical Art Episode 6: Character Animation Episode 7: Game VFX Episode 8: Sound Design Episode 9: User Interface Design Episode 10: Game Design Follow Riot Games Youtube: https://www.youtube.com/channel/UCJEGvSZnQ1pkVfHO8s5G8hA Twitter: https://twitter.com/riotgames Website: https://www.riotgames.com/en Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0Dp
  20. Integrity and Game Design by Westin Koessel Is a game really just a game? Or is it something more? In this thought provoking video, Westin Koessel explores these questions, sharing his thoughts on the true impact of games, and the accompanying responsibility designers have to make games built upon a foundation of integrity. Follow Westin Youtube: https://www.youtube.com/channel/UCwVxACgMT67Zq6CkgCtrCdg Twitter: https://twitter.com/_Xandrith Website: https://westinkoessel.wixsite.com/portfolio Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0Dp
  21. Creative Allowance by Westin Koessel Introduction Why was your first time in a Destiny raid remarkably more exciting than your last? Some would cite Destiny's 'feel' juxtaposed with the franchises notoriously shallow systems as the culprit for the dopaminergic delta. Some would hearken back to the good ol' days of Destiny, when raids like the Vault of Glass were apparently just 'better' than they are now. Others might even blame our inevitable disappointment on the games so-called 'overreliance' on repetition. Whatever you think the reason is, I'm here to tell you why I probably disagree. Not just about Destiny, but more specifically about the real reason any game stagnates. The best design never makes a choice for the player. Get it? No? Okay. I'll do my best to explain why this is relevant as simply as I can. If there exists an invariably 'correct' way to play a raid, or game, or class, or even map, the player is subsequently robbed of his/her free choice and only needs to acquiesce to succeed. As long as one or even multiple predetermined ideas are forced on a player, the player is not an influential factor. He's just a warm body, on his way to the factory we call 'modern video game design' to pull a lever the very same way he pulled it yesterday. Yes, some are better and more efficient at pulling that lever than others, but that's why things get stale. That's the real reason Destiny raids aren't as fun as they once were. When you load up a raid, and you're killing a big ass knight for the 30'th time, what are the quantifiable differences between this run and your first? Well, for starters, you've already killed this boss. As I stated earlier, Some will likely argue the point of repetition, so I'll preemptively indulge. Repetition is only detrimental if every cycle is the same as the one before it. To quote a famous Romanian level designer, your map only starts to stagnate when it's played the same way over and over. Repetition is actually a boon for a designer who knows how to wield its potential. It can create a beautiful dynamic where the meta for any given game or map evolves over time. It's rare, but I've seen it. Rocket League and Melee come to mind. That's why we can't blame stagnation on reiteration alone. The foundational design theory of an experience is what matters, and I can give some examples. Imagine you're going to play The Vault of Glass. Right off the start, you have to activate and defend 3 spires by standing in them, and deterring enemies from resetting your progress. That's it. There aren't any exceptions. Once your team has figured out what Bungie wanted you to do, that's the end of your neural activity. From then on, it's muscle memory training. In a couple weeks (if that) you will have experienced everything the raid has to offer, because every encounter passed that is designed the exact same way. Even if execution is incredibly hard, you know what to do. There is no more exploration, there is no more theory crafting. You stand here, and if you die, you change nothing and do it again. See what I mean? Good Design doesn't force these choices on people. If these encounters were designed differently, they could potentially evolve and hold replay value over long periods of time as people discover and create new strategies, as well as potentially new areas via similarly open-ended levels. Cooldowns & Systems First of all, cooldowns are a silly way to balance something. You can't give an ability integrity just by slapping on an arbitrary 14 second timer. As far as the grand scheme of a game goes, cooldowns DO balance the overall pacing and predictability of any given title. In that way, a game like Overwatch is balanced. On the other hand, you can't take something that's over-rewarding and make it okay just by making it rare. If it's stupid, it's stupid. Could one consider a tactical nuke 'balanced' if you gave it a 1 minute long cooldown? No? How about 10 minutes? It doesn't matter. If it's better than it is hard, then it's not right. In the very same way, the multitude of 'I win' buttons in games like Overwatch and Destiny aren't balanced. I don't care how long you have to wait between uses. Inversely, If a mechanic has integrity, it doesn't necessarily need a timer. This isn't to say that I think you should be able to spam everything all the time. That's not the point. The point is that you could design abilities in a way that allows the player to choose between them, which is intentionally allocated space for creativity. Systems, on the other hand, are often packaged and communicated by the developer in a way that makes us think we have creative control. A designer will say something like 'you can do x' as if you're being allowed the freedom to do 'x', when in reality, the system was designed in a way that the only choice you have is 'x'. Things like the ability to meat shield in Gears of War 4, the ability to spartan charge in Halo after sprinting, or vaulting in PUBG come to mind. They were designed to seem like you can do more, when in reality, if anything, your options have decreased after implementation. In the same way, the lead level designer for God of War admitted to 'tricking' the player into feeling like he could explore, when in reality he knew you couldn't. Faux design is everywhere, and it all wants to look like the real thing. Is it deep, or convoluted? Let's look at a game like World of Warcraft. I often hear WoW combat referred to as one of the deepest gameplay loops of all time, but is it? I don't really think so anymore. While It took me years of playing the game to realize, WoW eventually fell right under the category of design theory I'll start calling 'predeterminism.' Once you learn every ability, every quirk, and get proficient at every ability and even every class (barring how ridiculously long this takes) it becomes apparent. Especially in the highest level of pvp. The best players literally always know what the other player is about to do. Every pro match could be boiled down to players who are all excellent at their ability 'rotations' and excellent at punishing mistakes in those rotations. That's how players win games. They don't 'make plays' because the game won't allow them to. They simply have to manage what they have better than the other team, and pounce when the opposition makes a mistake. There are no 'surprises' at even the highest level of play, because the game is just that limiting. It still takes a tremendous amount of skill because of just how many things you have to track, but at the end of the day, that's convoluted. It's hard, and impressive, but convoluted. There are a few reasons for this. First of all, there is absolutely no overlap in utility within the sandbox of abilites. For example, every class has an 'interrupt' ability that literally only interrupts casts. Multiply this straightforward utility times 30 or 40 and you have a class in WoW. Some abilites do damage, some are defensive, whatever. This system means that I'm never actually presented with many real choices. If I want to interrupt someone, I press interrupt. Combine this system with a game where there is no aiming, and only an effectively 2d space, and you actually end up with a super shallow and thought discouraging game that usually rewards the person who has put himself through more hours than the other person just to learn how to 'play correctly.' Intentionality & Player Creativity With those many examples in mind, you may be asking yourself how one might go about preventing 'predeterminism' within his/her map or game, and maybe more importantly, how can one design with intent and still allow for individual creativity? To be frank, I'm still trying to figure this one out myself. I have ideas, some even well implemented and successful, but this is an incredibly hard thing to nail down into one sentence, although I am positive that such a sentence could exist. For now, I will try my best to provide pointers and examples. First of all, you need to build your map or game from the ground up with merit serving as your standardized currency. If you want something that's crazy powerful, that's fine, just make sure it's crazy hard. If you commit to this philosophy, you are paving the way for true creativity to shine, because no matter what insane things people eventually come up with, you can bet it will be hard to compensate and that you won't have to touch it. And remember, adding a cooldown to something that isn't balanced doesn't actually mend your design, it just makes that unbalanced ability happen less. Second of all, you do need to design counters within your map or sandbox. This might sound contradictory, but creativity only exists and is only necessary within set limitations. The trick is to just never force a player into using your predetermined and intentionally designed counters. If the only way to succeed in any given situation is to simply obey the design, you've gone too far. Third of all, you need utility overlap. If every part of your map, or every ability, or every weapon in your game only serves one purpose, then the player doesn't really get to think any more than 'this does this.' There's no choice, contemplation, or forward thinking. Imagine a gun that also knocks you backwards when you shoot it, which would overlap movement and offensive utility. Fourth of all, keep it simple. While the phrase 'easy to learn, hard to master' is overused at this point, it still rings true as the ultimate goal. If you design a simple, open ended toolkit that only limits the player by what his own ability allows, then you don't have to worry about adding artificial depth via complications, cooldowns, or gameplay systems. Lastly, always allow for the potential of swift counter-play. People constantly cite the longer kill times in Halo as the reason for the good players ability to turn the tides of a seemingly lost battle through sheer skill, but that idea has been long since debunked. What really allows a good player to turn on an enemy, or even take out multiple enemies, is the potential for brevity. In Halo's case, the magnums perfect time to kill compared to its average time to kill is the source of this potential, along with the ability to dodge bullets. It doesn't matter how long or short fights are, what matters is that I can kill you faster than you can kill me, if I play better than you. Apply this theory to everything, including counter play opportunities in level design. If I'm good enough at something, I should be able to do it quickly, or at least faster than someone else. Conclusion Once players learn the "right" way to play an encounter, a map, a class, or game, there is no longer any room for creative thought. The highest level will revolve around executing the already present and built in "correct" way to play. To avoid this, balance your design with player merit as your proverbial currency, create overlap in utility within your sandbox, and allow for swift counter-play. The best design never makes a choice for the player, but rather presents choice. We are facilitators, not dictators. Follow Westin Youtube: https://www.youtube.com/channel/UCwVxACgMT67Zq6CkgCtrCdg Twitter: https://twitter.com/_Xandrith Website: https://westinkoessel.wixsite.com/portfolio Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0Dp
  22. Is a game really just a game? Or is it something more? In this thought provoking video, Westin Koessel explores these questions, sharing his thoughts on the true impact of games, and the accompanying responsibility designers have to make games built upon a foundation of integrity. Follow Westin Youtube: https://www.youtube.com/channel/UCwVxACgMT67Zq6CkgCtrCdg Twitter: https://twitter.com/_Xandrith Website: https://westinkoessel.wixsite.com/portfolio Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0Dp
  23. We're overjoyed to bring you our very first Next Level Design interview with Max Pears, a level designer who's been in the gaming industry for several years. Sit down and relax as you read through our conversation with the Level Design Lobby founder, learning about his gaming background from childhood to present day. In the process you'll get to know him, and learn about what has motivated him to share his knowledge and experiences with his fellow level and game designers. NLD: Let's start at the beginning. What was your youth like? What sort of hobbies and activities did you participate in when you were growing up? Max: My life before games was the same as many to be honest. I played games a lot, I did quite a bit of theatre, played basketball but due to the fact that I’m very small the career never kicked off aha. NLD: Sadly, I can relate... Obviously gaming became an interest for you at some point along the way. Do you have any particular memories around gaming from your childhood? Max: Games have always been a big part of my life. My father was a huge gamer before me and he will always tell me this story: When the PlayStation 1 first came out he was unable to reserve the console, but he was put on a list for those who would be notified if any would be spare. He gets a call around lunchtime from a store informing him they have one but he needs to arrive ASAP or it would be sold. With this information he tells his boss that he has to leave early as me and my brother were sick (a total lie) in order to get the PlayStation, ahaha that always makes me laugh but it just shows how they have always been there. NLD: Do you remember when and why you started thinking about game design and level design? Max: I knew I wanted to get into games at a very young age. I used to walk around school with game guides and read them when I got a chance (please kids don't read them during class though). I had part time jobs as a paper boy, shop assistant and kitchen porter, but I knew I always wanted to make video games. The first game which inspired me was Metal Gear Solid. One of my most vivid memories was running up the stairs as a child to see my dad and uncle playing it. At the time, seeing a robot ninja, it blew me away. Not only that, but seeing how my dad pressed a button and then it having an effect, it was incredible. Ever since that game I was hooked, and played as much as I could. What drew me to making games was that feeling I got when playing a game - how it can take you on an emotional roller-coaster. One minute relaxed, as you have a sense of awe when being transported to other worlds you might not have been able to imagine. To then feeling your whole body tense with tension as you try frantically to solve a puzzle or beat a boss. I always felt games were the medium that could truly reach us like no other. Ever since that, I have been trying to make others feel like this, trying to emotionally connect players to the games that I make. NLD: Speaking of the games you make... Eventually you made it, obviously - you got into the gaming industry. What kind of projects have you worked on so far, and has it lived up to your expectations? Max: Yeah, for those who do not know me (which I imagine is quite a lot), I have been making games professionally now for over 5 years, coming up on 6. I have worked on a range of titles from Mobile, Augmented Reality, indie, and now currently AAA. Truly for such a short span of a career it’s been great fun to work and do all of these amazing projects as each one has many things to learn and get better from. The first game I shipped was a game called High Rise - it was for Mobile platform, in which players had a crane that moved left to right and players had to tap the screen in order to time when to stack the blocks to build the highest tower. My last released project was the DLC for Ubisofts The Division called Division Undergorund. As you can see that they are very different games. Funny when you look back as for every game there are many lessons you take away and other things you wish you could add or even finish for those games. NLD: Wow, that IS an interesting mix of games, and it sounds like you've learned a lot from them. Here at Next Level Design, we first became aware of you through your work on the Youtube channel Level Design Lobby. What is the channel all about, and what possessed you to start it? Max: Level design lobby, yes that is the name of my podcast and it’s been going on for over a year now which I’m really proud of, and people seem to be enjoying it which makes me happy. I started the podcast for a couple of reasons. One is because there is so many lessons which I have learnt, and it is hard to keep in my head so it is my own personal journal which I can look back to when I make a game (despite me never really getting comfortable with my own voice aha). The second reason is that I find there is not many resources about level or games design and even less from actual professionals who have worked on games. Which is why I like your site mate, you have a brilliant place for all of us to visit and learn from so thank you for putting it all together my man. But yes, so when I was trying to break into the industry a lot of conferences focused on art and animation, as to be honest they are much easier on the eyes and easier to understand from a visual perspective. So this is my way to give back to those who want to break into the industry. Level Design Lobby - Ep 31: Core Mechanics This has been one of my personal favorite episodes to record so I hope you love it as much as I did creating it. I break down how to make a core mechanic important to your game design. Looking into ways to make it memorable to the players. As I take a deep dive into two fantastic mechanics we can all learn from. NLD: Are there any subjects you’d like to cover on Level Design Lobby that you haven’t had the opportunity to get to yet? Max: Yes, I am excited as I am going to be doing deep dives into levels more in which I select a level from a game and while playing it I will start to deconstruct it. They will be coming to twitch and youtube shortly. NLD: Fantastic! Max, thank you very much letting us get to know you. We can't wait to see what the future brings for Level Design Lobby. Follow Level Design Lobby Youtube: https://www.youtube.com/channel/UCncCrL2AVwpp7NJEG2lhG9Q Spotify: https://open.spotify.com/show/03OTDRAPsAiocSLCTEiXBn Follow Max Website: http://www.maxpears.com/ Twitter: https://twitter.com/maxpears
  24. Introduction Why was your first time in a Destiny raid remarkably more exciting than your last? Some would cite Destiny's 'feel' juxtaposed with the franchises notoriously shallow systems as the culprit for the dopaminergic delta. Some would hearken back to the good ol' days of Destiny, when raids like the Vault of Glass were apparently just 'better' than they are now. Others might even blame our inevitable disappointment on the games so-called 'overreliance' on repetition. Whatever you think the reason is, I'm here to tell you why I probably disagree. Not just about Destiny, but more specifically about the real reason any game stagnates. The best design never makes a choice for the player. Get it? No? Okay. I'll do my best to explain why this is relevant as simply as I can. If there exists an invariably 'correct' way to play a raid, or game, or class, or even map, the player is subsequently robbed of his/her free choice and only needs to acquiesce to succeed. As long as one or even multiple predetermined ideas are forced on a player, the player is not an influential factor. He's just a warm body, on his way to the factory we call 'modern video game design' to pull a lever the very same way he pulled it yesterday. Yes, some are better and more efficient at pulling that lever than others, but that's why things get stale. That's the real reason Destiny raids aren't as fun as they once were. When you load up a raid, and you're killing a big ass knight for the 30'th time, what are the quantifiable differences between this run and your first? Well, for starters, you've already killed this boss. As I stated earlier, Some will likely argue the point of repetition, so I'll preemptively indulge. Repetition is only detrimental if every cycle is the same as the one before it. To quote a famous Romanian level designer, your map only starts to stagnate when it's played the same way over and over. Repetition is actually a boon for a designer who knows how to wield its potential. It can create a beautiful dynamic where the meta for any given game or map evolves over time. It's rare, but I've seen it. Rocket League and Melee come to mind. That's why we can't blame stagnation on reiteration alone. The foundational design theory of an experience is what matters, and I can give some examples. Imagine you're going to play The Vault of Glass. Right off the start, you have to activate and defend 3 spires by standing in them, and deterring enemies from resetting your progress. That's it. There aren't any exceptions. Once your team has figured out what Bungie wanted you to do, that's the end of your neural activity. From then on, it's muscle memory training. In a couple weeks (if that) you will have experienced everything the raid has to offer, because every encounter passed that is designed the exact same way. Even if execution is incredibly hard, you know what to do. There is no more exploration, there is no more theory crafting. You stand here, and if you die, you change nothing and do it again. See what I mean? Good Design doesn't force these choices on people. If these encounters were designed differently, they could potentially evolve and hold replay value over long periods of time as people discover and create new strategies, as well as potentially new areas via similarly open-ended levels. Cooldowns & Systems First of all, cooldowns are a silly way to balance something. You can't give an ability integrity just by slapping on an arbitrary 14 second timer. As far as the grand scheme of a game goes, cooldowns DO balance the overall pacing and predictability of any given title. In that way, a game like Overwatch is balanced. On the other hand, you can't take something that's over-rewarding and make it okay just by making it rare. If it's stupid, it's stupid. Could one consider a tactical nuke 'balanced' if you gave it a 1 minute long cooldown? No? How about 10 minutes? It doesn't matter. If it's better than it is hard, then it's not right. In the very same way, the multitude of 'I win' buttons in games like Overwatch and Destiny aren't balanced. I don't care how long you have to wait between uses. Inversely, If a mechanic has integrity, it doesn't necessarily need a timer. This isn't to say that I think you should be able to spam everything all the time. That's not the point. The point is that you could design abilities in a way that allows the player to choose between them, which is intentionally allocated space for creativity. Systems, on the other hand, are often packaged and communicated by the developer in a way that makes us think we have creative control. A designer will say something like 'you can do x' as if you're being allowed the freedom to do 'x', when in reality, the system was designed in a way that the only choice you have is 'x'. Things like the ability to meat shield in Gears of War 4, the ability to spartan charge in Halo after sprinting, or vaulting in PUBG come to mind. They were designed to seem like you can do more, when in reality, if anything, your options have decreased after implementation. In the same way, the lead level designer for God of War admitted to 'tricking' the player into feeling like he could explore, when in reality he knew you couldn't. Faux design is everywhere, and it all wants to look like the real thing. Is it deep, or convoluted? Let's look at a game like World of Warcraft. I often hear WoW combat referred to as one of the deepest gameplay loops of all time, but is it? I don't really think so anymore. While It took me years of playing the game to realize, WoW eventually fell right under the category of design theory I'll start calling 'predeterminism.' Once you learn every ability, every quirk, and get proficient at every ability and even every class (barring how ridiculously long this takes) it becomes apparent. Especially in the highest level of pvp. The best players literally always know what the other player is about to do. Every pro match could be boiled down to players who are all excellent at their ability 'rotations' and excellent at punishing mistakes in those rotations. That's how players win games. They don't 'make plays' because the game won't allow them to. They simply have to manage what they have better than the other team, and pounce when the opposition makes a mistake. There are no 'surprises' at even the highest level of play, because the game is just that limiting. It still takes a tremendous amount of skill because of just how many things you have to track, but at the end of the day, that's convoluted. It's hard, and impressive, but convoluted. There are a few reasons for this. First of all, there is absolutely no overlap in utility within the sandbox of abilites. For example, every class has an 'interrupt' ability that literally only interrupts casts. Multiply this straightforward utility times 30 or 40 and you have a class in WoW. Some abilites do damage, some are defensive, whatever. This system means that I'm never actually presented with many real choices. If I want to interrupt someone, I press interrupt. Combine this system with a game where there is no aiming, and only an effectively 2d space, and you actually end up with a super shallow and thought discouraging game that usually rewards the person who has put himself through more hours than the other person just to learn how to 'play correctly.' Intentionality & Player Creativity With those many examples in mind, you may be asking yourself how one might go about preventing 'predeterminism' within his/her map or game, and maybe more importantly, how can one design with intent and still allow for individual creativity? To be frank, I'm still trying to figure this one out myself. I have ideas, some even well implemented and successful, but this is an incredibly hard thing to nail down into one sentence, although I am positive that such a sentence could exist. For now, I will try my best to provide pointers and examples. First of all, you need to build your map or game from the ground up with merit serving as your standardized currency. If you want something that's crazy powerful, that's fine, just make sure it's crazy hard. If you commit to this philosophy, you are paving the way for true creativity to shine, because no matter what insane things people eventually come up with, you can bet it will be hard to compensate and that you won't have to touch it. And remember, adding a cooldown to something that isn't balanced doesn't actually mend your design, it just makes that unbalanced ability happen less. Second of all, you do need to design counters within your map or sandbox. This might sound contradictory, but creativity only exists and is only necessary within set limitations. The trick is to just never force a player into using your predetermined and intentionally designed counters. If the only way to succeed in any given situation is to simply obey the design, you've gone too far. Third of all, you need utility overlap. If every part of your map, or every ability, or every weapon in your game only serves one purpose, then the player doesn't really get to think any more than 'this does this.' There's no choice, contemplation, or forward thinking. Imagine a gun that also knocks you backwards when you shoot it, which would overlap movement and offensive utility. Fourth of all, keep it simple. While the phrase 'easy to learn, hard to master' is overused at this point, it still rings true as the ultimate goal. If you design a simple, open ended toolkit that only limits the player by what his own ability allows, then you don't have to worry about adding artificial depth via complications, cooldowns, or gameplay systems. Lastly, always allow for the potential of swift counter-play. People constantly cite the longer kill times in Halo as the reason for the good players ability to turn the tides of a seemingly lost battle through sheer skill, but that idea has been long since debunked. What really allows a good player to turn on an enemy, or even take out multiple enemies, is the potential for brevity. In Halo's case, the magnums perfect time to kill compared to its average time to kill is the source of this potential, along with the ability to dodge bullets. It doesn't matter how long or short fights are, what matters is that I can kill you faster than you can kill me, if I play better than you. Apply this theory to everything, including counter play opportunities in level design. If I'm good enough at something, I should be able to do it quickly, or at least faster than someone else. Conclusion Once players learn the "right" way to play an encounter, a map, a class, or game, there is no longer any room for creative thought. The highest level will revolve around executing the already present and built in "correct" way to play. To avoid this, balance your design with player merit as your proverbial currency, create overlap in utility within your sandbox, and allow for swift counter-play. The best design never makes a choice for the player, but rather presents choice. We are facilitators, not dictators. Follow Westin Youtube: https://www.youtube.com/channel/UCwVxACgMT67Zq6CkgCtrCdg Twitter: https://twitter.com/_Xandrith Website: https://westinkoessel.wixsite.com/portfolio Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0Dp
  25. In this approximately 1 hour talk from GDC 2018, Daniel Cook covers a subject that too often goes unconsidered by game makers and game players alike - how to use games as a means for creating and nurturing meaningful relationships. This is not exactly the type of content that Next Level Design typically focuses on, but we share a similar desire to nurture the human spirit and to have games influence our lives in tremendously powerful positive ways. Enjoy the presentation, and check out the links to Daniel's work below if you're interested in learning more. Daniel also has an article on this same subject, and has a lot of writing on it at his website which is linked below. Here's the link to the article: https://www.gamasutra.com/blogs/DanielCook/20170221/291910/Game_design_patterns_for_building_friendships.php Follow Daniel Twitter: https://twitter.com/danctheduck Webiste: http://www.lostgarden.com/ Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0Dp