A time travel strategy game
achrongame.com
achrongame.com
Okay... I was skeptical... in fact I'm still skeptical... but this sounds awesome.
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.
"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 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.
But it seems I was wrong.
This is impressive and could open a whole new strategic dimension to RTS gameplay.
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.)
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.
I agree with you that great idea does not necessarily mean great gameplay.
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:
"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.
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.
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 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 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.
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.
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.
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.
Still, I need to get that out again. Been a long time since I last played it.
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 the engine can handle the plot of Lost, it could handle anything.
- "That's against the rules!"
- "Not after I'm done"
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.
This is Dwarf Fortress levels of awesome. OK... close to Dwarf Fortress levels of awesome.
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 :)