Search the Community

Showing results for tags 'game design'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • 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 53 results

  1. WAYWO has landed. This is one giant leap for Level Design, one giant leap for Video Games. Or anything else you all deem appropriate to discuss in here, since it is traditional to go way, way, WAY(wo) off topic.... 😉
  2. Follow Nicolae Twitter: YouTube: Website: Follow Next Level Design Join the Forum: Follow us on Twitter: Discuss on Discord:
  3. Follow Randy Twitter: Website: Follow Next Level Design Join the Forum: Follow us on Twitter: Discuss on Discord:
  4. Follow Matt Twitter: Website: Follow Next Level Design Join the Forum: Follow us on Twitter: Discuss on Discord:
  5. I know I’m late to the Hollow Knight party myself, but if anyone out there still hasn’t played this magical arthropod adventure, do yourself a $14.99 favor and fall into Hallownest — you won’t regret it. And you do fall into it literally and otherwise; over 40 or so hours, as I descended down Hollow Knight’s subterranean realm of rain-soaked cities, cavernous sewers, and verdant gardens, so did my mind sink into perfecting its laser-precise combat system, deciphering its blink-and-miss story moments, and unraveling its interconnected worlds. The premise of Hollow Knight is simple and light on exposition. You’re a small skull-faced wraith armed with a nail and charged with exploring the decaying, sparsely inhabited kingdom of Hallownest where something has clearly gone wrong. And Team Cherry certainly kept the theme of exploration as a guidepost while designing the game. Here’s Ari Gibson, co-director of Team Cherry in an interview with PC Gamer: "A lot of these decisions we’re making, a lot of the scale and the rooms we build, all of it’s built around this sense of discovery. Exploration and discovery." In this article, I’ll be looking at how Hollow Knight crafts a navigation system that stays true to these themes of exploration and discovery by making players earn their progress in areas that are taken for granted in other games. /// Map-rotransactions Plentiful navigational aids are the norm in video games today, almost to a point where they’re counterproductive. It’s a tough tightrope to walk — provide too many map markers, waypoints, and HUDs and risk spoon-feeding players to the point of boredom, or provide too few aids and risk players banging their heads against dead-ends and cul-de-sacs in frustration. Hollow Knight breaks this navigational dilemma into individual components and essentially lets each player walk their own customized tightrope. Hollow Knight’s main navigational aids are a map, a compass to orientate the player, and pins/markers to highlight areas of interest in the map such as benches (which are checkpoints), stagways and tram stations (which are fast travel points), shops to buy and sell items, and so on. Prima facie, this sounds like a lot of navigational help, but they’re a final state that players have to work towards (if they so choose). When the game begins, you have no map, no compass or markers, nothing. Just you and your raggedy nail plummet down into The Forgotten Crossroads, the first big area of Hallownest, and start exploring. After some puttering about, you run into Cornifer, a cheerful cartographer that offers to sell you a map of the area. Find Cornifer in each area to access that area’s (incomplete) map. He mentions that a map alone will mean little and that his wife Iselda has a store in the village above ground that will help you make more sense of your surroundings. Find Iselda in Dirtmouth to fill in your map. It’s in this shop where you can buy a compass that tells you where you are on the map, a quill to fill in parts of the map you explore, and markers for areas of interest that can be placed on the map (either automatically or by the players). Menu of markers and pins that can be purchased for your map. Hollow Knight does a few things right here: It lets players choose the level of navigational support they want. If someone isn’t very skilled at mental models and spatial awareness, they can purchase every marker possible and have their map be a guiding light. If players are more confident of finding their way around (or if they just like the feeling of unforeseen dangers lurking around every corner), then they can choose not to purchase an area’s map from Conifer and go in blind. Even activating many navigational aids doesn’t make the game too easy to explore. The game does this by providing an incomplete ‘fog-of-war’ map from Cornifer every time — it’s up to players to fill it in. Any markers that are bought from the shop also only identify areas of the map where players have already been. So you won’t know bench locations in a new area in advance. Buying the bench pin automatically updates the map with bench locations (that you’ve already been to). Hollow Knight turns basic navigational questions (questions that are usually imperative for game design to answer accurately) such as… Where am I? Where am I? Where do I go from here? …into player-driven choices that require effort and sacrifice. It’s a game about exploration and discovery, after all. Exploration as a gameplay loop Hollow Knight is a Metroidvania, although Team Cherry wouldn’t necessarily apply that label. This roughly means: It has large interconnected areas filled with obstacles and power-ups. The player is able to access new areas by gaining these power-ups and getting stronger in the process. There’s a fair amount of ‘backtracking’ (going through the same areas twice) and getting lost. A simplified version of Hollow Knight’s main gameplay loop is shown below. Once players enter a new area, there’s usually a stiff test to overcome (either a boss battle or a platforming gauntlet) and a new player ability lies at the end of that test. Having gained the new ability, players can now access new areas by using that ability. For example, you enter the Forgotten Crossroads… …to ultimately fight the False Knight (a boss battle). After defeating the False Knight, you gain a new spell-casting ability… …and use this ability to defeat a hitherto invincible enemy… …that was blocking entry into the next area, Greenpath. While loops like this drive the overall narrative, Hollow Knight also has shorter, exploration-focused gameplay loops within each area to help instill a sense of progress as players move towards the end goal of that area. Hollow Knight’s shorter, exploration-focused gameplay loop. When you first enter an area, you don’t have a map for it because you haven’t met Cornifer the map-maker yet. So you explore away, relying on mental models as you succumb to the wonders of the next room and the room after that. All on your own. Hollow Knight never gives you anything for free, but that doesn’t mean finding Cornifer is a completely hit-or-miss exercise. The game provides signifiers of Cornifer’s presence in the form of a paper trail and the sound of him humming a merry tune to guide you along. There you are! Once you have your admittedly rudimentary map, you continue to explore, but this time with a completionist’s itch to turn the rough pencil-strokes of your current map into the high-definition exhibit of penmapship that it’ll undoubtedly become. Turn this… …into this. Apart from the signifiers to Cornifer’s location mentioned earlier, Hollow Knight makes another design choice that, in my opinion, is meant to encourage exploration and map-filling as a gameplay loop. Once you have an area’s map (and your quill), new areas explored will automatically be filled in whenever you save the game or die. This is a game that’s notoriously tough and follows some Dark Souls tenets like taking away all your Geo (currency) whenever you die and forcing you to go back to the location of your death to get it back. But while it takes away some progress as a punishment for dying, it lets you keep your map progress. It’s a stick-and-carrot balance that feels like the game’s telling you, “Yes, this is tough, but now you know what’s around the corner. Try again.” I don’t know what’s real anymore I strongly think that how “real” a game feels doesn’t depend on its graphical fidelity or accurate imitations of real life at all. A game feels “real” when it makes you believe in its setting (however conventionally unrealistic that setting may be) with in-world consistency and a sense of personality. It’s tough to put this exercise into some standardized ten-step process, but executing correct UI choices will usually make the cut. Hollow Knight combines two design considerations, one atmosphere-focused and the other gameplay-focused… Hallownest, a once-vibrant kingdom now swimming in its own detritus, would have had road signs to help travelers find their way. Players will need some guidance when they’re exploring new areas of the map. …by including in-game signs for benches, tram stations, stagways, and more. For example, once you’re in the Royal Waterways, the winding sewers beneath Hallownest’s main city, you soon see a picture of a bench scrawled with chalk on the wall. Time for some well-earned rest. Or if you’re mulling around in the Forgotten Crossroads, you see a sign with a bug and some tracks, leading you to a Stag Station that opens up fast travel to other areas of Hallownest. This sign… …leads to this. These signs are a good example of diegetic UI, which refers to UI elements that are part of the game world and can be seen by both you (the player) and the player-character. It’s not the right UI choice for every game, but usually hits the mark when it simultaneously helps players and builds a sense of consistency and depth in the game world. How Firewatch’s UI enhances immersion Hollow Knight is filled with bits of diegetic UI and signifiers. Almost every bench and fast travel point is earmarked with signs. A swordsmith you can visit near the City of Tears is signified with a sign and a series of failed swords strewn along your path. And your map itself is diegetic, since you physically acquire it within the game and update it with markers and tags that are also real within the game. The game doesn’t pause when you view this map , which is a small but important touch that makes Hallownest feel real. This article is not meant as design truism. Maybe the design choices mentioned above won’t work for your game, and maybe they didn’t work in Hollow Knight for you. But for me, exploring a game’s world has rarely been so organic yet authored, tough yet fair, and mystical yet real. For more stuff on game design, you can visit my Medium profile to read my other articles or follow me on Twitter. Thanks for reading! *Note: This article is republished in full on Next Level Design with permission from the author. Source: Follow Abhishek Twitter: Medium: Follow Next Level Design Join the Forum: Follow us on Twitter: Discuss on Discord:
  6. 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:
  7. 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:
  8. Titanfall 2 does so many things well. It has surprisingly robust character-building for a shooter, creating an endearing and believable camaraderie between pilot Jack Cooper and his iron giant buddy BT. Its single-player campaign is short, varied, and intense, packing more into 5 hours than most games do in 15. But perhaps the most impressive feat that Respawn Entertainment’s metal gnashing fun-fest has accomplished is unifying all of the game’s design systems to incentivize one core feeling: speed. For the uninitiated, Titanfall 2’s premise is simple. Militia rifleman Jack Cooper gets a pilot’s life foisted upon him after his mentor dies in battle, leaving Jack and his robot BT-7274 (the thing he ‘pilots’) to go on all manner of death-defying high jinks in an attempt to defeat the evil IMC. The game’s not winning any awards for its story, but you hardly pay attention to the occasionally hackneyed tale when the gameplay is so breathlessly enjoyable. Let’s take a look at how Titanfall 2 uses all the weapons in its game design arsenal to make being a pilot feel so fast. /// Movement For a game built around rapid motion as one of its lodestones, design decisions around player movement are critical, and Titanfall 2 hits it out of the park. The basic move set lays the foundation: the pilot can use his suit to double jump, wall run on vertical surfaces, slide on the ground, and cloak for short periods of time. But the game deliberately subverts industry design norms while implementing these features, incentivizing you to chain these forms of movement into an offensive orchestra during both platforming and combat. Wall runs: When the pilot wall runs, his speed increases with time. This encourages you to chain wall runs with other forms of movement, use wall runs to both attack and evade enemies, and, most importantly, look to start the next wall run as soon as the current one is done. You’re safest when you’re at speed, and wall runs (against conventional logic) help you gain speed. The level environments are also generously sprinkled with surfaces to wall run on, both during scripted story sequences and otherwise, leading you to find creative ways of downing enemies. Definitely more satisfying than a normal knife to the back Slides: Just like wall runs, when the pilot slides, his speed increases with time before coming to a stop. This, coupled with the long duration of a single slide, means that you can use this game mechanic as an offensive maneuver rather than just a retreat to find cover. Again, just like with wall runs, the sine wave of increase-then-decrease of slide speed makes you want to start the next slide that much sooner. The speed of a slide increases with time before coming to a stop Cloak: The pilot can cloak for a vanishingly small amount of time. Titanfall 2 — at least the single player campaign — is not a stealth game, so it was important not to unintentionally hand players a ‘safe’ combination of mechanics that could be used to finish most missions (think MGS Phantom Pain and the silenced pistol). The limited cloak time and the much longer time it takes for the ability to recharge means that you either use it to get out of a jam or to get a drop on unsuspecting enemies. But then the cloak is gone (at least for a while) and you’re back to the usual trapeze artist madness. Cloak in moderation is good for you Other nice touches like being able to change direction in mid-air during double jumps and choosing an ‘always be sprinting’ option from Settings also add to this fast, movement-chain friendly navigation. Enemies Not to diss any other shooters, but you know how enemies in many modern day FPS games are often the same basic unit with more armor and perhaps different weapons? When there’s minimal distinction between the various enemies you encounter, your mind naturally gravitates towards the single optimal way to defeat them. This leads to repetitive combat, which leads to an ultimately monotonous gaming experience. Titanfall 2 circumvents this trope wonderfully through the use of orthogonal unit differentiation. This design principle basically refers to multiple game elements having different functions, forcing you to adopt varying strategies and behaviors while encountering each element. Titanfall 2 has enemies that differ in their speed, damage quantity, and type of attack, and this makes you evolve and adjust with each enemy encounter. This very rudimentary graph highlights Titanfall 2’s enemy variety Grunt: The most basic enemy in the game, this unit is a foot-soldier with limited ability and intelligence. They have a hit scan attack, which means you can’t dodge their bullets when you’re in their sights. The grunt’s hit scan attacks Although individually not that dangerous, Grunts can be formidable in groups, will call for backup, and sometimes have shields that force you to navigate (again, at speed) around them for a hit. A grunt’s shield Stalker: This is a robotic enemy that differs from grunts enough for players to employ new strategies while fighting. They do more damage and are faster than grunts. Rather than just hang around, Stalkers come right at the player, forcing them to get out of cover and showcase that speed. They also have projectile weapons that can be dodged. A stalker comes right at you and hits you with projectiles Drones: These are flying robots that, just like Stalkers, are fast, come right at the player, and fire projectiles that can be dodged. But also, just like Grunts, they attack in groups. By combining bits of other enemies’ behavior, you have a completely new one that must be dealt in a unique manner. Groups of drones can be very frustrating to handle Prowler: Lizard creatures that are insanely fast and rush to bite and maul the player. I’ve categorized them in the graph as CQC or Close Quarters Combat. A different enemy in design and behavior, not just in graphical veneers and name. Prowlers can kill you in seconds if you’re not careful Tick: Robotic arachnids that make a beeline for the player before exploding. They have huge speed and damage, but from a tactical standpoint, their damage hurts other enemies too. If two of these go off in quick succession… I could go on and on, but the central thesis is this: when you’re in a massive arena with all these enemy types, the battle is almost like speed chess on steroids. Because there are enemies that rush directly at you, sniping them all away while sitting behind cover is useless. Because many enemies have projectile attacks that can be dodged, you feel confident jumping and sliding their way around them. And because each enemy has a unique set of attacks and behaviors, your mind (and your character) is whirring at mach speed as you make decisions while bunny hopping your way to victory. Level Design If these core mechanics weren’t enough, Titanfall 2 also has delightfully unique levels that are all geared towards making you take faster decisions and navigate the landscape quickly. So you will be time traveling in one level, taking on different enemy sets in both the past and the present… Best level ever …and jumping from wall to wall while also traveling through time. Ever Another level has you in a manufacturing facility, traipsing your way through the interiors as the level literally moves around you. Factory fun Two levels later, you’re armed with a retrofitted weapon that can move platforms and you basically create the level as your rush to your escape. What does this button do? Two things to note here: Although the themes of these levels are separate, they all feed into the central game feel of breakneck speed by making both navigation and combat faster and more challenging. The themes are abandoned after the levels are complete, preventing any feeling of drudgery or sameness and leaving you wanting more. /// Titanfall 2 is not a perfect game. There still are environments that feel similar and enemy encounters that make you think ‘I did something like this two hours ago’. But these foibles pale in comparison to its most towering success: the conceptualization and execution of a distinct game feel. A game feel of speed. You feel like a maverick pilot with a planet-hopping jumpsuit every second, from initial training to dramatic denouement. And all of the game’s systems — movement, enemies, level design, and more — coalesce with the aim of making you feel that way. Know any other games that have executed game feel successfully? Any other things in Titanfall 2 that I missed out? Let me know in the comments! *Note: This article is republished in full on Next Level Design with permission from the author. Source: Follow Abhishek Twitter: Medium: Follow Next Level Design Join the Forum: Follow us on Twitter: Discuss on Discord:
  9. 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:
  10. 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:
  11. Hey guys I'm planning on applying for level design work soon and if like to get some feedback on my level design portfolio. Lemme know how good or shit it is and what to fix It's also meant to work on mobile AND desktop so tech bugs are also useful to know
  12. 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:
  13. 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:
  14. 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:
  15. 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:
  16. I love watching Conan O’Brien’s ‘Clueless Gamer’ series. The lovable talk-show host plays the role of video game troglodyte to perfection as he ribs on the needlessly complex pretentiousness of many best-selling games. He rolls his eyes through long cutscenes, chuckles at often juvenile storylines, and hilariously struggles with the game controls. And he kind of has a point. Although not a problem for gaming enthusiasts, the litany of games with high production values, sequels-to-prequels, and story-heavy RPGs are difficult for casual gamers to just pick up and play. The tutorials comprise of walls of text or entire levels that teach you the button combinations and timing needed to conquer that dungeon or find that lost city. And there’s nothing wrong with any of that. But it’s just not conducive to casual play. In this post, we’ll look at a level that serves as a game tutorial with understated brilliance: Level 1–1 in Super Mario Bros. This game is from a time where console wars and Let’s Plays were definitely not part of everyday life. It thus had to be very easy to pick up and play while also being challenging and hard to master. Super Mario Bros. walked that tightrope with elan. Without further ado, letsa go... /// The Opening Screen As soon as you start the game, this is what you see: Pretty standard stuff, right? While it seems quite simple, a deeper look reveals the beads of design sweat poured into this screen: Firstly, the opening screen is devoid of any danger, allowing the player to experiment with Mario’s basic controls and get a feel of what the game is about. This is far removed from, say, the Uncharted games where Nathan Drake usually starts the game hanging from a derailed train, battling pirates on boats, or in bar fights. Awesome as these games are, there’s something calming about starting the game simply and allowing players the freedom to mess around. Secondly, the screen positions Mario on the left with lots of empty space on the right. These design choices help create an affordance and subtly tell the player to move right. Note: Affordance refers to the possibility of an action on an object or the environment. For example, a sidewalk presents the affordance of standing, walking, and running. The fact that Mario stays on the center of the screen for the rest of the game makes his opening positioning on the left even more pronounced. Mario stays in the center of the screen for most of the game… …except in the opening screen It should also be noted that video game budgets weren’t the bottomless pits they are now, and the common elements used for both the bushes and the clouds speaks to Nintendo’s resourcefulness. Boxes and Goombas As Mario plows forward, he is greeted by things both intriguing and intimidating: Once again, there’s much more going on beneath the surface. The properties assigned to each element help differentiate friend from foe in the player’s mind: Let’s look at the box first. It’s stationery and suspended in the air, piquing curiosity rather than raising haunches. It’s also glowing and emblazoned with a huge question mark. These are signifiers that scream: interact with me, I have a surprise for you. And since the player has already used the left and right touch pad controls, the next logical control to use is the up button to make Mario jump into the box and reveal a coin. Note: Signifiers are signals that communicate the methods of interaction possible with an object or the environment. In a way, affordances are assumptions (stemming both from our past experiences and the object’s design) of what interactions are possible, and signifiers are explicit clues that either validate, invalidate, or enhance those assumptions. From the sidewalk example, a sign reading ‘No Running’ is a signifier indicating that the sidewalk is only for standing and walking. Signifiers are also majorly at play when we look at the Goomba. Unlike the stationery box, the Goomba is traveling towards the player. Unlike the glowing question mark that generates curiosity, the Goomba has an angry face that marks it as a potential threat. And just like with the box, the most obvious mode of interaction to vanquish the Goomba is to jump on it. And if the player doesn’t get this, runs into the Goomba, and dies: not much of a problem. The game is restarted to a point just a few screens before, and this time the player is wiser about the course of action. This short cycle of engagement allows the player to learn the basic controls quickly without inducing frustration. And don’t get me wrong, Mario can be a frustrating game at times. But the player has already learned the basic mechanics by that time. It’s as if the game is saying: okay, now that you know what I’m about, show me what you can do. It’s a frustration that makes the player more eager to beat the game, as opposed to making the player rage quit. The joy and inevitability of mushrooms Once the Goomba has been dispensed with and the player knows what to do with boxes, the game delivers its next surprise: Mario creator Shigeru Miyamoto said that he chose a ‘suspicious mushroom’ to make Mario bigger as he thought it was a symbol that would be globally understood. While the signifiers here are a bit more muddled, there are still enough teaching points for the player to imbibe. First, unlike the Goomba that moved towards the player, the mushroom goes right, perhaps giving the impression of getting away from the player and automatically making it more attractive. Second, it falls down from the platform, teaching the player that gravity affects some objects (like Mario and the mushroom) and doesn’t affect others (the boxes and platforms). Third, it hits the green pipe and comes towards Mario, an early lesson in how objects interact with each other in this world. If the player learns this quickly, he/she won’t be surprised to see enemy patrols bookended by pipes later on in the level. This is an early lesson… …to teach this Now, as the mushroom comes towards Mario, the players have two choices, right? Either read the signifiers and run into the mushroom, or give into distrust and jump over the mushroom. But no, the game only gives the illusion of choice here. Whatever the player’s feelings about the mushroom, Mario will run into it. If the player tries to jump over the mushroom, Mario will still bounce off the underside of the platforms and fall into the mushroom. Every single time. If Mario tries to jump over the mushroom… …he will fail And once Mario falls into the mushroom and becomes bigger, the player knows for sure that these particular mushrooms are friends, not foes. The level design here makes up for the questionable signifiers and ensures that players get the benefit of mushrooms and experience the joy of powering up. Teaching through safe training The last point we’ll look at in this post is how Super Mario Bros. teaches players its mechanics by first having them practice it in a safe environment before upping the ante. This is a recurring trend in many levels, and indeed many future Mario games. For example, there’s a series of pipes of increasing length in the first level. This section teaches the player that holding the jump button for longer makes Mario jump higher. And if the player takes time to learn this, fine. There’s solid ground between the three pipes instead of the gaping ravines that follow. There’s minimal punishment for taking time in learning the controls. Teaching Mario how to jump higher Almost immediately afterwards, there are two pyramid-like objects that Mario has to jump over. If the player fails, there’s solid ground between the objects and the exercise can be repeated. Once the player learns this skill, the two pyramid-like objects are repeated, but this time with a pit in between them. Failure will be costlier now, and that’s okay. The rules are on the table and skills are being tested now. That’s what makes the game fun but not frustrating. Learn here… …before applying it here There’s so much more to learn from each Mario level, but this post is already prohibitively long so I’ll end it here. Let me know if I’ve gotten anything wrong (I’m learning too, after all) and share any other examples of great game tutorials that you can think of! References (for some screenshots as well as content ideas): Extra Credits: Eurogamer: nesplay: Source: Follow Abhishek Twitter: Medium: Follow Next Level Design Join the Forum: Follow us on Twitter: Discuss on Discord:
  17. Pascal works as a freelance game designer and creative director since 1995. He was commissioned by major studios and publishers including Activision, SCEE, Ubisoft and DICE. In particular, he was Lead Level Designer on the multiplayer versions of both Splinter Cell - Pandora Tomorrow and Chaos Theory, lead game designer on Alone In The Dark - The New Nightmare and Creative Director on Wanted – Weapons of Fate. Leveraging his console design experience, he is also working on mobile games, including freemium ones. His first game for mobile platforms, The One Hope, was published in 2007 by the publishers Gmedia and received the Best In Gaming award at the 2009 Digital Media Awards of Dublin. Proximity, responsiveness, relevance... these are the watchwords of efficient playtests. In the previous installment of this article, I had explored the reasons for the rising importance of playtests in game development. In an industry where games represent increasingly high financial risks for publishers, playtests have come to function as a strong guarantee for quality gameplay. I will share with you today my experience regarding the methodology employed in preparing and conducting them. Heeding the Clients: The Design Teams Foremost, one must be aware of a fundamental say: the role of playtests is not to redo the design in place of the design teams -- for either game or level design. They are instead conducted to help them. This observation is crucial, because it drives the entire approach to playtests. Firstly, we must respect the hard work of the design teams. Having had my own responsibilities in game and level design, I know how difficult it is to make "a good game". We must respect those who put their whole hearts into building the best game possible; we must not scorn or undervalue their work. Secondly, playtests must adapt to the needs of the design teams. Good tuning for maps or gameplay mechanics is often the result of trial and error. Knowing this, designers should require experimentation; playtests can afford them the opportunity to test out their hypotheses regarding design issues, and must therefore adapt to particular needs as they arise. Lastly, playtest results must be made available to the concerned parties as soon as possible, as time allotted for game development is always short. Preparing a Playtest Campaign A playtest campaign generally requires around one month of preparation. We must first define its objectives, because they will determine what types of playtesters we shall have to recruit, the scale of the sessions (1, 2, 4, 8, 12 players), and their duration (from half a day to a full week). We will also have to attend to the logistics as well as the legal framework (non-disclosure agreement, eventual monetary compensation for playtesters when sessions last over a half-day, etc.) And we must, of course, prepare the design teams to effectively utilize the playtests. One does not grow the best crops in dry land; a playtest's effectiveness is rooted in the playtesters themselves. Half the battle in running an effective playtest campaign lies in wisely choosing playtesters, which requires investment of time, energy, and perhaps a bit of money and patience. Recruiting takes time: we must not only hire as many candidates as possible (in order to have a solid pool of playtesters). We must also evaluate them. The purpose of evaluation is obviously to judge the candidate's gaming competence, but also his ability for analysis and self-expression. Evaluation may take several forms. An initial selection can be done through a more or less thorough questionnaire, to be completed by the candidate. The true evaluation, however, must be done during the sessions themselves, where we can observe the candidates at play. We must establish a protocol for obtaining the most consistent results possible. There is no "all-purpose" evaluation protocol; we must also be able to adapt to specific circumstances as the situation mandates. When I built a playtest structure at the Bucarest Ubisoft office, I encountered an interesting problem: we needed playtests for console games, but all the players we could find locally were exclusively PC gamers. I had to set up a specific protocol to evaluate the ease with which our Romanian candidates could adapt to console gaming. Ubisoft's Splinter Cell: Chaos Theory The protocol consisted of briefly explaining the gameplay controls of a complex game (the multi-player mode in Splinter Cell: Chaos Theory), and then setting them loose in the game in order to gauge the speed at which they adapted to the gameplay. This selection method proved to be quite efficient. Candidate selection must therefore be done according to a given playtest campaign's objectives. We may have need of only extremely skilled players who have already mastered the genre, or we may require novices, if the objective is to playtest the accessibility of the game. Communication regarding playtests also takes time. Before candidates can turn up on your doorstep, they must first be made aware of your need. In my experience, while recruiting through generic classified ads will yield a high number of candidates, many will be too young (careful of those labor laws!), and most will be only casual gamers. A good way to recruit experienced players is to make use of forums, gaming clans or specialized stores. It takes much more time but I always got great playtesters this way. In playtesting, quality matters more than quantity! Organizing the Sessions I shall address three aspects of playtest organization: the composition of the team, the preparation of the playtest protocol, and its logistics. Recruiting must start at least four or five days before the session itself. At this stage, the playtest manager already has access to a database of candidates that have already been evaluated or, at least, identified. He can thereby choose his playtesters according to the session's theme. Invites are sent by e-mail. At this point, we realize the importance of having a great number of candidates, since most are not available at will. We must therefore engage in mass-mailing to ensure sufficient availability of playtesters come session day. It is also best to invite at least one more playtester than necessary, since last minute withdrawals are commonplace. It is also usually a good idea to ask playtesters to confirm their presence via e-mail. Protocol setup is an important part of session preparation. Some playtests are organized near the end of the development cycle, to tune up maps or the game system. The protocol for this type of playtest is often straightforward: we must allow the playtesters to play for a maximum of time, note game statistics, and organize open Q&A sessions. The time when playtests are most useful, however, is during earlier stages of the development cycle, when the game system and maps are still in gestation. Let us not forget that the earlier we detect any issues, the easier and cheaper it will be to correct them. During the development of maps for the multiplayer version of Splinter Cell: Chaos Theory, I had organized playtests to evaluate the structure of the then still-embryonic maps. I specifically remember the Aquarius map: By having it tested by highly experienced playtesters, we -- including the level designer who had built the map -- quickly realized that the map was far too large. Having noticed this problem, he immediately rebuilt his map, which took little time as the map was still just a prototype. It took him a few iterations to downsize his map to the optimal size. In the end, Aquarius became one of the game's most popular maps. Ubisoft's Splinter Cell: Pandora Tomorrow Playtests allow us to shed light on many problems and to validate (or invalidate) hypotheses set by the design team. During the development of the multiplayer version of Splinter Cell: Pandora Tomorrow, specific playtests were undertaken with the purpose of tweaking the characteristics of certain pieces of equipment, such as the smoke grenade. The latter is one of the most-used accessories by the spies, since its cloud slows down the spy's opponents (the mercenaries), and it can even put them to sleep if they stay too long in its area of effect. Tuning the smoke grenade's parameters was not so simple -- if its range was too wide, it would be an unstoppable weapon for the attackers (they would simply need to employ a single grenade in a corridor to block any access by their opponents). On the other hand, if the grenade's effect zone were too small, the weapon would be completely useless (defenders have vision modes allowing them partial visibility through the cloud). Finding the right values took us a lot of time. Lastly, to be relevant, protocols must adapt to problems encountered in previous sessions as well as to the test requests put forth by the design team. This commensurability with the development team's needs is one of the hallmarks of a successful playtest. I shall address this point later on. Let us now talk about logistics. Good playtests require a stable build of the game without too many bugs. When directing playtests in the middle of the development cycle, this may be easier said than done. Regardless, the game must be sufficiently stable, and maps must be rid of the most detrimental bugs (such as the inability to climb a ladder, for example). A game delivery protocol must be set up with the development team. The latter must deliver a playtest-ready version of the game to the internal debug team, which will rapidly review the game to ensure that the version is playtestable. When issues arise, cooperation between the debug and development teams will allow for swift corrections of issues, and subsequently the production of a stable version suitable for playtests. Such organizational finesse requires a lot of discipline from all of the teams involved. Another good practice is to prepare a checklist for the level and graphic designers, so that they can make sure that their own maps are free of blocker bugs. Finally, the playtest session manager himself must make sure that the version is indeed playable. Playtest Sessions Playtests are especially instructive when design team personnel attend the sessions; indeed, a game or level designer will base his work on ideas he will formulate upon observing the behavior of the players. However, players do not always react as expected, and we must take their diversity into account. By seeing with his own eyes how real players use equipment or navigate a map's topology, and by asking them the reasons for their behavior at the end of the session, the designer can rapidly make optimizing adjustments -- a demonstration is always more efficient than a long speech! It is thus highly recommended to encourage the designers to attend the playtests. That's why I strongly recommend that playtests should be conducted on the premises of the development studio itself. Remote playtests are valuable for tweaking map and system settings, but less so for playtests on an embryonic game. Obviously, playtest observers must follow certain rules: they must not voice their comments or ask any questions until they are authorized by the playtest session manager, in order to preclude influencing the game session or the playtesters' judgement. If it is desirable for designers to attend the playtests, it is simply essential that the playtest session manager does so. He must not simply organize the session and ask his questions at the end; he must actually watch the playtesters at play. The reason is as follows: early playtests often have a limited number of playtesters, and the problems found are liable to be numerous. This fact is likely to affect the relevancy of feedback received, rendering it inconsistent at best and flat-out contradictory at worst. The manager must take all of this into account, evaluating the relevance of the feedback himself. Note, however, that the involvement of the playtest manager can be cause for controversy. In some cases, a playtest manager must simply behave as a mere observer; in fact, this is generally the best attitude to have during playtests occurring later in the game development, when it is time to fine-tune game system settings. The objective at this point is to collect a maximum of statistical data from a high number of playtesters. By contrast, during early playtesting meant to evaluate the strengths and weaknesses of embryonic maps or game systems, the comparatively low quantity and greater heterogeneity of the collected data require a more aggressive, reactive, and direct involvement on the part of the manager. At this point, he must necessarily "get his hands dirty", as he'll be working with incomplete data. While there is a risk of error here, my experience has shown me that playtest results are actually more concrete at this stage, and thus more useful. My experience amidst one of the best development studios in France has taught me that the playtest manager must be wholly invested in the final quality of the game, and must not be content with being a mere observer. This conclusion once again indicates the need for a close relationship between the playtest and the development teams. Debriefing We thus arrive at the final result of a playtest session. The general idea is to bring the playtest conclusions as quickly as possible to those who most need it -- generally the designers and project leaders. Debriefing may take several forms. First, design team members who observed the playtests may put their most pressing or immediate questions to the playtesters. They often leave the playtesting room with some strong ideas burning in their mind. Then comes the report, which must make a clear distinction between the facts (statistics etc.), opinions from the playtesters, and the manager's own observations and conclusions. Raw data must be provided so that the designers know on which bases the manager drew his conclusions. Putting all the cards on the table is a good way to establish trust with the ones who will read the report. Let us not forget that the purpose of playtests is to improve the game, and not to settle scores. A full-fledged report takes time to compile and to write so a shorter, intermediary debriefing might be needed if the needs for crucial feedbacks is urgent. As a final note, I'll mention that I had begun to experiment at the Milan Ubisoft studio with a protocol allowing a remote office (in another city or even another country) to obtain a hot report on a map playtest. Named D3 for "Debrief Dynamique à Distance" (Remote Dynamic Debrief), this protocol consists in quickly establishing a list of the main open issues, and organizing an online session where the concerned designers (at the development office) and the playtest session managers (at the playtest office) can log on. They can then explore the maps while the playtest team explains the issues with much precision, and all can work together in developing possible solutions. A playtester may even join them, contributing further to the dialogue. Source: Follow Pascal Website: Twitter: Follow Next Level Design Join the Forum: Follow us on Twitter: Discuss on Discord:
  18. 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:
  19. Pascal works as a freelance game designer and creative director since 1995. He was commissioned by major studios and publishers including Activision, SCEE, Ubisoft and DICE. In particular, he was Lead Level Designer on the multiplayer versions of both Splinter Cell - Pandora Tomorrow and Chaos Theory, lead game designer on Alone In The Dark - The New Nightmare and Creative Director on Wanted – Weapons of Fate. Leveraging his console design experience, he is also working on mobile games, including freemium ones. His first game for mobile platforms, The One Hope, was published in 2007 by the publishers Gmedia and received the Best In Gaming award at the 2009 Digital Media Awards of Dublin. There is nothing new about asking testers for their feedback on a game in development. However, the practice of managing playtests by following near-scientific protocols, and of integrating them very early in the development cycle, is a more recent trend. The spread of real playtests in the game development cycle is probably part of this silent revolution; a revolution profoundly affecting the development environment. How? Playtests force game development to center around the players instead of the hopes of the development team. Let's look at the effects of this shifted focus: Playtests allow the identification of gameplay or level design flaws that could elude the grasp of normal testers. After all, testers are always seasoned gamers who are not necessarily representative of the target audience. Who better than a casual gamer to pinpoint issues related to the difficulty curve or the overall understanding of the game? Playtests fulfill a moderator role in situations of disagreement or controversy within the design team. A series of playtests can quickly settle a contested issue by resolving almost any counter-argument or dispute, thereby preventing the disagreement from spiralling into an impasse. Playtesting is also a management tool. The partnership between playtesting and design can be very constructive. For example, it can be quite instructive for game and level designers to observe gameplay during playtesting, allowing them to immediately determine whether or not particular aspects of their design work as planned. Playtests executed on pre-prod mock-ups allow the anticipation of problems very early on, as well as timely corrections of said problems (the faster a problem is corrected in the development cycle, the less expensive it is). Game development can therefore become truly "player-centric". According to the playtest protocol and the selection of playtesters (hardcore, casual, etc.), playtests allow the examination of a specific aspect of the game with heightened acuity: game balance, navigation, understanding of the game objectives, etc. We all have the opportunity to play games that display high production values but nonetheless suffer from obvious flaws: erratic difficulty curve early in the game, navigation issues, overly complex interface, and so on. Such flaws could often have been easily avoided if they had been identified early enough. Major names in the industry understand this quite well, such as Ubisoft, which possesses qualified teams and invest lot of resources in this aspect of game development. What kind of problems might we fix or prevent with playtests? Some examples include: Accessibility and ease of use (interface, navigation within the game, etc.). Identification of sure-fire-wins, i.e. strategies allowing a player to easily overcome any challenge created by the designers and therefore remove any interest in the game or the current mission. This issue is especially sensitive for multiplayer maps. Fine-tuning of the game system: experience has shown me that the intensity of use of game features (weapons, equipment, actions, etc.) tends to vary considerably according to a number of factors. These include player profiles, the time a given player spends on familiarizing himself with the game, and of course the game tuning itself. Only through long-term playtests with relevant samples of players can we ensure that the game tuning maintains its balance and relevance even after long hours of gaming. Analysis of the early reactions of different categories of players during their first session. This will highlight their first impressions and initial frustrations. Some game demos have probably had a negative effect on the marketing of games they were meant to promote because of accessibility and tuning issues that could have easily been spotted during playtesting. For multiplayer games, the robustness of the game system and the potential of maps. I have had several opportunities to delve deeply into playtest management. I built the playtest structure from scratch at the Ubisoft Annecy studio, where the successful multi-player "versus" modes of Splinter Cell: Pandora Tomorrow and Chaos Theory were developed. I set up the recruiting methods, playtest protocols, and the debriefing methods employed in this program. I also set up a playtest cell at the Ubisoft Bucarest office and led playtests there myself. Playtests have changed the way I perceive my job as creative director, so I feel the need to share my experience with everyone. Let us start with a definition. Playtests consist in analyzing the reactions of a representative pool of players toward gameplay in order to improve the final game and to make sure it matches their expectations. Some will argue that game testing is nothing new. True, but real playtests have nothing to do with the debug testing executed at the end of the development cycle. Traditionally, game designers ask testers for their opinions. Testers are often excellent players and are therefore not always representative of the targeted demographic which is often made up of mainstream gamers. Moreover, testers generally get to know a game so deeply that their knowledge of it strengths and weaknesses profoundly influences the way they play. Therefore, they do not play as someone who discovers the game for the first time. Well-executed playtests allow us to evaluate gameplay strengths and weaknesses with great accuracy since they rely on two solid principles: The careful selection of playtesters. The use of ad-hoc protocols. The Selection of Playtesters Just as a peasant needs fertile ground in order to ultimately obtain the best yields, good playtests require a group of carefully-selected playtesters. I could never insist hard enough on the importance of the recruitment and evaluation of the playtest candidates. What are the recruiting criteria? This depends, of course, on what kind of playtests we are planning. We may need hardened gamers, beginners, console-only gamers, multiplayer fans, and so on. The candidate's gaming proficiency and overall game culture represent the first criteria. The second is the candidate's ability for analyzing and drawing conclusions from their gaming experience. Note, however, that it is not mandatory that a playtester should possess a high level of competence on both criteria. Again, the type of playtests will determine the requirements. I have the utmost respect for the playtesters I have worked with. Their good will and enthusiasm are boundless. Many came to Annecy from distant cities like Lyon, Grenoble, or Belfort simply for an unpaid half-day session! This generosity and enthusiasm are characteristics of our industry; let us nurture these characteristics by treating playtesters with the gratitude and respect that they deserve. The Use of Ad-hoc Protocols The protocol is the unifying thread of the playtest session, defining the objectives, allocation of resources, and especially the methods of collecting and parsing information for a given playtest. The playtest protocol needs to adapt to the specifics of the challenge at hand (game system tuning, navigation, map concept, etc.). During the playtest campaigns that I led, I would prepare a different protocol for each session. Indeed, an important part of those playtests involved multiplayer maps under construction or game system tuning. Each session revealed specific problems to be analyzed in the subsequent session. I shall conclude this first part by repeating that a playtest campaign must be directed with a true scientific rigor if it is to be of any use; one does not conduct playtests simply by bringing over one's buddies for a few hours of fun followed by a session of easygoing Q&As. Each aspect of the session must be carefully tailored in order to best realize the objectives at hand. Managing the session itself requires constant attention, not only because one can learn much by watching the playtesters in action, but also because things do not always go as planned! I shall address concrete aspects of playtests in the second part of this article. Source: Follow Pascal Website: Twitter: Follow Next Level Design Join the Forum: Follow us on Twitter: Discuss on Discord:
  20. Recently through the mysterious and tenuous connections of social media, I was asked a few questions about the game design of Halo multiplayer. Yes, the first Halo. Combat Evolved. Yes, I know that game came out when dinosaurs still roamed the Earth, but there are still a few things about the development process that might be interesting to designers. One question in particular caught my attention: “Was quick-camo intentional?” Paraphrased, I read the question this way: "When the player picks up the Active Camo powerup, they turn invisible. If they shoot while they're invisible, they become visible for a while. But some weapons seem to make the player fade in and then back out of view faster than others. Was that intentional?" The answer is related to one of my Universal Truths of Game Design. The Universal Truths are rules that I have figured out throughout my career in game development. I know they're true, because I have followed these rules and succeeded, and I've ignored them (or just been ignorant of them) and failed. In this case, the answer comes from; UNIVERSAL TRUTH #3: You must create a mental model That means that, as a designer you must create a theoretical model that describes how the systems in the game should act with each other. Game data design and balancing is an incredibly complex task. As anyone who has ever opened up a set of modern game tools knows, there are an overwhelming number of places where a designer can change numbers that can affect how the in-game systems behave. Here’s an example picture of an open game toolset that I grabbed off the web: It’s a pretty typical screenshot of a set of development tools. There are windows that allow the designer to place objects in 3D space, and along the right side of the screen there are a bunch of folders that hold different types of data that you can fiddle with. And adjusting any of the numbers will change what happens in the game. I’ve seen it happen many times, a good game designer is tasked with making the game more fun and, faced with the complexity of that job, gets overwhelmed and doesn’t know what to change to make the gameplay better. At best, a designer stuck in that situation is ineffective. At worst, the game sucks because of them. In my process, I make a mental model of how I think the system should work. It gives me a place to start figuring out what numbers to change, and in what ways I need to change them. From there, I adjust the data values to suit that model. And the more rigorous I am with my mental model, the more confidence I have when I'm adjusting the sea of numbers in front of me. Let me give you an example. As we were working on Halo, the team lead’s first choice was to make the guns work the exact same way in single player and multiplayer. The responsibility for balancing all those numbers had been given to a senior designer on the project, but the general feeling was that his changes were not making the game more fun (see above). I talked things over with Jason Jones (the creative genius at the core of Bungie) and he and I agreed that somebody with more experience in game balance needed to take over the job. Initially, Jason volunteered to handle it all himself. As the man behind the game balance of Myth, and the Marathon series of shooters he was more than capable of the job. But I pointed out that multiplayer would have very different needs for the guns than the single player team. Weapons in the hands of dumb AI bad guys need to provide fun challenges for the player to overcome, but weapons in the hands of a player are a different matter. As a quick demonstration, think about the gunfights in Halo. In most cases, encounters have multiple bad guys shooting at you at one time. Each gun can be adjusted to be a little bit weaker in enemy hands so that player (the hero of the story) doesn't get overwhelmed. But in multiplayer, most decisive fights are one on one. Guns needed to be unique and powerful. I also pointed out that if we just used one set of data, as I was changing the gun data for multiplayer I might be damaging the overall balance of the single player game. Jason agreed, and we decided to "branch" the data and create two versions of the numbers, one for single player and the other for multiplayer. So starting out, I had a handful of guns with some data already attached to them based on the single player game. I had the freedom to change whatever I wanted. All I needed to do was figure out how to make the fighting fun. I needed a roadmap to follow. A mental model. But where to start? Follow this link to read this section of the article: But just making the Halo multiplayer weapons respect their roles in the matrix really wasn’t enough. That’s kind of “first-person shooter design 101.” In a first-person shooter, weapons are the stars of the show. They need to look good, and sound good. They need awesome animations. They need to be effective in their roles and they have to make the player feel powerful and competent. But perhaps most importantly, they need to reward player mastery. To accomplish that, the design needed depth. Universal Truth Number Three (Part 2) I characterize depth as game systems or balance details that are included to enrich the experience of the player, but that are not necessarily explained or documented. They’re meant to be discovered and exploited as players’ expertise with the game grows. There are lots of great examples of what I’m talking about in all types of games, but I will offer up a couple of made-up examples for illustration: Example Game 1 is Wizard Warts, a fantasy role-playing game about a cabal of magical toads set deep in a haunted swamp. Pollywogs evolve into acolytes - able to hop, swim, wear armor and use weapons. But once they grow strong enough in the shallow waters around their home, they can quest deep into the swamp to find and eat one of the legendary magic Dragon-Flies. Four different types of Dragon-Fly swarms live in the swamp: Fire, Ice, Poison/Acid and Love. Once a toad gobbles one of them up, the acolyte evolves into a Toadzard, and can thereafter belch spells powered by the type of bug-dragon they gobbled. It’s important to note that an acolyte toad can only gobble one type of magic Dragon-Fly in their life, and the choice (and the evolution into Toadzard) is irreversible. The swamp is filled with a variety of magical monsters. They are all dangerous and hostile, but we can use the data of the game to add more depth to the gameplay. For example there are Plant type monsters are more vulnerable to Fire magic and take x3 damage from any source with that description, while Undead creatures are immune to Poison spells. Notice that one of the Dragon-Flies has two “type” descriptions – Poison/Acid. I chose to include the "acid" description as part of that spell group because of the depth that I wanted to include in the design. Acquiring spell powers and evolving into a Toadzard would be a big part of the fun in the game. But if the player chooses "poison" spells and finds that they are literally useless against undead monsters, and "poison" was the only type of damage in that spell category, it could leave an entire class of Toadzard useless in some situations. That’s a very un-fun outcome to players who chose to build that type of character, and it might make the game unexpectedly difficult. Consider the example of player who decided to make their Toadzard Poison/Acid and then had to take on a tough mission against Undead bad guys. A player running into that situation might have so much difficulty that they abandon the game, and who could blame them? Dropping some "acid" in helps solve these problems. "Acid" spells could still damage undead, leaving us the freedom to make "poison" spells useless against them. At this point you might reasonably ask; "Why fight so hard to preserve that part of the design at all?" The answer is that there is a lot of potential drama in the design that occasionally makes spells useless. It aggressively forces the player to adapt their comfortable play patterns, and it might encourage players to explore more of the content in the game. Imagine the player who finds themselves in a scary predicament when the spells and strategies that they've previously counted on suddenly stop working entirely. But, as they dig into the fullness of the spell systems they find that there is a way for them to adapt to the game situation without having to start over from the beginning. A less aggressive way to achieve a similar effect would be to extend the Fire example above, and only give the monsters vulnerability to some types of spells. So for example we could include Hate type monsters that were vulnerable to Love magic and Lava type monsters that were vulnerable to Ice magic. Anyone familiar with the Pokemon series of games will recognize this precise design. It doesn't penalize players as harshly as the proposed design above, but it's also not as dramatic in the player's experience. Follow this link to read this section of the article: The interesting, and sometimes wildly frustrating thing about depth in a design is that some players never become aware of the underlying nuances. In fact there are countless examples where depth is built into games, but players don’t understand it or take advantage of it. Multiplayer games suffer the most from this kind of mismatch in player expertise, because the parts of their community that grasp the deeper elements of the design and use them often have a significant advantage over the less-knowledgeable. This can lead to all sorts of hard feelings. (if you’re a League of Legends fan, last hitting creeps should spring immediately to mind) As I mentioned earlier, depth in the game balance can exist without being documented anywhere else. Players will feel the effects as they play and hopefully they’ll pick up on the subtleties and learn how to exploit the design. But for that to work well the design needs to make some kind of intuitive sense to the player. In the Wizard Warts example, the player would glean that Fire is extra dangerous to plants. That's a common trope in games and of course; wood burns. But the underlying logic that "poison" wouldn’t have an effect on the Undead since they don’t have a working nervous system or circulatory system is less obvious, and so might never make sense to the player base. If the game is popular enough, the players will learn how the numbers work and "play around" them, but they're liable to think there's some kind of a bug in the game. So to recap: We need a mental model with an underlying design for depth which is (hopefully) intuitive to the player. Which brings me back to the multiplayer weapons design process for Halo. I’ll explain how it all connects in my next post! Universal Truth Number Three (Part 3) I wanted the Halo weapons to have depth, so I began thinking about all the guns that were in the matrix. I needed to understand what they were, and how they fit into the design. The Human weapons were easy to understand. I’m a Human, and I know what we use guns for. But the weapons used by the aliens of the Covenant were another matter. The easiest place to start would be to simply say that the alien guns were simply analogs to the Human weapons on the matrix. The pistols, assault rifles etc. could be basically the same, only with different visual presentation. Easy, yes. But that seemed like a huge missed opportunity to add depth and richness to the game. So I started thinking why would the Covenant choose these particular weapons in the first place? We (Humans) have guns. And once guns were developed, Humans developed systems to protect people from bullets (bullet proof vests, riot shields etc.) And then in the relentless march of progress, people invented ways to kill other people inside of their body armor (armor piercing bullets etc.) Remember that at the time there wasn't a lot of settled "lore" about the game story. I decided that in my model, Human Spartan armor was created as a desperate response to the Covenant attacks. It had similar functions, like a personal shield, but was based on different technology. So how about the Covenant? There were some notes about the bad guys and their guns, but the honest truth was that the aliens shot light-up bolts of energy because they looked a lot more visually impressive coming towards the player on screen. If the bad guys shot nearly invisible bullets and you couldn't see them coming at you, it would be a total drag every time you died. But just knowing that they were colored lights wasn't going to help me balance my combat data. Clearly they had guns. And they had an equivalent to our body armor – personal energy shields. I could imagine Covenant warriors facing off against enemies across the universe with their plasma weapons blazing. Or more specifically, their Plasma Rifles. As an poor man's analog to the Human pistol, the Plasma Pistol was a pretty dull thing, only useful as a desperation choice for one of the two gun slots you were limited to. I stared at the various data fields in the Halo toolset for quite a while, trying to imagine what to do with the Plasma Pistol to make it cool. And then a question occurred to me: What if the Covenant had to fight an enemy with shields like their own? Or what if they had to fight themselves? They’d need their own armor-piercing capability. In the Halo tools, every projectile had a “shield damage” value. Most were set so that they would damage shields at a rate that matched the damage that their bullets would do to the player's health bar. None of the projectiles were really aggressively balanced against shields. And you know how I feel about data balance in a matrix! I started to experiment with making Plasma Pistol bullets designed to specifically shred shields. It was a snap to make a projectile that blew them off quickly, but then it seemed overpowered to also make those bullets do good levels of “body” damage as well. Then it occurred to me: maybe the shield-shredding effect could be assigned to a different bullet. The one assigned to the secondary fire-mode for the gun – the overcharge. This proved to be very fun. In my early playtests, I'd grab the Plasma Pistol and use the overcharge specifically to blow up the shields on enemies that I ran across. But it was frustrating when I missed the overcharged shot (full disclosure: I am a much better designer than I am a player) So to compensate, I gave the shield-busting projectile a terrifying amount of magnetism so that it would track towards whatever I shot it at. I loved it – I could overcharge the Plasma Pistol and let the shot fly, and it would whip around corners and blast targets, stripping off their shields just as I came running in behind and mowed 'em down! In the short term, I won a lot of playtest games. Unfortunately, once this tactic became known to other players, battles essentially started with “overcharged salvos” of tracking shots whipping across the battlefield. The only thing you could do was hunker down in cover and wait as the first round of supercharged shots came whipping overhead before you started moving. It was interesting to see how these data adjustments changed player behavior during our playtests, but a bunch of auto-tracking missiles wasn’t very true to the spirit of the Halo combat model which rewards player skill, fire and movement. So alas, the “super tracker” overcharged shots had to go. But I did keep some tracking, to help reduce the frustration of a player using the overcharge trick but missing the shot entirely. So my mental model of bullets/armor/armor piercing was working to create fun combat. But what else could it do for the game? Follow this link to read this section of the article: I made one other change under the hood of the Human weapons, which many people don't even realize exists at all. Jason Jones had designed the Human pistol to be the weapon of choice for players at medium/long range. The accuracy, high damage and the limited sniper zoom on the pistol made it a powerful choice for dropping enemies right at the edge of their "AI awareness" bubble, enabling players to pick off one or two targets as the enemies startled into their alert state and then came charging into battle. But it was strong. Damn strong. Frankly, it was too strong for multiplayer. I toyed with damage settings that made the multiplayer pistol weaker than it's single player counterpart. But to be honest, once it was "nerfed" it became a pale shadow of it's single player cousin and using the pistol became a lot less fun. Still, I felt that turning the full power of the pistol loose on the Halo multiplayer "sandbox" unaltered would be opening the door to endless criticism, so I decided to made a subtle change. The single player version of the pistol is "autofire" - meaning that if you hold the trigger down the weapon will repeatedly fire at the precise point you're aiming at. But... that's not true with the multiplayer version of the pistol. I wanted to at least challenge the skill level of players a little more. So the multiplayer version of the Pistol has shot spread. What that means is that, if you simply hold the trigger down and let the pistol automatically fire over and over, each bullet will deviate from the point that you're aiming at. And the amount of deviation will increase with every bullet. I wanted to make it so that players could still use the badass pistol, and it could retain the fun feeling that it had in single the single player game, but only if the player could master the technique of actually pulling the trigger with each individual shot. I still believe that this was a "righteous fix" - meaning that it was justified and the solution was (in my humble opinion) elegant within the restrictions of the established game play. Unfortunately, I lost my nerve a little bit. After all, this was a huge change from the behavior of the single player version of the Pistol. I was worried that players might have to re-train themselves to use the multiplayer version of the gun, which again might lead to huge volumes of outrage from players. So I didn't make the pistol deviate enough while auto-firing. Oh, the shots will spread if you hold the trigger down, but not so much so that you might not still get the head shot that you were aiming at. To this day, not adjusting the spread rate of auto-fire on the multiplayer pistol is one of my regrets. I wasn't aggressive enough! But hey, people still seemed to like the game. One of the things that I’m proudest of is how my mental model for Human and Covenant technologies had profound impacts on the single-player game. For example, the high camouflage ping rate of the Human weapons meant that, even late in the campaign, Human guns were ideal for exposing Covenant bad guys that were cloaked in Active Camouflage shields. A second impact was on the AI development of the game. When the mighty Chris Butcher (AI programmer for Oni and Halo) saw the changes to the Plasma Pistol, it gave him the idea to have the Jackals use the Plasma Pistol in it’s overcharged mode, along with their shields, to greatly differentiate them from the Grunts wielding Plasma Pistols and grenades. I’d like to take a moment here to talk about why I keep using the term “mental model”. You might ask “Shouldn’t the design document cover all of this?” And my answer would be that my design documents have never captured all the details of the game. I find documents valuable in helping me codify my own thinking, and they can occasionally be good tools for communicating a design to the people that are responsible for implementing it. But I've never encountered a game development team that religiously read every document produced by the game designers. And when you're actually knee-deep in making the game, you rarely have the time to fiddle around with keeping all your design documents up-to-date. So my own process has evolved to be very fluid and organic. I start with some clearly stated intentions as to what I want to accomplish with a design, and then start to build it. But along the way, I watch the design evolve and continually evaluate that process. As things happen I’m constantly deciding, “How is thing coming together? Are we going in the right direction, or should we be going another way?” So my paper specs get me started, but beyond that my mental model is constantly evolving. I once read a quote from Tim Schaffer, that I'm going to have to paraphrase heavily because I can't seem to find the original quote. He described the process of making a video game as building a puzzle out of pieces falling in slow motion. But the pieces fall at different speeds and the shape of the puzzle changes, depending on which pieces you get, and which fit. That is a very poetic and accurate description of what my process looks like: I like to toss the pieces up, and every day take a look to see what’s coming together, what’s falling behind and what shape the final form is going to take. (I apologize, but I can't find the quote out there on the web. If you find it please add it to the comments section and I'll edit this post!) So that brings us full circle, back to the one-sentence blurb question that I got via Twitter: was quick camo intentional? Yes; entirely intentional. All of the camouflage behaviors are a product of my mental model for Human and Covenant weapons, and my desire to add depth to the gameplay model for players to discover and exploit. Did it work? As I said before: often players will never know all the details included to add depth to a game. The fact that a person on Twitter was asking about that feature proves that, although my mental model was thorough and effective, it wasn’t so intuitive that players completely understood it, even after a decade of playing the game. But here’s the thing: even if an audience doesn’t understand all of the influences that shape their experience with a work of art, those influences still resonate in their mind at some level. That’s called subtext. When I watch a performance of Cirque du Soleil, I don’t know exactly what’s happening in the overall story of the performance. But I know there is a story. And my experience as an audience member is all the richer for it. There are large sections of the above article omitted here. We strongly recommend you read the articles in full via these links: Follow Hardy Youtube: Twitter: Follow Next Level Design Join the Forum: Follow us on Twitter: Discuss on Discord:
  21. This article is the first of a two-part series covering theories behind level design, establishing some rules for level creation. The intention is to aid those new to the field who want to design levels for pleasure or pursue a career in level design. Introduction Level design is the data entry and layout portion of the game development cycle. A level is, for all intents and purposes, the same as a mission, stage, map or other venue of player interaction. As a level designer, you are chiefly responsible for the gameplay. This article will give you insight into developing good levels for any type of game, whether they are military missions for your horde of tanks, aerial encounters for a flight simulator, a dungeon for a role-playing game, a board for a puzzle game, or a map for a world conquest god-simulator. I will present some theories behind level design, starting with an exploration of what good level design means. Then it delves into the non-electronic roots of computer game design from chess to GI Joe action figures, and how we can learn from their success. Finally it takes a thorough look into the theories behind storytelling and how we can apply them to level design. Escapism A player buys a game to escape from his or her reality. Good levels and hence good games will immerse the player and suspend their disbelief. From the moment the title screen comes up, you have their full attention. From that point on, they should see and do nothing that reminds them that they are anywhere but in the world you have them in. You must furnish a setting and actors that meet the players’ expectations. That is, you need to design a map that not only looks like it could fit inside the world they are playing in, but contains elements that help to draw that reality in the players’ heads. A player’s sense of escapism and suspension of disbelief can be ruined by a variety of common errors. These include bugs such as graphics glitches or crashes, but from a design standpoint, these also include inappropriate content. For example, a McDonald’s Golden Arches on the skyline of a medieval town is obviously out of context. Similarly, if a player is told by a character to hit control-T on his keyboard to teleport, then it would remind him that he’s typing at a computer and not in some fantasy realm. Generally, to maintain the players’ sense of escapism all content should be appropriate to what would be seen, said or done in the game setting. Challenge – Testing the Players’ Mettle Players buy games to be challenged. If there is no challenge, they might as well be interacting with their word processor or spreadsheet software. Challenge should always come in the form of testing the players’ skills at the core gameplay. A shooter should test their aim and reflexes. A wargame should test their tactics. A strategy game should test their strategic sense. Some games successfully combine forms of gameplay to offer a variety of challenges, such as Command & Conquer, which has both planning/building and tactical gameplay. Command & Conquer Challenge comes from difficulty. The trick to good level design is to present challenges that are difficult enough to merit the players’ attention and make their heart or mind race, but not so difficult as to always leave them failing and disappointed. It’s a delicate balance based on what is perceived as the median player skill, and it is a variable constantly adjusted up until the game ships. Entertainment Like a good television show or book, the game must maintain a player’s interest. The introduction of conflict, the revelation of the setting or back-story, the acquisition of new assets, the display of new art, and the increase in difficulty must all be deliberately spaced to keep the player interested and looking forward to the next level. One boring level can be the kiss of death to a game, especially if it’s one of the first few levels. Game reviewers and most players only give a game that much time before they praise or trash it. Good level designers have learned to be objective about their own creations and when asking themselves, "Is this fun?" The hard part for many designers is that what they find fun may not be what the target market finds fun. As a level designer you need to understand the core gameplay, which is part of the vision expressed by the producers and lead designers. You need to try to understand and become that target market. Something that helps designers tremendously is to play competitors’ games. Often producers and lead designers will name successful games that they are trying to emulate. Play and study those titles. Make sure your levels entertain, thrill and excite you as well or better than the competition’s levels. Frustration can also kill a game. Players stop being entertained when they encounter technical problems like slowdowns or graphics glitches. The level designer can avoid a lot of these bugs if they pay attention to technical limitations and to the instructions of the artists on how to place the art. Designers can, of course, create their very own frustrating bugs, like broken AI scripts or door triggers that never trigger, or missions that don’t always end when they are supposed to. Even worse, designers can create what are commonly called "show stoppers". Show stoppers are unbeatable missions or unsolvable challenges or unavoidable traps that frustrate players. A good level designer can spot these problems and resolve them with careful and rigorous play testing before consumers get their hands on it. Uniqueness Follow the link at the end to read this portion of the article The Roots Of Computer Game Design Follow the link at the end to read this portion of the article Board, Paper & Dice Games Games predate civilization. Some of our oldest games still survive to this day, like mangala (or stones), dice, checkers, tic-tac-toe and chess. What gives them their lasting power? What can we gain from them as designers of complex computer games? Simplicity and elegance. These games keep the gameplay and the rules simple. Almost anyone can grasp them and quickly perceive the strategies and skills necessary to achieve victory. Elegance comes from years of refining the rules and components to maximize and balance the gameplay, and provides lasting entertainment value. Simplicity and elegance should be your goal in level design. So many designers (I being one of them), have fallen into the trap of creating complex games and levels that make it difficult for players to grasp the rules, objectives, strategies and indeed the fun. Designers often fail to play test their level enough to uncover any unbalancing factors and make improvements. So keep it simple, and submit your level to a lot of play testing so you can polish it. There’s a lot more that can be learned from non-computer games, such as the value of symbolism, statistics, and role-playing, but this goes beyond the scope of level design and should be left for a future article on computer game design. Toys – Train Sets, GI Joe and Barbie Follow the link at the end to read this portion of the article Storytelling Follow the link at the end to read this portion of the article Thesis, Antithesis and Synthesis Follow the link at the end to read this portion of the article Understanding and Developing the Thesis in Level Design Follow the link at the end to read this portion of the article Introducing and Refining the Antithesis in Your Level Follow the link at the end to read this portion of the article Synthesis – Making Your Levels End in a Satisfying Tone Follow the link at the end to read this portion of the article Worthwhile Content Stories maintain your interest by presenting worthwhile content. People don’t buy a book or see a movie just to hear characters talk about the weather, unless the weather itself is the villain (as in disaster movies like Twister). All the details that a well-written story contains are those that render the setting, develop the characters or move the plot. While books can get away with including an awful lot of detail, films cannot. Films are aimed at short-attention span people who want to experience the whole story in 90 minutes or less. Films try to focus on the most important details and these usually are the ones involving character interaction. The same can be said with level design, except that you have an even shorter amount of time to tell your story. As a result, you must focus even harder on character interaction details, especially those that involve the player. Everything the player sees or does must further the story. All of the players’ accomplishments should move them toward the completion of the story or pull them further into the conflict with the villain. As the game is played, players should discover more about themselves and their opponents. This can be achieved when players develop new talents, find new weapons or upgrades, gain insight into strategy, or encounter new enemy tactics and new enemy types. All of these suggestions may sound obvious to you, but you would be surprised how often designers make the mistake of spending a lot if time working on setting details that are rarely, if ever, seen by the players. Spending a lot of time working on non-interactive details can be a waste of time and resources, although it’s important to put some effort into it because the player will pay some attention to it. For example, it’s ludicrous to spend a day creating the details of a farm that a player will pass in three seconds on his way to a tank battle. It’s better to just take a minute to sprinkle a few objects that give the player the feel of a farm, like a farmhouse, barn, silo and a few cows. Even if you have all the time in the world to create all sorts of non-interactive details, it’s still not a good idea. Players get distracted and suffer sensory overload from too many details. They also can get frustrated as they try in vain to interact with non-interactive details. Duke Nukem: "Come get some" It would be even better to make all the details of the setting interactive somehow. Duke Nukem did an excellent job of this. Even the toilets had some purpose, if only to give a little humor. The bar had a working pool table and the arcade had a Duke Nukem machine that prompted you to say, "Hmm, I don’t have time to play with myself." The extra effort it took was well worth it. The interactive setting created a great allure and set this game apart from all the other Doom clones. Verisimilitude – When to Stay within the Realm of Probability Verisimilitude is the technical term used by writers to describe the readers’ acceptance of the facts and events within the story. When the story steps out of the realm of probability, the readers get frustrated. Works of fiction must suspend the readers’ disbelief if they want to keep the reader. Readers are only willing to accept so much. How much varies with the reader, which often separates the readers of classical fiction and literature from those of fantasy and science fiction. Computer games have it easy because their target market is much more likely to be readers of science fiction and fantasy. Though the so-called "break through" titles which establish new genres of games often go beyond the sci-fi and fantasy market. Titles like Sim City, Tetris, Civilization, Deer Hunter, and sports games of all types don’t make any grand leaps of logic or fantasy, and they entice players who’ve never shot a single alien. Even so, sci-fi and fantasy oriented games are the vast majority of games made today. Sim City So assuming you are working on a sci-fi or fantasy game, you do have certain latitude (or indeed, a certain obligation) to extend the realm of possibility for the players. But it’s important to know when and where and how far to stretch reality. Players like the realm of possibility extended more for themselves than for other characters. While this seems one-sided, it’s what players want. Players feel cheated if the AI enemy kicks their ass by doing something amazing and beyond their capabilities. They prefer to have their butt kicked by an opponent who’s limited to what they can do. Then they can at least be impressed and comprehend that it is just a skill issue. On the other hand, players enjoy pulling off amazing feats beyond the scope of the AI capabilities and romping the AI for a spell. So give the players what they want. Let them enjoy themselves with a little god-like power. But be aware that giving that ability to players all the time can lead to a dull, unchallenging game. The trick is to balance it so that players don’t always have that edge, either by limiting the use of the ability or by countering it with enemy powers. In an ideal level, the players will face overwhelming odds and overcome them by leaping beyond the apparent realm of possibility. That way they can feel like they have done the impossible and that they’re real heroes. Armed with this understanding of level design theories, you can begin creating your own levels with greater confidence and a clearer insight into what will make them successful. Read the full article here: Read Part 2 of this series next here: Follow Tim Twitter: Follow Next Level Design Join the Forum: Follow us on Twitter: Discuss on Discord:
  22. The following is a portion of an article called 'The Fundamentals of Game Design', by Raph Koster. Raph is a veteran game designer and creative executive who has worked at EA, Sony, and Disney as well as run his own company. The lead designer and director of massive titles such as Ultima Online and Star Wars Galaxies, he’s also contributed writing, art, music, and programming to many other titles. He is the author of the classic book A Theory of Fun for Game Design. In 2012, he was named an Online Game Legend at the Game Developers Conference Online. Follow the link at the end to read the complete original article. Often people have trouble when conceptualizing a game. The idea, after all, is often the easy part. It’s actually making it, and figuring out where to start, that is the hard part. The Components of a Game The first thing to understand is that games are made out of games. A large game is actually composed of minigames. Even a small game is built out of very very simple small games. The smallest games are ones that are so simple and stupid, you can’t lose. You can think of this as “game atoms,” if you like. For example, in the classic puzzle game Tetris, the basic game is beating your high score. To beat that game, you have to master the game of forming lines. There’s actually multiple variants there, because you have to learn the games of placing all the different sorts of blocks. And finally, the simplest game is rotating a block, which is just a button and hard to screw up. So games are built out of games. This brings us to key piece of advice #1: Advice #1: Design One Game at a Time Even if you are making a complex game, built out of many “game atoms,” each atom is a game in its own right, and has to feel fun and satisfying. Even the stupid ones with no challenge have to feel good. Imagine how poor a game Tetris would be if the stupidly trivial game of “press a button and watch the block spin” wasn’t satisfying. Many games are ruined at this very fundamental level by poor design. For example, a bad designer might have decided that a random chance of the block not rotating would make sense. After all, we use random chance in gambling, board games, and roleplaying games, right? But it would make Tetris unplayable. OK, so you’re going to design one of the game atoms. Luckily, every game atom has the same characteristics: A player does something. The opponent (which might be the computer) calculates a response The player gets feedback. The player learns from this feedback, and gets to do something again. You can think of these steps in very abstract terms: Input Model Feedback Mastery Really, that is it. Let’s apply it to our Tetris example again. At the trivial “rotate a block” level, we have A player hits a button. The computer calculates that this means rotate the L counter-clockwise. The player is given the feedback of the block in its new position. The player figures out “I bet I can do this with other sorts of blocks too. And there’s probably a rotate clockwise button somewhere. Rotating is my goal!” Advice #2: Make Sure The Controls Match Up Well To What The Player Is Attempting To Do At a more advanced level we have A player can rotate left, right, drop a block, glance at the next block, etc. Lots of choices. The computer is going to take its turn and move the block further down regardless, or spawn a new block of a random shape if there isn’t one. The block moves down. Maybe it completes a line, maybe it doesn’t. The player says “aha! Completing lines is my goal, and different shapes help or hinder that!” Notice that if any of these four steps is poorly chosen, the whole game sucks. A player moves the mouse. The computer figures this means rotate a block. The player is not shown the block, but instead a stock quote. The player is baffled and quits. Advice #3: Make Sure The Player Can Actually Learn From The Feedback You Give Them Advice #4: try to stop thinking about what your game looks like, for a moment, and think about what it is actually modeling. Advice #5: check this list for every goal, every objective, every button press, every action a user can take, every decision they make. Advice #6: watch others play your game – you’ll quickly see where you didn’t provide enough feedback, or where they can’t figure out the underlying model. Fundamentally, never forget that if you want to design, you have to just go do it. The only way to get better at it is to keep doing it, because gamemaking is in itself a great and varied game to play. Read more about 3-5 on Raph's Website: Follow Raph Website: Twitter: Follow Next Level Design Join the Forum: Follow us on Twitter: Discuss on Discord:
  23. The Nature of Order in Game Narrative by Jesse Schell This 2018 GDC talk from Jesse Schell is inspired by the work of Christopher Alexander. He suggests that the wisest way to look at space is with our hearts. Follow Jesse Twitter: Youtube: Website: Follow Next Level Design Join the Forum: Follow us on Twitter: Discuss on Discord:
  24. I want to talk about some problems with player versus player games. In abstract, these problems are difficult to describe, so I want to talk about them through two matches of Halo multiplayer. These are matches where I played with a group of friends against unknown opponents through Halo’s matchmaking system. The specifics of these matches bring the problems of PvP into focus. Derelict Our first match was on “Derelict,” a two-tier octagonal map with a central tower and walkways connecting to an outer ring. Together, the tower and walkways occlude the lower floor into quadrants. The only routes up are through teleports, which deposit the player 45 degrees offset from their entrance, relative to the center. The teleport entrances and exits are in the open, with the best cover being the teleport itself. Green lines indicate teleport paths In the Team Slayer mode where kills equal points, all of the powerups spawn on the top floor. The overshield in the top center is the most important, and also the easiest to contest since the walls around it allow players on the bottom floor to bank grenades. Players who rush the teleports to the top floor have long sightlines down the walkways and past the overshield to the far side. In a coordinated attack, anyone by the overshield is doomed. View from the top floor Most of the player respawn points are on the bottom floor, and Halo’s respawn system favors being near allies rather than away from enemies. This system means that once a team is all on the top floor, dead allies will respawn on the top floor. However, if anyone on a team is on the bottom floor, dead allies are likely to spawn there. With the combination of the item placement and the respawn mechanics, the dominant strategy of “Derelict” is to control the top floor and kill the enemy players as they rush the teleports. Even in Team Slayer, “Derelict” plays like King of the Hill. View View from the bottom floor A final note before I get into the match’s specifics: in Halo, players spawn with an ineffective assault rifle equipped and have to switch to their secondary weapon, the pistol, to have a chance in a fight. This weapon swap means more than a second of vulnerability where the newly-spawned player can’t pressure an attacker to back off. Altogether, these systems turn Team Slayer on “Derelict” into a grinding slog. Match 1 In this specific match on “Derelict,” two of our four opponents dropped from the game within the first minute. By that time, my friends and I had started to control the top floor and the powerups. With only two opponents remaining, this imbalance guaranteed our map control, but this also slowed my team’s score per minute and drew out our inevitable win. After this match, we looked up our opponents’ stats and saw that they were new players with only a few matches of experience. My team’s attempt to efficiently end the match (and get on to something better) may have spoiled Halo 1 to these players. But because there are no easy systems for communicating across teams in Halo, the entire experience was an anonymous cruelty. When players are outnumbered in these situations, some choose to give up the match or “deny” it by preventing the other team from having fun. These players may set the controller down and walk away until the game ends as a passive rejection of the match. Or, in a more active rejection, they may kill their allies, jump off the map, or frag themselves on spawn. This behavior extends the game time, since it slows the rate at which the stronger team can score points, but it is a way for the losing team to control the pace of the game and reject the systems that put them there. Some of the behavior we commonly label toxic play or poor sportsmanship may stem from bad systems design. Even on Halo’s best maps, 4v2 matches are common. In The Master Chief Collection, the queue for Team Slayer lets players vote on a random map from each game in the Halo trilogy, and the original Halo is divisive. Unlike Halo 2 and 3, Halo: CE’s levels are difficult to learn, which adds to the gap between experienced and new players. There are no maps like “Derelict” in Halo’s sequels. As soon as this skill and knowledge difference between the teams becomes apparent, the players on the losing team are stuck in a bad situation. If they leave too many games, they will face an automatic deserter penalty and may also face Xbox Live’s player reporting systems for desertion or bad sportsmanship. As a player, it isn’t clear what many of these systems do. As a designer, it seems to me that the blame should fall on the systems that insisted a 4v2 match play to its end. Even before the match became a 4v2, the blame should fall on the matchmaking instead of the less experienced players. But there’s only so much that matchmaking algorithms can do on a small player population without dividing player parties. In designing these systems, we should ask ourselves who these systems are supposed to serve. Longest After this lopsided victory, our next match went to “Longest”, a small map with two parallel hallways and elevated rooms to either side. There are no rocket launchers or sniper rifles on “Longest”, but the standard grenades and pistols are more effective in the narrow gameplay space. The green lines indicate jump routes between platforms on the second floor At either end of the hallways are a red and blue base, a health pack, and an enclosed ramp up to the second floor. These bases are where the players spawn. Aside from walking the long halls, the only other route is jumping across platforms on the second floor. Up here in the middle there is a powerup on either side, swapping between overshield and active camo after each use. This jump route is outside the lethal range of grenades on the floor below, but Halo’s floaty jump makes these players exposed to pistol fire. A view from blue base down the hall toward red. The overshield is in the top center platform As a result of this structure, the map plays like a teeter-totter of balance swaps. At the start, both teams fight down the long hallways and push toward the far side. The team that wins the fight in the halls can continue the push into the enemy base, and if they kill all of their opponents there, the spawns will swap so that red team now spawns in blue base and blue now spawns in red. This spawn swap resets the fight, giving both teams a chance at a new push. This spawn-swapping property, which emerges as an interaction of the level design and the respawn system, makes “Longest” more forgiving than a map like “Derelict”. Even after a bad start, the losing team on “Longest” has a chance to recover. The limited items also reduce how far ahead the winning team can be. The grenades and health items on the map are only useful to recover to the starting amount. Match 2 Even though “Longest” is a more balanced map, our second match started much like our match on “Derelict”. Within the first minute, two of our opponents left. However, instead of another frustrating victory, I persuaded my teammates to stop shooting and to only use grenades and melee. The grenades are still effective, but players are limited to four, and must then find more grenades in the dangerous midfield, or must charge the enemies in melee combat. There is also friendly-fire, so our over-use of grenades turned the map into a hilarious chaos. Red base, and an exploding grenade, for scale Despite our numbers advantage, by applying our own rule modifier, the opposing team was in the lead until the last few kills at which point we resumed standard play. Our opponents also appeared to join in on our grenade-happy shenanigans, with one of them scoring 10 grenade kills in the match. Most importantly, the opposing players remained active despite the odds, rather than turning to fun-denying strategies. However, across the silent gulf of Xbox Live, I don’t know what our opponents thought, or if they recognized that we had changed the rules of the game to keep it fun. On our side, a few of my teammates saw the rule adaptation as a way to humiliate instead of merely win; perhaps this is how our opponents felt. Without means to communicate across teams, it is unclear whether our rule modification improved the situation. Problems Those with power in a match define its pace. Power here may mean having a numbers advantage, not just being the more skilled group of players. The responsibility falls on the dominant group to adapt their play for everyone’s enjoyment. Reinforcing feedback loops or “snowballing” in level design, where the team that takes the lead can easily maintain it. Rigid PvP systems that don’t match the players’ goals. Rigid multiplayer that lacks communication tools for players to negotiate their goals and restructure the match. Real World PvP With each of these problems, we should compare the situation to real world player versus player games. That is, if we played this matchmade game on the greens of a public park, would we play the game to its end without modification? If not, then this is a case where the rigidity of a digital game’s multiplayer systems does not serve the players’ needs. With these specific examples from Halo, imagine instead if the 8 of us were playing a game of soccer and two players had to leave. In the real world, the game is a servant to its players and will flex to accommodate their needs. The moment two players leave, the remaining 6 can decide if they want to continue with the game, and how they want to restructure the team if so. Or, if the match was more serious, the players can negotiate a rematch for the future. In digital games, the rules are too often inflexible. There aren’t systems in Halo to negotiate a rule change part way through a match. This negotiation could include a mode change, or a team restructure. In both of the 4v2 matches above, Halo could have prompted a vote to make the game free for all, to scramble the teams, to end the match early, or to seek players to join in progress. Existing Solutions? Match join-in-progress. Depending on how quick the enemy team’s numbers can be refilled, and how much of a lead the winning team can take on the map, this solution may come too late to fix the problem. This approach works best where the server persists across multiple matches. Player-controlled voting. In Counter-Strike’s casual servers, players can vote on a map change, on a team scramble, and on player kicking at any point. Most MOBAs let players vote to surrender. However, players can abuse these systems, whether or not the vote-calls are anonymous. Other Solutions? Discourage competitive motivations through the game mode design? Make the match about the kind of play that emerges in player versus player games instead of about winning. Treat PvP as a kind of cooperative play. (Regardless of how the game communicates this, competition is still a motivation players will bring to the game. There may be only so far we can push this solution.) Matchmake by player intent, rather than skill? If a player signals that they don’t care about winning, prioritize matches with others in that category of play-motivation. (Depending on implementation, some players will find ways to abuse this.) Add systems for nonverbal communication between teams? The first step of a negotiation between teams should be to identify and agree upon the problem. Acting upon that problem, such as a calling a vote, should follow from negotiation. Let players leave casual matches without punishment. If too many games are ruined as a result of players leaving, then there are problems in other systems that we need to fix. As a closing note, there is an experiment I want to run. In a game that is otherwise traditional PvP, I want to create an environment with no explicit goals or teams but provide tools and toys for various forms of play. This environment would have bases and flags, hills to be king over, as well as toys like exploding barrels and jump pads. This environment would allow players to set their character color mid-match to form teams. This environment would share voice chat across the entire group, allow the easy formation and dissolution of “team” communication channels, or use proximity-based communication. Better still, this environment would offer tools for players to communicate without relying on the disclosure of voice chat. My hypothesis around this experiment is that we would see healthier player interaction, and we would see player needs rise in priority above competition. Ideally, this experiment would reduce the toxicity that drives players away from PvP gaming. However, it may also be that denying players’ competitive motivations through these systems reduces player engagement and retention. This is an area I hope to investigate further in the future. Thanks for reading! Source: *Note: This article is posted in full on Next Level Design with permission from the author Follow Andrew Website: Twitter: Follow Next Level Design Join the Forum: Follow us on Twitter: Discuss on Discord: .galleria, .galleria-container { height:480px !important }
  25. Jenova a.k.a. Xinghan Chen or 陈星汉 is the visionary designer of the award-winning games Cloud, flOw, Flower, and most recently Journey. He's also the founder of thatgamecompany. *Note: The following is only a portion of the full article. We highly recommend you follow the link at the end to read the full piece. Video games as a media can be reviewed as two essential components: Game Content - The soul of a video game; a specific experience the game is designed to convey Game System - The body of a video game; an interactive software that communicates Game Content to the players through visuals, audio and interactions When treated as content, the definition of Flow is too broad. However, if applied properly, it can literally happen in every game. In order to make a game special, it requires content that is more sophisticated than Flow experiences. But when treated as a system Flow explains why people prefer certain games more than other games and how they become addicted towards these games. If a game meets all the core elements of Flow, any content could become rewarding, any premise might become engaging. [Sweetser & Wyeth 2005] From the simplicity of Tetris to the complexity of Civilization IV, video games have already proven to the world that anything can be fun if players can access Flow. Expand the Flow Zone Assume the content is attractive to the audience. Designing a video game is very much about how to keep the player in the Flow and eventually be able to finish the game. Therefore, the game system needs to maintain different players' experiences inside the Flow Zone. In Figure 2, the red curve represents an actual experience a player gained through playing one segment of a video game. The player may feel a certain part of the game experience is a little bit harder or easier than their expectation. But he can still tolerate and maintain his Flow experience inside the safe zone. If the actual experience gets too far away from the Flow zone, the negative psychic entropy like anxiety and boredom will break player’s Flow experience (see Figure 3 below). Unfortunately, like fingerprints, different people have different skills and Flow Zones. A well-designed game might keep normal players in Flow, but will not be as effective for hardcore or novice players (see Figure 4 below). For example, a simple action to an FPS player such as shooting, might be an extremely difficult task for a casual gamer just starting a game. Even though the rest of the game might be something that casual gamers enjoy a lot, the harsh beginning just turns them off. In order to design a game for broader audiences, the in-game experience can’t be linear and static. Instead, it needs to offer a wide coverage of potential experiences to fit in different players’ Flow Zones. To expand a game's Flow Zone coverage, the design needs to offer a wide variety of gameplay experiences. From extremely simple tasks to complex problem solving, different players should always be able to find the right amount of challenges to engage during the Flow experience. These options of different gameplay experiences need to be obvious, so that when players first start the game they can easily identify the corresponding gameplay experience and delve into it. Passive Flow Adjustment The biggest dilemma on Flow adjustment is whether or not to create a system to adjust the gameplay for the player. Under this kind of passive system, players can enjoy the Flow experience fed by the system. Much research centers around designing a system that adjusts the difficulty based on the player's performance. This kind of system-oriented DDA works under an iterative adjusting loop. The loop consists of four fundamental elements: Player - Create raw data inside the game through playing Monitor System - Choose critical data reflecting player’s Flow state and pass it over Analysis System. Analysis System - Analyze player's Flow state and notify the Game System about what needs to be changed Game System - Apply changes to the gameplay based on the request from Analysis System Theoretically, this system should be able to maintain player's Flow by constantly reacting to the feedback collected from him. [Bailey & Katchabaw 2005] However, there are still several key unsolved problems , which makes this type of passive flow adjustment hard to implement. No direct data - Video games do not read what player thinks yet. Up until today, the most common connections between players and video games are still going through game controllers. With limited inputs, the possibility to sense player's Flow state directly is very low. Although there are biofeedback devices on the market, people still lack the knowledge for imaging data into Flow and emotions. Most of the measurements are still based on assumptions and incomplete statistics. Performance does not mirror Flow - Video game designers and researchers have figured out ways to estimate player's performance through sampling limited data like “Total Kill”, “Accuracy” and “Headshot”. However, performance is objective while Flow is subjective. When a player is in the Flow of just jumping around in Super Mario Bro but not finishing any level, the DDA system will have trouble to sense that. Analysis based on assumptions - Assumptions never work for mass audience. When a player enjoys performing a suicidal stunt in Grand Theft Auto, it would be ridiculous for a DDA system to assume that the player's skill is too poor because of the death count. Changes are based on rigid design – The way a system adjusts its difficulty is pre-determined by the designer. Different designers use their own preferences when deciding how many changes should be applied; however, the individual preferences of a designer will never represent the preferences of a mass audience. [Costikyan 2004] In addition to the portions included here, Jenova proposed methods of implementing 'Active Flow Adjustment', discusses the impacts and takeaways of playtesting, and shares his thoughts on 'Embedding Choices into Gameplay' as a method of determining a players flow state. Read the full article here: Follow Jenova Website: Twitter: Follow Next Level Design Join the Forum: Follow us on Twitter: Discuss on Discord: