Approved "Real Time" Replay Speed

[CALLOUS]

Hello!

I have a YouTube channel and frequently narrate tournament games. As is, we as narrators have to make a choice. We either try to catch the game live, which is not always doable due to different people having different schedules, someone being at work, etc and does not allow for any redos/retakes or we simply narrate a replay after the fact. The beautiful thing about live is you get to see when the players pause for 30 seconds, 60 seconds, two minutes, etc during critical turns and it's excellent for the spectator experience not only because narrators can talk over the situation/discuss outs and lines/hype it up but also because it goes a long way towards building up the tension and the drama. In a replay, a decision that someone sat there and took over two full minutes to think about before finally deciding simply happens instantaneously just like any other turn. Yes, it notes in the battle log that someone's timer was going down, but it's very much not the same thing as experiencing it.

I'd really love to see a speed added to the replay viewer called "real time" or something along those lines which does exactly what it sounds like it should do- replays the battle at the speed it was played, including the pauses, in real time. For those who just want to zip through battles all the current speeds (including very fast and the ability to outright skip turns) would still be there, so there would be no drawback to implementing this, and as a narrator/content producer this would give me the best of both worlds- the drama, tension and realistic pacing of a high stakes tournament game (which currently cannot be done with a replay) but also the ability to pause and talk as long as I want (which cannot be done with a live game) and the ability to do retakes/redos if I blatantly mess up (which also cannot be done with a live game).

Thank you very much for reading and considering! :)

 

[pre]

This requires a protocol change as currently there are no timestamps included in the sim protocol, so it would be impossible to include the 'lag' with the current (and historical) replay data (one could kind of fudge things in the cases where timer messages showed up, but that would be hacky and wildly inaccurate). Every protocol line wouldn't need a timestamp, only 'decision points' (off the top of my head: |teampreview|, |turn|, but also |switch| in certain cases like Baton Pass, U-Turn, Healing Wish, etc). Realistically, the amount of work (protocol changes which would require changing *everything*, from usage stats scripts to bots etc, replay viewer changes) relative to the benefit the feature provides is unlikely to be worth it.

 

[Zarel]

This is pretty niche, but it seems surprisingly doable. Adding timestamps to specific parts of a replay should be pretty straightforward, and is probably useful to have regardless.

If you just implement it by way of an "empty timestamp" message, things like usage stat scripts and bots probably mostly wouldn't need to be updated.

 

[pre]

If you just implement it by way of an "empty timestamp" message, things like usage stat scripts and bots probably mostly wouldn't need to be updated.

|:|TIMESTAMP already exists in PROTOCOL.md, so yeah, we can technically just use that (though its status currently appears unclear). Just have the server send it whenever it sends back any information and that also gets around needing to worry about 'decision points' or breaking existing protocol

 

[Zarel]

|:|TIMESTAMP already exists in PROTOCOL.md, so yeah, we can technically just use that (though its status currently appears unclear).

Sadly, its current meaning is "this is the current server time, please use it as a delta for the other messages to find your own timezone", which is incompatible with the meaning you want for it. We'd have to use something else; I'd probably say |t:|.

 

[pre]

We only care about the current server time anyway (or specifically, we only care about deltas between timestamps, which can use any reference point, and the current server time is as good as any). Not sure we would need to create a new protocol message with the exact same information, even if the original intended use case for |:| was different.

 

[Zarel]

Specifically, |:| means the current server time at the time the message is sent, not at the line.

So:

|:|5
|c:|3| Zarel|hello
|c:|4| Zarel|goodbye

means I said "hello" two seconds ago, and "goodbye" one second ago.

Which is of course incompatible with |:| marking the time of the line.

 

[pre]

Did the server and client side of this (aka the easier parts). Someone can take a stab at the replay viewer logic or just wait for me to finish this whenever I next get bored and decide to work through this forum’s suggestions.