Hmmm... it depends on the movement you have. There was an extension eons ago that recorded movements, but I don't think I ever got it to work.
You could theoretically detect changes in speed and direction and record them in a txt or ini or whatever file, and then read them back. I suppose you could also detect length of input, but that could be imprecise and a hiccup could cause the racecar to turn into a wall too early or something.
Try the first thing... start a fastloop. Set a counter to current racecar speed. On loop, compare two general values, counter, and current speed. If they are different, record the change and set the counter to the new value. Do the same with direction... You'll have to have some sort of cushion. Perhaps just record the speed and direction regardless of whether it changed... or maybe you could figure out a timestamp. It's worth a shot.
Oh yes. Every time the player inputs a command have an array record the X and Y positions, the direction and anything else important. Then just duplicate the racing object and tell it to run off them commands!
Or be hella unresourceful and set it to record the X, Y and direction of everyframe to an array, have the ghost object have no movement and when the ghost is running set it to X and Y position as it moves down the array.
Years back a friend of mine was working on a vertical scroller that had a kind of rewind feature which also saved a replay, something by Biax if memory serves.
That's what I mentioned--the timer is a very inaccurate thing to use for something such as this. Differing computer speeds and processor/memory hiccups can throw everything off.
not if you use timeX extension. its based on teh processor independantly of the app. the way mmfs timer SHOULD be. so if the program slows down, the timer doesnt.
MMF's timer can do that. It's the machine-independent speed option. The problem is, when you have the time independent, the animations are too so things skip and look funky. TimeX separates them.
Originally Posted by UrbanMonk I just used the key object and recorded when keys were pressed or released then applied the same inputs based on a timer.
This can be a good method, but it needs to be very precise (I'm hoping "timer" would refer to a counter that's constantly counting, and not the actual timer?)
Specifically, if you have two active objects colliding with one another, the collision may end up a little different if the screen happens to be scrolling in a different manner than when it was recording. It should work well enough if you don't have any active/active collisions, or if you manage to do away with scrolling. But it can be tricky either way.
In basic, as people are pointing out, theres two different methods. Either you can record the exact position and properties of your player for every single frame, or you can record each input the player made and then simulate the replay by reading all these inputs in the exact same order/time. This latter method is exactly how say Warcraft III or Starcraft save their replays. But if a single bug occurs in this replay data, or if even one thing gets out of sync, it will crash and burn because the inputs will no longer make sense in each step. Thus saving each frame of gameplay is *simpler* in terms of coding and much more powerful for manipulation, but requires enormous amounts of data.
In my current project, I save up to 10 seconds of gametime all the properties of up to 500 objects, each with up to 12 properties that take up 4 bytes of data each (1 integer = 32 bits = 4 bytes). In a worst case scenario, this means I need (10*50) * 500 * 12 * 4 = [b]12 megabytes[/b] of data in my array, just for 10 seconds worth of gameplay! Imagine how much it would take to save 30 minutes worth!
But in this case I think you could get away with just saving the X/Y position & properties of each frame into an array, because you're only saving a single object. Just be very conscious of how large the 'replay' array really is
I personally wouldn't rely on MMF's capabilities to accurately simulate the correct inputs at each designated time to choreograph a replay. There's also a slightly disregarded problem with said method being the replay of opponents. Seemingly reproduced movements within the programming in each instance of any given opponent is still greatly influenced by MMF's ability to tell them what yo do. If MMF skips a beat then perhaps your character will do exactly what he did but the opponent will be out of whack.
(Imagine jumping on a mushrooms head in Mario that isn't underneath you, even if the replay is accurately representing your character)
Recording each objects X,Y coordinates, at the end of each cycle, into an array would probably be the best option. Yes it would account for a fairly large replay file but now you understand why so few games include such a feature.
You could do a hybrid work around by using inputs for the character and recording X,Y coordinates for the enemies, it might help reduce replay file size.
Don't forget knowing the X,Y position is only a part of the battle, you have to know said animation at said coordinate as well. If you watch replays in GTA San Andreas you'll notice that they skipped out on properly syncing animations to replays as to cut down on replay file size.
Good luck.
thinking is like pong, it's easy, but you miss sometimes.
Advertisement
Post Reply
Edited by Marcello64
