At some point after the first proper release of Age of New Worlds, I would like to make the project open source.

Not immediately. Not while the game is still changing shape every week. Not as a way to avoid finishing it. I want the game to stand on its own first: playable, understandable, and coherent enough that someone can experience it as a game, not only as a repository.

But after that, I want to open it.

Because Age of New Worlds has always been more than a private experiment for me. It started as a small project to learn the Apple ecosystem, Flutter, Flame, and the shape of building a game across client and server. Over time, it became a compact 4X architecture study: commands, reducers, projections, fog of war, AI, map editing, multiplayer safety, and a domain model that tries to stay testable.

That kind of project feels worth sharing.

Open Source After the Game Exists

I do not want to open source the game too early.

There is a stage in every project where everything is still negotiation. Names change. folders move. Systems are half-real. Some ideas are experiments. Some code exists only because I needed to learn something.

That stage is useful, but it is not always useful publicly.

Before opening the repository, I want Age of New Worlds to have a stable baseline:

• a playable release,
• a clear project structure,
• working tests,
• documented setup,
• known limitations,
• a contribution guide,
• a license decision,
• a separation between code and assets.

Open source should not mean “here is a pile of files, good luck”. It should mean that another developer can understand what the project is, run it locally, and see where they might help.

Why This Project Fits Open Source

A lot of games are difficult to open because their value lives mostly in private content, custom tools, commercial assets, or proprietary pipelines.

Age of New Worlds is different in an interesting way. The architecture itself is a large part of the project.

The codebase contains questions that other developers might find useful:

• how to combine Flutter UI with a Flame-rendered game world,
• how to keep a renderer from owning game rules,
• how to model commands and reducers,
• how to serialize game state,
• how to build save/load around snapshots and event logs,
• how to prepare a turn-based game for multiplayer,
• how to project server state safely per player,
• how to test bounded contexts,
• how to build developer tools like a map editor early.

Even if someone never ships a 4X game, those problems are interesting.

A game is a very good test of architecture because it refuses to stay simple. UI, simulation, persistence, rendering, audio, networking, and player feedback all meet in one place.

What I Would Open

I imagine the open source project having a shape like this:

age_of_new_worlds/
├── lib/
│   ├── game/
│   ├── map/
│   ├── editor/
│   └── shared/
├── packages/
│   └── aonw_core/
├── server/
├── test/
├── docs/
└── tools/

The most important part would be the code: the Flutter client, Flame renderer, shared core package, server, tests, and editor tooling.

Assets are a separate question. Some assets may be safe to include. Some may need replacement, separate licensing, or a clearer attribution path. I do not want to open source something with unclear rights attached to images, sounds, music, or generated art.

So the code license and asset license may not be the same.

That distinction matters. Open source games often fail here by treating code and content as one thing. They are not one thing.

Open Source as Documentation Pressure

One reason I like the idea of opening the project is that it forces better documentation.

A private project can survive with knowledge living in my head. An open project cannot.

If someone opens the repository, they should be able to answer:

• what is the game,
• how do I run it,
• how do I run tests,
• where does domain logic live,
• where does UI live,
• how do commands work,
• how does the server work,
• how do maps work,
• where should a new feature go?

That pressure is healthy.

It means the architecture cannot only be “obvious to me”. It has to be visible in names, folder structure, tests, diagrams, and documentation.

Contributions Need Boundaries Too

If the project becomes open source, I do not want contribution to mean “anything goes”.

A game needs taste and direction. An architecture needs boundaries. A codebase needs consistency.

So I would want contribution guidelines that explain the project’s rules:

• domain logic should not depend on Flutter or Flame,
• presentation should dispatch commands instead of mutating game state directly,
• server logic should stay Dart-only,
• new gameplay rules should have tests,
• new UI should use shared theme/components where possible,
• multiplayer-visible data must go through projection,
• assets need clear licensing.

This is not about being rigid. It is about making collaboration easier.

Good constraints help contributors avoid accidental wrong turns.

The Test Suite Makes This More Realistic

One reason open source feels possible is that the project already has a serious test layer.

There are tests for domain rules, movement, fog of war, city logic, worker improvements, command serialization, persistence, UI components, architecture boundaries, server projections, and protocol objects.

That matters because an open source game without tests is hard to maintain. Every contribution becomes risky. Every refactor becomes guesswork.

Tests give contributors confidence. They also give maintainers a shared language:

If the rule changes, the test should say why.
If the boundary changes, the architecture test should be updated deliberately.
If multiplayer data changes, projection tests should prove it is safe.

That is the kind of open source project I would want to work on myself.

What I Hope People Could Learn From It

I would love the project to be useful in a few different ways.

For Flutter developers, it could show how Flutter can be used for something more complex than a conventional app.

For game developers, it could show one way of separating renderer, domain, persistence, and multiplayer concerns.

For architecture-minded developers, it could be a practical example of DDD-inspired boundaries in a game, not an enterprise CRUD application.

For modders and designers, the map editor and rules catalogs could become a place to experiment with content.

And for me, it would be a way to keep learning in public.

The Risk

Open source is not magic.

It creates maintenance work. It creates questions. It creates issues. It creates pull requests that need review. It creates expectations.

That is why I want to do it after release, not before. I want the game to have enough identity that public development does not pull it in every direction at once.

The project should become open because it is ready to be shared, not because it is unfinished.

The Goal

My goal is not only to publish code.

My goal is to make Age of New Worlds a readable example of how a compact 4X game can be built with Flutter, Flame, Dart, a shared core package, and an authoritative server architecture.

I want someone to be able to clone the repository and understand the shape of the game.

I want them to see why commands exist, why reducers matter, why the renderer does not own the rules, why projections protect multiplayer, why tests guard boundaries, and why developer tools like the map editor were built early.

If the game reaches that point, opening the source will feel like a natural next step.

Not the end of the project.

A different kind of beginning.