Episode 1: Why I Started Building an Adventure Game

Development Journal for Where the Arc Falls

Why this project exists

When people hear that I am building an adventure game, they sometimes assume I must have a background in the games industry. My professional experience is technical rather than game-specific: software, automation, engineering systems, AI, robotics, machine vision, cloud platforms, and tools that solve concrete industrial problems. Games were always something else for me. They were the place where I went when I wanted to experience a story that could only work interactively.

My actual experience in game development before this project was amateur. I had experimented, learned tools, followed games closely, and built small things, but I had never worked professionally as a game developer. That matters because it shapes the project. I am not approaching this as a studio veteran with an established production pipeline. I am approaching it as someone who has spent years solving engineering problems, but who has always carried a strong appreciation for the particular kind of storytelling that adventure games can do.

Why adventure games stayed with me

The games that stayed with me were rarely the ones that tested reflexes. They were the ones that asked me to pay attention. A good adventure game makes every object feel intentional. A locked door is not just an obstacle. A strange machine is not just a puzzle. A conversation is not just flavor text. The world itself becomes something the player has to understand. Progress comes from noticing patterns, making connections, remembering small details, and gradually learning the logic of a fictional place.

That is still one of the most powerful things about the genre. A good puzzle is not only a challenge; it is a way of making the player inhabit the world. When the puzzle is designed well, solving it feels less like beating the designer and more like understanding something that was always true inside the story. That kind of thinking is deeply satisfying to me. It asks the player to slow down, observe, and reason.

But the best adventure games do more than make you think mechanically. They also leave emotional residue. They create images, ideas, and moments that remain with you years later. Sometimes it is a line of dialogue. Sometimes it is the feeling of arriving somewhere forbidden. Sometimes it is the realization that the story was not about the mystery you thought you were solving, but about memory, grief, identity, truth, or the way people protect themselves from knowledge they are not ready to face.

That is the kind of game I wanted to build: a story-driven adventure that combines riddles, exploration, and emotional consequence. I wanted a game that makes the player think in the practical sense of solving problems, but also in the slower philosophical sense of asking what the world means and what its characters are afraid to know.

The game I wanted to make, and why it felt impossible

For a long time, that kind of project felt unrealistic for one person. Narrative adventure games are content-heavy. They need characters, dialogue, locations, animation, music, sound, interface design, puzzle logic, implementation, testing, and endless revision. Even a short chapter can require a surprising amount of material. A larger game can quickly become impossible for a solo developer, especially one with a full-time career outside the games industry.

That was the wall I kept running into. I could imagine the game. I could describe scenes, characters, and puzzle structures. I could think about the kind of emotional and philosophical experience I wanted to create. But imagining a game is not the same as producing one. The gap between the idea and a playable chapter was too large.

What AI changed, and what it did not

Modern AI tools changed that calculation. Not because they make the game by themselves (they can but I wouldn't want to play them!), and not because they remove the need for taste, judgment, or craft. They changed it because they made certain production bottlenecks, especially around prototyping, less absolute. Used carefully, these tools did not replace the work. They made it possible to attempt the work at solo scale.

The project that came out of this is Where the Arc Falls, a story-rich point-and-click adventure about a girl beneath a broken sky, a boy aiming for the moon, and two civilizations that inherited only half the truth.

From an idea to a playable chapter

The first chapter is now in a fully playable state. The full chapter flow exists from beginning to end, although it still needs testing, bug fixing, and polish. Some systems need stabilization, especially around loading and state restoration. Some timed scenes and patrol sequences need refinement. But the important thing is that the project has crossed the line from idea to playable structure. That is the point where the work becomes different. It is no longer only about imagining the game. It is about testing whether the experience actually works for players.

Why I am documenting the process

This development journal is my attempt to document that process honestly. I am not writing it to claim that AI makes game development easy. It does not. I am writing it because I think there is value in showing what actually happens when a solo developer uses AI tools, Godot, automation, and a lot of iteration to build a commercial narrative adventure game.

Some parts of the process have worked better than expected. Some have failed completely. Some have introduced new problems I didn't anticipate: consistency, scope control, animation quality, production discipline, legal questions, and the simple fact I never shipped a game before, let alone solo.

That is what I want this series to cover. Not only the polished result, but the practical decisions behind it: why certain puzzles belong in the story, how animations are built, how reusable systems are created in Godot, and how feedback changes the game.

The experiment is still in progress

I do not yet know whether Where the Arc Falls will become a commercial success. That is part of the point. The project is still in motion. What I do know is that, for the first time, building this kind of game alone feels possible enough to seriously attempt. That alone makes it worth documenting.

What this series will cover

Future posts will go into the production process in more detail, including puzzle design, Godot systems, visual consistency, playtesting, and the hidden costs of trying to build a commercial game.

The next post will focus on puzzle design, specifically why adventure game puzzles should feel like part of the story rather than escape-room obstacles placed between story beats.

Discussion question

What adventure game, narrative game, or puzzle-driven story stayed with you long after you finished it, and why?

More information about the game can be found on the official Where the Arc Falls website .