Introduction

A map in Shards of Stone is a single JSON document. It carries the terrain, the elevation, every placed unit and building, the player roster, the triggers, any balance changes the map makes, and the cutscenes it plays. The game loads that document and nothing else, which is the property everything in these pages depends on: if the editor can write it, the game can play it, and if the file is self-contained then a multiplayer match cannot end up with two clients running different content.

The editor is the tool that writes that document. It is not a level viewer with a save button. It runs the same terrain renderer the game runs, the same placement rules the build system uses, and the same validator the publish endpoint runs, so that what you see while authoring is what loads at match start.

What you can author#

The modules are reachable from the top-right of the editor and by function key: Terrain on F5, Triggers on F6, Data on F7, Players on F8, Cutscene on F9, Validation on F10, and Test Map on Ctrl+F9. The layout is copied from StarCraft II on purpose, including the layer hotkeys and the number keys setting entity ownership while you place, because a lot of people already have those in their fingers.

What it deliberately cannot do#

Two limits are worth stating up front, because both are load-bearing rather than temporary.

Triggers are not scripts. There is no JavaScript in a map, not even in a sandbox. A trigger is a tree of typed nodes: an event, some conditions, some actions, each one a value the editor knows the shape of. That restriction exists because the simulation is lockstep, meaning every client runs the whole match and compares hashes rather than receiving state from a host. A script engine's iteration order, floating-point printing and maths library differ between browsers, so a map that ran user JavaScript would be a way for downloaded content to desync a match, and a desync from user content is not something anyone can fix in the field. Everything the campaign's 48 missions do is expressible in the same node set, so the ceiling is higher than it sounds.

A map cannot bring its own art. Custom units, buildings, items and spells are edited in the Data module, and they may reference any asset the game already ships. They may not reference an uploaded file. That is a content moderation and CDN problem rather than an engine one, and it is out of scope for this version.

Two things that will save you an afternoon#

Elevation is a terrace system, not a heightmap. Ground sits at integer levels, a step of one level is a cliff, and a cliff is impassable to ground units unless a ramp crosses it. The editor refuses to save a map with a two-level step, because the movement rule that reads it (heightStep) refuses to cross one even with ramps on both sides, and the minimap would draw the map as if it were fine. Terrain and Height covers the rules and the repair tools.

Publishing is gated on a validator that only reports failures you would not otherwise see. It does not have opinions about your map's design. It catches a mercenary camp that will spawn as scenery, a spawner that will tick forever producing nothing, two entities sharing an authored id so a trigger can only find one of them, and a one-seat map that declares victory on tick one. Publishing lists every rule and what each one prevents.

Where to go next#

If you have never opened the editor, read Interface and then Creating a Map. If you are porting a map from another game or another editor, start with Terrain and Height, because terraces are the part most likely to differ from what you are used to. If you already have a layout and want it to do something, go to Triggers.