Search the Community

Showing results for tags 'mike stout'.



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 9 results

  1. 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
  2. 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
  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 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
  4. 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
  5. 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
  6. In this article, Mike Stout shares his learnings from experience designing levels for Ratchet & Clank, Skylanders, and Resistance: Fall of Man. What follows is only a portion of the full article, which offers a high level overview of Mike's process for designing levels. Follow the link at the end for the full article. Introduction I'll walk you through an example level I'm creating from scratch, so you can see typical results from each stage of the process. In Step 1: Understanding Constraints, I'll walk you through common limitations I always look out for while designing levels. In Step 2: Brainstorming and Structure, I'll show you how I decide what goes into a level. In Step 3: Bubble Diagrams, I'll introduce you to a visual method for outlining what goes into each area of your level. In Step 4: Rough Maps, I'll talk about how I flesh out each bubble from a Bubble Diagram to figure out what goes into each area. I could write an entire series of tutorials about how to do this, so we'll only go over the basic outline here. In Step 5: Finishing the Design, I'll talk about moving on from your basic design to create final spaces. This is also a huge topic that could be further explored in a series of tutorials, so for scope I'll keep this very basic. 1. Understanding Constraints At the beginning of a design, the hardest part is figuring out what is going to be in a level. As a designer, you get to decide a lot, but you don't always get to decide everything—especially if you're working in a large team. On a large team, most of your constraints are going to come from other people. There will be business constraints, franchise constraints, audience constraints, legal constraints, engine constraints, and so forth. Most of the time, these restrictions come from far away up the chain. Closer to you will be the constraints applied by the vision of the creative director, art director, and anyone else involved making decisions at that level. If you're working on your own as an indie, you're the one who will be making these decisions, so you still need to understand your constraints very well. General Constraints There are a few general constraints I try keep in mind whenever I design a level; I find that these apply to most games I've ever worked on. I've provided example answers to the questions about these constraints below to show you the level of detail you need to get started, and I'll use these example constraints to construct an example level design in this tutorial. How Long Should This Level Be? This is a short level, about 30 minutes long at most. Are We Trying to Show off Any New Tech, Art, Audio, or Similar? Our imaginary game engine has cool indoor lighting effects, so I want to have lots of cool indoor spaces. How Much Time Do I Have to Design It? This article was written over the course of several months, but the level design aspect itself took about two or three days to complete. *Note: I'd expect this process to take about 5 weeks for a full-sized level on a real game. If Someone is Paying For This Game, What Are Their Requirements? For a game not made as a tutorial example, these requirements usually come from the publisher, the investors, the marketing department, and so on. What Platform is It On? The platform you make the game for imposes constraints. A game for a phone can't use as much processing power as, say, a game for PS4 or PC. A virtual reality game imposes restraints on camera movement to avoid causing motion sickness. Mobile games have length restrictions because people play in short bursts. Know your limitations. For the sake of this example, let's say the game is targeted at last-gen consoles (PlayStation 3, Xbox 360) and PC. Where Does This Level Fit Into the Level Progression? This is the third level of the game, and, as such, the challenges won't be too hard. Who is the Audience? This game is a sci-fi game, fairly violent. It will likely get an M (or 18+) rating. We're aiming this at hardcore gamers over the age of 18. The Most Critical Constraints If you find yourself in the fortunate situation that someone is paying you to design a level, remember that they want this level/game for a reason. If the stuff you make doesn't satisfy that reason, they will not (and should not) pay you, or the development studio you work for, for it. Satisfying clients is the best way to make sure they hire you or your studio again, so make sure to ask questions about what that reason is. Those critical questions vary from project to project, but regardless of whether I'm designing a level for myself or for others, I find that there are four questions that are almost always the most important to ask first: What is required by the level's story, theme, and plot? What are my set-pieces? What metrics am I constrained by? What does the game's "Macro design" require from this level? Let's look at each of these, in turn: What is Required by the Story, Theme, or Plot? The goal of the example level is to rescue a VIP who is trapped in a military facility, then leave the area in a helicopter. What Are My Set-Pieces? For the sake of this example: Dark hallways and stairwells show our lighting off to good effect. Employ surprise to prompt weapon firing, which will cast cool shadows. Fight a huge monster in a destroyed barracks near the middle. A Control Tower where the VIP is located. What Metrics Am I Bound By? Each area that you design needs to take into account things like the player's movement speed, the size of the player, the size of the monsters, jump heights, and so on. Each of these informs how large your corridors and spaces need to be, and what heights and lengths are available to be used as jumps. What Does the Game's Macro Design Require From This Level? Early in the development of a game, a short document is usually developed that decides what goes on in each level in very vague terms. (Watch this D.I.C.E. 2002 speech by Mark Cerny for more information on Macro designs.) A Macro document specifies which puzzles and enemies go in each level, how many usages of each are expected per-level, what rewards you get, and things of that nature. This puts further constraints on your design. For the sake of our example, here are our Macro constraints: First: this is a simple first-person combat game. No puzzles, and simple combat with four enemy types: Ranged: An enemy that stands still and shoots at the player. Melee: An enemy that runs up close and attacks the player with a weapon. Swarmer: A small, close-range enemy with a single hit point. Good in swarms. Heavy: A large enemy that stands still, takes lots of hits to kill, does lots of damage, and has both a ranged attack and a melee attack. Second: once the player has rescued the VIP, there needs to be a shortcut back to the start of the level, so the player doesn't have to re-traverse the whole thing. Third: the VIP is located in the final combat room. She is being held prisoner by elite soldiers. 2. Brainstorming and Structure - Follow the link at the end to read this section 3. Bubble Diagrams - Follow the link at the end to read this section 4. Rough Maps Flesh out Each Bubble Once I've got the Bubble Diagram finished, we know what's going into this level, and we know how each area is connected each other area. The next step is to run down the list and create a rough design for each bubble. I almost always do this on paper or in Illustrator, because that's how I learned, but I know a number of great designers who do this kind of thing in-engine to get a better sense of the space. Whatever makes you work fastest is best here. Below, see an example of what one of the bubbles (specifically Bubble 3: Tight Corridors) looks like after I've designed it out on paper (top-down): The player starts at the top of this area and proceeds to the bottom. This area makes use of right angles to introduce enemies as a surprise to the player I'll break this down: Player comes south and fights 3 Swarmers. After player rounds the corner, four more Swarmers run out from an alcove. After rounding the second corner, the player is face-to-face with a Melee enemy. This enemy will need to close distance before attacking, so having it around the corner isn't cheap. Rounding the third corner, the player fights a horde of Swarmers, along with a single Melee enemy that runs from behind cover to attack. The Swarmers come from inside the alcove close to the player, and from around the next corner. The player passes the fourth corner and turns the fifth corner to be confronted by three Ranged enemies, each using the wall as cover, while five Swarmers run at the player. Rounding the last corner, the player proceeds to the area in Bubble 4. Note how this area is designed in isolation from the others, and scale is considered, but not called out. Note how the distances and heights are still not well defined. In this rough stage, it's really helpful to be able to change things quickly, so I don't finalize those details until I'm ready to finish the design. I do try to keep the scale relatively consistent between all the areas, though, as this will make my job easier in the next step when we connect the areas together. Don't get too hung up on accuracy or small details. Things about this design will change constantly from now until the game ships (even after we "finalize" the design). Nothing is being set in stone Connect the Areas Together After taking each bubble and designing them in rough, on paper, I link them together (roughly). For readability, I've done it here in Adobe Illustrator, but this can be done on paper as well. Note how the areas are all laid out end to end, so I know how they'll connect, but I haven't finalized anything yet. Try to ramp the intensity up, area by area. Make sure you're combining your enemy types well, and that in general the difficulty, complexity, and intensity of your enemy encounters or puzzles increases over the course of the level. Make sure to add plenty of rest spots between combats or challenges to lower intensity from time to time. If you keep the intensity at 10 all the time, 10 will become the new 5. The end product (as appears in the image above) is what I call a rough map. 5. Finishing the Design - Follow the link at the end to read this section Review I begin the process by understanding all the constraints and restrictions that surround the level. Having a solid handle on my requirements prevents the need for re-work to fix the lack later. Next, I brainstorm ideas and get together a rough structure for what the level will be like: how many areas I'll need, and what will basically be in them. This usually ends up being a simple numbered list, especially for linear levels like the one we've been working on in this article. Then, I create a Bubble Diagram so that I can understand how all my areas fit together. It gives me a foundation for understanding the basic flow of my new level at a glance. After that, I create a rough map. I usually design each area separately, on paper, and then later figure out how to string them together. Once I've got them where I want them, I can see if any changes need to be made to anything I've designed to accommodate the areas fitting together. Once I've got a rough map, I either start working in-engine or finish the map. When I'm working on my own projects, I go in-engine. When I'm working for others, I usually make a map. A map is a very effective communication tool, and if you keep it relatively up to date it can be useful for people to look at during meetings. We hope you've learned something from this. To read the remaining portions of this article, follow this link: https://gamedevelopment.tutsplus.com/tutorials/a-beginners-guide-to-designing-video-game-levels--cms-25662 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 .galleria, .galleria-container { height:480px !important }
  7. 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 }
  8. People ask me sometimes where my ideas come from. Well, that’s not exactly true, nobody asks me that, but all kinds of famous people say people ask them that so I figured I’d jump on the bandwagon. But if they DID ask me, this is what I’d say (at least as far as level design). I design a level one “setup” at a time, then I link all the setups together to form a level. When I’m thinking of a specific setup, here is the basic process I go through: WARNING: GET READY FOR A TON OF BULLETED LISTS AND SENTENCE FRAGMENTS!!! Bullets R Boring! Gimmeh some pictoorz! Intensity Curve How many setups are in the level? On a scale of 1 to 10, rate each setup in terms of how intense (difficulty + energy) it should be. These numbers should go up over the course of the level, but we should have some noise in this regard (see image below). "Interest Curve" As defined by Jesse Schell in The Art of Game Design: A book of lenses Difficulty / Intensity Where is this setup located on the “intensity” curve of the level? Does the intensity curve want a combat setup or a non-combat setup here? If we want the intensity to die down a bit, non-combat setups help with that. If it’s a combat setup, based on the intensity curve, determine the number of enemies and the combination of enemies in the setup. Never repeat a setup. Always introduce an enemy before you use multiples of that enemy or use the enemy in combination with other enemies. (Enemy A, Then Enemy B, then two A’s, then an A with a B, then two Bs, then two As and two Bs, etc). Choose the enemies based on “archetypes” (see below). Terrain Features Gaps: Horizontal separators. Need to determine: Width The path around or over the gap The fiction or type of the gap (cover, a river, a pit, etc…) Ledges: Vertical separators. Need to determine: Height (usually in two increments: Short and Tall) The path to the top of the ledge The fiction or type of the ledge (a car, a balcony, a platform…etc) Gaps and ledges Area Shape Determine the size (Should it feel tight, normal, or vast) Make sure enemy entrance or spawn points are visible from the player’s entrance point Reveal VS Recon (Is the player surprising the enemies or are the enemies surprising the player. This should vary based on the intensity curve) Make sure the area contains or has a view of some kind of focal point. The action should revolve around or serve to frame this visual focus. Tight Space Enemy Archetypes Near: Attacks close-up Far: Attacks from far away Heavy: Can be near or far, but should be player’s top priority if all else is equal Popcorn: Can be near of far. Not dangerous unless in groups. Should make the player feel strong. Near / Far / Swarmer / Heavy Enemy Idle Behavior If the player is surprising the enemies, what are they doing before he triggers them? (Patrolling, idling, juggling, etc…) Enemy Intro Behavior How is the enemy introduced? Spawn-in: The enemy appears (Teleport, jump in, etc) Run-in: The enemy comes in from off-screen (run ,fly, etc) None, the enemy is already there when the setup starts These should be varied based on the intensity curve. Enemy Trigger Zones Where does the player have to be for the enemies to activate and begin attacking? Where does the player have to be for the enemies to stop following him once they’re activated? Where does the player have to be for the enemies to deactivate? Enemy Location / Placement Must be visible to the player from the entrance to the area Do we want enemies to clump or be spaced out? Are the enemies close to or distant from the entrance How close or far do we want them from terrain features? (Over a gap, up on a ledge, behind cover, etc…) Place important items E.g. Explody barrels, health, etc Usually place close to a wall or suggestively (an explody barrel right next to a group of guys) Coin placement! Place gravy items Rewards: (Crates, coins, etc) Pure gravy: E.g. Breakable scenery Visual gravy: Non-breakable scenery, usually to provide movement or points of interest. (Blinky lights, scrolling water, plants, etc…) 'What are you trying to say? That I can stop bullets?' Source: http://www.ongamedesign.net/when-im-designing-a-level/ *Note: This article has been posted in full with permission from the author Follow Mike Website: http://www.ongamedesign.net/ Website: http://www.chaoticstupid.com Twitter: https://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
  9. Every so often every person in a creative occupation gets stuck. It’s a common enough frustration, and one that I’ve felt the pain of on many occasions.Since I’ve been giving the problem a lot of thought recently, I thought I’d post some techniques I use to get past it. While this may not be of immediate practical use to non-game designers, I’m fairly confident that some of the techniques can be adapted to any kind of creative process.Why do we get blocked?A lot of times, when I get blocked, I stare for long periods of time at an empty piece of paper, a new Illustrator file, or a blank Word document. I just can’t think of a single thing that I want to put down on it, and I’m completely baffled by the problem of it.Often, when this happens, I’ll find myself drifting onto other tasks. The problem is just too big, and my brain wants to be somewhere it can be of more use. The task and my ability to concentrate are, at that moment, like the wrong sides of two magnets.And the procrastination begins.When I get this feeling, it’s generally because the problem I’m concentrating on IS actually too large. As soon as I realize this, I have a few techniques that I use to try to break the problem down into smaller, more manageable chunks.Post-itsI’m a very tactile person. I prefer to do early drafts of my designs on paper or in some physical medium. It’s important to me to be able to move things around physically, or to be able to step back and look at what I’ve done in it’s entirety.Later drafts which require less sweeping change tend to go on the computer, but the early stages have to be physical somehow.If you’re like me in this, you’ll probably respond well to the Post-It technique. I bust out three or four Post-It Note pads (each a different color) and three or four colored markers. Then I proceed to write down everything I can think of about my level: What kind of locations would be fun to see in this level? What kinds of enemies or encounters can I include? Sometimes I even get as granular as specific landmarks or structures that might appear only in one place in the level.Each of these gets its own post-it and goes up on the wall in no particular order. I color-code them based on whatever seems to make the most sense to me at the time — making no attempt to rationally organize or disrupt the flow of ideas.When that runs dry, I stand back and look at the wall and start weeding out the weak or redundant ideas. These all go on a separate part of the wall in case I need them later (never, ever, throw anything away!) and I begin to sort the remaining ones into categories.Where might these appear in the level? Do any of them share a common theme? Then, when I finally get them all sorted out, I put them in order.Which of these things would be good at the beginning? Which would be good at the end?For enemies and encounters, I begin to think about difficulty ramping and other design principles and arrange them appropriately.When I’ve got this all done, I take a picture of it with my digital camera (in case a post-it falls down) and then transcribe the whole thing into Excel or Word.By the time I’ve done all this, I have a plethora of ideas and I can finally begin to start drawing a map.Block DESTROYED!Bubble DiagramThere are some cases where the Post-It approach is not appropriate. What if you’re the type of person who thinks better on the computer? What if you need to show the results of this to someone else who can’t understand your stupid made-up organization and encoded cryptic phrases? What if you hate wasting paper?What if you own stock in a competing paper company?In these cases, a bubble diagram comes in very handy.A bubble diagram is a VERY simple map of the level with arrows indicating travel direction and circles indicating destinations. Next to the arrows you put text that describes what you do to get from one destination to the next.Or rather, that’s how I do it. Almost every designer I know does them a little differently, and that’s okay! The only requirements are that you must be consistent and that the final product must be readable. Part of the idea with these things is that they can help communicate your ideas to others, so keep that in mind when you do them.This is an example of a bubble diagram of a level for a Ratchet and Clank – type game. It’s pretty self-explanatory: Put all your major goals, destinations, landmarks, or environments in circles and then draw lines between them with arrows. You can interrupt the lines as much as you want with other circles to expand your idea.Keep doing this until you have enough to start actually designing the level, or until you have enough information to accurately describe your level idea to a third party.Bingo! The block is gone!Boring ListsI tend to be very technical with my designs. I often start by developing a formula for the level — something very linear, very symmetrical… and very boring.This often takes the form of a checklist or bulleted list of features that the level HAS to have.For example:– 3 gadget puzzles– 15 enemy setups– 5 hard setups– 5 medium setups– 5 easy setups– 3 context-sensitive events– 3 cool enemy intros– 1 boss battleAnd so forth.You’ll notice that the list is very concrete and linear. It also looks very boring. There’s nothing even remotely creative about this — it’s just a feature list. It’s like reading the back of a game box, only less interesting in every conceivable way.It makes my right brain SCREAM in outrage… and that’s exactly why it’s awesome!The problem started because the creative part of my brain wouldn’t get started. So to retaliate, I cut that part of the brain completely out of the loop.By the time I get back around to customizing this boring formulaic outline, the right brain is SO angry that it begins to work overtime. The list then becomes less of a checklist and more of a skeleton — a frame around which we can begin to sculpt something that actually IS cool. It’s both a starting point for the process AND a catalyst to stir the brain into action.What I’m trying to say is that it works pretty damn well most of the time.Anyway, that’s all I’ve got on the subject for now, but I’d love to hear what methods you guys use to get past your creative blocks. Feel free to post whatever you’ve got in the comments.Source: http://www.ongamedesign.net/beating-design-block-level-design/Follow MikeWebsite: http://www.ongamedesign.net/Website: http://www.chaoticstupid.comTwitter: https://twitter.com/MikeDodgerStout