🧩 Post #6: Simulation Code Architecture and Modular Namespaces

Genesis of Infrastructure — Entry #6
By Emergent Dynamics, building Colonies: Genesis of E.D.E.N.

---

If version control is the spine of your infrastructure, modular architecture is the nervous system. It keeps everything organized, predictable, and extensible.

In this post, we’ll show you how Colonies: Genesis of E.D.E.N. is built using namespace-driven code organization and why it’s essential for simulation-scale systems.

---

🗂️ Folder Structure: Simulation First, Unity Second

We split our project into two primary zones:

Assets/
├── External/                  ← All simulation modules live here
│   ├── Eden.Core/
│   │   └── World/
│   ├── Eden.Definitions/
│   ├── Eden.Simulation/
│   ├── Eden.Unity/            ← Unity-facing bindings
│   │   ├── UI/
│   │   │   └── Builder/
│   │   ├── World/
│   │   └── Tools/
│   └── Eden.Tools/
└── Scenes/, Prefabs/, UI/     ← Unity project roots

🧠 Why? Because Unity is just the front-end. The simulation must be clean, testable, and reusable without it.

---

🧭 Namespace Conventions

Each subfolder maps directly to a namespaced module:

Assets/External/Eden.Core/World        → Eden.Core.World
Assets/External/Eden.Unity/UI/Builder  → Eden.Unity.UI.Builder

This structure provides:

• Zero ambiguity about where a class lives
• Natural IntelliSense and autocomplete hierarchy
• Strong boundaries between systems (e.g., Eden.Core.Mathematics has no Unity dependencies)

---

🧱 Modules Are Autonomous

Each module:

• Has its own .asmdef file
• Can be tested independently
• Only references what it needs
• Uses interfaces (IDefinition, ITickable, etc.) for extensibility

For example, Eden.Core.World simulates planetary surfaces.
It doesn’t care if Unity exists.
Eden.Unity.World binds that simulation to Unity for visuals.

---

🧰 Unity Is a Layer, Not a Core Dependency

Unity-related code exists only under Eden.Unity

This means:

• All simulation logic is portable and testable outside Unity
• CI can run headless builds with no graphics overhead
• The simulation can one day run server-side, cloud-native, or embedded in tools

---

📐 Practical Example: Wind Vector System

Here’s how the new wind system might be split:

File	Purpose	Namespace
WindVector.cs	Core wind simulation logic	Eden.Core.Weather
WindVectorVisualizer.cs	Unity rendering logic	Eden.Unity.Weather
WindOverlayDefinition.json	Data config	Eden.Definitions

Each part lives in its own module. Each is testable.
None of them are tangled together.

---

🧠 Why This Matters for Simulation Games

Colonies is not a typical game.
It’s a multi-layer simulation platform with systems that include:

• Celestial mechanics
• Geodesic climate models
• Trophic ecosystems
• Faction memory
• Orbital logistics and manufacturing

Without strict modular boundaries, these would quickly turn to chaos.

---

🏁 Summary

✅ Folder = Namespace
✅ Unity = external view layer, not logic core
✅ Each module has .asmdef, minimal dependencies
✅ Unity folders are nested under Eden.Unity/*
✅ Namespaces build trust in system stability

---

⏭️ Next Entry: Resource and Reaction Definitions — Powering Everything with JSON

Colonies is a definition-driven simulation.
In Post #7, we’ll explore how resources (like water, biomass, heat) and reactions (like evaporation or crafting) are stored in data — not code — using our IDefinition system.

You’ll see how this powers emergence, modding, and the adaptability of the engine.