Burst & Grid

Grid

Problem:

Concept of entities with volume that define different characteristics which need
to be volume tested against for various gamelogic purposes. Previous iteration 
was a grid implementation where these characteristics were represented as
 bitflags, each `int` a gamelogic concept to be tested against. E.g. Pathing: 
 [None, Impassable, Occupied, Walkable, Flyable, Vaultable, Climbable,
 Interactable, Teleporter, Staircase]
Any volume placed on the grid would OR added to the grid's characteristics 
bitmasks of the cells it occupied.

Problem Characteristics:
- Grid: hundreds x hundreds x ones. E.g.: 300x300x2
- Volumes: 95% case is small, (3x3x1 - e.g.: a wall, a unit).
-- However, we tend to construct concepts hierarchically. 
   I.e.: Map Editor placement adds a "building" which is a volume containing 
   various volumes. (think 50x50x2)
   Current idea is to do "hierarchical" grids, where each layer aggregates the 
   results of the entities contained within.
-- Often relatively sparse: only 3 to 10 entities occupy a single cell.
- Smaller objects tend to be repeated. ("Floor Tile A" is placed 10x5 times to 
   create the floor to a building)
-- Q: Visualization optimization is already handled - mesh merging etc.  
   But would it be interesting to do the same for game data? Instance the entity
   and only separate once we start mutating it?
   Could this alter the grid datastructure somehow?

Access patterns:
- Random volume (aligned to grid), or even individual cell, testing comparing a 
  volumes's characteristics to the grid through bitwise operations (&, |, ^)
- Volume mutation (add, remove, change) at runtime
-- Mutation at content creation time is large (e.g.: placing buildings)
-- Mutation at runtime is small (destroying individual objects)
- Line casting / path checking against various characteristics on cells

Questions:
- Given that the 95% case is small, but I can conceptualize things 
  hierarchically, do I want to move away from the grid datastructure to a more
  BSP approach?
-- If I go with the grid, how do I setup my arrays such that memory access is 
   optimized?  
   Currently we use a single-dim array with an address struct to acces it. 
   Given that random volumes will not be similarly sized, the access on the 
   larger grid will be staggered striped on the array.
- How could I use Burst to optimize the different patterns?
-- Do I want to upgrade all access and mutation to Jobs, or do I want to only 
   optimize larger (volume) operations?
-- If I hybridize, how do I avoid having to copy across data to Burst accessible
   formats / avoid the managed access to my data?