The MonoRpg Project: Building a Framework While Building a Game

This article introduces the MonoRpg project and its core philosophy: building a reusable game framework in tandem with a commercial game to ensure every feature is practical, tested, and immediately valuable.

Many game developers dream of building their own game framework—a powerful, reusable foundation for all their future projects. But building a framework in a vacuum is a classic trap; without the concrete demands of a real game, it’s easy to get lost in building features I think I’ll need, only to find they don’t fit a real-world use case.

This article introduces the philosophy behind the MonoRpg project, which tackles this problem head-on. I am simultaneously developing two things:

1. MonoRpg: A reusable 2D RPG framework built with C# and MonoGame.
2. AetherDraw: A commercial 2D trading-card RPG that serves as the first “customer” of the MonoRpg framework.

This symbiotic approach ensures that every feature built into the framework is practical, tested, and immediately valuable.

Why Build a Framework at All?

In a world with powerful, off-the-shelf engines like Unity and Unreal, why build your own? For me, the answer lies in control, performance, and long-term reusability.

The MonoRpg framework is designed to be a lightweight, modern, and highly-optimized foundation for 2D RPGs. By building it myself, I gain:

• Full Architectural Control: I can implement clean, scalable patterns like a three-layer architecture and an Entity Component System (ECS) without fighting against a black-box engine.
• Performance by Design: I can build highly performant systems, like my prerendered tilemap pipeline, that are tailored specifically to the needs of a 2D RPG.
• True Reusability: Once AetherDraw is complete, the MonoRpg framework will be a mature, battle-tested asset that can be used to kickstart my next RPG project, saving months or even years of development time.

The Symbiotic Relationship: Framework and Game

The core principle of the project is that the framework drives the game, and the game drives the framework.

• AetherDraw needs a feature. For example, it needs a flexible dialog system that can handle interactions with moving NPCs.
• I design and build that feature in the MonoRpg framework. I don’t just build a dialog system for AetherDraw; I build a reusable RPG dialog system within the framework’s RPG layer (MonoRPG.RpgFramework).
• AetherDraw implements the feature. The game-specific project (AetherDraw) then uses the new, generic system to implement its specific dialog content.

This ensures that the framework never becomes a purely academic exercise. Every system—from the rendering pipeline to the entity spawning logic—is built because the game needs it. This forces us to solve real problems and avoid over-engineering.

The Four-Layer Architecture in Action

This separation is made possible by a strict four-layer architecture:

1. The Core Framework (MonoRPG.Framework): The game-agnostic core. It knows nothing about RPGs, only about rendering sprites, handling input, and managing an ECS.
2. The RPG Framework (MonoRPG.RpgFramework): The reusable RPG layer. It contains systems common to most RPGs, like level management (LDtk), dialog controllers, and quest infrastructure. It knows nothing about cards.
3. The TCG Framework (MonoRPG.TcgFramework): The reusable card game layer. It defines what a card is, how decks work, and the rules of turn-based card combat. It knows nothing about AetherDraw’s specific cards.
4. The Game (AetherDraw): The final product. It contains all the unique content, rules, and logic for my specific TCG-RPG, built on top of the other three layers.

Dependencies only flow one way: Game → TCG Framework → RPG Framework → Core Framework. This enforced separation is what makes the framework truly reusable.

Conclusion: A Pragmatic Approach to Framework Building

Building a game framework alongside my first game is a challenging but incredibly rewarding approach. It forces pragmatism, ensures every feature is battle-tested, and leaves you with a valuable, reusable asset at the end of the development cycle.

This article is the first in my “Building the MonoRpg Framework” series. In the articles that follow, I will dive deep into the specific systems I’ve built, from the four-layer architecture and rendering pipeline to the entity spawning and dialog systems that bring the world of AetherDraw to life.