The ‘arena’ or ‘environment’ of the Battle System, which constrains participating entities to a grid of cells.
The grid is isometric. Each cell is twice as wide as it is tall.
The grid will always be a perfect rectangle, but may not be the same width or height every time.
Cell terminology
A cell is:
- Cardinal to another cell if they share a side.
- Diagonal to another cell if they share a corner.
- Adjacent to another cell if they a side OR a corner.
For example:
- “Units move one cardinal cell at a time.”
- “This ability hits all units in one diagonal direction.”
- “This effect applies to all adjacent cells.”
The grid’s boundaries are called edges. We’re avoiding the term “wall” as that might come up in gameplay.
Coordinates
We will use the coordinate system from yellowafterlife’s blog post to describe cell coordinates. We recommend that the programming team reads the article for implementation tips.
Essentially, despite being being viewed from a 45º angle, the grid’s data is still stored in a 2D array. The positive x-axis points to the bottom-right, and the positive y-axis points to the bottom left. The very top cell has coordinate (0, 0).
Radius
When something has an x cell radius, it influences cells that you can reach by travelling that many cells in cardinal directions only.
Radius Examples
Radius of 1 cell:
Radius of 2 cells:
Radius of 3 cells:
Square
When something has an x cell square, it influences all cells that fit within a square that is cells wide.
“All surrounding cells” is equivalent to a square of 1.
Square Examples
Square of 1 cell:
Square of 2 cells:
Square of 3 cells:
Cell occupancy
Each cell may, at any given time, have:
- One entity occupy it (or none at all)
- One cell state (or none at all).
Cell states
Grid cells may have one cell state, which generally apply effects to entities that occupy that cell.
Other cell metadata
Depending on which kind of entity is occupying it and what state each cell is in, they must know (or be able to determine) some other properties.
| Property | Meaning |
|---|---|
| walkable | Grounded entities can pass through the cell in order to get to another cell. If false, they can’t. Ungrounded entities ignore this. |
| movable | Entities can pass through the cell in order to get to another cell. Applies to grounded and ungrounded entities. If this is false, walkable has no effect (since nothing can enter it anyway). |
| occupied | An entity is occupying this space. An occupied cell is not necessarily unmovable (units could walk through an occupied cell to get to another one), but an entity can’t “land” on this cell and stay there. |
| obstructed | Determines if this cell blocks Line of Sight. |
Level Layouts
At the start of a battle, a layout will be selected from a pool of hand-defined layouts. The district type, room position, combat type (normal/elite/boss) are not factors in deciding which one is picked, the game will just grab any layout and spawn the necessary objects onto the grid.
Bosses may define a layout that will be used every time they are encountered.
The following information is included in a level layout. None of the spawns should overlap.
Grid Size
The size of the grid (w x h). Shall be used to generate the initial grid at a certain size.
Player Spawns
The locations where the players will spawn. There must be exactly 3, and they shall be ordered (i.e. the character in the party’s first slot will spawn at player spawn 1, etc.)
Enemy Spawns
The locations where enemies are spawned. There must be exactly 10, and they shall be ordered (i.e. the first enemy will spawn at enemy spawn 1, etc). The type and number of enemies is determined outside the level layout; this layout is simply used to position them on the battlefield.
Cover Spawns
The locations where Cover will spawn. There can be any number of these locations (0 to many). Unlike players and enemies, cover will spawn at every single location defined.