There might be benefits in terms of having to write less rules code and forbidden moves etc.
In the end though, it’s probably less friendly to someone that wants to play a variant but isn’t sure where to find the rules. You can’t just play by clicking about to see what happens, since you’ve to make everything happen yourself.
In theory that’s more flexible, but to that end, one might as well just make a shared sgf type editor that one or more people can control and be able to add and remove form a selection of pieces.
I think what you end up with going in that direction is something like
Definitely also leaves a lot of flexibility for testing new ideas and variants, or even just playing a game in the meantime while the rules are being added
I have no problem having a “flexible” variant, or starting with something simple just to get off the ground. But when I play a game, I’d be looking for validation of which moves are legal - it’s no fun realizing you missed an atari 20 moves ago!
I support the general idea, but think that we should consider alternatives for
Assuming that every intersection is associated with a unique integer (e.g. given by the order in which a fixed deterministic algorithm creates the intersections). Then we can store a single board position with an array of T, where T is a type defining the characteristics of an intersection (colours, visibility etc.).
Next we save the entire history of a game, i.e. a list containing the board positions leading up to this point. Then the needed storage is multiplied by the number of rounds. However, in most variants the board position changes only slightly each round. So lets consider alternatives.
Another option is to save a list of pairs (int i, T t) for each intersection, with the meaning “this intersection has characteristics t since round i”. (Ideally these are ordered by i, so we can quickly compute the characteristics of an intersection in round k by finding the first list entry where i <= k)
For example a traditional move, where just one empty intersection becomes coloured, means that we need to add just one list entry of the form (int i, T colours) rather than storing the whole array again.
Therefore this method might need less storage on average. (However it might be a challenge to create a sensible data structure for a data base)
If we do take the rules into consideration for the purpose of encoding the game history, then we can potentially save even more space. We could e.g. store the list of choices (moves) made by players in order. This method has some drawbacks
Less flexibility, as the encoding of a move depends on the exact rules
You could just consider compression to be a detail of the storage implementation. But let’s see, if each intersection has 256 states, that’s 361 bytes per move on the big board, so maybe 50kB for a typical game.
A minimal cloud server gives you 10GB these days. That’s enough to store 20,000 games. Maybe this isn’t going to be an issue for a long time?
Oh, I totally agree that we should only save moves in the database (some how we need to make sure the games are deterministic, but that’s another question)
But I think rules can be enforced before they are saved, here’s the flow I was thinking:
I think storing the list of choices makes sense, because you want to remember those anyway. For flexibility the transition function could be replaced by player choices.
So the flexible variant could look like this:
Players take turns.
During their turn a player adds stones to the board and/or removes stones from the board.
Or with simultaneous moves and an arbiter:
All players may add stones to the board
Arbiter may remove stones frome the board
Repeat from 1.
This just needs some collision handling. But that could be done by allowing multiple stones on one intersections.
I think it would be nice if users can easily navigate through the game history.
For the record, I am currently in favour of storing the history of board states via database entries along the lines of
{ int Id, int GameId, int IntersectionIndex, int SinceRound, TColours Colours }
… and additionally save all player choices / moves made.
I understand that space is “cheap”, but regardless I do propose to eventually add a mechanism that regularily deletes old games, e.g. games that are finished / inactive for a year.
But as always I won’t insist, other options are equally good
Looks like this leads to another question regarding how our stack of technologies should look like. So far we have discussed programming languages, which database to use is another thing to decide. Does anyone have thoughts about SQL vs NoSQL?
Probably it’s not practical, but I’m curious about the possibility of serverless peer-to-peer games based on WebRTC and PeerJS. In this case the data would all have to live in browser local storage.
The main advantage would be that anyone could release a new variant at any time just by putting up some modified static files on a free hosting site.
Most of my experience is in languages like Ruby, C#, and C/C++ though so I’m really lost trying to accomplish anything serious in JS.
But do you really need to store all of the board states and not just the moves/actions themselves?
Like if you want to replay a game or jump to move 50, just have the client skip ahead just using the moves that are played to recreate the board state?
Yes both are possible. Storing only the moves themselves is very space conserving, but how a move is defined may vary between different variants. So the idea behind storing the board positions is (i believe) to have one backend structure that works for many different kinds of variants.
If one stores only the moves, and say it’s a fairly statically typed language, one might need to make sure whatever a “move” is, it’s flexible enough to account for current and future variants.
Still presumably the game moves are much more resilient to future changes than the board states themselves. One might in future change how board states work, and then backwards compatibility becomes an issue for replaying old games (which might be dependent on whether they get deleted anyway).
Maybe it’s same sort of thing though with moves, like the representation of a move might change and then one would still need a way to parse older versions or just give up on them.
How should simultaneous moves interact with time control?
In this project the question is for the future, but I’m also thinking about implementing simultaneous moves in my project.
Does the clock tick down until I submit a move? After submitting a move, can I still change my submission? If I change it, do I lose time on my clock?
Also should players be able to see who has already submitted a move?
I think in a variant with simultaneous moves one could just have a round timer, where everyone’s moves need to be picked or submitted by the end of the round?
That seems to make sense. Maybe one could debate about whether it could be tactical to discuss something after someone locked in a move.
Maybe instead if moves aren’t visible, it wouldn’t matter if a submitted move changed before the time deadline.
I kind of imagine that with some variants, diplomatic, battle royal type stuff, giving people equal shared time to discuss and pick moves is probably better than players taking turns in an order, even if the moves are placed simultaneously afterward.
