Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Exodus-Protocol: Building a persistent MMO you play through AI

A topic by MOL20K created 33 days ago Views: 331 Replies: 3
Viewing posts 1 to 4

What happens if the main interface of a strategy MMO is not a traditional game client, but a conversation with an AI?

That is the idea behind Exodus-Protocol.

We are building a persistent multiplayer space strategy game where players explore a shared galaxy, colonize planets, build structures, mine resources, research new technologies and eventually command fleets and fight other players.

The unusual part is how you interact with it.

Instead of navigating dozens of traditional game screens, you interact with an AI agent. You can ask what is happening on your planets, request information about resources, decide what to build, inspect the galaxy or eventually give orders to your fleets.


The AI is not the game itself. Behind it is a persistent simulation with its own rules, resources, technology trees, fleets, travel times and other human players. The galaxy continues running whether you are there or not.

On our website we have an indication of what goes on in the galaxy at the moment, keep in mind this is still only us testing, we're not yet open for other players. https://www.exodus-protocol.com/ 

We are also experimenting with mixing conversation and visual gameplay. When a response becomes too complex for text alone, the AI can show interactive visual elements directly inside the conversation: planets, resources, structures, fleets and eventually larger parts of the galaxy.


Another part of the experiment is how we are building the game. We are a very small team using AI throughout development: specifications, coding, testing and parts of the visual-production process. One of the questions we want to explore is how far a small experienced team can push a project of this scale when AI becomes part of the development workflow rather than just an occasional tool. Our goal is to share as much knowledge as we can through posts on our website. This is not only about the usage of AI, but also about gameplay challenges we're facing.

We are still very much in development. At the moment we already have the persistent galaxy, planets, resources, mining, structures and a large part of the progression system working, and we are now moving deeper into units, fleets and combat.

I’ll use this devlog to share the progress as we build it: new systems, experiments that worked, things that failed, design decisions and some of the technical challenges behind making an AI-driven MMO actually work.

AI in game development is an interesting and sometimes controversial topic. Whatever your view on it, we believe these tools are going to become an increasingly important part of how games are built.

That is one of the reasons we started Exodus-Protocol.

The project is not only about creating a type of game we have not really seen before. It is also about documenting the journey: what AI makes possible, where it falls short, what changes in the development process, and what we learn along the way.

Whether the project will ultimately succeed is still unknown.

The bigger question for us is:

"Can a conversation with AI become a real game interface rather than just a gimmick?"

That is what we are trying to find out, keep you posted!

(2 edits)

Balancing a fleet without making one ship the obvious choice

Make a bomber tough enough to threaten capital ships, and you risk making it too tough for the light ships that are supposed to counter it.

That’s one of the balancing challenges we’ve been working through in Exodus-Protocol. Our ships and combat structures follow a rock-paper-scissors-style design: different strengths, different weaknesses, and reasons to build more than one type of unit.

Our latest development work includes additional gameplay testing and a rework of combat logic, with separate approaches for attacking and defending fleets.

To test balance without spending all our development time setting up battles, we’ve connected AI agents to our battle simulator. We still use its visual playback to inspect individual fights, but agents handle much of the repetitive setup and simulation work. Around 5,000 simulations have helped us tune the base statistics of ships and structures.

We compare performance against resource cost, construction time and the actions a unit can take. We also repeat matchups with different random seeds, rather than treating one lucky victory as proof that a ship is balanced.

Alongside those simulations, gameplay agents build empires and report potential bugs. This reduces the manual workload and makes repeated testing more manageable for a small team.

The aim isn’t to make every matchup equal. It’s to preserve useful strengths and meaningful weaknesses, including when upgrades enter the picture. The agents help us explore the numbers; deciding whether the resulting choices are interesting remains our responsibility.

More about the process and what we’ve learned:

Using AI to test our game, not just build it

https://www.exodus-protocol.com/journal/using-ai-to-test-our-game-not-just-build...

More upgrades should mean more interesting choices, not one obvious winning combination. That’s what we’re working toward with the module system in Exodus-Protocol, our persistent multiplayer space strategy game played through an AI assistant.

This week, we’ve reworked the implementation so we can more easily configure local or global effects. We now support up to 20 effect types, allowing modules to provide benefits, introduce drawbacks or combine several effects. The challenge is making those choices worthwhile without removing the weaknesses that give ships and defensive structures their roles. We want modules to support different strategies, rather than make the same upgrade path the best choice for everyone.

The implementation is in place, but balancing is still ongoing.


We’re also aiming to begin beta testing in the coming weeks. Next week, we’ll continue tuning the game and start creating an introduction video. 

Preparing to let people play has brought up another concern: exposing the experience before we’ve had a chance to establish it. Could someone use AI tools to imitate the core mechanics, create something simpler and reach an audience before us? We want player feedback, not endless development behind closed doors. But we’re interested in how other indie developers are weighing that risk.

I’ve written about our thinking in:

The Dark Side of AI: When Anyone Can Copy Your Game
https://www.exodus-protocol.com/journal/the-dark-side-of-ai-when-anyone-can-copy...

Has the risk of AI-assisted copying pushed you toward smaller, closed playtests, or are you still comfortable showing your game early?

I would start with a small closed test built around one question, like whether people can give fleet orders without help. That gets you useful feedback before you need to expose every upgrade and combat rule