RogueLegacy1: source only, no assets, and a build that needs FNA

What is deliberately missing

The README states the scope in unusually direct terms: this is the source code for Rogue Legacy, more specifically only the code, and only the FNA build. The assets and content project are not included.

That single sentence removes most of what a buildable game repository normally contains. There is no art, no audio, no level data and no content pipeline project. It contains only the FNA build described in the README.

The licensing position follows from the same practicalities. The source is released under a specialized, non-commercial-use license documented in LICENSE.md at the repository root, and the README points at that file for details rather than summarising the terms. The top level also carries an EXCEPTIONS.md, which is consistent with a release that carves out specific components rather than granting a blanket permission. Read both files before you plan anything with this code.

The licence is listed as Other, a custom licence GitHub cannot classify, so no automated tooling will tell you what is permitted.

Two recursive clones, then dotnet build

The build instructions assume you already have the game. First step is to download this repository and FNA with its submodules, and the native libraries are a separate download:

git clone --recursive https://github.com/FNA-XNA/FNA.git
git clone --recursive https://github.com/flibitijibibo/RogueLegacy1.git

The README supplies both clone commands with the `--recursive` flag.

After that, the build is a single command:

dotnet build RogueLegacy.sln

The output lands at `RogueCastle/bin/x64/Debug/net40/`, which tells you three things at once: the executable is x64, the configuration is Debug, and the target framework is.NET Framework 4.0. That last one is the constraint people trip over. This is not a modern.NET project, so the `dotnet` CLI on a current Linux or macOS machine will need additional runtime support to build and run it, and the FNA documentation linked by the README is the place to find out how.

The native libraries come from the fnalibs-dailies repository, which is where the README points for the latest builds.

The manual step that decides whether the game runs

Even after a successful build, the README asks for manual file copying, and these are the steps that make the difference between an executable that starts and one that does not.

The Content folder has to be copied from your personal copy of the game into the output folder. This is the assets step the README warned about at the top, and it is why owning the game is a prerequisite rather than an optional extra. The build produces code, not content.

Second, the native libraries matching your OS and architecture go next to the executable. The README gives the Windows case explicitly: copy `fnalibs/x64/*.dll` next to RogueLegacy.exe. On other platforms you pick the equivalent set for your architecture.

Only after both does the game start, in the README's phrasing. This is worth internalising as a pattern: the repository is a code drop with a documented manual assembly step, not a turnkey build. Anyone automating it needs to script both copies.

A related detail sits in the root directory listing. Alongside the solution and the project file there is `rd.xml`, which is a runtime configuration file, hinting that the build carries explicit runtime behaviour settings worth looking at if your .NET version disagrees with the project about how the application should run.

What the directory layout tells you about the architecture

The top level is small enough to read as a map of the game. `RogueLegacy.Core.csproj` and `RogueLegacy.sln` are the build entry points, with the executable output under `RogueCastle/`, which is the working name the game shipped under.

Four directories describe distinct subsystems. `DS2DEngine/` is the engine: 2D sprite, sound and content framework work, which is the part that a game of this era builds itself. `SpriteSystem/` handles sprite handling and drawing. `InputSystem/` is input, abstracted away from whatever the platform provides. `Tweener/` is tweening, the interpolation library used for animation curves and transitions.

The presence of `.vscode/` in the root indicates the project is edited in Visual Studio Code rather than Visual Studio, and `.github/` holds the repository's automation. Nothing here suggests a test project, which for a game source drop of this size is unremarkable.

Taken together, the layout describes a self-contained 2D engine with the rendering, input and animation layers separated from game code. That separation is the practical reason the source is useful to read at all, since the interesting part is how the systems talk to each other rather than the content that is absent.

The editor gap, and what it means for modding

The level editor is a separate repository, RogueCastleEditor, linked from the README. What follows is the part that matters for anyone planning to make content:

The README states plainly that the original editor used to make Rogue Legacy is no longer compatible with the latest version of the game.

So the toolchain has a hole in it. You can build and modify the game code, and you have the original editor, but the editor cannot round-trip current game data. That constrains what modding looks like: code changes are open to you, level content changes are not, unless you reverse the format yourself.

This is also the clearest signal about the release's purpose. It is a source code release for study and code modification, not an open content pipeline. The README's own framing is narrow and consistent, and the missing assets, the non-commercial licence and the broken editor all point the same way.

The homepage points at the official game page at cellardoorgames.com, which is where the commercial product lives, and the repository has no GitHub releases at all. The last push was on 2026-07-15, so the code tree is not frozen but is also not receiving visible release tags.

Against a modern engine port and against modding frameworks

If your goal is to make a game in this style today, this repository is a reference rather than a foundation, and there are two other routes.

One alternative would be a modern engine port, but the README does not compare this source code with other engines.

The second would be an existing modding framework, but no such framework is identified or documented in the README.

The distinction between the two is worth being clear about. Rebuilding from this source means owning the assets and accepting a manual assembly step. Patching means neither, but works only within the game's existing structure. The repository supports the first path and, through the broken editor, explicitly not the second.

Editorial conclusion

Use this repository if you want to read or modify the gameplay code of Rogue Legacy and already own a copy of the game, since the missing Content folder has to come from there. Do not treat it as a runnable open source project: the licence is non-commercial, the assets are absent, and the linked level editor is stated to no longer work with the latest game version. Verify first that your toolchain matches the FNA recommended environment before expecting `dotnet build RogueLegacy.sln` to succeed.

Frequently asked questions

Official sources

1. flibitijibibo/RogueLegacy1 on GitHub
2. Issues
3. Project website
4. README