HEXIT Devlog 06: Unreal as a Client, Not the Referee
How typed intentions, JSON commands and authoritative snapshots shape the Unreal side of HEXIT's backend integration.
Local development match during movement resolution. This screenshot illustrates the presentation layer; it is not evidence of a remote multiplayer session.
The click is a request, not the result
A player selects an enemy through a gap between two obstacles. The client highlights a shot. What if that line is actually blocked? The answer cannot be “the animation already started, so the attack must be valid.”
That distinction drives the server-authoritative architecture. A client communicates what the player wants to do; the match authority validates the order and produces the outcome. Unreal then turns the accepted state into a readable experience.
Xeon owns the backend and Angular application. My work is on the Unreal and art side, including the client integration described here. The protocol is the boundary between those responsibilities, not a reason to blur their attribution.
A shared vocabulary for actions
The Unreal command model covers deployment, movement, attack, ability, ready and undo. Each is represented as a typed intention that can be serialized through the JSON transport layer. A movement request identifies the unit and desired destination; it does not tell the server to trust a client-authored final board.
The same principle applies to abilities. The client names the ability and target. It must not invent a legal teleport destination, pull path, affected units, remaining health or consumed use count for a remote match.
Keeping the commands explicit makes them easier to inspect, reject, test and compare with other order sources. It also reduces the temptation to hide gameplay mutations inside input handlers.
The round trip
| Stage | Responsibility |
|---|---|
| Player intent | The UI and controller describe the requested action. |
| Authority validation | The match checks ownership, phase, board legality and relevant action constraints. |
| Resolution | Accepted orders update match state in the agreed sequence. |
| Events and snapshots | Results describe what happened and the authoritative state to present. |
| Unreal playback | Movement, portraits, damage feedback, sound and HUD state communicate that result. |
This is an architectural outline, not a claim that the remote service was exercised in the captures on this page.
Line of sight belongs to the board model
An obstacle-related attack bug is a good example of why this separation matters. A convenient client trace can be useful for selecting something, but it cannot be the only definition of combat legality.
The rules layer needs the logical terrain, heights and obstacles. Preview code can reuse the same query services to provide immediate guidance, but the preview is provisional. The authority must still reject an invalid action, including one whose target or path changed after another action resolved.
This also affects movement onto objectives. A decorative marker should not block the cursor; removing its input collision does not mean removing the real occupancy or pathfinding checks.
Offline play is a reference path, not a remote fallback
The local prototype uses an offline authority so maps, armies and combat can be developed without waiting for a network service. That is useful for iteration and deterministic tests.
It does not authorize the remote client to quietly resolve outcomes if the backend is unavailable. The online path consumes server state and events; its correctness depends on the contract and actual integration testing.
What is implemented—and what still needs proof
The Unreal project contains command types and codecs, a multiplayer controller/session layer, launch descriptors, snapshot/event handling and focused contract tests. Environment selection is also carried by the launch contract rather than being inferred from a visual map name.
What this devlog does not claim is shipped multiplayer, production backend reliability or a completed end-to-end remote test of every ability and objective. Those require evidence from the running integration with Xeon’s systems.
For me, the valuable engineering result is a clearer client responsibility: help the player make an informed request, then faithfully explain the answer. The next milestone is to verify that contract under real connection, sequencing and content-version conditions.