Check Out the following Kickstarter Campaigns:
Goblin Teeth
Dark Metal

Connect with the Nerdlab Community:
Join the Nerdlab Community
Nerdlab Website
Nerdlab Facebook Page
Nerdlab on Twitter
Nerdlab on Instagram
Join the Nerdlab Discord

I have been asked several times if it is worth to write a Game Design Diary. And if so why?  What are the benefits? And how do you do that at all? What do you write down? How do you keep order and what is it worth to publish at the end as a work in progress blog post or as a design diary article? These are many questions. And I have to confess that I don’t have the answers to all of them at the moment. Probably there is also no right or wrong. But since the documentation of the design process is actually relevant for every game developer, I thought I would dedicate myself to this topic today. And to make the whole thing plausible I will take my current project as an example and describe how I document my design process and how I keep track of important decisions. 

Design Diaries are typically reports from designers about the creation process of their game. They often address design challenges and describe the options they have tried to overcome them. 

I think design diaries are great because they are interesting for both the players and the game designers and provide a lot of useful information. Players get more background information on the games they love. And designers can learn a lot from how other designers have overcome their problems. And by that I mean not only the mechanics the designer may have used, but also their approach of identifying and solving the problem. 

And that’s exactly the information you need to publish in a good design diary. That’s why it’s important to track this information early on in the design process. And I will share with you now how I do that.

But before I do that I need to tell you that I distinguish between a published design diary and your personal design diary. The published one is to connect with your audience while the personal design diary is really to support your game design process. Today I will focus on your personal design diary which should be a good basis to publish work in progress posts and design diaries as well.

Why you should write a design diary: 

  • To record decisions. Because otherwise, you think again and again: Oh actually the idea I had at that time was super good. Why did I actually make them like that? 
  • To identify the Most Important Task

 

What do I keep track of? 

  • Game Elements and Rules
  • Game Components
  • Inbox of Ideas
  • Backlog of Ideas
  • Challenges
  • Playtest results
  • Daily Design Journal

 

What tools do I use?

  • Google Spreadsheets
    • Challenges
    • Backlog
    • Game Components (Versioning)
  • Google Presentations (Visualisations)
    • Game Elements
    • Rules (Screenshots go Back into OneNote)
  • One Note
    • Game Elements & Rules
    • Design Journal
    • Idea Inbox
    • Playtest Documentation
  • Trello
    • Tasks
  • Whiteboards and Pen & Paper 
    • Typically I try to transfer this kind of information to a digital form later on to have it all in one place. 

Daily Design Journal

Life is a journey and for me, each day is a new chapter in my life. Keeping track of my life and the different adventures, is for me like writing my own quest log?

I personally do that twice a day. Often these journal entries do not contain any content that I want to reuse later on as a “work in progress” post or in my rulebook or what so ever. It is something that is more for me personally. Some form of self-dialogue that helps me to find mental clarity and allows me to connect to my inner thoughts and feelings.

It really helps me to identify my goals and to focus my self on the necessary tasks for the day. I am also pretty sure that this habit helps me to solve problems because they are more clear to me and this results in an advantage to push my ideas forward. 

So how do I do it: I have a specific section in one note that is titled “daily design journal”. In this section, I have a template page that I create a copy from every day. This is actually the first and the last digital thing that I try to do every day. It really has become a habit that helps me to stay focused. The template contains a few questions that I ask myself. A few questions for the morning and another few for the evening. The questions are the same for every day but from time to time I add or remove a question if I have the feeling that it is needed.

My questions for the morning are:

What can I do today to profit in the future?  

  • Answers can be to research a specific topic
  • Or to tell a random person about my game
  • Or to reach out to a designer that I admire to arrange an interview on the podcast
  • Or to prepare something about the current state of my game to show to my mastermind group
     

What am I grateful for today?  

  • This question is not really game design specific. But I have the tendency to think too much about the negative things in my life. And spending just 1 minute in the morning can really help me to focus on the positive aspects of my life and also my game. When I work on the game I often think about the problems and how to solve them. But not everything is bad and it can help to take a few moments to recall the positive elements as well.
     

Task List Review: What is the most important thing that I can achieve today (what is the frog)?  

  • The goal really is to identify the most important thing that I can achieve today. For my personal situation, this really is dependent on two things. First, how much time do I have to work on the game today? And second, what task on my task list is achievable in this timeslot. 

My questions for the evening are:

Divided into two groups. Some questions to reflect the day and 2 questions to plan the next day.

  • How do I feel today? 
  • How much time did I spend working on the game today? 
  • What have I achieved today?  
  • What did I learn today?  
  • What can I do better tomorrow?  
  • What do I want to achieve tomorrow?  

The goal in the evening is really to reflect again on what you have achieved during the day and already set yourself a rough goal for the next day. When you get up in the morning you then have already a good reason to get up. That helps me tremendously in the morning at 5 o’clock not to press the snooze button. 

Inbox

The concept of having an inbox for all your ideas that come to your mind is something I already talked about a while ago on this podcast. The concept comes from the book “Getting Things Done” by David Allen. Instead of carrying all my thoughts and tasks around in my head, I immediately write every idea into my inbox. This should be as easy as possible and don’t take longer than a few seconds. In my case, it’s also a Section in my OneNote Notebook. Every new entry gets a new page. No ordering, no tagging, nothing. The goal is to get it out of your head as soon as possible. This creates space in my head, prevents distraction and gives me the mental strength to focus on the essential issues I am working on in that particular moment.

I write down everything. The names of a game I want to test in the future. A keyword that might be work for my game. A story idea. Or a possible solution for one of my design challenges. The ordering of the messy inbox happens later when I have the time to do it. 

What’s very important is that you have a system in place you can trust. That means you need a fixed time where you empty your inbox and transfer the topics from your inbox to your task list, your design document, your design diary or your backlog for later. You must trust your system so much that your subconscious mind is willing to completely forget the thought you had for the moment. Because you know that your system in place will help you to come back to that topic later when the time and place are right. 

If you only adapt one thing from everything I talk about today I would recommend starting with the inbox. It is my number one tool to increase my mental capability by getting rid of distracting thoughts. 

Game Elements & Rules

For all the elements of my game, I have a separate page in OneNote. This can be imagined as a very rough rulebook in terms of structure. Each section of the rulebook is a separate page in OneNote. A page to describe the phases of my game. A page to describe the drafting process. One to describe the combat system, one to describe the movement, another one to describe the resources of the game and so on. What I don’t do on these pages in Onenote is to go into the detail of single cards. But I describe very well the structure of the different card types. So how is a Hero card structured. What are item cards and how are they used in the game? The actual cards are in a spreadsheet. Because I need to order them, calculate values automatically and use it as an input file for automated card creation. 

My goal for these Game Element pages in OneNote is to have a central place where I collect the ideas for the individual elements. And I also want to keep track of how those elements evolved over time. That means I typically don’t remove text when I make changes but I write it on top of the page and divide it with a separator line and a headline. By doing that each page is some sort of history of how the specific game element evolved over the course of the design phase. I also make a note here when I encountered a specific design challenge. I hope this helps me to publish interesting Work in Progress Posts and Design Diary Articles in the future. 

Playtest Documentation

Another thing I keep track of are my playtests. And when I say playtest I even mean my own solo playtests. For each test I copy my documentation template page in onenote and write down everything that is important for that testrun: My template contains the following:

Setup of the test: 

The setup section can be considered as the metadata of the testrun. What kind of metadata you want to keep track of might be different for your games. I keep track of things like: 

  • How many players? And who? 
  • What kind of game elements where tested? (Often I only test a specific combat mechanic or phase of my game)
  • How where the game elements implemented during this test run?
  • How many Heroes? Which Heroes? Which Alliances?  
  • For example I tested different battlefield variants for my game. Therefore I kept track fo which option I was testing in which run. One was a grid version, another one was a battleline version and so on.  
  • Other stuff I try to track is the time the test took. How long do the rounds take? How long does combat resolution take and so on? 

What was good / What was bad? 

I keep a list of bullet points of what felt good and what felt bad during the playtest. I especially try to identify the situations in which my playtesters react very emotional. When did they have fun? When were they frustrated or even angry?

At the end, I transfer those bullet points into challenges and ideas which both go into my spreadsheet. Either to my challenge section or my idea backlog for ideas I want to test in future iterations. 

That is everything I use onenote for. You can, of course, use any other kind of note-taking software. I’ve been using Evernote a lot in the past for example. At the end, I don’t think it makes too much of a difference what you use as long as you are comfortable using it. 

Game Components (Versioning)

For the real game components, I use spreadsheets. I don’t want to talk too much about the game components spreadsheet today I think it is the component of my documentation plan that differs the most between games. What I have is a separate sheet for each component type. SO on sheet for all the hero cards, one for all the spells, one for the items and so on. If I make major changes to the list I add a new version. Just to be able to track the changes later on.  

  • For all decisions, one should write down a reason. Let me give you an example. When I design keywords for card games, I write a list of all KEywords I want to test. Then I test the KEyword. If it doesn’t work, then it comes to another list of keywords that didn’t work. I write a reason behind it and documented it.