Dytbaat Games · making good games greatCopenhagen, Denmark · game design, data and growth

Home › About

Case notes: what we learn from every release

About · 18+ · Dytbaat studio
Case notes: what we learn from every release

Every project leaves a record, whether or not anyone writes it down. We choose to write ours, because a lesson remembered is worth little and a lesson recorded can be learned by the whole team. These case notes are how we capture what we decided, what happened and what we would do differently, across both our own games and the projects we take on for studios.

Why we keep case notes

A studio without records keeps relearning the same lessons. A change that worked two years ago is reinvented badly; a mistake made in one project is repeated in the next because nobody remembered why it failed. Writing it down is the cheapest way to build memory into a small team.

Case notes: what we learn from every release

Case notes also make honesty easier. When a decision and its result are both written, it becomes much harder to tell a comfortable story about a project after the fact. The record keeps us faithful to what actually happened, which is the only version worth learning from.

What goes into a case note

A good case note is short and specific. It records the situation, the decision, the expectation and the outcome, and it ends with the lesson. It is not a report for a client and not a marketing story; it is a working document for people who will face a similar problem later.

  • The problem, stated in a sentence.
  • What we decided and why.
  • What we expected to happen.
  • What actually happened.
  • What we would do differently.

That last line is the one that matters most, and it is the one most likely to be left out. A note that ends with the outcome alone is a diary; a note that ends with a lesson is a tool.

Learning from our own releases

Our own games are the richest source of case notes, because we live with the results for a long time. When Solitaire Grove taught us that subtraction outperforms addition, that lesson went into the notes and shaped every title after it. When Flop Ball Jump corrected our sense of feedback and difficulty, the note changed how we advise clients as well.

The table below is the shape of a typical lesson from our own titles, from the situation to the habit it changed. Each one began as an observation during play and ended as a rule we now keep.

SituationWhat we learnedThe habit it changed
A calm game felt stressfulRemoving pressure helpedDesign by subtraction
A run felt unfairFeedback, not rules, was wrongTune the feel first
A daily loop felt like a debtForgiving calendars retainReward return, never punish
A puzzle felt luckyFairness must be visibleCheck every board

Learning from client projects

Client work produces its own lessons, and we are careful about how we record them. A case note about a client never names them without permission and never includes anything that could identify their game or their numbers. We record the method and the reasoning, and we leave the identity out.

That restraint is not only a courtesy. It is also what makes the notes useful, because the transferable part of any project is the method rather than the particular game. A lesson stripped of names travels further and reads more honestly than one that trades in specifics it should not share.

Reviewing the notes before the next project

The notes only earn their keep if they are read. Before a new project we go back through the relevant ones and ask what applies, so that the team starts from what it already knows rather than from scratch. This small ritual has saved us more than once from repeating an expensive mistake.

We also revise the notes when we learn something new, because an understanding that never changes is usually an understanding that stopped looking. A note is a living document, and the day it becomes a museum piece is the day it stops helping anyone.

When a project goes wrong

The most valuable case notes are the ones about things that did not work. A failed change, a misjudged feature, an assumption that turned out to be wrong: these are the notes that save the most time later, and they are the ones a proud studio is most tempted to leave unwritten. We make a point of writing them first.

A note about a mistake is not a confession; it is a map of a place not to go again. Recording it plainly, without blame and without softening, turns an expensive lesson into a cheap one for whoever faces the same terrain next. The habit costs nothing, and it is the difference between a team that learns and one that merely endures.

Memory as a studio asset

For a small studio, accumulated judgement is the main thing we have that a larger competitor cannot simply buy. Case notes are how that judgement survives the person who earned it, and how a lesson learned in one project reaches the next one without being lost in the gap between them. Writing them down is tedious, and it is one of the few habits that makes a small team quietly formidable over time.

How we work. Every engagement starts with measurement: we look at how your game actually behaves before we suggest a change. We give honest, evidence-based advice, and we would rather tell you that a feature is working than push a rework you do not need.

Read next

About

About Dytbaat: a studio and consultancy

Three industry veterans, one studio, and a focus on making good games great.

About

Our approach: data, play and iteration

Why we measure before we change anything and how iteration shapes our work.

About

The tools behind our games and analysis

The everyday software and methods our designers, engineers and analysts rely on.