A Plan for Building Games

Opening#

I think this also calls for an explanation of why games.

To be honest, there is no grand reason. Stories about writing code faster with AI are already common. I think many people are already feeling that change themselves. Game development began from a somewhat indulgent question: what can I actually turn into something shippable?

In the past, this was an area you could not easily step into even if you looked only at development and operations resources. Now it feels like the era has changed enough that you can start without overthinking it. On top of that, building something I can enjoy myself, and doing development that feels closer to a hobby than a job, also feels somewhat romantic.

That introduction got longer than expected. In this post, I want to talk about the game genres I plan to pursue and why I chose this direction.

Implementation Order

Why Start with Story Quiz#

The first genre I chose was Story Quiz. It is a visual-novel-style structure where the story unfolds and the player gains experience by solving deduction questions in the middle or at the end. The reason I chose this genre first is simple. The center of the fun is clearly the story and the deduction, while the operational burden can be kept relatively low.

AI does not need to go everywhere here. I actually think that point matters. In Story Quiz, I want AI to stay close to grading and production support, while the play experience itself remains on top of rules and direction designed by people. That way operations do not spiral out of control, and at the same time I can test a model where writers publish their own work.

It is still early, but the implementation direction is already moving that way. Instead of dropping manuscripts directly into the database, I want to optimize AI for story production through a pipeline that goes from markdown manuscript → parsing → script enhancement → prompt generation → translation → import.

source.md
-> parse-episode.py
-> script-doctor.py
-> prompt-gen.py
-> translate-story.py
-> /bo/story-quiz/games/import

How Far Has Story Quiz Been Implemented#

Based on the current repository, Story Quiz has moved a little beyond the pure idea stage. On the player side, there are already APIs that connect game list and detail views, session creation, resume, answer submission, and epilogue lookup. In the back office, there is a structure that separately manages games, characters, phases, blocks, quizzes, and background assets. On top of that, there is already a flow for importing and exporting full game data as JSON, so it is beginning to be treated not as a single game but as a publishable content format.

The important point is that this genre is growing with a separation between content data and play sessions. A single game is split into characters, phases, blocks, quizzes, and background assets, while a session separately manages the current phase, the current quiz, used hints, score, and progress state. In other words, the flow where an author edits a work and the flow where a player consumes it are already being separated into different layers.

Grading follows the same philosophy. Objective questions are graded immediately, while subjective questions are handled through separate strategies and back-office review flows such as KEYWORD_ONLY, LLM_ONLY, HYBRID, and MANUAL. What matters to me is not that AI is always right. What matters is a structure where only problems that can be handed to AI are handed to AI, and everything else remains available for human review.

The delivery layer is also being organized for the publishing experiment. Cover and card images are delivered through public source paths and preset-based thumbnails, and Asset Studio is set up so that character and background assets from Story Quiz and Mystery can be managed together. In the end, Story Quiz is both a game and the first testing ground for a work-production, review, and publishing pipeline.

Why the Next Step Is Mystery#

If Story Quiz is closer to a structured experience designed by an author, Mystery is a much more dynamic genre. Players do not stop at reading clues. They take roles, talk, suspect each other, and continuously update the situation. It is a niche genre, but if it lands well, the depth of engagement can become much greater.

And this is exactly where the share of AI becomes much larger. In Story Quiz, it is fine to use AI in a limited way, but in Mystery, areas like NPC reactions, interrogation, hint assistance, and scenario reinforcement are much closer to the core experience. I see this genre as the second stage, where AI enters the play experience in earnest.

How Far Has Mystery Been Implemented#

Because I have been working on multiple tracks at the same time, Mystery has also already reached a point where you can see a small prototype with your own eyes. The platform APIs already connect scenario lookup, session creation and invite-code join, ready state, start, phase transition, notes, items, and interrogation records. Sessions are managed around tickets, invite codes, player lists, and state transitions, and data such as starting items, starting notes, and starting interrogations is attached separately. In other words, the session model needed to actually run a round is already in place first.

The production side is even more interesting. Mystery has a back-office flow called Draft Scenario, and the generation stages are split into CONCEPT → TRUTH → CHARACTERS → TIMELINE → CLUES → ROLEPLAY → WORLD_BUILDING → SYNOPSIS → PROLOGUE → EPILOGUE. This is not simple text generation. It is a way of treating the answer, motive, character relationships, alibis, clues, and role reactions as separate nodes. I think that structure matters. In Mystery, logical consistency has to come before stylish sentences.

The real-time dialogue side also already has a skeleton. The game session chat APIs include character dialogue, SSE streaming responses, and an AI assistant chat, and every conversation is stored in interrogation history. That means the structure is not one where AI simply throws out answers. It is designed so that the conversation accumulates as memory inside the session. This is the area where AI dependency is likely to rise the fastest.

Why MMORPG Is the Last Challenge#

MMORPG is tied for me not only to technical curiosity but also to personal nostalgia. I wanted to test how far I can recreate something with the feel of Lineage, which I used to play for a long time, using today's tools and structure. If it eventually reaches commercialization, that would be ideal, but before that, the more important question comes first: how far can a genre this heavy be pushed with the current way of developing?

I also think that, for MMORPG implementation, many of the systems mentioned above can later be reused or adapted for worldbuilding, story, and NPC setup.

Isn't MMORPG Too Hard to Build#

Surprisingly, the current mmorpg-service already has a fair amount of spec-driven code generated. The current level of coding agents is honestly beyond whatever you imagine. With only a few prompts, both the client and the server of a real-time MMORPG can be generated.

The game is planned in a form similar to Lineage, which I enjoyed playing, and on the server side a Netty-based gateway, session manager, Redis session synchronization, duplicate-login handling, world and zone creation, tick scheduler, maps and pathfinding, AOI synchronization, combat broadcasting, inventory and shop flows, and drop and spawn flows are already implemented and deployed as a separate service.

On the runtime side, GameWorld manages multiple Zones and attaches players by separating session and world indexes. Monsters are managed not as simple spawn objects but as runtime entities with FSM states such as IDLE, PATROL, CHASE, ATTACK, RETURN, and DEAD. The trigger system directly executes world reactions such as trap damage, spells, dialogue, and chat. On top of that, there is even a WorldContinuum that persists world time and weather separately.

Let's Build a Ladder#

Story Quiz is a genre for experimenting with publishing works under low operational burden. Mystery is a genre for experimenting with role-based deduction where AI enters the play experience. MMORPG is a genre for testing how far the current development method can go in the heaviest kind of real-time world.

That is why these three are not separate projects but parts of a single ladder. I want to establish the production pipeline and review structure in the lightest genre first, then increase the density of AI interaction, and finally climb all the way to a real-time world.

In the end, the question I want to answer is simple. It is not whether AI lets us make games faster. It is where AI has to be placed so that a game can still remain something humans are responsible for until the end. For me, making games in Omnilude is the most serious way of running that experiment right now.

Closing#

In the earlier posts, I talked about changes in coding style and backend structure. This post is closer to an answer about what kinds of games I am actually making on top of that structure, and in what order.

Next time, I want to narrow the focus further and explain in more detail either how the publishing pipeline for Story Quiz actually works, or how I am designing the AI interrogation structure for Mystery.