Balthazar Auger

Tag Archives: pixel game

Post navigation

One pixel games are a little pet experiment of mine in which I try to find “gameness” or ludicity in minimal systems, namely “pixels” – squares whose only function is to display color. You can check out other instances of these pixels here.

Anyways, I’ve continued working on one-pixel games in the meantime. I was planning to extend the color-displaying capacities at first, but decided to give my pixel the ability to recognize each keyboard key separately. This was previously not the case, as every key counted as a “press”.

The implications of this change is that the possible states of the input device can’t be naturally mapped to all the states the pixel can display. Prototypes derived from this situation should take advantage of this fact.

Since the number of possible input configurations has exploded compared to the number of states the pixel can display, it becomes difficult to find the proper input if not explicitly prompted. This was leveraged for these two prototypes, where the proper input is randomly chosen between the alphabet letters at every new cycle. Theoretically, you would have 1/26 chances of finding the good input, averaging to 13 tries per cycle if you are methodical.

That’s not fun. Believe me, I’ve tried.

In order to make the system more fun, I implemented a hint system that warns you when you hit a letter close to the one randomly chosen. I believe that this mechanism reduces the feeling of being just trying to “brute force” the search and try to be a little more strategic, this being what might elicit the ludicity of the given system.

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.

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.

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.

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

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.

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.

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:

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!

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.

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.