Write a devlog about the thing you changed

I would rather read how you fixed a slippery jump than another announcement that a game was made with AI. One concrete change gives me something to understand, discuss and perhaps try in my own project.

By VelvenBeginner3 min readPublished Sep 9, 2026Updated Sep 11, 2026

Loose but skillful risograph editorial illustration: two human hands exchanging a small sketchbook showing a simple green maze drawing.

Find the before and after

Choose a development event with a visible consequence. The player used to slide after releasing a key; now movement stops predictably. The exit used to be hard to notice; now it opens with a clear visual cue.

Capture both states if you have them. If you don't, explain the earlier behavior plainly rather than recreating evidence and presenting it as an old build.

I'd open the post with the problem and the change. Put the tool names later, where they help explain how you worked. The interesting part is the decision and what it did to the game.

Record small changes instead of waiting for a highlight reel

Several gamedev devlog threads agree on a small, repeatable format. Record a short clip or screenshot when something meaningful changes, then group related changes into one post. Don't wait until you have a polished trailer; two usable clips are enough to explain a change.

Keep each post on one subject: say what you did, why you did it, and how. That structure is easier for another creator to follow than a broad announcement that the game was made with AI.

Explain the part another creator can use

Keep the technical detail proportional to the lesson. A short code excerpt or prompt can help if you explain what it changed and where it belongs. A huge transcript usually makes the reader do the editing you skipped.

Include the failed idea when it explains a useful tradeoff. Perhaps adding friction made the movement feel sluggish, so you changed the release behavior instead. That is more valuable than presenting the result as an effortless sequence of correct choices.

Use footage from the actual build and identify what is still provisional. If you share a playable link, make sure it points to the version you're discussing.

End with a question that has a job

Ask whether the jump landing feels predictable, whether the exit is visible, or where someone first got confused. A focused question makes it easier for a reader to contribute a useful observation.

Follow the rules of the place where you post and respond to specific feedback. Keep notes against the build version so a comment about yesterday's bug doesn't become a mystery next week.

I'd treat the next devlog as a chance to close the loop: what you heard, what you changed and what remains uncertain. A series of understandable decisions gives people a reason to follow the project while helping you build it more carefully.