HEXIT Devlog 01: Building a Battlefield from Data
From hand-placed hexagons to CSV-authored battlefields with height, obstacles, objectives and reusable Unreal presentation.
Ruined Bastion in the map viewer. Its central depression, elevated rim, obstacles and peripheral Boost Nodes are authored as board data.
The problem: a board that could grow beyond one level
The first building block was a hexagonal tile that remained comfortable to edit in Unreal. That sounds small, but the tile had two jobs: look like part of a consistent modular set, and represent a precise playable location. Decorative bevels and column bases could not become the definition of movement distance or adjacency.
Hand placement was useful for testing materials and silhouettes. It was not enough for iterating on complete tactical layouts. Moving a route or adjusting an elevation should not require maintaining a second, unrelated version of the board for gameplay.
The solution was a data-first authoring pipeline:
CSV document → parser → generator → logical grid → visual and gameplay queries.
This is authored generation, not a claim that every level is randomly generated. A designer specifies the layout; the pipeline turns that document into a board that the game and the viewer can both use.
What a map actually contains
The document can describe terrain, coordinates, height, deployment zones, Boost Nodes, objective tiles and obstacles. Obstacles inside a cell and barriers between cells are different concepts, because a wall on an edge should not silently turn both neighbouring cells into unusable terrain.
Metadata adds the scenario around the layout. A Central Control map carries its mode and score target alongside the cells that form its objective. This keeps the map’s gameplay meaning close to the content being authored.
That separation also makes debugging more concrete. If a unit cannot reach a tile, I can investigate connectivity, occupancy, terrain cost or a blocked edge rather than guessing which decorative mesh intercepted a trace.
Keeping the Unreal workflow useful
Data-driven does not mean removing the editor from the process. The main tile Blueprint remains an authoring surface for materials and geometry. The Gym supports small, controlled tests, while the map viewer loads complete CSV layouts without starting a match.
The viewer and the playable mode share the board-generation path. I can inspect a layout, then use that same content in a battle. Menu code selects and launches content; it does not parse a CSV or implement movement rules itself.
The distinction between the playable top and the decorative body has been particularly important for stacked tiles. A small gap between column bases may be an intentional visual detail. A gap between playable surfaces can make the entire grid look disconnected.
Rendering without losing identity
Repeated static board layers can be grouped through an instanced renderer. However, optimizing repeated geometry must not erase which logical tile the player clicked. The renderer retains the relationship between a visible instance and its source tile; gameplay continues to query the board model.
Material compatibility also matters. A fallback path is preferable to an optimization that makes a terrain layer disappear because a required material variant is unavailable. This is an ongoing rendering concern, not a blanket performance claim.
The same pipeline in a playable match: terrain, water, the objective perimeter, deployment state and unit presentation are connected without turning the level into the rules engine.
What this unlocked
New maps became content work rather than a new code path. The same pipeline supports small duels, more obstructed control arenas and larger experimental layouts. Adding a planet can change the visual treatment while preserving the board document.
The larger benefit is consistency. A tile has one tactical identity whether it is being inspected in the viewer, selected by a player, queried by an AI or included in a simulation. There are still edge cases to test, but the architecture gives those cases a place to live.
Next question: once both sides can issue orders on that board, how do their decisions resolve—and how can the player understand the result?