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.