Tools and pipeline for a small game team

Version control, and the binary problem

Games are mostly large binary files, which is precisely what most developer tooling handles worst. Two files nobody can merge is a different problem from two branches of text.

• Everything goes in version control, including art source files, audio and the engine project. Assets on somebody's desktop are assets that will be lost.
• Use file locking for binaries. Whatever system you choose, artists need to be able to reserve a file so two people cannot edit the same scene or texture in parallel.
• Configure large file handling early. Repositories that grow uncontrolled become the reason cloning takes an afternoon.
• Commit small and often, with messages a person can read in six months.
• Keep source art in the repository too, not just exports. The day you need to change a texture is the day you discover only the PNG survives.
• Test the restore. A backup nobody has restored from is a belief, not a backup.

One command to a running build

The single highest-value thing a small team can build for itself, and the thing most often skipped because everyone's machine already works.

1. Automate the build, so producing a playable build is one action rather than a ritual only one person knows.
2. Run it on a schedule, nightly at minimum, so breakage is discovered within a day rather than at the milestone.
3. Put the output somewhere everyone can reach, with the date and the commit in the filename.
4. Build every platform you ship on, regularly, not just at the end. Platform-specific breakage found late is expensive.
5. Keep the last known good build. When today's build is broken, playtesting continues with yesterday's.

Task tracking that survives contact

• One list, one place. Tasks split across a chat app, a spreadsheet and somebody's notebook is the same as having no list.
• Simple beats sophisticated. Small teams do well with a board of four columns and a rule about who moves cards.
• Tasks are things, not areas. "Inventory screen empty state" is a task; "UI" is a category.
• Every task has an owner and a size, even a rough one, or the list cannot be used to plan.
• Link tasks to milestones, so the board answers "are we going to make it" rather than only "what is everyone doing", per running milestones.
• Groom it weekly. A board with two hundred stale cards stops being read, and then the real list moves back into chat.

Naming and folders

Unglamorous, and it decides whether anything can be found in month eighteen. Agree it once, write it on one page, and enforce it while the project is small enough to fix.

The same discipline applied inside the engine is what keeps a component library usable, which is in prefabs, variants and a Unity UI kit.

The asset pipeline

• Define the export path once: source file, export settings, destination folder, naming. Written down, not remembered.
• Automate the export where you can, because a manual step performed hundreds of times will be performed inconsistently.
• Agree the specs before production, not per asset: resolutions, formats, padding, atlas grouping, import settings.
• Keep source art out of the built game but in the repository.
• Make the round trip cheap. If updating one icon takes twenty minutes of manual steps, icons will not be updated.
• For interface specifically, the specs that matter are in designing game UI for Unity.

Playtest and feedback loop

1. A build people can play, every week. Not perfect, playable.
2. One place for feedback, with a template: what happened, what you expected, build number.
3. Automatic build numbers in the corner of the screen, so a report can be traced to a build. This one line of interface saves hours.
4. Crash and error reporting wired up early, because the crash you cannot reproduce is the one players will hit most.
5. A regular external playtest, which is a different thing from the team playing it, per how to run a playtest that tells you something.

Working with people who are not in the room

Most small teams now include somebody remote, and most contractors are. The tooling questions are the same; the discipline needed is higher.

• Write decisions down. A decision made in a call that nobody recorded will be re-made differently in three weeks.
• Async by default, calls for decisions. Long threads for context, short calls to choose.
• Overlap hours, stated. Two or three hours where everyone is available is enough, and knowing when they are prevents a day of waiting per question.
• Give contractors real access: the repository, the build, the task board. Working through a middleman doubles everyone's cost.
• One person who answers questions, so a blocked contributor is blocked for an hour rather than a day.

Every hour a small team spends on pipeline is an hour bought back from every person on the project, every week, for the rest of it.

What to skip

• Heavyweight process. Sprints, ceremonies and estimation rituals designed for thirty people cost more than they return on four.
• Custom tooling before you know the problem. Build the tool after the manual version has hurt three times.
• Perfect documentation. A one-page setup guide that exists beats a wiki that does not.
• Tool churn. Switching task trackers mid-project costs more than the deficiency you were fixing.
• Automating a thing you do twice. Automate the daily, not the annual.

A pipeline check

1. Time a new person from nothing to a running build.
2. Ask who can produce a release build. If the answer is one name, that is a risk.
3. Check whether source art is in version control, not just exports.
4. Try to restore yesterday's build. Does it exist?
5. Open the task board. Is it current, and can you tell whether the next milestone will land?
6. Pick a random asset and check it against your naming convention.
7. Count the manual steps between changing one icon and seeing it in game.
8. Check the build number is visible in the game.
9. Ask a remote contributor what blocked them longest last month.
10. Confirm the last known good build is kept somewhere everyone can reach.