Millions use ChatGPT. How many would want to play here?
Hundreds of millions of people use ChatGPT. But is there a large enough audience among them for a deep, persistent multiplayer game played directly inside the ChatGPT interface?
That’s a question we keep coming back to while building Exodus Protocol.
We are building a space strategy MMO where you develop colonies, research technologies, command fleets and form alliances through conversation with an AI assistant.
Not a quick mini-game or an improvised story, but a shared galaxy with other human players, long-term decisions and consequences that persist when you log off. ChatGPT is your interface; our backend runs the world and enforces its rules.
The opportunity is exciting, but we don’t assume that a huge platform automatically means an audience for our game. Are we reaching people who would enjoy a different way to play, or building for a niche within a niche? We have a hypothesis, not an answer: an AI assistant could make complex strategy more approachable without taking the decisions away from the player.
AI is also part of how we build the game, from specifications and code to artwork. We’ll aim to share a short update here each week: what we’re working on, decisions we’re weighing, and what worked or didn’t. Each post will include a question or challenge for the community to discuss.
Would you play a strategy game this way? What would make you return, rather than try it once out of curiosity?
For more complex responses, we can also return visual elements inside the conversation instead of relying only on text.
So the core idea is starting to work: ChatGPT becomes the game interface, while our backend runs the persistent world.
One thing we are still struggling with is app versioning. We haven’t found much clear documentation on how updates to a ChatGPT app should be handled once users are actively using it.
Has anyone here already dealt with versioning of ChatGPT apps? Any advice, patterns or documentation we should look at?
Last week we mainly focused on reducing how much data gets loaded when opening a conversation.
Because the richer parts of Exodus-Protocol run inside iframes, longer conversations can easily cause the same images, scripts and other assets to be loaded repeatedly across multiple embedded elements.
We improved this in several ways:
added more caching
reduced asset sizes, especially images
optimized the JavaScript bundle so the initial index is smaller
added lazy loading so only web elements currently in view are loaded, instead of loading everything further up in the conversation
The result is a much lighter experience, which becomes increasingly important as more visual game elements start appearing throughout the chat history.
We still don’t have a satisfying solution for versioning ChatGPT apps, so that remains an open item for us.
On the game side, we’ve now started implementing ships. The next area we want to explore is whether AI agents can also help us test the application, rather than only helping us build it.
We’ve also started using the Exodus-Protocol website for longer write-ups about some of the broader lessons we’re learning while building the project.
Two recent topics are:
Designing websites that AI tools can understand as well as human visitors — looking at what changes when AI becomes another consumer of your website, rather than only a tool used to build it.
Using threats and player interaction as a gameplay mechanic — exploring how negotiation, pressure and conflict between players can become part of the game systems themselves.
The weekly posts here will stay short and focused on progress, while we’ll use the website for the topics that deserve a deeper explanation.
This week we mainly focused on extending the Exodus-Protocol management portal, which we use to tweak and tune the game.
We added a visual editor for building tech trees, as well as configuration for effects on structures and individual structure levels. That fits directly into the progression model we are building around structures, technologies, modules and units.
The more interesting learning, though, is about how we build it.
We use an Atomic Design + Storybook approach: first building atoms, then molecules and larger components in isolation, and only after that combining them into complete management screens.
Combined with AI-assisted development in Visual Studio, this is working surprisingly well. We are able to produce structured, reusable and maintainable frontend code while doing very little of the actual coding ourselves.
But there is an important catch: AI works much better when you already know exactly what you want to build.
Our current workflow is increasingly becoming:
Functional specification → technical specification → small implementation tasks
We deliberately keep those implementation tasks small enough to fit comfortably within the model’s context. When we try to solve too much in one go, the quality and maintainability of the result drops quickly.
Our AI agents are now playing, testing and helping balance the game
This week, we’ve focused on more gameplay testing for Exodus-Protocol and reworked the combat logic, separating the approaches used by attacking and defending fleets.
One useful development has been giving AI agents their own player accounts and asking them to play through our application’s text interface via MCP.
They explore, build, colonize and fight. But they also check server responses against our functional specification. When construction takes time, an agent schedules a return visit around the estimated completion time to check the result. Potential bugs are reported with reproduction steps, timestamps and relevant IDs.
The agents also update their own Markdown knowledge files with what they learn, so future sessions can build on previous discoveries. We review their reports weekly, because an unexpected result can still be a misunderstanding rather than a bug.
Separately, we’ve exposed our battle simulator through an administrative MCP interface. Agents can run simulations, adjust statistics and compare outcomes against our balance targets. Around 5,000 simulations have helped us tune the base statistics so far.
This sits alongside our existing unit and browser tests, rather than replacing them. The biggest benefit is spending less time operating tests and more time deciding what the results mean.
We’ve written up the workflow, including real bugs and false positives, here:
