Skip to content

Instantly share code, notes, and snippets.

@gjroelofs
Last active February 27, 2020 17:08
Show Gist options
  • Save gjroelofs/07bb300a43b2076c89c493f9476654f0 to your computer and use it in GitHub Desktop.
Save gjroelofs/07bb300a43b2076c89c493f9476654f0 to your computer and use it in GitHub Desktop.
Burst & 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?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment