Balthazar Auger

To conclude this exercise, I’d like to present you with the final bouquet. This is the most complex system of the series and features a new kind of warning state. Here it is:

Randomness everywhere!

Featuring random choices both in state timer lenght and state successor, this prototype flirts with the limits of the “hold” mechanic for the current constraints. It attempts to avoid the pitfalls encountered throughout the different prototypes by introducing warning states that give a hint to the next state.

But does more complex equals more fun? Check it out:

Click here to show/hide the prototype

That’s it for this series of prototypes. For the next exercise I will stick to just two colors (black and white) but will expand the input capabilities of the pixel class.

Thanks for sticking around!

In an attempt to make the random successor rule visible, I’ve replaced the tolerance period between states by the graphical warning.

Random successor with warning

This prototype is somewhat flawed too, for the similar reason than “Hold when black, release when white” was flawed: when the system exits the generic warning state, there is no way of knowing if the next state will be black or white. Try to guess more than three successive states by trying the prototype.

Click here to show/hide the prototype

The transition between states is now obvious, but there’s no way of knowing which state will be next other than guessing. An intended game of reflexes became a game of pure luck with just a cosmetic change. What about that!

Another experiment with randomness, this time applied to the way states follow each other. When a state’s timer is depleted, there’s a random choice between both black and white states to see which one will be the next.

Random next state

The main issue here is that this prototype feels a little like yesterday’s, but for the wrong reasons. Since the tolerance is of the color of the state it precedes, when a “black” state follows another “black” state, the transition tolerance is black too. What happens then is that we have some states that seem to last longer than others, only because they are made of several successive, similar states with no graphical indication of transition between them.

Click here to show/hide the prototype

The main takeaway from this experiment is that for something to gain existence in a virtual system, it must be visible or have a visible effect on something else. If a rule has no visual manifestations, there is no way for the player to know it exists.

Next prototype will be an attempt to make the “random successor” rule visible.

Today’s prototype is an attempt to remedy the limited interest of the previous iteration by using a very cheap trick: random intervals.

Cyan nodes indicate the presence of randomness.

Random intervals between black and white states

Random numbers are often used as a cheap method of renewing an experience who would otherwise feel repetitive or stale. The addition of an unknown variable in the system undermines the feeling of control (and boredom) one develops when confronted with a grokked system. Please give the following prototype a spin to see what changes when adding a random variable (time, in this case).

Click here to show/hide the prototype

I believe it is safe to say that this iteration feels more interesting than the previous one. Next prototype will see a variation on the random variable.

This prototype is very similar to yesterday’s in its general form, the only thing that changes is the graphical appearance of the tolerance. I’ve turned it into a less violent flicker than the “lose” state in order to measure the effect of graphical artifacts. The new systems goes like this:

Grey indicates the blinking warning, or "tell"

Maybe it’s just me, but I get the feeling that this version feels less hectic than the previous one. I believe it’s due to the fact that with the tolerance mechanism, you are always catching up to the system, whereas with the warning mechanism you anticipating it. Catching up generates a feeling of urgency or surprise, while anticipating gives a feeling of control.

Click here to show/hide the prototype

I’ve assumed that this prototype bears ludicity since it’s just a graphical modification away from the previous one. Nevertheless, this iteration is relevant in the exercise just to show that although cosmetic modifications have no active effect on the system flow, they influence our perception of it in a passive way, giving in this case an impression of urgency or control.

And this is for a simple system… In most modern videogames, the sum of all the small passive influences the varied and detailed graphical objects have upon us often outweigh the strong influences of the game system. In short, this gives credit to the expression stating that graphics can either “make or break” a game.

In an attempt to render yesterday’s prototype more playable, I’ve added a short “tolerance” time in each state during which input state doesn’t matter in order to play nice with human reaction times.

Hold when black, release when white with tolerance

The impossibility issue is averted thanks to this short tolerance factor. The system can now be experienced in his entirety (the user sees all states at least once) and has gained some ludicity. I suggest you try it out to see how it goes.

Click to show/hide the prototype

On the next prototype, I intend in changing the appearance of this tolerance phase just to see what happens.

Yesterday’s prototype was flawed, but a loophole in the rules still allowed avoiding the lose state, at the cost of the desired reflex-based challenge. Today’s iteration sees the addition of a rule concerning the “white” state. The “release when white” rule is implemented as a transition to the lose state if any button is pressed while in the white state. The new state flow is as follows:

Hold when black, release when white

Ugh, now the prototype is really broken. No workarounds, no loopholes, it is impossible to not lose at the end of the black state, given the insane speed one state transitions to the next. You can see for yourself if you desire:

Click here to show/hide the prototype

There’s nevertheless a very obvious lesson to be drawn from this: while failure is an important part of games, it is important to remember that it must above all have a reasonably attainable victory condition (or ways to avoid losing). Games can be insanely difficult, but never impossible.

I told you it was an obvious lesson… I’ll try to fix it on tomorrow’s prototype.

Following some of the lessons learned on the previous series, this next iteration features a “lose” state. The conclusion of the previous exercise was that a system who could process failure and gave specific negative feedback could yield ludicity.

The resulting system behaves like this:

Hold when Black with lose state

Upon analysis, it becomes apparent that the addition of a “lose” state actually breaks the intended behavior. Since the human reaction time is higher than the speed of a computer, it is impossible to anticipate the change of state. The system goes straight to “lose” when exiting “white” because a human hand will never be fast enough. Even trying to match the timing is near impossible, since we’ll always be less precise than the computer.

And still, there is a way to avoid losing. Bonus points if you discover it!

Click here to show/hide the prototype

If you found the way to avoid losing, good! Did the flaw in the system ended up becoming a source of ludicity? Or was it the fact that I challenged you to find a workaround?

One lesson we could learn from this is that ludicity depends on context. Taken as is, the above system is flawed and fails at fulfilling the requirements for satisfying the reflex-based play announced in the title of the system (Hold when Black). But when adding a different context, the game shifts from being reflex-based to being an enigma. In this case, since I can’t display text with my pixel, the context is separated from the system, but still it obviously influenced the way you felt about it. Modern games are usually able to display text and other non textual cues to give context to your actions and keeping you on the desired course. What is sometimes called “emergent gameplay” is when a player replaces the provided context with his own, thus changing the actions he will perform to have fun. Speedruns, stunts, performances and  griefing are some examples of these context shifts.

Spoiler: how to avoid losing

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.