Originally, the puzzles were more rigid. But I'm not a very good programmer, and more importantly I've never designed puzzles before. The result is puzzles that are not good. Here's what's going on, to satisfy your curiosity:
- The goal in level 1 is to pick up a stone. I didn't communicate this properly. If you type next before completing the level, it will tell you what you need to do. The messages are timing based. Afterall, the researchers need time to type them! The result is less than well communicated.
- Level 2 was pre-emtively cut due to cowardice! I had another idea for what to do with the arms, one fitting of the great mind of Franz Bagel, but it would have required a lot of extra implementation, and it also seemed in character for him to forget about something as routine as a hiring exercise. He and B.S. are based on two archetypes of compsci professors I've met during my major. And explorative-creative but sort of detached-wistful type and a micromanager-paranoid practical type respectively.
- Level 3 does not have the goal of holding Tibbles. It has the goal of moving him inside. Once he is inside, you're free to go.
The sensors are wrong because the way objects are displayed and searched for is only partially systems-based. A lot of it is actually just manual terminal messages I wrote, which is why the colors or names are sometimes off.
Thank you so much for the in-depth analysis. I also like how the tone turned out. I'm learning about some early programming concepts in school right now and I'm subscribing to the idea that, by modern sensibilities, these dawn-of-computing programs would come off as buggy and opaque. It's a slightly simplistic view but I'm sure players will sympathize with it.