Time Travel Titan

I mean, why not? Game has information about all unit/projectile/planet positions at any point of time. Save/load features are also here. There should be minimal lag, because chronocam works fine with skipping 1-2 mins back and fourth. The only thing needs to be done is resetting all effects, but it also possible at the moment.

1-time ability (or with very long recharge) to transfer solar system to a minute ago is not that OP with big power drain and high metal cost. And being able to have only one machine at once.

So if there is an invasion on your planet, you can transfer back in time and stop it, add more defences. But your enemies will know some stuff about your planet, so they can use completely different tactic. Or if you are invading with all your forces, you can have 2 tries instead of 1.

imcrazy

ʘ‿ʘ so you'd use chronocam (it's the save feature essentially) to start back up at another point?

why make a whole unit that would be unusable in multi for that when the load anywhere function is already coming to the game?

(well...... maybe I shouldn't speak too soon. @jables?)

There is a game based on this mechanic.

The whole point of unit to make it usuable in multiplayer. It basically *create a save minute ago and load* on fly in the middle of the match.

http://www.achrongame.com/site/

*chuckle*


Please do describe how that would work

especially in the case where both are going for it or If one does it but rewinds back to a time back where someone else had a time machine but didn't decide to use it but now does?

In fact please throw in as many of those buggers into your explanative scenario as possible so that we may stress test the theory at work behind this.

what about planet positions ? destroyed or burnt trees? wreaks? scorch marks?

Everything will be as it were 1 minute before activation. Planets, units, features. The only thing that will not change is the charge of time machine itself, to prevent infinite use. However, charge will not reset on other players machines. Each can have 1 at a time.

So if enemy use it, than you use it, it will get really complicated and I need to go get some paper and draw some stuff.

NO IM WRONG YOU DIDNT SEE ANYTHING HERE

I literally don't know. I'll go ask someone for help.

If it is even technically possible to use resume with multiple players in a game.

There are options that could be interesting at least initially.

e.g.
When you start building it the other players can see it building and there is a timer "1-2 minutes" until the "jump" much like the RAGNAROK then "Destroys the planet/system" while the game is re-winded in time by a set time maybe upto 10 minutes. All that changes if the information both players have learned the first time otherwise the it's like resume from chronocam.
This could work ok but quickly become very tedious annoying by stretching games out for a long time.
You could make it so that it can only be used once per game or per player.

Never gonna happen. Sorry.

Basically you can describe the development of a game as a time function, something like:
f(t): \R -> {GameState}
This is function which outputs the state of the game for every time you put into. The development of this function is governed by the input of the players and by the rules of the game.
Basically if you have a ant in an game state at time t this function will put that ant a bit further in t+1. Time points outside of the game will be undefined, but for all time point with a game this function is well defined.

You can now define a series of those function starting with f_0(t), which is the original game started in the lobby. On each activation at any point in time you basically go back in the past by \delta t amount and copy the actual state of that function into a new one.
Let f_i be the current game function and let t_e be an point in time, where a time travel is activated. Define a new function f_{i+1} with:
f_{i+1}(t_e - \delta t) = f_i(t_e - \delta t)
At this point you use f_{i+1} to let the game develop from the point t_e -\delta t onwards according to the function development mentioned above.
Not that the criterion f_{i+1}(t_e - \delta t) = f_i(t_e - \delta t) guarantees us that the development of the game from f_{i} to f_{i+1} is seamless.

The trick is that you can define a "gather" function F(t) : \R -> {GameState} in a way like this:
F(t) = f_j(t) with j = max i (of all function f_i that exists at point t).
Remember, we defined all f_i in seamless way, so this function F is seamless too.
In a nutshell, F will basically be the last "true" game function which describes the complete game and therefore is the function that decides who won the game.

For playability \delta t (aka the amount of time that gets re-winded) should be longer than the build time t_B of the time machine, that solves the problem of recurring time machine use a bit more naturally.


That was easy, maybe you need to copy this into Latex for a better reading experience
(Sorry I couldn't resist. I did typesetting in Latex the whole day.)

not gonna happen because how long loading times would be .. if you then consider planets and units it becomes even worse it would be a massive take on hardware, game would be paused for the duration it would need to load old time states ..

nice idea in theory but with the ammount of stuff the engine would have to work with i think it's highly unlikely that this could be done in a quick manner especialy in a multiplayergame ..

@crizmess

what about someone got killed so ofc he leaves the game but now someone rewinds to a time he wasn't dead?

If we will use GW logic, commanders are controlled from somewhere. After first death control signal ends - commander self-destructs. Don't forget that originally I was suggesting only 1 min time rewind.

that's enough for someone to quit upon death and another simultaneously rewinding

but sure.

The commanders aren't controlled from somewhere in GW, they are fully sapient beings.

But the Synchronous have a hive mind, and eve then most of it's members have a lot of individual control unless they are so consumed by the hive mind that the will of it controls them (A digit).

The event of leaving will be there, but it will shift to the point where you glue together f_j and f_{j+1}.
So when you construct F(t) you will observe that the player left at the time point where time it was rewinded to. But note that this point is indistinguishable from any other point in the game. It will look as if the player just left.

I think it helps if you realise that the overarching game function F(t) has no event of an successful activation of any time machine in it. It looks like these things where never used, because every successful activation will cut out exactly the part of the game function that includes the time machine and its activation. This is the interval (t_e - \delta t , t_e] in the above defined nomenclature.

so then you recreate a bunch of units JUST for them to bow up.

That would be incredibly annoying. All the work in an RTS and now you'd suddenly need to recheck everything you're doing. >_>

I really like the sound of this. I just like things the weirder and more interesting they can get. Three things:

1. When activated there should be an announcement to all players: "Temporal anomaly detected", followed by a countdown, preferably in either Majel Barret's voice or Ellen McClain's. Majel has passed so it would have to be done creatively.

2. It should be called the Omega 13 Device.

3. If possible, "Back in Time" by Huey Lewis and the News should play after the countdown completes. Maybe during the countdown. Not sure.