|
A few months ago, there was a thread on rewinding replays. the conclusion of which being that it would be quite awesome, but it's technically impossible because of the way replays are saved. This is quite unfortunate because as much as rewinding replays is awesome, it is even more awesome when combined with play-from-replay. (in another thread, i talked about being able to pause a replay at any time, and entering the replay as a game with the other observers taking positions as the opponent) (also, the request-watch-replay option at the end of a game right next to when the surrender button)
But let's look back at the replay-rewind option, and we'll see that it's actually not technically impossible, nor is it technically difficult. certainly, in designing sc, far more complex things have been done. First, for an explanation of why it doesn't work in sc1.
replays files are simply a log of the starting condition of the map, and every single action that either players have performed throughout the game and at what time point. when a replay starts, the game loads the starting conditions of the map. as the replay progresses, instead of the game receiving "instructions" from the player as would be normal, the game receives "instructions" from the player actions that were saved in the replay. all else being equal (game version, etc), the game ends up playing out exactly the same. this is also why replays are sometimes corrupt with different versions.
the reason why replays don't work backwards for sc1 (but could be implemented for sc2) should be obvious by now, but can also be illustrated with an example. suppose that at some timepoint, the player creates an instruction that tells a dragoon to fire a bolt at a marine. the bolt flies through the air, collides with the marine, and then disappears, and kills the marine.
if the replay is going forwards, the game can interpret the player instruction to mean that he told the dragoon to shoot, which would cause it to fire a bolt, which would cause the bolt to fly through the air, which would cause it to collide with the marine, killing the marine and deleting the bolt.
But if this process was going backwards as in replay, the game INSTEAD would need to know at what time to create a marine corpse, and at what time to turn it into a marine at 10hp with a bolt flying from it. This reverse process cannot be extrapolated from the information saved in a standard sc1 replay which only saves the time the dragoon fires the bold, but doesn't save anything thereafter.
But this can easily - I repeat, EASILY be solved - and the previous thread's assertions that it is difficult is actually null. only a little bit of technical thinking reaches a solution that is easily implemented.
In a game of sc, there are 2 major things going on as far as instructions go. first, there are player actions (cause and effect), and second, there are unit productions (produce, and die).
replays going in the forward direction need to know when things start. ie, when players clicked something. when dark swarm went up. when a building is made. etc. from all the information on when things start, the game can extrapolate the rest of the game.
replays going in teh backward direction need to know when things die. ie, when dark swarm DISAPPEARS, when a bolt by a dragoon DISAPPEARS, when a marine DISAPPEARS and leaves a corpse, etc etc.
going back to the dragoon bolt example, a replay in sc1 just saves the time when the player tells the dragoon to attack. but in sc2, it can also save when the bolt disappears and when the marine disappears. then when rewinding the replay, at the time when the bolt disappears, sc2 will construct a bolt and a marine based on the saved data and the bolt will fly back to the dragoon.
this might sound technical to non-programmers, but being a C++ and Java programmer, this is actually very easy. programmers please comment, but in sc1 and sc2, there will already be sub-programs (functions for the coding savvy people) that manage when anything in the game dies. To make replays save deaths too, the programmers just need to go to the death function and add an extra line to tell it to save the time.
as for replay size, this will not make the replay much bigger actually. saving time points and things is much like saving things in a text file. each instruction is just a few digits and even an hour long game will just have a few pages of time points which isn't that big if you've ever typed a few pages of digits into a textfile and checked the size. the biggest part of the replay is in saving the map state at the beginning of the game.
previously suggested way of creating replay-rewind which was the save timepoints at different points in the game doesn't work because as mentioned in the paragraph above, timepoints that require all map data to be saved is huge.
hope for good discussion and hopefully everyone agrees with me. hopefully we can make blizzard do this.
imagine: replay-rewind, play-from-replay, and request-replay all in sc2. it would be so awesome.
i hope you'll at least agree that with all the benefits of replay-rewind, it at least deserves a more technical second look.
|
for object creation/deletion it's correct,
but what about unit positions/movements/resource gatherings?
there are things, that should really be very hard to implements - imagine rewinding drone-drilling - that should be hard as fuck.
one thing that would be possible though, is create check-points in the game when nothing fancy is taking place, where everything essential is recorded. then rewinding would just jump through to these points.
|
On March 31 2009 16:09 araav wrote:
for object creation/deletion it's correct,
but what about unit positions/movements/resource gatherings?
there are things, that should really be very hard to implements - imagine rewinding drone-drilling - that should be hard as fuck.
one thing that would be possible though, is create check-points in the game when nothing fancy is taking place, where everything essential is recorded. then rewinding would just jump through to these points.
there wont be drone drilling in sc2
|
On March 31 2009 16:09 araav wrote:
one thing that would be possible though, is create check-points in the game when nothing fancy is taking place, where everything essential is recorded. then rewinding would just jump through to these points.
CS's "viewdemo" does this. Probably wouldn't be too hard to create it as a plugin for SC.
|
It's not that simple, pathing algorithms are not reversable, since they depend on earlier events, unit postions, the orders given, etc. Knowing that unit x died at position y at time z does not tell you how it got there in the first place, and in order to know that you'll need:
1. the whole gamestate saved very often, which means much bigger filesize and additional processing power required(consider that saving the game in BW takes quite more time than the 1/24 of the second gamestate it saves, although I'm sure a faster algorithm could be created) or...
2. the game practically fast forwarding the whole replay again in order to be able to follow the chain of events from the start, which is almost the same as playing it again by yourself.
The solution is of course saving the gamestate from time to time, while you're watching the replay.
|
Bill307
Canada9103 Posts
On March 31 2009 15:48 Polyphasic wrote:
But let's look back at the replay-rewind option, and we'll see that it's actually not technically impossible, nor is it technically difficult.
...
But this can easily - I repeat, EASILY be solved - and the previous thread's assertions that it is difficult is actually null. only a little bit of technical thinking reaches a solution that is easily implemented.
...
this might sound technical to non-programmers, but being a C++ and Java programmer, this is actually very easy.
LOL
LOL
LOL
Do you have ANY idea how hard your idea is?
Granted I don't know what StarCraft 2's game engine really looks like, but I can take a pretty good guess.
StarCraft 2's engine is programmed so that time elapses in only one direction: forwards.
In order to play a replay backwards, you would basically have to rewrite the ENTIRE engine all over again.
Even something as simple as a dragoon's projectile homing-in on a target: ask yourself how the heck you would determine its trajectory in reverse, keeping in mind both the dragoon and its target may have been moving while the projectile was travelling. Off the top of my head, I haven't got a clue. And when you do figure it out, you'll probably find that it requires completely different code from the function used to home-in on a target.
That's just one small example of how pretty much the ENTIRE game would have to be redone.
Furthermore, since you're writing so much new code to handle playing events in reverse, you also have to TEST this code. Now normal replays don't need to be tested very much because they run using (essentially) the same engine as an actual game, so you know 95% of the code they're running works because you've already tested it during actual games. This isn't true for your new reverse-engine.
My gosh, it amuses me how little so many "programmers" know about actual game programming. (A certain post in the "nuke dot" topic comes to mind...) Even I don't know that much. Still, it's a basic rule of software development that any change you want to make that you didn't anticipate beforehand will be a pain in the ass to implement.
So at this point in SC2's life cycle, pretty much ANY change to the game engine will be a nightmare, no matter how "easy" it may seem.
But this is all beside the point in this topic, because the whole idea of playing replays in reverse, for a game as intricate as StarCraft, is a ludicrous suggestion.
|
On March 31 2009 17:02 Bill307 wrote:
My gosh, it amuses me how little so many "programmers" know about actual game programming.
That's probably, because web design deals with pretty simple applications.
|
Polyphasic, did you even really read the last thread about replay rewinding? I'm 99% sure we came up with like 3 different solutions to the issue (one being like araav suggested, another being playing back the replay really fast in the background with no graphical output up until the point the user wanted it rewound to, etc.). Your solution is pretty much impossible though, since you're neglecting things like HP, exact position including the way the unit is turned, etc. To put it in perspective, each unit in SC1 (their attributes at the current time, that is) takes up around 336 bytes of memory. If we assume that SC2 units take up more memory than that (which is certainly a fair assumption), then you can easily see how much data could be tacked onto replays even if we're only storing things about units when they're destroyed. And to properly handle things, we'd also have to store things about units when they're damaged, since otherwise the HP would not update properly.
To put it quite simply, rewinding the game directly in a replay file is a technical problem that *cannot* be overcome. We can work around it though, in ways that I think people would find just as useful (and I think araav's suggestion is really the best one in that regard).
On March 31 2009 16:17 SonuvBob wrote:Show nested quote +On March 31 2009 16:09 araav wrote:
one thing that would be possible though, is create check-points in the game when nothing fancy is taking place, where everything essential is recorded. then rewinding would just jump through to these points. CS's "viewdemo" does this. Probably wouldn't be too hard to create it as a plugin for SC.
Man I wish I understood SC's replay format better... 
|
Logging player actions and feeding them to the game to replay them is entirely different to recording game events and playing them back again. In order to view those you'd have to record pretty much everything all the time. Saving the whole gamestate in a very small interval would make for lots and lots - I repeat, LOTS and LOTS - of memory consumption and don't even think about saving that to a replay.
Even with a bigger interval you'd have what araav already suggested. Some kind of checkpoints you'd be able to jump to but no real backwards play functionality.
I guess this would work just as fine even with a pretty big interval because replaying only the last x minutes is way less annoying than replaying the whole thing in case you missed something.
Also, why would you even consider saving it to the replay file?
In order to rewind you'd have to have watched past the point you'd want to rewind to anyway. Just keep those things in memory as the replay progresses.
|
Bill307
Canada9103 Posts
Oh yeah, and let's not forget how the game would also have to save the ending times of every single animation in the game.
|
On March 31 2009 17:08 tec27 wrote:Show nested quote +On March 31 2009 16:17 SonuvBob wrote:On March 31 2009 16:09 araav wrote:
one thing that would be possible though, is create check-points in the game when nothing fancy is taking place, where everything essential is recorded. then rewinding would just jump through to these points. CS's "viewdemo" does this. Probably wouldn't be too hard to create it as a plugin for SC. Man I wish I understood SC's replay format better...
It's pretty well documented, but is that even needed for this? What viewdemo does is preload the entire thing before you watch, making checkpoints every x seconds.
|
how to rewind such things as random damage?
I don't know if it will be in sc2, but in sc there are lots of situations where the amount of damage is not exact and could be random (e.g. firing from the ground to the uphill).
|
No time right now to read the whole thread, but my solution would be this:
Let the client make full state savepoints every, say, 30 seconds dynamically while watching. This way, the game state does not need to come with the replay file, but is calculated only temporarily in the client's memory. To rewind, go back to the nearest checkpoint before the desired point in time, then fast forward from there (without the graphical representation of fast-forwarding to save computation time!).
To tune this, a tradeoff must be made between frequency of making full savepoints often (costs memory) or seldom (costs more time to fast-forward).
|
Imagine trying to code reverse pathing algorithms, I mean imagine if this was for starcraft, how in hell would you code for dragoons to get stuck on everything in reverse? And things still get stuck in sc2, even if not as often, and every time the pathing algorithm fails it is impossible to do it in any easy way in reverse.
As such you need to save the position of every unit all the time or that would happen, which mean that you are basically saving a whole video again.
|
There is another possibility for replay rewinding, downside being lots of temporary disk space, possibly several GB/min for hi-res. Each frame that should be rendered on the screen by the engine, is rendered into video file on disk (maybe with some sort of loseless compression) and than played back from there. After that, it is trivial to rewind/FF at any point.
|
Dunno why, but this made me remember a troll on the war3 beta forums.
"Make the farsight ability see 2/3/4 minutes in the future at levels 1/2/3."
|
Not sure, but wouldn't it be easiest to just let the watcher save specific points in a replay to be able to rewind to that point?
Since replays are essentially nothing but games Comp vs. Comp with saved orders, you should be able to just save the game at any point and reload later. Let's say you have hotkeys for save and load without confirmation dialogue, you could easily hit "Save" before a huge battle / Simulataneous Actions and after watching you could hit "Load" and it would jump back.
|
Sydney2287 Posts
On March 31 2009 16:16 Polyphasic wrote:Show nested quote +On March 31 2009 16:09 araav wrote:
for object creation/deletion it's correct,
but what about unit positions/movements/resource gatherings?
there are things, that should really be very hard to implements - imagine rewinding drone-drilling - that should be hard as fuck.
one thing that would be possible though, is create check-points in the game when nothing fancy is taking place, where everything essential is recorded. then rewinding would just jump through to these points. there wont be drone drilling in sc2
Maybe not drone drilling specifically, but who knows what else there could be.
|
If there was a progress bar, you could theoretically jump ahead (as fast as your computer can go, without gfx output,) and save states and such. Your computer would have to, of course, re-calculate everything to go back in time, but once a state is saved partway through, couldn't it simply calculate to the new point from the first point? Saving time and all? This seems viable to me, though it might take up a lot of memory... Though I really don't know how viable it is on the technical side, as my knowledge is limited.
|
United States4991 Posts
On March 31 2009 17:08 tec27 wrote:Show nested quote +On March 31 2009 16:17 SonuvBob wrote:On March 31 2009 16:09 araav wrote:
one thing that would be possible though, is create check-points in the game when nothing fancy is taking place, where everything essential is recorded. then rewinding would just jump through to these points. CS's "viewdemo" does this. Probably wouldn't be too hard to create it as a plugin for SC. Man I wish I understood SC's replay format better...
.rep itself is pretty well understood (except, so far as I know, the algorithm used for calculating the checksum). What you really need is to be able to read information about game state and write an entirely new game state on command.
Writing something to process the replays at accelerated speed and then store the checkpoints seems exponentially harder, as you'd be rewriting the SC engine yourself from scratch. (unless it's possible to hack it so that you can use speeds even faster than x16, but not sure how feasible that is!)
|
|
|
|
|
|
EPT
