Recording demo/playing it back

[Bilbo]

I thought about ability to record the session and being able to play it back later. Technically it should not be very hard, since the session would contain the savegame of state at start of the session, then appended stream of packets of world updates as it would come from network server (or even the exact stream that comes from network server if not playing locally.) Maybe add some extra info to the demo (viewport position, etc ...)

Replaying the demo would require just loading the map, then switch to spectator mode and start "receiving" the packets stored in the demo file as if they came from the server.

This may be invaluable to show someone how to do something or maybe to report some bugs ...

The demos will be probably incompatible between versions but ... it is still useful even in that way.

[Bilbo]

I wonder, IF the demo would be played by the exact version in which it was recorded ... would this "playback" work? In theory it should and basically, the demo will require same amount of data to record as is transfered over network if playing (or less if some compression is used) ... and since this is not much, the demos would be reasonably large, right?

Any insight from devs on feasibilty of coding this?

[Tom0004]

i believe someone attempt this awhile back, using sceenshots and putting them into a little video, but can't find the thread

[Bilbo]

i believe someone attempt this awhile back, using sceenshots and putting them into a little video, but can't find the thread :roll:

That would be awfully ineffective and lossy ...

What I thought of is a demo that will consist of a savegame (as received when starting game/connectiong to server), version info (to ensure it is played in same version as recorded) and stream of DoCommand packets as received from servers (and this stream will then build tracks, handle trains, etc ...) - or some similar stream generated when playing locally). Since OpenTTD is said to consume 1.2kbyte/second, this stream should have same size. So 1 hour demo will have about 4 megabytes. Which is IMHO reasonable and much less than 1 hour video. Also, such demos may be invaluable tool to hunt bugs and post bug reports ... :)

[RainierWatcher]

Since OpenTTD is said to consume 1.2kbyte/second, this stream should have same size. So 1 hour demo will have about 4 megabytes. Which is IMHO reasonable and much less than 1 hour video. Also, such demos may be invaluable tool to hunt bugs and post bug reports ...

Well, once the initial map array is stored, the rate is that anyway. But bear in mind that a 2048*2048 map will be about 4MB before anything else.

But I see where you are coming from, storing that data as it happens and replaying it might work.

[TrueBrain]

I think this is close to what you mean:

http://devs.openttd.org/~darkvater/patches/demo_v8.diff
http://devs.openttd.org/~truelight/patc ... 2.01.patch

The first is DarkVater's continued work on my initial patch to record a demo of an OpenTTD game and replay it later, the second is a rewrite of me from the v8, also trying to keep track of the mouse-cursor, in order to allow tutorial recordings. But as many of my projects (or DarkVater's for that matter), they tend to die when they take too long

(ps: as you can see, the patches are from REALLY long ago, and won't apply anymore

[Torrasque]

Well, once the initial map array is stored, the rate is that anyway. But bear in mind that a 2048*2048 map will be about 4MB before anything else.

But I see where you are coming from, storing that data as it happens and replaying it might work.

No, if you record an entire game, you juste have to send the seed used when generating land, wich is a few byte.

[RainierWatcher]

Well, once the initial map array is stored, the rate is that anyway. But bear in mind that a 2048*2048 map will be about 4MB before anything else.

But I see where you are coming from, storing that data as it happens and replaying it might work.

No, if you record an entire game, you juste have to send the seed used when generating land, wich is a few byte.

What if it isn't a random one? Plus the location of roads, buildings vehicles at the start, if you don't tart recording at the very beginning.

[Bilbo]

Well, once the initial map array is stored, the rate is that anyway. But bear in mind that a 2048*2048 map will be about 4MB before anything else.

But I see where you are coming from, storing that data as it happens and replaying it might work.

No, if you record an entire game, you juste have to send the seed used when generating land, wich is a few byte.

What if it isn't a random one? Plus the location of roads, buildings vehicles at the start, if you don't tart recording at the very beginning.

It will be solved same way as when joining network game. Start with sending (saving) entire map, then send (save) only commands after that.

[MagicBuzz]

Sorry, I didn't read all.

The big problem with demo playback is... the random factor.

Many parts of the game are using random numbers, so you can't reproduce exactely the same thing.

The best exemple is about the original Transport Tycoon game.
There were a button "tutorial", that just launched a saved game and let the computer playing to show the player the basis of the game.

Bad news, when the tutorial started, a news message was poping, and the tutorial mouse cursor accidentally click on it (because it was recorded without this message poping), then the screen scrolled to another area and the tutorial was completery stuck.

With this exemple, I can say the demo play back concept is quite easy, but the border effects can be huge and hard to predict

[richk67]

Actually, there are no truly random numbers in OTTD. It uses a seeded pseudo-random number generator. Reload the generator with the current seed, and the sequence after that is identical. Its the only way we can reliably do testing...

[Bilbo]

Actually, there are no truly random numbers in OTTD. It uses a seeded pseudo-random number generator. Reload the generator with the current seed, and the sequence after that is identical. Its the only way we can reliably do testing...

Also the only way how networking can work - the seed is maintained same between server and client - if client gets different seed than server somehow (like due to some bug), desync will occur.

[DaleStan]

The best exemple is about the original Transport Tycoon game.
There were a button "tutorial", that just launched a saved game and let the computer playing to show the player the basis of the game.

Bad news, when the tutorial started, a news message was poping, and the tutorial mouse cursor accidentally click on it

That has nothing to do with random numbers. That's the news settings. The demo assumes that you don't know how to change the news settings before you watch the demo.

[Bilbo]

That has nothing to do with random numbers. That's the news settings. The demo assumes that you don't know how to change the news settings before you watch the demo.

Still, the developers should have taken a bit precaution and disable the news for the demo. Well, there are many games when demo or tutorial will fail because on of the key characters dies or gets lost or stuck ....

I tired out of curiosity the demos in TTDPatch .. all of them fails because controls are a bit different than in original TTD ... :)

[DaleStan]

And *that* is because you didn't turn everything off first.

The demos in TTD are really weak, and we see no reason to fix them. If you actually want to watch, ensure that all news messages are set to "summary", and that all patches, except win2k, are off.

This isn't documented well, but since it comes up only once every couple of years, no one's bothered to actually do so.

[Zephyris]

If they dont work surely its time to fix/remove them?

[DaleStan]

They do work. Provided you do things correctly.