|
On May 21 2007 10:13 HnR)Insane wrote:Show nested quote +On May 21 2007 10:06 DrainX wrote:On May 21 2007 07:29 Cascade wrote:On May 21 2007 04:34 DrainX wrote:On May 20 2007 17:23 Zironic wrote:
Since computers don't actually do random, they do a calculation based on what's known as a "seed". The seed is a number generated when the game is started and is then saved into the replay so random rolls will always become the same. If they use the same seed during the entire game then each random-roll would turn out the same (If one unit misses vs higher ground then all do etc.). Have blizzard ever made any statements about what they use as seed? or how can you be so sure? You either need a seed that varies over time or you need one seperate seed for every "die-roll". I think its much more likely that they use the "gametime played so far" as seed since it varies throughout the game but is always the same each time you replay it. Another option would be creating a high number of seeds at the start of the game and then using them in some set order... but that would just be stupid... Ok, you do not quite understand how seeds work.  Starting from ONE seed you generate not one, but a (very) long series of random numbers. These numbers are not truly random but completely determined from the seed, and the generator used. They are though random enough to use in starcraft. We don't want to get too technical. Point is: you can with one single seed generate a very long series of random numbers. I know prefectly well what a seed is. In most cases the system clock is used as seed and the reason you can create many different random numbers along the way is the clock always changes. If the clock were to stand still the seed would not work since it would turn out the same each time.  Random seed initializes the random generator. However, the next random number is not determined just by the initial seed, but it has some weird complicated formula which takes into account what was previously generated. When you seed the random number generator, it has no idea that the thing passed in is the system clock, nor does it keep track of how the clock changes. If you always start with the same seed at the start of your number sequence, then you'd be generating the same number, but what happens to the clock after you first seed it doesnt matter.
they don't need to be THAT complicated.  One of the easiest just take the last random number, multiplies with some number, adds some number and then takes the modulus with respect to a third number. R(i+1) = a*Ri + b MOD m.
m is often very big. R0 would be the seed, determining completely all coming Ri if we know a, b and m. Wouldn't suprise me if that is the generator used in sc.
Sorry for the offtopic, this thread is too good to waste with stupid random number generation...
|
On May 21 2007 10:13 HnR)Insane wrote:Show nested quote +On May 21 2007 10:06 DrainX wrote:On May 21 2007 07:29 Cascade wrote:On May 21 2007 04:34 DrainX wrote:On May 20 2007 17:23 Zironic wrote:
Since computers don't actually do random, they do a calculation based on what's known as a "seed". The seed is a number generated when the game is started and is then saved into the replay so random rolls will always become the same. If they use the same seed during the entire game then each random-roll would turn out the same (If one unit misses vs higher ground then all do etc.). Have blizzard ever made any statements about what they use as seed? or how can you be so sure? You either need a seed that varies over time or you need one seperate seed for every "die-roll". I think its much more likely that they use the "gametime played so far" as seed since it varies throughout the game but is always the same each time you replay it. Another option would be creating a high number of seeds at the start of the game and then using them in some set order... but that would just be stupid... Ok, you do not quite understand how seeds work. Starting from ONE seed you generate not one, but a (very) long series of random numbers. These numbers are not truly random but completely determined from the seed, and the generator used. They are though random enough to use in starcraft. We don't want to get too technical. Point is: you can with one single seed generate a very long series of random numbers. I know prefectly well what a seed is. In most cases the system clock is used as seed and the reason you can create many different random numbers along the way is the clock always changes. If the clock were to stand still the seed would not work since it would turn out the same each time. Random seed initializes the random generator. However, the next random number is not determined just by the initial seed, but it has some weird complicated formula which takes into account what was previously generated. When you seed the random number generator, it has no idea that the thing passed in is the system clock, nor does it keep track of how the clock changes. If you always start with the same seed at the start of your number sequence, then you'd be generating the same number, but what happens to the clock after you first seed it doesnt matter.
Yeah you are correct I didnt think of that possibility. That must be how it works. When I work with random numbers I always take a new seed every time I want a new random number since if you only use one seed everything is predetermined from game start :p To me that feels less "random" and in many games that information could be used by programmers for stuff like seeing what items mosters are going to drop etc but I guess in starcraft since there is so little randomness it doesnt realy matter. I guess there would be problems with doing it my way though because of lag :p
On May 21 2007 10:26 Cascade wrote:
Sorry for the offtopic, this thread is too good to waste with stupid random number generation...
Yeah sorry. You win  I missunderstood you a bit. Lets keep it on topic from here on.
|
On May 20 2007 16:18 thedeadhaji wrote:
I will be sad if communal replay watching ceases to exist, much like in war3
Here here. I did read somewhere that Blizz wants to encourage replay watching (or at least VOD watching) with US fans so as to make a possible scene like that in Korea. So, I think we are safe.
|
I read this on the blizzard suggestion forum:
"Start game from replay -- this would be very very very interesting. If you could load a replay with a friend and then start a real game from a particular point in the replay timeline. Thus allowing you and a friend to go back in time and try to play the same game differently, allowing you to really see what types of strategies would pay off and fine tune your skills."
That wouldnt be too hard to implement and it would be realy cool. Would be great if you are trying to learn the game or help someone learn the game. Watch their replay, then jump in and show them how they should have done etc.
|
I think the best way to 'rewind' replays would be to be able to load the replay at any point in time, which would have to reload the whole game etc.
So it's at 10 minutes but I want to see something at 9 minutes... I basically 'start it over' but at 9 minutes instead of the beginning. That way you don't have to store all the shit in the replay file, since it's just reading the commands from an earlier point in time.
If the commands in the file are listed chronologically... which I assume they are, as I understand it.
|
On May 23 2007 16:52 DrainX wrote:
I read this on the blizzard suggestion forum:
"Start game from replay -- this would be very very very interesting. If you could load a replay with a friend and then start a real game from a particular point in the replay timeline. Thus allowing you and a friend to go back in time and try to play the same game differently, allowing you to really see what types of strategies would pay off and fine tune your skills."
That wouldnt be too hard to implement and it would be realy cool. Would be great if you are trying to learn the game or help someone learn the game. Watch their replay, then jump in and show them how they should have done etc.
jesus
that'd be hot ^^
practicing would get so much easier, if you wanna practice a certain build ..
|
Russian Federation4235 Posts
On May 20 2007 16:41 Zironic wrote:
It would have to be all that information, FOR EVERY FRAME, with 60 FPS that means even if the information just takes one kb per frame it would still eat up 3.6MB per minute, and I think the information would take more then one kb per frame.
This is untrue. Game timer (which is what you probably are talking about) and FPS in 3D games are not connected because the framerate varies from video card to video card. And there is little need to store all the information for every timer tick - storing simple string variables (commands for the game engine that encode not the data, but the changes made to it - could be as simple as 1 letter and the accompanying integer number like a unit type to produce etc. which would probably take 5-10 bytes per command) is a much more efficient way. Even if you want rewinding, you should just save some additional events (like unit death etc) not save the complete state of the system, that is inefficient and stupid. The engine, ofc, would need some tweaks for this, but this is definetely possible.
Speaking on random number generation, its actually done using a seed of N bits and a simple logical operation. Every next bit is a result of XOR (exclusive OR) operation applied to the N bits before it. It effectively behaves like a random system with very low auto-correlation, but it's totally deterministic in its basis.
XOR (2) table:
00->0
01->1
10->1
11->0
Random number generation is not done programmatically, it's hardware-side (afaik, a RNG is located in a processor), so using any other way to do this is very inefficient.
|
On May 27 2007 12:24 BluzMan wrote:Show nested quote +On May 20 2007 16:41 Zironic wrote:
It would have to be all that information, FOR EVERY FRAME, with 60 FPS that means even if the information just takes one kb per frame it would still eat up 3.6MB per minute, and I think the information would take more then one kb per frame. This is untrue. Game timer (which is what you probably are talking about) and FPS in 3D games are not connected because the framerate varies from video card to video card. And there is little need to store all the information for every timer tick - storing simple string variables (commands for the game engine that encode not the data, but the changes made to it - could be as simple as 1 letter and the accompanying integer number like a unit type to produce etc. which would probably take 5-10 bytes per command) is a much more efficient way. Even if you want rewinding, you should just save some additional events (like unit death etc) not save the complete state of the system, that is inefficient and stupid. The engine, ofc, would need some tweaks for this, but this is definetely possible. Speaking on random number generation, its actually done using a seed of N bits and a simple logical operation. Every next bit is a result of XOR (exclusive OR) operation applied to the N bits before it. It effectively behaves like a random system with very low auto-correlation, but it's totally deterministic in its basis. XOR (2) table: 00->0 01->1 10->1 11->0 Random number generation is not done programmatically, it's hardware-side (afaik, a RNG is located in a processor), so using any other way to do this is very inefficient.
Wouldn't rewinding also require you to have a random function that can be run backwards? I suppose that could be done but I don't think the built in function can do it.
The largest problem with rewind i think is that all animations would have to be programmed so they can be run backwards. I'm not sure how much work this would be but as a guess it would be substantial.
Anyhow I wasn't thinking clearly when I suggested to save the gamestate for every frame of the game. At most you would need to save the gamestate for each tick (i don't know how fast Starcraft ticks but Supcom for example has 10 per second) and even then you would just need to save what changed since the last tick.
|
On May 23 2007 21:48 SoleSteeler wrote:
I think the best way to 'rewind' replays would be to be able to load the replay at any point in time, which would have to reload the whole game etc.
So it's at 10 minutes but I want to see something at 9 minutes... I basically 'start it over' but at 9 minutes instead of the beginning. That way you don't have to store all the shit in the replay file, since it's just reading the commands from an earlier point in time.
If the commands in the file are listed chronologically... which I assume they are, as I understand it.
ROFL, you can't skip or rewind commands and you can't start at a specific moment, because it's impractical to have the unit positions saved for every point in time of the game and not to mention this would mean the file would be as big as game ticks per second * game lenght in seconds * size of a single save game file and you'll need the processing power to save the game each game tick(and this usually takes a lot more) as well as run it, which would be completely pointless.
You can have it save the position every minute for example, but your replay stopping for a few seconds each game minute would still be annoying as hell, even more annoying than restarting the replay(except if you restart every replay you watch multiple times). Of course it could be optimised to run fine, but it would be a waste of programmers time, after all, they don't even include replay compatability between patches, which is not that hard to program.
|
Russian Federation4235 Posts
SC 1 timer ticks at about 25-30 (don't remember the exact number) Hz on fastest. On normal its 15.
Speaking on the function, as you can see, XOR is an irreversible operation. You would need to store the seed and, during replay loading, create an array of values for every time RNG triggers. The actual event should be then enriched by an integer value specifying the index of the RNG array element. Given that a typical SC game has maybe 100-1000 RNG triggerings, that is neglible. That is given SC2 uses RNG at all.
I've never said replay rewinding would be easy. The reverse algorithms for pathfinding could actually be extremely time-consuming, but I'm sure they are possible to implement.
EDIT: The more I'm thinking about this, the more actual data to store and handle I can see. However(!!!), since a game is 100% reconstructible using the replay data, any additional data would have to be calculated and loaded into memory during replay loading.
So, the ability to make replay rewind is machine-dependent, but, implemented or not, it won't affect replay file sizes at all.
On another note, replay rewinding is a cool feature, but it's not really needed. Instead, you could save complete game data for, say, every 5 minutes. That would be a nice compromise.
|
what I want from replays in future?
+ rewind (or maybe have a timeline bar we can scroll through, like with media players)
+ more stats
+ viewable from a player's perspective
+ replay with text
+ able to view/watch ums games properly (so i can watch games like macro/micro if theres something i wana learn)
+ no problem watching replays with future sc2 updates
+ autosave/autonaming feature (so you can save all replays, just refer back by date, map name, etc
+ ability to turn replay into movie easily? (maybe not quickly i guess, depending on processor, but it would be nice)
some of these i DID take from the WGT launcher, but it would be good to have those things without a separate program
|
One way to make rewind work that doesnt need anything added or changed with the replayfiles but is rather unefficient is:
Say you are at 75% game played and want to jump back to 50% game played. Then if you click 50% let the computer restart the replay counting actions from its start but not showing anything on the screen. Let the computer run the game hidden at 100x speed until it reaches 50% then go on as usual. This wouldnt actualy be rewinding just restarting and forwarding realy fast but it would give the illusion of rewinding. But since it isnt rewinding its realy easy to implement. You would have to wait a few seconds each time you want to rewind a bit though propebly ;e
Dont see this as a serious suggestion to how they should implement it in SC2 xD I hope they dont do it this way. I just wanted to show that even if they used the same type of replays as in SC1 it would still be possible.
|
On May 27 2007 13:37 vicml21 wrote:
what I want from replays in future?
+ rewind (or maybe have a timeline bar we can scroll through, like with media players)
+ more stats
+ viewable from a player's perspective
+ replay with text
+ able to view/watch ums games properly (so i can watch games like macro/micro if theres something i wana learn)
+ no problem watching replays with future sc2 updates
+ autosave/autonaming feature (so you can save all replays, just refer back by date, map name, etc
+ ability to turn replay into movie easily? (maybe not quickly i guess, depending on processor, but it would be nice)
some of these i DID take from the WGT launcher, but it would be good to have those things without a separate program
hm. It would be cool if they added a way if they added all the old versions of the game as some kind of mod so you can view old replays and play UMS maps that become bugged with new versions. I'm unsure how practical it would be however.
|
Also fixing a good first person view wouldnt be that hard. All you need is X,Y possition of the screen on the map for every frame and X,Y possition of the cursor for every frame. Thats 4 numbers per frame and doesnt have to sum up to too much. All the actions like key and mouse clicks are already in the replayfiles. In a 20 minutes long game there are 36000 frames if there are 30 frames per second. Possition on the map propebly doesnt have to be more accurate than 256x256 so one or a few byte each would do for them. Cursor possition would propebly need to be more accurate but a total of 8-20 bytes per frame would do I think. So that wouldnt have to add more than 1-2 MB to the filesize of a normal length 2 player game. You could always add it as an option you can turn of when you save the replay if you dont like the size.
|
Russian Federation4235 Posts
On May 27 2007 14:30 DrainX wrote:
Also fixing a good first person view wouldnt be that hard. All you need is X,Y possition of the screen on the map for every frame and X,Y possition of the cursor for every frame. Thats 4 numbers per frame and doesnt have to sum up to too much.
OMG, not again. Framerates are different on the machine saving replay and and the machine playing it.
All the actions like key and mouse clicks are already in the replayfiles.
No. No, no, no. Mouse clicks are not there. Actions are.
In a 20 minutes long game there are 36000 frames if there are 30 frames per second. Possition on the map propebly doesnt have to be more accurate than 256x256 so one or a few byte each would do for them. Cursor possition would propebly need to be more accurate but a total of 8-20 bytes per frame would do I think. So that wouldnt have to add more than 1-2 MB to the filesize of a normal length 2 player game. You could always add it as an option you can turn of when you save the replay if you dont like the size.
Again, not precisely true. Cursor position on variable resolutions is a slippery thing, since it's a sprite overlay, it's position is actually in global screen coordinates, while in-game coordinates in 3D are not tied to global. (much like the framerate isn't linked to game timer) Sure thing, it's scalable, but again, it's more logical to record cursor movement, not its absolute position.
|
On May 27 2007 14:44 BluzMan wrote:Show nested quote +On May 27 2007 14:30 DrainX wrote:
Also fixing a good first person view wouldnt be that hard. All you need is X,Y possition of the screen on the map for every frame and X,Y possition of the cursor for every frame. Thats 4 numbers per frame and doesnt have to sum up to too much. OMG, not again. Framerates are different on the machine saving replay and and the machine playing it. No. No, no, no. Mouse clicks are not there. Actions are. Show nested quote +In a 20 minutes long game there are 36000 frames if there are 30 frames per second. Possition on the map propebly doesnt have to be more accurate than 256x256 so one or a few byte each would do for them. Cursor possition would propebly need to be more accurate but a total of 8-20 bytes per frame would do I think. So that wouldnt have to add more than 1-2 MB to the filesize of a normal length 2 player game. You could always add it as an option you can turn of when you save the replay if you dont like the size. Again, not precisely true. Cursor position on variable resolutions is a slippery thing, since it's a sprite overlay, it's position is actually in global screen coordinates, while in-game coordinates in 3D are not tied to global. (much like the framerate isn't linked to game timer) Sure thing, it's scalable, but again, it's more logical to record cursor movement, not its absolute position.
Im not talking about the graphical framerate. Im talking about the rate at which the gameloop works. Also true that the clicks are not in the files... they would also have to be added but not keyboardclicks since they wouldnt show up anyway if they didnt cause an action. Even so mouseclicks would just add another bit saved to each frame(give it a better name then frame if you so please) 0 for no click 1 for click. And ofc the cursur could be saved as a scale like you say. I dont see how cursor movement would be better since the mouse moves all the time and the value of a possition would take up as much space as the value of a movement but I guess saving movement would be just as easy.
My point was that this was easy to implement and wouldnt take up all that much space. If you dont disagree with that then I dont understand what we are arguing about.
|
OK children this is a thread about replays NOT random number generation. If you lot want to check out the real deal on that it's on Numerical Recipes. Sorry to come across as arrogant but a lot of the programming comments made previously are just dumb and uninformed, so let's move on.
All the features discussed here except for reverse replays are very easy to code and won't clog up filesize, so we can only hope Blizzard adds them at least in a patch. The best idea to me so far is that of being able to jump in a replay. That'd be really cool.
Oh and displaying APM in-game would be a clear signal sent to the competitive community.
|
How about NO REPLAYS at all? Do you want the game to be ruined like they did to SC once they released the patch with replays so all of the average/noobs can learn from them? I believe its true sir.
|
On May 27 2007 22:33 DesOndaes wrote:
How about NO REPLAYS at all? Do you want the game to be ruined like they did to SC once they released the patch with replays so all of the average/noobs can learn from them? I believe its true sir.
Are you a troll?
I think there should be replays and they should be as good and have as many built in functions as possible without making the filesize too big. Helping new players learn is a good thing no?
|
On May 27 2007 22:33 DesOndaes wrote:
How about NO REPLAYS at all? Do you want the game to be ruined like they did to SC once they released the patch with replays so all of the average/noobs can learn from them? I believe its true sir.
I don't think that replays should be removed completely, but I think that there should be a check box, that only when all players in game check can a replay be saved. I think that a lot of replays from higher level players would go unsaved. It would be nice if not every player in the whole world played like boxer with really bad micro and macro.
|
|
|
|
|
|
EPT
