Warcraft Arena is a WoW-style combat system with the netcode kept out of the gameplay

A combat engine, not a finished game

Warcraft Arena is described as a World of Warcraft style combat system built in Unity, playable in single-player, over LAN, or on an online server, and it also ships a standalone Path of Exile Sirus boss-fight game mode. The framing is accurate and worth holding on to. What exists is a combat system with a mage spell kit, auras, a spell effect model, an arena location based on the Lordaeron map, and a lobby to start a session from. The single-player mode plays against AI and scripted encounters, the LAN mode hosts or joins a session on the local network, and the online mode uses Unity Gaming Services Lobby and Relay for matchmaking. The Sirus encounter is a single-player boss fight against Sirus, Awakener of Worlds, described as a fast-paced bossfight shooter built on top of the same combat engine. So the project is a platform with one demonstration game mode, and the interesting engineering is in the platform.

The networking framework is confined to adapter assemblies

The architecture section is the most transferable idea in the project, and it is enforced rather than merely intended. The codebase is split into assemblies with `.asmdef` files and a strict dependency direction, so gameplay logic never depends on any networking framework. `Game.Core` holds pure gameplay, units, spells, auras and combat, and references only `Game.Common`. Below it sits `Game.Net.Abstraction`, which defines framework-neutral interfaces and messages, and below that sit two implementations: `Game.Net.Local` for the single-player and offline backend, and `Game.Net.Ngo` for the Netcode for GameObjects backend. `Game.Server` holds authoritative server logic and `Game.Client` holds presentation, itself split into `Game.Client.UI` for unit frames, action bars, lobby and chat, `Game.Client.Effects` for spell, projectile and aura VFX, `Game.Client.Sound` and `Game.Client.Localization`. The networking layer itself is drawn as an abstraction with two implementations beneath it.

Game.Net.Abstraction  ◄── framework-neutral interfaces & messages
   ├── Game.Net.Local  (single-player / offline backend)
   └── Game.Net.Ngo    (Netcode for GameObjects backend)

The README states that the networking framework lives only in the adapter assemblies, and that the asmdef dependency graph enforces that wall at compile time. The point is that the backend is swappable, and the compiler is the thing that stops the wall from eroding.

Photon Bolt was dropped for Netcode for GameObjects

The project's networking history is stated plainly in the README, and it explains a lot about the current shape. The project originally used Photon Bolt. That backend has been deprecated, and the old version is preserved on a branch called `photon-bolt`. The `master` branch now runs on Unity Netcode for GameObjects behind the framework-agnostic networking layer described above. The repository description still mentions Photon Bolt, which is a leftover from when the project description was written. Two lessons sit in that history. The first is that the abstraction was retrofitted, and the retrofit is visible in the assembly names, where `Game.Net.Ngo` and `Game.Net.Local` sit side by side as interchangeable implementations of the same interface. The second is that the Photon Bolt branch is a complete earlier state of the project, which is useful reading if you want to see how the gameplay code looked when the network calls were direct, and useful as a fallback if a Photon based deployment is what you actually need.

Spells and auras are ScriptableObject assets

Combat is described as fully data-driven, with content consisting of reusable ScriptableObject balance definitions. A spell is assembled from one or more spell effects, which are the things a cast does, and an aura is assembled from one or more aura effects, which are the persistent buffs and debuffs a spell applies. The documented spell effects are Damage, Heal, Apply Aura, Area Effects, Direct Teleport, Dispel Mechanics, Kill and Resurrect. The aura effects list is longer: Periodic Damage, Periodic Healing, Absorb Damage, Damage Reduction, Critical Damage, Haste, Speed, Stat Mod, Spell Modifier, Spell Trigger, Stun, Freeze, Root, Silence, Pacify, Confuse, Immunity, Slow Suppression, Ignore Aura State and Display Model. The README's own conclusion is that new abilities are largely a matter of authoring assets, and it points to a wiki guide on adding a new spell. What you get is therefore a fairly complete effect vocabulary, and the work of a new ability is composition rather than programming.

The mage kit and the systems around the fight

The included content is a World of Warcraft Mage kit plus a few support spells, grouped by school. The Fire school covers Pyroblast, Scorch, Flame Strike, Living Bomb, Fire Blast, Blazing Speed and the Hot Streak proc. Frost has Frost Bolt, Ice Lance, Cone of Cold, Deep Freeze, Frost Nova, Ice Barrier, Ice Block, Icy Veins, Ice Nova, Fingers of Frost and Shatter. Arcane and utility hold Polymorph, Blink, Arcane Intellect, Presence of Mind, Resurrect, Holy Word: Serenity, Pain Suppression and a PvP Trinket. Support holds Flash Heal and Renew. Around the combat sits the rest of the systems. The player side has a third-person camera and a character controller, the world has arena setup on the Lordaeron map plus the Sirus scenario, the UI has unit frames, action bars, customizable hotkeys, lobby, chat, floating combat text and unit selection projectors, and the presentation layer has visual effects for casts, projectiles and auras plus spell, UI and character sounds. The systems list also names localization with spell-error notifications, and AI behavior graphs for scripted encounters.

Opening the project and the order the scenes have to build in

The getting started section is short, and it is specific in the way that matters. You open the project in the Unity Editor version specified in `ProjectSettings/ProjectVersion.txt`, and then enter play mode from the Launcher scene at `Assets/Scenes/Launcher`. The build instruction is a constraint rather than a convenience: the Launcher scene must be included first, followed by the playable locations, so a build made in the wrong order will not behave. From the lobby you have three choices. Single Player starts a local session and plays offline. Start Server hosts a session that LAN and online clients can discover. Start Client waits for sessions to appear and then connects, and if a connection fails the reason is shown at the bottom of the lobby panel. The controls are the usual shape for this genre, with WASD or left and right click to move, Space to jump, Tab or left click to target, Esc to deselect or cancel a cast, and drag with left click to rotate the camera. The `Packages/` and `ProjectSettings/` directories at the repository root, and the `Assets/` directory holding the scenes, are what you open.

The content is licensed by Blizzard, not by the project

This is the constraint that decides who can use the project. The licence and attribution section states that all character models, textures and sounds are copyrighted by Blizzard Entertainment, with all rights reserved, and the repository itself is released under the Unlicense. Those two facts pull in opposite directions. The code is public domain, in the most permissive sense available, so you can take the engine, the assembly structure, the data-driven spell model and the netcode abstraction and do anything you like with them. The art and audio are not, and they are what make the project look and sound like World of Warcraft. A team building a commercial title on this foundation therefore needs its own art and audio pipeline, and it should treat the Sirus encounter and the Lordaeron arena as reference rather than as content to ship. The Unlicense on the code also means the project offers no warranty and no obligation to maintain compatibility, and the README shows a recent release named for the boss fight example, with the last push on 2026-06-18.

Editorial conclusion

Adopt Warcraft Arena if you want a reference implementation of a World of Warcraft style combat engine, with spells, auras and spell effects as data rather than code, and if the assembly separation gives you a networking abstraction you can use. Skip it if you need shipping content, because the character models, textures and sounds are owned by Blizzard Entertainment, and if you need a game rather than a combat system. Before you commit, open the project in the Unity version named in ProjectSettings/ProjectVersion.txt and confirm the Launcher scene builds, since the build order puts Launcher first by requirement.

Frequently asked questions

Official sources

1. Issues
2. License: Unlicense
3. README
4. Reinisch/Warcraft-Arena-Unity on GitHub
5. Releases