EGamePlay: a Unity combat and skill framework built on Entity-Component and EcsNode

What EGamePlay actually solves for a Unity RPG team

Combat code in a Unity RPG tends to rot in a predictable way. Damage formulas, buff stacking and skill timing end up inside MonoBehaviours that also drive animations and particle effects, so a designer cannot change a skill without a programmer, and a programmer cannot change a hitbox without touching gameplay balance. EGamePlay is the author's answer to that: a combat and skill framework that keeps the data and the logic apart, and keeps the business logic apart from the view logic. The target user is a Unity developer building an RPG or MMORPG who wants to define abilities as data and let runtime systems execute them.

The README points to a shipped example rather than a hypothetical one. The commercial game listed there, Dark Land (暗黑之地), is described as a one-person project whose entire combat was rewritten with EGamePlay before relaunch. That is a single data point, not a benchmark, but it says the framework has survived contact with a released title. It also sets the scale: one developer, not a combat team of ten.

The scope is deliberately narrow. This is not a character controller, an inventory system or a netcode layer. It is the ability, buff and status machinery that sits between your input and your animation.

Entity-Component plus EcsNode: how the runtime is put together

Version 3.0 is described in the README as a runtime rewrite, not a data change. The ability configuration structure is the same as before; what moved is the code that executes it. The rewrite pulls in a second repository by the same author, EcsNode, and adds a System concept on top of the Entity-Component pattern. The stated goal is a three-way split: logic separated from data, and business logic separated from view logic.

That split is visible in the repository layout. Assets/Game.Model holds the data side, Assets/Game.System holds the system side, and the README's porting instructions tell you to sort files by whether their folder name contains View or Unity: Game.MapView and Game.UnitySystem are view code, everything else is pure business code. The framework also carries its own third-party directory, Assets/Game.ThirdParty.

Configuration is where the framework makes its most opinionated choice. Ability effects are authored as ScriptableObject assets through the Odin Inspector-based editor tooling, and skill tables live in Excel under the top-level Excel/ directory. The README describes two entry points in the Unity menu: Assets/Create/能力/能力配置 for ability effect assets, and Tools/EGamePlay/SkillEditorWindow for the skill editor window. A separate Tools/导出配置 menu item generates JSON and configuration classes from the Excel sheets. So the pipeline is Excel or ScriptableObject in, generated classes and JSON out, EcsNode systems at runtime.

One consequence worth naming: because the runtime was rebuilt on EcsNode, the framework is coupled to that second repository. Upgrading EGamePlay means tracking EcsNode as well.

Installing EGamePlay and authoring a first ability

There is no package manager install in the README. The project is used by copying directories into a Unity project, and it targets Unity 2022.3.53f1 as stated in the version badge. The README's porting section gives the prerequisite plainly: Odin Inspector must already be in the project, and the UNITY conditional compilation symbol must be added. Then you copy these directories across.

/Assets/Gizmos
/Assets/Game.Model
/Assets/Game.System
/Assets/Game.ThirdParty
/Assets/Unity.EditorScripts/Editor
/Assets/Unity.Scripts/UnityMono/EGamePlay
/Assets/Plugins/Editor/npoi
/Excel

The README does not claim this is clean. It says the integration is not yet perfect and that conflicts or missing pieces will appear during the port and have to be handled case by case. Budget time for that, because the list spans editor scripts, runtime MonoBehaviours and a bundled NPOI build for Excel parsing.

If you would rather see it run before porting it, the repository ships scenes. The RPG demo runs from the RpgExample scene, and the skill debugging editor runs from ExecutionLinkScene. Those two scenes are the fastest way to confirm the framework compiles and behaves in your Unity version.

The README's four-step recipe for a new skill is short enough to quote in full. Add a skill row with an id and parameters in AbilityConfig.xlsx. Right-click in the Project panel and choose 能力/能力配置 to create the ability config asset for that id, then choose 能力/Execution to create the matching execution body that configures the fragment presentation. At runtime, attach the skill to a CombatEntity and release it through the SpellComponent. The naming matters here: the ability config, the execution body and the Excel row all key off the same skill id, so a mismatch between them is the first thing to check when a skill does nothing.

The paid-plugin dependency is the real adoption cost

EGamePlay is MIT licensed, but the MIT licence covers the code in this repository only. The README lists three paid Asset Store plugins the project uses: DOTween Pro, Odin Inspector and Animancer Pro. Odin Inspector is not optional in practice, because the ability configuration tooling is built on it and the porting instructions require it to be present before you copy anything. That means the effective entry price is the cost of those licences, per seat, on top of the free framework.

This is the point where a team evaluating the framework should stop and check what it already owns. A studio that has standardised on Odin and DOTween pays nothing extra. A solo developer starting from zero pays for three plugins before writing a line of combat code, and the framework will not compile without at least Odin.

The bundled NPOI editor plugin is a related constraint. It exists because Excel parsing happens in the editor, which is what makes the Tools/导出配置 workflow possible. It also means the Excel path adds an editor-side dependency that the ScriptableObject path does not need. If you never intend to use Excel, the ScriptableObject route avoids that piece entirely.

Where EGamePlay is the wrong choice

The README labels the project status as work in progress, and the honest reading is that this is a framework you port and adapt, not one you install and forget. The porting sections for a plain Unity project and for the ET framework both end with the same admission: the integration is not perfect and conflicts or missing pieces must be resolved as they come up. If your team cannot afford to debug someone else's framework inside its own codebase, that sentence should end the evaluation.

Launching the project also means accepting a Unity version floor. The badge names 2022.3.53f1, and nothing in the README suggests a tested range below it. Projects on older Unity LTS lines have no documented path.

The demo situation is a second limitation. Version 3.0 removed the turn-based demo and kept only the RPG example; turn-based samples live on the 2.0 and 1.0 branches. If your game is turn-based, you are reading the wrong branch's documentation and the wrong branch's runtime.

Finally, the ET framework port is explicitly partial. The README says the ETHelper folder contains old ET code that conflicts with the ET framework itself, that it can be deleted and replaced with the framework's own code, and that the config table workflow also has to be moved to ET's own flow. That is a porting project, not a configuration step.

How EGamePlay differs from the other Unity skill systems it links to

The README's own comparison list is the most useful part of the repository for a decision. It links five alternatives, and the differences are about architecture rather than features.

UnityGameplayAbilitySystem is described as taking its approach from Unreal's Gameplay Ability System but implementing it in Unity with DOTS where possible. That is the opposite bet from EGamePlay. DOTS pushes toward data-oriented, job-friendly structures; EGamePlay keeps ScriptableObject assets and Odin-driven editor tooling, which is friendlier to designers and to teams without DOTS experience. If your project is already committed to DOTS, the DOTS-based option fits your architecture better regardless of which one is more pleasant to author in.

SkillSystem by dongweiPeng is described as having a rich interface set for extension, a complete skill effect flow with flowcharts, a paired skill manager and custom skill data tables. EGamePlay's own selling point is narrower and sharper: Excel or ScriptableObject configuration with a generated JSON and class pipeline, plus a dedicated skill editor window and a debugging scene for execution links. The dx50075 SkillSystem is a different flavour again, with skills written as text descriptions such as a skill id followed by FaceToTarget, PlayAnimation, Bullet and PlayEffect calls. That is a compact scripting format; EGamePlay is a data-asset format with a GUI on top.

The ET framework link is not an alternative so much as a host. EGamePlay's README documents porting into ET 8.1, which tells you the author expects the framework to live inside a larger server-and-client architecture rather than stand alone.

Maintenance, licence and upgrade path

The repository is not archived, and the last push was on 2026-09-02, which is within the last month. There are no releases listed, so there is no tagged version to pin to and no changelog to read before upgrading. The README instead organises history by branch: 3.0 on main, 2.0 on the 2.0 branch, 1.0 on the 1.0 branch. That is a workable versioning scheme for a single-author project and a poor one for a team that wants to diff two releases.

The upgrade cost has a specific shape. Because 3.0 kept the ability configuration data structure unchanged and rewrote the runtime, a move from 2.0 to 3.0 should leave your ScriptableObject assets and Excel sheets intact while your integration code changes. That is the author's claim, and it is the thing to verify against your own fork before merging.

On licensing, the MIT licence on this repository is the only licence fact stated. The three Asset Store plugins are governed by their own terms, and the README does not discuss redistribution or what happens to a shipped build. Anyone planning to ship should read those plugin licences directly rather than assume the MIT header settles it.

Editorial conclusion

Adopt EGamePlay if you are building RPG or MMORPG combat in Unity 2022.3.53f1, you already license Odin Inspector, DOTween Pro and Animancer Pro, and you want ability data in ScriptableObject assets or Excel rather than in code. Do not adopt it if you need a drop-in package with no paid editor dependencies, if you are not on Unity, or if you want a finished turn-based sample: the 3.0 branch keeps only the RPG demo and the turn-based demo lives on the 2.0 and 1.0 branches. Before committing, verify that your Odin Inspector licence is in place and that the UNITY conditional compilation symbol the README requires is actually defined in your project, because the porting steps list both as prerequisites and the README states the integration is not yet perfect.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. m969/EGamePlay on GitHub
4. README