GameDevelopmentKit wires Unity, ET and HybridCLR into one pipeline

A framework that is really an integration

GameDevelopmentKit, GDK, is described as a Unity game development framework. The server side is built on ET 8.1 and the client side uses UnityGameFramework, also called GF, as its base, and you can choose between a pure GF mode, GameHot, and an ET development mode. The interesting part of the project is that most of its identity comes from how it assembles other people's projects rather than from what it implements itself. The dependency table lists the core frameworks as UnityGameFramework, UGFExtensions and ET 8.1, the hot update and configuration layer as HybridCLR, Luban and a Luban Extension, the async, serialisation and networking layer as UniTask, a MemoryPack Extension, Protobuf Unity and UnityWebSocket, and the UI and binding layer as UXTool, CodeBind, StateController, ReactiveBinding and LoopScrollRect. Several of those extensions are the author's own repositories, listed under the XuToWei organisation, which tells you where the real work sits. The project code itself is MIT licensed, and the README states that third party resources and plugins follow their own licences.

Two run modes, one compile symbol each

The run mode table is the piece to read before anything else, because the choice is baked into the build. The pure GF mode, GameHot, uses the compile symbol UNITY_GAMEHOT, which is marked as mandatory, and suits using the GF client while loading the GameHot business assemblies. The ET mode uses UNITY_ET and covers the ET entity system and a business model shared between client and server. The HybridCLR mode stacks on top with the symbol UNITY_HOTFIX and changes the current business module into a DLL resource load. The rule is stated plainly: UNITY_ET and UNITY_GAMEHOT are mutually exclusive, while UNITY_HOTFIX can be stacked. So the axis is really two axes, one choosing between the two development approaches and the other choosing how the business code is loaded. The editor keeps the rest in sync when you switch, updating the Luban project, the resource collection rules, link.xml and the HybridCLR assembly list, which is the kind of automation that makes the choice survivable, because otherwise four separate places would need editing by hand every time you switched.

Configuration and protocols come from code generation

The data and protocol row of the capability table is where the framework earns its keep. Luban exports the configuration, and a Proto2CS tool generates the ET and MemoryPack protocol code and the GF and Protobuf protocol code from the same definitions. Generating both sides from one source is the whole point, because a protocol that has been hand-written twice is a protocol that will drift, and in a client and server codebase the drift shows up as a field that is silently zero on one side. The other two layers follow the same pattern of generating rather than writing. ReactiveBinding, CodeBind and StateController cover reactive data, component binding and UI state, so the UI is driven by generated bindings rather than by manual assignments in every panel. In the editor tools row, code generation, package update, the toolbar and one click build are listed together, which reflects the reality that a framework with a hot update path is as much a build pipeline as a runtime library.

Hot updates through HybridCLR

HybridCLR manages the hot update assemblies, the AOT metadata and the build process, and the run mode table describes what that means in practice: with UNITY_HOTFIX set, the current business module becomes a DLL resource load rather than compiled into the player. The value of that is iteration speed, because a logic change can be pushed as a DLL without a full player rebuild and a store submission, and the cost is a constraint set on what the hot code may do. There is also a second meaning of the word hot in this project, which is the GameHot business assembly in the pure GF mode, and the two should not be confused. The documentation navigation points at a dedicated page for HybridCLR hot updates and another for one click packaging, so the build side is treated as a first class topic rather than an afterthought. The Unity side of the framework lives under the Unity/ directory, and the ResourceOptimize utility referenced in the capability table points at a specific editor script path, which suggests resource redundancy reduction is handled at build time rather than by convention.

Getting the tool projects built first

The quick start assumes you have the .NET 8 SDK and Unity 6000.3.18f1 installed, and the first build step is the tool projects rather than the Unity project. You compile the solution from the repository root:

   dotnet build Kit.sln

The same solution can be built from Rider, or from inside Unity through the Game > Build Tool Editor menu. The repository root holds Kit.sln and Kit.sln.DotSettings, alongside Config/, Design/, DotNet/, Share/, Tools/, Unity/ and a Book/ directory for documentation, with an AGENTS.md and a CLAUDE.md at the top. The Unity side is then opened from the Unity/ directory, you load the Assets/Launcher.unity scene and press Play, which is the launcher entry point rather than a sample game. The design documentation is a separate directory from the source, and there is a TODO.md at the root, which tells you the project is still moving and that the public roadmap is in the repository rather than only in the discussion group.

What the framework leaves to you

There are two gaps a reader should notice. The first is the commercial dependency. The README lists Odin Inspector as a commercial plugin that you need to buy separately and whose licence terms you must follow, and Odin is a paid Unity asset rather than an open source library, so a project that relies on it is not licence-clean without a purchase. The second is the breadth of the dependency surface. A framework built from UnityGameFramework, an ET fork at a specific commit, UGFExtensions, HybridCLR, Luban, a fork of Luban, UniTask, a MemoryPack extension, a Protobuf Unity fork, UnityWebSocket, UXTool, CodeBind, StateController, ReactiveBinding, LoopScrollRect, SocoTools and FolderTag is a stack that has to be kept in step, and several of those entries are forks pinned to particular commits. The ET dependency in particular is linked to a specific commit hash rather than a branch, which is the correct thing for reproducibility and means upgrades are deliberate work. There is a QQ group listed for discussion, and the licence split is stated plainly, with the project code under MIT and third party resources and plugins under their own terms.

Editorial conclusion

Adopt GameDevelopmentKit when your Unity project needs a real server, a hot update path and a shared protocol and configuration layer between the two, and you are prepared to work in a framework that stitches together several other projects. Do not adopt it for a client-only game, because the ET integration, the ETUI and ETEntity layers and the dual run modes only make sense with a server in the picture. Verify first which run mode suits your project, since UNITY_ET and UNITY_GAMEHOT are mutually exclusive while UNITY_HOTFIX stacks on top, that your Unity version matches the 6000.3.18f1 the setup instructions name, and that you are comfortable buying Odin Inspector separately, since that commercial plugin is not included.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. XuToWei/GameDevelopmentKit on GitHub