I'm afraid it's time to look into having save/restore for my #Machiavelli #Fediverse #bot. If you're wondering why I've done everything to do without so far, the answer is (de)serialization.
I think the main reason why it's not that simple is that in my code there is too intimate a coupling between games and “channels” (remember, this code has roots on an IRC bot plugin, that would manage one game per IRC channel).
Breaking this coupling would have a curb-cut effect: not only it would (probably) make saving and restoring easier, it would most likely also allow me to do something that I've been thinking about since I started experimenting with various UI to the engine:
Those that followed [my first thread on the bot development](https://sociale.network/@oblomov/110895903380866105) know that among the other things I also developed a web interface for the engine, which is currently *separate* from the other interfaces (console single-player, console LAN multi-player, web, Fedi). In fact, all interfaces are separate. But one thing I've been thinking about is that it would be … interesting (to say the least) to allow multiple interfaces to the *same* game.
Decoupling games from channel is “mostly” trivial, especially since my intent is to keep the restriction that each channel should only have one game. The non-trivial part concerns “broadcast” communications from the game engine to the *possibly* connected players over multiple separate channels. A similar challenge is actually what led me to suspend development of the web UI to the engine, although for different reasons.
The way the engine works currently is relatively straightforward: it receives messages through a channel, updates the state of the game, and then replies to *that same message* to propagate the updated state back to the user(s) following the game through that channel.
Decoupling games from channels leaves *that* part unchanged, but now we want to inform users of the updated game state potentially through other channels too. How?
The easy way to do this would be to assume a pull architectures: each interested channel can ask the bot for the new state, and notify the users on that channel of any changes.
On the upside, this works even on channels that have no “push” capability at all. On the downside, it doesn't work well on channels where messages (“pulls”) depend on user interaction (e.g. the Fediverse itself).
Imagine for example a combo Fediverse / web interface to the same game. The web interface can poll the bot via JavaScript timers to know when the game has been updated Fediverse-side, but a Fediverse player has to manually ask the bot periodically “whose turn is it?” just to know if it's their turn to play. Horrible user experience.
So even with decoupling, the engine still needs to track which channels are following a game, and it needs to attempt a “push” on update.
Honestly, this doesn't really look like a path that would actually help me solve my problem. Or at the very least, it “solves” it by opening a whole new can of worms: keeping track of which channels are tracking the game, and recreating the connections when reloading. Which actually is going to hit scope snags not too unlike the one I experienced during my first foray in save/restore.
Am I looking at this from the wrong angle?
I think I've satisfactorily completed the decoupling of games from channels in my #Machiavelli #Fediverse #bot. The next steps is to generate IDs for each game and provide a to (re)attach channels to games. I would like game IDs to be “meaningful” in some way, so I'm probably going to go with an ID based on the name of the user that created the game and the date when it was started, unless somebody can come up with a fancier idea.