A time travel strategy game(achrongame.com)
achrongame.com
A time travel strategy game
http://achrongame.com/
33 comments
WOW. Just WOW. I have always believed that you can't have a good idea without someone else having it at about the same time, but this is the most uncanny experience I have had yet.
I had this exact same idea in January, or at least a very similar one. Time waves, etc.
Amazing.
By the way, this is one of the reasons I don't like patents that much - what if I had patented "A real time strategy game with time travel elements using propagating time waves"? Then these guys wouldn't have been able to implement it, even though they obviously came up with the idea separately, and have spent more effort implementing it.
I had this exact same idea in January, or at least a very similar one. Time waves, etc.
Amazing.
By the way, this is one of the reasons I don't like patents that much - what if I had patented "A real time strategy game with time travel elements using propagating time waves"? Then these guys wouldn't have been able to implement it, even though they obviously came up with the idea separately, and have spent more effort implementing it.
I should also have stated that in the reverse: What if he had patented the thing, when I have also independently created the idea? Looking over his curriculum vitae, it looks like he already has:
"Patent Pending: Methods, systems, and computer program products for simulating a scenario by updating events over a time window including the past, present, and future. Submitted July 10, 2008."
Oh well.
"Patent Pending: Methods, systems, and computer program products for simulating a scenario by updating events over a time window including the past, present, and future. Submitted July 10, 2008."
Oh well.
The hypothetical scenario you describe would be tough for Hazardous software; however, they had the opportunity to do a patent search for related pending applications prior to investing any resources creating Achron.
The Patent subsystem of our govt can serve a useful purpose for inventors and society in general.
But as with nearly any system of this type, there are "corner-cases" for undesirable usage.
A big problem is that someone can submit a patent and "sit on it" for years and years. A fallow patent provides no value to taxpayers. At best, the issue of the patent had a marginal cost for taxpayers, but at worst, there is a huge opportunity cost if commercial development of the invention yields value.
Our patent system should demand inventors make timely, reasonable effort towards commercial development of their inventions.
Kudos to the Achron inventor (Christopher Hazard?) for doing just that.
The Patent subsystem of our govt can serve a useful purpose for inventors and society in general.
But as with nearly any system of this type, there are "corner-cases" for undesirable usage.
A big problem is that someone can submit a patent and "sit on it" for years and years. A fallow patent provides no value to taxpayers. At best, the issue of the patent had a marginal cost for taxpayers, but at worst, there is a huge opportunity cost if commercial development of the invention yields value.
Our patent system should demand inventors make timely, reasonable effort towards commercial development of their inventions.
Kudos to the Achron inventor (Christopher Hazard?) for doing just that.
I've always wanted this sort of thing, but given up on the idea quickly, thinking that time travel in a multiplayer game just doesn't make any sense and there's no sensible way to come up with a way to make the mechanic work.
But it seems I was wrong.
This is impressive and could open a whole new strategic dimension to RTS gameplay.
But it seems I was wrong.
This is impressive and could open a whole new strategic dimension to RTS gameplay.
If you move a unit to a new location in the timeline-present, then go into the timeline-future... wait a little for it to propagate... then, when it appears, chonomove it to the timeline-past in the same location... wait a little while for it to propagate... and BOOM, it chronofrags itself.
Lets say it 100% destroys itself (it doesn't in the video)... wait a little while for its absense to propagate into the timeline-future... now, when it arrives (and not before), there is no unit to chronomove into the past, and so the unit does not appear in the timeline-past... wait a little while for its absence in the past to propagate... And now there is no chronofrag to destroy that unit, and so it exists... and the cycle repeats.
I like this time-paradox being resolved by becoming a cycle, due to the delay of propagation.
(However, in a video they imply that you need to manually manage paradoxes, by chronomoving it to the timeline-past for each loop.)
Lets say it 100% destroys itself (it doesn't in the video)... wait a little while for its absense to propagate into the timeline-future... now, when it arrives (and not before), there is no unit to chronomove into the past, and so the unit does not appear in the timeline-past... wait a little while for its absence in the past to propagate... And now there is no chronofrag to destroy that unit, and so it exists... and the cycle repeats.
I like this time-paradox being resolved by becoming a cycle, due to the delay of propagation.
(However, in a video they imply that you need to manually manage paradoxes, by chronomoving it to the timeline-past for each loop.)
I think it might actually be interesting to be able to create time paradoxes. It would give a different dimension to guerrilla warfare for example by being able to set up traps in time and space.
Though probably the hardest thing still left is to make it a fun game to play through, as it's quite easy to have a great idea but still make a crappy/average game.
Though probably the hardest thing still left is to make it a fun game to play through, as it's quite easy to have a great idea but still make a crappy/average game.
BTW: They say they do have time paradoxes.
I agree with you that great idea does not necessarily mean great gameplay.
I agree with you that great idea does not necessarily mean great gameplay.
The time related gameplay elements shown in the videos struck me as extensive, entirely unprecedented and exciting. Wow!
Not entirely unprecedented:
http://news.ycombinator.com/item?id=244594
But, of course, Chronotron is merely the time traveler's Donkey Kong, whereas this new thing is Starcraft. For people who are bored with regular Starcraft and have a desire to play n-way simultaneous Bughouse Starcraft:
http://en.wikipedia.org/wiki/Bughouse_chess
http://news.ycombinator.com/item?id=244594
But, of course, Chronotron is merely the time traveler's Donkey Kong, whereas this new thing is Starcraft. For people who are bored with regular Starcraft and have a desire to play n-way simultaneous Bughouse Starcraft:
http://en.wikipedia.org/wiki/Bughouse_chess
Good points, good links. True, this is a time traveler's Starcraft/Warcraft/Command and Conquer, etc. On the Achron website they state:
"The company's innovation will create new sub-genres of games, starting with the game Achron." Achron is in the MTS sub-genre of RTS, to be pedantic:) However, the scope of differences in here make the term "sub-genre" seem unfair.
The new time related gameplay will demand a huge new strategic skill-set from the players. I don't think this will be true for Starcraft II. And you won't be able to learn this skill-set by playing any of the "old-school" RTS games.
"The company's innovation will create new sub-genres of games, starting with the game Achron." Achron is in the MTS sub-genre of RTS, to be pedantic:) However, the scope of differences in here make the term "sub-genre" seem unfair.
The new time related gameplay will demand a huge new strategic skill-set from the players. I don't think this will be true for Starcraft II. And you won't be able to learn this skill-set by playing any of the "old-school" RTS games.
The complexity of their game engine must be staggering...
Not necessarily. While playing Braid, in the back of my head I was reverse-engineering the engine.
It's a programmer thing. I'm sure you can all relate. :)
Anyhow, if you come at this sort of program in the imperative mindset, it looks impossibly complicated. Imperative programs live in the now, constantly fiddling with their state with no ability to go back. But if you come at this from a functional viewpoint, suddenly it's not so hard; functional programs naturally live in a timeless way and the challenge there is to actually hook them up to reality in a meaningful way!
Instead of recording the state and constantly mutating it, you record the inputs and replay them as needed. The engine will be entirely deterministic, so the game state can be freely rolled back and forth. And, here's the key: While retrofitting an imperative program to do this would be a nightmare, if you know what you are doing and you start with the understanding you need this, it's not so hard. You build a small test engine with the ability to do just one thing (maybe move units around), work out the necessary primitives, then start expanding the engine, maintaining the necessary properties as you go. You grow it from a small, maintainable seed.
This is where, even though you can't go to school and take "mutatable chronology mathematics", it really helps if you have a lot of math under your belt, because you need to be thinking in terms of invariants and maintaining properties and other such mathematical things. Sitting down to just hack this out Will. Not. Work.
Oh, I don't want to trivialize the accomplishment. This is the basic structure, but you're still going to encounter fundamental contradictions you need to work out how to resolve, and there will be tricky interactions that don't work quite right, and slight violations of some relevant property (that you may not even have fully understood or articulated) may manifest as some of the subtlest bugs you've ever seen (with their only saving grace being that they should be fully replicatable, in a system that basically has a time-traveling debugger). My point here is that while it is complicated and possibly the subtlest real-time strategy engine ever built, it is not as complicated as your imperative intuition is telling you. It's just fiendishly complicated, not impossibly complicated.
It's a programmer thing. I'm sure you can all relate. :)
Anyhow, if you come at this sort of program in the imperative mindset, it looks impossibly complicated. Imperative programs live in the now, constantly fiddling with their state with no ability to go back. But if you come at this from a functional viewpoint, suddenly it's not so hard; functional programs naturally live in a timeless way and the challenge there is to actually hook them up to reality in a meaningful way!
Instead of recording the state and constantly mutating it, you record the inputs and replay them as needed. The engine will be entirely deterministic, so the game state can be freely rolled back and forth. And, here's the key: While retrofitting an imperative program to do this would be a nightmare, if you know what you are doing and you start with the understanding you need this, it's not so hard. You build a small test engine with the ability to do just one thing (maybe move units around), work out the necessary primitives, then start expanding the engine, maintaining the necessary properties as you go. You grow it from a small, maintainable seed.
This is where, even though you can't go to school and take "mutatable chronology mathematics", it really helps if you have a lot of math under your belt, because you need to be thinking in terms of invariants and maintaining properties and other such mathematical things. Sitting down to just hack this out Will. Not. Work.
Oh, I don't want to trivialize the accomplishment. This is the basic structure, but you're still going to encounter fundamental contradictions you need to work out how to resolve, and there will be tricky interactions that don't work quite right, and slight violations of some relevant property (that you may not even have fully understood or articulated) may manifest as some of the subtlest bugs you've ever seen (with their only saving grace being that they should be fully replicatable, in a system that basically has a time-traveling debugger). My point here is that while it is complicated and possibly the subtlest real-time strategy engine ever built, it is not as complicated as your imperative intuition is telling you. It's just fiendishly complicated, not impossibly complicated.
It doesn't even have to be fiendishly complicated. Each "time wave" is simply a different run of the simulation engine, with a differing set of inputs. The videos also explain how seemingly paradoxical situations, like units fighting alongside time-shifted selves are handled.
The JWARS simulation engines built by the US Department of Defense (in Smalltalk, BTW) could handle theater-wide simulations down to the individual soldier level at 10,000X speed, and this was implemented in Smalltalk many years ago. Handling a dozen or two dozen "time waves" in parallel shouldn't be too much of a burden.
The JWARS simulation engines built by the US Department of Defense (in Smalltalk, BTW) could handle theater-wide simulations down to the individual soldier level at 10,000X speed, and this was implemented in Smalltalk many years ago. Handling a dozen or two dozen "time waves" in parallel shouldn't be too much of a burden.
I called it "fiendishly complicated" in this case because even if the code is simple when written out, the underlying mathematics is tricky. A programmer off the street couldn't just wander up and modify it meaningfully in the way that a programmer can hack on the Quake III engine without breaking it; the slightest change could cause massive bugs, if you're not maintaining the invariants. The word "fiend" is chosen carefully :)
The chronoporter is underspecified by the demo (which is not surprising and I do not mean as a criticism, buy the game to find out more). I can come up with several possibilities for how that works in game terms that match what we see in the demo, each with their own problems and benefits for the player.
The chronoporter is underspecified by the demo (which is not surprising and I do not mean as a criticism, buy the game to find out more). I can come up with several possibilities for how that works in game terms that match what we see in the demo, each with their own problems and benefits for the player.
What I'm talking about doesn't take any fancy mathematics. Earlier in this thread, someone else was talking about functional programming. You could do the same thing with OO, deterministic pseudo-random generators, and a few patterns like Action. All you have to do is support multiple time-shifted simulations in parallel, and you are mostly there. The complicated part is displaying "overlaps" but that is also not "fiendish." (And the game dynamics discussed in the videos would make that much easier.)
What is truly clever is the introduction of the propagating "Time Waves" in the first place! Once you have that insight, such a game becomes easier to envision implementing.
What is truly clever is the introduction of the propagating "Time Waves" in the first place! Once you have that insight, such a game becomes easier to envision implementing.
That "functional programming" someone was me.
And you missed my point entirely about mathematics, I think. "Fancy math" here is not calculus or fancy topology or graph theory. "Fancy math" here is that you need to build a new fancy math that works with your temporal engine. You can't just sit down and hack shit out, or you will die under the combinatorial explosion of temporal possibilities. You need to build yourself a system of primitives that are time-safe under the temporal transformations you wish to run, and make sure that as you add actions they are also time-safe.
Or you will be crushed by the complexity. Standard OO will not help. You don't need "a functional language", but you damn well need functional style. You'll end up reinventing it even if you didn't know about it advance, with rigid, explicit control over side effects.
If you set out to implement this, you will find the standard Action/Command pattern to be not very helpful. This game has a much richer timeline than the usual Command pattern is designed to handle.
"All you have to do is support multiple time-shifted simulations in parallel, and you are mostly there."
No, that will be inadequate. That doesn't get you to backing up to arbitrary points in the timeline, and since the simulations are not independent, you're going to have a hell of a time expressing all the dependencies in standard OO.
(Note that you could easily do functional-style OO. No problem. But it's not just standard imperative OO, such as might work with Starcraft. This takes more.)
If you don't believe me, try implementing it in a model system. I can only handwave so hard here before you need code to see my point, unfortunately, but I am extremely confident that if you approach this with the standard grab-bag of imperative techniques, you will fail, hard.
And you missed my point entirely about mathematics, I think. "Fancy math" here is not calculus or fancy topology or graph theory. "Fancy math" here is that you need to build a new fancy math that works with your temporal engine. You can't just sit down and hack shit out, or you will die under the combinatorial explosion of temporal possibilities. You need to build yourself a system of primitives that are time-safe under the temporal transformations you wish to run, and make sure that as you add actions they are also time-safe.
Or you will be crushed by the complexity. Standard OO will not help. You don't need "a functional language", but you damn well need functional style. You'll end up reinventing it even if you didn't know about it advance, with rigid, explicit control over side effects.
If you set out to implement this, you will find the standard Action/Command pattern to be not very helpful. This game has a much richer timeline than the usual Command pattern is designed to handle.
"All you have to do is support multiple time-shifted simulations in parallel, and you are mostly there."
No, that will be inadequate. That doesn't get you to backing up to arbitrary points in the timeline, and since the simulations are not independent, you're going to have a hell of a time expressing all the dependencies in standard OO.
(Note that you could easily do functional-style OO. No problem. But it's not just standard imperative OO, such as might work with Starcraft. This takes more.)
If you don't believe me, try implementing it in a model system. I can only handwave so hard here before you need code to see my point, unfortunately, but I am extremely confident that if you approach this with the standard grab-bag of imperative techniques, you will fail, hard.
Most game replay systems work this way - they store the chain of user inputs, and then just resimulate it in order, with the same random seed. Thats the main reason they don't give you the option to rewind the replays and you have to start over.
This game just has multiple simulators running through the chain of commands at the same time, a "movable" simulator (the player's view) and the ability to modify the chain of commands. Once you can distill the idea of "moving backwards through time" into a command, it can be added to the chain of commands and be deterministically simulated like everything else.
This game just has multiple simulators running through the chain of commands at the same time, a "movable" simulator (the player's view) and the ability to modify the chain of commands. Once you can distill the idea of "moving backwards through time" into a command, it can be added to the chain of commands and be deterministically simulated like everything else.
For the game replay system you describe, the only requirement is total determinism. That's not the same as what is being shown here, where the "separate simulators" are actually not independent.
Both you and stcredzero are significantly underestimating the complexity introduced by the chronoporters. Without those, you'd be right, but those introduce additional complexity that I would despair of getting right with imperative programming.
It always looks simple when you just look at a demo. It's much harder when you go to actually do it.
Both you and stcredzero are significantly underestimating the complexity introduced by the chronoporters. Without those, you'd be right, but those introduce additional complexity that I would despair of getting right with imperative programming.
It always looks simple when you just look at a demo. It's much harder when you go to actually do it.
I have no idea if it'll keep me intrigued long term, but the game blew my mind for an evening just thinking about game mechanics. The slow moving 'time waves'/windows are such an elegant solution.
The card game, Chrononauts, has been around a while already. On the other hand, you'll only be frustrated if you bring too much strategy to the table for that game.
If I recall, the only time I've ever been frustrated in that came is when someone kills and/or revives Hitler for the fortieth time.
Still, I need to get that out again. Been a long time since I last played it.
Still, I need to get that out again. Been a long time since I last played it.
It strikes me that the key strategy in this game would be creating actions that are easily reversible. I wonder if resources travel in time with you too, because then the obvious strategy would be to create units as far back in time as possible so you can rush the enemy.
I mean if you have a battle of 30 units vs 30 units and you win with like 2 units left, then you travel back in time and produce 10 more so the original battle was 40 vs 30. However, I'm sure the time traveling of units would be helpful if not risky. I mean what happens if you tele-clone a unit 5 times and the original gets killed? Well if you did that with your entire army of 30 unites, when that time wave hits the battle could switch to 6 vs 30.
I can't wait for a chance to play this, the possibilities are astounding. It's so incredibly rare to get to play with a game this original.
I mean if you have a battle of 30 units vs 30 units and you win with like 2 units left, then you travel back in time and produce 10 more so the original battle was 40 vs 30. However, I'm sure the time traveling of units would be helpful if not risky. I mean what happens if you tele-clone a unit 5 times and the original gets killed? Well if you did that with your entire army of 30 unites, when that time wave hits the battle could switch to 6 vs 30.
I can't wait for a chance to play this, the possibilities are astounding. It's so incredibly rare to get to play with a game this original.
If they ever get to the point of making this into a game engine, one of the first licensees will probably be the company making the official Lost strategy game.
If the engine can handle the plot of Lost, it could handle anything.
If the engine can handle the plot of Lost, it could handle anything.
- "I go back in time, and kill the creator of this game"
- "That's against the rules!"
- "Not after I'm done"
- "That's against the rules!"
- "Not after I'm done"
Wow. I've actually been working on a board game that uses time travel as its mechanic: http://jetpackshark.com/recursed
Ok, this looks awesome. I wonder how players will be able to manage the increasing complexity as a game progresses, but this definitely looks really promising.
I was thinking that too. One thing that helps is we allow the player to focus on the time travel gameplay rather than unit micromanagement by giving the units intelligence.
You could create arbitrarily complex battles across the timeline, but in an ordinary RTS, you can also be overambitious, and not be able to manage everything you set out to do.
Your real-world time in setting up position is also a limit they have in common. Of course, they add the complexity of managing paradoxes, but also introduce the limit of chronoenergy, which seems to have the effect of limiting how many units you can deploy across the timeline at once. hmmm... chronoenergy must be a time-global variable.
You could create arbitrarily complex battles across the timeline, but in an ordinary RTS, you can also be overambitious, and not be able to manage everything you set out to do.
Your real-world time in setting up position is also a limit they have in common. Of course, they add the complexity of managing paradoxes, but also introduce the limit of chronoenergy, which seems to have the effect of limiting how many units you can deploy across the timeline at once. hmmm... chronoenergy must be a time-global variable.
Holy cow. Just... holy cow.
This is Dwarf Fortress levels of awesome. OK... close to Dwarf Fortress levels of awesome.
This is Dwarf Fortress levels of awesome. OK... close to Dwarf Fortress levels of awesome.
Does anyone have any data how to become beta? I'll code for possibility of testing it:P?
Holy shit! First I thought how can this possibly work, I mean having two players playing at different time periods at the same time sounds iffy... but it looks like they might actually pull it off.
Thats pretty cool since time progresses, just in modifiable ways. And what is awesome there is how the progressions are propagated via "time waves" So even though you might have died in the past, you can still fix it in the present and undo your demise.
In any case we need to get some serious budget for these guys to work with :)
Thats pretty cool since time progresses, just in modifiable ways. And what is awesome there is how the progressions are propagated via "time waves" So even though you might have died in the past, you can still fix it in the present and undo your demise.
In any case we need to get some serious budget for these guys to work with :)
Okay... I was skeptical... in fact I'm still skeptical... but this sounds awesome.