The tools behind our games and analysis

The tools a studio uses are less interesting than the habits it keeps, but they still shape how work gets done. Ours are chosen for one reason: they let a small team measure, build and communicate without adding ceremony. This article describes the everyday software and methods behind our games and our analysis, and why we keep the list short.

Choosing tools for a small team

A small team pays for complexity twice: once in money and again in attention. Every tool added has to earn its place by removing more work than it creates, and a studio of three cannot afford a stack that needs a person to maintain it. We favour tools that are simple, dependable and easy for a newcomer to learn in a day.

We also favour tools that make the work visible. A design note, a data query or a build that anyone on the team can read without training keeps the studio honest, because judgement improves when it can be checked by someone else.

For design and planning

Design work lives in writing and in simple diagrams. A short brief that states the player's goal, the constraint and the expected result does more for a project than any elaborate planning software. We keep design documents close to the game, so that a decision and the reasoning behind it are never more than a few steps apart.

For planning we use a plain shared board with a small number of columns. The value is not in the software but in the shared agreement about what each column means, which is what stops a plan from quietly becoming a wish.

For building and testing

Engineering happens in a version-controlled project with automated checks, because a small team cannot rely on memory or on one person's care. A build that can be reproduced and a test that runs on every change are the cheapest insurance a developer has, and they pay for themselves the first time someone breaks something at the wrong moment.

• Version control for everything that can be versioned.
• Small, frequent commits with clear messages.
• Automated checks that run before a change lands.
• Builds that anyone can make, not just one machine.

We keep the tooling modest on purpose. A simple, reliable set of checks beats an elaborate pipeline that nobody trusts enough to rely on.

For data and analysis

Our analysis rests on a small, well-named set of events and a few honest questions, rather than on an elaborate reporting stack. The table below is how we organise the tools of the trade and what each contributes.

For communicating as a team

Communication tools exist to keep a distributed team aligned, and we choose them to protect long stretches of quiet work rather than to fill them. Writing is the default, a short call is the exception, and everything important ends up somewhere a colleague can find it later. The best communication tool is the one that lets someone get on with the work.

We keep notifications deliberately quiet. A tool that interrupts constantly for things that can wait is not saving time; it is spending the studio's attention in small, invisible instalments until nothing is left for the work itself.

The tools we deliberately avoid

Just as important as what we use is what we leave out. We avoid elaborate process software that needs its own maintenance, dashboards that nobody acts on, and any tool whose main effect is to make the team feel busy. Complexity tends to arrive disguised as professionalism, and a small studio has to be able to tell the difference.

The test we apply is simple: does this tool help the team decide or build something sooner? If the answer is not a clear yes, it does not earn a place. That test has kept our stack small and our attention on the work, which is exactly where a three-person studio needs it to be.

A stack that serves the work

Our tools are not a showcase and they are not permanent. They change when the work changes, and they stay only as long as they make the work clearer. The point of a tool is to disappear into the background and leave the team with the game, the players and the honest questions about both. When that happens, the tool has done its job.