|
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?
|
Calgary25998 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.
|
Calgary25998 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.
|
|
|
|
|
|
EPT
