MyFramework: a Unity game framework built around code generation and hot update layers

A workflow, not a set of wrappers

The framework describes itself as a Unity game framework and tool chain with a traditional game engine development style, and it is explicit that it is not simply a runtime wrapper around the Unity API. It is an engineering system organised around the workflow of a real commercial project, and the areas it names are hot update layering, UI code generation, a configuration table tool chain, network protocol code generation, asset management, object pooling, project checks, low garbage collection, strict lifecycle control, and client and server collaboration. It was designed from zero and iterated over many years, and the projects it has been applied to are a personal commercial MMORPG, and a company mobile game project. Supported platforms are Windows, Android, iOS and WebGL. The primary language of the repository is C#, and the licence is MIT, with the first and only tagged release being 1.0.0 in June 2026 and the last push on 2026-10-16.

Installing through the Unity package manager, with a Gitee mirror

The package installs through the Unity Package Manager as a git URL, and the recommended approach is to install from the release branch so that the user does not have to name a version. The GitHub URL points at the repository with a path selector for the package directory, and there is a Gitee mirror with the same shape, the recommendation being to use the Gitee address when GitHub access is unreliable, which is a real consideration for a team working in that region. The URL itself, for the GitHub version, points at the repository with a path selector for the package directory:

https://github.com/ZHOURUIH/MyFramework.git?path=/Packages/com.zhourui.myframework

In the editor, the path is Window, then Package Manager, then the plus button, then Install package from git URL, and you paste the URL there. After the plugin is installed, a new project has no default startup scene, no business entry script and no runtime configuration file, and the initialisation menu creates them. The two menu entries are a plain initialisation and one that also sets up HybridCLR and Obfuz.

What the initialisation actually generates

The initialisation step is a list of file operations, and reading it tells you what the framework expects to exist. It copies the default project files from the ProjectTemplate folder, generates the startup scene at Assets/Resources/Scene/start.unity, generates the frame settings asset at Assets/Resources/Settings/FrameSettings.asset, generates the framework settings asset at ProjectSettings/MyFrameworkSettings.asset, attaches the GameEntry script to the GameEntry node of the startup scene, and adds that scene to the build settings. The HybridCLR plus Obfuz variant does more on top: it installs HybridCLR, installs Obfuz, adds the USE_HYBRID_CLR and USE_OBFUZ defines, and sets the generated code output directory to Assets/Scripts/AutoGenerated. That last point is worth noting on its own, because it tells you where the code generation output lands, and therefore where you should not put your own hand-written files. The README also flags an input system conflict that will bite you on a fresh project.

The old input API is a documented rough edge

The framework and its default startup scene still use some older input interfaces, specifically UnityEngine.Input and StandaloneInputModule. If your project has the Input System package enabled and you see the runtime message about trying to read Input using the UnityEngine.Input class, the fix is a manual change in the editor, under Project Settings, then Player, then Other Settings, and setting Active Input Handling to Both. The change usually needs an editor restart to take full effect. This is the kind of detail that the framework could have handled for you and has not, and it is a fair indication of the overall shape of the project, which is a set of conventions the team follows rather than a set of guarantees the framework provides.

UI, configuration tables and protocols are all generated

The three code generation paths are the heart of the framework, and each replaces a category of hand-written boilerplate. The UI generator works from the nodes you mark on a UI prefab and emits the member variables, the node lookup code and the registration logic, keeping whatever logic you wrote by hand. It supports single nodes and array nodes, and it generates the member variables, an assignWindow method, the construction code and the registration code. The configuration chain uses CSV as the table format with a custom table editor, and it checks field types, enum validity, id uniqueness, table references and asset paths, then generates both client and server table code plus the runtime check logic, so the errors show up while you are editing the table rather than at runtime. The protocol chain generates client and server message code from a protocol configuration, covering message classes, field serialisation, deserialisation, message registration and the per-side code, again preserving hand-written logic. The point of all three is the same, which is that the description of the data lives in one place and the code follows.

Five layers, and only two of them can be patched

The hot update layering is the architectural commitment that shapes everything else, and it is worth reading closely because it cannot be changed later. The framework code is divided by whether it can be hot updated. Frame_Base is the most basic framework code and is not hot updatable. Frame_Game is framework code for the project that is not hot updatable. Game is the project application layer start-up logic and is not hot updatable. Frame_HotFix is framework layer hot update code and is hot updatable. HotFix is the project application layer hot update code and is hot updatable. The dependency relationships follow from that, and they are simple enough to state in full:

Frame_Base -> Frame_HotFix -> HotFix
Frame_Base -> Frame_Game   -> Game
Game       -> HotFix

So Frame_Base feeds both Frame_HotFix and Frame_Game, Game depends on HotFix, and Frame_HotFix feeds HotFix. The stated purpose is to give both the framework layer and the business layer a high degree of hot update capability while keeping the necessary start-up stability, which is the trade every hot update system has to make.

The rest of the framework, from the feature table

The feature overview table lists what is done and what is not, and the unfinished entries are as informative as the finished ones. HybridCLR, Obfuz, the UI framework, the UI code generation, the custom input system, asset management with AssetBundle, the four network transports TCP, UDP, WebSocket and HTTP, the network message generation, the three serialisation formats, the CSV configuration chain, the pooling for class objects, lists, GameObjects, Prefabs and Effects, the tween system and the multi-language support are all marked as complete. The newbie guide, the Google login, the Google payment and the AAB PAD packaging flow are marked as partially split, to be organised, or to be tidied. A separate feature section covers the UI framework, which avoids the business layer touching native Unity components, supports infinite scrolling lists, checkboxes, sliders, progress, dropdowns, long press, double click, drag, click-through, UI object pooling and code generation, and deliberately avoids relying on UGUI anchors and auto layout in favour of explicitly controlling position, size, visibility and input in code. The input system is custom too, replacing the UGUI EventSystem as the main input dispatch path with its own unified detection for mouse, touch, click, double click, long press, drag and click-through.

A companion server framework and a comparison table

There is a matching server framework in a separate repository, and the two are designed to share the protocol generation and the configuration table tool chain, which the readme says suits medium and large projects needing long term maintenance. The networking layer supports TCP, UDP, WebSocket and HTTP, with automatic message registration, generated message code, and three serialisation formats, JSON, byte serialisation and a bit level serialisation that reduces bandwidth further. Alongside that sit a command system for encapsulating events with complete logical meaning, used for logic encapsulation, module communication, decoupling UI from logic, deferred execution, main thread scheduling and log tracking, and a component system that organises some logic by composition rather than complex inheritance. The readme ends with a positioning table against GameFramework, ET and TEngine, and it is careful to say the table is only to explain design direction and is not a comparison of quality. The verification table gives the numbers the author claims, with five plus years of iteration, the author's own project on Unity 6000.2 and a recommended Unity version of 2022.3 LTS or newer, a client project of more than 200,000 lines and a server project of more than 200,000 lines.

Editorial conclusion

MyFramework suits a studio building a long-lived Unity client and server pair where hand-written binding and protocol code has become a maintenance burden, and where the team wants the generated code to be the single source of truth. It does not suit a small project, since the setup involves a package install, an initialisation pass and a tool chain you have to learn, and the readme is written in Chinese. Before adopting it, read the hot update layering, because the Frame_Base and Game layers being unpatchable is a permanent architectural constraint rather than a setting, and check that you can commit to a 200,000 line codebase and a companion server framework, since the client and server are designed to share their tool chain.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. ZHOURUIH/MyFramework on GitHub