Search the Community

Showing results for tags 'questions'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

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

Categories

  • Articles
  • NLD Originals
  • News
  • Projects

Blogs

  • NLD Dev Blog

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


About Me

Found 2 results

  1. 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: http://www.chaoticstupid.com/trinity-9-why-i-call-it-trinity/ Follow Mike Website: www.ongamedesign.net/ Website: http://www.chaoticstupid.com/ Twitter: twitter.com/MikeDodgerStout Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0Dp
  2. Intro This is the first of a series of blog posts which will try to convey my overall design methodology, which I’ve nicknamed Trinity for now. It’s a big task, and I’m not sure how many posts it will take to get there – we’ll have to see as we go. There are two ways I could write this: I could start big and zoom in, or start small and zoom out. If I start big, I start in the realm of abstract principles and, over the course of the series, drill down to show how those principles are applied in practice. The other way (which is the way I’m going to write it) is to start with specifics and, by the time the series is finished, show how all the specifics are just applications of a few generic principles. I like the second way best because I don’t like having arguments, and generic principles are argument magnets. Arguments are hard to avoid without a huge amount of preamble – and so I will start with the preamble and move on over time to the “amble”. The kinds of games I’m discussing There is one overarching principle, though, that I have to state at the beginning. These posts will all grow out of the idea that “a game is fundamentally a conversation between a game’s designer and the game’s players.” I state this not because I believe that is the One True Definition™ of games, or because I think that is the only way a game can be made – but because I am limiting the scope of this series to games which are that way. I’m sure someone can come along and make a great game that doesn’t meet these criteria – and that’s cool. What I’m going to talk about in these articles might even apply to that game, but I have no idea if it will. All the games I’ve ever made or played fit this definition, as far as I’m concerned, so just know all that going into this and take everything with a grain of salt. I hope to demonstrate how it is true at some point, but until then just keep this in your mind as you read the rest of this series and try to see how it applies: A game is fundamentally a conversation between designers and players. Principle #1: Games ask questions, Players answer them Trinity all begins with what I’m calling Principle #1 (not because it’s most important or anything, but because I happened to write it first). As a game designer, your job (in a very practical sense) is asking the players questions. The players’ job is to answer those questions using the tools you give them. I think this is what legendary Game Designer Sid Meier meant when he said that games were a series of interesting choices, only I want you to see it from a slightly different angle: Instead of focusing on the choices, I want to focus on the questions the game asks that cause players to make the choices. It may seem like a small difference, but focusing on choices has a number of knock-on effects. Sid Meier's Civilization IV Focusing on Choices Before I talk about questions, let me give you a couple examples of what I mean by “focusing on choices.” Hopefully this will give you an idea of the knock-on effects I’m trying to avoid by phrasing Principle #1 (designers ask questions and give players tools to answer them) this way. Normally when I see designers approach mechanic design by designing a series of interesting choices, I see something like this: “Do you want to go left, or go right?” The designer here wants players to make choices about their path through a level – ideally choices that result in varied gameplay. Imagine a linear level that forks off two ways, and you have to choose one. Or you’re given dialogue choices between good and evil, etc. There’s nothing really wrong with doing it this way, but I find the results end up being expensive to make, and the player only sees half of the game this way. Even worse, I’ll sometimes see things like this: “Do you want to do it the right way or the wrong way?” Imagine an enemy that can be damaged by two different attacks. Attack A does more damage to the enemy than Attack B. Sure, the player can “choose” between them, but only one is correct – so it’s not really a choice, it’s just rope to hang the player with. There are many other pitfalls I see all the time because a designer focuses more on the choice than on the reason the choice is there in the first place. Focusing on Questions & Answers (AKA Game Mechanics) Think of it this way: The game presents a problem, the player uses a countermeasure. Our job is to design both the problem (question) and the countermeasure (answer) that solves it. You can start with either, but eventually you’ll need to design both. Before I close this first post, I want to walk you through what it’s like to design this way. It’ll become more obvious as the series goes on, but this should give you enough context to make it through to the next post. Let’s take the same problem of the multi-vulnerable enemy I mentioned above. We want the players to have choices in dealing with this enemy, so the enemy needs to ask a question that prompts each answer. The easiest, most used form of this is the enemy with vulnerability states (e.g. When the enemy turns red, Attack A is most effective. When the enemy turns blue, Attack B is most effective). This is very common, but there are other answers too. For example, the enemy could ask a single question, but the best attack to use against it at any given time is based on the context the enemy exists in. Let’s say you have a 1 HP 1 Damage enemy called “Bob” which stands still and shoots at the player. The player has three attacks: One shoots bullets straight ahead (Magic Missile), one does damage over time to everything in a short cone (Cold Spray), and one lobs a projectile into the air that explodes on landing (Fireball). The attacks may have other differences, but for now let’s just consider the range. If the player encounters Bob on a flat plane, any of the three attacks are a good answer. If Bob is behind cover, though, Magic Missile and Cold Spray are useless unless you run around and get a new angle. Fireball, though, could arc over the cover so it’s the best option. If Bob is up on a ledge, the player could aim and shoot with Magic Missile, or try to jump and lob a fireball. If there are two Bobs close together, Cold Spray and Fireball will hit both of them, but Magic Missile will only hit one. The enemy is still asking one question “what’s the best way to attack me” but now we’ve added a meta-question: “Given the terrain, what’s the best way to attack me?” You keep stacking questions and meta-questions on top of each other until your game feels like the player has enough choices in every circumstance. A few things to notice: The goal isn’t to create individual choices, but rather to create a “choice field” (or “design space,” as I’ve heard it called). I’m going to go into these more later, just keep them in mind. The questions and answers can all be very simple. When layered together with other questions (like those asked by a level design’s gaps, ledges, and cover), new answers begin to emerge based on context. I started this example with the attacks and questions already decided to make Principle #1 more clear, but usually you have to decide on these things yourself. In later posts I’ll try to illustrate how I come to decisions like that (it’s complicated) but just remember that the foundation of it all will rest on Principle #1 (designers ask questions and give players tools to answer them). (Link to Part 2) *Note: This article is published with permission from the author, and in accordance with Creative Commons guidelines. Source: http://www.chaoticstupid.com/trinity-a-game-design-methodology-part-1/ Follow Mike Website: www.ongamedesign.net/ Website: http://www.chaoticstupid.com/ Twitter: twitter.com/MikeDodgerStout Follow Next Level Design Join the Forum: http://www.nextleveldesign.org/index.php?/register/ Follow us on Twitter: https://twitter.com/NextLevelDesig2 Discuss on Discord: https://t.co/hkxwVml0D