This next series of 1-pixel games is built on the same pixel class than the previous series, from a programming point of view. As before, I’ve limited my action to manipulating the different states the pixel goes through without adding functionalities.

This new series sees the replacement of the “press any keyboard key” action by “hold any keyboard key”. As for the previous series, I will iterate on the rules and attempt to describe the evolution of the system. Here is the behavior for the first pixel of this series:

Hold when Black

It’s pretty evident that this system is nothing but a glorified button that requires to be pressed for a certain time before turning white, then resetting back to its initial state. I’ve embedded the prototype below for illustrative purposes.

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.

Press when black - with Lose state

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.

Notice the subtle change in the title? As I had added a timer to the white state, in this iteration I add a timer to the black state, effectively creating a loop that doesn’t require human input.

Press when Black - timed loop

The title of the two previous iterations, “Press to win”, doesn’t quite apply here anymore, since the previous initial state, black, no longer waits for player input. The new rule creates a window of opportunity for successful interaction (since white doesn’t accept any input). Of course, the title is also part of the experience and since it also looks like a little like an instruction, I believe I can safely say that this system has much more ludicity than the previous two. An improvised test session tended to show that people end up trying to press the button as fas as possible when black appears, which is a good testament to the improved ludicity of this prototype.

So, I’ve added just one rule and all of the sudden the dull, simple interactive system of the two previous examples became a simple and dull game-like interactive system. What do you think just happened?

My hypothesis is that the time loop allows something not to happen, thus sparking different nodes in the user’s mind than those used when using any non-game software. When something doesn’t happen in a regular piece of software, you get frustrated and blame the developer, but when something doesn’t happen in a game-y piece of software, you tend to blame yourself. And so you try again, and again, until you reach your patience’s limit and then blame the developer.

Could we perhaps think from this that games are systems that accept, integrate and exploit failure? I think we could…

EDIT: I forgot adding a link to the prototype (swf), silly me.

Next up, I’ll add a single rule to my previous simple interactive object: when it has stayed in “white” state for a while, go back to “black”.

Press to win - looping

The looping structure is pretty evident in the graph. The pixel will stay black until a button is pressed, which will make it go white. After a certain delay, the pixel will turn black again. Still no hint of ludicity here, but at least you don’t have to manually restart it.

You can download the executable here (swf).

I’ll kick off this series with the basic object I’ll be manipulating over the course of the exercise. It has two visible states, black or white and accepts as input the press of any button on your keyboard. The input also has only two states, pressed or not pressed, depending on whether any or none keys are being pressed. Continue reading →