Add support to record and replay game commands/actions.

[ZehMatt]

This is something I wanted to do for a longer time now. Basically this records all game actions and game commands and replays it back.

Small preview: https://share.epic-domain.com/2018-12-06_06-30-281437ce2a04a2d1077.webm

[ZehMatt]

Ok a few things that we need to discuss:

1. What should the file extension be for replays?
2. What should the output filename look like?
3. Is the current path acceptable?
4. Should user interaction stay locked while the replay is active?

And I think it would be better if we save the cheats and in replays as we can use them to do regression tests on hacked parts.

[AaronVanGeffen]

This is a really neat idea. Sounds like this would make a really neat way of making time-lapses as well, e.g. for NE design parks.

[ZehMatt]

My current goal is to use this system to generate regression tests. Lets say something would crash by placing a scenery in a specific way. So we fix it, we create a replay and put it to the regression tests, that assures that the exact situation will not ever crash again. But yeah I think this system could be used for more like macro recording. Right now its currently bound to park snapshot and specific ticks but it could in theory save some optimized output to simply replay actions.

[ZehMatt]

Okay I think this should do, the WIP label can be removed. However we need to decide where what goes still.

[fromthere]

I think this can be used to create tutorial(there should be popup function though)

or speedrun recording? (with early completion feature)

[ZehMatt]

I might look into that afterwards, my focus currently sits more on stability and such tests can easily detect if something fundamentally changed in the game logic or rendering.

[Gymnasiast]

I ran into difficulties fixing the Xcode project on this. It complained about not being able to find gtest.h after I added the ReplayTests.cpp file to it. On closer inspection, it appears the Xcode project does not do testing at all, which might explain this.

[janisozaur]

Perhaps it's finally time to move macOS builds to cmake, given how problematic updating the xcode project is on account of both technical term as well as social – there's nobody using it.

[Gymnasiast]

I think Xcode is needed to make an .app package on Mac. Cmake just makes a Unix-style binary.

[ZehMatt]

Perhaps skip ReplayTests.cpp for the time being?

[Gymnasiast]

The problem is that it can't compile due to it not finding symbols. The regular code should not need test sources (the other way round is fine, and inevitable).

[IntelOrca]

I think there are cmake extensions for creating a .app, a .app at the end of the day is just a directory so we can always create it ourselves manually. Someone with more experience would need to investigate this.

OpenLoco has proved to be much more convenient regarding macOS (e.g. no xcode and filesystem via boost).

[IntelOrca]

The problem is that it can't compile due to it not finding symbols. The regular code should not need test sources.

What src/ source file are you referring to? I don't see any that require test headers.

[Gymnasiast]

@IntelOrca https://github.com/OpenRCT2/OpenRCT2/pull/8374/files#diff-5c155256c2c881f7688d360b0d381fafR12

[ZehMatt]

Only ReplayTests.cpp includes gtests.h, so the idea was to leave ReplayTests.cpp out of the Xcode project/build.

[Gymnasiast]

Oh, wait, I now see what I did wrong. I added ReplayTest.cpp instead of ReplayManager.{cpp,h}. Taking another stab tonight.

[janisozaur]

I'm pretty much done with reviewing this and most of my requests have already been taken care of.

Other than the remaining comments I also have one more request: at the very beginning of record data add recording version id ("1") and network stream version string. I know it's not expected to change in format but if it does it will make it easier for us. In case of recording version reject replays in different version, for network stream print a warning stating the current and expected version as well as hint to perform normalisation.

I still haven't tested it, I'd like to do so tomorrow.

[ZehMatt]

Fair enough, will refactor it slightly to support other versions if required.

[janisozaur]

Last minor comments and a suggestion: it would be nice to have some indication the playback has finished (other than the status text missing) like a pop-up (think: network desync) and the client getting paused.

Other than that it's fine to get merged.

[ZehMatt]

I left out the pausing of the game as that felt really off. Also instead of a window popup I have used the news queue which seems to do the notification job well enough, also when pausing the game it would stop updating the news queue and only half way renders the text, hope this approach is fine too.

[janisozaur]

The news ticker approach sounds fine. There's some failing CI job now.

[ZehMatt]

Yea GCC would need a macro but I rather wen't the C++ approach using stringstream now which at least adds type safety.