|
I trust other people more than myself to make Starcraft II a great game so screw the gameplay discussions from me.
But one thing that I was thinking about is how much polish you could add to the replays and observer modes. Let's make a list and send it to Blizzard?
Some ideas:
* More stats that only the observer can see.
Nr of kills are cute for the players but while watching a replay I'd be thrilled if I could bring up lists over the units with most kills and see other fun stats, like how much damage a unit has dealt or taken, how much minerals a probe have mined and how long a unit has been on the battlefield. I love to keep track of marines with high numbers of kills, perhaps even add in some visual markers (for example, the probe that has mined the most gets a little star selection for each player etc).
More random, cute and useless stats please!
* Free camera for replays! It migth start to lag if the observer goes crazy with camera angles but damn do I want to be able to zoom down over the shoulder of a Terran marine when the zerg horde comes down on him (you could do this in Ground Control btw and it was really neat).
* Ability to get the ammount of psi and minerals for all players on a scoreboard or similar in a replay or as an observer. Possibly also include APM.
* Ability to see mouseclicks and actions in replays.
* Included BWchart mass of stats and graphs and shit after game is finished.
A feature to collect all those stats for a player over his entire play time would be awsome as well. (Etc: Has built 63412 marines total or something).
* Top ten units when the game has finished based on how many points they helped bring in! 
Anyone else can think of more cute things?
|
Wouldnt that make the replay files be larger than it is now? Like maybe even a meg or so each replay.
|
It would definatley make the replays bigger for sure, but the idea of,
* Free camera for replays! It migth start to lag if the observer goes crazy with camera angles but damn do I want to be able to zoom down over the shoulder of a Terran marine when the zerg horde comes down on him (you could do this in Ground Control btw and it was really neat).
sounds really good.
|
camera angless? This isn't myth. I do think some of the stat stuff would be neato though.
|
Instead of a scoreboard of supply and resources, it could be as simple as clicking on a player's unit or building to see his current supplies.
|
so basically intergrate ob mode from bwl into sc2?
|
Osaka27149 Posts
i dont think replay size is really too much of an issue anyways in the era of broadband and 200gb harddrives
|
On May 20 2007 15:36 Manifesto7 wrote:
i dont think replay size is really too much of an issue anyways in the era of broadband and 200gb harddrives
Amen. I just bought one yesterday ;D Feels good to move from 40 GB to 200.
|
great thinking! this is important not just for us gamers, but for broadcasters as well.
the ability to zoom out further in obs/replay mode would be great too, but restrict gameplay to a certain maximum distance like wc3.
|
Anyone played Startrek Armada?
The camera work on that was pretty awesome.
|
That would be pretty sweet to have a free camera angle...
I've always wondered what it was like to be at ground level during one of those intense battles...latency of course would be an issue.
|
I don't see haw any of those idea would necessary change replay size. That is not information that has to be written in replay file, it just has to have every command and then sc2 process it. Does sc2 calculate apm or not is irrevelant to size of replay[...].
*reverse play in replay.
|
On May 20 2007 15:36 Manifesto7 wrote:
i dont think replay size is really too much of an issue anyways in the era of broadband and 200gb harddrives
Because of shitty monopolistic telephone company I have to change 512kb down to 256kb I go fucking lower and lower whit time, that piss me off so much.
|
The camer stuff might be already implemented... just watch the WWI presentation - he paused the game and rotatet the camera right? As long as this isn't possible in normal games I'm a very happy boy.
|
On May 20 2007 16:11 Polis wrote:
I don't see haw any of those idea would necessary change replay size. That is not information that has to be written in replay file, it just has to have every command and then sc2 process it. Does sc2 calculate apm or not is irrevelant to size of replay[...].
What I would really like to see is reverse play in replay.
Reverse play in replay would be technically impossible due to the way replays work. Replays work by saving all the commands done by the players and then it replays the game using those. This is also the reason why you could show all kinds of fancy stats and camera angles in a replay without affecting replay size at all.
However since all the stored information is just commands you can't effectively reverse it. In order to reverse it you would have to store all game state data in some kind of file and that file would become freaking huge.
|
thedeadhaji
39489 Posts
I will be sad if communal replay watching ceases to exist, much like in war3
|
Since most of you are not familiar with GGC and WaaaghTV I'll give a few examples:
On-screen display (in chat section):
<<xxx trains yyy>>
<<xxx researches yyy>>
Where xxx is the name of the player (like he would say it but only obs/refs can see it) and yyy is unit type (appears only first time certain unit is being trained) or the name of the upgrade.
It makes obsing so much easier, you don't have to watch everything and you're kept up to date with everything (there's also an option to disable this).
Dunno if it was in SC (wasn't obsing much there) but when you click on a players unit/building it shows his current resources and pop.
Simple stuff like that, no need for some super detailed info since it could make obsing a bit hard, maybe the chart being more advanced.
|
All the silly stats would ofcourse be optional stuff that you can turn on/off
|
On May 20 2007 16:18 Zironic wrote:
However since all the stored information is just commands you can't effectively reverse it. In order to reverse it you would have to store all game state data in some kind of file and that file would become freaking huge.
That is so many information? It would have to be unit location/unit death/building death/cancel building/bullet location everything that can mess whit patchfiding/action of unit building it could be added to temporary replay that is deleted after you watched game. Maybe it is more then I think through or programming would be big task, maybe it would take to much cpu power but that is doubtful as it is not that many actions.
|
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.
|
One thing I stil miss REALLY much from the short BWTV period was the minerals per minute (MPM) statistics for the different players.
|
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.
you could save the complete game-data every 10 seconds or so. You could only reverse/fast forward to even 10 seconds, but that would be enough, and it shouldn't take TOO much memory (hopefully).
|
The gamestate data would be as big as a savegame, I don't know how big those are (Doesn't have any saves), feel free to make a save game in WC3 or Starcraft and look at the filesize. You could probably add somekind of autosave feature when playing a replay with a toggle for how often. Every minute or so would probably be the most reasonable.
|
If you need fewer you could make dynamic times based on "hotpoints" or something like that. Like save before major battles etc.
Or you could make the replay to play at like 100x speed without drawing any graphics. So when you place the seeker at a time maybe 2 minutes after the latest stored time-point, you could make the replay go back to the closest stored point and play the game on it's own without drawing any graphics. probably it could do that pretty fast. You would have to wait a second or two every time you use the time-seeker, but that shouldn't be a big problem.
God, I should have become a game-developer instead of stupid physics!! 
|
Without any graphics the game should be able to play as fast as the CPU allows and if you got a fancy quad core cpu or whatever is the best when SC2 is released you can probably fast forward damn fast.
|
On May 20 2007 16:18 thedeadhaji wrote:
I will be sad if communal replay watching ceases to exist, much like in war3
this is so true. Watching wc3 replays by your self = boring fest.
|
Audioreplays are fairly interesting, I've never actually done any communal replay watching so I suppose my opinion is null and void.
|
One thing ive been thinking about... if the replays only contain the players commands then the game has to be completly deterministic for the replay to always be the same as the game. But say you fire with a tank against higher ground and there is a set chance that you miss... how is this handled in replays? Or do they just use something like milliseconds into the game as seed for the randomizer so it always turns out the same way ?
|
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.
|
you should be able to see where a player's mouse is, would definitely be helpful for specs if they were aware whether or not a player has missed an attack
|
On May 20 2007 15:36 Manifesto7 wrote:
i dont think replay size is really too much of an issue anyways in the era of broadband and 200gb harddrives
200 GB huh...My desktop at home is rockin w/ the 20 GB 
|
Sweden33719 Posts
On May 20 2007 17:08 Zironic wrote:
Audioreplays are fairly interesting, I've never actually done any communal replay watching so I suppose my opinion is null and void.
Realllllly? One of the most enjoyable things in SC for me has always been kicking back late night with some nice replays and a bunch of friends/friend.
Also nice for teaching or showing someone something.
|
Really hope they keep more of a SC replay system than the WC3 one
|
Lets keep things so that they can still run on non-suped up computers.
|
I like most of your ideas, however reps would be like so big, but maybe blizzard could think of something, i like your thoughts
|
-rewind
-zoom/change angle
those are 2 features which stick out to me
|
On May 20 2007 21:11 XDawn wrote:
Lets keep things so that they can still run on non-suped up computers.
I bought my computer two years ago for $800
It has a 300 gb hd
Radeon x1300 512 mb graphics card
2 GB of ram
And it's a factory made gateway -_-
Just use your tax refund if you get one to buy something like this for about 500$ now.
|
Time to add my 2 cents...(as a programming/amature game designer)
1) It would not increase the file size of the replays. Take for example a microsoft word document. You can see at all times the number of words in the document. You think that this information is stored in a .doc file? No its not. It is calculated at runtime. Same thing for no of kills etc in a replay. BWChart etc calculate how many marines have been built and display it. Adding any stats about a replay would not increase its filesize.
2) Computers perform well over 8 million actions per second. That was a stastic from like 5 years ago. You really think a hud displaying numebr of kills etc would struggle? Not 1 bit.
RTS games are not very cpu intensive. In fact the only part of a RTS that is intensive is the AI. and replays don't run ai.. all the enemys 'moves' are stored just like yourown. Because their is no AI script running their is a massive ammount of unused potential which would be put to good use displaying this kind of information.
And as for Observer mode, every time a unit dies all players are updates with this information. So far as code goes its player1kills=player1kills+1 kinda stuff.
Their is no chance that any stats or extra ingame hud information would slow the game down.
(BTW.. has blizz confirmed replay features? Also are their replays in WC3? never really played it)
|
On May 20 2007 15:37 Zeenix wrote:Show nested quote +On May 20 2007 15:36 Manifesto7 wrote:
i dont think replay size is really too much of an issue anyways in the era of broadband and 200gb harddrives Amen. I just bought one yesterday ;D Feels good to move from 40 GB to 200.
Oh darnit My comp only has what... 12G? Lol I'm so behind...
|
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...
|
Counter-Strike has had all sorts of demo features including rewind and choosing any angle and it was made a long time ago. The demos are bigger than SC's but they're extremely compressible.
|
Are you sure that Counter-Strike has rewind?
Anyhow Counter-Strike includes ALOT less information then starcraft, 10 units vs 300 anyone?
|
On May 21 2007 05:25 Zironic wrote:
Are you sure that Counter-Strike has rewind?
Anyhow Counter-Strike includes ALOT less information then starcraft, 10 units vs 300 anyone?
but it's 3D..
|
Heh, yes, I'm quite sure. Unlike others, I don't speak about subjects I know nothing about. The thing is, the 'vcr' tab of CS was implemented so many years ago and has made CS even more spectator friendly than it already is and has also made it extremely easy to make movies (so many thousands of CS movies...). So if Blizz can't do it in 2007...well, that's too bad.
|
It'll be recordable, it can probably have all kinds of nifty features, but I don't think rewinding will be one of them.
|
Taiche
France1963 Posts
As someone who has been playing a bit with replays' internal format, here's my 2 cents :
1) please version replays correctly -_-; Not being able to find out which version of the exe was needed to run a replay is a pain the ass. And please don't "support" it like in War3 (old replays can simply not be loaded... thanks !). Real versioning with real backward compatibility would be much appreciated !
2) insert minimap in replay like in War3 OR provide native tools/libraries to let third-party applications make their own (even simple documentation will do). We had a rough time figuring out how to generate a minimap from raw data with RepASM/ReXplorer and I don't want to run into this again (this point is somewhat related to point 6 ; see below)
3) same, insert the actual map into the replay. The way this is handled in Warcraft III is completely stupid IMHO. People must download/copy the actual map to the right directory before seeing a replay ? Please no. Now, I understand this can be difficult if maps are large files (i.e. 3MB+) because that might be the case but PLEASE think of something handy.
4) yeah, stats are fun and nice, add some during actual replay ! Providing an external application to display some charts would be great as well (but I guess we can make our own anyway ;p )
5) like in War3, make it so double-clicking on a replay launches the game with replay loaded. I know it's a very basic and easy-to-implement feature and it's soooo useful for the end-users.
6) adding metadata to a replay. This is a more generic version of point #2. The idea is to provide some room or make the format so that people can insert safely any type of data : images, text, audio... That way, third-party apps would be able to plug into the replay without messing around the whole system. See RWA/RWT/FPREPs implementations for example, where the extra data were just appended at the end of the file -_-;
7) yeah, rewinding would be great but I don't know how doable this is.
Now, for something a bit further than the point #6... maybe provide interfaces/SDK/scripting system so people can make legal plugins for SC ? But this is a bit off-topic anyway
|
As long as you can watch all opponents with their stats at the same time I'm happy. In war3 you could only see one or all but then you could't see the stats of a specific player (If I remember correctly).
|
On May 20 2007 21:18 DeCoup wrote:
Time to add my 2 cents...(as a programming/amature game designer)
1) It would not increase the file size of the replays. Take for example a microsoft word document. You can see at all times the number of words in the document. You think that this information is stored in a .doc file? No its not. It is calculated at runtime. Same thing for no of kills etc in a replay. BWChart etc calculate how many marines have been built and display it. Adding any stats about a replay would not increase its filesize.
2) Computers perform well over 8 million actions per second. That was a stastic from like 5 years ago. You really think a hud displaying numebr of kills etc would struggle? Not 1 bit.
RTS games are not very cpu intensive. In fact the only part of a RTS that is intensive is the AI. and replays don't run ai.. all the enemys 'moves' are stored just like yourown. Because their is no AI script running their is a massive ammount of unused potential which would be put to good use displaying this kind of information.
And as for Observer mode, every time a unit dies all players are updates with this information. So far as code goes its player1kills=player1kills+1 kinda stuff.
Their is no chance that any stats or extra ingame hud information would slow the game down.
(BTW.. has blizz confirmed replay features? Also are their replays in WC3? never really played it)
You are full of shit everywhere.
Replays DO use the AI. Replays are just a list of player commands, and the AI takes care of pathing, etc.
|
On May 21 2007 04:34 DrainX wrote:Show nested quote +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.
___________________________________________________
Ontopic:
It would be great if you in the bottom right could show whats building in all the barracks, etc. just a small icon of a marine, and completion bars.
Also a occupied time - idle time ratio for each production building (especially CCs!!) would be fun. That would be a better (note: not the ultimate! ) measurement of macro-skills than just APM.
|
More things:
* Option to reccord audio straigth to replay (this would only apply for the rep saved at your computer naturally. ^_^). Also option to add soundtrack to existing rep!
* Super broadcast mode. Only avalible in LAN enviroment for full use of all options (or when the internet connections have super good connections).
Saves the replay as well as VODs from all active players in an intregrated manner. Includes audiotracks (possibly from all players and the main observer). If you want you can have "slave" observers that has teamspeak to the main observer so they can tell him were the action is at, or which can toggle statistics. The main observer is able to switch between his own screen or first person view of the active players screen (FPS mode).
This mode should also be able to generate a videostream of the main observers screen that is separate of the game (this should be avalible even if the connection is to weak to allow FPS view of all players for example so that you only get the observer).
OK that's just wishfull thinking but GOD DAMN would it be nice. Can you imagine the ammount of broadcasted leauge games we would get? Like every final. ^_^
|
On May 21 2007 06:46 ofclean wrote:Show nested quote +On May 20 2007 21:18 DeCoup wrote:
Time to add my 2 cents...(as a programming/amature game designer)
1) It would not increase the file size of the replays. Take for example a microsoft word document. You can see at all times the number of words in the document. You think that this information is stored in a .doc file? No its not. It is calculated at runtime. Same thing for no of kills etc in a replay. BWChart etc calculate how many marines have been built and display it. Adding any stats about a replay would not increase its filesize.
2) Computers perform well over 8 million actions per second. That was a stastic from like 5 years ago. You really think a hud displaying numebr of kills etc would struggle? Not 1 bit.
RTS games are not very cpu intensive. In fact the only part of a RTS that is intensive is the AI. and replays don't run ai.. all the enemys 'moves' are stored just like yourown. Because their is no AI script running their is a massive ammount of unused potential which would be put to good use displaying this kind of information.
And as for Observer mode, every time a unit dies all players are updates with this information. So far as code goes its player1kills=player1kills+1 kinda stuff.
Their is no chance that any stats or extra ingame hud information would slow the game down.
(BTW.. has blizz confirmed replay features? Also are their replays in WC3? never really played it) You are full of shit everywhere. Replays DO use the AI. Replays are just a list of player commands, and the AI takes care of pathing, etc.
he meant AI as the strategical, instead-human-player AI
|
On May 21 2007 08:54 freelander wrote:Show nested quote +On May 21 2007 06:46 ofclean wrote:On May 20 2007 21:18 DeCoup wrote:
Time to add my 2 cents...(as a programming/amature game designer)
1) It would not increase the file size of the replays. Take for example a microsoft word document. You can see at all times the number of words in the document. You think that this information is stored in a .doc file? No its not. It is calculated at runtime. Same thing for no of kills etc in a replay. BWChart etc calculate how many marines have been built and display it. Adding any stats about a replay would not increase its filesize.
2) Computers perform well over 8 million actions per second. That was a stastic from like 5 years ago. You really think a hud displaying numebr of kills etc would struggle? Not 1 bit.
RTS games are not very cpu intensive. In fact the only part of a RTS that is intensive is the AI. and replays don't run ai.. all the enemys 'moves' are stored just like yourown. Because their is no AI script running their is a massive ammount of unused potential which would be put to good use displaying this kind of information.
And as for Observer mode, every time a unit dies all players are updates with this information. So far as code goes its player1kills=player1kills+1 kinda stuff.
Their is no chance that any stats or extra ingame hud information would slow the game down.
(BTW.. has blizz confirmed replay features? Also are their replays in WC3? never really played it) You are full of shit everywhere. Replays DO use the AI. Replays are just a list of player commands, and the AI takes care of pathing, etc. he meant AI as the strategical, instead-human-player AI
Some people are a bit hasty with their namecalling I think...
|
On May 20 2007 16:18 thedeadhaji wrote:
I will be sad if communal replay watching ceases to exist, much like in war3
I agree 100%
|
On May 21 2007 08:49 CuddlyCuteKitten wrote:
More things:
* Option to reccord audio straigth to replay (this would only apply for the rep saved at your computer naturally. ^_^). Also option to add soundtrack to existing rep!
* Super broadcast mode. Only avalible in LAN enviroment for full use of all options (or when the internet connections have super good connections).
Saves the replay as well as VODs from all active players in an intregrated manner. Includes audiotracks (possibly from all players and the main observer). If you want you can have "slave" observers that has teamspeak to the main observer so they can tell him were the action is at, or which can toggle statistics. The main observer is able to switch between his own screen or first person view of the active players screen (FPS mode).
This mode should also be able to generate a videostream of the main observers screen that is separate of the game (this should be avalible even if the connection is to weak to allow FPS view of all players for example so that you only get the observer).
OK that's just wishfull thinking but GOD DAMN would it be nice. Can you imagine the ammount of broadcasted leauge games we would get? Like every final. ^_^
Oh, I love this idea! It would generate EXTREMELY sweet replays! To the extent that people would quit playing the game and just watch these reps.
Blizzard is taking notes, yes?
|
On May 21 2007 07:29 Cascade wrote:Show nested quote +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 or some other state of the computer 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. You said it yourself, computers are completly deterministic and so if you give them the same input they will always return the same output.
|
United States12235 Posts
On May 20 2007 15:29 CuddlyCuteKitten wrote:
* Free camera for replays! It migth start to lag if the observer goes crazy with camera angles but damn do I want to be able to zoom down over the shoulder of a Terran marine when the zerg horde comes down on him (you could do this in Ground Control btw and it was really neat).
I don't understand what this means. Camera angles wouldn't be saved into the replay file or broadcasted to other players. The only one experiencing an FPS hit would be you.
|
United States4991 Posts
On May 21 2007 10:06 DrainX wrote:Show nested quote +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.
|
I'd rather make the minimum cpu specs sky high than gimp the game because somebody with a 1ghz machine wants to be able to play.
Buying a decent computer isn't expensive. Buying a top of the line one is, but you don't need top of the line to play most games. All it takes is a decent video card, above average RAM, and a solid CPU. You can probably get that for like $700-800 TOPS and be able to run anything on the market.
|
On May 21 2007 10:08 Excalibur_Z wrote:Show nested quote +On May 20 2007 15:29 CuddlyCuteKitten wrote:
* Free camera for replays! It migth start to lag if the observer goes crazy with camera angles but damn do I want to be able to zoom down over the shoulder of a Terran marine when the zerg horde comes down on him (you could do this in Ground Control btw and it was really neat). I don't understand what this means. Camera angles wouldn't be saved into the replay file or broadcasted to other players. The only one experiencing an FPS hit would be you.
I was thinking more that if the game isn't optimized for free camera angles (no reason for it) a couple of observers zooming around wildly could perhaps lag their computers and thus the other players in an online game.
In a replay it doesn't matter because your the only one watching so you can do what you want with the camera.
|
On May 21 2007 10:22 CuddlyCuteKitten wrote:Show nested quote +On May 21 2007 10:08 Excalibur_Z wrote:On May 20 2007 15:29 CuddlyCuteKitten wrote:
* Free camera for replays! It migth start to lag if the observer goes crazy with camera angles but damn do I want to be able to zoom down over the shoulder of a Terran marine when the zerg horde comes down on him (you could do this in Ground Control btw and it was really neat). I don't understand what this means. Camera angles wouldn't be saved into the replay file or broadcasted to other players. The only one experiencing an FPS hit would be you. I was thinking more that if the game isn't optimized for free camera angles (no reason for it) a couple of observers zooming around wildly could perhaps lag their computers and thus the other players in an online game. In a replay it doesn't matter because your the only one watching so you can do what you want with the camera.
Since observers arn't actually expected to send any worthwhile information to the host (The only thing they could send is chat) they should be able to lag their asses off without affecting the game itself.
|
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.
|
On May 27 2007 16:45 MyLovelyLurker wrote:
Oh and displaying APM in-game would be a clear signal sent to the competitive community.
Indeed.
|
I'm too lazy to read the whole thread to see if someone already said this, so here goes:
As an observer, I'd like to be able to select a building and see what it's doing. At the moment, selecting it just gives you a stats display about the building itself, but it wouldn't be too hard to give the observer a look at the unit queue or current upgrade.
|
On May 20 2007 15:31 XCetron wrote:
Wouldnt that make the replay files be larger than it is now? Like maybe even a meg or so each replay.
If you have limited space then it should have an options page where you can turn stuff on/off.
|
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. That is one KICK ASS idea!
|
On May 28 2007 18:47 ubergamer15 wrote:
I'm too lazy to read the whole thread to see if someone already said this, so here goes:
As an observer, I'd like to be able to select a building and see what it's doing. At the moment, selecting it just gives you a stats display about the building itself, but it wouldn't be too hard to give the observer a look at the unit queue or current upgrade.
That's implemented already in WC3 I think so it's almost guaranteed to be in SC2.
|
On May 28 2007 14:47 Element)LoGiC wrote:Show nested quote +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.
Worst idea I've heard yet, hackers would have a field day with that.
|
I think they should bring the action camera mode from WC3, it automatically moves the camera to where ever the action is. I also want them to bring the ctrl+c replay feature from WC3 that automatically centers the camera on whatever the player is clicking on, it's the closest thing to player view, and they should add a checkbox that spams that.
|
On May 20 2007 15:34 dropthesky wrote:
camera angless? This isn't myth. I do think some of the stat stuff would be neato though.
yep, gogo, every "Player" of this type gogo to sc2, sc:bw will be purged, hell, will make it even a better game
|
THERE SHOULD BE NO MORE REPLAY CORRUPTION! why hasn't anyone mentioned this!? that's the only thing that bugs me about bw. perhaps a 1.15 sc2 would run a 1.14 sc2 rep in an emulated 1.14 sc2 engine or something? but i know nothing of programming, so i have no idea how feasible this is.
|
You can't guarantee replays won't be corrupt with the current save player actions and replay player actions idea. You could provide an engine for each patch though. Automatically.
|
On May 20 2007 16:18 Zironic wrote:
Reverse play in replay would be technically impossible due to the way replays work. Replays work by saving all the commands done by the players and then it replays the game using those. This is also the reason why you could show all kinds of fancy stats and camera angles in a replay without affecting replay size at all.
However since all the stored information is just commands you can't effectively reverse it. In order to reverse it you would have to store all game state data in some kind of file and that file would become freaking huge.
This is a common misconception. Yes, replays do work by recording commands as they were issued, then playing them back, but that does not mean it's impossible for the game to reverse a replay without storing additional data.
There's an easy way and a hard way to solve the problem.
The easy way: Automatically store autosaves of the game as the replay progresses. When the user wants to go to an earlier point in the replay, the game loads the closest autosave and then replays the same forward until it reaches the right point.
Upside: The user can jump back almost instantly to any point in the replay and forward to as far as they've watched so far.
Downside: You can't scrub the replay forward and back. Replaying back would cause a short pause. Also, this method requires streaming autosaves so that the game can save regularly without causing the game to hitch.
This is the method used on development for CoD2 and CoD4. We can jump back and forward even though we're using the same method of storing commands and playing them back.
The hard way:
Instead of writing out autosaves in chunks, you could stream the history of the game out into one file. When you put the replay in reverse, the game plays the unit history backwards.
Upside: You can scrub back and forth like a video tool, which would make for some very nice examinations of cool moments.
Downside: You could only jump forward/back as fast as the game can simulate, but this would probably still be fairly quick. This method would require less significantly streaming since it's just writing the history at server framerate, rather than writing a complete snapshot every X number of seconds.
The first method is the brute force method, which is why its easier. The second method would take more work to make it not be fragile, but would be easier to make play smoothly.
Replaying back is not an unsolvable problem. I hope Blizz'll at least take a stab at it.
|
The second metod would create a very large file, because it would need to save every unit attack, death and whatever, in order to be able to reverse it.
|
On June 09 2007 15:50 lololol wrote:
The second metod would create a very large file, because it would need to save every unit attack, death and whatever, in order to be able to reverse it.
Very large is relative. Even if a long game generated a 1 gig file, it wouldn't matter with today's hard drives, especially since the file would be cleared when you quit the game or load a new replay.
|
make obs mode and replay mode be able to see more of the screen than the standard in-game screen size. ideally, the whole map or close to it at the same time and be able to zoom in. future broadcasting will most likely be done from multiple screens so while on broadcasting screen is looking at the map, the others are going through the bases and looking at things. still another might be following each player in a FPVOD sort of way.
|
|
|
|
|
|
EPT
