Legends-Of-Heroes: an ET-based state-sync MOBA framework with a ball-battle demo

The problem Legends-Of-Heroes addresses

Writing a multiplayer action game in C# usually means solving the same set of problems before you write a single line of gameplay: where authoritative simulation runs, how clients receive state, how skills and buffs are modelled so they can be data-driven, how assets and code get updated after release, and how a build pipeline produces both a Unity client and a server binary from shared logic. Legends-Of-Heroes is an attempt to answer those questions once and hand you the result. The README describes it as a front-end and back-end game framework built on the ET framework, with a basic hot-update pipeline and a combat system that already includes an ECS-based skill and Buff implementation. The intended audience is a team that has decided on Unity for rendering and C# for server logic, and would rather extend an existing ET-derived codebase than start from an empty solution. The bundled ball-battle demo exists to show the pieces connected, not to be a shippable game.

State synchronization means the server owns the simulation

The architectural decision that shapes everything else is state synchronization. The README states plainly that all collision detection, skill, and AI logic runs on the server, and clients render broadcasted state. That is the opposite of a lockstep or client-prediction-first design, and it has consequences you should weigh before adopting. On the plus side, there is no client trust surface for hit detection or skill resolution, and no need to keep a deterministic simulation in sync across machines. The cost is bandwidth and latency tolerance: the server must broadcast enough state for clients to render convincingly, and every input round-trips. The README also lists lockstep among the server-side gameplay modules, so the repository appears to contain both approaches, but the stated default for the demo is state sync. If your game is a slow-paced MOBA or a small-room action game, this trade is usually acceptable. If it is a 100-player battle royale, the broadcast volume is the first thing you should measure.

How the client, server and shared assemblies fit together

The architecture diagram in the README shows three cooperating parts. The client is Unity 2022.3.62f3, with EUI and YIUI for UI, HybridCLR for hot update, YooAsset 3.0 for asset and bundle management, and ModelView plus HotfixView assemblies holding client-side ECS code. The server is a .NET 10 process running Actor Location and message routing across login, lobby, room and map roles, with gameplay ECS covering skill, buff, timeline, collision, behavior tree, AOI, movement and lockstep. Below both sit shared Model and Hotfix assemblies distributed as cn.etetet.* packages. The README says the full module list lives under Packages/ and that there are more than 70 such packages, each following ET's Model, ModelView, Hotfix, HotfixView assembly split so logic can be reloaded. Transport is TCP, KCP or WebSocket, and the README mentions servicediscovery and router packages for multi-process topologies managed through .NET Aspire. The tooling column lists harness, unitybridge, an AIBridge CLI and UnityMCP.

Getting it running: what the repository tells you

The README does not include a step-by-step setup section in the material available here, and that is a real gap for anyone evaluating the project. What it does give you is the shape of the workflow. You need Unity 2022.3.62f3 for the client and a .NET 10 SDK for the server, since the server process targets .NET 10 and the description names .net10 alongside Unity 2022.3.62. Configuration is authored with Luban, and the README lists Config (Luban) inside the server process alongside DB and Redis, so you should expect a Luban table set to be generated before the server starts. Assets are handled by YooAsset 3.0, and code hot update by HybridCLR. The demo video is checked in at Document/loh.mp4 with a cover image at Document/loh-cover.png, and the behavior-tree screenshot is at Document/et-bt.png. Package-level detail lives in Packages/cn.etetet.*, and the AI workflow hooks are pointed at Packages/cn.etetet.harness/. Anything beyond that, including exact build commands, is not in the supplied material and should be read from the repository before you plan an integration.

The combat stack and what is still missing from it

The combat system is the most developed part of the project. The README says an ECS-based skill plus Buff system is already in place, and the layer table assigns skill, spell, behaviortree, collision and aoi to separate server packages. The behavior tree has an in-engine editor, with the node library exposed through the btree, btnode and btreedemo packages, and the README includes a screenshot of it. The honest caveat is stated in the README itself: the skill editor and behavior-tree editor are still under development. That sentence is worth reading twice, because it means the behavior-tree editor screenshot may show a work-in-progress tool rather than a finished one, and it means skill authoring may currently require editing data by hand. For a framework whose selling point is a complete combat system, the authoring layer being incomplete is the single largest gap. Teams that only need runtime skill and buff resolution will be fine. Teams that expect designers to author skills in a GUI should verify the current state of that editor at the commit they intend to use.

Where this is the wrong choice

There are cases where Legends-Of-Heroes is not the right tool. If your game is single-player or peer-to-peer, the entire server process, Actor Location routing and state-sync broadcast layer are overhead you would be paying for and then working around. If your team is not on Unity, the client half is unusable, though the server-side packages could in principle be extracted. If you need a deterministic lockstep RTS with replay from input logs, the default state-sync model is a mismatch even though a lockstep package is listed. And if you need documentation you can hand to a new hire on day one, this is a thin repository: the English README is a summary, and the project is primarily Chinese-language, with a README.zh-CN.md linked alongside the English one. None of these are defects in the framework. They are boundary conditions, and knowing them early saves a wasted sprint.

Alternatives and how they differ

The most direct alternative is the upstream ET framework itself, which this project builds on. ET provides the ECS plus Actor foundation, the Model/Hotfix assembly split and the cn.etetet.* package ecosystem, but it does not ship a combat system, a ball-battle demo or a state-sync gameplay layer. Choosing ET means starting lower and owning more decisions. Choosing Legends-Of-Heroes means inheriting those decisions along with the code that implements them. A second comparison point is Photon Quantum or Fusion, which take the opposite approach: they run a deterministic or predicted simulation and lean on client-side prediction and rollback rather than server broadcast. That gives better perceived latency in fast action games but requires you to write your simulation to be deterministic, which is a constraint ET's ECS does not impose on you. The choice comes down to whether you would rather fight bandwidth or determinism.

Licence, dependencies and the cost of keeping up

The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That covers the code in this repository, but the README describes a large dependency surface: 70-plus cn.etetet.* packages, the ET framework itself, YooAsset, HybridCLR, Luban, EUI and YIUI. Those carry their own licences, and the supplied material does not enumerate them. Check each one against your distribution model, particularly if you plan to ship a closed-source client. On maintenance, the repository was last pushed in July 2026 and is not archived, and the README notes that the skill and behavior-tree editors are still under development, so you should expect upstream movement in those areas. The practical upgrade cost is concentrated in the ET package set and in Luban-generated configuration: a Luban schema change ripples into generated code on both client and server, and an ET package bump can touch the Model/Hotfix assembly split. Pin your package versions and treat upgrades as planned work rather than incidental maintenance.

Editorial conclusion

Adopt Legends-Of-Heroes if you are building a server-authoritative multiplayer game in C# and want a working ET-derived baseline for skills, buffs, AOI and collision rather than assembling those pieces yourself. Do not adopt it if you need a finished skill or behavior-tree authoring tool, or if your team cannot read Chinese documentation and source comments, because the English README is a summary rather than a full guide. Before committing, verify that the skill editor and behavior-tree editor are usable at your target commit, that the demo's state-sync bandwidth profile matches your player count, and that every cn.etetet.* package you depend on carries a licence compatible with your distribution plans.

Official sources

1. FlameskyDexive/Legends-Of-Heroes on GitHub
2. Issues
3. License: MIT
4. README