|
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!)
|
Sweden33719 Posts
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.
This is what they've said their doing tho, isn't it? At Blizzcon they said they were experimenting with checkpoints.
|
On March 31 2009 20:50 FrozenArbiter 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. This is what they've said their doing tho, isn't it? At Blizzcon they said they were experimenting with checkpoints.
hehe, then why is this guy worried so much? If Blizzard experiments for this feature, then i am sure they will come up with a good solution.
|
If I made a checkpoint system I would just fast forward the game really fast during the loading of the map until I reached the checkpoint that was wanted. That seems to be the easiest solution, no need for saving anything other than what is in a normal replay file.
|
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.
But how would the replay know when there is nothing important? It's all subjective, my friend
|
What if, as the replay was played it wrote the locations/status of everything to your ram, so you could feasibly rewind, but you'd have to have watched it first (or at least the actions would have to have been carried out, whether you've seen them or not). This way doesn't increase the actual size of the replay that you download, as the rewind gamestate data is temporarily created in your ram each time you watch the replay. With today's ram sizes (4 gig of ram is probably pretty standard these days right?) and read/write speeds this shouldn't be too much of a problem yeah?
This could feasibly be combined with checkpoints, but only ones that rely on a system of the game actions up to that point being played quickly without graphical output (something that won't increase replay size). If it relied on saving an actual game state every x seconds and going from there it would not work as the actions and state of every part of the game is not being played through to be cached (is that the right word?)
Disclaimer:
I dunno if this is going to make any sense whatsoever, as I have no knowledge of programming (except very limited HTML) or if this even has anything to do with programming. Feedback plz
|
On March 31 2009 19:48 HnR)Insane wrote:Show nested quote +On March 31 2009 17:08 tec27 wrote: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!)
Actually, now that I think about it, you could probably abuse the save game functionality to save out game states while watching. And you could very likely run SC at speeds faster than x16, as all those update speeds are stored in memory and you could just change their timing values. I guess the major issue there is that game saving may take some time, and that would definitely slow down the process.
|
On March 31 2009 20:50 FrozenArbiter 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. This is what they've said their doing tho, isn't it? At Blizzcon they said they were experimenting with checkpoints.
Indeed, they did:
+ Show Spoiler +A new feature called Bookmarks will be implemented into the replay functionality of StarCraft 2. There will be both standard and user customizable bookmark functionalities.
For example, there may be automatic bookmarks set at every 5 or 10 minute mark. This would allow the user to quick jump throughout the replay without have to spend time fast forwarding. Very similiar to the difference between DVD and Tapes.
With user customizable bookmarks, the replay author could set bookmarks at particular battles and other points of interest.
Source: StarCraftZine.com
|
On March 31 2009 22:57 nataziel wrote:
What if, as the replay was played it wrote the locations/status of everything to your ram, so you could feasibly rewind, but you'd have to have watched it first (or at least the actions would have to have been carried out, whether you've seen them or not). This way doesn't increase the actual size of the replay that you download, as the rewind gamestate data is temporarily created in your ram each time you watch the replay. With today's ram sizes (4 gig of ram is probably pretty standard these days right?) and read/write speeds this shouldn't be too much of a problem yeah?
This could feasibly be combined with checkpoints, but only ones that rely on a system of the game actions up to that point being played quickly without graphical output (something that won't increase replay size). If it relied on saving an actual game state every x seconds and going from there it would not work as the actions and state of every part of the game is not being played through to be cached (is that the right word?)
Disclaimer:
I dunno if this is going to make any sense whatsoever, as I have no knowledge of programming (except very limited HTML) or if this even has anything to do with programming. Feedback plz
I have always wondered if this is possible. Can someone with programming experience comment on its feasibility. From the small .rep file you would then create a much larger amount of information that would then allow you to go backwards, having complete game states at many intervals along the way.
|
On April 01 2009 01:50 Ingenol wrote:Show nested quote +On March 31 2009 22:57 nataziel wrote:
What if, as the replay was played it wrote the locations/status of everything to your ram, so you could feasibly rewind, but you'd have to have watched it first (or at least the actions would have to have been carried out, whether you've seen them or not). This way doesn't increase the actual size of the replay that you download, as the rewind gamestate data is temporarily created in your ram each time you watch the replay. With today's ram sizes (4 gig of ram is probably pretty standard these days right?) and read/write speeds this shouldn't be too much of a problem yeah?
This could feasibly be combined with checkpoints, but only ones that rely on a system of the game actions up to that point being played quickly without graphical output (something that won't increase replay size). If it relied on saving an actual game state every x seconds and going from there it would not work as the actions and state of every part of the game is not being played through to be cached (is that the right word?)
Disclaimer:
I dunno if this is going to make any sense whatsoever, as I have no knowledge of programming (except very limited HTML) or if this even has anything to do with programming. Feedback plz I have always wondered if this is possible. Can someone with programming experience comment on its feasibility. From the small .rep file you would then create a much larger amount of information that would then allow you to go backwards, having complete game states at many intervals along the way.
You'd have to do it at a set (and fairly large) interval, or it'd be far, far too much data. As I said in a previous post, in SC1, each unit takes 336 bytes to store. So at 200/200 supply for 2 players (not an exact measurement, obviously, but I think that accounts for things like keeping track of minerals, buildings, and critters), thats 400 units * 336 bytes = ~130 KB per state. If we stored states per frame, that'd be about 3MB per second of data, which is obviously far too high. If we knock the state time up to every minute, then its around 2.5MB per 20 minute game, which is definitely more acceptable. SC2 probably has more data per unit/building/whatever though, so thats an important consideration, but storing the complete game state every minute is certainly reasonable (assuming its done dynamically as you watch the replay).
|
Thanks tec, now I see that rewinding with checkpoints is possible and the odds of it being implemented (sooner or later) are very high.
|
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.
This is the method I favor as well
On March 31 2009 22:15 il0seonpurpose 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. But how would the replay know when there is nothing important? It's all subjective, my friend
How do you think you resume a saved game? If the position and status of each object are saved, then you can just follow the same actions and end up with the same result. As long as the dragoon is always in the same place, the marine always has the same result, telling the dragoon to attack the marine will always have the same result.
|
On March 31 2009 23:17 tec27 wrote:Show nested quote +On March 31 2009 19:48 HnR)Insane wrote:On March 31 2009 17:08 tec27 wrote: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!) Actually, now that I think about it, you could probably abuse the save game functionality to save out game states while watching. And you could very likely run SC at speeds faster than x16, as all those update speeds are stored in memory and you could just change their timing values. I guess the major issue there is that game saving may take some time, and that would definitely slow down the process.
do it do it do it do it do it do it do it do it! 
|
Here is an idea I have.
When a replay is saved there is 2 things saved, 1 is the full replay that we are used to.. another is just a video of the game (the live action) not detailed but just the actual recording of the game. These 2 files will be associated together. Both the full replay (of course) and the video of the game are time synced.
So lets say we load a replay and start watching. Of course it will be using the classic replay. You fast forward, click around on units, have a FULL detailed replay that we are used to. So lets say we click ahead to the 10 minute mark. Now we decide that we want to rewind a little bit. By hitting rewind the replay switches to "video only" mode where it is literally just the game played backwards. You cannot see details by clicking on units while rewinding, but the actual VIDEO of the game is rewinding. And of course all the time is synced. When you hit PLAY the game reverts to the full regular detailed replay.
In short, when rewinding the game uses a less detailed "video only" version of the game which is literally the game video in reverse. When you start going forward again the actual replay returns with full detail clickability.
Just some random thoughts, SC would have to have a video mode for games and a video player etc.
|
You wouldn't be able to choose your viewpoint in that case. Rendering, encoding and saving the whole map in your screen resolution in real time is just impossible.
|
On April 01 2009 04:42 ven_ wrote:
You wouldn't be able to choose your viewpoint in that case. Rendering, encoding and saving the whole map in your screen resolution in real time is just impossible.
There could be some clever tricks, considering we don't actually want to watch the video in rewind but simply have the option to rewind our game. A very low quality "video" of the game that is only applied to kick in when Rewind is engaged. Overall it does seem improbable though, perhaps with some iterations and some ingenuity this could be applied.
|
You'd still have to actually rewind the replay in order to play from a previous point in time. Having a video played backwards won't help with that.
|
On April 01 2009 03:52 Pufftrees wrote:
Here is an idea I have.
When a replay is saved there is 2 things saved, 1 is the full replay that we are used to.. another is just a video of the game (the live action) not detailed but just the actual recording of the game. These 2 files will be associated together. Both the full replay (of course) and the video of the game are time synced.
So lets say we load a replay and start watching. Of course it will be using the classic replay. You fast forward, click around on units, have a FULL detailed replay that we are used to. So lets say we click ahead to the 10 minute mark. Now we decide that we want to rewind a little bit. By hitting rewind the replay switches to "video only" mode where it is literally just the game played backwards. You cannot see details by clicking on units while rewinding, but the actual VIDEO of the game is rewinding. And of course all the time is synced. When you hit PLAY the game reverts to the full regular detailed replay.
In short, when rewinding the game uses a less detailed "video only" version of the game which is literally the game video in reverse. When you start going forward again the actual replay returns with full detail clickability.
Just some random thoughts, SC would have to have a video mode for games and a video player etc.
What's that good for? Noone is interested in seeing a game backwards. It's only to jump back and see an interesting battle twice or something. Forward of course.
|
On April 01 2009 04:51 Scorch wrote:Show nested quote +On April 01 2009 03:52 Pufftrees wrote:
Here is an idea I have.
When a replay is saved there is 2 things saved, 1 is the full replay that we are used to.. another is just a video of the game (the live action) not detailed but just the actual recording of the game. These 2 files will be associated together. Both the full replay (of course) and the video of the game are time synced.
So lets say we load a replay and start watching. Of course it will be using the classic replay. You fast forward, click around on units, have a FULL detailed replay that we are used to. So lets say we click ahead to the 10 minute mark. Now we decide that we want to rewind a little bit. By hitting rewind the replay switches to "video only" mode where it is literally just the game played backwards. You cannot see details by clicking on units while rewinding, but the actual VIDEO of the game is rewinding. And of course all the time is synced. When you hit PLAY the game reverts to the full regular detailed replay.
In short, when rewinding the game uses a less detailed "video only" version of the game which is literally the game video in reverse. When you start going forward again the actual replay returns with full detail clickability.
Just some random thoughts, SC would have to have a video mode for games and a video player etc. What's that good for? Noone is interested in seeing a game backwards. It's only to jump back and see an interesting battle twice or something. Forward of course.
The idea is that this allows us to rewind games without actually encountering the technical issues with having a replay running in rewind. Then we can rewind replays without going to a particular time set. After a large battle in a replay, simply rewind until the battle starts then continue. Nothing ground breaking just throwing out some ideas.
|
Russian Federation4235 Posts
Hoohoho, no.
As a Java, C++ programmer you should certainly know the concept of hashing which is behind every data integrity check, associative array lookup and many more things. That, itself, is a small part of a larger concept - there are functions that are irreversibly introducing a loss of data, in which the input is not possible to reconstruct from output.
In a hash function, you can not theoretically reconstruct the input even if you know every nook and cranny of the algorithm and the output (trust me, I've tried). It's irreversible, because it implies information loss. While hashing itself doesn't have any use in gamestate chaging, many other irreversible operations do. Examples?
1) Pathfinding. Provided it doesn't calculate the whole path from A to B but updates it as the unit goes along an approximated one, the corresponding path from B to A will be different. Guess what? Pathing algorithms have non-linear computational difficulty, so this will surface up no matter how good the player's computer is. It is bound to happen. Desynch.
2) Physics. StarCraft II will not use animations for explosions and debris, it will use physics, meaning that a piece of scrap metal will behave like a physical object bouncing at landscape impurities. Will you be able to reconstruct it's path back to the origin? Hell no. Desynch or disable animations.
3) Many other fields where information loss happens which could theoretically be made two-way compartible, but that would require tons of work. Will not happen.
I'm sorry, but I doubt your programming credibility now.
|
Russian Federation4235 Posts
When a replay is saved there is 2 things saved, 1 is the full replay that we are used to.. another is just a video of the game (the live action) not detailed but just the actual recording of the game. These 2 files will be associated together. Both the full replay (of course) and the video of the game are time synced.
Think! THINK! Whose viewpoint it's being saved as? A video is just a video, you cannot expect to put your mouse to a screen's edge and scroll, it will stay within someone's field of view. Well, and FPVOD is possible that way, but to make something other you will need a spectator. Unless, of course, you have 100 Terabytes of free space and a mainframe so that you will record a video of the whole map.
|
It's a little bit off topic but how does a replay work with random things ? Like, if you have 30% chance to hit against upperground units, how can a replay works everytime ? The random "seed" is in the replay ?
|
On April 01 2009 03:44 SonuvBob wrote:Show nested quote +On March 31 2009 23:17 tec27 wrote:On March 31 2009 19:48 HnR)Insane wrote:On March 31 2009 17:08 tec27 wrote: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!) Actually, now that I think about it, you could probably abuse the save game functionality to save out game states while watching. And you could very likely run SC at speeds faster than x16, as all those update speeds are stored in memory and you could just change their timing values. I guess the major issue there is that game saving may take some time, and that would definitely slow down the process. do it do it do it do it do it do it do it do it!
Maybe doable, the max speedup I can see getting (for caching the replay initially) is about 1.4 seconds per minute of gameplay (since each fastest frame is 42ms, and therefore the max we can speed the game up is to 1ms per frame). I guess thats reasonable, now I just need to figure out the optimal way to save game states
On April 01 2009 05:14 Nitro68 wrote:
It's a little bit off topic but how does a replay work with random things ? Like, if you have 30% chance to hit against upperground units, how can a replay works everytime ? The random "seed" is in the replay ?
Correct.
|
i know nothing about programming, all I do know is that your wrong, rewinding replays is not as easy as you say. If you understand how replays work, how starcraft works and have any logical thinking ability then it's pretty obvious your wrong..
|
Wait , when did Drone drilling get removed? Wtf ?
|
On April 01 2009 05:16 stk01001 wrote:
i know nothing about programming, all I do know is that your wrong, rewinding replays is not as easy as you say. If you understand how replays work, how starcraft works and have any logical thinking ability then it's pretty obvious your wrong..
A great post.
"I don't know if you're right or wrong, but I do know you're wrong and lack any logical thinking ability."
The concept of rewinding replays is simple, it's the technical aspect that makes it difficult. You seem like you're just trying to sound intelligent by flaming someone for being wrong, when you don't know how or why they're wrong. lol@TLstreetcred
|
i can rewind your replays for you...
just reopen the replay and ultra fast fwd! XD
I win!
|
You've tried to simplify an extremely complex problem. It would be much easier to implement a "go to time x:xx" which would solve the problem by simply presenting the user with a "loading" animation while the replay actually goes back to the start, and fast forwards quickly to that position, and then shows you from that point.
This, imo, is the solution. (I didn't read page 2 and 3, sorry if someone alrdy posted this)
|
|
|
The problem with playing back a movie of the game you've seen up to that point is not only would you have to save a high res version of the entire map, but you also couldn't interact with it. No selecting units, buildings, etc.
As for randomness, I'd bet that they seed a random based on game time, and perhaps the units id number. So basically it adds up (for example) the number of seconds played + the unique number of the unit that is firing, use that number to generate a random number which determines whether it hits a unit on hire ground. So during the game or during replay, the unit number and attack time will always match up causing the unit to either always miss or always hit, but the player would perceive it as random and be unable to predict such an outcome during a game.
As for what method will be used, they will probably use save checkpoints plus fast forwarding. The reason they'll do this is because they already had to write the save game code anyhow, so they might as well use it, and they already had to write the replay code that could go at any speed, so they'll slap those together in half a day, tweak the snapshot length until they have a happy medium between size and speed and get on with coding the rest of the game.
Of course it may turn out that fast forwarding is all they need, given that the game logic really isn't much more complex that it was in BW, unit pathing aside. So don't worry about it, it is hardly the worst engineering problem this team has had to deal with.
|
On March 31 2009 17:25 Bill307 wrote:
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.
But can you make it so that you are able to jump to a specific point in time of the replay ?
Lets suppose, and im a complete programming newb, that you are watching a replay and at 7:35 theres 2 battles going on.
Can you watch one battle in 1 place, then jump back to 7:35 (no reverse animatons nor rewind effect just starting it again and going at x60000 speed to that exact time) would it be possible ?
Because if some way of going back in the replay is doable at all, its all that counts, rewind effect for animations and shit are useless, unless you think the only cool thing about it is to grab the handle and see that shot flying in the air.
|
On April 01 2009 05:06 BluzMan wrote:
Hoohoho, no.
As a Java, C++ programmer you should certainly know the concept of hashing which is behind every data integrity check, associative array lookup and many more things. That, itself, is a small part of a larger concept - there are functions that are irreversibly introducing a loss of data, in which the input is not possible to reconstruct from output.
In a hash function, you can not theoretically reconstruct the input even if you know every nook and cranny of the algorithm and the output (trust me, I've tried). It's irreversible, because it implies information loss. While hashing itself doesn't have any use in gamestate chaging, many other irreversible operations do. Examples?
1) Pathfinding. Provided it doesn't calculate the whole path from A to B but updates it as the unit goes along an approximated one, the corresponding path from B to A will be different. Guess what? Pathing algorithms have non-linear computational difficulty, so this will surface up no matter how good the player's computer is. It is bound to happen. Desynch.
2) Physics. StarCraft II will not use animations for explosions and debris, it will use physics, meaning that a piece of scrap metal will behave like a physical object bouncing at landscape impurities. Will you be able to reconstruct it's path back to the origin? Hell no. Desynch or disable animations.
3) Many other fields where information loss happens which could theoretically be made two-way compartible, but that would require tons of work. Will not happen.
I'm sorry, but I doubt your programming credibility now.
+1
physics in particular... Since Havok is middleware i doubt they could 'reverse the physics'... And if they could, then you'd need to reprogram the engine to be able to work in reverse (i.e. negate all movement values including acceleration, velocity)... i suppose it doesn't help that it's 3d and your not working with sprites any more ether for reversing the animation...
|
Even if you could easily do this, I'd prefer current replay size > double size. It doesn't really make a difference considering how small it is, but I don't rewind my replays. I learn from my replays, and to learn I have to concentrate, which in turn means I understand whats going on and what has been done.
|
If it was that easy, R1ch would have already done it.
|
On April 01 2009 07:09 CharlieMurphy wrote:
Wait , when did Drone drilling get removed? Wtf ?
it didnt get removed, workers still stack and stuff, but the path finding and unit behavior is so clean now that they unstack and clear each other so fast that you dont get the same effect.
on the other hand they practically autosurround now so you can still hold off rushes with workers, easier than in sc1 actually.
|
The most simple way of including rewind for blizzard is just to make it possible to play the replay in comp's memory from the start to the point needed and resume it onscrean afterwards. Yes it will take awhile but no more than loading a saved game anyway. They can cut lots of corners (forget about scrapmetal falling down, it does not change the flow of the game so noone will really bother if in a resumed game the battlefield will be clear of blood and scrap) doing it so it will be much faster and less CPU demanding. You don't even need to save states of the replay while it is playing. Actually you do pretty much the same when you exit replay and reload it to the point you need, just the CPU will do this for you much faster with no need to draw graphics.
|
Russian Federation4235 Posts
Well, the man above is somewhat right.
Replay rewinding itself is possible (but to a limited extent and probably not online) if the game is making a shadow copy of every second's gamestate while the replay is being played. As soon as you finish the replay, the memory is freed. The player can set the size of the replay backwards cache depending on his system capabilities. Say I have 4 Gb Ram, and in SC II settings I set up the replay cache to 1000 Mb. I will be able to go back as deep as 300 seconds backwards from a given point, that's 5 minutes. That is possible, "true" backwards playing is definetely not.
|
I just don't want replays to take up a shitload of space like those Warcraft 3 ones.
|
You guys are really considering recording every unit's position/state/animframe/buffs/debuffs/whateverothervcariable every second (or maybe 60 times per second for a smooth 60fps rewind playback)? You have any idea how much memory that would be?
If you're going that far isn't it better to simply fraps it and play it on a video player?
Blizzard's idea already is to save it once every 3minute'ish so you can jump around (proly even adjustable to even less than that). That's good enough lol
|
i'd imagine it's possible, but that it would be profoundly difficult.
the main reason Braid hasn't been released on a computer is due to hardware issues. Though the graphics look cartoonish and low level, the game demands such an insane amount of memory due to having to record the game state for that awesome "rewind" function. Without a super tripped out computer, you'd be living in frown town.
That said, I'm still curious how much memory/processing power a rewind function would ACTUALLY demand (because I'm a mathematician and <3 complexity theory hahaha). MIT just came out with a 1000ghz processor. Now they just need to hop on 1000gb of ram hahaha.
|
On April 01 2009 18:53 meegrean wrote:
I just don't want replays to take up a shitload of space like those Warcraft 3 ones.
Hu??? The average 1v1 WC3 replay is 150KB. Most 4 - 6 player FFA games are less then 350KB...
|
On April 02 2009 02:13 Day[9] wrote:
i'd imagine it's possible, but that it would be profoundly difficult.
the main reason Braid hasn't been released on a computer is due to hardware issues. Though the graphics look cartoonish and low level, the game demands such an insane amount of memory due to having to record the game state for that awesome "rewind" function. Without a super tripped out computer, you'd be living in frown town.
That said, I'm still curious how much memory/processing power a rewind function would ACTUALLY demand (because I'm a mathematician and <3 complexity theory hahaha). MIT just came out with a 1000ghz processor. Now they just need to hop on 1000gb of ram hahaha.
Consoles aren't as powerfull as modern computers.
|
Sweden33719 Posts
On April 01 2009 18:53 meegrean wrote:
I just don't want replays to take up a shitload of space like those Warcraft 3 ones.
.. WC3 replays are the same size as BW replays. Latest game I played (a 2v2) was 69kb.
Yo DO need to have the map the game is played on tho, which is ANNOYING AS FUCK. I'd much rather have reps be 300-500 kb (come on, it's 2009) than having to have every fucking version, every new map..
|
On April 02 2009 04:21 FrozenArbiter wrote:Show nested quote +On April 01 2009 18:53 meegrean wrote:
I just don't want replays to take up a shitload of space like those Warcraft 3 ones. .. WC3 replays are the same size as BW replays. Latest game I played (a 2v2) was 69kb. Yo DO need to have the map the game is played on tho, which is ANNOYING AS FUCK. I'd much rather have reps be 300-500 kb (come on, it's 2009) than having to have every fucking version, every new map..
It's even better if players can choose to save a replay with or without map
|
On April 02 2009 04:21 FrozenArbiter wrote:Show nested quote +On April 01 2009 18:53 meegrean wrote:
I just don't want replays to take up a shitload of space like those Warcraft 3 ones. .. WC3 replays are the same size as BW replays. Latest game I played (a 2v2) was 69kb. Yo DO need to have the map the game is played on tho, which is ANNOYING AS FUCK. I'd much rather have reps be 300-500 kb (come on, it's 2009) than having to have every fucking version, every new map..
If I remembered correctly, Starcraft replys won't work if there are triggers in play. Warcraft 3 however has fixed that problem, and if all those replys included the map, it would be massive, because alot of custom maps are over 3 to 4 MB.
Might not be a problem today through as most people has lot bigger drives.
|
On April 02 2009 02:13 Day[9] wrote:
i'd imagine it's possible, but that it would be profoundly difficult.
the main reason Braid hasn't been released on a computer is due to hardware issues. Though the graphics look cartoonish and low level, the game demands such an insane amount of memory due to having to record the game state for that awesome "rewind" function. Without a super tripped out computer, you'd be living in frown town.
That said, I'm still curious how much memory/processing power a rewind function would ACTUALLY demand (because I'm a mathematician and <3 complexity theory hahaha). MIT just came out with a 1000ghz processor. Now they just need to hop on 1000gb of ram hahaha.
The main reason Braid hasn't been released for PC yet is because its developer fails at programming.
And doesn't the xbox 360 only have like 512mb of ram anyway?
On April 02 2009 04:43 hixhix wrote:Show nested quote +On April 02 2009 04:21 FrozenArbiter wrote:On April 01 2009 18:53 meegrean wrote:
I just don't want replays to take up a shitload of space like those Warcraft 3 ones. .. WC3 replays are the same size as BW replays. Latest game I played (a 2v2) was 69kb. Yo DO need to have the map the game is played on tho, which is ANNOYING AS FUCK. I'd much rather have reps be 300-500 kb (come on, it's 2009) than having to have every fucking version, every new map.. It's even better if players can choose to save a replay with or without map
Just include the map if it's not played on a standard map and if the size is reasonable. Some tourney maps in WC3 have insane file sizes because of ingame ads.
|
Bill307
Canada9103 Posts
On April 02 2009 05:09 furymonkey wrote:Show nested quote +On April 02 2009 04:21 FrozenArbiter wrote:On April 01 2009 18:53 meegrean wrote:
I just don't want replays to take up a shitload of space like those Warcraft 3 ones. .. WC3 replays are the same size as BW replays. Latest game I played (a 2v2) was 69kb. Yo DO need to have the map the game is played on tho, which is ANNOYING AS FUCK. I'd much rather have reps be 300-500 kb (come on, it's 2009) than having to have every fucking version, every new map.. If I remembered correctly, Starcraft replys won't work if there are triggers in play.
They can work just fine. E.g. Team Micro Melee replays work fine.
Afaik, the only things you can't use are the "Elapsed Time" trigger and the "Wait" action (which will break replays if you change their playback speed), but they are largely unnecessary, anyway.
|
Think it would be easier to just have a replay to avi converter type.
|
On April 02 2009 08:36 ocoini wrote:
Think it would be easier to just have a replay to avi converter type.
and which part of the map the screen focus on? :S
|
On April 01 2009 02:08 tec27 wrote:Show nested quote +On April 01 2009 01:50 Ingenol wrote:On March 31 2009 22:57 nataziel wrote:
What if, as the replay was played it wrote the locations/status of everything to your ram, so you could feasibly rewind, but you'd have to have watched it first (or at least the actions would have to have been carried out, whether you've seen them or not). This way doesn't increase the actual size of the replay that you download, as the rewind gamestate data is temporarily created in your ram each time you watch the replay. With today's ram sizes (4 gig of ram is probably pretty standard these days right?) and read/write speeds this shouldn't be too much of a problem yeah?
This could feasibly be combined with checkpoints, but only ones that rely on a system of the game actions up to that point being played quickly without graphical output (something that won't increase replay size). If it relied on saving an actual game state every x seconds and going from there it would not work as the actions and state of every part of the game is not being played through to be cached (is that the right word?)
Disclaimer:
I dunno if this is going to make any sense whatsoever, as I have no knowledge of programming (except very limited HTML) or if this even has anything to do with programming. Feedback plz I have always wondered if this is possible. Can someone with programming experience comment on its feasibility. From the small .rep file you would then create a much larger amount of information that would then allow you to go backwards, having complete game states at many intervals along the way. You'd have to do it at a set (and fairly large) interval, or it'd be far, far too much data. As I said in a previous post, in SC1, each unit takes 336 bytes to store. So at 200/200 supply for 2 players (not an exact measurement, obviously, but I think that accounts for things like keeping track of minerals, buildings, and critters), thats 400 units * 336 bytes = ~130 KB per state. If we stored states per frame, that'd be about 3MB per second of data, which is obviously far too high. If we knock the state time up to every minute, then its around 2.5MB per 20 minute game, which is definitely more acceptable. SC2 probably has more data per unit/building/whatever though, so thats an important consideration, but storing the complete game state every minute is certainly reasonable (assuming its done dynamically as you watch the replay).
NOTE: THIS DOES NOT INCREASE THE SIZE OF THE REPLAYS, SO DON'T BITCH TO ME ABOUT THAT, REPLAYS WILL BE THE SAME SIZE AS USUAL. (not directed at tec, but idiots who can't read)
Umm, there's something wrong with your maths dude. Say the game runs at a smooth 60fps, that's 130KB*60*60 = 468000KB = 468MB/Minute, which is definitely too much. BUT, if you save the state every second you get 130KB*60=7800KB=7.8MB/minute. If you said the average game was 20 minutes long, you get 7.8MB*20=156MB/game. You could definitely go bigger if you want to, every quarter second = 624MB/game.
Considering ram sizes these days runs up to 4GB+ there's no reason this isn't feasable. Note that this doesn't increase the actual size of the replay, as this data is created as the replay is played. The state is saved every second and held in the ram until you finish watching the replay, you don't get a very smooth rewind, but a functional rewind for sure. The only thing I could think of that would limit this is the time it takes to load the game states, and I don't really know how to fix that problem. This could be combined with the idea of checkpoints by playing the replay with no graphical output at x5million speed (slight exageration possible) and saving the states into the ram at the same time (which I admit would probably bottleneck the speed at which the replay could be played at)
Maybe you could elect to have rewind turned on or off when you start the replay, rewind on it works like I said, rewind off it works like a normal replay.
|
On April 02 2009 10:57 nataziel wrote:Show nested quote +On April 01 2009 02:08 tec27 wrote:On April 01 2009 01:50 Ingenol wrote:On March 31 2009 22:57 nataziel wrote:
What if, as the replay was played it wrote the locations/status of everything to your ram, so you could feasibly rewind, but you'd have to have watched it first (or at least the actions would have to have been carried out, whether you've seen them or not). This way doesn't increase the actual size of the replay that you download, as the rewind gamestate data is temporarily created in your ram each time you watch the replay. With today's ram sizes (4 gig of ram is probably pretty standard these days right?) and read/write speeds this shouldn't be too much of a problem yeah?
This could feasibly be combined with checkpoints, but only ones that rely on a system of the game actions up to that point being played quickly without graphical output (something that won't increase replay size). If it relied on saving an actual game state every x seconds and going from there it would not work as the actions and state of every part of the game is not being played through to be cached (is that the right word?)
Disclaimer:
I dunno if this is going to make any sense whatsoever, as I have no knowledge of programming (except very limited HTML) or if this even has anything to do with programming. Feedback plz I have always wondered if this is possible. Can someone with programming experience comment on its feasibility. From the small .rep file you would then create a much larger amount of information that would then allow you to go backwards, having complete game states at many intervals along the way. You'd have to do it at a set (and fairly large) interval, or it'd be far, far too much data. As I said in a previous post, in SC1, each unit takes 336 bytes to store. So at 200/200 supply for 2 players (not an exact measurement, obviously, but I think that accounts for things like keeping track of minerals, buildings, and critters), thats 400 units * 336 bytes = ~130 KB per state. If we stored states per frame, that'd be about 3MB per second of data, which is obviously far too high. If we knock the state time up to every minute, then its around 2.5MB per 20 minute game, which is definitely more acceptable. SC2 probably has more data per unit/building/whatever though, so thats an important consideration, but storing the complete game state every minute is certainly reasonable (assuming its done dynamically as you watch the replay). NOTE: THIS DOES NOT INCREASE THE SIZE OF THE REPLAYS, SO DON'T BITCH TO ME ABOUT THAT, REPLAYS WILL BE THE SAME SIZE AS USUAL. (not directed at tec, but idiots who can't read) Umm, there's something wrong with your maths dude. Say the game runs at a smooth 60fps, that's 130KB*60*60 = 468000KB = 468MB/Minute, which is definitely too much. BUT, if you save the state every second you get 130KB*60=7800KB=7.8MB/minute. If you said the average game was 20 minutes long, you get 7.8MB*20=156MB/game. You could definitely go bigger if you want to, every quarter second = 624MB/game. Considering ram sizes these days runs up to 4GB+ there's no reason this isn't feasable. Note that this doesn't increase the actual size of the replay, as this data is created as the replay is played. The state is saved every second and held in the ram until you finish watching the replay, you don't get a very smooth rewind, but a functional rewind for sure. The only thing I could think of that would limit this is the time it takes to load the game states, and I don't really know how to fix that problem. This could be combined with the idea of checkpoints by playing the replay with no graphical output at x5million speed (slight exageration possible) and saving the states into the ram at the same time (which I admit would probably bottleneck the speed at which the replay could be played at) Maybe you could elect to have rewind turned on or off when you start the replay, rewind on it works like I said, rewind off it works like a normal replay.
There's nothing wrong with my math. SC1 takes 42ms per game frame on fastest. Keep in mind that the game frame is not necessarily the same as the drawn frame, but rather the time between updates of each unit/item. I never said you couldn't save states at a faster rate, I merely suggested an interval that I thought would be reasonable (honestly, the smallest interval you'd probably ever need is 15 seconds, why exactly would you need finer precision?). You failed to consider a couple things in your suggestions, though: First, the game is probably already taking a decent portion of the ram for the stuff it needs to do, we don't want to be taking out 150-600 megs for something thats going to be used like 5 times per replay. Second, not everyone who plays the game will have 4GB of ram, or even 2GB, and we can't assume they will. Third, we need this method to work for not only 20 minute games, but 3 hour games as well, and also for more than just 2 players. My estimations are undoubtedly on the low side of it, and so you have to take that into account. So yeah, I think maybe every 15 seconds would be a reasonable interval to save states, but every second or quarter seconds is out of the question.
|
You guys are not even considering the CPU issue as well for this brute force approach you're considering. Not only there's the obvious memory problem tec27 talks about and which will prolly be even worse on sc2 (such as maybe using 8 byte double floats for position for example). But you guys are also completely ignoring the cpu. Recording 60fps of all that data would be a heavy slow down for any popular home computer even IF you have the memory for it. You might just fraps it instead ¬¬
And there's also the development time.. honestly, they have better things to focus their strength on. They haven't even finished coding bnet yet. Let's delay the game release by a couple of months only so a few randoms can enjoy replay rewinding... yea right... They're already putting on state saving every x minutes, that is good enough, be satisfied with that.
This brute force idea of saving states every frame during live play is completely out of question. Stop dreaming ^^
|
lol @ RAM size talks. ever heard of virtual memory?
|
Sure, why not waste as much memory as possible. You're implying we have enough of it anway, right?
|
yea my way is the easiest way me thinks...
|
The OP really has no idea what he is talking about, making replays go backwards would require completely new functions in the game.
|
On April 02 2009 17:59 fearus wrote:
The OP really has no idea what he is talking about, making replays go backwards would require completely new functions in the game.
that's why he disappeared after bill just grilled him and his "programmer" knowledge...
|
On April 02 2009 08:48 prOxi.swAMi wrote:Show nested quote +On April 02 2009 08:36 ocoini wrote:
Think it would be easier to just have a replay to avi converter type.
and which part of the map the screen focus on? :S
The one you'r watching as you convert
|
tec, are you working on your proposed solution? <3
|
Yeah, I've barely begun though. But SC is cool with me changing the tick counter at will (thereby jumping back or forward in the replay action list), and the game can be sped up to 42x fastest speed without any real modification (so every 1.4 seconds is a minute of gameplay). Both of those make it look doable. It should theoretically be possible to make SC run the game as fast as possible (no delay between update frames), but that will take a fair amount of work, I think.
Things I still need to do:
- Traverse the unit list
- Copy the unit list and store it elsewhere in memory
- Devise a good way to replace BW's unit list
- Make something to run through the replay as fast as possible and cache the unit list at specific intervals, then restart the replay from the beginning.
- Figure out how to fix the replay text when I jump around the replay, since for some reason it will only ever display a line of text once, even if I jump back before that point in the replay.
Assuming I can make all of that work, we should have a working replay seeker May be a while though, as I've got a bunch of other CS projects to do for school right now =/ (But SC stuff is so much more fun  )
|
tec, if we can go that fast, wouldnt it be more feasible to interpret the click on the replay progress (back or forward in time) and get the tick you clicked on. If its behind ur current replay progress point, hen restart the replay. Next is to speed up 42x till you get to the desired tick. I mean, i think this would probably take less time to implement than the checkpoint idea, and 42x is preetty fast... dunno if this is too noticeable though. What do you think?
|
On April 03 2009 06:10 never_toss wrote:
tec, if we can go that fast, wouldnt it be more feasible to interpret the click on the replay progress (back or forward in time) and get the tick you clicked on. If its behind ur current replay progress point, hen restart the replay. Next is to speed up 42x till you get to the desired tick. I mean, i think this would probably take less time to implement than the checkpoint idea, and 42x is preetty fast... dunno if this is too noticeable though. What do you think?
It'd definitely be noticeable, but its a decent idea I suppose. Main issue there is actually restarting the replay, but I'm pretty sure thats doable (I know I accidentally found a way to restart games in progress when I was coding APMAlert ). Main problem there is restarting from the beginning when you want to seek like 20 minutes in, which would take almost 30 seconds to get to.
|
On April 03 2009 06:48 tec27 wrote:Show nested quote +On April 03 2009 06:10 never_toss wrote:
tec, if we can go that fast, wouldnt it be more feasible to interpret the click on the replay progress (back or forward in time) and get the tick you clicked on. If its behind ur current replay progress point, hen restart the replay. Next is to speed up 42x till you get to the desired tick. I mean, i think this would probably take less time to implement than the checkpoint idea, and 42x is preetty fast... dunno if this is too noticeable though. What do you think? It'd definitely be noticeable, but its a decent idea I suppose. Main issue there is actually restarting the replay, but I'm pretty sure thats doable (I know I accidentally found a way to restart games in progress when I was coding APMAlert ). Main problem there is restarting from the beginning when you want to seek like 20 minutes in, which would take almost 30 seconds to get to.
Right right... hmmm...
Unless you can do the no wait between updates, which i think wouldnt be that much of a gain generally... I would still love to see an early version if you can make the fast forwarding idea...
tec, can I help you out with some coding? ^-^
|
On April 03 2009 07:00 never_toss wrote:Show nested quote +On April 03 2009 06:48 tec27 wrote:On April 03 2009 06:10 never_toss wrote:
tec, if we can go that fast, wouldnt it be more feasible to interpret the click on the replay progress (back or forward in time) and get the tick you clicked on. If its behind ur current replay progress point, hen restart the replay. Next is to speed up 42x till you get to the desired tick. I mean, i think this would probably take less time to implement than the checkpoint idea, and 42x is preetty fast... dunno if this is too noticeable though. What do you think? It'd definitely be noticeable, but its a decent idea I suppose. Main issue there is actually restarting the replay, but I'm pretty sure thats doable (I know I accidentally found a way to restart games in progress when I was coding APMAlert ). Main problem there is restarting from the beginning when you want to seek like 20 minutes in, which would take almost 30 seconds to get to. Right right... hmmm... Unless you can do the no wait between updates, which i think wouldnt be that much of a gain generally... I would still love to see an early version if you can make the fast forwarding idea... tec, can I help you out with some coding? ^-^
Yeah, I think I may try implementing that fairly quickly here. I wouldn't mind having some help on this project, but there may be some difficulties in that. I'll PM you about it though.
|
Yeah being able to rewind a reply is a great help especially if your analyzing a build order and in case you missed something you can just rewind it back instead of restarting the whole replay.
|
EDIT: sry just completed reading whole thread, seems my point was brought up before, ill leave my coment as is anyways, just for consistency ;p
you could always implement some kind of replay rewind in sc1 (although it would be horrendously memory consuming), you would just have to have some plugin that saves the state of the game at each time a new action is taken in memory and an index that refers to each 'savestate', you wouldnt be able to see 'visually-rewinded' animations, but you basicly could go back to any 'frame' of the replay where 'frames' are not measured in seconds, but in indexed times, when actions happen
e.g.: player one (he is an asshole hacker) gives automine command+produce worker command at gametick 5 he doesnt issue any other commands till lets say gametick 30, while player two (some random but honest noob) issues his non-splitting gather command at gametick 18, then issues a train worker command at gametick 22, has no other actions till 30 as well
that would mean that our 'frames' till this point in the game would be
frame 0 : start of game (no safestate needed, already in the replay file)
frame 1 : gametick 5 : hacker issues his commands
frame 2 : gametick 18 : noob gathers
frame 3 : gametick 22 : noob trains
...
and so on
drawback: you would need number of savestates equal to 'frames', which would sum up quite a lot of memory (RAM) space
pro: play from replay possible, you can go back in the replay if you missed anything
hope that clarifies that there indeed would be the possibility of sc1 replay rewind, but its rather unpracticle because of the amount of resources it would consume
hf
|
On March 31 2009 17:02 Bill307 wrote: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.
1) it amazes me that you tout people when you don't even grasp the concepts of information management. it would be TOTALLY feasible to add a rewind functionality to sc2 offline replay viewing by rendering snapshots of units. given a 1 sec snapshot interval (1/30th of what css standard server use ... but of course sc2 snapshots will be bigger due to more data beeing transfered) and a 20 minute game (20*60 = 1200) you would occupy AT MOST 120mb ram. and trust me, this is VERY pessimistic (no compression, LOTS of details captured in the snapshot ... like animation state for units and doodads which could proof to be unimportant anyway).
of course you could reduce memory load by only snapping every 5 or 10 seconds (much like most mpeg4 implementations) to 20 or just as little as 10 megabytes ram load. with fast harddrives beeing already a standard, you could even cache the snapshots on harddisk ... seeing that some games require as much as 2gig for swap files, this 100mb+ seem quite minimalistic.
possible problems with this implementation would include
-) exact timecode (reproduciong the exact progressbar state of unit/building construction or upgrade research)
-) still too much data to handle (8 players with each hundreds of units could increase snapshot size). but with adaptive lossless compression (coordinates for units can be compressed VERY efficiently to about 1/5th of their uncompressed size) this shouldn't be an obstacle
-) online implementation (sending 100k snapshots over consumer upload takes quite a while). this could be countered by fixing snapshot creation to a timecode and creating snapshots on each machine. then you just have to transmit the snapshot number to jump to (which IS a possible security risk if not handled properly).
-) memory requirements (100mb+ memory load for replays). again this can be countered by both compression and harddisk caching
-) animation synchronisation. depending on how details animations will be, how they are coded and how importan they are for gamemechanic calculation, this could be quite some chunk of data. but given a server tick rate of 20-30fps (no current online game has higher tickrates over internet) you could introduce a fixed timecode for that so snapshos could save an exact timeintervall since the animation has startet. same goes for building/unit construction and research upgrades, but the problem is less dramatic here.
conclusion:
this is DEFINITLY doable, even without touching actual replay code at all. it can be "added" as an option to replay playback with very little, if not none at all, interaction with gamelogic and replay code.
so now quite sticking your head up your .. and start beeing creative. how do you think waaaghtv spawned over 5 years ago? noone thought it would be possible ... look at it now.
/edit:
of course this could only be implemented "easily" when modifying the original sourcecode. you could do it in a community project, but how will you implement controls to actually jump back to a given frame ... i'm not good at interface manipulation so i can't see now how it would be possible other than running sc2 in window and having an external controllbar to rewind.
also if done as community project this could be seen as a hack by blizzard, because you are actively reading sc2 memory (wow glider had problems with that and lost the case i think) which blizzard doesn't really want you too (for obvious reasons ... maphack). so best bet would be to hope for blizzard to implement it.
|
Guys
Anyone who says rewind can be implemented in replays with ease has ZERO clue what they are talking about.
Edit --
Here is a scenario to ponder about:
Here is my dummy replay ------------
Game starts - usual preload such as map, race etc..
Command 1 - Select 4 probes
Command 2 - Right click on minerals.
Game ends
I let the game run for say ... an hour and go afk, game length is irrelevant as I have only issued 2 commands.
Now this 1 hour long replay has 2 commands. Only 2 and the unit list remains at 4 probes.
Just off the top of my head the additional functions that would be needed.
- 2 new mineral functions - 1 to increase mineral patch when it is mined, 1 to decrease player mineral count whenever a probe returns cargo to the nexus.
- 1 new movement function - so probes can moon walk backwards
- 1 mining path AI function - this alone is such a crapload of work, as we all know when workers mine, they often run to a patch, notice it is already being mined then suddenly change target mineral patches and run across to another patch.
Any of the suggestions about saving game state, then loading it from that point of time, isn't in theory a rewind. A rewind would be to exactly as the name suggests that we read the command backwards.
i.e. we can watch the game play itself backwards.
A gamestate loaded somewhere is pretty much a fast(a really fast) forward to that point of the replay.
|
On April 04 2009 12:42 fearus wrote:
i.e. we can watch the game play itself backwards.
now that will probably be impossible because of the way gamecode works.
AOn April 04 2009 12:42 fearus wrote:
gamestate loaded somewhere is pretty much a fast(a really fast) forward to that point of the replay.
not quite.
fast forwarding from begining to a given point DOES take calculation time directly proportional to the time elapsed from the beginning to the desired point. a savestate solution is (virtually) independent of this timespan.
again:
the savestate way is used in all common used video codecs (mpeg2, xvid, divx, h264, vc1, ...) and in any decent first person online shooter on the pc (all games with any quake and valve engine ... don't know about unreal engine). although not all pc games let you rewind demos (quake 3 e.g.) several community projects showed that it can be done.
many people have so much excess computing capabilities that they even can dump the entire video stream to their harddisk ... dumping snapshots of gamestate shouldn't drag down performance that much.
|
What about saving the rep as a video file with attached units/resources info?
|
how big is the resolution of that video file ? the whole map resolution ? 1 second would be 20M at least with low quality image compression -.-
|
On April 04 2009 16:24 LibertyTerran wrote:
What about saving the rep as a video file with attached units/resources info?
i can't follow you
1) in a video, you wouldn't be able to change your view (e.g. scroll around)
2) in a video, ressources would already be displayed ... why attach it?
3) a video would take MASSIVE ammounts of data ... uncompressed 1280x800 frames occupy 3mb of space. 3mb*60(fps)*60(seconds) = 10,8gig of uncompressed video data each minute. what?
|
On April 03 2009 18:03 jacen wrote:Show nested quote +On March 31 2009 17:02 Bill307 wrote: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. 1) it amazes me that you tout people when you don't even grasp the concepts of information management. it would be TOTALLY feasible to add a rewind functionality to sc2 offline replay viewing by rendering snapshots of units. given a 1 sec snapshot interval (1/30th of what css standard server use ... but of course sc2 snapshots will be bigger due to more data beeing transfered) and a 20 minute game (20*60 = 1200) you would occupy AT MOST 120mb ram. and trust me, this is VERY pessimistic (no compression, LOTS of details captured in the snapshot ... like animation state for units and doodads which could proof to be unimportant anyway). of course you could reduce memory load by only snapping every 5 or 10 seconds (much like most mpeg4 implementations) to 20 or just as little as 10 megabytes ram load. with fast harddrives beeing already a standard, you could even cache the snapshots on harddisk ... seeing that some games require as much as 2gig for swap files, this 100mb+ seem quite minimalistic. possible problems with this implementation would include -) exact timecode (reproduciong the exact progressbar state of unit/building construction or upgrade research) -) still too much data to handle (8 players with each hundreds of units could increase snapshot size). but with adaptive lossless compression (coordinates for units can be compressed VERY efficiently to about 1/5th of their uncompressed size) this shouldn't be an obstacle -) online implementation (sending 100k snapshots over consumer upload takes quite a while). this could be countered by fixing snapshot creation to a timecode and creating snapshots on each machine. then you just have to transmit the snapshot number to jump to (which IS a possible security risk if not handled properly). -) memory requirements (100mb+ memory load for replays). again this can be countered by both compression and harddisk caching -) animation synchronisation. depending on how details animations will be, how they are coded and how importan they are for gamemechanic calculation, this could be quite some chunk of data. but given a server tick rate of 20-30fps (no current online game has higher tickrates over internet) you could introduce a fixed timecode for that so snapshos could save an exact timeintervall since the animation has startet. same goes for building/unit construction and research upgrades, but the problem is less dramatic here. conclusion: this is DEFINITLY doable, even without touching actual replay code at all. it can be "added" as an option to replay playback with very little, if not none at all, interaction with gamelogic and replay code. so now quite sticking your head up your .. and start beeing creative. how do you think waaaghtv spawned over 5 years ago? noone thought it would be possible ... look at it now. /edit: of course this could only be implemented "easily" when modifying the original sourcecode. you could do it in a community project, but how will you implement controls to actually jump back to a given frame ... i'm not good at interface manipulation so i can't see now how it would be possible other than running sc2 in window and having an external controllbar to rewind. also if done as community project this could be seen as a hack by blizzard, because you are actively reading sc2 memory (wow glider had problems with that and lost the case i think) which blizzard doesn't really want you too (for obvious reasons ... maphack). so best bet would be to hope for blizzard to implement it.
I like this idea alot. snapshots of in-game data wont be very large at all, as most game data in the replay tends to be of the terrain and what not.
especially with compression, the snapshot will decrease in size significantly seeing how most units will be already in previous locations during the game, so most building locations can be compressed.
i'd say that a snapshot every 5 seconds is totally doable. when the cumulative snapshot size begins to exceed 50mb, snapshot log can be trimmed down to one every 10 seconds thus deleting every other one. this trimming may even be done continuously rather than at set intervals.
seeing how AIM instant messenger takes a whole fucking 30 megs don't ask me why, i'd consider 50 megs for SC2 snapshots as totally doable, as by the time sc2 is out, 3gig mem on comps will be rather normal.
|
what's nice with play-from-replay, is that you're now able to resume a game just before your friend disconnected
|
So you are trying to integrate a function which you don't even have a closed functional form of... Seems like restarting the replay in super fast mode (no graphics, no game engine slowdowns, etc) is only feasible way.
|
How would taking a snapshot of ingame data every 5seconds achieve anything.
You expecting all the units to be stationrary in that 5 second?
|
On April 05 2009 17:38 NoNameLoser wrote:
So you are trying to integrate a function which you don't even have a closed functional form of... Seems like restarting the replay in super fast mode (no graphics, no game engine slowdowns, etc) is only feasible way.
what are you talking? what would need to be integrated? ressource ammount ... i already said this could be stored in a snapshot too.
On April 05 2009 18:16 fearus wrote:
How would taking a snapshot of ingame data every 5seconds achieve anything.
You expecting all the units to be stationrary in that 5 second?
What? you just play the replay from the snapshot on ... where is the problem?
|
look at replay playback as a multidimensional function which has some unique value (gamestate or snapshot if you will) at a given point in time. you are trying to invert it (feed time to get gamestate). The main problem i see is that it is not invertible by design, game engine only takes few parameters and then does complex uncontrollable loops that only go one way, forward.
Besides that the "function" is self recursive (things that happened early on effect how later things happen) so having an engine which will play things in reverse is out of the question without redesigning every aspect of it where every bit of information is stored.
Think of a gasoline car, you feed fuel, which through explosions (irreversible process) gives out kinetic energy which makes the car move. Reversing a replay is like making the car move so that its sucks back its exhaust does some impossible physics and produces back energy (gasoline)... It just cant do that by design. Electric cars have some of that ability but its still not perfect.
Game state idea could be feasable but it requires that at that specific point in time no irreversible loops are being run which is rather unlikely. If a unit was given a command to move from one corner of map to the other, AI logic will flow in one way, forward, and you wont be able to "loop back" because it cannot do that by design.
|
On April 06 2009 03:21 NoNameLoser wrote:
look at replay playback as a multidimensional function which has some unique value (gamestate or snapshot if you will) at a given point in time. you are trying to invert it (feed time to get gamestate). The main problem i see is that it is not invertible by design, game engine only takes few parameters and then does complex uncontrollable loops that only go one way, forward.
Besides that the "function" is self recursive (things that happened early on effect how later things happen) so having an engine which will play things in reverse is out of the question without redesigning every aspect of it where every bit of information is stored.
Think of a gasoline car, you feed fuel, which through explosions (irreversible process) gives out kinetic energy which makes the car move. Reversing a replay is like making the car move so that its sucks back its exhaust does some impossible physics and produces back energy (gasoline)... It just cant do that by design. Electric cars have some of that ability but its still not perfect.
Game state idea could be feasable but it requires that at that specific point in time no irreversible loops are being run which is rather unlikely. If a unit was given a command to move from one corner of map to the other, AI logic will flow in one way, forward, and you wont be able to "loop back" because it cannot do that by design.
K.....I'm getting fed up
LISTEN UP KIDS YOU CAN EASILY REWIND YOUR DAMNED REPLAYS!!!!
All Blizzard needs to do is set it up so that when you click a different position on the replay time bar the replay automatically restarts and runs in fast forward(as fast as they can possibly get it) until it reaches the specific point in time. Is it perfect? no but as we have already fucking figured out by now Sc2 isn't set up in a way that would make this easier.FIN
|
as far as i can tell there are 2 good suggestions in the thread:
Checkpointing
and
Re-replaying from the beginning to the user selected time point at xASFASTASPOSSIBLE speed
Why not just do both? Do some form of checkpointing to save the game state (but at low frequency) , and when the user chooses a spot to jump to, restore it by going forward as quickly as possible from the nearest checkpoint? I think that's the best space/time tradeoff.
as far as "true" replaying is concerned (i.e. going back in time and watching the replay backwards)... i don't think thats possible as many people have said already. and i don't think anyone here really wants to watch it in "real" backward.
|
Actually, that ram capture method has some real potential. Especially if implemented during production.
For those who don't understand it entirely a simple example can come from old console emulators (eg SNES). This is just a rehash of how the idea proposed by the people above works for those that may not understand its aid. Also note that it does not give true 'rewind' but rather allows you to step back and forward to any point in a replay that you choose.
Traditional save features in games are based on the game data. The save would go through and put the position, direction, current animation frame, etc for every unit/object in the game into a file. The save files size would vary greatly based on how many units etc are currently in the game.
A 'state save' as used in emulators for example, simply makes a copy of the ram in the location where the game is running in memory. To load it simply replaces the current games in ram state with the saved state. Every file is the exact same size, no matter how many units are in the game because the entire 'allocated' ram area is saved, even if its empty.
If an in-game state saved was implemented by the creators of the game (instead of a 3rd party as in emulators) they could specifically avoid saving the areas of memory which simply hold graphical and audio tracks. The piece of ram which is grabbed and saved can be dropped to a very small amount.
Once the replay is loaded saved states can be captured every x seconds. Since we know that the state will be the same size every time, the system can see how much free memory you have and change x to the smallest number possible in seconds to allow you to jump to more locations within the replay.
This process could be further refined to lower ram costs by taking the fast forward function into account. If for example you know you can fast forward at 44x speed. Why take a state every second, when it would take 1 second to process 44 seconds of play? If those (made up) numbers are accurate you would at most take a save state every 44 seconds. The point is that by taking both save state, and fast forward speed into account you can create a significantly less ram consuming advanced system.
|
On April 06 2009 03:21 NoNameLoser wrote:
look at replay playback as a multidimensional function which has some unique value (gamestate or snapshot if you will) at a given point in time. you are trying to invert it (feed time to get gamestate). The main problem i see is that it is not invertible by design, game engine only takes few parameters and then does complex uncontrollable loops that only go one way, forward.
Besides that the "function" is self recursive (things that happened early on effect how later things happen) so having an engine which will play things in reverse is out of the question without redesigning every aspect of it where every bit of information is stored.
yeah ... like when did i say that reversing the gameplay would be possible. reversing videostreams (other than back-playing I frames or prerendering b and p frames for reverse play) is also not technically possible. and since my explanation is largely based on this concept ... what gives.
but again, to state the obvious:
reversing the gameplay will not be possible.
On April 06 2009 03:21 NoNameLoser wrote:
If a unit was given a command to move from one corner of map to the other, AI logic will flow in one way, forward, and you wont be able to "loop back" because it cannot do that by design.
i see your point.
but with snapshots you don't have to loop back. you capture a state where the unit is inbetween it's start (left side of the map e.g.) and goal (right side of the map e.g.). as long as you ALSO capture its goal (right side) the ai will pick up as if the order was given at the snapshot.
if this would not be possible, you couldn't change unit's orders while they are executing them, only after they finished. and since we do know this is possible, it should also be possible to capture goals and feed them through snapshots.
so with snapshots you also only run forward through gamecode, you just have to be sure to capture all states that are relevant to it.
On April 06 2009 04:22 DeathSpank wrote:
K.....I'm getting fed up
LISTEN UP KIDS YOU CAN EASILY REWIND YOUR DAMNED REPLAYS!!!!
All Blizzard needs to do is set it up so that when you click a different position on the replay time bar the replay automatically restarts and runs in fast forward(as fast as they can possibly get it) until it reaches the specific point in time. Is it perfect? no but as we have already fucking figured out by now Sc2 isn't set up in a way that would make this easier.FIN
let me state a few things here
-) noone outside blizz has seen a sc2 replay yet
-) noone outside knows the game and replay code
so saying "by now Sc2 isn't set up in a way that would make this easier" is a little too much speculation imho. as stated above, replays could be at least "back-skippable" through some sort of snapshots ( compare to Intra-Frames: http://en.wikipedia.org/wiki/Intra_frame ), without having to restart and fast forward the game.
On April 06 2009 12:04 DeCoup wrote:
This process could be further refined to lower ram costs by taking the fast forward function into account. If for example you know you can fast forward at 44x speed. Why take a state every second, when it would take 1 second to process 44 seconds of play? If those (made up) numbers are accurate you would at most take a save state every 44 seconds. The point is that by taking both save state, and fast forward speed into account you can create a significantly less ram consuming advanced system.
i seriously doubt the 44x speed value for sc2. seeing as 8x speed had troubles producing smooth framerates during war3 and even tft launch on mid-range hardware, i am not seeing this happening.
i'm interested ... let's do some math.
assuming the replay controls will have about the same screensize in sc2 as they had in sc and war3 we have 25% of screenwidth (war3 has just 20%) availible for a replay progress bar. assuming a resolution of 1920x1200, we end up having 480pixels worth of progress bar estate.
now most games will be less than 40 minutes or 2400 seconds. if you create snapshots every 5th seconds, you end up getting 480 snapshots in 40 minutes or 240 snapshots in 20 minutes. that means that in a 20 minute game, every snapshot only occupies 2 pixels at one of the highest resolutions availible for mass consumers. considering that many people will still play 1280x1024, they will end up getting almost exactly 1 snapshot per pixel during a 20 minute game (256pixels covering 240 snapshots).
conclusion:
snapping more often than 5 seconds will not be noticable in a vast majority of cases. you will need games under 10 minutes and resoltions over 1680px width to have one snapshot streching over 3 pixels. this seems to be reasonably good accuracy if you want to enable back-skipping in replays.
|
I Already asked this question to dustin when the game was announced....
|
On March 31 2009 17:02 Bill307 wrote:Show nested quote +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.
sorry for the thread bump but it appears a lot people got PWNED this blizzcon. It was announced (edit: apparently it was announced pre blizzcon but I missed it) that replays will have the rewind ability. Of course I am not pointing any fingers
|
On August 25 2009 02:36 houseurmusic wrote:Show nested quote +On March 31 2009 17:02 Bill307 wrote: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. sorry for the thread bump but it appears a lot people got PWNED ages ago. It was announced ages ago that replays will have the rewind ability. Of course I am not pointing any fingers
Fixed.
|
Who get pwned? It seems like you dont have any clue at all and still dont understand shit after much debate. Normal rewind is still impossible and always impossible unless blizz wants to save every frame, which is obviously not doable due to the excessive storage.
Current rewind is not the rewind like what you have in the video player. In the current rewind system, they save the key frame every short internval of time, like 10 secs, 20 secs..., so the user can jump back 10 secs, etc.. in the replay. The shorter the difference time between each key frame is, the *smoother* the rewind becomes but also the size of the replay increases greatly. If the interval time is 1 frame, then we have the perfect rewind. Blizz has been talking about trying to implement such thing long time ago and we also know about this.
The difficulty is how to find a good difference time between the key frames so that the rewind feature and the size of replay are acceptable. The only new thing here is that Blizz announces they have successfully implemented such feature.
|
Why can't the extra data just be stored in temporary file that is created while you are watching the replay?
|
Calgary25977 Posts
Because it saves the state of the entire game in that extra data. You can't generate that data from nothing.
And houseurmusic, you don't understand the announcement or the problems with your suggestion. Replay rewind works as hixhix explained, with keyframes, and this has been announced for at least a month, if not several.
|
tec27, did you get to test the solution we proposed for sc1 bw rewind?
|
On August 25 2009 03:21 Chill wrote:
Because it saves the state of the entire game in that extra data. You can't generate that data from nothing.
If you are watching replay then you don't generate that data?
|
Sweden33719 Posts
On August 25 2009 03:21 Chill wrote:
Because it saves the state of the entire game in that extra data. You can't generate that data from nothing.
And houseurmusic, you don't understand the announcement or the problems with your suggestion. Replay rewind works as hixhix explained, with keyframes, and this has been announced for at least a month, if not several.
They actually talked about it the first time LAST blizzcon (2008) then announced it 2 or so months ago?
|
Well it was new information to me however it works. I just remembered so much flaming from this particular thread and giggled when I heard it talked about during the panel. I didn't get into the discusion here because I believed in general what bill posted.
|
On August 25 2009 03:18 Polis wrote:
Why can't the extra data just be stored in temporary file that is created while you are watching the replay?
You mean they can generate the key frames on fly while watching the replay to reduce the size of replay? That's doable for sure, and it comes with several cons and pros:
Pros:
- Smaller size of the replays, virtually a replay file contains the same data as wc3 and sc1 replays.
Cons:
- Everytime you watch a same replay, a large amount of the same data is generated.
- Time-consuming. Imagine watching every replay is like you play sc1 and save the game every 10 seconds. If all key frames are saved once and used many times, it's faster.
So I guess the primary trade-off between generating key frames on fly and saving all the key frames once is the replay file size and processing time. Blizz probably tried both ways, or even combined them to get an efficient solution.
|
Calgary25977 Posts
On August 25 2009 04:30 Polis wrote:Show nested quote +On August 25 2009 03:21 Chill wrote:
Because it saves the state of the entire game in that extra data. You can't generate that data from nothing. If you are watching replay then you don't generate that data?
I really doubt they would do that because it would feel like a really 2002 solution. Like you can't fastforward anything or rewind unless you've already gone past that point at 1x speed. It would feel like buffering something that's already on your computer.
I suppose alternatively, when you load a replay, the program could quickly run the entire game at 1000x speed or something to generate the keyframes, but I would guess that runs into other technical problems, specifically for 4 hour long games. I think having larger replays is fine.
|
There's always the possibility of the replay storing key frames at bigger intervals, and that on demand, on smaller intervals keyframes are remembered, or generated in advance within local watching context or something.. there's a solution that scales.
|
they should just record the video, not every action
|
On August 25 2009 05:53 alt.tday wrote:
they should just record the video, not every action
Most video formats also apply key frames with difference frames to optimize storage while supporting winding (and probably also to improve accuracy with lossy compression being applied).
Funny thing eh?
Serious answer though. Storing video would be horribly less efficient in terms of memory and in terms of visual quality, not to mention all the features you're gonna do without such as free roaming on the map while playback is happening, being able to see in-game statistics and probably more.
|
On August 25 2009 05:52 Badjas wrote:
There's always the possibility of the replay storing key frames at bigger intervals, and that on demand, on smaller intervals keyframes are remembered, or generated in advance within local watching context or something.. there's a solution that scales.
So what you're saying is that they (for example) store keyframes at 30 second intervals, and to rewind to 3:42, it starts at 3:30 and fast forwards through 12 seconds lightning fast before it resumes playing?
|
On August 25 2009 03:30 never_toss wrote:
tec27, did you get to test the solution we proposed for sc1 bw rewind?
I started working on it but then got busy doing other stuff. Haven't really looked at it since. Guess its still just as doable, but I'm not sure when/if I'll get around to it.
On August 25 2009 07:06 kerr0r wrote:Show nested quote +On August 25 2009 05:52 Badjas wrote:
There's always the possibility of the replay storing key frames at bigger intervals, and that on demand, on smaller intervals keyframes are remembered, or generated in advance within local watching context or something.. there's a solution that scales. So what you're saying is that they (for example) store keyframes at 30 second intervals, and to rewind to 3:42, it starts at 3:30 and fast forwards through 12 seconds lightning fast before it resumes playing?
There's not much a reason to discuss possible solutions any more. There's really only like 3 different ways to do it, pretty much, and all of them have already been discussed to death in this/other threads on here.
|
At Blizzcon 09 they declaired that they have now worked out how to perform replay rewind.
They told us it could not be done, but we found a way
So now we don't have to worry about using bodgy time stepping or recording video which can be rewound. They have working rewind.
|
On August 25 2009 10:14 DeCoup wrote:At Blizzcon 09 they declaired that they have now worked out how to perform replay rewind. So now we don't have to worry about using bodgy time stepping or recording video which can be rewound. They have working rewind.
But as hixhix mentioned, it does not work the same way as a video recorder rewind.
|
Half Life engine games/mods have had rewindable demos for a long, long time. Of course if they did this with SC2 the replays would probably be a lot bigger.
|
On August 25 2009 05:53 alt.tday wrote:
they should just record the video, not every action
lol, good one :p
|
On August 25 2009 05:36 Chill wrote:
I really doubt they would do that because it would feel like a really 2002 solution. Like you can't fastforward anything or rewind unless you've already gone past that point at 1x speed.
Why at 1x speed? It could scale if you watched at 4x speed and it saves every second then you you have 1 saved state every 4 sec for 1x, for 8x it would just skip half etc. The benefit of this is that you could rewind pretty much the point that you want becouse space will not limit the amount of save states as it does for the replay. Both could exist at once have some saved states every minute or so so you could fast forward.
|
reverse engineering the replay would take way too much time/resources on blizz's part. instead, they should simply allow for faster replay fast forwarding, like x256 or something. so if you want to "rewind" you just restart the replay and fast forward at an absurdly fast speed until you get to where you want to watch.
|
Reading this I've just had a thought, if the old replay system simply replays user commands how does it deal with the miss chance to higher ground? Presumably you could end up with units living longer than they should have done through freak runs of misses.
Sorry if this was answered already but it's a long thread..
|
On August 26 2009 20:13 WolfStar wrote:
Reading this I've just had a thought, if the old replay system simply replays user commands how does it deal with the miss chance to higher ground? Presumably you could end up with units living longer than they should have done through freak runs of misses.
Sorry if this was answered already but it's a long thread..
There is no chance to miss on high ground in SC2. But since it is possible to enable the feature (or use randomness in other ways) in UMS maps i'll explain how it is implemented.
There is no such thing as true random on a computer. They are only capable of performing calculations on existing data. There are 2 commands used to give the illusion of randomness on a PC.
1) The seed (eg Randomize 34, would set the seed to 34). Depending on the program you can set a seed to anything you like. A number, a string of text etc. (Think of the seed as a number for this example to make it easier to understand).
2) Generate number (ill call the command RND for the rest of this post). The command that actually generates a 'random number'.
The RND generates a 'random number' based on the seed, then increases the seed by 1. So if your initial seed was 32 then after you generate a random number the seed becomes 33. etc.
A random number is just a maths formula performed on the seed. So if for example you made a game that rolled a dice 5 times, and you set the seed to 34 the sequence of 'random numbers' would ALWAYS be (for example) 1 4 3 2 4. If you load the game again and run it again the game would always produce those numbers in that order.
The way games appear to have randomness is to set the Seed to the current date/time (in milliseconds). So every time you play the game the seed is different, but technically it is still not truly considered to be random, because if we were to save that seed (whatever the time was) and use it later we would get the same results. But it appears to be random. Basicly computers are not capable of generating random numbers, but we trick them into it by using a number under constant change (time).
So all a game needs to do is at the start, save the seed it generated from the clock time to the replay dile. Next time the replay is watched the seed is set to that same number and all 'random' events will be the same result as when you played it.
I hope my 'Understanding Random 101' lesson made sense to at least a few of you. I am not that great at explaining things such as this, but it is actually pretty interesting when you look into it.
|
Actually the mechanism used in most implementations for "random" (the simple ones anyway) is called a "linear congruential sequence" where a simple transform is repeatedly applied on the seed value.
Typically seed <-- (A * seed + B) mod M, where A, B, M are properly chosen constants. then the random number that is returned is usually taken from the bits of the seed value with shift/mask. The least bits have repeating patterns but the higher bits appear random enough to qualify.
So starting from the same seed you would get the same sequence.
But if you start from seed + 1, you get a totally different sequence, where in your example, you would get the same sequence, with the first number missing. This would be considered a bad thing for a random number generator.
|
Very true. I tried to make it easy to explain but told a small white lie to do so, haha. But yeah, it is very important to note that seed+1 would be totally different. Thanx ;P
|
As for reversing a replay in an RTS.
This is an extremely difficult thing to implement -- if we ignore the brute force solution of re-running the replay from the last available saved game state until just before the current "game tick".
To do this you would have to store game state changes as a series of transactions, and store sufficient information in the replay to reverse them. You would have to cover everything, from units to projectile movement to automatic retargetting, application of special abilities on targetted units and buildings, and so on.
Reversible replays would still take a lot less storage than videos, but much more than "commands only" replays like those in BW.
|
Thanks chaps very interesting.
Ah the mighty computer is unable to just pick a number lol
|
On August 26 2009 20:43 DeCoup wrote:Show nested quote +On August 26 2009 20:13 WolfStar wrote:
Reading this I've just had a thought, if the old replay system simply replays user commands how does it deal with the miss chance to higher ground? Presumably you could end up with units living longer than they should have done through freak runs of misses.
Sorry if this was answered already but it's a long thread.. There is no chance to miss on high ground in SC2. But since it is possible to enable the feature (or use randomness in other ways) in UMS maps i'll explain how it is implemented. There is no such thing as true random on a computer. They are only capable of performing calculations on existing data. There are 2 commands used to give the illusion of randomness on a PC. 1) The seed (eg Randomize 34, would set the seed to 34). Depending on the program you can set a seed to anything you like. A number, a string of text etc. (Think of the seed as a number for this example to make it easier to understand). 2) Generate number (ill call the command RND for the rest of this post). The command that actually generates a 'random number'. The RND generates a 'random number' based on the seed, then increases the seed by 1. So if your initial seed was 32 then after you generate a random number the seed becomes 33. etc. A random number is just a maths formula performed on the seed. So if for example you made a game that rolled a dice 5 times, and you set the seed to 34 the sequence of 'random numbers' would ALWAYS be (for example) 1 4 3 2 4. If you load the game again and run it again the game would always produce those numbers in that order. The way games appear to have randomness is to set the Seed to the current date/time (in milliseconds). So every time you play the game the seed is different, but technically it is still not truly considered to be random, because if we were to save that seed (whatever the time was) and use it later we would get the same results. But it appears to be random. Basicly computers are not capable of generating random numbers, but we trick them into it by using a number under constant change (time). So all a game needs to do is at the start, save the seed it generated from the clock time to the replay dile. Next time the replay is watched the seed is set to that same number and all 'random' events will be the same result as when you played it. I hope my 'Understanding Random 101' lesson made sense to at least a few of you. I am not that great at explaining things such as this, but it is actually pretty interesting when you look into it.
Basically you're right. But there is true randomness generators on computer such as /dev/random that intercepts environmental noise to generate `random' seed. And if you are really biased to say the environmental noise is not `random' then theoretically, nothing in the universe is random Also, there are tons of methods to generate random numbers. The way you describe is the simplest way, it can be used for statistical stuffs, but for security, you need strong cryptographic random generators which are way more complicated than just increasing the seed by 1.
|
On August 26 2009 21:01 EmS.Radagast wrote:
Actually the mechanism used in most implementations for "random" (the simple ones anyway) is called a "linear congruential sequence" where a simple transform is repeatedly applied on the seed value.
Typically seed <-- (A * seed + B) mod M, where A, B, M are properly chosen constants. then the random number that is returned is usually taken from the bits of the seed value with shift/mask. The least bits have repeating patterns but the higher bits appear random enough to qualify.
So starting from the same seed you would get the same sequence.
But if you start from seed + 1, you get a totally different sequence, where in your example, you would get the same sequence, with the first number missing. This would be considered a bad thing for a random number generator.
Interesting stuff! I never read much about how random numbers were generated and found this little program which I found pretty interesting.
http://www.vias.org/simulations/simusoft_lincong.html
|
Meh, it's easy. Most video codecs solved this problem eons ago.
You store "keyframes" at specific intervals with the state of the entire game saved. When you want to go backwards, you skip to the nearest saved keyframe, and then, resume to where you want to see.
This would allow you to go backwards to previous parts in the match and resume. To achieve real time reverse playback, you'd have either in a seperate manner record actions as they're played back (and simply reverse them), or, split a span of time into a ton of keyframes. You could do this in an efficient matter from the nearest keyframe k when you're at position n. Compute a new keyframe at (k+n)/2, and repeat until you're some small threshold t from n. As you recurse through the match you'll have nearly all of the keyframes you need computed.
|
I would say: use the old small "encrypted" replay format, but save the state while replaying x times per second. This way u should be able to rewind and so on
|
|
|
|
|
|
EPT
