Some new design thoughts

A logfile is a well-known feature in VASSAL. It facilitates PBEM.

A logfile consists of a start state and a number of individual moves. A logfile is created by first saving the game and then recording moves. At log end the recorded moves are saved together with the saved game.

When you load a file, as soon as appended moves are detected then it’s a logfile, not just a saved game.

Saving and loading of games has already been implemented. Also, recording of moves has been implemented through the undo-stack. So the only new code necessary is to combine a saved game with appending the moves on the undo-stack.


Choosing Begin logfile... from the menu lets you specify the name of the logfile and then starts the recording. A red circle appears on the toolbar to clearly remind you that recording now takes place.

End logfile will append the made moves (the content of the undo-stack) to the logfile specified in Begin logfile...

Opening a logfile will activate the step buttons on the toolbar. There are three buttons: Step, Go To End and Abort. Illustrations can be found on my GitHub.

Step will step forward one move. Go To End will step to the end of the logfile (if you for some reason don’t need to see the individual steps). Abort will exit stepping at this point. This can be of use if a mistake has been detected that makes it impossible to go on. Needless to say, the reason for aborting a logfile must be good and made clear. Often a mistake in a logfile need not influence later moves. There has to be a very good reason for aborting a logfile.

I have imposed a few restriction on recording and stepping. These restrictions are temporary. If good arguments for removing them come, I will consider that.

In recording you can not undo a move. It has a very practical reason. If you could undo say a bad die roll then using logfiles would never work. I know very well that moves need not be saved on the undo-stack but on a seperate stack. But that would need more code. I think that the nature of recording should prevent undoing moves. If you make a mistak it’s fair to take it back but this should be explained and made apparent in the recording. So no undo while recording.

In stepping through a logfile, a step can not be undone. Steps in a logfile are not put on the undo-stack. Even more important, when stepping a logfile no other operation is possible. All counters are disabled. No new counter can be dragged to the map.

I see no purpose in doing anything else while stepping a logfile. If you could, say, delete a counter that is later moved by the logfile, it would not be good. It is the land where bugs grow. All kinds of complications could arise if you can do things to the game that your opponent can not see. If an error occurs in the logfile then you can abort.

Again, if there is a good reason to make your own moves while stepping a logfile, then this restriction can be removed. Usually it is possible to step through a logfile and then start recording and make your own moves. The gameplay becomes cleaner by this in my opinion. But it depends on the game and circumstances. I do not have all the answers.

Note also, it is not possible to record while stepping through a logfile. Given the restrictions above, this is useless.


All actions will always be logged to a chat-console window (and possibly also to an output file).

Note: the chat-console window is not made yet. It will be the third window besides the map window and repository window. I will come back to it later. For now it’s more important to implement vital functionality like cards and grids.


A summary of the engine so far:

  • A modules consist of Luau script files, a C++ binary, the Luau VM engine and the Qt library. Each module has it’s own copy of the GUI library so we never need to worry about changes.
  • A configurable window for access to all the game’s counters, the Repository window. Counters can be accessed in tabs, lists and combo boxes in any order.
  • Definition of traits (counter abilities). Inheritance of traits to build more complex traits.
  • A script-driven interface to the C++ engine. Script can do most of the operations a user can do.
  • A Luau sandboxed environment for security.
  • A rigorous undo/redo system for undoing mistakes or just checking what took place.
  • The ability to scale the map, either by a fixed percentage or free scaling with the mouse wheel.
  • The ability to rotate the map by fixed increments of 90 degrees.
  • The ability to open and manipulate stacks, either by increasing the offset, or as offset-less stacks where you select and reorder counters in a popup window.
  • Saving and loading of games.
  • Recording and stepping through logfiles.

Up until now I have basically made a copy of VASSAL. Now it’s time to go into new territory and try to implement features you do not find in VASSAL. I will try to implement the so-called artillery-tables in Verdun: A Generation Lost. I will describe in detail what these tables are and what they are meant to do.

It will be a good test. It must follow the design. I can not make “hacks”. It will be the real test of the engine. I hope that in making these tables I will show the abilities of the engine.

1 Like

Some thoughts on your critique of this feature:

It’s sometimes useful to record an online session.

If a module has to handle its own undos, this will require more effort in module development in proportion to the complexity of the actions that the module allows (movement triggers come to mind).

Vassal allows “presumptive play”. This speeds up PBEM turnaround considerably for highly interactive games. Unrestricted undo and ability to add into a log file are key features that enable this feature.

I don’t mean to detract from your concerns. Undo is certainly one of the more bug prone areas of Vassal, in my experience. And, it’s not uncommon to have to make manual corrections where a log file makes changes that an intervention has invalidated.

Aside: One thing I could use in Vassal v3 is a checkpoint feature, so that a module can prevent undo beyond a key points (say when some hidden information has been revealed).

1 Like

Thank you for your comment!

I can not in any way have a complete knowledge of what a board game engine needs. Therefore comments like yours are very important.

In my development of the prototype I have gone through many issues lightly. Typically I make a simple version of something (like logging) or just provide an example of something (like with ownership-rights). I do this to keep the overall goal in mind. I have to focus on the essential (next up cards, then grid) and not get bogged down in detail.

In my opinion it’s better to give users choices rather then decide how things are done. An example are stacks, with or without an offset. I don’t think it’s wise to decide what is “right”. If it is necessary to undo while recording then fine. It will be developed and given as an option. If players want to undo while stepping through a logfile, or be free to move their own counters, then fine. Implement it and give it as an option.

A module should never need to handle their own undo. Then the design is flawed.

It is possible to record while online, just not when stepping through a logfile offline.

You mention prohibiting undo after hidden information is revealed. I agree. One solution is to record all undo in a fashion that can itself not be undone. This may be easier to implement.

2 Likes