Time travel
From Achron Wiki
Events are typically connected in a very linear shape, from the past to the future. However, as soon as time travel is taken into account the relationship between events and moments in time becomes less linear and multifaceted. In order to properly understand temporal mechanisms the concepts of chronal and achronal must first be understood. The topic of time travel does not deal exclusively with chronoportation. The topic of time travel also envelopes player movement through time and the impact of the time window, as well as the interacting connections.
Some terms have more relation to other concepts and are therefore contained within other pages. For a full briefing on game terms see also Time Window and Terminology.
Contents |
Levels of complexity
When viewing the topic of time travel, the inter-connections of events and their results can occur at different levels of complexity and consequence.
Strictly chronal
Bearing very little importance to the topic of time travel, the first level is the most basic and simplest to understand. Events occur from the past to the future. When a unit moves through time, either normally or by chronoporting, they carry everything with them. There are no discernible differences between a unit at two points in time beyond those resulting from events that have occurred in the meantime.
Simple incursion
Working very similarly to strictly chronal time travel, however, minor changes are made to time, but all with a logical source and conclusion. This can be as simple as a unit chronoporting through time, or a player giving an order to a unit in the past.
Inter-achronal
More complex, the interacting achronal events and objects can create a complex and fragile timeline. This includes objects such as interacting paradoxes, the unplayable past, the time window, and chronoenergy.
Timeline
The term timeline more-or-less refers to a course of events from beginning to end. The time window in Achron typically displays a view of the timeline as it stands, with time waves possibly carrying alternate versions. Most of the time a timeline will make intuitive sense, however as soon as chronoportation is introduced the timeline may start showing inconsistencies and seemingly incorrect events.
Propagation
Changes to the timeline must be propagated in order to take place. A time wave is considered a propagator, and will move forward, changing the timeline. If events were not propagated by time waves, the time line would not change or fluctuate and the only events of consequence on the timeline would be those occurring at the present.
Alternate timelines
Time waves that bring forward changes to the timeline are considered to be carrying forward alternate timelines or alternate versions of the timeline. Even the slightest change is considered an alternate timeline, as its consequences can potentially cause massive butterfly effects.
Iterations
Whenever a time wave passes over an event or a section of the timeline, this event is called an iteration. The concept of iteration is intricately linked to the concept of propagation. In usage, the term is typically confined to changes to the timeline so far as they concern specific events. If a player were to attack another player's base, the first iteration of the event would be the first time this event is propagated, the second iteration would usually come when the other player responds or if either player changes the course of events.
Chronoportation
Typically, a chronal entity will travel through time by moving forward at a set rate, however there are ways of travelling through time at non-linear rates, such as chronoportation. When a unit chronoports very little about it changes between its arrival and departure. However, on arrival, a chronoported unit will be given a new ID number, meaning that it will not follow the same commands as its previous self. A TSSed unit cannot chronoport.
Chronoclones
Any time there are two of the same unit at any point in time, the older version is considered a chronoclone. Chronoclones are a direct result of chronoportation and can be very useful.
Paradoxes
Paradoxes may also result from chronoportation. Within Achron, a paradox is defined as an event that causes the timeline to fluctuate between two or more states unless interrupted. For example, if in an iteration the opponent destroys a players base, but in the second iteration the player saves their base with units sent from the base's future, the timeline will fluctuate between the base-destroyed and base-saved states.
Chrono-surfing
Temporal ghosts can be kept alive temporarily by continuously chronoporting away from a time wave that is propagating their destruction. This involves monitoring time waves and consuming plenty of chronoenergy, but does not permanently consume Q-plasma or deal any permanent damage. Temporal ghosts primarily serve to distract the enemy.
Chrono-surfing may also be used to keep paradox ghosts alive long enough to affect the alternate state of a paradox and ensure a positive outcome for both paradox-states.
Chrono-surfing involves clever manipulation of the topology of the time line structure and selective propagation to protect a chronal event or entity from being completely undone. Chrono-surfing involves a unique mix between both achronal and chronal events, resulting in an achronal entity leaving no permanent mark to the chronal history but still being bound by chronal locality. Anything that relies on chrono-surfing is constantly in danger of being undone.
Game engine
Buffer
Every 30 ticks, the game engine saves a state of the current point in time for use when players jump through time. When a player jump through time, they will either snap-to a nearby player wave (within approximately two seconds, and if the two are moving at the same rates), or to the closest buffer point in the past. Using SET_PLAYER_TIME functions in a similar way to a player manually jumping through time.
Chronoportation
Chronoportation is executed in multiple stages. A unit's Objective is set to 48 when a unit is attempting to chronoport, even if it is unable to chronoport, and will change to 49 on the last tick of departure. On a unit's arrival it's objective will remain 49 until the point it finishes arriving. A unit's ObjectiveParameters value will equal the target time for chronoportation (in ticks), for both the arrival and departure periods. To detect a unit's departure time after it has chronoported, TimeCameFrom can be used. The Action numbers for departure and arrival are 60 and 63 respectively. A forced unit action 37 calls the primitive chronoport action.
When a unit chronoports, its Name property remains the same, but its ID # will differ. This means that a chronoported unit will not follow the same orders as its past-self.
