# Loxodon Framework: MVVM and data binding inside a Unity 3D project

> An MIT licensed Unity package that adds view models, two way data binding, a messaging layer and a Lua path to C# game projects, shipped as a family of OpenUPM and npm packages.

**vovgou/loxodon-framework** — An MVVM & Databinding framework that can use C# and Lua to develop games

- Repository: https://github.com/vovgou/loxodon-framework
- Stars: 2,209 · Forks: 387
- Language: C#
- License: MIT
- Published: 2026-10-07 · Updated: 2026-10-07 · Language: en
- Canonical page: https://hysenlabs.com/projects/vovgou-loxodon-framework

## What Loxodon puts between a Unity scene and your game logic

The repository describes itself as an MVVM and databinding framework that can use C# and Lua to develop games, and the README names the target as Unity 3D with C#, XLua and ILRuntime. The minimum version it asks for is Unity 2018.4 or higher, and the plugin is listed as compatible with MacOSX, Windows, Linux, UWP, WebGL, IOS and Android with all source code provided.

The practical addition is a layer between MonoBehaviours and the data they display. A view model holds the state, the view binds to it, and the binding updates the UI when the value changes. The alternative most Unity projects start from is direct field assignment inside MonoBehaviour scripts, wired through UnityEvent or a serialized reference. That approach works until the same value has to appear in four places, at which point you are hand writing the update calls that a binding would have handled.

The README also states that the framework has been validated in projects and calls the architecture clear and extensible. That is an author claim rather than a measurement, and no benchmark numbers appear anywhere in the repository. What is verifiable is the shape of the feature list: localization, an encrypted preferences store, a messaging system, a scheduled executor with multithreading, and asynchrony in both C# and Lua.

## The binding types Loxodon ships and why the list is long

The databinding list in the README is the most informative part of the project, because a binding framework lives or dies on which binding shapes it actually handles. Loxodon enumerates field binding, property binding, dictionary, list and array binding, event binding, Unity 3d's EventBase binding, static property and field binding, method binding, command binding, ObservableProperty, ObservableDictionary and ObservableList binding, and expression binding.

Two of those deserve comment. Command binding is the MVVM staple: a button is bound to an ICommand style object on the view model rather than to a UnityEvent inspector list, which means the command object can carry its own enabled state and can be reused outside a button. Expression binding goes further and lets the target be written as an expression over the source rather than a single property path, which is how you bind a formatted string without writing a setter.

The collection bindings matter for real interfaces. A list bound to a virtualized scroll view only updates visible rows, so the cost of a bound list is proportional to what is on screen rather than to the size of the data set. The README does not document the internals of that behavior, so the claim to hold is that the binding types exist, not that any particular scrolling profile has been established.

## The garbage collection argument behind dynamic delegates and code weaving

Loxodon makes a specific and unusual pitch: data binding performance comparable to direct invocation, with zero garbage collection during UI view updates. The mechanism it names is dynamic delegates and static code weaving, used to avoid reflection, and separate notes about avoiding boxing and unboxing of value types.

That is a coherent position for Unity, where garbage collection spikes show up as frame hitches. Reflection based binding would allocate on each update. Binding an int to a Text component naively would box that int to pass it through a non generic API. A weaver that rewrites binding sites at build time removes the reflection lookup from the hot path, and a typed delegate removes the boxing. Both techniques are in the repository: Loxodon.Framework.Fody is the weaving package, and the main package is described as supporting dynamic delegates as the alternative when you do not want a build step.

The TextFormatting and TextMeshPro packages extend the same idea to strings. TextFormatting extends StringBuilder's AppendFormat to avoid allocations when concatenating text or converting numbers, and adds TemplateText and FormattableText controls. TextMeshPro then plugs FormattableTextMeshProUGUI and TemplateTextMeshProUGUI into the AlertDialog and Toast views, replacing UnityEngine.UI.Text. The result is a claim that updating these views allocates nothing at all. Whether that holds for your content depends on what you bind, so the TextMeshPro package is worth reading before you commit to it.

## Twenty packages beside the core, and which ones bind to what

The repository is not a single package. The tree shows the core Loxodon.Framework directory surrounded by nineteen sibling packages, and picking the right ones is the actual work of adopting this project.

```text
Loxodon.Framework.Fody/
Loxodon.Framework.XLua/
Loxodon.Framework.TextMeshPro/
Loxodon.Framework.OSA/
```

XLua is the one that changes the shape of a project: the README says you can make your game in Lua, with asyncawait and try, catch and finally supported in Lua as well. Addressable, Connection and FairyGUI are integration points for asset loading, networking and the FairyGUI UI system. LocalizationsForCsv, Log4Net, NLog and Obfuscation cover translation, logging and build protection. UIToolkit and TextUGUI are alternative UI stacks. ILRuntime is the IL2CPP counterpart to XLua for hotfixes. OSA adds data binding to ListView and GridView, but it depends on a separate paid Asset Store plugin, Optimized ScrollView Adapter, which you must install first.

## Getting the packages onto a project and what Installation.md settles

Loxodon is not installed from a git URL you then have to wire up manually. The README carries an OpenUPM badge for the package com.vovgou.loxodon-framework, an npm badge for the same name, and an AtomGit mirror for users inside China. There is also an Asset Store listing. Fetching the source directly works too, and it is the fastest way to read what actually ships:

```bash
git clone https://github.com/vovgou/loxodon-framework
cd loxodon-framework
```

The repository holds Installation.md and Installation_CN.md at the top level, and the README defers to the English one for the actual steps. The manuals are in docs/ as LoxodonFramework_en.md and LoxodonFramework_en.pdf. Because the packages are versioned independently of the repository, the version notes in the README matter more than usual, and they are where the first surprise lives.

## Version lines, release tags and the unreleased gap

The README's notes section splits the project into two eras, and the split is easy to miss:

```text
.Net2.0 and .Net2.0 Subset,please use version 1.9.x.
LoxodonFramework 2.0 supports .Net4.x and .Net Standard2.0
```

So a project still on .Net 2.0 is pinned to the 1.9.x line and cannot simply take the current packages. LoxodonFramework 2.0 onward requires .Net 4.x or .Net Standard 2.0 and runs on both Mono and IL2CPP. The newest release tag is v2.6.7 from 2025-08-11, with v2.6.6 from 2024-07-12 and v2.6.5 from 2024-06-04 before it, and the last push to the repository was on 2026-04-01. Those two facts sit awkwardly together: there are roughly eight months of commits with no release attached to them, so pinning to v2.6.7 and tracking master are two quite different choices for a shipping project.

A second gap is in the README page itself, which ends partway through the entry for the Data plugin. That package exports spreadsheet data to Json, to Lua files or to a LiteDB database and converts it to C# objects through Json.Net, and the README recommends LiteDB for configuration storage. The dependency list underneath it is not shown. The repository also carries a LICENSE file, and GitHub reports the project as MIT, which matters if you intend to ship a game built on it.

## Conclusion

Loxodon earns a place in a Unity project that already has a UI layer large enough to hurt, a designer-facing view model pattern, or a need to move gameplay scripting into Lua. It costs you a set of conventions, a code weaving option in the Fody package, and a dependency on bindings being written in the style the framework expects. The last push was on 2026-04-01 and the newest release tag is v2.6.7 from 2025-08-11, so commits since that tag are unreleased and you are tracking master. Start by reading Installation.md for the package set, then decide between runtime dynamic delegates and the Fody weaver before the first view is bound.

## FAQ

### Is Loxodon Framework free to use in a commercial Unity game?

The repository carries a LICENSE file and GitHub reports the license as MIT, which permits commercial use. The README also links an Asset Store listing, so some components may be available through that channel under its own terms. Read the LICENSE file yourself before shipping, and check whether the OSA plugin's dependency on Optimized ScrollView Adapter is covered by the MIT grant.

### Which Unity version and .NET profile does Loxodon require?

The README asks for Unity 2018.4 or higher. Its notes split the project: LoxodonFramework 2.0 and later need .Net 4.x or .Net Standard 2.0 and support both Mono and IL2CPP, while projects on .Net2.0 or the .Net2.0 Subset should stay on version 1.9.x.

### Can I write a Loxodon game's gameplay logic in Lua instead of C#?

Yes. The README lists XLua support and says you can make your game in Lua, with asyncawait and try, catch and finally available to Lua code too. The XLua package is a separate directory in the repository, and the header line names C#, XLua and ILRuntime together.

### Does data binding through Loxodon allocate memory on every UI update?

The README claims zero garbage collection during UI view updates, and attributes it to dynamic delegates and static code weaving that avoid reflection, plus avoiding boxing and unboxing of value types. The TextMeshPro package makes a similar claim for AlertDialog and Toast views. These are author claims stated in the README, and the repository publishes no benchmark numbers to back them.

## Sources

- [Issues](https://github.com/vovgou/loxodon-framework/issues)
- [License: MIT](https://github.com/vovgou/loxodon-framework/blob/master/LICENSE)
- [README](https://github.com/vovgou/loxodon-framework/blob/master/README.md)
- [Releases](https://github.com/vovgou/loxodon-framework/releases)
- [vovgou/loxodon-framework on GitHub](https://github.com/vovgou/loxodon-framework)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/vovgou-loxodon-framework