Breach: Post-Pyweek notes

Tee on 2016/09/25 04:34 of Tee-py22

Thanks for your comments on my game! I'm glad that you enjoyed it. :)

I've already discussed the game in my previous post, so I don't have much to say that I haven't said in it. I just want to comment on the "PS" portion in my previous post, because it's an interesting tidbit on the story of the development of the game.

I asked in that post whether there was a way to compute any boolean function with a level in my game (in theory). The answer is yes. The game has NOT gates, and doors behave in an OR fashion: it requires at least one wire to be on in order for it to be closed. Now, a NOR gate is an universal gate, meaning that we can construct all other ones from it, so if we can make one of those, then we're done. A door is not exactly able to produce output, but the feature I added in later levels does allow you to retrieve the output of a door: with track-powered sources, we can position a track, a door, and a source, so that the source is on if and only if the door is closed. This plus attaching a NOT gives us a NOR gate, which we can use to construct any other gate and therefore compute any boolean function.

In fact: this was what drove me to make a crucial decision late in the week. I was originally going to add AND and OR gates to be used just like the NOT gates. The reason is that having only the NOT gates limits the depth of the puzzle a bit. However, I liked the simplicity of having just one type of gate. So I thought, could I do something else that gives me the power of AND/OR gates, and yet lets me maintain this simplicity? For example, I had drawn a use case of AND gates where you had to keep a wire on in order to close a door behind you and avoid a track escaping. Well, in the second to last level, something similar is executed in the top right part of the level -- yet not with an explicit AND gate. The thing is, I realized that doors worked as an OR, but there was no way to capture their output. So I came up with the idea of track-powered sources, which emulated that and fit pretty well with the whole game. It just felt right: while you have to manage doors in order to take care of tracks, this feature made it so you also have to manage tracks in order to take care of doors, and we get a nice circular relationship going on. Time constraints only allowed me to make the 4 levels with track-powered sources in the game, but I think you can make some neat stuff. As a bonus, that was easier to implement than AND/OR gates. :)

Anyway, congratulations to the team winners, and thanks to blakeohare for hosting this Pyweek! See you all next time! (Also, xmzhang1, thanks for that cool award picture. :))

$ python3 run_game.py 
Traceback (most recent call last):
  File "run_game.py", line 3, in 
    from gamelib import main
  File "/home/jorge/Descargas/Breach-1.0/gamelib/main.py", line 11, in 
    import game
ImportError: No module named 'game'