|
On April 02 2009 02:13 Day[9] wrote:
i'd imagine it's possible, but that it would be profoundly difficult.
the main reason Braid hasn't been released on a computer is due to hardware issues. Though the graphics look cartoonish and low level, the game demands such an insane amount of memory due to having to record the game state for that awesome "rewind" function. Without a super tripped out computer, you'd be living in frown town.
That said, I'm still curious how much memory/processing power a rewind function would ACTUALLY demand (because I'm a mathematician and <3 complexity theory hahaha). MIT just came out with a 1000ghz processor. Now they just need to hop on 1000gb of ram hahaha.
Consoles aren't as powerfull as modern computers.
|
Sweden33719 Posts
On April 01 2009 18:53 meegrean wrote:
I just don't want replays to take up a shitload of space like those Warcraft 3 ones.
.. WC3 replays are the same size as BW replays. Latest game I played (a 2v2) was 69kb.
Yo DO need to have the map the game is played on tho, which is ANNOYING AS FUCK. I'd much rather have reps be 300-500 kb (come on, it's 2009) than having to have every fucking version, every new map..
|
On April 02 2009 04:21 FrozenArbiter wrote:Show nested quote +On April 01 2009 18:53 meegrean wrote:
I just don't want replays to take up a shitload of space like those Warcraft 3 ones. .. WC3 replays are the same size as BW replays. Latest game I played (a 2v2) was 69kb. Yo DO need to have the map the game is played on tho, which is ANNOYING AS FUCK. I'd much rather have reps be 300-500 kb (come on, it's 2009) than having to have every fucking version, every new map..
It's even better if players can choose to save a replay with or without map
|
On April 02 2009 04:21 FrozenArbiter wrote:Show nested quote +On April 01 2009 18:53 meegrean wrote:
I just don't want replays to take up a shitload of space like those Warcraft 3 ones. .. WC3 replays are the same size as BW replays. Latest game I played (a 2v2) was 69kb. Yo DO need to have the map the game is played on tho, which is ANNOYING AS FUCK. I'd much rather have reps be 300-500 kb (come on, it's 2009) than having to have every fucking version, every new map..
If I remembered correctly, Starcraft replys won't work if there are triggers in play. Warcraft 3 however has fixed that problem, and if all those replys included the map, it would be massive, because alot of custom maps are over 3 to 4 MB.
Might not be a problem today through as most people has lot bigger drives.
|
On April 02 2009 02:13 Day[9] wrote:
i'd imagine it's possible, but that it would be profoundly difficult.
the main reason Braid hasn't been released on a computer is due to hardware issues. Though the graphics look cartoonish and low level, the game demands such an insane amount of memory due to having to record the game state for that awesome "rewind" function. Without a super tripped out computer, you'd be living in frown town.
That said, I'm still curious how much memory/processing power a rewind function would ACTUALLY demand (because I'm a mathematician and <3 complexity theory hahaha). MIT just came out with a 1000ghz processor. Now they just need to hop on 1000gb of ram hahaha.
The main reason Braid hasn't been released for PC yet is because its developer fails at programming.
And doesn't the xbox 360 only have like 512mb of ram anyway?
On April 02 2009 04:43 hixhix wrote:Show nested quote +On April 02 2009 04:21 FrozenArbiter wrote:On April 01 2009 18:53 meegrean wrote:
I just don't want replays to take up a shitload of space like those Warcraft 3 ones. .. WC3 replays are the same size as BW replays. Latest game I played (a 2v2) was 69kb. Yo DO need to have the map the game is played on tho, which is ANNOYING AS FUCK. I'd much rather have reps be 300-500 kb (come on, it's 2009) than having to have every fucking version, every new map.. It's even better if players can choose to save a replay with or without map
Just include the map if it's not played on a standard map and if the size is reasonable. Some tourney maps in WC3 have insane file sizes because of ingame ads.
|
Bill307
Canada9103 Posts
On April 02 2009 05:09 furymonkey wrote:Show nested quote +On April 02 2009 04:21 FrozenArbiter wrote:On April 01 2009 18:53 meegrean wrote:
I just don't want replays to take up a shitload of space like those Warcraft 3 ones. .. WC3 replays are the same size as BW replays. Latest game I played (a 2v2) was 69kb. Yo DO need to have the map the game is played on tho, which is ANNOYING AS FUCK. I'd much rather have reps be 300-500 kb (come on, it's 2009) than having to have every fucking version, every new map.. If I remembered correctly, Starcraft replys won't work if there are triggers in play.
They can work just fine. E.g. Team Micro Melee replays work fine.
Afaik, the only things you can't use are the "Elapsed Time" trigger and the "Wait" action (which will break replays if you change their playback speed), but they are largely unnecessary, anyway.
|
Think it would be easier to just have a replay to avi converter type.
|
On April 02 2009 08:36 ocoini wrote:
Think it would be easier to just have a replay to avi converter type.
and which part of the map the screen focus on? :S
|
On April 01 2009 02:08 tec27 wrote:Show nested quote +On April 01 2009 01:50 Ingenol wrote:On March 31 2009 22:57 nataziel wrote:
What if, as the replay was played it wrote the locations/status of everything to your ram, so you could feasibly rewind, but you'd have to have watched it first (or at least the actions would have to have been carried out, whether you've seen them or not). This way doesn't increase the actual size of the replay that you download, as the rewind gamestate data is temporarily created in your ram each time you watch the replay. With today's ram sizes (4 gig of ram is probably pretty standard these days right?) and read/write speeds this shouldn't be too much of a problem yeah?
This could feasibly be combined with checkpoints, but only ones that rely on a system of the game actions up to that point being played quickly without graphical output (something that won't increase replay size). If it relied on saving an actual game state every x seconds and going from there it would not work as the actions and state of every part of the game is not being played through to be cached (is that the right word?)
Disclaimer:
I dunno if this is going to make any sense whatsoever, as I have no knowledge of programming (except very limited HTML) or if this even has anything to do with programming. Feedback plz I have always wondered if this is possible. Can someone with programming experience comment on its feasibility. From the small .rep file you would then create a much larger amount of information that would then allow you to go backwards, having complete game states at many intervals along the way. You'd have to do it at a set (and fairly large) interval, or it'd be far, far too much data. As I said in a previous post, in SC1, each unit takes 336 bytes to store. So at 200/200 supply for 2 players (not an exact measurement, obviously, but I think that accounts for things like keeping track of minerals, buildings, and critters), thats 400 units * 336 bytes = ~130 KB per state. If we stored states per frame, that'd be about 3MB per second of data, which is obviously far too high. If we knock the state time up to every minute, then its around 2.5MB per 20 minute game, which is definitely more acceptable. SC2 probably has more data per unit/building/whatever though, so thats an important consideration, but storing the complete game state every minute is certainly reasonable (assuming its done dynamically as you watch the replay).
NOTE: THIS DOES NOT INCREASE THE SIZE OF THE REPLAYS, SO DON'T BITCH TO ME ABOUT THAT, REPLAYS WILL BE THE SAME SIZE AS USUAL. (not directed at tec, but idiots who can't read)
Umm, there's something wrong with your maths dude. Say the game runs at a smooth 60fps, that's 130KB*60*60 = 468000KB = 468MB/Minute, which is definitely too much. BUT, if you save the state every second you get 130KB*60=7800KB=7.8MB/minute. If you said the average game was 20 minutes long, you get 7.8MB*20=156MB/game. You could definitely go bigger if you want to, every quarter second = 624MB/game.
Considering ram sizes these days runs up to 4GB+ there's no reason this isn't feasable. Note that this doesn't increase the actual size of the replay, as this data is created as the replay is played. The state is saved every second and held in the ram until you finish watching the replay, you don't get a very smooth rewind, but a functional rewind for sure. The only thing I could think of that would limit this is the time it takes to load the game states, and I don't really know how to fix that problem. This could be combined with the idea of checkpoints by playing the replay with no graphical output at x5million speed (slight exageration possible) and saving the states into the ram at the same time (which I admit would probably bottleneck the speed at which the replay could be played at)
Maybe you could elect to have rewind turned on or off when you start the replay, rewind on it works like I said, rewind off it works like a normal replay.
|
On April 02 2009 10:57 nataziel wrote:Show nested quote +On April 01 2009 02:08 tec27 wrote:On April 01 2009 01:50 Ingenol wrote:On March 31 2009 22:57 nataziel wrote:
What if, as the replay was played it wrote the locations/status of everything to your ram, so you could feasibly rewind, but you'd have to have watched it first (or at least the actions would have to have been carried out, whether you've seen them or not). This way doesn't increase the actual size of the replay that you download, as the rewind gamestate data is temporarily created in your ram each time you watch the replay. With today's ram sizes (4 gig of ram is probably pretty standard these days right?) and read/write speeds this shouldn't be too much of a problem yeah?
This could feasibly be combined with checkpoints, but only ones that rely on a system of the game actions up to that point being played quickly without graphical output (something that won't increase replay size). If it relied on saving an actual game state every x seconds and going from there it would not work as the actions and state of every part of the game is not being played through to be cached (is that the right word?)
Disclaimer:
I dunno if this is going to make any sense whatsoever, as I have no knowledge of programming (except very limited HTML) or if this even has anything to do with programming. Feedback plz I have always wondered if this is possible. Can someone with programming experience comment on its feasibility. From the small .rep file you would then create a much larger amount of information that would then allow you to go backwards, having complete game states at many intervals along the way. You'd have to do it at a set (and fairly large) interval, or it'd be far, far too much data. As I said in a previous post, in SC1, each unit takes 336 bytes to store. So at 200/200 supply for 2 players (not an exact measurement, obviously, but I think that accounts for things like keeping track of minerals, buildings, and critters), thats 400 units * 336 bytes = ~130 KB per state. If we stored states per frame, that'd be about 3MB per second of data, which is obviously far too high. If we knock the state time up to every minute, then its around 2.5MB per 20 minute game, which is definitely more acceptable. SC2 probably has more data per unit/building/whatever though, so thats an important consideration, but storing the complete game state every minute is certainly reasonable (assuming its done dynamically as you watch the replay). NOTE: THIS DOES NOT INCREASE THE SIZE OF THE REPLAYS, SO DON'T BITCH TO ME ABOUT THAT, REPLAYS WILL BE THE SAME SIZE AS USUAL. (not directed at tec, but idiots who can't read) Umm, there's something wrong with your maths dude. Say the game runs at a smooth 60fps, that's 130KB*60*60 = 468000KB = 468MB/Minute, which is definitely too much. BUT, if you save the state every second you get 130KB*60=7800KB=7.8MB/minute. If you said the average game was 20 minutes long, you get 7.8MB*20=156MB/game. You could definitely go bigger if you want to, every quarter second = 624MB/game. Considering ram sizes these days runs up to 4GB+ there's no reason this isn't feasable. Note that this doesn't increase the actual size of the replay, as this data is created as the replay is played. The state is saved every second and held in the ram until you finish watching the replay, you don't get a very smooth rewind, but a functional rewind for sure. The only thing I could think of that would limit this is the time it takes to load the game states, and I don't really know how to fix that problem. This could be combined with the idea of checkpoints by playing the replay with no graphical output at x5million speed (slight exageration possible) and saving the states into the ram at the same time (which I admit would probably bottleneck the speed at which the replay could be played at) Maybe you could elect to have rewind turned on or off when you start the replay, rewind on it works like I said, rewind off it works like a normal replay.
There's nothing wrong with my math. SC1 takes 42ms per game frame on fastest. Keep in mind that the game frame is not necessarily the same as the drawn frame, but rather the time between updates of each unit/item. I never said you couldn't save states at a faster rate, I merely suggested an interval that I thought would be reasonable (honestly, the smallest interval you'd probably ever need is 15 seconds, why exactly would you need finer precision?). You failed to consider a couple things in your suggestions, though: First, the game is probably already taking a decent portion of the ram for the stuff it needs to do, we don't want to be taking out 150-600 megs for something thats going to be used like 5 times per replay. Second, not everyone who plays the game will have 4GB of ram, or even 2GB, and we can't assume they will. Third, we need this method to work for not only 20 minute games, but 3 hour games as well, and also for more than just 2 players. My estimations are undoubtedly on the low side of it, and so you have to take that into account. So yeah, I think maybe every 15 seconds would be a reasonable interval to save states, but every second or quarter seconds is out of the question.
|
You guys are not even considering the CPU issue as well for this brute force approach you're considering. Not only there's the obvious memory problem tec27 talks about and which will prolly be even worse on sc2 (such as maybe using 8 byte double floats for position for example). But you guys are also completely ignoring the cpu. Recording 60fps of all that data would be a heavy slow down for any popular home computer even IF you have the memory for it. You might just fraps it instead ¬¬
And there's also the development time.. honestly, they have better things to focus their strength on. They haven't even finished coding bnet yet. Let's delay the game release by a couple of months only so a few randoms can enjoy replay rewinding... yea right... They're already putting on state saving every x minutes, that is good enough, be satisfied with that.
This brute force idea of saving states every frame during live play is completely out of question. Stop dreaming ^^
|
lol @ RAM size talks. ever heard of virtual memory?
|
Sure, why not waste as much memory as possible. You're implying we have enough of it anway, right?
|
yea my way is the easiest way me thinks...
|
The OP really has no idea what he is talking about, making replays go backwards would require completely new functions in the game.
|
On April 02 2009 17:59 fearus wrote:
The OP really has no idea what he is talking about, making replays go backwards would require completely new functions in the game.
that's why he disappeared after bill just grilled him and his "programmer" knowledge...
|
On April 02 2009 08:48 prOxi.swAMi wrote:Show nested quote +On April 02 2009 08:36 ocoini wrote:
Think it would be easier to just have a replay to avi converter type.
and which part of the map the screen focus on? :S
The one you'r watching as you convert 
|
tec, are you working on your proposed solution? <3
|
Yeah, I've barely begun though. But SC is cool with me changing the tick counter at will (thereby jumping back or forward in the replay action list), and the game can be sped up to 42x fastest speed without any real modification (so every 1.4 seconds is a minute of gameplay). Both of those make it look doable. It should theoretically be possible to make SC run the game as fast as possible (no delay between update frames), but that will take a fair amount of work, I think.
Things I still need to do:
- Traverse the unit list
- Copy the unit list and store it elsewhere in memory
- Devise a good way to replace BW's unit list
- Make something to run through the replay as fast as possible and cache the unit list at specific intervals, then restart the replay from the beginning.
- Figure out how to fix the replay text when I jump around the replay, since for some reason it will only ever display a line of text once, even if I jump back before that point in the replay.
Assuming I can make all of that work, we should have a working replay seeker  May be a while though, as I've got a bunch of other CS projects to do for school right now =/ (But SC stuff is so much more fun  )
|
tec, if we can go that fast, wouldnt it be more feasible to interpret the click on the replay progress (back or forward in time) and get the tick you clicked on. If its behind ur current replay progress point, hen restart the replay. Next is to speed up 42x till you get to the desired tick. I mean, i think this would probably take less time to implement than the checkpoint idea, and 42x is preetty fast... dunno if this is too noticeable though. What do you think?
|
|
|
|
|
|
EPT
