Loading...
  OR  Zero-K Name:    Password:   

Post edit history

Time Travel Mechanic

To display differences between versions, select one or more edits in the list using checkboxes and click "diff selected"
Post edit history
Date Editor Before After
2/15/2016 6:57:41 PMUSrankPhoenixCalliber before revert after revert
2/15/2016 6:53:04 PMUSrankPhoenixCalliber before revert after revert
Before After
1 [quote]Achron with Spring requires you to solve two practically impossible problems: 1 [quote]Achron with Spring requires you to solve two practically impossible problems:
2 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. 2 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.
3 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. 3 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.
4 \n 4 \n
5 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. [/quote] 5 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. [/quote]
6 \n 6 \n
7 Thank you GoogleFrog for the input. I get the impression that the second item is a solution to the more more general reversible computing problem that this mechanic poses. Where any point in the process has to be generated without knowledge of previous state. 7 Thank you GoogleFrog for the input. I get the impression that the second item is a solution to the more more general reversible computing problem that this mechanic poses. Where any point in the process has to be generated without knowledge of previous state.
8 \n 8 \n
9 Which might mean doing away with the game loop paradigm entirely. I have an idea for a solution i'm trying to debunk before I post about it in any detail for the community to debunk it further. It actually depends largely on whether linear functions can be computed efficiently and that all non-graphical simulation mechanics can be represented as a linear function of time. 9 Which might mean doing away with the game loop paradigm entirely. I have an idea for an alternative solution i'm trying to debunk before I post about it in any detail for the community to tear it apart. It actually depends largely on whether linear functions can be computed efficiently and that all non-graphical simulation mechanics can be represented as a linear function of time.
10 \n 10 \n
11 my intuition also tells me that at least some of these calculations can be run on the gpu for extra processing power if the cpu proves to be too limiting despite the ability to be efficiently computed, but i'm considerably less certain of this. 11 my intuition also tells me that at least some of these calculations can be run on the gpu for extra processing power if the cpu proves to be too limiting despite the ability to be efficiently computed, but i'm considerably less certain of this.
12 \n
13 I like all the other possible approaches mentioned too. Lots of possibilities to choose from.