Modular Game Architecture: How AAA veterans structure Godot projects

When Ricard, a former lead programmer at Crytek, set out to build a 40+ hour CRPG with his team at Epictellers, they spent six months creating a demo to test if Godot could handle their project. The result? Not only did Godot prove capable; they discovered they could build the entire game using GDScript.

This lead them to make Starfinder: Afterlight, which was one of 2025's most successful projects on Kickstarter.

Pre-alpha screenshot of Starfinder: Afterlight courtesy of Epictellers

Ricard kindly got in touch with us to share how he applied his experience as a AAA lead programmer at Crytek to structure their Godot project.

At the time of writing, the team is composed of 15 people, and the studio is looking to grow to 25-30 developers. They've implemented a compartmentalized architecture that allows them to work efficiently on a large codebase while making future games and expansions much easier to build.

In this study guide, you'll get an overview of their modular architecture and what you can take away for your own projects. You'll learn:

• How a game industry veteran structures a large Godot project to support a team of dozens of developers
• Why strict separation of code concerns becomes more and more valuable as teams grow
• How to adapt these insights to smaller teams

The four pillars of Epictellers' modular architecture

When you're building a game that will take tens of people years to complete, code organization isn't just about keeping things tidy; it's about preventing issues and enabling code reuse. Ricard learned this lesson from his years as a lead programmer at Crytek, where poorly structured code means bugs and throwing away hard work when moving on to the next project.

At the heart of Epictellers' approach lies a simple principle: no code should depend on other code it doesn't need to know about.

This philosophy is implemented in a strict folder structure that forms the backbone of their project code architecture.

There are four key folders the team uses to enforce clear boundaries between different parts of the codebase. Each folder serves a specific purpose and, more importantly, follows strict rules about what can depend on what: game-specific content, levels, and scripts depend on game systems, which depend on general-purpose code libraries.

Here are the four main folders in short:

• Add-ons: Libraries made in-house for tools and APIs that work in any 3D game
• Systems: Core game rules and mechanics that define how your game plays (like your combat system or game-specific character movement and pathfinding)
• UI: User interface code that reads from the game systems and displays information but never controls or writes anything
• Content: The actual game assets, dialogues, quests, and level-specific scripts and events

This separation ensures that the content folder can be replaced at any time without breaking the user interface or game systems. It means that when Epictellers makes a new game, they can copy everything except the content and be ready to work immediately.

Let's explore how each of these four pillars works.

Addons: A reusable foundation of libraries

The team populates their add-on folder with many in-house code libraries containing game-agnostic code. Think of these as a toolbox: input helpers, camera controllers, data structures, algorithms, and other utilities that could work in different kinds of games. It's all the code that's not specific to their CRPG but will be useful across projects.

Why make everything in-house and not use community add-ons?

When you have a team of experienced developers, it can be both faster and more reliable to create your own code libraries than to use community-made ones.

You need to carefully evaluate and test third-party tools before using them in a professional project. Also, with free and open-source add-ons, you can't be sure they'll be kept up to date in the future or that they're thoroughly tested for stability and performance. You have to carefully read the source code to ensure it meets your standards.

By making your own libraries, you ensure that they follow your team's coding standards, are well-documented, and meet your exact needs.

Systems: Where the game core rules live

The systems folder is where the magic happens. This contains all the game rules: AI behaviors, combat systems, the game state manager... These systems use the libraries but remain independent of the user interface and specific game content. Every system and mechanic that isn't directly tied to a specific game level or single quest lives here.

UI: Completely isolated user interface

The UI folder breaks a common gamedev anti-pattern for larger projects. Instead of UI code that reaches deep into game systems, Epictellers' UI widgets only receive and display data. They never modify game state directly or contain game logic. This isolation means you can completely overhaul your game's UI without touching a single line of gameplay code.

Use this mindfully

If you're a solo indie developer, keep in mind that this separation isn't strictly necessary and has a cost in terms of complexity. If you're building a small game, it's fine to have your UI tied directly to game characters or systems: it'll make the code much faster to write and edit.

As your team and production costs grow, however, separation becomes more valuable as it helps to avoid bugs when devs collaborate and makes it easier to change the UI or game systems without breaking anything.

Content: Where your game lives

Finally, the content folder contains everything specific to this particular game: quests, dialogue, levels, characters, and all the associated scripts. Here's the key part: systems never depend on content. The dependencies only flow one way: content uses systems, systems use libraries, UI uses systems, but nothing else depends on content.

This one-way dependency flow isn't just about being tidy; it's what enables modularity. You can swap out your entire game's content while keeping the same systems, build expansions, or create multiple games on the same foundation.

Godot's own architecture mirrors this principle

The Godot engine itself uses a similar architectural principle. The engine's core does not depend on higher-level systems like nodes; it's the opposite. Similarly, while the editor and engine core live in the same codebase, they are separated by a clear boundary. This is notably what allows released Godot games to have no editor code shipped with them. That's also in part why you can easily strip engine features that are not needed in a specific game to reduce the final game's size.

The "gyms" folder: A sandbox for experimentation

Here's a challenge every structured project faces: having rigid architecture can hurt creativity and slow down prototyping. When you need to test a new idea or mechanic, the last thing you want to worry about is writing perfectly compartmentalized code because it takes time.

Epictellers solves this with their "gyms" folder. Each team member gets their own subfolder where they can experiment, code prototypes, and test ideas without following any conventions. These folders are automatically excluded from game builds, so there's no risk of experimental code shipping to players.

How the gyms system works in practice

When a dev at Epictellers wants to test a new combat ability, they create a quick prototype in their gym folder.

It's checked into the project's version control system so other team members can test it and give feedback. Once everyone agrees the feature is solid, it gets refactored and properly implemented following the project's coding standards. Otherwise, it can be deleted safely.

Applying this to your own team

Not every project needs Epictellers' level of structure. As I've mentioned, they have dozens of people, and that's not the case for most of us. Here are some tips to adapt Ricard's insights to your team size:

I'm a solo indie

If you're working solo, you can focus on separating your content from game systems. Even a simple division between "game mechanics" and "level-specific code" will help when you want to reuse code in your next project. You don't need to worry about strict conventions. It's enough to keep things organized and clear for yourself so you can find them later.

My team is small (2 to 5 people)

For a small team, it's worth adopting the basic folder structure (libraries, systems, UI, content) and establishing simple naming conventions. You can write a script that quickly checks filenames and file locations every time someone makes a commit; it's a simple way to help the team keep modules organized.

I have a medium to large dev team (more than 5 people)

This is where Epictellers' full approach starts paying dividends. You have enough people that dedicating one person to implementing detailed automated checks is well worth it. At this size, the overhead of structure is quickly offset by the increased clarity of the codebase and how easier it is to onboard new teammates.

Should I implement this architecture from day one?

I'd start simple and add structure as you validate your game concept. Early in development, you want to prototype and iterate fast to figure out what exactly you're building. Once you know you're building something substantial, that's when a more constrained architecture becomes an investment in your future productivity.

Just like Epictellers has this "gyms" folder for prototypes and experimentation that they use before committing and adapting code to stricter guidelines.

updates / code patches

• Suggest an update.
• No errors reported. Report an error.