Week ???

*taps microphone* is this thing on?

It's been quite a while since the last devlog. We've been working hard on implementing the core functionality and ui that lets the player interact with the game.

Time travel

Our chosen form of time travel (at least the primary one in this early stage of development) is sending items through time. Instead of actual time travel and all the mess that would occur there, we only allow items, which is much simpler and results in some interesting key-door problems. We also made keys removable, when they're no longer needed, you can take a key out of a door and send it back (or forward) in time to be used elsewhere, this plays into the time travel mechanic nicely.

The Time Line

The primary mechanic of the game is time travel, this necessitates displaying what happened, is happening, and will happen to the player. We chose a linear timeline to represent this, which will later have arrows showing items being sent back and forth through past and future.
The timeline in action, complete with time travel, paradoxes, and unfinished graphics!

The game records all actions done by the player and allows modification and rewriting of those actions. After each modification, we simulate the new action list to locate any paradoxes which are marked on the timeline in red. Paradoxes are orphaned sections of the timeline where A fails to lead to B, a puzzle cannot be completed while there are any paradoxes active, but they may be created temporarily in the transition to a goal state. our game permits certain closed paradoxes such as the bootstrap paradox, where the future causes the past, but it does not permit the grandfather paradox, where the future prevents the past from happening.

A nice feature of this timeline is how it can be much more powerful than a standard puzzle game's undo mechanic, the player can jump to any point in the timeline and add, delete or modify existing actions as much as they like.

Actions

The core engine is actually quite simple. There are only 4 types of actions:
-walk from a to b
-interact with something (pick up a key, open a door, ...)
-send an item to another point in time
-receive an item from another point in time (this is intrinsically linked to a send action)

This makes it very easy to store a list of actions and their resulting states, each action tells the game how to change the state to next.

To reduce the number of actions and facilitate compatibility, walk and interact actions work by path finding, they'll try to find any valid path to get to the target. This means we don't bother the user with irrelevant details about how the action they changed prevents them from getting from A to B through the particular route they used. Another nice detail of this is it allows us to dynamically choose a path for the player to walk in order to get to the right spot when jumping around the timeline, giving the game a bit more animation.

Using pathfinding to dynamically walk the player to the target position, rather than just teleporting there