RPG-Core: a Unity RPG framework with swappable mechanics

One framework, several kinds of game

RPG-Core is described as a framework that wants to simplify the creation of role playing games while still providing flexibility, making it easy to make any type of game with the included functionality. The promise in the second sentence is the interesting one, because if the game you want is not possible out of the box, it will be very easy to extend.

The requirements are short. Unity 2019 or later, the addressables package, and DOTween as an optional dependency. The badge in the README pins the tested editor to a specific Unity release, and the addressables requirement matters more than it looks, because an addressable content system is what lets the framework load characters, scenes, and data without shipping everything in the build.

The repository is small in terms of what is visible. There is a station directory, which holds the framework itself, an images directory, a README, a licence file, and a gitignore. The project is written in C#, the default branch is master, the last push was on 2026-04-14, and there is a single release, version 0.5, described as the code only version, published in May 2020.

That release history is the first thing to weigh, and it points the same way as the README does. The framework is a substantial body of work that has been developed without a steady release cadence, which is common for a solo project that is used as a base for one game at a time.

The documentation lives outside the repository, on a GitBook site, and the README marks it as work in progress.

What the framework ships with

The feature list is the longest part of the README, and it is a catalogue of the systems a role playing game needs.

There is a saving system, and the description of the spawning feature notes that use rules and state can be saved, which is the point of the whole design.

The stats system covers attributes, vitals, statistics, and elements. The character system covers races, player classes, and non-player characters, with a party and the ability to switch character. Factions are there as a first class concept, and abilities and skills are separate lists, which is a distinction that matters for a game where a skill is something you learn and an ability is something you have.

The world side covers worlds, scene data, spawners, and portals. Interaction covers buttons, harvest nodes, portals, and chests. There is spawning for characters and for any other object, and items with different types and functionalities, and containers, which serve as player inventories or as chests.

Then there are the three hot swappable mechanics, which the README lists separately from everything else: swappable character creation, swappable user interface, and a swappable character controller, input, and camera.

The fact that the user interface is on that list is worth pausing on, because it is a larger claim than swappable controls. A framework that can replace its own interface layer is doing more than parameterising a game, it is offering a different presentation of the same underlying model.

The list of what is in progress and what is planned is just as informative. In progress are equipment and character AI. Next come extended status effects, a hate system, a counters system, a quest system, and crafting.

So the systems a player notices most, the equipment they wear, the quests they follow, and the enemies that think, are the ones that are not finished, which is exactly the information a team needs before choosing a base.

Nothing is hardcoded, and a calculator does the arithmetic

The section on flexibility answers the question the feature list raises, and it does so with two rules.

The first is that none of the stats, skills, names, vitals, or character creation are hardcoded, and that they are configured through the editor instead. The second is that each character instantiates a scriptable object called a calculator, which is responsible for the calculation and for telling the other components what to do.

The calculator pattern is the interesting architectural decision here, and it is the one to understand before extending anything. A scriptable object in Unity is a data asset that the editor can author, so the difference between a stat block being a hardcoded number in code and a stat block being an asset with a configurable calculator is the difference between a designer needing to recompile and a designer dragging a reference.

It also explains the shape of the example code, which is the only substantial code in the README. A custom character builder overrides two methods. One returns the matching type, so the framework can tell which kind of character it is building. The other performs the build, and it is long because it does everything a character needs: it looks up the player class, the active abilities, and the passive abilities from the database systems, it fetches the class model, it instantiates the stats calculator on the character and checks that it is not missing, it calls the setup on the calculator with the class data, it initialises the character with its identifier, race, faction, gender, calculator, and name, it sets up the stats and the vitals from the saved values, it initialises the player input handler, and then it builds the abilities, the action bar bindings, the passive abilities, and the skills.

That last part is instructive. The builder is the single place where a character is assembled, which means a game with a different kind of character, a pet, or a non-player character, overrides the builder and gets the same treatment, rather than duplicating the assembly logic.

The pattern the README describes for extension is exactly this. You override the character builder to create a specific builder for players, non-player characters, or pets, and then assign it to any of the mechanics.

Switching mechanics without touching the data

The hot swappable mechanics feature is the claim that makes the framework more than a set of role playing systems, and the README explains it with a deliberately extreme comparison.

You can use the classic role playing mechanics for a team based game, then change to the first person role playing mechanics, and the game will play like Skyrim. The README is explicit that this does not require reconfiguring the data or the scenes.

That is a strong claim and it is worth being precise about what it implies. The data, meaning the stats, the abilities, the classes, the characters, the items, and the scenes, is written to be mechanic agnostic. The mechanics, meaning the character creation, the user interface, the controller, the input handling, and the camera, are the swappable layer.

The reasons to want that are practical. A team that has committed to a role playing system and then discovers the game plays better in first person can change it in the editor rather than starting again. A studio shipping the same world in two genres can share the content. And a prototype can be built with one set of mechanics and tested with another.

The cost is that the mechanic agnostic data model is a constraint on the content. A mechanic that needs a different notion of a character, or a different notion of an action bar, cannot be expressed without extending the framework, which is why the builder pattern exists.

It also explains why the user interface is in the list of swappable mechanics. The interface is the part of a role playing game that is most tied to a particular view of the world, so a framework that can swap it is making a statement about the data model underneath.

The documentation for the mechanics is in the documents area, and the example directory in the repository shows the configuration side, with a keybindings file, a main configuration file, and a themes directory.

The state of the project, the licence, and the documentation

Three practical points to check before committing to this framework.

The first is the release state. There is one release, version 0.5, published in May 2020, and the repository has continued to receive commits since, with the last push in April 2026. The framework is therefore developed but not packaged, and the phrase in the release name, code only version, suggests that the release is the source rather than a built asset. For a Unity project that is not unusual, since Unity packages are usually consumed as a git reference or a submodule anyway, but it does mean there is no version history to pin your fork to.

The second is the licence. GitHub cannot classify it automatically, and the licence file is a text file named LICENSE.txt in the root. For a framework that is intended to be the base of a commercial game, the terms of that file are the difference between a foundation and a constraint, and they are worth reading before anything else.

The third is the documentation. The project uses a GitBook site, and the README says the documentation is work in progress. The features are described well in the README itself, and the code example is unusually long and real, but there is no reference documentation for the data model, and that is where a new user would want to look first.

There is a Discord server for questions, and the contributing section asks for bug reports and feature requests without describing a process, which again points to a project maintained by one person around one game.

For a team, the honest summary is this. The architecture is interesting and the swappable mechanics idea is a real contribution to how role playing games are built in Unity. The systems that a shipped game needs most are still in progress. The documentation is incomplete. And the licence needs reading. That is enough to try it on a prototype, and enough to be careful about building a product on it.

Editorial conclusion

RPG-Core fits a Unity team that has to support more than one way of playing the same game, or that wants a role playing game systems layer without writing one from scratch, and that is comfortable with the editor driven configuration the framework expects. It does not fit a project that needs equipment, character AI, quests, or crafting today, because those are on the in progress and next features lists. Verify first that the Unity version in use meets the stated requirement and that the addressables package is in place, that the licence in the repository permits the intended use, since it is a custom licence that GitHub cannot classify, and that the documentation on the linked site is complete enough for the mechanics you intend to swap, because the README marks it as work in progress.

Frequently asked questions

Official sources

1. delmarle/RPG-Core on GitHub
2. Issues
3. README
4. Releases