Design Dive 43 - Goal Driven Design


Kelly Tran - Co-founder and Game Designer at Evolved Play. Previously, Game Design Professor researching games and players at High Point University. PhD in learning and tech. Solo Twitch - Group Twitch - Website

Ian Schreiber - Senior Game Designer at Oxide Games. Previously Assistant Professor Rochester Institute of Technology.

Dan Felder - Lead Game Designer Riot Games. Previously Abrakam, Blizzard, EA.

Zorbaz Englander - Game Designer. Previously Mohawk Games.


  • Intuitive Designer - Imaging something and imagining if it feels fun. You usually play one genre a lot, become an export and have a strong feeling of what’s fun in that genre. It makes it harder to design for a different genre if you are an intuitive designer. How do you articulate what good even looks like? Lots of design discussions turn out to be because designers have different goals in mind. 

  • Example should you add stealth mechanics - A FPS game, 2 designers, one want to add a stealth system, drag bodies, shadows you can sneak in. Another designer argues against it, it takes a lot of resources, slit the attention, and can't make 2 types of games as well. Which one is right? 

    • Best or worst outcome? - One thinks of the best scenarios, the other thinks of the worst outcome. 

    • More questions about the scenario - What’s the team like? Have they lots of FPS experience, do they know anything about stealth? Are you outside of your expertise? Is IP involved, are you making Doom 6? Stealth doesn’t fit in that IP. Stealth in the Hulk…?

    • Throw-in mechanic - Stealth, one of the common throw-in mechanics in games, that turned out not to work well. 

    • Writer, write a chapter, short story about the fantasy of the game, to show how the game would feel.

    • Batman: Arkham Asylum - A stealth game when you are empowered instead of vulnerable. 

    • Wolfenstein 3D had stealth - the original 2D game had stealth and dragged corpses, but it got too slow in 3D. They had it implemented so it wasn't a scope creep. They removed it to make the game more focused.

    • Many subpar systems add up - Deus Ex Quete, if we got compared to single purpose games, it was bad, but when people understood that they could do anything. Design goal of atoumany, that the player could choose, so they could have a bunch of subpar systems, but they add up together to something greater. So many ways to handle the problems. You figure out the best way in. 

  • Design pillars - Does this support the core mechanics? Support the pillars? If it works in early focus tests, and prototypes. 

  • Design skeleton - Content design for Characters, writes a list of roles in excel 100+ of different goles for each slot. Instead of going with the different IPs of different characters. Ex: Support for crafting 3, tier 2.  A very specific shape of your pegboard makes design very easy. MTG design skeleton

    • Most original designs come up when solving very specific goals. 

  • Finding your goals - It’s not like you know your design goals in the beginning. Make a prototype in a few days, see that some things don't work. Now you can see the sticking points that you need to look out for for the rest of the development. 

    • Example: Hostile interface, trick the player into pressing windows hotkeys. Hold Alt, press F4 to open doors. Might close the program by mistake. When a player loses they must blame themselves instead of blaming the UI, because they should have seen it coming. 

  • Old world events - Examples, Parent cruelty, events where the child inherits it and becomes cruel, or rejects it and becomes compassionate. Write a dossen event for this mechanic. Law, slavery, martial law, then you would get a event connected to that. Hard to do right, it has to grow very organic. 

  • Coherent whole - Examples, the designer lists equipment systems, but what is the goal? You might end up with just a collection of things you stitched together, instead of making a coherent whole. Easy to tunnel vision on a specific sub system and lose sight of the whole game. You build this system that could be its own standalone game, traveling system, combat system, etc. Hard to keep it all in your head. 

  • Peripheral systems - You make diagrams, here’s a system connected to another system. And then have a different document with the other systems. If a system is peripheral, not connected to anything else, maybe it’s possible to streamline the game without losing anything. If there’s a tight loop, you also need to keep your attention on it. 

  • Different progression from different modes - MMO where you get similar progression material from different types of modes. Can we differentiate it? You get material for equipment from this mode, and something else from this other mode. 

  • Pillars affect the entire game, goals can be smaller parts. Overarching goals for the team. Discovery is the path to power. High Level creative statements that shape decisions later down. 

  • Changing goals? - Question about what if the goals fissel away along development? Playtests, do you need to change the goals or refine them? The cost of changing goals is how long you are in the design process and how large goals you are changing. Lots of rapid prototyping and playtesting early, at a fundamental level. After that you can go and fill in a lot of details with more confidence. 

  • Have you noticed any drawbacks with this approach? - There’s no way to evaluate your design if you don’t have goals. But you might need to change the goals. Ape out started out as a stealth game, but players played it more aggressively, so they changed the goals.

    • It can be done poorly. “Make it more fun”, that goal doesn’t add anything, you might end up doing things that take away from the “fun” of the game. 

  • Max depth with minimum required for first time players - Design goals with conflicting goals. Want as much as possible provided that fulfill a minimum. Ex max depth provided that a new player can understand it quickly. Can compromise on this goal, but as long as that’s ok, we can optimize this other parameter. 

  • “Another point: Intuition is valuable to guide your exploration and discovery, but not necessarily to justify your decisions”

  • Notes from a Design Dive Talk about Design Pillars.

Notes by Christoffer Lundberg, solo game developer, Twitter - Devlog