Legends-Of-Heroes: an ET 10 C# game framework with a server-authoritative combat core

What problem Legends-Of-Heroes solves, and who it is aimed at

Most Unity multiplayer samples put authority on the client and reconcile later. Legends-Of-Heroes goes the other way. The README states that the project uses state synchronization and that all collision detection, skill, and AI logic runs on the server. The client renders broadcasted state. That single decision shapes everything else in the repository: the server carries the gameplay ECS, and the client is mostly input, UI and presentation.

The target reader is a C# gameplay engineer who already knows Unity and wants a multiplayer skeleton with the boring parts attached: login, lobby, room and map routing through the Actor Location system, a Luban config pipeline, YooAsset bundle loading, and a HybridCLR hot-update path. The README describes the project as "a front-end and back-end game framework built on the ET framework" with "a relatively complete combat system". The demo is a LOL-style ball battle, which is a small enough game to read end to end.

It is a poor fit for single-player projects, for teams that want a pure client-side physics game, and for anyone who needs the tooling finished. The README is explicit that the skill editor and behavior-tree editor are still under development.

How the ET Actor plus ECS split actually carries a match

The architecture diagram in the README shows two processes. The server process runs on .NET 10 and holds Actor Location and message routing for login, lobby, room and map, then a gameplay ECS layer with skill, buff, timeline, collision, behavior tree, AOI, move and lockstep, then Model and Hotfix assemblies, then DB, Redis and Luban config. The Unity client holds an EUI (UGUI) or YIUI UI layer, joystick and camera follow, HybridCLR for hot update, YooAsset 3.0 for assets and bundles, and its own ModelView and HotfixView ECS assemblies.

The two sides share the cn.etetet.* packages, which is where the ET assembly split lives: Model, ModelView, Hotfix and HotfixView. The README says each package follows this split for hot reload, and that the full module list is under Packages/ with more than 70 packages. Transport is TCP, KCP or WebSocket, carrying state sync plus position broadcast. Distributed topologies use servicediscovery and router, managed through .NET Aspire.

The consequence for a gameplay programmer is that adding a skill is a server-side change. You write the ECS component and system in the shared Hotfix assemblies, and the client picks up the resulting state broadcast. That is a real constraint, not a stylistic one: anything that must be deterministic or authoritative cannot live in the Unity project. The upside is that a client cannot cheat by editing skill logic, because the skill logic is not there.

Installing Legends-Of-Heroes and getting the ball battle running

There is no package registry entry for this project. It is a repository checkout, and the README points at the GitHub repository itself rather than a download page. Because the framework depends on ET, the practical first step is to obtain the repository and open the solution in the toolchain the README names: .NET 10 for the server and Unity 2022.3.62f3 for the client.

git clone https://github.com/FlameskyDexive/Legends-Of-Heroes.git
cd Legends-Of-Heroes

After cloning, the two entry points are ET.sln for the server-side C# solution and the Unity project rooted at Assets/ and ProjectSettings/. Open ET.sln in an IDE with .NET 10 support and let the cn.etetet.* packages under Packages/ restore. The README does not document a single build script, so expect to build the server project from the solution and then open the Unity project separately.

For the demo itself, the README links a video at Document/loh.mp4 with a cover image at Document/loh-cover.png. The README notes that GitHub renders the MP4 as an inline player when you open the file directly. Watching it before you build is the cheapest way to confirm that what you are about to run matches the intended ball battle.

The README does not give a start command, a port number or an environment variable for launching the server, and it does not document rollback. Treat the first run as an exploration of the solution structure rather than a documented procedure.

Where the framework is thin: editors, documentation and the hot-update boundary

The most concrete limitation is stated in the README itself: the skill editor and behavior-tree editor are still under development. The ECS-based skill and Buff system is described as already in place, and the behavior tree node library is exposed through the btree, btnode and btreedemo packages, but authoring content through a GUI is not finished. If your workflow assumes designers build skills in an editor, you will be writing data by hand or building the editor yourself.

A second boundary is the hot-update split. HybridCLR and YooAsset are listed on the client side, and the cn.etetet.* packages follow the Model, ModelView, Hotfix, HotfixView assembly split. That structure exists to make hot reload possible, and it also means code placement matters: put a system in the wrong assembly and it will not hot-update. The README does not spell out which assembly each kind of logic belongs in.

Documentation is the third gap. The README is a feature list plus an architecture diagram, and it is truncated in places mid-sentence. There is a docs/ directory and a Book/ directory in the repository, but the README does not describe what either contains. Installation, launch configuration and rollback are not covered. For a framework that claims to be production-ready, that is a mismatch between the claim and the written material.

How it differs from a client-authoritative Unity framework

The obvious alternative is a client-authoritative Unity framework, where gameplay logic runs in the Unity project and the server relays or validates. That approach is simpler to build for, because a developer stays in one language, one editor and one debugging loop. Legends-Of-Heroes trades that convenience for server authority: the README's state-synchronization design means collision, skills and AI all execute on the .NET 10 process, and the client renders what it receives.

The difference shows up in what you can trust. In a client-authoritative design, the server has to re-derive or police what the client claims happened. Here the server is the only place the logic exists, so the client cannot produce a state the server did not compute. The cost is latency handling: the client has to render broadcast state, and the README lists move and lockstep packages on the server side rather than describing a client prediction system. The README does not document how input is buffered or how prediction and reconciliation work, which is the part a client-authoritative framework would have handled differently.

A second alternative is to use ET directly, without this project's combat layer. ET provides the Actor model and the assembly split; Legends-Of-Heroes adds skill, buff, timeline, collision, AOI and behavior tree packages plus the ball battle demo. Choosing ET alone means less code to read and no demo to reverse-engineer, but also no worked example of how combat fits into the Actor topology.

Maintenance, licence and the cost of keeping up with ET

The repository is not archived, and the last push was on 2026-07-27. There are no retrieved releases, so there is no versioned upgrade path to follow; the practical upgrade unit is the commit.

The upgrade cost is dominated by the ET dependency. The README's own header calls this a framework built with ET 8.x in one place and describes the project as based on ET 10 elsewhere, and the repository description says ET 10. That inconsistency in the README is worth resolving before you start, because it determines which upstream ET branch your cn.etetet.* packages track. The README also points at the ET repository at github.com/egametang/ET as the base framework. When ET changes its package layout or assembly split, this project has to follow, and any local changes you make in the shared Model and Hotfix assemblies become merge work.

The licence is MIT, per the repository metadata and the licence badge in the README. MIT permits commercial use and modification with the copyright notice preserved. That is a permissive starting point, but it says nothing about the licences of the third-party packages the project depends on, including ET itself, HybridCLR, YooAsset and Luban. Those need to be checked separately for your distribution model. This is not legal advice; confirm the dependency licences with your own counsel.

Editorial conclusion

Adopt Legends-Of-Heroes if you are building a server-authoritative multiplayer game in C# and want ET's Actor plus ECS split, a Luban config pipeline and a working combat demo to start from. Do not adopt it if you need a shipped skill editor or behavior-tree editor today, or if your team has no ET experience to spend on the learning curve. Before committing, verify that the solution opens under .NET 10 and Unity 2022.3.62f3, that the cn.etetet.* packages under Packages/ restore, and that the Document/loh.mp4 demo runs from your own checkout.

Frequently asked questions

Official sources

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