I have not yet tested it on anything other than MacOS, and I am pretty sure that it would yet not work on other platforms. Among other things, the ingame rules and guide is currently in progress. For now, the rules are here.
Hopefully, you have seen and played a "program a robot" game in the past. If you have not, http://robozzle.com/ is a fun one. Paradox Maze is one of these games, but with a twist. In this game, the puzzles involve time travel as well, allong with other related mechanics. Here is the general outline of the gameplay: in each "room", you program a robot to traverse a tile map and reach every target tile (not neccessarily at the same time). Be carful not to run into walls, create paradoxes, or run out of energy (running out of energy does not neccessarely cause you to lose, but the robot stops where it is). Each move consumes one unit of energy for your robot, so economize your moves.
You code the robot in a micro-language with the following syntax.
<Command, loop, or condition>;
<Command, loop, or condition>;
<Command, loop, or condition>;
...
// Comment
sleep; // Wait one tick (still consumes one unit of energy)
fd; // Move one block forward
lt; // Rotate 90 degrees left (counter-clockwise)
rt; // Rotate 90 degrees right (clockwise)
Loops do not consume any energy or time
forever { // Continue until the robot runs out of energy or the loop is broken out of
<Command, loop, or condition>;
<Command, loop, or condition>;
<Command, loop, or condition>;
...
}
repeat(<N>) { // Repeat N times or until the robot runs out of energy or the loop is broken out of
<Command, loop, or condition>;
<Command, loop, or condition>;
<Command, loop, or condition>;
...
}
Control flow commands do not consume any energy or time
break; // Breaks out of the innermost
stop; // Completely halts the program
look; // Same effect as sleep, but senses whether the path ahead (just the block infront of the robot) is clear
Conditionals do not consume any energy or time
ifOpen { // Only executes the block if the path ahead appeared safe the most recent time that look was performed (initially safe)
<Command, loop, or condition>;
<Command, loop, or condition>;
<Command, loop, or condition>;
...
}
ifClosed { // Only executes the block if the path ahead appeared blocked the most recent time that look was performed (initially safe)
<Command, loop, or condition>;
<Command, loop, or condition>;
<Command, loop, or condition>;
...
}
Don't worry, they will be introduced gradually and with demonstrations
Safely press each of these tiles to win the level
Enter this tile to be telleported to the matching destination tile (same color/letter)
Does nothing, but is the destenation for portal tiles
Same thing as an empty tile, but it appears to be a wall to the look
command
Same thing as a wall, but it appears to be an empty tile to the look
command
Opens when the timer runs out (counts as an empty tile at 0)
Closes when the timer runs out (counts as a wall at 0)
Sends the robot forward or backward in time (a -2 time portal only sends the robot to one tick before it entered the portal as one tick elapses to move onto it)
Sends the robot to a specific time
Opens when any connected button tiles are triggered (a button is connected if it has the same color/number)
Closes when any connected button tiles are triggered (a button is connected if it has the same color/number)
The time travel system is centered around the idea that there are no paradoxes. Any event that had occured in a timeline will be caused and any effect that a robot causes will have already happened. There is complete (if potentially circular) cause and effect. There is no spliting of timelines. You may have noticed, however, that there could sometimes be multiple possible and valid timelines. All of them will be tested and all valid timelines must result in a success for you to win. Also, it can occur that there are no valid timelines (ie. all possibilities are paradoxical such as if the robot triggers a button that causes a door to close on it in the past and never reach the button). In this case, you lose.
This may be confusing. Here is an example that will hopfully clear things up:
In this case the robot must trigger one of the two button tiles to open the door and win. However, one of the buttons is after the door and if the robot presses the other, it will be trapped and unable to reach the door. This puzzle might seem unsolvable at first but the solution is like this. The robot must move forward and look at the door. If the door is closed, then it should immediately go right and push the button. This will cause the door to have been opened. The robot would then be trapped after pushing the button, but it does not matter as this will never happen! Beause of this code, the door could not have been closed as that would cause your robot to have pushed the button and oppened it. That would be contradictory, so that timeline does not occur. The door must be open. Now, if the door is open, you might be tempted to head directly for the target tile. The path is clear, you just have to go forward, right? No! If you head staight for the target tile, then nothing would have caused the door to be open which is imposible! The situation of the door being open would be paradoxical as well, so there would be no possible timelines. To avoid this, you must turn right and press the button immediately after passing the door. This will be the cause for the effect of the door being open. Then you can proceed to the target tile.
There are two important things to note about this situation. First, though the door will never be closed, the code dealing with if it were is still neccessary though it will never be run. Second, it is neccessary to push the button after crossing the door, even though you have already crossed and it is not neccessary by that point. For anyone interested in philosophy, this has everything to do with Newcombs Paradox.
Here is the solution code:
'''
fd;
look;
ifClosed {
rt;
repeat(3) {fd;}
}
ifOpen {
fd; fd;
rt;
repeat(3) {fd;}
rt; rt;
repeat(3) {fd;}
rt;
fd;
}
'''