Braid is undecidable (2014) [pdf]
arxiv.org
arxiv.org
I can't think of many other games where the mechanics themselves reinforce the story. Papers, Please does it pretty well.
Also consider playing the following if you have thirst for puzzle games
- The Swapper
- Snakebird
- Spacechem
- Starseed Pilgrim (this one I haven't played but Blow recommended it, iirc)Also check out The Talos Principle [0], it resembles The Witness (based on little clips I've seen of it), and feels like Portal with a dash of Isaac Asimov and a sprinkle of Religion.
Beautiful audio, beautiful scenery, clever puzzles. One of the best games I've ever played.
I've replayed Limbo, but never Braid.
FWIW I've revisited Braid multiple times, but don't think I'd get anything new out of Limbo if I played through it again.
I don't think I'd consider them better games than Braid, however, they just have (much!) more replayability/content.
(I would consider them better than Limbo, but that's neither here nor there).
Also, I wonder if most programmers have unknowingly built a ton of Braid intuition because of the way the time reversal tree matches the way we model the undo tree in $EDITOR.
The classic undecidable problem is "the halting problem". In short, given a computer program (and some input for it), decide if that program will ever stop, or continue forever. It turns out there is NO WAY to write a program which will, for any input program, check if it will halt in finite time.
This stuff is a little mind-blowing at first -- the wikipedia article isn't bad.
EDIT: Fixed typo from wolfgke
The classic undecidable problem ...
Some examples of this are propositional logic and linear logic are decidable, whereas the halting problem and nonlinear logic are not.
For instance, the halting problem isn't decidable because although you can answer true or false for some specific programs, there exists programs where you do not know if they halt or not. Arbitrary mathematical problems in general are undecidable (see Gödel's incompleteness theorems) but we can still carve out domains within this that are decidable.
PS: the usual recommendation is to build a game not an engine, I guess nobody have foreseen an experienced developer going even lower in abstraction :). One of these days: "I am not satisfied with the hardware we have, where is my soldering iron..."
The implementation of the counter is IO (the levers that Tim pulls), ADD, SUB (branch if 0), M1 (the counter).. and then M2.
M2 is the counter that holds the monsters as they are subtracted from M1. It is also used as IO for the branch part of SUB (if I understood the article correctly).
Therefore, if I call SUB with M2 = 0, then the counter will malfunction.
I think that the consequence of this is that the given function has a decided halting point.(Branching was taken out). I have no idea how to say this in a better way, sadly my computer science education is tragically lacking.
When a monstar leaves the counter (due to a SUB lever emitting a bunny), the monstar has to proceed to the area under the ladder, where Tim has to kill it in order to proceed.
If Tim pulls a SUB lever when the counter equals zero (no monstars), then the bunny will die on the ceiling spikes and be removed. Tim will not be able to reach the ladder and will have to exit the branch point and proceed to the next spot.
Alright, M1 the first memory "thing", the counter where the result of ADD is stored. M2 is the second memory "thing", the room mentioned in the part quoted. However, you have made me feel rather silly for not realising the very obvious solution to the problem.
Thanks.