UMA: the Unity Multipurpose Avatar system for making modifiable characters

What UMA is and the problem it was designed around

UMA is the Unity Multipurpose Avatar System, shortened to UMA, and the README describes it as a free character creation and modification system with lots of cool features. It was designed with flexibility in mind, so although its primary purpose is for working with humanoid characters, its systems can be adapted to work with any model you like.

That flexibility is the substance of the project rather than a marketing aside. The phrase in the README is that if you want to create modifiable, optimised models for use in your games, UMA is the place to start. A character system that assembles a person at runtime, from a set of interchangeable parts, solves problems that a single authored mesh cannot: a player who changes their appearance, a crowd of NPCs with generated faces, a game where equipment changes what a character looks like.

The README is also honest about what kind of project this is. As a community project UMA is always being improved, and although the best efforts are made to keep the wiki up to date, it relies on the spare time of helpful individuals to maintain. The invitation at the end of that paragraph is direct: if you want more help or feel like chipping in, get involved with one of the community links.

That sentence, more than any feature list, tells you how to evaluate the project. It is maintained by volunteers, its documentation is a wiki maintained in the gaps, and the expectations on a user are correspondingly different from those of a commercial asset.

The project structure and where the code lives

The repository is small at the top level, which is what you would expect from a Unity project where the bulk of the code is in a package rather than in loose files.

There is a UMAProject/ directory, which is the Unity project itself, and alongside it the usual repository files: a README.md, a LICENSE, a CONTRIBUTING.md, a .gitignore and a .github/ directory for the workflow configuration. Two images sit at the root, intro.png and logo.png, which the README references in its header.

The important detail for anyone integrating UMA is the LICENSE. It is MIT, stated plainly in the README as well as in the file, and that is a meaningful choice for a project of this kind. An MIT character system can be used in a commercial game, modified, and redistributed without the copyleft obligations that come with a shared-assets licence. For a system that is a foundation rather than a finished asset, that removes an entire category of legal question before a producer has to think about it.

The .github/ directory and the CONTRIBUTING.md are the signals about process. The project has a written contribution process and continuous integration configured in the repository, which for a volunteer project is the difference between a codebase that accumulates patches and one that accumulates patches nobody can merge.

Releases, version naming and what the numbering tells you

The recent releases are three, and their names are worth reading carefully because they are irregular.

v3.1f3 is labelled UMA 3.1f3 Full Release and was tagged on 2026-10-09. V3.1f1, labelled UMA 3.1f1 Full Release, was tagged on 2026-09-28. v3.05, labelled UMA 3.05 Full Release, was tagged on 2026-08-31.

So the version string changes shape across those three tags. One uses three components with a letter suffix, one is capitalised differently at the start, and one uses a two-digit patch with a leading zero. That is not a semantic versioning scheme, and the README does not claim it is one. What it tells you is that this is a project where the release names track something other than a clean version progression, most likely a line that moves with the Unity version it targets, and where the maintainers have not imposed a format on it.

For a user, the practical consequence is that picking a version is not a matter of sorting numbers. The three releases are close together in time, between the end of August and the middle of October 2026, and the last push to the repository was on 2026-10-18, after the newest tag. Development on the branch has continued past the most recent release, so the difference between the current master and the newest tag is unknown without comparing them.

That is a normal state of affairs for a Unity project, where the package is often consumed by copying the folder into your project rather than through a package manager with pinned versions.

The community infrastructure the README points at

The README lists four places to go, and each answers a different question.

The Git repository is where the code lives, at github.com/umasteeringgroup/UMA. The project board is on the organisation rather than the repository, at the umasteeringgroup organisation's projects page, which is where the roadmap and the work in progress live. The wiki is the documentation, at the wiki URL for the same repository. And the forum is a thread on the Unity forum about UMA on the Asset Store, which tells you two things at once: that there is a Unity forum thread devoted to the system, and that a version of UMA has been made available through the Unity Asset Store at some point.

The header image links to an introductory video hosted on YouTube, which is the fastest way to see what the system actually does before reading anything else.

Taken together, those four links describe a project with more infrastructure than a single asset would have. A project board means there is a visible plan and people assigned to items. A wiki means the documentation is a living document rather than a PDF that shipped with the download. A forum thread means there is a place where questions get answered that is not the issue tracker.

The organisation naming is also a small signal. The project is under umasteeringgroup rather than an individual account, which suggests a team rather than one person, and that matters for a system whose users are building games that will need maintenance over years.

Limits: a community project, a wiki and the humanoid assumption

The limits are visible in what the README says and in what it leaves unsaid.

The first is the documentation. The README says explicitly that although the best efforts are made to keep the wiki up to date, it relies on the spare time of helpful individuals to maintain. That is a statement about the state of the documentation, and it is the practical constraint anyone adopting this has to plan around. You will be reading source, and you will be relying on the community forum for answers that the wiki has not yet absorbed.

The second is that the primary purpose is humanoid characters. The README says the systems can be adapted to work with any model you like, and that flexibility is a design goal. Adaptable is not the same as supported. Making the system work with a non-humanoid rig is possible in principle, but the humanoid path is the one the maintainers will have tuned, documented and tested, and the difference in effort between the two is where the real risk sits.

The third is the release naming irregularity described above, which means choosing a version requires reading the release notes rather than comparing version strings.

The fourth is that this is a Unity package rather than a redistributable library. The repository holds a UMAProject/ directory, so integrating it means bringing it into a Unity project and dealing with the package in that project's terms, which for a monorepo or a team with strict asset pipeline rules can be more friction than a NuGet or npm dependency would be.

The fifth is the one the README does not discuss at all: there is no feature list, no documentation of the API, and no statement of which Unity versions are supported. The README is a description of the project's intent and a set of links, nothing more. Everything you would need to evaluate the system technically is in the wiki, and the wiki is maintained in volunteers' spare time.

UMA against a baked character asset and against a commercial avatar creator

Two comparisons make the choice clearer.

The first is against a single authored character mesh, which is how most small games ship their cast. The difference in approach is when the character exists. A baked mesh is a fixed artefact that the artist finished, and every change to it is an artist task and an asset pipeline change. A runtime-assembled avatar is a set of parts and a recipe, so a hat, a body type or a face can change at runtime without anyone repainting a texture.

For a game where the player's appearance matters and changes, or where a crowd of NPCs needs to be varied rather than cloned, the runtime approach is the only practical one. For a game with three characters and a fixed cast, a baked mesh is cheaper in every dimension, and a full avatar system is machinery you do not need.

The second comparison is against a commercial avatar creator. Those products generally have better documentation, more polished tooling, a support contract and a predictable release cadence, and they are a supportable purchase for a studio. The difference in approach is licensing and openness. UMA is MIT, so it can be modified freely, embedded in a game without per-seat fees, and continued by whoever owns the game if the community moves on. A commercial creator is the opposite on all three counts.

So the choice turns on two questions. Does your game need characters whose appearance changes at runtime, and would a proprietary dependency on your critical path be a problem? If the answer to the first is no, a commercial tool with documentation and support will serve you better. If the answer to the first is yes and the answer to the second is that you want control, then a free MIT system with a maintained community behind it is the sensible place to start, with the understanding that you will be reading its source.

Editorial conclusion

Adopt UMA when you need characters whose appearance changes at runtime, where a baked mesh cannot work, and you want a free MIT licensed base rather than a commercial asset. Do not expect it to be a finished product with consistent documentation, since the README says outright that the wiki depends on the spare time of helpful individuals. Verify first that the version you take supports your Unity version, that the community documentation covers the features you plan to use, and that you are prepared to read source when the wiki falls short.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. umasteeringgroup/UMA on GitHub