[PATCH] Simulation - Game Record/Replay

[Stuart Walpole]

• Initial settings and all input is recorded.

• These same inputs can be fed back into the game at a later date so that the player can view it as a replay.

• User cannot affect what happens, but can view it (alter playback speed, look at play from any players' POV, etc).

• Needs a JS Interface. Should probably start and stop recording synchronized with CGame somehow. Needs a file format (pipe network packets to a file). Needs an entry point for replay (could do something wicked with CMessagePipe and the polling framework already in place for sockets, perhaps). http://www.wildfiregames.com/forum/index.php?showtopic=1665

• Also would need a Game Replay user interface to handle special features (selecting control of a different player, adjusting the rate of playback, rewind, etc) as well as select a replay to load (variation of Load Game screen).

---

Related tickets: #3168 Lets observer change perspective #3253 Save playernames to commands.txt #3255 Update directory structure to prevent overwrites #3258 Main menu entry to start visual replays

[(none)]

Milestone Advanced Multiplayer Demo deleted

[historic_bruno]

Attaching a work in progress patch for visual replay that uses the existing commands.txt log files. Currently it can only be accessed from the command line:

pyrogenesis -replay-visual=\path\to\commands.txt

Current features:

• Can choose which player to view (see their LOS, resources, etc.)
• Can view selection details for any entity
• Can view production queues (research and technology) for all structures
• Can use other session features (e.g. developer overlay)
• Can not control what's going on in the game, it's only for viewing
• Notifies the user when the last replay command is reached, can optionally continue viewing

An overview of how it works:

• Similar to autostart, a new startup mode for visual replays
• CGame currently responsible for parsing commands.txt, works similarly to current non-visual replay (see Replay.cpp​)
• New turn manager, CNetReplayTurnManager stores the list of commands (as strings) and adds them after each turn
• Shares some aspects of the normal session UI but has it's own page (I thought this was better than special casing all the different logic)
• CGame detects the last command and sends a message to the replay UI

TODOs:

• Make this a main menu option
• The replay data is stored in text files which are not efficient to parse, should probably be more like saved games and include separate metadata. Compression would be nice
• No speed controls in the UI
• Doesn't really support "rewind" - rewind requires something like timewarp mode that stores the simulation state at each turn to allow going back in time, which eats lots of memory
• Make saving replay data an option?
• Use VFS to access replay file?
• Possibly factor out common parts of session and replay UI into separate files? (may also help with e.g. observer mode)

[Jonathan Waller]

Just some comments on what I think would make a good replay selection GUI. If we are auto saving every game we want to make it possible to find games easily without the user needing to enter a suitable title.

The key information is player names, date, game duration and map name. Some indication of the winner would be nice as well (maybe an icon next to their name). Giving the option to name a game manually would be good as well but I think auto naming should be primary.

[alpha123]

Update for a newer SVN version.

[alpha123]

Update for SVN r14723. May also work on A15.

[elexis]

Updated patch and removed GUI code. Replays a commands.txt file visually without GUI.

[elexis]

This patch replays a commands.txt visually with the -repay-visual=/path/to/commands.txt argument. Contrary to earlier patches, this one uses the observer mode, so that the HUD is visible and the viewer can't issue commands while replaying. Also it doesn't change the DEFAULT_TURN_LENGTH_SP to 500, but rather supports variable turn lengths by reading the turn length from the replay and updating it each turn. It seems to work fine already. However to make sure that the replay shows the actual recorded game, further testing is necessary. I thought it might be feasible to check for oos by reading the hash values from the replay file too and comparing them to the hash of the simulation state. However I get an out of sync on each turn with this version. Help welcome.

[elexis]

Thanks to Itms for committing r16531! This has helped me to find the reason why the previous patch caused an oos on every turn.

First I produced some oosdata with the -ooslog option and replayed the commands.txt after that with the -ooslog and -replay-visual option. This is the diff for the first turn:

1c1
< State hash: 5f703e921353f9018aa129164a7b4c4e
---
> State hash: 06f3356df65d0fe3e4392afbe2d3a224
28849c28849
<   "time": 500,
---
>   "time": 200,
28851c28851
<   "turnLength": 500
---
>   "turnLength": 200

Updated patch will follow soon.

[elexis]

No more out of sync. Should be ready to commit / ready for review. Other observer related features will be implemented in different tickets, like #3168.

[elexis]

JFYI: I removed the const keyword in Replay.h, because I otherwise would get the following compile error:

../../../source/ps/Game.cpp: In constructor ‘CGame::CGame(bool, bool)’:
../../../source/ps/Game.cpp:82:43: error: invalid new-expression of abstract class type ‘CDummyReplayLogger’
   m_ReplayLogger = new CDummyReplayLogger();
                                           ^
In file included from ../../../source/ps/Game.cpp:39:0:
../../../source/ps/Replay.h:55:7: note:   because the following virtual functions are pure within ‘CDummyReplayLogger’:
 class CDummyReplayLogger : public IReplayLogger
       ^
../../../source/ps/Replay.h:44:15: note: 	virtual void IReplayLogger::Turn(u32, u32, std::vector<SimulationCommand>&)
  virtual void Turn(u32 n, u32 turnLength, std::vector<SimulationCommand>& commands) = 0;
               ^
engine.make:259: recipe for target 'obj/engine_Release/Game.o' failed

On may 19th leper noted on irc why that change is needed:

(17:10:33) leper: ah, yes removing that const makes sense since the other loggers don't have it (17:11:15) leper: which means you have a pure virtual function in that the dummy logger which is what the compiler complains about (17:11:23) leper: now why are those others non-const (17:12:25) leper: could it be that one "bug" that StringifyJSON needs non-const? (17:17:07) leper: elexis: so that const change is ok (17:17:32) leper: (because JS_Stringify needs a JS::MutableHandleValue)