HEXIT
Building a simultaneous-turn tactical game in Unreal Engine: readable combat, data-driven battlefields and a modular planetary presentation system.
A battlefield built from data: elevated approaches, a central control zone and optional Boost Nodes. Captured in Unreal Engine, September 2026.
Plan together. Resolve in order. Fight for position.
HEXIT is a tactical strategy game in development in Unreal Engine 5. Both sides plan their orders before the battlefield resolves them in sequence. The interesting question is not just “Can I hit that unit?” It is “Will this still be the right decision after the other side moves?”
The prototype combines compact armies, a three-dimensional hex board, uncertain combat outcomes and objectives that reward holding useful ground. Its sci-fi direction is expanding toward planetary environments and stylized lunar characters. This devlog follows the work from modular tiles to a playable local match, including the revisions that made the game easier to understand.
My role
I am responsible for art and Unreal Engine: the in-engine experience, visual presentation, tools, tactical interface and integration on the Unreal side. Xeon develops the backend and Angular application. HEXIT is a collaborative project; the server/client architecture connects our respective areas of work.
This portfolio focuses on my Unreal and art responsibilities. Current screenshots show a development build, with placeholder figures and temporary portrait art—not a finished character-art showcase.
The playable loop
Choose a map, two armies and an environment. Deploy your units, plan movement, then choose attacks or abilities. Orders resolve according to their priorities; the board changes, combat feedback explains the result, and the objective is evaluated before the next round.
In Central Control, occupying the middle with only your team earns one point at the end of the combat phase. The first side to reach five cumulative points wins. An enemy contesting the zone denies that point, and eliminating the opposing army remains another route to victory.
That creates a useful tension: chase a vulnerable target, protect the middle, or spend an action displacing the unit that is keeping the zone contested?
The current battle interface keeps both teams’ health and ability availability visible. Hovering a badge reveals the explanation when it is needed; eliminated units remain identifiable in the roster.
What makes this project interesting to build
- Anticipation over click speed. Simultaneous planning creates commitment; sequential resolution makes the consequences readable.
- Terrain with a purpose. Height, obstacles, firing lines, deployment areas and objective coordinates are part of the logical board, not just decoration.
- Clarity before spectacle. Combat moved away from a roulette-style display toward explicit damage outcomes, consistent portraits and readable impact feedback.
- Content without duplicated systems. CSV maps, JSON armies and reusable ability definitions support iteration without creating a bespoke implementation for every matchup.
- Presentation without authority leaks. Unreal communicates intent and presents accepted state. The backend is intended to decide remote match outcomes.
Explore the development
| Chapter | The question behind the work |
|---|---|
| 01 — Building a battlefield from data | How can a modular board stay easy to author and reliable to query? |
| 02 — Making simultaneous combat readable | How do players understand risk and follow a resolved attack? |
| 03 — Giving players a reason to move | How do objectives and points of interest change positioning? |
| 04 — A tactical interface that answers questions | What should be visible, contextual or only one hover away? |
| 05 — Small armies, distinct decisions | How can reusable abilities and different speeds create variety? |
| 06 — Unreal as a client, not the referee | Where should intent, validation and presentation live? |
| 07 — Testing the game without playing every match | What can simulation tell us—and what can it not prove? |
| 08 — One board, different worlds | How can lighting, materials and the table change without changing the rules? |
From interaction to implementation
Vector Hook targeting uses a yellow perimeter, distinct from ordinary attack and movement previews. The same unit card carries the action state and contextual explanation.
A recurring lesson has been that a system can work mathematically and still fail the player. A percentage without a clear label, an objective that resembles a buff, or an effect that blocks a tile click all change how the rules are understood. Many recent improvements have therefore been about consistency between input, authoritative state and the picture on screen—not simply adding more features.
Current development snapshot
Playable locally: map and army selection, deployment, movement planning, attacks, the three prototype abilities, an AI opponent, Central Control, elimination, combat feedback and team-state panels. A separate map viewer supports visual iteration without running a battle.
Implemented foundations: typed commands and JSON transport on the Unreal side, snapshot/event presentation, deterministic local resolution, automated checks, headless simulation/reporting tools and Earth/Mars/Moon environment selection.
Still being validated: real remote end-to-end matches, parity between all simulation paths, army balance across maps, onboarding, sustained performance and final visual production. The existence of a protocol or a test suite is not a claim that multiplayer is shipped or the game is already balanced.
The recorded September 10 regression run completed 68 automated tests successfully. This is a dated engineering checkpoint, not a substitute for player testing.
Technology and direction
Unreal Engine 5.7, C++ and Blueprints form the game client. Board documents use CSV; army and ability definitions use JSON. Separate domains handle authoring, rules, interaction, UI, audio, rendering and online integration.
The next priorities are to test whether Central Control consistently creates interesting decisions, close online-integration gaps, and replace placeholder characters with a coherent stylized lunar identity. Equipment should feel functional in an astronaut’s world; readability at tactical camera distance matters as much as close-up detail.
If you are evaluating my work for a team or a potential collaboration, the chapters below document both the visible result and the reasoning behind it. The most useful next conversation is a walkthrough of the current prototype: the experience we can demonstrate today, the remaining risks, and what the next milestone needs to prove.
Image note: screenshots are from the HEXIT development project. Temporary characters/portraits and third-party environment assets are not presented as final original character art. The grassy showcase uses Stylized Grass by Mayu. Other sourced prototype content remains subject to its respective licenses.