UnityStarter: a modular foundation for long-lived Unity projects

A foundation project rather than a game

UnityStarter is described as a production-oriented, modular Unity foundation project and reusable framework base, informed by Unreal Engine architecture, and the README says so in a plain way: it is for developers and teams who want production-grade Unity structure from the start.

The list of what it provides is the argument for it. Predictable asset ownership, separated gameplay architecture, data-driven content, explicit module boundaries, build automation, analyzers and maintenance tools.

The gameplay layer is where the Unreal influence is most visible. The GameplayFramework applies Unreal-style organisation around the concepts of an actor, a pawn, a controller and a game mode, and gameplay abilities and gameplay tags provide GAS-like primitives for expressing gameplay contracts explicitly.

That is a meaningful difference in kind from a Unity starter template that is really a folder of scripts. The organising idea is that the pieces of your game have owners and that the rules of the game are expressed as abilities and tags rather than as a tangle of MonoBehaviours with public fields.

The README also says who it is for. UnityStarter targets medium-to-large Unity productions with long-term iteration needs, with explicit ownership boundaries, performance-conscious runtime systems, engine-agnostic core layers and project-owned build and tooling infrastructure.

The project is MIT licensed, with the badge also stating compatibility with Unity 2022.3 LTS and Unity 6.

Two ways to take it into your project

The README gives two practical routes, and they suit different kinds of team.

The first is to use the repository as a project template. You open the UnityStarter directory in the Unity editor, rename it with the bundled tools, and let the project-owned build layer evolve with your game.

The second is to use it as a package. You move the folders you want out from under the CycloneGames directory and add them from the Package Manager, which means you take only the modules you need and the rest stays behind.

That second route is what the package layout is for. The reusable framework layer lives under the third party directory inside the assets folder, and the assembly definitions in the assets declare the package and project assembly boundaries. The Unity version is read from a single file in the project settings, which is the usual way to keep a project pinned to one engine version.

The distinction between the two routes matters for a long project. As a template, the whole structure comes with you and you own all of it, including the parts you did not write. As a package, the framework evolves separately and your project consumes it, which is cleaner but means you track upstream changes.

The README's own framing of the value is worth repeating: a reusable engineering foundation covering ownership, testability, optional integrations, build configuration, editor tooling and documentation.

The module map and the ownership model

The README calls the module map the primary index, and it covers gameplay, content, user interface and input, artificial intelligence, runtime infrastructure, build tooling and experimental networking packages.

The module list is more concrete than that. The gameplay group holds the gameplay framework, the abilities, the tags and something called an RPG foundation. The content group holds asset management, data tables, localisation and audio. The presentation and input group holds the user interface framework, the input system and device feedback. The artificial intelligence group holds a behaviour tree and perception. And the runtime infrastructure group holds the factory, the logger, deterministic maths, hashing and input and output.

On top of that sits an ownership map, which the README is careful to describe as a repository ownership and module responsibility diagram rather than a runtime dependency graph. That distinction matters, because it shows which parts are expected to evolve with your game, which are reusable framework modules and which are optional.

flowchart TD
  subgraph ProjectOwned["Project-owned template layer"]
    StarterAssets["Assets/UnityStarter/\nScenes, project assets, composition"]
    BuildLayer["Assets/Build/\nBuild and CI entry points"]
    ProjectTools["Tools/\nRename, cleanup, maintenance utilities"]
  end

  subgraph FrameworkModules["Reusable CycloneGames modules"]
    Gameplay["Gameplay\nGameplayFramework, Abilities, Tags, RPGFoundation"]
    Content["Content\nAssetManagement, DataTable, Localization, Audio"]
    Presentation["Presentation/Input\nUIFramework, InputSystem, DeviceFeedback"]

The arrows in that diagram make the intent plain. The project owned tools feed the starter assets and the build layer, the starter assets consume the framework modules, and the framework modules sit on the runtime infrastructure. The optional integrations are connected with dashed arrows and labelled as optional bridges, which is how the diagram says that the networking packages are reachable but not required.

The architecture principles behind the code

Six principles are stated, and they are the ones that will decide whether the framework is useful to you.

Pure C# first where it matters is the first. The core contracts avoid leaking Unity engine types when the logic should remain testable in a command line run, in edit mode, in headless simulation or in a future adapter. That is a testability decision expressed as a rule about type dependencies.

Unity as the integration layer is the second. Behaviours, scriptable objects, editor tools, scene bindings and assets bridge into the runtime systems without owning complex domain rules.

Optional integrations stay isolated is the third, and the list is specific: dependency injection containers, tween engines, scene navigation, serializers, transports and hot-update backends all live behind dedicated integration assemblies. The rule is that the core does not depend on any of them, so choosing one is a wiring decision rather than a rewrite.

Performance is a design constraint comes next. Hot paths aim for zero or low garbage collection behaviour, with predictable ownership, reusable buffers and explicit lifecycle cleanup, which is a notable claim for a Unity framework where allocation in an update loop is easy to do by accident.

Build is project-owned is the fifth, and it is the most opinionated. The build directory is expected to travel with derived projects and to change with product requirements, which is an argument against treating the build as reusable infrastructure.

Docs are part of the API is the last. Long-lived modules are expected to maintain the English and the Simplified Chinese readme together, which is why the repository carries README.SCH.md beside README.md.

Analyzers, rulesets and the tooling

The tooling is where the framework's claim about quality becomes concrete.

There are more than twenty implemented analyser rules in a dedicated CycloneGames.Analyzers assembly, and they are staged project-wide by a ruleset file placed at the root of the assets with the exact name Unity applies automatically. That detail is the kind of thing that takes a while to discover, and it means the rules are active without every project having to opt in.

Alongside the analysers there are standalone maintenance tools, and the table describes them as Go tools with Windows executables under a directory in the tools folder. Go for the tooling is a deliberate choice: a small, fast, statically linked binary that anyone on the team can run without a Unity licence or a managed runtime.

The project-owned build layer is the third piece. The README says the build directory is expected to travel with derived projects and to change with product requirements, and the ownership diagram labels it as the build and continuous integration entry points. The hot update build hooks are connected to it with a dashed arrow labelled detects and invokes, which is how a HybridCLR or YooAsset or Addressables installation gets picked up when it is present.

The networking packages are described in the same diagram as experimental until they are validated end to end, and the README has a section dedicated to the networking status. That is the kind of labelling that saves an adopter from building on top of something the author considers provisional.

Requirements, first run and what to check

The README has a getting started section with a requirements list and a first run procedure, a section on using individual modules, and a technology stack section.

The badges give the engine versions to check against: Unity 2022.3 LTS and Unity 6000.x compatibility. That matters because a framework that uses engine features from a particular version will not build on an older one, and because the module set here covers areas where the engine API has moved between major versions.

The getting started section also covers using individual modules, which is the package route in practical terms. If you only want the gameplay framework and the ability system, you take those packages and leave the rest of the third party folder behind.

There is a validation status section in the table of contents, and a related projects section, which together tell you how the project presents its own maturity. The single release tag is v1.0.0, named first release, from 2025-09-03, and the last push to the repository was on 2026-10-16, so the code is being worked on well after the first release.

Four checks before you adopt it. That your team is willing to own the build layer, since the README is explicit that it is expected to change with your requirements rather than be maintained upstream. That the analyser rules do not fight your existing code, since a project-wide ruleset applied automatically can produce a wall of warnings on day one. That the parts you need are validated rather than experimental, particularly the networking packages. And that the documentation maintenance expectation, two readmes per module, is one your team will actually meet.

Editorial conclusion

UnityStarter suits a studio starting a Unity project that is expected to run for years, because it encodes the decisions that are expensive to change later, ownership boundaries, an engine agnostic core, a build pipeline that belongs to the project and documentation that travels with the code. It is the wrong choice for a small prototype, where the framework cost outweighs the benefit, and the wrong choice if your team is already settled on an architecture, since a second opinion is not what you need. Verify first which Unity version your target uses, since the project states 2022.3 LTS and Unity 6 compatibility, that the networking packages are experimental before you plan around them, and that your team is prepared to own the build layer, since the README is explicit that the build infrastructure is expected to travel with your game and change with your requirements.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. MaiKuraki/UnityStarter on GitHub
4. README
5. Releases