AnyRPG: an open source RPG engine that arrives as a whole Unity project

It supplies the RPG machinery so you can supply the story

The pitch is narrow on purpose. AnyRPG is a role playing game engine written in C# for Unity, and its stated goal is to let content creators build short stories, scenarios, adventures and even full games rapidly. The mechanism behind that goal is simple: the project provides the most common role playing game functionality out of the box, so the person making the content only has to provide visual assets and story content.

That division of labour is the product. Someone who has never written dialogue trees, inventory logic or a quest system can open the engine, point it at their own art, and get a playable scene. The project describes itself as a hundred percent free and open source project, and the repository carries an MIT licence.

What you are adopting is a layer above the raw Unity APIs. That layer saves time and, at the same time, decides for you how quests, conversations and characters are structured, which is a decision that is hard to reverse later. Teams who already have their own systems should weigh that before anything else.

The engine is a Unity project, not a package you reference

The repository layout tells you what kind of thing this is. The top level is dominated by Assets/, Packages/ and ProjectSettings/, the three folders that make up a Unity project, with a .vsconfig, an .editorconfig, a .gitattributes and a CONTRIBUTING.md and CODE_OF_CONDUCT.md alongside them. There is no separate engine assembly folder and no published package manifest at the root.

That has a direct consequence for integration. You do not add AnyRPG to an existing Unity codebase as a dependency. You open the project itself, which means the Unity version matters, and the setup instructions pin it: the current project Unity version is 6000.3.10f1, and step one of installation is to install the correct Unity version to open the project.

The practical implication is that a team with an existing project, an established render pipeline or a pinned Unity version of its own will find that adopting the engine means reconciling versions rather than adding a feature. The engine is delivered in the same shape as the game you are meant to make with it, which is convenient for a clean start and awkward for anything else.

Two ways in, and neither is a command line

Installation is described as having two options, and both are documented with a video tutorial. The first is the GitHub route, and it is three steps: install the correct Unity version to open the project, clone the repository into a directory on your computer, then open the Unity Hub and add the project. The tutorial linked in the README covers AnyRPG Core version 1.0 and higher.

The second route is the Unity Asset Store, where AnyRPG Core is listed under the package slug 234361. A separate video tutorial walks through the Asset Store installation for version 1.0 and higher.

There are no build scripts or command line steps to run, which is unusual for a repository that looks like a software project and is actually a Unity workspace. The result is that installation produces an openable Unity project, not a compiled artifact, and everything after that happens inside the editor.

The two channels are worth thinking about as a pair. A GitHub clone gives you the full source and the sample games. The Asset Store copy is the same engine packaged for the editor, with a video tutorial for each path, and the project treats them as equivalent starting points rather than describing how they differ.

The welcome window is the real front door

Getting started is a short sequence of steps in the Unity editor. You open the Tools menu, choose AnyRPG and then Welcome Window, click the Import TMP Essential Resources button, and from there you can find and open the included sample games, launch the New Game Wizard to set up your own game, or open the online support resources for deeper help and information about using AnyRPG.

The New Game Wizard is the piece that matters most for a content creator, because it is where a new project starts from the engine's own structure rather than from a blank scene. The sample games serve the complementary purpose. They are working examples of what the engine can do, which is a faster way to learn the system than reading documentation, and they are also the reference you compare your own project against.

One dependency is called out explicitly in the setup steps: the import of TMP Essential Resources. It is presented as a button inside the welcome window and as a step in the getting started flow, so it is easy to follow and easy to miss. The documentation does not explain what the resources are for or what breaks if you skip the import, which is a good example of where the written documentation stops and the video tutorials take over.

What the written documentation leaves out

The README is short, and the deeper documentation lives on Gitbook at docs.anyrpg.org. That is a reasonable arrangement, but it means the repository itself answers only a few questions.

There is no feature list in the README. You get the goal, the two installation routes, the welcome window steps and a set of links, but nothing that enumerates which role playing game systems the engine implements, which Unity versions are supported beyond the single pinned one, or what the sample games actually contain. The version support question in particular has a thin answer: the project names 6000.3.10f1 as the current project Unity version and does not describe an earlier version that still opens.

There is also a packaging question the README leaves open. The engine is distributed through two channels, GitHub and the Unity Asset Store, and the documentation does not explain how the two are kept in step, or whether the Asset Store copy always matches the repository. Anyone planning to work from the Asset Store version and follow the repository for fixes needs to verify that for themselves.

The community links are the place to look for the missing detail instead. The project points at a Discord server, a Trello board, a YouTube channel, a Patreon page and a downloads page hosting Unity packages and example games.

Where the engine is the wrong tool

The stated target is 3D role playing game content in Unity, and the boundaries follow from that. The project description calls it an engine for Unity 3D, so a 2D pixel project is outside what you are getting. A game built around a different engine, or a headless or server-authoritative design, has no path into this codebase, because the engine is delivered as a Unity project with its own editor tooling, its own welcome window and a New Game Wizard that assumes you are building inside it.

The second mismatch is structural rather than technical. An engine that hands you common RPG functionality also hands you its opinion about how that functionality fits together, and a content creator who arrives with a story that does not match the engine's quest or dialogue structure can spend longer fighting the tool than writing the story. The included sample games are the way to find out early, and the New Game Wizard is the point at which that mismatch shows up.

The third case is scale mismatch in the other direction. The engine is aimed at short stories, scenarios and adventures, with full games as a stretch. If you need a large project with its own tooling, editor extensions and build pipeline, you are adopting a small team-oriented engine and will end up writing that infrastructure anyway.

MIT terms, a single release, and steady repository work

The licence is MIT, which is the simplest possible answer for a project you intend to modify. You can take the C# source, change it, and ship your own game without the copyleft obligations that a shared-source licence would impose on a distributed game. For an engine whose whole purpose is to be edited while you build content, that matters more than the licence choice usually does.

The release history is thin. There is one release, v1.0.1, published on 2026-05-26. The version numbering referenced throughout the installation instructions is the 1.0 line, which suggests the project treats 1.0 as the stable baseline that the tutorials were written against.

The repository itself is being worked on. The last push was on 2026-09-27, and the repository is not archived, so the engine is being changed even when it is not being cut as a release. The practical consequence for a user is that the Unity version pinned in ProjectSettings can move under you between clones, which is exactly the kind of change worth watching in the commit history when a project stops opening.

Funding runs through Patreon, and support runs through Discord, so the shape of the project is closer to a maintained community tool than to a commercial framework with a support contract behind it.

Editorial conclusion

AnyRPG suits a solo developer or small team who wants to ship a short scenario, visual novel style adventure or small 3D RPG in Unity and would rather spend the time on art and dialogue than on engine plumbing, and who are willing to work inside a pinned Unity version. It does not suit a team with an existing Unity codebase, a non-Unity project, or a 2D pixel game, since the engine is a Unity project you open rather than a package you reference. Verify three things before committing: that Unity 6000.3.10f1 opens the project without a version upgrade prompt, that the Asset Store copy and the GitHub copy you plan to use actually match, and that the example games included in the welcome window cover the features your own scenario needs before you commit to its structure.

Frequently asked questions

Official sources

1. AnyRPG/AnyRPGCore on GitHub
2. License: MIT
3. Project website
4. README
5. Releases