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


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


  • Articles
  • NLD Originals
  • News
  • Projects


  • NLD Dev Blog

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



About Me

Found 14 results

  1. An Overview: What is Fun About FPS Multiplayer? Choices Sid Meyer once said that “a game is a series of interesting choices” and nowhere in game design is this more true than Multiplayer Design. In a single player game, the designer has access to design tools to help guide the player, like linear progression, or even just general good crafting of gameplay segments. In a multiplayer game, the player is constantly having to make his own experience using only the tools you provide him to do so. As such, it is important to approach multiplayer map design from this perspective: Provide the player with good tools and he can create a good experience. All this sounds blaringly obvious, of course, but given how many people get this basic tenet wrong it deserves stating. Terrain Options One good way to provide players with interesting choices in a multiplayer FPS map is to give them a variety of terrain options to choose from. (Elements like walls, cover, high ground, and low ground are all examples of these terrain options.) Good players learn what terrain to use depending on the situation – for example, it’s usually just a better idea for a player to have higher ground than his opponent. Not only does it provide him with an excellent angle to fire at them with, it also usually provides partial cover. Now lets say you place the high ground near a wall – now the player has a choice to make: Does he go for the high ground and attempt to get cover, or does he stay in the open to avoid getting hit easily with a splash damage weapon? A good multiplayer designer is always thinking of terrain options and trying to engineer them to provide as many good choices for the player as possible. Multiple Paths In single player games, it is often beneficial to lead the player towards the best gameplay experience your game has to offer. Often, this leads to a linear level design (which is, in most cases, best suited to the experience you want to provide). In multiplayer a linear path is rarely beneficial. A good player is constantly varying his route through a level, sometimes to shake off pursuers or sometimes in order to go after desirable weapons or pickups. Either way, it is always advantageous for the player to have a number of paths to get to and from every major area in a multiplayer map. As a general rule, a good multiplayer design should strive to make sure all major areas have at least three ways in and/or out of them. As with all rules, there are exceptions — and I’ll get into those in future installments. Flow In addition to multiple paths, a good multiplayer level designer is constantly thinking of how he wants the players to move globally through a multiplayer map. This level of understanding, called flow, affects everything from pickup placement in a deathmatch map to node placement in a node-capture map. It is often beneficial for a designer to come up with a rough bubble diagram before attacking the level. Such a diagram will usually just consist of simple shapes (circles, squares, triangles) representing major areas. Once you’ve got a nice area layout, you connect them with arrows showing the different ways in or out of that area. Then you start to think about how you want a player to travel from one area to the next and where the points of interest are on that path. If you’re ever having trouble coming up with a good flow, there are several default shapes that you can always fall back on that work almost every time. The Circle A circle is the simplest kind of flow a level could have. While you would almost never design a level that only flowed in a circle, sometimes you can define your major flow path as a simple circuit through the level. This is often a good springboard that gets you thinking about even better flows. The Figure 8 If you play any competitive multiplayer games (most often FPSs) you will notice that a lot of levels are based off the simple figure 8. Figure 8’s are a very interesting shape for major flow. While they offer all the benefits of a circle, as far as providing interesting flow, they also have the added benefit of an additional major flow path that cuts through half the circumference of the circle. Often, you can get incredibly involved and complex flows out of a few well-placed figure-8s. Interesting Spaces Focal Points Focal points are a particularly important feature of multiplayer maps. Not only do they divide up the players’ interest to many different points on the map, they also provide areas of visual interest. Every well designed map will contain a focal point at the most important point on the map (usually the center) as well as minor focus points in every major area. Examples of focal points include really tall structures, interesting terrain formations, gameplay-required elements (such as nodes), pickups, and anything that adds particular visual interest to an area. Verticality The terrain options section touched on this a little bit, but verticality’s importance in multiplayer design can not be overstated. Verticality increases the amount of player choices in an area, but also increases the “gameplay per square meter” that a map has. A completely flat map that supports 32 players might be 400m x 400m, but you could fit the same number of players into a 200×200 map just by adding one or two levels of verticality to all the major areas on a map. In Resistance, for example, we found that adding verticality to a space in 3 meter increments (specifically 3 and 6 meter height differences up or down) made our spaces much more interesting and allowed them to be a lot denser and generally more fun. Cover It’s important in multiplayer that your players not be able to shoot too far ahead of themselves most of the time. Large open spaces should usually be broken up with a lot of full cover. This also allows players to advance through areas without being vulnerable for too long. The exception to this rule is any area where you want to encourage a risk/reward scenario (for example, with a large open space with lots of cover on the outskirts and a nice powerup in the center the player is encouraged to take a risk and get the powerup with the possibility that someone might shoot at them from the well-covered spots.) We’ll get more into risk/reward scenarios in future installments. *Note: This article is republished in its entirety on Next Level Design with permission from the author. Source: Follow Mike Website: Website: Twitter: Follow Next Level Design Join the Forum: Follow us on Twitter: Discuss on Discord:
  2. Intro This is one in a series of blog posts/articles I’m writing to describe my game design methodology. In the first article, I named the system “Trinity” – but I mentioned that I had to lay a bunch of pipe before I could describe why. I have now laid enough pipe, and in this article I’m going to go over (in the most general terms) why I called it that. There are a lot of “things” that make up a game, and I like to break them down into three categories – like smashing an atom into a proton, a neutron, and an electron. In my method, these three categories are super-important. They apply at every level of my decision making process, so this article is going to be all about the three categories. (Link to Part 8) The “Trinity” There are at least 3 basic categories that everything in a game can be broken down into, which I call “Context,” “Theatrics,” and “Questions.” All three components are equally important. They also depend on each other. Like load-bearing pillars, if one falls the others aren’t going to hold the roof up by themselves. This is so important, I’m going to restate it: Context, Theatrics, and Questions are the building blocks of a game. All three are equally important, and they are all interdependent. “Context” is about the creative agenda (and if you’re selling the game, the business agenda). “Theatrics” is about flashy showiness – audio-visual aids that help the game communicate with players. “Questions” is about interactivity – anything interactive falls into this group. Each adds a different “flavor” to the game soup, as I’ll get into below. Context (Spicy) Context is the game’s “spiciness” – it’s what gives it a certain flavor, or character. Often Context is based on real-world concerns like budget or audience, but also deals with creative or artistic concerns like art style and theme. Context is a patchwork creative agenda comprised of the needs, vision, and craft of everyone who works on a game. It is the harmony of intentions across the entire team – both at the developer and (if applicable) the publisher or money-people. Some examples of Context in a game: The game’s overall art style (grounding Theatrics) The game’s plot The business model Supported platforms The game’s theme/message The game’s genre or intended audience (grounding Questions) The budget Etc… Context provides the spice to a game like Chess. The game could be much more abstract (e.g. the pieces could be colored cubes with names like “piece A,” “piece B,” etc) but instead the game was themed as a medieval war with ranks of pawns, knights, bishops, fortifications, kings, and queens. The medieval war metaphor grounds the game in an idiom that makes it more understandable (and perhaps enjoyable). Books are the most famous Context-based medium out there. Unless you’re talking about a popup or gimmick book, most books don’t use audio-visual Theatrics. The story is not usually interactive so Questions are not an issue either – the medium thrives entirely on things that fall into the group I’m calling Context. Theatrics (Juicy) Theatrics represent the “Juicy” parts of a game — the flashy showiness and clever trickery that often makes the difference between bad, good, or great. Theatrics are audio-visual in nature, and serve to deliver the game’s Context and Questions. Some examples of Theatrics: Visual effects (particles, scrolling textures, etc) Musical stingers Cutscenes (delivering Context) Sound effects Camera shakes Force feedback Stagecraft in Player-VS-Player games Enemy attack telegraph animations (delivering Questions) Etc… Popcap’s Peggle is a great example of theatrics all-around. But check out the video below for my favorite bit — EXTREME FEVER!!! Theatrics provides the juice to a game like “Mouse Trap.” “Mouse Trap” is essentially “Chutes and Ladders” with great Theatrics. Check out the video below to see what I mean. Flip the man in the pan and the ball rolls down into the rub-a-dub-tub and the cage comes down and whaaaaaaa? Not surprisingly, Theatre and Movies are the most famous Theatrics-based medium out there. Unless you’re talking about Improvisation, Experimental Theatre, or Point Break Live, most times you go to see a play it is not interactive – same with movies – so Questions don’t come into play. You’ll notice, though, that Context is still VERY relevant (budget affects what kinds of effects you’ll be able to use, who can write your music, your plot, theme, art style, and so forth). Questions (Crunchy) One of the premises we’ve been building on so far in these articles is that games are fundamentally a conversation between the designer and a player. The designer asks Questions and provides the player with Tools to answer the Question. This idea of Questions – of an interaction between the player and the designer – is central to this third, interactive axis of Trinity. Questions deepen a game. Side note on “Crunchy”: I play a lot of tabletop RPGs – and have since I was in high school. Some of the role playing systems we used were much more complex than others, and generally the more complex they got the “crunchier” they got (referring to the amount of number-crunching you’d have to do to find out what happens). Because of this I have always associated “crunchiness” with the ways players interact with a game. The more rules there are to interact with, the crunchier it gets. One time we played a system so complicated I couldn’t create my character without a complicated Excel spreadsheet. This was not the same game as when my friends used calculus to figure out if they could conjure enough acid to dissolve a dragon trapped inside a hemispherical wall of force, in case you were wondering. Some examples of Questions: What weapon will be most effective against this enemy setup? What Tetris piece will drop next? Which building/unit should I build next? Should I sacrifice my knight to take the bishop? How do all the pieces work? How do I find the programmer’s hidden name in Adventure? Quick-time Events (QTEs) – (deepening Theatrics and Context) (Essentially, “what are the rules” and “how can I apply them creatively.”) Smashing Particles I can’t go into any depth on this for this installment, but I wanted to mention this: I used the metaphor of smashing an atom earlier – but what happens when you smash it down even further? These three pillars of Trinity (Questions, Context, and Theatrics) are fractal in nature. That means if you smash any one of them open, you’ll see all three of them inside. Split a game into these three parts, and any further split will also break down into these three parts – just smaller. No matter what I’m using it for, I view every aspect of a game through this lens. When I design a puzzle, I consider all three. When I write a story, I consider all three. When I decide what technology to use, I consider all three. And so on, forever. No matter how far down I go into a game’s design or production, I see whatever I’m looking at through these three pillars. What do I use it for? Mostly I use it when I’m designing a feature to make sure I consider every angle. As I mentioned above, this doesn’t matter how big or small, meta or micro, the feature is – I try to see how all three parts apply. I sometimes use it to break down games when I’m studying them to see what I can use, but that’s not mainly how I apply it. *Note: This article is published with permission from the author, and in accordance with Creative Commons guidelines. Source: Follow Mike Website: Website: Twitter: Follow Next Level Design Join the Forum: Follow us on Twitter: Discuss on Discord:
  3. Intro This is the latest in a series of articles I’m writing to describe the way I approach game design. The last installation was on “Ramps” – essentially a tool for scaling intensity over time. This article builds on the last one, so if you haven’t read it yet I’d recommend you do that first. (Link to Part 7) This installation is going to be on a concept I call “Paths.” I’m going to need this concept to explain something else further down the line, so I wanted to outline it now. I’m planning on fleshing the concept out a bit more when I return to it later. Path: One or more Ramps comprising a connection between multiple parts of your game. For example, I often talk about the “Critical Path” – the simplest collection of Ramps and Nodes that connects the beginning of a game to the end (if the game has such a thing). A Path can be very small or very large, depending on how you apply the concept. It can refer to small part of a single level of your game or it could refer to a huge web of ramps spanning the far extents of your game. Note how the Paths contain both Ramps and the “hub areas” before and after Common Path Types This list is not comprehensive, but the three types of Paths I outline below make up what I see in maybe 80% of all games out there, so I wanted to bring them up. They are: Linear Forked Spiderweb Note how the Paths contain both Ramps and the “hub areas” before and after Linear Linear Paths are one contiguous series of Ramps and areas (perhaps with small offshoots for non-Critical Path bonuses). One Ramp leads to another until the level is done. Note that many linear Paths (like the one in the diagram above) have short offshoots for rewards, secrets, sub-missions, or optional objectives, but those almost always return to a hub back on the linear Path after a short time. Note how the areas connect together in a linear fashion The above image is a map of the first level in Ratchet and Clank: Going Commando, The Flying Lab on planet Aranos. The player starts at the bottom of the map and has to get to the top. Note how the areas connect together in a linear fashion. Forked Two or more Linear Paths joined by a “hub” area. This is the second level of the same game (Ratchet and Clank: Going Commando), and this level has a forked Path structure. The player starts at the orange star and has a choice of two Paths to go down (A and B). Each loops back to the start hub when it is done, and each one is linear. Path C is grafted onto the end of Path B, and when you finish it you can shortcut back to the hub area. Spiderwebs A spiderweb contains many forked Paths and many hub areas all joined together. This wasn’t a structure we used much in the Ratchet and Clank series – you tend to see it more in games like Skyrim, Fallout, or the Deus Ex franchise. Players are allowed a number of possible solutions to many problems they encounter. Because of its complexity compared to the other two, I don’t have a good way of visually representing this, so let me give you an example. In the Deus Ex franchise, for example, there are often three or more ways to solve a problem: Combat You versus enemies Stealth/Hacking Avoid and find shortcuts Special ability (super-jump, punch through walls, etc) The player has many context-sensitive abilities such as punching through walls. Often problems will allow the use of one of these abilities as a solution. Each of these Paths through a challenge involve separate Ramps. For example, there’s a mission in Deus Ex 1 where the player needs to get into a building. The player can go in through the front door, but then the only option is a bloody fight with the guards. As another option, the player can find a secret passage by hacking a soda machine found in a different part of the level and get in that way without having to fight. As a third option, if the player has purchased enough ranks in the super strength augmentation, the player can lift some heavy boxes blocking a back-way into the building and thus either avoid combat or get the ability to sneak up behind patrols you otherwise couldn’t sneak past. (Link to Part 9 - To be Updated) *Note: This article is published with permission from the author, and in accordance with Creative Commons guidelines. Source: Follow Mike Website: Website: Twitter: Follow Next Level Design Join the Forum: Follow us on Twitter: Discuss on Discord:
  4. Intro This is one in a series of articles I’m writing to describe the way I approach game design. In this article, I’m going to show you a trick I like to use that helps me create good pacing in my designs. I was originally planning on showing and writing about how this kind of pacing looks in a recently-released game (namely The Talos Principle), but it became a bit too much to handle for a one-week article. I’ve put pictures and my notes in the Appendix, so hopefully they will be useful for someone. (Link to Part 6) Ramps A Ramp is a pattern of increases and decreases to Intensity over the course of a game segment, created with the purpose of achieving a desired balance between Intensity and Rest. I talk more about Ramps (which I called Intensity Ramps) in the previous article. As you can see in the diagram below (from Jesse Schell’s The Art of Game Design: A Book of Lenses), Ramps are not linear slopes, but rather contain many peaks and valleys. As mentioned in the previous article, this is because of Principle #5: “If it’s always ‘turned up to eleven’, eleven becomes the new five.” In other words, if intensity does not vary between parts of a game, you effectively have no intensity. Usually a Ramp increases in intensity over time and contains many small Rests. Not every game will want the same kind of Intensity Ramping. Some will want a steeper overall curve, some will want a shallower one, and some may even want one that trends down in Intensity over time. When I’m designing part of a game, I create Ramps for many different purposes, but always with the goal of balancing Rest and Intensity in a way that best suits the game I’m making. A Trick to Create a Ramp Using Archetypes Learning the ABCs As we’ve talked about before, Archetypes represent the extreme edges of your game’s design. To begin creating a Ramp, first I make a list of all the Archetypes I have available to me in the part of the game I’m currently designing and assign each one a letter. (The order doesn’t really matter that much for now.) For example, let’s say I’m designing an early level of a game that uses the same kind of combat system we’ve been developing over the course of this series, except you can only attack by jumping on an enemy. It’s early-on, so let’s say my available Archetypes are restricted to these three: Swarmer (Small, dies in a single hit, best in large groups) Ranged Enemy (Stands in one place and shoots at you) Terrain Gaps (You can fall in and enemies can shoot over it) To create a Ramp out of these, I combine the letters in such a way that Principle #3 is always followed: Principle #3: Let the player interact with your Questions and their Tools in a simple way before requiring them to interact with them in a complex way. This means that when you combine the letters together, you must introduce each letter to the player in a simple way before increasing complexity. Each group of letters, when you’re done, represents a Setup for you to design the specifics of. And the order of the Setups automatically Ramps in the way we just discussed. Note: Additionally, it’s very important never to re-use a combination of letters within the same Ramp. If the point of this is to ask the player Questions, repeating the Question will get boring for the player very quickly. Fortunately, this method tends to give me more than enough setup ideas than I usually need for a single Ramp. For example: A | B | AB | C | AC | BC | ABC Using this trick allows you to increase the intensity of your setups over time without having to first design all the setups out in their entirety. This tends to save a lot of time. Note: The letter means “one or more of this archetype” – in the above example the first setup could be designed to have either a single enemy of type A, or many, and the pacing still works. Rests Principle #4: An intensity ramp is not a linear increase in intensity, but rather a “lumpy” one. Rest periods are as important as active periods. In the technique I showed above, a good place for a rest is after you’ve combined some archetypes, but before you add a new one. For Example: A | B | AB | REST | C | AC | BC | REST | ABC Designing Setups Based on the Ramp Given the Ramp we’ve just created, I’ll now show you how I’d put it all together to design a Ramped series of Enemy Setups. For simplicity, rather than creating a player and some weapons from scratch, I’m designing these assuming the player is small Mario from Super Mario World. Mario, when small, can run forward and backwards, he can jump, and that’s it. If he jumps on top of (stomps) an enemy, the enemy dies. If Mario is touched by an enemy in any other way, falls in a pit, or is touched by a projectile, Mario dies. To illustrate what a first-pass design using a Ramp might look like, I cobbled together this rough Mario segment design Mario starts on the left side of the image and wants to run all the way to the right side. On the way, he encounters the Ramped Setups we created out of Archetypes. A – Three Swarmers on a flat plane. (Note that it’s not restricted to a single instance of the Archetype.) B – The player must approach the Ranged enemy, wait till there’s a gap in the hammers, and run through. AB – Adding height to this setup allows me to present both the Ranged and the Swarmer at the same time. The player now has to wait for an opening and then time a jump to avoid or stomp the Swarmers. REST – Optional coins and power-up blocks along a segment of nonthreatening flat ground. The player then goes down the green pipe and ends up in the underground section below (the left-most pipe is the segment start). C – Jump over a gap. Since this is the first one, I’ve put blocks below so the player doesn’t die. AC – Swarmers patrol the far side of the gap, so the player has to time a jump to avoid or stomp. BC – The player has to time a jump between the gaps in the hammers, then time a jump over the Ranged (or time a stomp). REST – A large coin “hidden” up off the screen, along with some power-up blocks on flat terrain ABC – All of the challenges are here together. Additionally, players can only stomp the first Ranged if they climb up and get the “Secret” large coin from the rest area. Conclusion In this article we went over a trick that I use to create Ramps. Next article we’ll be combining Ramps into Paths, and Paths into Levels. After that, we should have enough information for us to “zoom out” again (two articles from now) and begin to talk about the reasons why I call this series “Trinity.” Appendix Originally I wanted to write an analysis of the puzzle game The Talos Principle to demonstrate how this kind of pacing shows up out in the real world, but I ran out of time to do a full write-up of it this week. I did, however, make some images and a few notes, so I wanted to include those here in case people can get anything out of them. First Six Puzzles (Training) These first six setups are the first six of the game. You have to go through them in this order. Learn that there are force fields you are allowed to walk through. Learn that there are force fields you can NOT walk through. Learn to use a Jammer to disable the force-field so you can get past it. There are dangerous mines that patrol on a path. The Jammers work on them, too (the circled thing is a Turret). The Jammers work on Turrets TOO! They introduced all the elements in training. When you’re done with that, the next puzzles begin to overlap all the elements (I only finished diagramming the first puzzle) After the training, the game becomes less linear and gives you a pool of puzzles. This is the easiest one / the one with the fewest overlapping elements. Upper: Use the Jammer (cyan) to block the Turret (yellow) so you can turn it off with a switch (red). Lower: Now that the Turret is off, use the same Jammer to jam the Mine (bottom right), then win. (Link to Part 8) *Note: This article is published with permission from the author, and in accordance with Creative Commons guidelines. Source: Follow Mike Website: Website: Twitter: Follow Next Level Design Join the Forum: Follow us on Twitter: Discuss on Discord:
  5. 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 5) 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. Archetypes: Very typical examples of one of the extreme boundaries of your game’s design. Setups: Variously-sized groups of Archetypes, all combined together to ask the player a unique Question. Intensity and Ramps This week I’m going to introduce the subjects of “Intensity” and “Ramps,” which I’ll define later on. I’ll be developing these concepts further next week when I talk about how knowing about these helps you decide what Archetypes go in a Setup (see the previous article for more about Archetypes and Setups). Before diving into the guts of this piece, I need to define a couple of terms. Difficulty First off, I’m going to be using the term “Difficulty” a little differently than most people do – and I want to be clear up front that it’s not what I’m talking about when I talk about Intensity. As with everything else in this series, I’m not doing this to imply that my way is somehow better or more correct. It’s just necessary that you understand how I’m using it here to avoid potential confusion. “Difficulty”, as I use it, doesn’t really measure how hard content is for any given player. It measures the difference between players. For example, if you measure, say, how long it takes different players to complete various levels and record how many times they died, you can know whether Level 1 in your game can be said to be objectively harder or easier than Level 1 in another game (at least in terms of those two things you’re measuring). Further, you’d be able to rank the players’ comparative skill in those areas, like with a leaderboard. Difficulty: The objective difference in complexity or required skill between multiple games or players. “Objective difference” is used to mean “the view from outside the player.” It is externally comparative. Difficulty is a very important aspect of game design, and I don’t want you to think I’m ignoring it. In this early-on phase of design, though, I don’t find it particularly useful to think about how objectively hard my content will be. Intensity Early in the design process, I care most about how hard my content will be compared to the content that surrounds it. The word I use for that is “Intensity.” Intensity – The subjective difference in complexity or required skill between different parts of the same game. “Subjective difference” is used to mean “the view from inside the player.” For example, let’s say I created two levels (1 and 2), where the second level was supposed to be more Difficult than the first. A pro gamer, a novice, or my dad would each have different subjective experiences of how hard those levels were, but if I’ve done my job right they would all agree that Level 2 is more Difficult than Level 1. Intensity measures the difference between Level 1 and Level 2 in terms of how hard it was for a given player. Note that Intensity does not compare multiple players or various games to each other – it only takes into account one specific game and one specific player, namely: The player who is currently playing your game. Intensity and Pacing Pacing Pacing is the ratio of Intensity to Rest over the course of a segment of your game. A great example of good pacing can be seen in the recent film Mad Max: Fury Road. Commonly described by reviewers as “a two hour long chase scene” – the movie nonetheless does a masterful job of balancing rest time for the viewers without destroying the forward momentum that makes that movie so great to watch. The two most clever rests I can think of in that movie are: The chase sequence through the crazy tornado storm The part where they get stuck in the mud. Both are action packed and intense, but they mark a clear change of intensity and pace when compared to the surrounding scenes. During the chase through the tornados, the audio fades down and everything seems to move in slow motion. The cars are still moving and getting ripped apart, but the intensity has died down – the viewer gets a rest. The color palette cools down, the action slows,the music ducks itself, and even the carnage shown in this shot feels restful. This keeps the viewers from getting worn out by constant action. In the “stuck in the mud” scene, the color palette changes abruptly to night and the motion of the cars actually stops for a while – but the action goes on. The characters are under threat, need to get out of the mud, and are being chased by an insane person. There’s even a cool explosion during this scene. And nevertheless it acts as a down-pacing moment. It gets you emotionally ready for the action that is to come, and makes that action (when it comes) feel much more intense by comparison. Again the colors cool down. In this scene the main motion of the cars stop while the characters dig it out, but there are still plenty of explosions, cars with tank treads, and gunfire. This is a great example of the application of what I’m going to call “Principle #5”: Principle #5: If it’s always “turned up to eleven,” eleven becomes the new five. (I know I haven’t done Principles 3 and 4 yet, but I HAD to make this one either number 5 or number 11, and 5 was closest. The persons responsible for this decision have been sacked). Intensity is the measure of your content as compared to other content that’s come before or to any future content in your game. This means that if I never change Intensity between the different segments of my game, my game essentially has zero Intensity. Even if objectively the whole game was brutally Difficult, players will not perceive any relative change from one segment to another. Pertaining to games, this teaches us that if you want your players to feel a change in intensity at certain points, you have to let them rest beforehand so the change is noticeable. Going from intensity 5 to intensity 11 is a big jump, but going from 10 to 11 is not. Intensity Ramps Jesse Schell, in his wonderful The Art of Game Design: A Book of Lenses shares an anecdote about when he learned the importance of pacing. He was working in a performing troupe and had just put on his first show. He went backstage and the head of the troupe, Mark Tripp, told them the show had been good, but not great. Their progression (pacing) had been off: “It’s simple. You need to start with more of a bang — to get their attention. Then you back off, and do something a little smaller, to give them a chance to relax, and get to know you. Then you gradually build up with bigger and bigger routines, until you give them a grand finale that exceeds their expectations.” From this experience, Dr. Schell developed the concept of “Interest Curves:” Since my time at the amusement park, I have found myself using this technique again and again when designing games… The quality of an entertainment experience can be measured by the extent to which its unfolding sequence of events is able to hold a [player’s] interest. The level of interest over the course of the experience can be plotted out in an interest curve. An example graph of what Dr. Schell calls “a successful Interest Curve.” What he calls an “interest curve” I’ve been calling “an intensity ramp” for much of my career. For the purposes of this article series we’ll use my term (to keep it easier for me) but you should know that he’s talking about exactly the same thing I am. Intensity Ramp: The measure of relative intensity and complexity between the beginning of any segment of game content, and the end of it. Intensity ramps commonly start at low intensity and increase over the course of the segment. (Link to Part 7) *Note: This article is published with permission from the author, and in accordance with Creative Commons guidelines. Source: Follow Mike Website: Website: Twitter: Follow Next Level Design Join the Forum: Follow us on Twitter: Discuss on Discord:
  6. 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) *Note: This article is published with permission from the author, and in accordance with Creative Commons guidelines. Source: Follow Mike Website: Website: Twitter: Follow Next Level Design Join the Forum: Follow us on Twitter: Discuss on Discord:
  7. 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: Follow Mike Website: Website: Twitter: Follow Next Level Design Join the Forum: Follow us on Twitter: Discuss on Discord:
  8. 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: Follow Mike Website: Website: Twitter: Follow Next Level Design Join the Forum: Follow us on Twitter: Discuss on Discord:
  9. 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: Follow Mike Website: Website: Twitter: Follow Next Level Design Join the Forum: Follow us on Twitter: Discuss on Discord:
  10. 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: Follow Mike Website: Website: Twitter: Follow Next Level Design Join the Forum: Follow us on Twitter: Discuss on Discord:
  11. 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: Follow Mike Website: Website: Twitter: Follow Next Level Design Join the Forum: Follow us on Twitter: Discuss on Discord: .galleria, .galleria-container { height:480px !important }
  12. 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: *Note: This article is shared on Next Level Design with permission from the author. Follow Mike Website: Website: Twitter: Follow Next Level Design Join the Forum: Follow us on Twitter: Discuss on Discord: .galleria, .galleria-container { height:480px !important }
  13. 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: *Note: This article has been posted in full with permission from the author Follow Mike Website: Website: Twitter: Follow Next Level Design Join the Forum: Follow us on Twitter: Discuss on Discord:
  14. 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 Lists I 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: MikeWebsite: http://www.chaoticstupid.comTwitter: Follow Next Level Design Join the Forum: Follow us on Twitter: Discuss on Discord: