What Comes Next After Analyzing Games

After spending years studying game design concepts, ideas, and principles, there comes a point where analysis starts to feel incomplete. Talking about ingredients is useful, but eventually someone has to bake the cake.

The next project is simple in scope: make a video game. A very small video game. A very rough video game. But still a complete game, carried from not knowing much at all to releasing something tiny on a place like itch.io.

The point is not to create a definitive tutorial or a complete map of indie development. The point is to document one person's experience of trying to make a game from scratch, honestly and transparently, with design as the main thread.

It is possible to talk usefully about screenwriting without making movies, or about game design without shipping games. Outside analysis can still be valuable. Players, critics, designers, researchers, and teachers can all see different parts of the same craft.

But there is something especially interesting about taking design ideas that have lived in essays, examples, and principles, then trying to apply them to an actual project. Suddenly the ideas have to survive constraints, tools, time, taste, mistakes, and limited ability.

A small game can touch many parts of development: art, audio, code, tools, collaboration, learning, and production. But the central question remains design-focused: what happens when abstract design principles are used to shape a real game?

A player or critic can talk about level design, bosses, puzzles, pacing, tutorials, game feel, and structure from the outside. Building even a tiny game forces different questions.

Which idea is actually possible at this scale? Which mechanic sounds clear in theory but becomes confusing in a prototype? Which limitation is technical, which is artistic, and which is a design problem hiding under another name?

Those are the surprises that only appear when the work becomes physical. The value of the project is not that every decision will be correct. The value is in watching where theory breaks, bends, or becomes useful.

Many people who love games are interested in making one someday. They also have good reasons for delaying it. They do not know where to start. They do not know how long it will take. They do not know which tools to use, what skills they need, or how small the first game should be.

A transparent development diary can make that uncertainty less abstract. It can show the early confusion, the wrong turns, the tool choices, the first ugly prototype, the parts that are easier than expected, and the parts that are harder than expected.

That still does not make the project a step-by-step guide. It is only one path through a large field. But one honest path can help someone else imagine their own first steps.

The project does not need to pretend to be an expert course. It can simply say: here is one person trying to learn game development in public, from a small indie perspective, with enough transparency that the mistakes are useful too.

That is an important distinction. A beginner's process can be valuable precisely because it shows the beginner problems. Experts often forget what the first obstacles feel like. Someone starting from the bottom can make those obstacles visible.

If the result helps another creator decide where to start, what to learn first, what to avoid, or how small to make their first project, then the transparency has done its job.

Doing one kind of creative work for years can lead to competence, but competence can also become restless. Once a format feels familiar, the next useful move may be to step outside the comfort zone.

For this project, that means learning not only game development, but also the practical craft of presenting the process: cameras, lights, microphones, lenses, production habits, and the unfamiliar awkwardness of being visibly present instead of only explaining over footage.

It also means learning engines, code, collaboration, scope control, and the thousand small decisions that turn an idea into something playable. That unfamiliarity is the attraction. The challenge is the reason to do it.

Moving into development does not mean abandoning analysis. In fact, making a small game can create better analysis because every feature becomes a research question.

If the game needs a boss fight, then the next step is to study boss fights: play strong examples, inspect their structure, read interviews, and talk to designers. If the game needs a tutorial, pacing structure, audio cue, or puzzle, the same process applies.

That research can then become useful writing in its own right. Making the game produces practical questions, and those questions lead back to analysis with a sharper edge.

The obvious development is the game itself: a small project moving from nothing to release. That alone is worth following, because even a tiny game contains design, production, technical, and emotional lessons.

There is also a development of the broader work: from only analyzing games to also making them. The perspective changes when the person asking design questions is also responsible for answering them inside an actual project.

Finally, there is personal development: moving from someone who plays and enjoys games, to someone who analyzes and breaks them down, to someone trying to design one. That progression is the real subject.

At the beginning, there are many reasonable questions. Which engine will be used? What genre will the game be? When will it be playable? How much collaboration will be involved? How large can the project become before it stops being small?

Those questions do not need to be answered all at once. Part of the value is discovering the answers through the process, not pretending they are settled before the work begins.

The important first commitment is smaller: make the game, keep the scope modest, show the process honestly, and treat each obstacle as material for learning.

The game does not need to be grand to be worthwhile. A tiny project can still force real decisions about mechanics, art, audio, structure, tools, feedback, scope, and release.

In fact, a small game is probably the right size for this kind of journey. It leaves room for failure without making the project impossible. It creates enough pressure to learn, but not so much that the whole thing collapses under ambition.

The promise is not that the finished game will be brilliant. The promise is that the process will reveal what changes when someone stops only analyzing games and starts building one.