EPTReplay Rewind - a second look - Page 7
| Forum Index > SC2 General |
|
marshmallow
United States93 Posts
| ||
|
Tyraz
New Zealand310 Posts
On August 25 2009 05:53 alt.tday wrote: they should just record the video, not every action lol, good one :p | ||
|
Polis
Poland1292 Posts
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. | ||
|
lazz
Australia3119 Posts
| ||
|
WolfStar
United Kingdom155 Posts
Sorry if this was answered already but it's a long thread.. | ||
|
DeCoup
Australia1933 Posts
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. | ||
|
EmS.Radagast
Israel280 Posts
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. | ||
|
DeCoup
Australia1933 Posts
| ||
|
EmS.Radagast
Israel280 Posts
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. | ||
|
WolfStar
United Kingdom155 Posts
Ah the mighty computer is unable to just pick a number lol | ||
|
hixhix
1156 Posts
On August 26 2009 20:43 DeCoup wrote: 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. | ||
|
lowlypawn
United States241 Posts
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 | ||
|
agorist
United States115 Posts
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. | ||
|
dnosrc
Germany454 Posts
| ||
| ||
