Print

[ChatniAeon]

Greetings.

I am currently working on idea of time-travel MMO in HE.

While I have backstory and most of mechanics (at least as much is possible without actual scripting) already prepared, I would like to have some help/advice with design choices.


1) Short-term vs Long-term time jumps vs Mix
STTJ (range minutes, or hours, maximum 1-7 days) bring most challenges, ie how to model multiple players interaction with their past selves (Echoes). Keep them (could fast clutter area with multiplicates, and have to store and replay their past actions until interference) and deal with paradoxes (like killing past self and undoing present self); or remove them (removes in part reason to travel in time and mess with it)? Or some combination? Remove past iterations of character after certain threshold (maybe 1-3 copies max)?
LTTJ (range hundred or thousand year) similar to STTJ, plus long-term effects on timeline.

2) Area design for various timelines
Have fixed area for each timeline possibility (would grow fast) and limit options for change (2-3 max), or dynamically generate and store versions for each active variant of given area (and temporally subsequent areas)? Awareness system?

3) Single timeline, or multiple timelines
With single timeline, how to handle area changes in relative past/present of player character, happening "now" due to other players interference?
With multiple timelines, how to handle where player character will end after time travel to past or future?

4) How many "key points"?
This deals with number of significant events in history/future, that could be affected by players actions. Also dependent on points 1-3. My idea is about 10-30 at launch, maybe adding more later (I initially wanted 1000 key points in 100 years increments, but this now looks too much, given various possibilities or variants)...

5) Dependence of various areas
Should each area of spacial zone react to events in other(s), or should their history be independent keeping updates only to "their own" history? This in my opinion relates to all previous points and their solutions, and here I am most uncertain.


There are more points, but those are ones I am most concerned with.

Any idea or advice would be welcomed.

[Thazager]

  Have you seen a TV series called Legends of tomorrow, where a small group of heroes travel through time? They have similar situations, and where they actually met themselves and changed things they "broke time". This creates random things and people jumping/falling thru time out of their original time frame, and the group now needs to put them back. One theory they keep consistent and also use in the Flash series, is that time takes time to become permanent. They also added a way similar to "men in black" where they can remove memories with a flash to the person's eyes.

1) short vs. long: I believe long might be safer game wise. While they could be there in the same time zone, interacting might set off some bad thing that happens, like for example: they could revert to their former selves in that time frame, the newer versions might poof from existence,  and they loose experience.

2 & 3) more than 1 timeline: this can get tricky, keeping track of more than 1. It might be best to only keep the current one the players are in, and not allow them change it back. (In Flash TV series, trying to change it back only messes things up more.)

4) as the "Game" lives and grows thru the years, more key points can be added. Knowing how many to start with usually requires a group of play testers and see how long the created ones take to complete, this would give a time frame for how long the game will last before you need to add more.  In my opinion, this should be about a year in length, and during this year the group is adding more key points to the game.

5) this could go either way, create 1 event in both ways and see if it was worth the effort or easy enough to keep track of the diff versions.

[ChatniAeon]

Hello and thanks for your input.

Well, I missed that series. But I am big fan of Doctor Who. Sadly, mechanics used there are not of much use for my project. As Doctor himself said, "time is big ball of wibbly-wobly timey-wimey stuff". While there are some good pointers, it is not entirely applicable to my case.

Also, I want some maleability to be possible - permanent changes are not exactly I am aiming for. So bit of flexibility, and possibility to repair changed event is needed.
Still struggling if to use "timewaves" (like in Achron game) that propagate changes at certain periods (not sure how long should they be), or "reality factor" (percentage that determines, how probable each variant of event is) that would be instantly recalculated when players made change at that time-zone and propagate to "future" versions of area.

To your points.

Ad 1: I agree, that long would be better. Keeping tabs of all shadows of "past" players meddling would be too cumbersome to maintain. Also agree of some kind of consequence for players - depending of how "unreal" their "home reality" would become, they should be given some penalties (experience lost, becoming more transparent and less able to affect past events, etc). Still WIP.

Ad 2 and 3) Good point. Version with too low "reality" should become unacessible to all, until somebody manage to revert it to safe threshold (should it be group effort, or allow some events be soloable?). This could allow to spin-up areas of "unreal" versions of areas only when needed (or keep separate version up for those, who have it as their "home-time"; or not - time-orphans fighting to reestablish their home-time? Hmm.).

Ad 4 and 5) So, I was thinking about starting with 10 mutable zones (with 5-10 key points max each), connected with "immutable" passages. Focusing more on temporal aspect, while keeping bit of variability. That makes 310 individual area versions for minimum set, while rising to 15.350 if aiming for upper set (whoa!), if I am counting right. This with only two change options in each period. And I was thinking about to allow 3 options at certain times... Hmm.


Example:

Lets have zone, called Alpha, that is (to make it simple) in its original state grassy plain with small river, and grazing animals.

Local Conflict: Natural preserve VS Futuristic city VS Alien colony

Point 1) Year 0
Original state.
Changes: Place measuring probes VS Destroy them (no versions needed here yet)

Point 2) Year 100
Version 1: No probes - same as original (maybe different animals), no further changes in future versions
Version 2: Probes successfully deployed - first settlers arrived
 Changes: Place city capstone VS Destroy it

Point 3) Year 200
 Version 1: inherited from Y0
 Version 2a: Capstone placed - initial construction of city commenced
  Changes: Help construction VS Sabotage construction
 Version 2b: same as v1

Point 4) Year 500
 Version 1, 2b: Aliens landed and are building colony
  Changes: Attack aliens VS Help aliens
 Version 2aA) City constructed
  Changes: Modernize city VS Sabotage
 Version 2aB) City in ruins
  Changes: Rebuild city VS Destroy city

Point 5) Year 1000
 Version 1.2bA) Natural preserve established
 Version 1.2bB) Alien colony alive - home-time for Alien Sympathizers faction
 Version 2aAa) Futuristic city alive - home-time for Futurist faction
 Version 2aAb) Natural preserve saved (in fact same version as 1.2bA)
 Version 2aBa) Futuristic city saved (same as 2aAa)
 Version 2aBb) Natural preserve saved - home-time for Nature First faction, otherwise same as version 1.2bA
 No further manipulations in this point (save for future game expansion, of course)

This is of course simplified example, not taking into account changes via NPC dialogs (like in P3.V2a: Talk with founder to keep capstone at original place, or move to other river bank - would change future city design OR City Hall placement; etc), assassination vs saving of important NPC, etc.

[Thazager]

In design of different versions, one could make the permanent part like ground terrain part for the base area, and load in using specs the different objects that would either display or not.

An object could be defined using a class, having data like location (vector3), object to load (string), and other things like color (rgba).  Check the tutorial on Dynamic Replicated Objects for create and display object in area. The specs could be used for a list of objects in each version. Check the tutorial on spec system, and the Dev versions to help explain Specs. This would save on the amount of actual areas created, possibly to just 1 or 2.

Things like trees, buildings, and other objects could be placed in each spec to show the diff timeline.