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