Quick answer: Write the summary line for the person searching history during a bug hunt: imperative, specific, under ~70 characters — 'Fix dash passing through locked doors', not 'fixes'. For game work especially, record the why of tuning and design changes in the body, because 'Increase jump force to 12' without the reason is a mystery you'll re-litigate in three months.
Write the summary line for the person searching history during a bug hunt: imperative, specific, under ~70 characters — 'Fix dash passing through locked doors', not 'fixes'. For game work especially, record the why of tuning and design changes in the body, because 'Increase jump force to 12' without the reason is a mystery you'll re-litigate in three months. That's the short version — the sections below get into the how, the why, and the mistakes worth dodging.
Messages are for the debugger you'll become
The audience for a commit message is someone bisecting history to find when a bug appeared — usually you, angry, months later. 'Update player.gd' helps that person not at all; 'Clamp fall speed to fix tunneling through thin platforms' lets them skip or suspect commits at a glance. The discipline costs ten seconds per commit and repays it the first time history answers a question.
The conventional shape works: imperative summary line ('Add', 'Fix', 'Tune'), blank line, then body only when the change needs explaining. Tags like 'audio:' or 'ui:' prefixes help filtered searching in bigger projects.
Game dev's special case: record the why of feel changes
Code changes explain themselves in the diff; tuning changes don't. 'Reduce coyote time 0.15→0.08' is visible in the diff — what's invisible is that playtesters found jumps too forgiving on the speedrun routes. Game history is full of numbers changed for reasons, and the reasons are the valuable part: they prevent endless re-tuning oscillation when a future change re-raises the question.
Same for asset commits: 'Replace boss theme — old track fought the SFX frequency range' turns an opaque binary swap into a documented decision.
Small commits make good messages possible
The unwritable message ('Fix UI, tune enemies, add save migration, misc') is a symptom: the commit is three commits. Committing each logical change separately produces messages that write themselves and history that bisects cleanly — the practices reinforce each other.
Don't aim for poetry; aim for searchability. Six months from now you'll grep history for 'dash' or 'save' — write the words your future search will use, and the system works regardless of prose quality.
Your future self is a stranger — leave notes
Six months from now you will not remember why that magic number is 0.73 or which scene is safe to delete. Project knowledge that lives only in your head evaporates on contact with a break, a jam, or a day job crunch.
Keep one running NOTES file: decisions made, things that look unused but aren't, how to do the fiddly release steps. Five minutes of writing per week buys you days of re-discovery later.
Boring tools are a superpower
Every hour spent fighting your own pipeline is an hour not spent on the game. The goal of tooling isn't sophistication — it's that builds, backups, and versioning become so boring you forget they exist. Set them up once, automate them, and let them run.
The test is simple: if your machine died tonight, how long until you're working again? If the answer is 'an hour', your tooling is good. If it's 'I'd lose a week', fix that before adding any feature.
Close the loop with real players
Advice gets you to a sensible starting point; only real player behavior tells you if it worked. Ship the change, then watch what actually happens — the reports that come in, the errors that spike or vanish, the place sessions end.
Make that loop short. When a player can report a bug in ten seconds and you see it with logs attached, you stop guessing what to fix next. Tight feedback loops are the closest thing indie development has to a cheat code.
Putting it to work
Don't try to act on all of this at once. Pick the one change that costs you the least and pays the most this week, do it, and see what actually happens before reaching for the next.
Most of this rewards steadiness over intensity. A small improvement made every week, checked against how real players respond, outruns any single burst of effort — in this corner of game development and every other one.
If your machine died tonight, you should be working again by morning. Build toward that.