Game Record & Replay

[Esodi]

Hello Everyone!

I played Transport Tycoon a very long time ago. In the meantime I had forgotten all about it.
Now that I tried OpenTTD, I am addicted again right away.

OpenTTD has evolved beyond the original game. For example, there is now an online multiplayer
feature. This is great, because now you can share the OpenTTD experience with your friends.
Perhaps even be a little competitive.

There is a limitation, though, you can only share the game you play with the people you are
playing it with. There is no way to record it to gloat over your achievements later, or to
present a great game to those that could not be there to observe it.

Personally, I think this would be a great addition to the game. At the end of a game, you
could "save the recording" as it were a saved game. For playback, you would load it as a
saved game. Hosting and replaying games over the internet would also be possible.

Of course, playback can be (has to be) faster than real-time!

Unfortunately, the current implementation does not easily allow for a recording feature. The
problem is that any change to the game would break replaying compatibility. You could only
replay games in the same version they were recorded with.

Working around this would be a lot of work. Although not impossible, it would probably
require a complete redesign of OpenTTD's inner workings.

My questions to the community are

[1] Does anyone besides me really miss a recording feature?
[2] Would recordings be worth it if you could only replay them in the same version they were
recorded with?

[LilDood]

1) nope most games are hours long

2) Its would be a video you probably wouldn't even need OTTD to play it back

[Esodi]

Ah! I forgot to mention : )

A video is not acceptable because filesize is way too large, you can't control your vision area yourself, and you cannot possibly host it as a game online, to chat about it.

[Rubidium]

Efficiency in file size and speed are mutual exclusive. You either want a really fast replay or a small file size. Because small file size means you are effectively rerunning the whole game in fast forward.

Secondly, you have to tell before you start the game whether to record it or not. Afterwards is not possible, as all data has been lost and it is nonsense to keep that data in memory.

It would be best (file size wise) to use the current efficient network protocol, which is about 1-10 kB per second (3.5 to 35 MB per hour) and only stores the actions performed by the users. However, to get exactly the same game, you have to run it with the same version as any minute change in the game logic, i.e. fixing the acceleration of a vehicle or even the growth algorithm of houses makes the playback useless.
Unless somebody comes up with a brilliant way to store the core game logic in the savegame that can be run at the same speed as the current game logic and on all platforms the current game logic works on, i.e. develop an interpreted language that is always as fast as the native C(++) code.
It furthermore means that there needs to be a stable API for almost all other functions. This means that those API functions will become big wrappers around other functions as the way the map or a vehicle is stored is changed.

So in short: a fast and small playback with backward compatability becomes one big maintainance problem within a matter of weeks.

Furthermore, do you want to be able to start anywhere during the game play, go back etc? Then you need to make regular save games like the 'key frames' in videos, considerably blowing up the size of the replay.

[Ben_K]

Admittedly, recording would be nice in order to produce tutorials, for example. Or to take the neat screenshots even further! I wouldnt use it if I could record a whole game - mine last for days and days... I would use one that I could run to record shorts sessions.

Hmm... maybe something you could attach to a 'extra viewport' or something

[Mchl]

It would be best (file size wise) to use the current efficient network protocol, which is about 1-10 kB per second (3.5 to 35 MB per hour) and only stores the actions performed by the users. However, to get exactly the same game, you have to run it with the same version as any minute change in the game logic, i.e. fixing the acceleration of a vehicle or even the growth algorithm of houses makes the playback useless.

Would it cover also random events (vehicle breakdowns, disasters etc?)

[Rubidium]

Would it cover also random events (vehicle breakdowns, disasters etc?)

Yes, as they are not really random :)

[Mchl]

Yes, as they are not really random

I knew there was some cheating going on!



Anyways, from what you've written it seems to me that also changes in newgrfs could spoil the replay (say, someone tweaked vehicle speed or capacity a little). You would also want to save patches configuration and all changes to them during the play...
Or maybe this is covered in current protocol already...

[Rubidium]

Either the patch changes are distributed properly in multiplayer games or they are not enabled (AFAIK).

The 'modified GRF' is the reason why we use the MD5sum to check whether everyone has the same version of a GRF in multiplayer games.

But yes, any modified GRF will also destroy the replay; basically everything that would cause a desync in multiplayer games would destroy the replay.

[Mchl]

So a person willing to view a replay posted for example on these forums should have
1. Same build of OpenTTD as the person who recorded it (I guess that even some platform related issues such as floating point representation could have negative effects here - most likely not, but might be worth thinking of it).
2. Same set of grfs (exactly the same versions).

In my opinion too impractical for wide use. Might be fun to record your games for yourself, but you'd have to keep track of application version and grfs used to be able to replay them...

I know! Let everyone install SVN on their PCs (I already did )

[cmoiromain]

if you want to show your games to other people, there are other things to do:
either the person joins the server as an observer
or you can use a video screen capture software to create a video of your game, and send it to him...

Or maybe I didn't understand your message correctly...

[Rubidium]

1. Same build of OpenTTD as the person who recorded it (I guess that even some platform related issues such as floating point representation could have negative effects here - most likely not, but might be worth thinking of it).

Not an issue as there is no floating point used in the game logic; the only place you'll find it is in the TGP map generator.

2. Same set of grfs (exactly the same versions).

One could store the version in the savegame/replay. The used GRFs are already stored in the savegame with MD5 checksum, so can make it enforce the NewGRFs as in a network game.

[Mchl]

1. Same build of OpenTTD as the person who recorded it (I guess that even some platform related issues such as floating point representation could have negative effects here - most likely not, but might be worth thinking of it).

Not an issue as there is no floating point used in the game logic; the only place you'll find it is in the TGP map generator.

In that case let's hope there aren't any others platform related problems.
I've written about floating points, because I've seen it causing problems, but it was a scientific project which relied on precision of calculation. That's why it popped int my mind.
Abyway, it is quite tricky not to use floats at all

2. Same set of grfs (exactly the same versions).

One could store the version in the savegame/replay. The used GRFs are already stored in the savegame with MD5 checksum, so can make it enforce the NewGRFs as in a network game.

My point is. Apart from knowing the version, one also needs to have proper files. Obtaining them might be difficult (especially if author used a build compiled and tweaked by himself). Of course at some point in future most people will use 'final' version of OpenTTD... or maybe not...
Nah... it's too late for me to think clearly, let alone putting down results of this process...


To sum up: I must say, that I like the idea of using network communication protocol for this purpose. It's kind of... clever
The difficulty I see, is that there be problems concerning diffirent versions of recording and replaying clients.

Good night