An essay by Arty

Vision-based Game Design

The five steps to effective RPG design

Designing roleplaying games is pretty hard. Yes, making up rules for a game is easy, and putting
them together isn't too hard. But the process of honing and making it better, that's the difficult
part.

In this essay, I walk you through a method I came up with which elevated my workflow and
designs to another level. These days, I make better games and I make them faster than I did
before.

Background
Every story begins somewhere. Mine begins with a game called ​Misfortune​. It was the first game
I ever published, but far from the first I wrote. I had several projects before it, ​Atrox​, ​Six Stories
and so forth, which I never released.

The reason why ​Misfortune ​ended up being released was because I believed in it. It felt different,
and the mechanics folded into each other. The game had a strong design vision, and it allowed
me to recognize the shortcomings of my other systems.

After releasing it, I struggled with my next game, ​Fairytale​, once again. I had a strong idea for it,
but I couldn't quantify why it didn't work like ​Misfortune​ did. It was brash, bold, and different! It
should have worked.

This made me look back into ​Misfortune​, and how the design folded around itself. This
introspection led me into years of honing this method, which I now call Vision-based Game
Design (VbGD).

Introduction
I believe I am not doing anything new with this method. I can tell you right now, the primary
feature of this method is making a design document. That's it. However, how you make that
document matters. Many of use tabletop game designers don't have traditional game design
knowledge, and this is both a good and a bad thing. We experiment more, but we also lose out
on many useful tools that already exist.

Vision-based design is my answer to that. While not only for tabletop roleplaying / storytelling
games, I made it with those in mind. It is a simple method for extracting ideas from your head
and putting them to paper. Effectively, it means you design the game before you write a single
sentence of rules.

The method has five steps, which you usually go through in a linear order. However, sometimes
breaking the order is beneficial, so use the order more as a guide, not a strict path.

The five steps in the method are ​Vision, Requirements, Structures, Connections, and Presentation.
Vision​ is the foremost basic concept of the game. The meat, and the emotional goal you have in
the game.

Requirements​ are the foundational building blocks that you need for the vision to be true. It
means you translate your vision into distinct, achievable goals.

Structures​ are the different parts and loops of gameplay. They provide a way to manage how the
game is played.

Connections​ are made up of individual elements. Mechanics, resources, playing pieces,

characters which influence the gameplay, and how they interconnect.

Presentation​ is how you present the game, and how to use it to give the gameplay experience
you desire.

These five steps become five parts in your design document, and they massively help you design
a game.

Making the document

Before you can make anything, you need to actually start making the document. I prefer to use
Google Docs or some kind of a text editor, but doing things by hand can prove beneficial. The
design document created this way is almost never more than one sheet of paper long.

Once you have the empty document ready, just add the first heading, which will be Vision.

Vision
Vision is the central pillar of your game. It is the seed, the idea from which the tree that your
game is sprouts from. So from the very beginning, it is important to have a compatible vision for
the game.

What works best for the vision are evocative things. It doesn't even need to be immediately
apparent to any player of the game. You can even put in an example situation with the desired
outcome.

"A Post-apocalyptic game focusing on happiness"

"A game that questions whether player characters have free will"

"A game about learning a complex magic system through gameplay"

"A Fantasy game exploring the contrast between humanity and heroism"

These are all Visions that I use and have used in my games.

The most important feature of a vision is brevity. Try to crystallize the feeling or goal with the
game into as few words as possible without losing nuance. If the vision is too lengthy, such as a
paragraph, it can be wieldy to use later on.
Requirements
Requirements is the deconstruction of the Vision. In the requirements, you take a vision and
chunk it into achievable conditions. These requirements take form as features that must exist in
the game, but also as things to omit from it.

Let's take the first example vision we had:

"Post-apocalyptic game focusing on happiness."

This is a simple vision to create requirements for, because it only has a few details. I would see
them like this:

– The game must be post-apocalyptic

– Happiness is a central game mechanic

– To focus on happiness, survival aspects only matter as much as they affect your happiness

– To further focus on happiness, things such as combat should not be on the table

These four requirements are what I started from when designing Last Little Wonders.

This part of the design document, requirements, is arguably the most important one. When you
construct these requirements, you are going to gain clarity on what the game itself will look like.
So pay attention to the things you write.

Structures
Structures are a way to formalize different types of gameplay you have, and how they connect.
Structures are gameplay loops, different sections of gameplay, or the different roles players
have. By recognizing these structures, you can fine-tune the feeling the game has.

Most games start out with a structure we call Character Creation. This is a separate part of
gameplay we usually don't think about. Regardless, it is gameplay, oftentimes its own separate
game, even. By recognizing how Character Creation connects to different parts of the game, you
can make it more enjoyable.

When making structures, you should be aware of the Requirements you wrote for the game.
This allows you to nudge the design into the right direction and get novel ideas on how to
execute it.

Let's make an example:

Challenges use up resources.

Challenges give rewards.

Resources are regained with rest.

This is a simple gameplay loop, where you do challenging things, and are rewarded, and must
rest afterwards. Most roleplaying games have similar gameplay loop, in some form.
To make up an example, I'm going to show how changing little parts in this gameplay loop can
make a large difference. This is how this gameplay loop worked in Last Little Wonders.

Challenges use up Happiness.

Challenges give mostly temporary rewards.

Happiness is regained by using time to your interests or having fun.

By changing these key factors, you can get a feel for the game. Using Happiness for resolving
challenges gives a different feeling to just resources. Gaining happiness through interests and
having fun puts emphasis on those things. And lastly, challenges giving mostly temporary
rewards makes the entire gameplay loop feel futile.

Structures can also take form of simple, descriptive sentences.

– Character Creation focuses on emotional bonds with the other characters.

– The magic system is based on the classical Greek elements.

– The player characters do not have free will by default

These work as guidelines to design your Connections and the rest of the game around them.
Sometimes, when I feel lazy, I skip over Connections and Presentation, and start writing at this
point. However, this is only recommended when you are familiar with this method.

Connections
Connections is a phase where you write out elements in the game, which you then connect to
each other. This allows you to find dependencies and tweak the balance of individual parts of
the game before writing.

The word 'element' includes things like Resources, Attributes, Resolution mechanics or Dice.
Essentially it is any singular item or feature that affects gameplay meaningfully. List all of the
elements, such as different attributes, individually.

Then start creating connections, what kind of features in the game they effect. You can write
these connections out, or you can make a mind map of them. Regardless, just keep connecting
the individual parts until you have a good set. Don't try to catch every minute detail, focus on
the most important ones to your Vision and Requirements.

Once you have made the connections, you can easily see which elements of the game have
emphasis over others. If, for example, one attribute has only one or two connections, and
another has ten, you can see a discrepancy. You can then use this information to analyze the
game, and either cut or further develop underdeveloped features.
Presentation
Then, finally, we get to presentation. Presentation means how you structure the actual
document, the rules of the game. What kind of art are you going to use, if any? What kind of font
and layout are you going to make for the game?

These questions are beyond the scope of this essay, and require their own kinds of expertise.
However, it is good to think about these things before you start developing the game. You might,
for example, get an idea that the game would actually work well as a card game. This requires a
completely different approach to writing the game than one kept inside a document.

While presentation is important to the game, it is important to realize that it is a completely

different world than game design. Many games can elevate themselves via the use of
presentation, and others fall because of it. Regardless, the design of the product you aim to make
is still usually completely different from the core game design of the game.

Your presentation chapter doesn't need to be too long, assorted notes for the presentation is the
most important. For example:

Use a notebook style. Stick fake post-it notes and polaroid pictures into the game as art and
additional notes.

Write it all into a .txt file. Use ASCII art for the headers to separate the chapters.

Let it sink in
After you're done with presentation, the document is done for now. However, I would still
advise against starting to write a game. I usually let my designs sink into my head for a while,
like a week, before I start writing the game proper. This lets the ideas in my head mature, and I
might get some new, bold ideas to the project. Game design isn't a race, unless you're trying to
get something out into a game jam or something.

Nested documents
Sometimes, you might hit a wall with the game. Your idea might be too big to handle, and you
end up with too many structures and connections to keep it all together. This has happened to
me, too, with one of my projects.

This method is best suited for small games. I'm talking 10 to 20 pages long at most. However, I
came up with an supplementary method that makes it possible to use this for larger projects.

It's very simple. Instead of making a single document, you make nested documents for different
parts of the game, complete with the same subsections. Cutting Presentation is possible, unless
you want some part of the game to stand out.
For example, in Endless Expedition, I made separate design documents for:

– General game

– Character Creation

– Magic system

– Scene system

– Adventure Managing tools

This helps to segment the goals of each part of the system, without needing to handle the entire
project at once.

Afterword
This design method is something that helped me a lot to keep consistent and flexible in my
design efforts. It also helps a lot to go in with an open mind when starting this process. If you
have a project you're already writing, this method can be difficult to apply to it. This is because
you already have all these mechanics in your head, and it becomes harder to navigate the
important bits.

However, like all advice on the internet, take this method with a grain of salt. It isn't perfect,
one-stop-shop for all your design needs. Expand your horizons and use this tool however you
see fit.

Thank you for reading. I hope that this method helped you in some way. Whether it's actually
using it, or simply getting an idea on how to develop your game, I'm happy if it helped you.