Figuring out the data layout

[bskinn]

What thoughts on data topology? 3P3 gives six options:

1. Player-turn-stat
2. Player-stat-turn
3. Turn-player-stat
4. Turn-stat-player*
5. Stat-player-turn
6. Stat-turn-player

Implicit in any of these is a 4th layer, of per-card data where relevant (cached food count, etc.)

As with the current score scraper, I'd consider per-round stuff as happening in its own turn, between rounds. Same for end-of-game.

Non-player-specific per-turn info (NPSI) would have to be handled differently depending on where Player falls in the hierarchy. To my mind, this argues for Player being at the innermost level, because then NPSI could live as a sibling to it.

The current scraper uses format 4. Game-invariant data (first turn assignment, winner, etc.) lives at the root of the object. I feel like 3 and 4 would be the easiest for me to code on the creation side, but they might be more awkward on the usage side. Not sure, though. And, since I'm not sure, I'm inclined to go with what'll be easiest now.

[jbialo]

I've been running with an approximation of #3 on my end, representation of a game looks something like:

• Game
  • GameState[]
  • Birdfeeder/Tray/etc.
  • Player[]
    • Score
    • Food
    • Hand
    • Habitat[3]
    • BirdState[5]
      • Eggs
      • CachedItems
      • ActivationCount

[bskinn]

Mmm, activation count.

[bskinn]

I would really like to have Typescript for this. It would help avoid a lot of mistakes. Will have to check if it's possible.

Maybe a manual TS->JS build step to /dist...

[bskinn]

Looks like that should be fine