|
On April 03 2009 06:10 never_toss wrote:
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?
It'd definitely be noticeable, but its a decent idea I suppose. Main issue there is actually restarting the replay, but I'm pretty sure thats doable (I know I accidentally found a way to restart games in progress when I was coding APMAlert  ). Main problem there is restarting from the beginning when you want to seek like 20 minutes in, which would take almost 30 seconds to get to.
|
On April 03 2009 06:48 tec27 wrote:Show nested quote +On April 03 2009 06:10 never_toss wrote:
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? It'd definitely be noticeable, but its a decent idea I suppose. Main issue there is actually restarting the replay, but I'm pretty sure thats doable (I know I accidentally found a way to restart games in progress when I was coding APMAlert ). Main problem there is restarting from the beginning when you want to seek like 20 minutes in, which would take almost 30 seconds to get to.
Right right... hmmm...
Unless you can do the no wait between updates, which i think wouldnt be that much of a gain generally... I would still love to see an early version if you can make the fast forwarding idea...
tec, can I help you out with some coding? ^-^
|
On April 03 2009 07:00 never_toss wrote:Show nested quote +On April 03 2009 06:48 tec27 wrote:On April 03 2009 06:10 never_toss wrote:
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? It'd definitely be noticeable, but its a decent idea I suppose. Main issue there is actually restarting the replay, but I'm pretty sure thats doable (I know I accidentally found a way to restart games in progress when I was coding APMAlert ). Main problem there is restarting from the beginning when you want to seek like 20 minutes in, which would take almost 30 seconds to get to. Right right... hmmm... Unless you can do the no wait between updates, which i think wouldnt be that much of a gain generally... I would still love to see an early version if you can make the fast forwarding idea... tec, can I help you out with some coding? ^-^
Yeah, I think I may try implementing that fairly quickly here. I wouldn't mind having some help on this project, but there may be some difficulties in that. I'll PM you about it though.
|
Yeah being able to rewind a reply is a great help especially if your analyzing a build order and in case you missed something you can just rewind it back instead of restarting the whole replay.
|
EDIT: sry just completed reading whole thread, seems my point was brought up before, ill leave my coment as is anyways, just for consistency ;p
you could always implement some kind of replay rewind in sc1 (although it would be horrendously memory consuming), you would just have to have some plugin that saves the state of the game at each time a new action is taken in memory and an index that refers to each 'savestate', you wouldnt be able to see 'visually-rewinded' animations, but you basicly could go back to any 'frame' of the replay where 'frames' are not measured in seconds, but in indexed times, when actions happen
e.g.: player one (he is an asshole hacker) gives automine command+produce worker command at gametick 5 he doesnt issue any other commands till lets say gametick 30, while player two (some random but honest noob) issues his non-splitting gather command at gametick 18, then issues a train worker command at gametick 22, has no other actions till 30 as well
that would mean that our 'frames' till this point in the game would be
frame 0 : start of game (no safestate needed, already in the replay file)
frame 1 : gametick 5 : hacker issues his commands
frame 2 : gametick 18 : noob gathers
frame 3 : gametick 22 : noob trains
...
and so on
drawback: you would need number of savestates equal to 'frames', which would sum up quite a lot of memory (RAM) space
pro: play from replay possible, you can go back in the replay if you missed anything
hope that clarifies that there indeed would be the possibility of sc1 replay rewind, but its rather unpracticle because of the amount of resources it would consume
hf
|
On March 31 2009 17:02 Bill307 wrote:My gosh, it amuses me how little so many "programmers" know about actual game programming. (A certain post in the "nuke dot" topic comes to mind...) Even I don't know that much. Still, it's a basic rule of software development that any change you want to make that you didn't anticipate beforehand will be a pain in the ass to implement.
1) it amazes me that you tout people when you don't even grasp the concepts of information management. it would be TOTALLY feasible to add a rewind functionality to sc2 offline replay viewing by rendering snapshots of units. given a 1 sec snapshot interval (1/30th of what css standard server use ... but of course sc2 snapshots will be bigger due to more data beeing transfered) and a 20 minute game (20*60 = 1200) you would occupy AT MOST 120mb ram. and trust me, this is VERY pessimistic (no compression, LOTS of details captured in the snapshot ... like animation state for units and doodads which could proof to be unimportant anyway).
of course you could reduce memory load by only snapping every 5 or 10 seconds (much like most mpeg4 implementations) to 20 or just as little as 10 megabytes ram load. with fast harddrives beeing already a standard, you could even cache the snapshots on harddisk ... seeing that some games require as much as 2gig for swap files, this 100mb+ seem quite minimalistic.
possible problems with this implementation would include
-) exact timecode (reproduciong the exact progressbar state of unit/building construction or upgrade research)
-) still too much data to handle (8 players with each hundreds of units could increase snapshot size). but with adaptive lossless compression (coordinates for units can be compressed VERY efficiently to about 1/5th of their uncompressed size) this shouldn't be an obstacle
-) online implementation (sending 100k snapshots over consumer upload takes quite a while). this could be countered by fixing snapshot creation to a timecode and creating snapshots on each machine. then you just have to transmit the snapshot number to jump to (which IS a possible security risk if not handled properly).
-) memory requirements (100mb+ memory load for replays). again this can be countered by both compression and harddisk caching
-) animation synchronisation. depending on how details animations will be, how they are coded and how importan they are for gamemechanic calculation, this could be quite some chunk of data. but given a server tick rate of 20-30fps (no current online game has higher tickrates over internet) you could introduce a fixed timecode for that so snapshos could save an exact timeintervall since the animation has startet. same goes for building/unit construction and research upgrades, but the problem is less dramatic here.
conclusion:
this is DEFINITLY doable, even without touching actual replay code at all. it can be "added" as an option to replay playback with very little, if not none at all, interaction with gamelogic and replay code.
so now quite sticking your head up your .. and start beeing creative. how do you think waaaghtv spawned over 5 years ago? noone thought it would be possible ... look at it now.
/edit:
of course this could only be implemented "easily" when modifying the original sourcecode. you could do it in a community project, but how will you implement controls to actually jump back to a given frame ... i'm not good at interface manipulation so i can't see now how it would be possible other than running sc2 in window and having an external controllbar to rewind.
also if done as community project this could be seen as a hack by blizzard, because you are actively reading sc2 memory (wow glider had problems with that and lost the case i think) which blizzard doesn't really want you too (for obvious reasons ... maphack). so best bet would be to hope for blizzard to implement it.
|
Guys
Anyone who says rewind can be implemented in replays with ease has ZERO clue what they are talking about.
Edit --
Here is a scenario to ponder about:
Here is my dummy replay ------------
Game starts - usual preload such as map, race etc..
Command 1 - Select 4 probes
Command 2 - Right click on minerals.
Game ends
I let the game run for say ... an hour and go afk, game length is irrelevant as I have only issued 2 commands.
Now this 1 hour long replay has 2 commands. Only 2 and the unit list remains at 4 probes.
Just off the top of my head the additional functions that would be needed.
- 2 new mineral functions - 1 to increase mineral patch when it is mined, 1 to decrease player mineral count whenever a probe returns cargo to the nexus.
- 1 new movement function - so probes can moon walk backwards
- 1 mining path AI function - this alone is such a crapload of work, as we all know when workers mine, they often run to a patch, notice it is already being mined then suddenly change target mineral patches and run across to another patch.
Any of the suggestions about saving game state, then loading it from that point of time, isn't in theory a rewind. A rewind would be to exactly as the name suggests that we read the command backwards.
i.e. we can watch the game play itself backwards.
A gamestate loaded somewhere is pretty much a fast(a really fast) forward to that point of the replay.
|
On April 04 2009 12:42 fearus wrote:
i.e. we can watch the game play itself backwards.
now that will probably be impossible because of the way gamecode works.
AOn April 04 2009 12:42 fearus wrote:
gamestate loaded somewhere is pretty much a fast(a really fast) forward to that point of the replay.
not quite.
fast forwarding from begining to a given point DOES take calculation time directly proportional to the time elapsed from the beginning to the desired point. a savestate solution is (virtually) independent of this timespan.
again:
the savestate way is used in all common used video codecs (mpeg2, xvid, divx, h264, vc1, ...) and in any decent first person online shooter on the pc (all games with any quake and valve engine ... don't know about unreal engine). although not all pc games let you rewind demos (quake 3 e.g.) several community projects showed that it can be done.
many people have so much excess computing capabilities that they even can dump the entire video stream to their harddisk ... dumping snapshots of gamestate shouldn't drag down performance that much.
|
What about saving the rep as a video file with attached units/resources info?
|
how big is the resolution of that video file ? the whole map resolution ? 1 second would be 20M at least with low quality image compression -.-
|
On April 04 2009 16:24 LibertyTerran wrote:
What about saving the rep as a video file with attached units/resources info?
i can't follow you
1) in a video, you wouldn't be able to change your view (e.g. scroll around)
2) in a video, ressources would already be displayed ... why attach it?
3) a video would take MASSIVE ammounts of data ... uncompressed 1280x800 frames occupy 3mb of space. 3mb*60(fps)*60(seconds) = 10,8gig of uncompressed video data each minute. what?
|
On April 03 2009 18:03 jacen wrote:Show nested quote +On March 31 2009 17:02 Bill307 wrote:My gosh, it amuses me how little so many "programmers" know about actual game programming. (A certain post in the "nuke dot" topic comes to mind...) Even I don't know that much. Still, it's a basic rule of software development that any change you want to make that you didn't anticipate beforehand will be a pain in the ass to implement. 1) it amazes me that you tout people when you don't even grasp the concepts of information management. it would be TOTALLY feasible to add a rewind functionality to sc2 offline replay viewing by rendering snapshots of units. given a 1 sec snapshot interval (1/30th of what css standard server use ... but of course sc2 snapshots will be bigger due to more data beeing transfered) and a 20 minute game (20*60 = 1200) you would occupy AT MOST 120mb ram. and trust me, this is VERY pessimistic (no compression, LOTS of details captured in the snapshot ... like animation state for units and doodads which could proof to be unimportant anyway). of course you could reduce memory load by only snapping every 5 or 10 seconds (much like most mpeg4 implementations) to 20 or just as little as 10 megabytes ram load. with fast harddrives beeing already a standard, you could even cache the snapshots on harddisk ... seeing that some games require as much as 2gig for swap files, this 100mb+ seem quite minimalistic. possible problems with this implementation would include -) exact timecode (reproduciong the exact progressbar state of unit/building construction or upgrade research) -) still too much data to handle (8 players with each hundreds of units could increase snapshot size). but with adaptive lossless compression (coordinates for units can be compressed VERY efficiently to about 1/5th of their uncompressed size) this shouldn't be an obstacle -) online implementation (sending 100k snapshots over consumer upload takes quite a while). this could be countered by fixing snapshot creation to a timecode and creating snapshots on each machine. then you just have to transmit the snapshot number to jump to (which IS a possible security risk if not handled properly). -) memory requirements (100mb+ memory load for replays). again this can be countered by both compression and harddisk caching -) animation synchronisation. depending on how details animations will be, how they are coded and how importan they are for gamemechanic calculation, this could be quite some chunk of data. but given a server tick rate of 20-30fps (no current online game has higher tickrates over internet) you could introduce a fixed timecode for that so snapshos could save an exact timeintervall since the animation has startet. same goes for building/unit construction and research upgrades, but the problem is less dramatic here. conclusion: this is DEFINITLY doable, even without touching actual replay code at all. it can be "added" as an option to replay playback with very little, if not none at all, interaction with gamelogic and replay code. so now quite sticking your head up your .. and start beeing creative. how do you think waaaghtv spawned over 5 years ago? noone thought it would be possible ... look at it now. /edit: of course this could only be implemented "easily" when modifying the original sourcecode. you could do it in a community project, but how will you implement controls to actually jump back to a given frame ... i'm not good at interface manipulation so i can't see now how it would be possible other than running sc2 in window and having an external controllbar to rewind. also if done as community project this could be seen as a hack by blizzard, because you are actively reading sc2 memory (wow glider had problems with that and lost the case i think) which blizzard doesn't really want you too (for obvious reasons ... maphack). so best bet would be to hope for blizzard to implement it.
I like this idea alot. snapshots of in-game data wont be very large at all, as most game data in the replay tends to be of the terrain and what not.
especially with compression, the snapshot will decrease in size significantly seeing how most units will be already in previous locations during the game, so most building locations can be compressed.
i'd say that a snapshot every 5 seconds is totally doable. when the cumulative snapshot size begins to exceed 50mb, snapshot log can be trimmed down to one every 10 seconds thus deleting every other one. this trimming may even be done continuously rather than at set intervals.
seeing how AIM instant messenger takes a whole fucking 30 megs don't ask me why, i'd consider 50 megs for SC2 snapshots as totally doable, as by the time sc2 is out, 3gig mem on comps will be rather normal.
|
what's nice with play-from-replay, is that you're now able to resume a game just before your friend disconnected
|
So you are trying to integrate a function which you don't even have a closed functional form of... Seems like restarting the replay in super fast mode (no graphics, no game engine slowdowns, etc) is only feasible way.
|
How would taking a snapshot of ingame data every 5seconds achieve anything.
You expecting all the units to be stationrary in that 5 second?
|
On April 05 2009 17:38 NoNameLoser wrote:
So you are trying to integrate a function which you don't even have a closed functional form of... Seems like restarting the replay in super fast mode (no graphics, no game engine slowdowns, etc) is only feasible way.
what are you talking? what would need to be integrated? ressource ammount ... i already said this could be stored in a snapshot too.
On April 05 2009 18:16 fearus wrote:
How would taking a snapshot of ingame data every 5seconds achieve anything.
You expecting all the units to be stationrary in that 5 second?
What? you just play the replay from the snapshot on ... where is the problem?
|
look at replay playback as a multidimensional function which has some unique value (gamestate or snapshot if you will) at a given point in time. you are trying to invert it (feed time to get gamestate). The main problem i see is that it is not invertible by design, game engine only takes few parameters and then does complex uncontrollable loops that only go one way, forward.
Besides that the "function" is self recursive (things that happened early on effect how later things happen) so having an engine which will play things in reverse is out of the question without redesigning every aspect of it where every bit of information is stored.
Think of a gasoline car, you feed fuel, which through explosions (irreversible process) gives out kinetic energy which makes the car move. Reversing a replay is like making the car move so that its sucks back its exhaust does some impossible physics and produces back energy (gasoline)... It just cant do that by design. Electric cars have some of that ability but its still not perfect.
Game state idea could be feasable but it requires that at that specific point in time no irreversible loops are being run which is rather unlikely. If a unit was given a command to move from one corner of map to the other, AI logic will flow in one way, forward, and you wont be able to "loop back" because it cannot do that by design.
|
On April 06 2009 03:21 NoNameLoser wrote:
look at replay playback as a multidimensional function which has some unique value (gamestate or snapshot if you will) at a given point in time. you are trying to invert it (feed time to get gamestate). The main problem i see is that it is not invertible by design, game engine only takes few parameters and then does complex uncontrollable loops that only go one way, forward.
Besides that the "function" is self recursive (things that happened early on effect how later things happen) so having an engine which will play things in reverse is out of the question without redesigning every aspect of it where every bit of information is stored.
Think of a gasoline car, you feed fuel, which through explosions (irreversible process) gives out kinetic energy which makes the car move. Reversing a replay is like making the car move so that its sucks back its exhaust does some impossible physics and produces back energy (gasoline)... It just cant do that by design. Electric cars have some of that ability but its still not perfect.
Game state idea could be feasable but it requires that at that specific point in time no irreversible loops are being run which is rather unlikely. If a unit was given a command to move from one corner of map to the other, AI logic will flow in one way, forward, and you wont be able to "loop back" because it cannot do that by design.
K.....I'm getting fed up
LISTEN UP KIDS YOU CAN EASILY REWIND YOUR DAMNED REPLAYS!!!!
All Blizzard needs to do is set it up so that when you click a different position on the replay time bar the replay automatically restarts and runs in fast forward(as fast as they can possibly get it) until it reaches the specific point in time. Is it perfect? no but as we have already fucking figured out by now Sc2 isn't set up in a way that would make this easier.FIN
|
as far as i can tell there are 2 good suggestions in the thread:
Checkpointing
and
Re-replaying from the beginning to the user selected time point at xASFASTASPOSSIBLE speed
Why not just do both? Do some form of checkpointing to save the game state (but at low frequency) , and when the user chooses a spot to jump to, restore it by going forward as quickly as possible from the nearest checkpoint? I think that's the best space/time tradeoff.
as far as "true" replaying is concerned (i.e. going back in time and watching the replay backwards)... i don't think thats possible as many people have said already. and i don't think anyone here really wants to watch it in "real" backward.
|
Actually, that ram capture method has some real potential. Especially if implemented during production.
For those who don't understand it entirely a simple example can come from old console emulators (eg SNES). This is just a rehash of how the idea proposed by the people above works for those that may not understand its aid. Also note that it does not give true 'rewind' but rather allows you to step back and forward to any point in a replay that you choose.
Traditional save features in games are based on the game data. The save would go through and put the position, direction, current animation frame, etc for every unit/object in the game into a file. The save files size would vary greatly based on how many units etc are currently in the game.
A 'state save' as used in emulators for example, simply makes a copy of the ram in the location where the game is running in memory. To load it simply replaces the current games in ram state with the saved state. Every file is the exact same size, no matter how many units are in the game because the entire 'allocated' ram area is saved, even if its empty.
If an in-game state saved was implemented by the creators of the game (instead of a 3rd party as in emulators) they could specifically avoid saving the areas of memory which simply hold graphical and audio tracks. The piece of ram which is grabbed and saved can be dropped to a very small amount.
Once the replay is loaded saved states can be captured every x seconds. Since we know that the state will be the same size every time, the system can see how much free memory you have and change x to the smallest number possible in seconds to allow you to jump to more locations within the replay.
This process could be further refined to lower ram costs by taking the fast forward function into account. If for example you know you can fast forward at 44x speed. Why take a state every second, when it would take 1 second to process 44 seconds of play? If those (made up) numbers are accurate you would at most take a save state every 44 seconds. The point is that by taking both save state, and fast forward speed into account you can create a significantly less ram consuming advanced system.
|
|
|
|
|
|
EPT
