Stores tracker

[WinstonHartnett]

Stores TODO

• Unboxed
• Boxed
• Compacted
• Resource

Unboxed

Uses growable unboxed MVectors under the hood. Probably fastest of array-like component stores.

Boxed

Uses growable boxed MVectors under the hood. Might suffer from long-term cache locality problems. Also has GC performance problems for large stores (due to card table).

Compacted

The idea is to provide a [mostly] contiguous store for long-lived boxed components (excluding functions and mutable data as per compact). A compact store is divided into compact-region chunks. On mutation (which should be avoided at all costs for preexisting components), a master record list w/ pointers to each chunk element from every chunk is updated to point to copies of the mutated chunk (with the mutated element(s) changed). Old references will still keep old blocks alive... beware!

Question: is copying on any modification a good idea? Maybe have some internal fragmentation heuristic?

Resource

Basically a global IORef.

[WinstonHartnett]

World design

Use Generics to assign a type-level ID to each World store like so:

data World = MkWorld (Arch Position) (Arch Velocity) (Arch Flying) (Global  Whatever) -- 0 1 2 3
  deriving Generic

this avoids the need for TH Components. Unfortunately, you can't access stores directly, but you can dump

Uniform Access API

Data stored in the ECS should be uniformly accessed regardless of store type

mySys = do
  p <- get @Position -- Standard component
  (MkVelocity v) <- get @Velocity -- targets archetypes: { A | components(A) ∩ {Position, Velocity} == {Position, Velocity} }
  g <- get @Whatever -- Doesn't filter at all, retrieves from global element store