Showing your work: the culture around making games

The defining problem of amateur game development is that projects die, and they die in the middle rather than at the start. The activity page is direct about why: scope. What the community adds is the thing scope discipline needs and a solo project cannot generate — an external date, and somebody who is not you playing the thing.

That is why jams, devlogs and public playtesting are treated here as practice rather than as socialising. A jam supplies a deadline you did not set and cannot move. A devlog supplies an audience small enough not to be frightening and real enough to notice when you have gone quiet for three weeks. Playtesting supplies the only information that matters, which is whether anybody who is not the author enjoys it.

None of this requires being any good. The culture is unusually tolerant of beginners and of failure, and that tolerance is load-bearing.

• What they are — A fixed period — commonly a weekend, sometimes a month — in which everybody makes a game to a shared theme announced at the start. Hundreds run every year at every level, from enormous international ones to small friendly ones with twenty entries.
• Why they work — The deadline is external and immovable, the scope is forced small, and finishing is the norm rather than the exception. Most people’s first finished game is a jam game, and most people’s tenth is too.
• Ranked or unranked — Many jams have voting, where entrants play and rate each other. It is worth entering ranked jams for the feedback rather than the placing — the written comments from other developers are the valuable part and the score is noise at this scale.
• Submit something broken rather than nothing — The strongest norm in jam culture. An entry that crashes on the second level is a finished jam entry; a polished thing still on your hard drive is not. Nobody is judging the bugs.
• Play other people’s entries and comment properly — Reciprocity is the whole economy. A specific paragraph about what you felt at a particular moment is worth ten "nice game"s, and it is also how you learn to see your own work.
• Do not use a jam to start your dream project — The commonest beginner mistake and the one that turns a jam into another abandoned folder. A jam is for a complete small thing.

A devlog is a public record of a project as it goes — written, or short video, or a weekly screenshot. The convention is that it is honest about failure, and that convention is unusual enough to be worth naming: the well-regarded devlogs are the ones that say "this system did not work and I deleted three weeks of it", not the ones that only show the good weeks.

The practical benefit is a soft deadline that costs nothing. A weekly post is a commitment small enough to keep and public enough to notice breaking, and it converts a project with no structure into one with a heartbeat.

The recurring pitfall is polishing the devlog instead of the game. It is entirely possible to build an audience for a project that never ships, and it is a specific and well-known failure mode. The test is simple: if the screenshots are getting better and the build is not, the devlog has become the project.

Where this happens, in broad terms:

• Jam and hosting platforms — The dominant home for amateur games, where jams run, entries are hosted and played in a browser, and comment threads are the main feedback channel.
• Chat servers and forums — Most engines and most jams have one. Feedback threads with a clear "here is a build, here is what I want tested" convention are where the useful criticism lives.
• Short-form video and screenshot days — Weekly screenshot conventions produce enormous reach for very little effort, and are the closest thing the hobby has to a shop window.
• Local meetups and student groups — Underrated. Watching somebody play your game in the same room for five minutes is worth more than a hundred online comments, because you can see the face.