Create a boardgame-game-board element

[jkomoros]

Whoops, we accidentally tracked work for #542 and #547 in #476 by mistake. Creating a new bug to track what was supposed to be tracked in #476.

[jkomoros]

The board takes an SVG (it should also be able to take a canvas, with region polys provided) to render.

Regions have ids like region-ENUMNAME-ENUMSTRINGVAL. The board positions boardgame-token elements at stable-but-random x/y offset, just like boardgame-component-stack layout=pile does.

Enums should get a RangedEnum, which takes a slice of ints, and produces values like "0", "1-2" (for two dimension) and "3-4-5" (for three dimension). Basically all it is is nicer getters/setters that know that the StringValues are actually ints.

Boards have a grid helper where regions don't have to be explicitly enumerated but rather can just say, here's the rectangular region, and it should be broken into n columns and m rows, (and space spread between that). (Optionally with a given gap amount for rows and columns)

In terms of representing in state the position of tokens, the idioms are: if more than 1 token may be in a logical space, create a SizedStack of the correct length for each player. In the game state have a overlap merged stacks (overlap:"players.TokenPositions", which overlaps all of the "TokenPositions" stacks into one overlapped merged stack). (But wait, that wouldn't allow multiple players in each position then... If only one token may ever be in a logical space, just have a single TokenPositions stack on game.

[jkomoros]

And of course a GraphConnectedness Component (as in #493) that takes those int dimension values and has a directed graph. You'd have a different graph for things like straight forward connections, and another graph for things like ladders/chutes (or visibility for monroe). In the graph nodes can have int values attached (which could encode things like whether there is a chance card on a given space) and edges can have them, too. You can interpret those as a val into an Enum, if you wish.

[jkomoros]

First, it should not allow an SVG, but make it work with checkers. (#486). Number of rows and cols to create. dom-repeat that creates them. And each of those have a region-ID tapped. And then you can style them based on even or odd

[jkomoros]

• [ ] Allow piping through even/odd styling
• [x] Fire a region-int-int event when region tapped
• [ ] Position tokens within the cell they're in (board has messy attribute)
• [ ] Position tokens differently for single-token-allowed style (always centered) versus cells that might have multiple tokens
• [ ] Support an SVG to load
• [ ] position tokens that are within it
• [ ] Template should spit out up to four layers of dimensions based on dimensionality. Give a style target for them (horizontal, vertical), and by default horizontal vertical horizontal vertical
• [ ] Plug in a particular enum into the board to have region row/col be named (and theoretically to figure out even more dimensions. The value of the cell is the index into the enum).

[jkomoros]

The enum information needs to be sent down in Chest. Every enum has a map of int to string, and ranged enums also output their dimensions

[jkomoros]

Think more deeply about when the information about which space should be encoded as just the single-dimension index and when it should be a dimensionined thing

• Pro: don't have to do weird conversion to get row/col
• Does the recommendation thing differ for single dimension?
• String value more vulnerable to for example string delim changing for transmission and storage
• What about stacks that change size? Is enum just always longer then it could possibly be?
• Pro: naturally make it so index within bounds

Does all of htis imply that there needs to be a special type of thing for dealing with spaces? They need a very specific best practice to model, which differs depending on which dimension they have

The only reason to have the full expanding on clientside is to know dimensions to auto-create the regions. but it's actually cleaner if the region is simply the underlying enum val. (But that's not true for normal enums, e.g. where "red" is a much more useful wire format, and these should operate like normal enums as much as possible)

[jkomoros]

Also another oddity: right now the location of the token is entirely implied by the index that they're in in the containing Slots array. But the related enum is the thing that that technically tells the client what that index actually means, in terms of the row/col.

Could we just have the row/col info be entirely iimplied client side? The board takes the arrays of spaces, and the enum that tells us how to map an index to an expanded enum, and then to a region.

We also need adjacency info for move legality in moves, right? Yeah; that's implicitly handled in methods on the token objects, or in moves. Every time you have a componentIndex, you need to convert via the enum you know exists.

One thing to do might be to have each Stack take an (optional) enum it's associated with so that server-side and client-side they're known to be wired together. It doesn't do THAT much--you only need to map between the two in two locations, really. But it might be nice because you can do it once server-side and then it can automatically come through wired client-side.

[jkomoros]

Think about how to model spaces that allow multiple tokens. How would they be passed into boardgame-board?

It's not clear, because each token has an owner, implicitly, whose playerState they show up in in that case. Definitely model that explicitly and make sure it works.

[jkomoros]

Started exploring the problem of spaces more generally in the wiki: https://github.com/jkomoros/boardgame/wiki/Representing-spaces