Breach. Screenshot.


You wake up with one purpose in your newly born mind: to protect home. But you did not expect everything to be so quiet and empty. What is going on? A top-down bit-flipping puzzle game, set in the depths of an AI.

In celebration of my 20th Pyweek submission (10+ years!), I put in more effort than usual for this one. I hope you enjoy! :)


Pyweek Honorary Award
Presented by xmzhang1

Ghost in the machine
Presented by Cosmologicon

Give this entry an award


Ratings (show detail)

Overall: 4.3
Fun: 4.2
Production: 4.4
Innovation: 4.4

Respondents: 13


File Uploader Date
Breach. Windows version (py2exe'd).
Tee 2016/09/11 04:38
Breach. Screenshot.
Tee 2016/09/10 23:50
Breach. Final version.
Tee 2016/09/10 23:43

Diary Entries

Breach: Done

This one was fun. Because this is my 20th Pyweek submission, I wanted to try making something special, though I'm not sure how much that shows. For example, it's my first submission with an actual in-game story. :)

Most of my Pyweeks consist of either doing something small in the last few days due to time constraints, or iterating through a number of bad or overly ambitious ideas throughout the week until I find an appropriate one (again, in the last few days). Luckily, this time I had a reasonable amount of time, and I figured out an idea early on that I stuck with throughout the week. I knew that I wanted to do a puzzle this time -- I just felt in the mood for designing puzzle levels -- and having my mind set on it was helpful. As usual, I did not implement everything I wanted to due to time constraints, but I implemented most of it.

The core mechanic is fairly simple: you move around flipping bits in wires in order to open and close doors and reach the breaches. A door is closed when it receives at least one positive signal (i.e. it receives energy), and open otherwise (i.e. no energy to power it up). A special component is that there are one or more paths that always need to be blocked by at least one door, because "you can't let him in here".

Creating levels was surprisingly time consuming. The reason is that I found it tricky to turn this puzzle mechanic into deep levels. I didn't want to add too much to the core puzzle mechanic because I like its minimality, and I like the whole concept of generating depth with simple rules. I might just not be good at puzzle design, but I often got either straightforward levels or "superficially complex" levels from this mechanic. That might be due to the nature of the core mechanic, but maybe someone can prove me wrong. :) Towards the end I did add another feature to try to deepen the mechanic a bit, and I hope the last four levels turn out to be more interesting.

I hope you find this game fun! As always, congratulations to all of you who submitted a game!

PS: Bonus question! Prove that it is possible to construct a level, using any element of this game, that computes any given boolean function. That is, given any n-ary boolean function f (say, expressed as a propositional formula), show that you can construct a level that takes n wires with inputs x1, ..., xn, and outputs f(x1, ..., xn) in a wire. For the sake of this question, ignore space and placement constraints (infinite space, a breach does not need a wall, etc.).

Add a comment

Breach: Post-Pyweek notes

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. :))