So I'm on break right now, and there's a Dominion-related project that I've wanted which doesn't exist yet.
Basically, when I was writing an article (I think it was Leveraging Information), I realized that the log prettifier is really helpful in comparing decks between turns, but not for seeing choices made in the middle of the turn. With a little work, you can figure out what order people played actions in, but without keeping track yourself, it's hard to, say, find out what actions a player didn't play because it would cause a reshuffle. For engine games, this is especially bad - there's no way I'm going to go through a page worth of text to figure out exactly how much buying power the player had that turn, even though that's one of the most important things to know. In short, right now it's easy to understand the macro strategy of what cards people buy and when, and it's much harder to understand the micro strategy of how people actually play their decks.
However, in game log, we have a record of every action made. Therefore, from that log, we should be able to rebuild the game state at any point, even in the middle of the game, and then you can learn whatever you want to learn. I remember mentioning this to AI one time, and he said he tried to get something similar working in Goko, but he couldn't.
If people think this is worth the time, I can start looking into it, but I'd probably need help. My Javascript is like a solid 1/10, and there's a lot of parts. In terms of design, I'm seeing the following:
- From a log, correctly reconstruct the exact hand, board, and supply state for each player. The existing log viewer code may do parts of this, but I think you'd need to write your own parser.
-- I'm envisioning a slider that you can move back and forth to apply/unapply actions. The game state constructor must be able to both apply and unapply a line of log text to handle this. Alternatively, whenever a client moves the slider, start from the beginning, and apply each line until you reach where the client stopped. Actually, the way that gives best performance is probably going to be saving the state after every line in an array of game states on initialization, then choosing the proper game state from this array on client-move. (DP FTW)
- Reconstruct the Goko interface, or at least a decent enough interface to display all this information. Given that AI had issues doing this within Goko, this most likely will need to be written from scratch, meaning an Iso-looking bare-bones interface is most likely. Frontend people can help here.
-- At a given game state, list what cards are in each players deck. Ideally, display what cards are in discard, in draw, in play, and in hand, all separately, since deck tracking is important to explain things like Wishing Well decisions. Figuring out how to lay this all out is tough.
-- This interface is going to need the ability to switch between player perspectives. Well, maybe not, there might be enough space to have full information displayed. This is up for debate.
-- Same issue as the backend code - rebuilding all DOM elements for each game state is easier to code, but worse performance. Updating the elements dynamically is better performance but trickier to write.
- Get general networking going, so that people can actually use this.
This feels like a lot of parts to me, but it probably isn't actually that bad. It certainly feels like less pieces than the extension itself, and there's no dealing with Goko's code since this is presumably made from scratch.
If people are interested in helping out with this (or have comments in general), let me know. If people think this wouldn't actually be that useful to have, also let me know.
Author
Topic: Interest in a Dominion replay system? (Read 7406 times)