

A time travel strategy game - wavesplash
http://achrongame.com/

======
Eliezer
_Chris used a neat strategy against me in a memorable free-for-all game
between him, Konrad, and myself. I launched a massive surprise attack on
Chris's mining base, so he traveled back in time, prepared a large fleet to
counter my attack and succeeded. However, in the present I acquired nukes and
sent a nuke back to the end of the battle that destroyed his remaining fleet.
Before it was over, he jumped back further in time, moved his mining base and
undid his counter attack. Since his fleet had left the area and my army had
conquered it, my nuclear blast from the future decimated my own forces! Right
at that time, Konrad came at me with his forces, so I didn't have time to undo
my nuclear blast._

Okay... I was skeptical... in fact I'm still skeptical... but this sounds
_awesome_.

------
shader
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.

~~~
shader
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.

------
DarkShikari
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.

------
10ren
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.)

~~~
daemin
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.

~~~
10ren
BTW: They say they do have time paradoxes.

I agree with you that great idea does not necessarily mean great gameplay.

------
davidbnewquist
The time related gameplay elements shown in the videos struck me as extensive,
entirely unprecedented and exciting. Wow!

~~~
mechanical_fish
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>

~~~
davidbnewquist
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.

------
davidbnewquist
The complexity of their game engine must be staggering...

~~~
jerf
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.

~~~
stcredzero
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.

~~~
jerf
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.

~~~
stcredzero
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.

~~~
jerf
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.

------
wavesplash
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.

------
Agathos
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.

~~~
crowbar
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.

------
electromagnetic
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.

------
ivankirigin
\- "I go back in time, and kill the creator of this game"

\- "That's against the rules!"

\- "Not after I'm done"

------
chez17
You're forgetting Day of The Tentacle!

~~~
kenver
You jsut brought back some old memories for me! DoTT was one of the first
games where I really enjoyed the story.

------
jimbokun
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.

------
t3knomanser
Wow. I've actually been working on a board game that uses time travel as its
mechanic: <http://jetpackshark.com/recursed>

------
gfunk911
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.

~~~
10ren
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.

------
patio11
Holy cow. Just... holy cow.

This is Dwarf Fortress levels of awesome. OK... close to Dwarf Fortress levels
of awesome.

------
p47
Does anyone have any data how to become beta? I'll code for possibility of
testing it:P?

------
GrandMasterBirt
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 :)

