Loading...
  OR  Zero-K Name:    Password:   

Why is this not possible? Devs pls this would be a quality of life upgrade to replays

18 posts, 869 views
Post comment
Filter:    Player:  
sort
6 months ago
In a replay, you cannot go backwards, only forwards. Is there a way to fix this?
+5 / -0
Within Spring a replay is played as a stream of actions, as calculate within an engine. The state of the game, where units are, what actions are ongoing etc., is not stored. Only the starting state (also indirectly, as it is calculated). To have this, 'key frames' need to be included, where the game-state is fully known. You could call them 'save-points', like a save, but lightweight.

To create these frames you need to serialize the entire state, this can cause memory/CPU spikes and freezes.

To have a more fluent user experience the game and its engine-instance should not fully reset, just the state.

Point is that it hasn't been made.
+7 / -0

6 months ago
I don`t fully understand this tbh. What I do not get is the following:
So, a unit, lets say a flea sits at a specific point at a specific time of the match. The description now is that the game does not know fron where that flea got to that place. But now, if you go back a command, shouldnt there be only one possible starting location? (Sorry, I am totally and utterly unversed at math, but I think what I mean is: Are movement commands not even stored as vectors?)
+0 / -0


6 months ago
I think the best way to understand replays is to know precisely what they store. A replay stores all the things that players told their units to do. So when you select a Flea and right click, that move order is saved in the replay.

You can't know where a Flea is after being given a move order, unless you know where the Flea started and the positions of everything it might hit along the way. Keep in mind that there isn't a unique position and orientation associated with a Flea that has finished a move order, and move orders can even be interrupted.

If we restrict ourselves to move orders, then all Fleas are in one of two states:
  • Has been given a move order in the past.
  • Has never been given any order.
The position of Fleas that have never been given an order depends on orders given to the factory that created them, nearby constructors, and the whole economy. So to figure out where a Flea is, you need to work backwards along all of its orders, and everything that could have affected how it carried out those orders. At which point you're just running the whole game forwards.
+3 / -0

6 months ago
Another part of this which IMO contributes to it being incredibly elegant overall is that the replay information is also essentially the same stuff that different players need to send to each other. Since every copy of the game knows the rules, and everyone agrees on the order of "random" numbers, you don't need to say a word about the exact paths of each missile or submunition or how the ground deforms, or the radius a plane turns in frame by frame, or whatever. Its wonderfully minimalistic.

A shame about not making checkpoints, theoretically possible as noted above, but not without cost.
+4 / -0

6 months ago
It's counter-intuitive how difficult this is, I'm sure of it. How so? I watched Valve completely eat sh*t when they tried to put in dota. We're not talkin' normal absentee valve either, this was a crunch time, pushing huge QOL updates left and right about 5-6 years ago Valve, and they got completely mopped by this task. First it crashed the client to desktop, then it hung the client, then it got removed and sat in derelict for years. I don't know if it even works now, i don't expect it to.
It appears the "recording" needs to be fully offloaded into a separate recreation, so that it can be interactable on the spectator plane in this way. I think about a memory write header going in reverse and my brain explodes... it would have to be mimicry, video disguised as gameplay... pure fucking witchery.
+1 / -0
To add to what skuggmodzer0 said, this also is what allows the servers to be essentially relay stations. Clients send in a checksum of a frame to ensure they are synchronized in the simulation; majority decides what is the correct check-sum, other value having players are 'desynched'.

The load-save functionality already allows for full serialization and de-serialization of the state.

You can save during a replay and load it, having that state.

That only contains the already buffered actions of the replay(-reader). And the gameframe is off.

Either there should be a reference to the replay, including a pointer to the appropriate game-frame, which is then loaded in; or you'd need to buffer the entirety of future actions and keep that within the save-file.
+2 / -0

6 months ago
Now that I think about it, the windback doesn't have to be too complicated. You can make timestamps every 1 minute, every 5 minutes, etc, and only make them DURING replays so that they don't take up storage space. But I'm an amateur programmer, so take my words with a grain of salt.
+0 / -0
6 months ago
checkpoints would be nice, definitely
+0 / -0

6 months ago
Adding replay checkpoints to engine would be good and I think it's "just" a matter of extending save/load to handle 100% of the synced game state.
+3 / -0


6 months ago
Making them as the replay is being run is a neat idea, then the replay file sizes are kept small, and only those watching replays with the setting enabled are affected. Might hurt ram though. Also, I don't think the current serialised saves have any guarantee that they sync.
+1 / -0
6 months ago
anyone knows what starcraft II does for their replays? They can backwards
+0 / -0


6 months ago
Starcraft 2 built their engine themselves and specced it into it.
+0 / -0


6 months ago
Starcraft II seems to have the system proposed here. Basically, commands and checkpoints. This is just from my recollection of watching replay analyses ages ago. It looked like the the system was loading the game at some point in the recent past, then simulating forwards.

The game world of Starcraft is a lot simpler than in Zero-K, where all the angles of the limbs of robots technically matter, because they might try to shoot a projectile out of some of them. Zero-K is also simulated at 34% higher fidelity (30 Hz vs 22.4 Hz). This makes Starcraft checkpoints smaller, and makes rapidly simulating between them faster. But PCs can be quite fast these days, so it isn't like we couldn't have the same system. Especially, and idk whether Starcraft does this, if the checkpoints were post-processed after the live game, so lag spikes were not an issue. I think my PC could process a 20 minute 1v1 in only a few minutes.
+4 / -0

6 months ago
Just the fact that the simulation is run at x5 to whatever is the max speed, and it's still ok, tells enough. Should be possible without much delay.

The total size of a save, as it contains everything including projectiles, lua noise, is bigger than the replay itself - at least for small 1v1s.
+0 / -0
i was just wondering im not asking for it but can a super fast replay mode that does not render anything (no animations) while holding a key be made? for potato pc's that struggle with 5x catchup speed

because i noticed that if i zoom into the ground while catching up i get a better catchup speed vs zoomed to show all animations
+4 / -0
That would be good, but it is something the engine would want to do for the best effect. I guess nobody has requested such a thing recently.
+3 / -0
5 months ago
quote:
You can make timestamps every 1 minute, every 5 minutes, etc, and only make them DURING replays so that they don't take up storage space


Cliver5 FWIW the term for this is "key frame" which MSPR mentioned in the first reply to OP. Keyframes more generally are a concept from animation (when artists use interpolation/tweening) and video encoding (most video we watch has an I-frame at least once every few seconds).

Or "checkpoint" since if the idea is to do these only once every few minutes then it's kinda odd to think of them as keyframes.

But to get back to the point: it's totally possible, but also a surprisingly bigass task for such a "simple" feature as others explained. Not that I've looked into Spring dev myself (apart from once in an aeon past) but thinking of it just brings to mind so many things that can go slightly-but-replay-breakingly wrong until all the details are hammered out. Still... possible.

So I am a little surprised that this sort of thing was never implemented in Spring over the last ten years. It's such a high-quality FOSS game engine and its community have done amazing work, but I guess it somehow never topped the list of priorities. Because players lurv their replays, so it would clearly provide a lot of value.
+1 / -0