For my second Game-Build-A-Thon as Competition Chair of ACM Gamebuilders at UIUC, I wanted to choose a theme which would encourage the club's new, less experienced members to participate while also encouraging the club's existing members to try building something a little different than they normally would. I chose the theme "It's Not a Bug, It's a Feature" for this purpose. Beginners would be free to experiment and could explain away unintended behavior with "It's a feature!", while more experienced members would be encouraged to experiment with integrating traditionally "buggy" behavior into gameplay.

Adina and I chose to play with the idea of integrating the common physics bug of phasing through walls into our game as a feature. The game is designed to be a relaxing, low-stress experience, with lots of satisfying destruction, no fail condition, and no hard-coded win condition. We wanted to hide our bug mechanic so that the player would not expect it and instead be taken by surprise.

At first glance, the game appears to be a simple game in which the player moves their character through a cube-shaped room while holding a mouse button to swing a sword over their head and smash apart blocks that are moving towards them. As the player destroys more blocks, it becomes obvious that they can swing their sword faster and faster. Once the sword is swinging fast enough, the player takes off into the air like a helicopter, and the controls change to simple flight controls. This evolution of the gameplay is intended as a red herring. Since everyone at the event knew what the theme was, we knew they'd be looking for a bug, so we put this in to take them off guard, thinking they'd found it.

Our real bug doesn't occur until later, however. As the player continues to destroy enemies, their sword continues to swing still faster, causing their speed through the air to increase. This continues until they're moving too fast to control themselves and will inevitably run into a wall. The walls are programmed to allow the player through if the player is moving fast enough, to simulate buggy collisions (we didn't use actual buggy collisions because we wanted to be able to control this behavior). Once the player passes through the wall, they find themselves in a much larger room, with the previous room only a small box in the center of it. At this time, the old enemy spawners inside the smaller room deactivate, and new enemy spawners in the bigger room activate, spawning larger enemies and in greater number than those of the smaller room. This was so that the player would still be able to aim at and hit the enemies in this larger room while moving at extremely high speeds.

As the player continues to destroy enemies in this room, they continue to gain speed and will most likely realize that they are expected to gain enough speed to break out of this room into another even larger room. Thus, the player learns our novel progression mechanism on their own, accidentally. Once the player breaks out of this room they find themselves in another even larger room, which is the final room we designed.

We intended for the game to end at this point. However, when we had club members playtest the game, we found that they were actually able to break our game's physics and break out of the final room by getting enough speed to phase through the wall for real. At this point, they found themselves flying out into a black, empty void, with the exterior of the final cube behind them. They have escaped from our game about breaking physics by using our own mechanics to actually break physics. We consider this to be a fitting end to the game.