— 1pxg — 1 min read
Building on yesterday’s prototype, “Press when black – with punishment” introduces a new type of state. The system is somewhat similar to the previous ones, but when it reaches “lose” state, the pixel will flicker rapidly before resetting.The flow of the prototype is unchanged, I’ve just added a state that lets the player know when he has allowed the black state timer to expire. Of course there’s nothing innocent in naming it “LOSE” and rendering it as a rather unpleasant flicker. After identifying the need for failure in the previous prototype, I merely added (negative) feedback to it that indicates when the player has not complied with the system premise.
Does this aesthetic modification add anything to the ludicity of the system? I’d be inclined to say it does, as it builds on our love/hate relationship with failure discussed in the previous article. The state flow hasn’t changed, but now one of the paths is much less pleasant than the other.
There are some interesting side-questions we could ask, too. For example, why do we feel the need to press the button when the pixel is black? Is it out of fear to see the unpleasant state that follows, or just because it’s the only moment where our input can be acknowledged? Would it have been better to feature a positive feedback instead of a negative one, and would it have been possible to render using only our pixel’s actual capacities?
Judge for yourselves by giving today’s prototype (swf) a spin. EPILEPSY WARNING: flickering/strobe graphics present.