Point of Reference
I've been incredibly fortunate to have worked with some first-class designers and producers over the past 15 or so years (people from Sony, Nintendo, Blizzard, Riot, and more). And thankfully, all of these people have been open and willing to share a wealth of knowledge. It is with this absorbed knowledge that I've been able to wrangle, organize, and formalize a clear way of thinking as I approach any new game design (or work to improve a current game design).
Over the past few years, I've been trying to crystallize my approach into something tangible--something that can be articulated both verbally and visually. Recently, I have achieved this goal, and would love to share my methods with other designers.
(NOTE: I realize that every designer thinks differently, and has his own way of approaching game design. I am in no way trying to claim that my method is better than anyone else's. But, this method might help some game designers who struggle with organizing an approach or pathway to a complete, bulletproof game design.)
After spending a lot of time with many game designs (playing the games and/or analyzing the games), most designers can begin to find flaws in some area of the design. Also, many times, players can easily find these flaws (even if they aren't able to articulate them, they can "feel" them).
However, it's not often that an entire game design can be claimed flawed. In fact, most game designs that see their way into players hands are solid and have many merits. It's not these merits, though, that we tend to focus on (an unfortunate flaw in human nature). We focus on the flaws, the scuffs, the dents in the game design...
An Alternate Perspective
There must be some way that we, as game designers, can shield our game designs from delivering hiccups to players. Even if we can't fully shield the designs, we can at least highly mitigate the possibility of flaws. We just need to approach design with a plan--a structure--a purpose. We need to recognize every facet that makes up a game design, how it fits in, how it ramifies to every other facet--and, most of all, how it affects the player experience.
First of all, we need to approach our game design as our game design. This is absolutely imperative. If we approach our design through a lens crafted by our experience and understanding of some other game design, we almost guarantee that our game design will be flawed (and also not feel fresh to players--which is a whole other issue on its own).
Once we have a head to dive into our design from the ground up, without reference from prior game designs, we can begin to look at the structure of a game design--and how to build our own design on this framework.
So what are the key components of a game design?
A fascinating fact about these game design components is they all have a very clear structural relationship to one another:
Communication is the "foundation" of any game design, and supports every other facet. If this foundation isn't rock-solid and level, all other facets of your game design will topple.
Motivation, Learning, Balance, Pacing, and Feel are the "pillars" that rise from the foundation, making up the player experience. If these pillars are uneven or weak, they will not properly support the Engagement you desire of your players.
Engagement is the "roof" that sits on top of the pillars. Engagement is the singular expression of whether or not a player enjoys the game ("engagement" is a better word for "fun", as it covers more broadly the type of positive experiences we can have while playing games). Engagement is the result of properly building all of the former game design facets.
To follow is a visual depiction of how all these things fit together, along with short-form information about what each of them specifically mean. (You can also view/download this diagram as a .pdf file from this link.)
By approaching your game design through this structural lens, you can focus clearly on each and every facet. As a result, you can ensure that each facet properly plays its role, and that no single facet is lacking. (In the future, I'll write another blog post that dives deep into what each of the game design components is, and how to apply each of them. I'll come back and edit this post with a cross-link once the future post is complete.)
I hope some of you find this information helpful. Until next time!
Justin D Leingang
Point of Reference
I came across a post that seems to be striking up a bit of controversy, regarding the difficulty of designing tutorials for tabletop games. This is a subject I'm very passionate about, so instead of just chiming in the comments of that post, I've decided to take a deeper dive and include my thoughts in this blog post. I'm here to look at tutorial design from An Alternate Perspective, hopefully to add some insight as game designers work toward hitting a home run with tabletop game tutorials.
Your Fault, Not Theirs
There are a lot of users chiming in on the aforementioned blog post, who are negatively pointing fingers at players whom "don't get" the idea of a tutorial. Here's the hard truth of the matter: It's not the players' fault they don't like the tutorial, it's the designer's fault.
Looking specifically at Charterstone (the game acting as the primary subject of the linked blog post), the issue resides in the stripping out of what experienced players feel are meaningful, complex choices--in order to instead introduce those choices over time. I give credit to Jamey Stegmaier for thinking outside the box on this one: It's a smart, innovative approach to teaching. Who would have thought to use the currently-hot ideas of Legacy game mechanics to teach players! However, this method clearly alienates a good number of experienced players.
A good analogy of how this system works:
* You go and buy the sweet new car everyone is talking about.
* When you first fire up the ignition, the car won't let you do anything except flip on the turn signal.
* After you've toggled the turn signal a bunch of times, the steering wheel is unlocked.
* You turn the steering wheel a bunch of times, then the horn is unlocked...
The obvious good point about this scenario is the fact that someone who has never driven a car can be safely introduced to the process. However, the obvious flaw with the scenario is the fact that anyone who has driven a car before is now forced to wade through familiar activities just to get to what they bought the car for in the first place: Driving really fast!
So, we have lowered the barrier to entry for inexperienced people, but have also raised the barrier of entry for experienced players--an unwelcome, unintended consequence.
Another issue with this tutorial design method is it prevents players from experimenting in the front game. Experimentation is one of the strongest tools a person has in the learning process. Experimentation allows a learner to understand the "why" behind how things work. Understanding the why is what separates true learning from simply memorizing.
An Alternate Perspective
So, how do we design tutorials that aren't limiting, overly-didactic, and mostly boring? How do we keep our tutorials from being barriers to entry for experienced gamers? The answer is simpler in concept than you might think:
Use motivation and goals to teach players about your game.
Instead of stripping down your game rules up front, go ahead and leave it all in there. There's no harm in having a bunch of cool, complex things a player can do--as long as the player is made aware of the merits of each of these things, in a digestible manner. We can accomplish this by giving players explicit goals--focal points to keep them from being distracted--designed specifically to teach about a single rule/small set of rules. Keep these goals optional, but provide ample motivation for players to accomplish them, via meaningful rewards upon accomplishing the goals. If your motivation is properly designed, you'll be hard pressed to find many players ignoring these goals. The result being that your players are not only learning, they're having fun because they're accomplishing things, being rewarded, and feeling as though they're discovering instead of being guided.
An easy way to accomplish this is to break down every one of your game rules into an actionable item. Then, design a goal for accomplishing that actionable item, and a reward for the success. Now, find a way to present to the player these optional goals, one-at-a-time or a few at a time, depending upon how complex the goals are. When goals are accomplished, new goals are presented, all within the framework of the core game rules. The challenge is in keeping these goals as subtexts to your game, rather than them becoming the key focus of the game.
Never forget: Your responsibility as a game designer is to provide guidance to players--not put them on rails--so they can smoothly learn, not memorize. Explicit goals/rewards is an amazing tool: It's the only ongoing direct communication pipeline between the designer and the players--inside the game, instead of inside the rule book (Designer to players: "Hey, this is important, and here's why! Try it out and I'll give you a gift.")
The Basis For My Argument
Tutorial design is something I've been challenged with for years in video game design. It's from experience that I discovered players' positive reactions and skill/knowledge improvements being fueled by goals and rewards. It can be tricky to translate this method into tabletop game rules, since the play experience and environment is so dramatically different. However, with careful attention, you can weave this method of teaching into any tabletop game design. (It's even possible to retrofit the method into existing games. So, if you have a complex game you love and want someone else to learn, you can apply this method and get the other player in and having fun really quickly.)
Thanks for tuning in! Until next time,
Justin D Leingang