Time Travel Mechanic

A whole new game?

So the mechanic doesn't fit with zero-k or is the work involved just that much involved?

We already have a time travel mechanic. You can only travel forward in time though and only in small steps.

Traveling backwards would require some sort of "perfect" save system or code that allows you to play the game backwards. Both probably take quite a bit of work. Making actions affect different time dimensions in a magic way would probably be a whole different matter though.

So to answer your question:

quote: what would it take to implement a time travel mechanic similar in style to Archon

Probably nothing short of a Pull Request by yourself would have a chance at getting an Achron-like system into the Spring engine/ZK.

warcraft 3 mapmakers were able to code in nerubian weaver's ultimate which takes him to his position and health/mana however many seconds back in time. i have no idea how they did it

dota weaver is trivial to make, just save the health/position for the last N seconds and set on usage (knorke did that once iirc)

giving orders on separate timelines on the Spring engine sounds almost impossible, in theory you could stack hacks upon hacks but probably unfeasible (random blocker: eg. map deformation, would need to hold a ton of heightmaps)

Short answer: No

Long answer: Consider that not only was Achron's engine specifically designed for the time travel and manipuation mechanics, but that in order to do so much of the game and units had to be limited in ways that would have been ridiculous as far back as 1995. At present[*], units cannot have their own timers for reloading or healing or anything[*] which means no cooldowns or durations for abilities, units can only move on a grid where 1 square is the size of the smallest unit[*], units can only move in 8 directions, units can only have somewhere on the order of 12 bits for health and 8 bits for energy and ammo, player resources can only take on the order of 25 bits for the main two, and closer to 16 for power and reserves, and moving beyond even 30 units in play on most systems will cause noticeable lag issues[*], along with the entire system being client-server just to let people without 2011-era monster CPUs play multiplayer at all.

That's not even all the limitations, but the point is that in order to make time travel a thing, pretty much everything else was restricted to be more on par with WarCraft 1 than StarCraft II. Making any Spring engine game have even rollback netcode[*] would be a tricky matter of data compression and storage, making it have full-on manipulable timelines would pretty much require dropping most of what we value in the Spring engine for unit movement and physics.

If you want to re-implement something into whatever the current version of the Resequence engine is, then talk to Hazardous Software about licensing.

I think it's possible. A lot of work. But possible. At least in LUA.



We have the technology! (Sort of)


In gadget code all you'd have to do really is copy every unit/projectile/etc's position, velocity, etc in a table then load it from there. It's only going backwards but hey, you never said I had to go forwards.

quote: In gadget code all you'd have to do really is copy every unit/projectile/etc's position, velocity, etc in a table then load it from there.

That is just saving and loading, that is not the problem. But is not enought.
In "your time" a unit might be that position.
In "my time" a unit might be this position. Or maybe the unit does not exist yet/anymore.
That is not possible with spring. The same goes for projectiles and everything else.
Imo there are three options and all suck:
1) The "Lets' use spring but actually not use it" option.
Only use spring for rendering, do not use any of its physics, do not use the command system, use it only for rendering things.
Aka the technically correct answer to every problem ever. Sadly it is so theoretical that it is useless.
2) Use multiple instances of spring that talk to each other. This allows different time-zones to be alive at same time.
This is maybe doable if spring gets some function to spawn new instances (like ~happend when spring.restart was bugged) but cumbersome.
3) Divide the map into several identical areas. Each area is a different time-zone and stuff gets copied around and blabla and each player only sees his area.

None of that seems like a good idea.

Shadowfury333 : Do you have a source/link for that?
It reads as if they had to optimize everything to make it work with realistic hardware requirements. That seems bit strange.
Achron uses 1 GB ram or so, that includes everything: models, textures, sounds, map etc.
It seems strange that they would optimize to a level of only using 8 bits to store units health and could not fit other properties.
If health and coordinates of a units can be stored then what prevents storing other properties?
A few more variables per unit is only a few more bytes, even multiplied by 100 units and even storing it for every single frame (say in a 45min game) would only mean a handful more MB.

Achron with Spring requires you to solve two practically impossible problems:

• Speed up the simulation (all non-graphics bits) by at least a factor of 10. This is required because the timewaves and player wave system is going to need to run at least 10 copies of Spring at once.
• Make a savegame system which is able to store 1000s of simframes, save them constantly throughout the game and load them with little noticable delay.

If Spring supported simultaneous play across multiple maps then it may be possible to hack together a small scale timetravel game. It would be possible to do on a map split into regions but that would be really ugly.

What about the power of desync? It proved perfectly capable of running multiple different games in one match :P