Pirate-Rob: Sorta.

Twister ghost: that is the source of every object in the room. It's actually a way of having time travel be possible. Basically, every frame of the game is kept so that objects can go back in time. (No, not rewinding. Time travel. Big difference).

Don't do that; assuming what someone will think and correcting them.

And if you want objects to go back in time, why not store the past however many steps in an array? Its going to be a lot of data, but its a hell of a lot less than creating a bajillion objects.

Then, have a change_time(X) which just causes all time-traveling things to to forward or backwards X in their array.

"Don't do that; assuming what someone will think and correcting them."

Well, literally everyone I've asked for help has gotten it confused. So… XD

Anyway, what do you mean store it in an array? Do you mean store the past x/y values for each object in itself? That would work if I were rewinding the game or working with no collision events. (You can't simply rewind for time travel cause then the game would never move past the point something goes back in time) As far as I know, there is no way to do collision squares/circles without physically moving the objects. Hmmm :/

I'll look into it. Let me know if either of you think of something! :)

Every step: save_game under a different file name

Time travelling: load_game

Yes, everyone will start screaming at you but hey, it works

I like that solution the best out of any solution to a problem ever.

For the array method you don't need to store the x, y for every step.

I would use a method similar to sending updates in multiplayer games, only storing information when things change: an instance is created, changes speed, or direction.

When I need to go back in time to pointA, all I need to do is find the most recent update before pointA then simulate the missing frames between the update and pointA.

I'm going to ignore that post… There's no way it'll work way.

Mairu makes a decent point. I /could/ save info for direction and speed changes, but that might be a bit harder. :/

I honestly have very little clue Cyrus is saying. It sounds like you want me to limit the amount you can go back, so memory can be cleared?

Oh, and I just realized how nobody has any clue why my original code broke. I probably won't use, but I'm still curious as to what the issue is.

This only works if you've set future to an object already. The fact that you're trying to reference what appears to be a temporary variable in an entirely different event is very likely to be the cause of your problem. Even if you were calling it in the same event, you only set the variable during a particular point in time, so that temporary variable would be empty in the steps that the object isn't being created.

As for the other suggestions, storing data every frame is an extremely bad choice, considering that, given your object-based approach, you'll overload the game with instances, and even in an array approach, you could only possibly have 32000 frames worth of data, which is at maximum nine minutes, and very slow.

I would also suggest an array system but only at specific keyframes that are at least one second apart, with a set maximum so you don't overflow. Think intelligently here. Storing data every frame with no plans to manage that data is a good way to make sure your game never works correctly. I'm fairly certain that even Braid, which is probably the most similar game to your purposes, managed time in a sort of keyframe and interpolation method.