OR  Zero-K Name:    Password:   

Movie codecs vs replays

2 posts, 148 views
Post comment
Filter:    Player:  

8 months ago
(edited 8 months ago)

It's probably not a project for zero-k but spring engine, but I'll post nevertheless. I summon JPrankgajop

I've always wondered whether it was considered to treat replays similar as in video codecs - with sync frames I and differential frames P, B.

Currently as I understand it, everything is recorded differential - all new input of commands and actions are recorded. This makes it impossible to quickly rewind the replay or go backwards in time. What I'm curious about is if it is feasible to periodically save whole game state you could jump to. Frequency of said saves is another matter to discuss - depends on their size, but I think that no more often than 60 sec and no more seldom than 300 sec.

I'm not aware what would be the cost of full gamestate: whether is it just all units and projectiles or whole map (for terrain deformations and decors). Maybe map changes could be saved as a compressed difference from original.

This whole thing could be done as a (possibly background) post processing after game is done, and not necessarily with every replay... Why I'm suggesting this: it's a mess when you want to find a single event in replay and you can't rewind it backwards or hop in time - if you miss or fail to make it right (like record for a gif or screenshot) you have to repeat whole time consuming and expensive process of replaying the game.

Don't read this as a request but as a question for insight what would be technical difficulties of such attempt.
+2 / -0

8 months ago
ILrankAdminhokomoko might actually be the most qualified to answer this in our community, as he was and believe still is a Spring engine developer.

I'll try my best though. In the video encoding whole state of a given frame is immediately visible and has no hidden parts. That's why you can take any frame and encode following ones incrementally/differentially.

Not the case with Spring/ZK. Some state is indeed capturable: unit, projectiles, wrecks, explosions, terrain, positions, rotations, etc. can be captured and theoretically restored. On the other hand engine has a huge blackbox called Lua Virtual Machine, which has its own state, coroutines, variables, arrays, etc. Almost everything in ZK uses Lua and amount of state is huge. Even if it's possible to capture, I don't think it's possible to inject it back without appropriate support from widgets and gadgets.

It's interesting to note, that current save/load code does exactly this: every gadget is responsible to save and load the state manually by themselves. We are unable to save 100% of ingame Lua state this way, but what we are able to save/load at the moment I think is good enough. Now imagine if we distribute a copy of the savegame to every player and ask them to load it, the game will start in a state, very close to what it was when the save was recorded. That said, load() requires engine reload, which is not convenient, and savegame distribution/coordinated load infrastructure is not there and wasn't even thought of. Moreover, if it's even possible to do, the effort is quite huge and the immediate profit is not clear.

All ^^^ IMO. Might be wrong in every sentence.
+1 / -0