-
Notifications
You must be signed in to change notification settings - Fork 0
FAQ
Common questions about RealmEngine's design, technology choices, and project scope.
Not yet — it's a fully functional game engine backend. Almost all game systems are implemented (19/20, 95% complete), but the frontend/UI layer is separate. The engine exposes everything via MediatR commands and queries that a UI layer calls into.
RealmEngine is UI-agnostic — it has zero UI framework dependencies and exposes everything via MediatR commands and queries. Any .NET application can call mediator.Send(command) to consume it.
The official clients built in this repository both use Avalonia:
- Veldrath.Client — cross-platform desktop client for the multiplayer game
- RealmForge — Postgres content editor
External consumers like Godot (via GDNative), Unity (via C# scripting), or a custom console app are fully supported by the architecture — they just aren't actively developed here.
Yes. The architecture is deliberately generic — you'd populate the content catalog with your own data and tune the systems for your game. The engine is MIT licensed.
RealmEngine is a logic layer, not a rendering engine. The goal is clean, testable, portable game rules that can be consumed by any frontend. .NET gives us excellent tooling, nullability guarantees, a rich testing ecosystem, and easy Godot GDNative integration.
Three reasons:
- Clean separation — Commands change state, Queries read state. No service classes that do both.
- Pipeline behaviors — Validation, logging, and error handling attach to every operation automatically without touching handler code.
-
Consumer-agnostic — any .NET UI layer calls
mediator.Send(command)and gets back a typed DTO. No need to expose internal services.
Cross-platform. Avalonia runs on Windows, macOS, and Linux. WPF is Windows-only. Since the server runs on Linux (Docker), having a matching Linux-compatible client matters.
Game content (weapons, armor, spells, abilities, etc.) lives in a PostgreSQL database via EF Core's ContentDbContext, with a full migration history. Save data (character saves, inventory records, hall-of-fame entries) is stored in a separate GameDbContext. Both use EF Core's InMemory provider for tests — no database required to run the test suite.
This approach gives the engine typed entities, queryable indexes, and schema migrations, and lets RealmForge read from and write to the same content catalog the engine queries at runtime.
Each test project mirrors its source project. This means:
- CI can run engine tests without pulling in client/server dependencies
- Test isolation — a failing client test doesn't block an engine release
- Coverage is reported per component (engine, client, server, forge)
A few ViewModel methods (like DoRegisterAsync) are internal to prevent external callers from bypassing the CanExecute guard on ReactiveCommand. Tests need to call them directly to cover defensive guard branches. InternalsVisibleTo gives the test project access without making the API public.
It's a git submodule pointing to the GitHub Wiki repository. This lets wiki pages be edited either directly on GitHub or via a normal code editor with version history.
Yes. Because RealmEngine exposes everything through MediatR commands and queries, any .NET-capable consumer can integrate it. For Godot, you'd add the engine DLLs as a plugin and call mediator.Send() from C# scripts via GDNative. The same pattern works for Unity, a console app, or any other .NET host.
A dedicated Godot or Unity project is not included in this repository — the focus here is the engine itself and the official Avalonia-based clients (Veldrath, RealmForge).
Not yet — it's in active development. The server and client build and run, character creation works end-to-end, and the SignalR hub connects. Full gameplay loop support is in progress.
Open a GitHub Discussion or file an issue.
Home · Getting Started · Contributing · FAQ
Characters & Progression
Combat
Items & Economy
World & Content
Extensibility
Regions & Zones