# Scenario Based Design Concepts
Whereas Semantic based design tries to understand the player from a logical and term-driven approach, Scenario based design tries to understand the player from a moment to moment perspective.
If you've ever worked as a designer you have inevitably been pulled between two desires. On the one hand you have your own inner voice, or a coworkers, putting forth the idea that, "we need to define the goal for this level", or "this move doesn't have a strong purpose", or even more semantic, "there is no AffordanceThe properties of an in-game object or mechanic that imply or communicate how the player should best use it. An axe implies, or 'affords' a downward motion to the attack, while a small dagger 'affords' a stabbing motion. on this!"
And you've found yourself thinking, "That's all well and good, but how is the player even going to know when and how to use this?! Also, what can we do with the pieces we ACTUALLY have right now!" Congrats, you're dealing with the problem of Semantic vs Scenario based design. Both of these approaches are correct, in a technical sense, but too much of one will cause you to lose sight of the other, and that is the only objectively bad approach.
Common questions that a scenario based approach can help to answer:
- Why is the player doing this, when I wanted them to do that?
- Which of these concepts best fits this monster?
- How do we guide the player?
- What's missing from this level?
- When do we introduce this monster?
The articles in this section involve a more "bottom up" approach to designing a game. This often involves looking at what you have and asking what can be built with it, or pondering how the player is actually processing and understanding the scene you've built
Your job as a designer is to know the problems that your game is facing, and scenario based design concepts are one of the ways in which you can spot and discuss those problems.
However, they are not silver bullets. Players can be inscrutable, as any designer that has been to a playtest will tell you, but do not let this discourage you. We must try, and these tools are my best attempts.
# Decoy Choices
Often you will have debates with other designers about holding the player's hand, or letting them make their own choices. This is one way of doing both.
# Hierarchy of Experience
You can think of this as the hierarchy of player needs. The more important your feature or mechanic, the higher it must move up this hierarchy, or your game will be unsatisfying.
# Hierarchy of Reasoning
I learned a lot from working with concept artists, but this is probably the most important thing I ever learned. A breakdown of how someone understand what they are looking at.
# The Moment of Evaluation
My personal methodology on understanding players and how they evaluate your systems. This is a critical component in one of my processes, the System Designer's Checklist.