26-NOV-2024

1252 - familiars

Continuing from previous entry, I’m starting to solidify the design of the playing-end of this thing.

I have this setup:

Log is a way to store a sequence of anything, in our case ChessActions

Chess Action supports a notion of 'Variation'

The Log lays out it's contents as single, seekable stream, similar to the File API.

Log can produce a Cursor or WriteHead (mutable cursor) on itself, which can be used to navigate the log.

A Familiar takes a Cursor and calculates some useful values, in particular the current board state and current metadata
information.

Familiars are generic, they only care that the type they work over implements `Play`, which itself is a trait that is
generic over the Rule and Metadata types that govern whatever abstract game they define.

A Familiar can be specialized to a specific representation type to allow for faster/more efficient calculation, it might
be responsible for caching important results, etc. Most directly, it's responsible for calculating the current board
and metadata state.

The final engine will essentially be a Log, a bunch of Familiars that can be created/destroyed as needed, and insodoing I can have multiple representations that can all benefit from intraconversion. Familiars should have a ‘Set Position with cached state’ option which allows one familiar to transfer it’s state to another; so that a Familiar optimized for fast scanning can then feed one that’s designed for fast querying, etc.

This also means new representations can be easily compared apples-to-apples with exisitng representations.