Create a Board property type

[jkomoros]

Noted while exploring #550, and in this exploration: https://github.com/jkomoros/boardgame/wiki/Representing-spaces

To represent Spaces, which may have 1 to n items in them properly, you need a GrowableStack for each logical space. Things like having a separate SizedStack for each Player are an illusion, because that only works to the extent each user has a single component that could be placed.

For a board with 5 spaces, you could image encoding 5 growable stacks manually:

type gameState struct {
  Space0 boardgame.MutableStack `stack:"Tokens"`
  Space1 boardgame.MutableStack `stack:"Tokens"`
  Space2 boardgame.MutableStack `stack:"Tokens"`
}

But that's extremely annoying.

Basically a Board is a property type that is exactly equivalent to a fixed array of GrowableStacks.

The growable stacks might have a maxlen on all of them at the same time, (e.g. if only one player may be in each one, or if only up to two tokens may be in a single space). But if you want something more complicated than that (e.g. only one token of a given color in a board space at a time, then you have to encode that in Move.Legal() logic).

[jkomoros]

type gameState struct {
  Spaces boardgame.MutableBoard `size:"64" stack:"Tokens,2"`
}

Do we need a separate Board and MutableBoard? And theoretically the thing you get back from them is literally a GrowableStack.

And how does a given component know which spot it's in? Conceptually each stack grows a Board reference, if it's part of a board, and also a BoardIndex. So a component can figure out which stack it's in, which then allows it to figure out what space index it's in.

[jkomoros]

Also note: given a ref to a component (and a State) it's actually not possible to (efficiently) determine which Stack it's in currently. That implies some kind of state-wide index that is updated.

[jkomoros]

Should boards be resizable, like Stacks are? Obviously the stacks to be removed would have to be empty.

Conceptually they are like a SizedStack of GrowableStacks, except that having them literally be that is unnecessary.

[jkomoros]

type Board struct {
  spaces []Stack
}

func NewBoard(size int, deck *Deck) *Board {
}

func (b *Board) Spaces() []Stack {
  return b.spaces
}

func (b *Board) SpaceAt(index int) Stack {
  //TODO
}

[jkomoros]

• [x] To/From json (test!)
• [x] Sanitization
• [x] importFrom on board (like stack.importFrom) (currently panics)
• [x] copyReader needs to know how to handle boards (probably safest to grep for TypeStack in whole code base and see which ones need updating)
• [x] Add to propertyReader (and friends) interfaces
• [x] Add as a property type
• [x] autoreader supports
• [ ] board.importFrom likely needs to save state before, and reset itself after setting all stack's importFrom... or maybe not, because they each individually keep the new state. Test.
• [x] Test round tripping through json (and putting at least one item in one of the Board spaces)
• [x] Test putting at least one component in the board
• [x] Test sanitizing board
• [x] Transitively mark dynamic component types as visible in sanitize needs to iterate over all stacks (and test). Best way is likely to have a readerUtil that takes a Reader and returns all Stack objects (both top-level but also all ones in Boards).
• [x] patchtree-helper expand on the test hierarchy fails. ERror in #607?
• [ ] Add a test of components in a Board that exercise transitive visibility
• [x] newReaderValidator needs to know about boards in order to do struct tag inflation
• [ ] Board doesn't sound right--it's too specific, too big. (The whole package is called boardgame!). Is it more like Region?
• [x] Stacks within a Board should not be allowed to set their len
• [x] Allow creation from struct tags
• [ ] Unmarshal JSON will panic (I think) if Spaces size is now different than it was when JSON was marshalled. Luckily stacks are easy to clone by inspecting properties on existing ones (add clone() method?). Wait, doesn't this apply to all stacks today for when the size of th estack doesn't match e.g. the maxsize that was stored? Maybe not, but it's at least possible.
• [ ] Client side expanding also expands the stacks within the board
• [ ] Checkers should use Board
• [ ] board struct inflater should default to 1 if none provided
• [ ] Update tutorial
• [ ] boardgame-board element should be able to take a board or a sizedstack interchangably
• [x] Should Board fit within MutableStack interface, as well? Just pretend to be a SizedStack that's not resizable, only reports up to one item in the space, but allows to move within them even if there's an item there, as long as MaxLen. If we do this, then it's arguable whether Board should be a different property type in the first place, or just a SizedMultiStack. Looking more carefully through the MutableStack interface, there are a LOT of things that would be way more complicated to wire through the general interface. Good to pop out into a separate issue.
• [x] Stacks grow a Board and BoardIndex property
• [ ] If all components are in the same Board, then there has to be a way to signify which components below to whom (e.g. by tying an EnumProp, which generally is "color"). Currently in Monroe who's allowed to move a component is implied by the Stack it's in. One way to do this is to have Boards have MovePredicates or something, which are simple functions that are run before a MoveComponent into one of the stacks even runs, and rejects moves out of hand early. The library would then make a few available for conveniece, similar to the graph library making Downward filters available. The easiest would be: "Only allow one component in the stack to have this EnumProperty set to any given EnumValue." (Are there others?). The stacks within a Board would then have to be thin wrappers around SizedStack, overriding the MoveComponent (and maybe other methods that could move a component in?) to first run all of those predicates. One annoying thing is that the board would need the predicate configured on each Board when instantiated, which impliesstruct tags, which likely wouldn't work fo rthis case.
• [ ] Update Monroe to use Board as a stress test, too
• [ ] Don't boards need MergedBoard machinery, too, for cases where some components are face up and some are face down? :-/
• [ ] Update autoreader on MBP

[jkomoros]

Currently in branch "board"

[jkomoros]

Wait, if we have board, what's the way to stamp out the templates for the tokens? Monroe does it in a kind of weird way, where each component has its own stack. I guess the answer is fixing #604