(5:40:34 PM) Me: oh so i've been thinking about what primitives are needed to describe any (or damn near most) board games and how best classes should fit together for deployment to different platforms and allow users different settings or screen resolutions, or make superficial adjustments to the positions of visual elements (this basically amounts to discrepancies between display positioning, and in some cases whether or not a particular client is "headless")

(5:44:07 PM) Me: I think it can be boiled down to "objects," "attributes," "displays," "collections," "zones," "items," "pieces," and "knowledge transition"

(5:47:46 PM) Me: objects describe a hierarchy of namespaces. items are also objects. collections are arrays with careful access semantics, zones are a type of collection, pieces are a type of item which can be put into zones, and a "knowledge transition" is whenever a member of a collection is resolved, or an item is placed into a collection and anonymized.

(5:47:54 PM) Me: oh i forgot about asymmetrical knowledge

(5:49:45 PM) Me: now the reason for the careful access semantics is because i want a fair randomness system which requires all players to generate their own chaos pool and have it signed by a trusted third party before beginning the game

(5:50:34 PM) Me: requirements for random data are filled by combining chaos from all players in a way that cannot be taken advantage of

(5:52:23 PM) Me: in order to possess knowledge that no other player does, your client merely has to pull random data from all other players without sharing in return, but still informing all other players that you have allocated that portion of your chaos pool (so that they can mark it as unknown, and at the end of a game each client can verify that each other client did not cheat)

Some more thoughts:

If I implemented a client for DOM/Js and/or Flash, I could use mouse cursor movement to seed the chaos pool, just like old video games used to gather entropy from minutia of controller input timing, and also the encryption software TrueCrypt.

I didn't really mention what Items were, but they're basically elements of game state which are not typically represented by Pieces. Item also acts as a parent class for Items.

I forgot to mention that "Displays" almost types of "Items," but instead they ought to just be separate objects which visually display a representation of an Item. In a game of Chess a Display could show your score, number of moves, or timer data. In every game, which player's turn it is could be indicated by a Display. In more complex games like Magic: The Gathering, Displays could be used to show which phase/step you're on, or the stack.

I also didn't really talk about this: Collections can be associated with Items, and Zones can be associated with Pieces. On a "headless" client (like the server) (hmm, maybe there doesn't need to be a real game server -- the server could be an application-agnostic message passing system, thus avoiding the need for "headlessness.") Zones and Pieces on clients are represented merely by Collections and Items on the server with the notable difference from other Collections and Items that they "know" they ought to be Zones or Pieces where they can be. Am I just describing MVC?

Oh, here's an idea. If the notional controller of the MVC pattern is a controller which asks each other client in the game, perhaps a stack ought to exist here to give players an opportunity to respond -- this could also potentially swallow up the M:TG stack. Would a stack preclude any board game which actually legislated player timing semantics? Perhaps the game description can mark some moves as stackless which resolve immediately -- but that doesn't combine well with attempts to iron out timing discrepancies between clients over the network.

Another difficulty with the stack approach is that it might become tedious to click "pass" all the time. Perhaps there is a means to formalize relaxation on stack rules? Another option is that the game state could be "rewound" if a player says "no wait," or if multiple clients try to take the next move simultaneously. Perhaps multiple ACKs need to exist?