Ramblings of mine about recording/play back etc

Feature Requests
1

Hi,

A common complaint I find with new players (and with myself when I began using Vassal), is that trying to understand what your supposed to do with the interface to make log files, record moves etc, is not at all obvious. I remember myself I had to do quite a bit of experimentation writing and playing back log files etc, before I had a grasp of what was happening.

I propose that the main screen/toolbar/status bar should expose the user to several things …

  1. The current state of the game …
    … Did I just load someones log file?
    … Did I just save the game?
    … Am I logging moves?
    …A biggy => How many moves of what total moves have I played back, and when recording, how many moves/comments have I recorded? This should be front and centre when recording … a big record button on the toolbar, and a count of the moves/steps/what-ever recorded so far.
  2. I just broached the subject, but record and play back buttons and also a save game button (or save game at current position so as to distinguish it from save a log file). And someplace either on the tool bar or status bar, some feedback about the play back or recording.

You know, the number of times I have played back someones file, then saved the game, and later or next day or next week I have loaded it to start recording my moves, but forgot to open a log file. My big issue here is that the only way you know your recording is the title bar changes. That is not sufficient notice. And during playback, you only know when your opponents moves have finished because the toolbar button becomes inactive.

I am clutching a little at straws here. I know something is really wrong and annoys me with the interface, and everytime for example I have to explain to a new Vassal guy about recording etc I think why isn’t the interface showing him what needs to be done.

Oh, another one. The other day a guy was recording his move notes in the Notes widget under Public notes. I explained that he could just enter them into the log window chat and they end up in the log file. Again, this is not immediately obvious.

  1. Perhaps when ever you begin a new log file or new game (not just when you first open Vassal), the chat window edit box could contain an inactive message like . Or if your playing live with another player . This message could change and you change mode, which again is more visual feedback to let the user know what they are doing (recording/playback/live etc).

Some thoughts or ramblings perhaps. But yeah the main interface I feel needs to revolve more around numbers of moves and the current mode, are you recording a log file, how many steps etc.

Regards,
Scott

2

See vassalengine.org/wiki/Roadmap#3.3 Logging Improvements.

Unfortunately I would hazard a guess ( I think it has been previously discussed partially by devs) that after the release of 3.2, this version of Vassal will be deemed End Of Life and any further changes such as 3.3 / 3.4 will not happen and instead it will be easier/applied to the new Version 4 instead. So basically could be awhile till that gets done in other words :slight_smile:

3

I’ll have to search for that thread where the previous discussion happened, I only barely remember it. But I agree with virtually everything Scott said.

I’m not sure I can point to what good logging and playback should look like, but obviously what exists is well short of ideal. More prominent visual cues that playback/logging are in process would definitely be a huge help.

The other area where my groups have gotten muddled is the fact that there is no board state check that occurs when you load a logfile. We had a case where a player made a log, then subsequently his play was canceled by someone else and we decided to have the next player in sequence carry on logging without incorporating that most recent log (essentially reverting to the logfile previous to it). Unfortunately another player had been using the Load Continuation feature all the way through and missed the email exchange directing everyone to ignore the one player’s logfile. He loaded it, played it back, and then followed up with the log he was supposed to start with, leading to a large discrepancy in board state between his logs and everyone elses. From what I can tell, VASSAL right now cheerfully loads any log you throw at it, which makes Load Continuation awfully prone to human error. Maybe it’s a big coding challenge, but some sort of mismatch warning would have saved us a lot of grief in this case. With a 6 player async game, it’s almost inevitable that mixups like this will happen at some point.

4

Thus spake JoelCFC25:

I’ll have to search for that thread where the previous discussion
happened, I only barely remember it. But I agree with virtually
everything Scott said.

I’m not sure I can point to what good logging and playback should
look like, but obviously what exists is well short of ideal. More
prominent visual cues that playback/logging are in process would
definitely be a huge help.

Quite some time ago now (maybe three years ago?) Tim and I worked out
what we thought would be a good way. It amounted to having a list of
actions/events, with a marker (maybe a line?) at an insertion point
(between events) indicating the current state. Events before the line
can be undone, events after can be redone. If a new action is taken,
events after the line disapear (i.e., the redo list clears when you
do something new). Somewhere near this (below?) there would be a set
of VCR buttons (|<, <<, <, , o, >, >>, >|) for navigating the history.

The other area where my groups have gotten muddled is the fact that
there is no board state check that occurs when you load a logfile. We
had a case where a player made a log, then subsequently his play was
canceled by someone else and we decided to have the next player in
sequence carry on logging without incorporating that most recent log
(essentially reverting to the logfile previous to it). Unfortunately
another player had been using the Load Continuation feature all the way
through and missed the email exchange directing everyone to ignore the
one player’s logfile. He loaded it, played it back, and then followed up
with the log he was supposed to start with, leading to a large
discrepancy in board state between his logs and everyone elses. From
what I can tell, VASSAL right now cheerfully loads any log you throw at
it, which makes Load Continuation awfully prone to human error. Maybe
it’s a big coding challenge, but some sort of mismatch warning would
have saved us a lot of grief in this case. With a 6 player async game,
it’s almost inevitable that mixups like this will happen at some point.

Merging logfiles is not so different from merging branches in a version
control system. In a multi-player game where players take turns
simultaneously, you’ll need a way to join the logs together at the end
of each turn. So long as the changes can be merged consistently, simply
dumping all of the player logs together while maintaining the relative
order of their actions suffices. The difficult thing is defining what
“consistency” is. For example, if two players try to move the same peice
to different places, that will tend to be illegal in most (but perhaps
not all) games. What other things can be merged consistently will depend
on the game you’re playing, and most likely you’ll need someone to
resovle these things by hand.

–
J.

5

I think each log file should be stamped at the end with “user name + time-date”. That is pretty unique. Any log file created on the end of the playback (i.e. I replay the log file then sometime later start recording mine and that indeed could be immediately, or at a later session perhaps next day or next week after I reload the vsav file) should have this “link” to the previous logfile, the user name and time+date. If, during a multiple player game, a player inadvertently tries to playback a log out of sequence, the program could easily identify this and warn the user. Actually, you could just use some unique atom rather than user name and time-date, or in addition to it. The important thing is that this log file be uniquely identified among all log files.

You could get quite clever here, and in each log file, keep a link to all the previous log files - just the user name and time-date and any other unique identifying information.

This would also solve another problem I have had, where a player makes some kind of error during the turn, and the other players suggests that this player should correct the move. Did the first player then send the other player a replacement log file or one that is supposed to be appended to his last one? Currently I try to enforce the rule that the file name should have the sequence number at the start i.e. First log file is “000xxxxxx” or “001xxxxx”, next is number+1. Something along those lines. So if you get a log file with the same sequence number after a correction then it replaces the last log file. Now, I don’t want Vassal to enforce any naming conventions for the log files - we can take care of that ourselves and the conventions vary with game and number of players. But, Vassal should be aware of where in the sequence this particular log file belongs. If I try to replay it on the end of the wrong log file (i.e. some other log file), I expect Vassal to pop up and warn me. Now, I don’t want it to NOT replay the log file if I still insist, but I would like it to warn me in big bold letters that the game may now be inconsistent.

Now in fact if the game keeps a record of all the previous log files that have been recorded to bring the game to this point, you could look this information up in a list and perhaps glean other useful facts from it. For example, how fast individual players take their turn. “Is it my turn or yours now it’s been 3 weeks since I last saw a log file and have forgotten?” Has Joe had his turn yet, this round has taken 3 weeks and I can’t remember? … These are just ideas but with the simple “link” to previous log files, you can accomplish a lot of other things.

The issue of what is consistent playback is an easy one. Each event is unique and occurs at a unique time in a linear sequence among all the other events. When 2 players go for the same piece, only one can grab it and move it. The other player will grab thin air. But this situation only arises in real time play, and the issue here is one of concurrent access to the game interface and not a log file problem. There is no simultaneous or concurrent playback of different log files, because either the players recorded their moves separately and their log files get played back one after another in sequence, or they were playing in real time in which case there is only one log showing the sequence of all players moves. If you try to develop a game where both players conduct game play in log files separately and then try to merge them later, this introduces all kinds of contention problems, access to pieces etc, and I suspect at that point how to merge log files will be a fairly trivial side issue.

Cheers,
Scott

6

Au contraire, my friend, you clearly don’t play online much. :wink: I think what actually happens is they both grab the piece and then their clients’ game states fall out of sync; one completes the drag event and sends an update command, and the other completes the drag event and sends an update command and then processes the first player’s command, giving them two pieces - or perhaps this only happens with decks, or perhaps in a different manner entirely. I would post a bug about it, but I can’t personally test the exact conditions for failure with only one computer. Anyways, never tell your players ‘Everyone draw a card from deck X’, it will only end in tears.

-Seth

7

Thus spake anonemous123:

I think each log file should be stamped at the end with “user name +
time-date”. That is pretty unique. Any log file created on the end of
the playback (i.e. I replay the log file then sometime later start
recording mine and that indeed could be immediately, or at a later
session perhaps next day or next week after I reload the vsav file)
should have this “link” to the previous logfile, the user name and
time+date. If, during a multiple player game, a player inadvertently
tries to playback a log out of sequence, the program could easily
identify this and warn the user. Actually, you could just use some
unique atom rather than user name and time-date, or in addition to it.
The important thing is that this log file be uniquely identified among
all log files.

You could get quite clever here, and in each log file, keep a link to
all the previous log files - just the user name and time-date and any
other unique identifying information.

This would also solve another problem I have had, where a player makes
some kind of error during the turn, and the other players suggests that
this player should correct the move. Did the first player then send the
other player a replacement log file or one that is supposed to be
appended to his last one? Currently I try to enforce the rule that the
file name should have the sequence number at the start i.e. First log
file is “000xxxxxx” or “001xxxxx”, next is number+1. Something along
those lines. So if you get a log file with the same sequence number
after a correction then it replaces the last log file. Now, I don’t want
Vassal to enforce any naming conventions for the log files - we can take
care of that ourselves and the conventions vary with game and number of
players. But, Vassal should be aware of where in the sequence this
particular log file belongs. If I try to replay it on the end of the
wrong log file (i.e. some other log file), I expect Vassal to pop up and
warn me. Now, I don’t want it to NOT replay the log file if I still
insist, but I would like it to warn me in big bold letters that the game
may now be inconsistent.

Both problems you mention can be solved by (1) keeping one log per game,
rather than per turn, and (2) better log management tools. #1 is up
to the players. #2 is planned for VASSAL 4.

The issue of what is consistent playback is an easy one. Each event is
unique and occurs at a unique time in a linear sequence among all the
other events. When 2 players go for the same piece, only one can grab it
and move it. The other player will grab thin air. But this situation
only arises in real time play, and the issue here is one of concurrent
access to the game interface and not a log file problem. There is no
simultaneous or concurrent playback of different log files, because
either the players recorded their moves separately and their log files
get played back one after another in sequence, or they were playing in
real time in which case there is only one log showing the sequence of
all players moves. If you try to develop a game where both players
conduct game play in log files separately and then try to merge them
later, this introduces all kinds of contention problems, access to
pieces etc, and I suspect at that point how to merge log files will be a
fairly trivial side issue.

Merging separately constructed logs is nontrivial, and in some cases
won’t have an algorithmic solution. (It’s essentially the same problem
as merging branches in a VCS.) If you have two players move the same
piece differently, how that should be resolved, if it’s even legal, has
to be determined by the rules of the game being played, not in some
generic way by VASSAL.

–
J.