Balthazar Auger

Je sors de mon long silence hivernal pour vous pointer rapidement vers la première partie d’une interview qui s’annonce excellente, “Enseigner les jeux vidéo“.

Mr Viennot nous présente Mr Natkin:

[Stéphane] est capable de vous parler des mécaniques de dramaturgie mises en œuvre dans certains jeux et, dans la minute qui suit, d’évoquer, avec la même précision, le processus de création de Sol Lewitt (qu’il a exposé dans la galerie qu’il créa dans les années 90) avant de prendre quelques instants plus tard une guitare (il en possède une bonne douzaine) et de vous interpréter une chanson des Stones ou de Bob Dylan dont il possède la voix nasillarde.

A lire (et à suivre) sur l’excellent blog de Mr Viennot.

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.

Following up from the simple alphabetical proximity, I’ve decided to try another method for key search, this time based upon the physical arrangement of your keyboard keys. Proximity is now dependent upon whether a key is physically adjacent to another key. Of course, the limit of this approach is that it’s limited by the many different models of keyboards. For the sake of simplicity, I’ve limited myself to the standard qwerty and azerty key arrangements

qwerty keyboards

Click to show/hide the prototype

azerty keyboards

Click to show/hide the prototype

My hypothesis is that linking the virtual system (the pixel) to a physical representation (your keyboard) makes it a lot easier. The alphabetical proximity referenced an abstract arrangement of values, whereas the physical proximity is direct and obvious. The difficulty in the alphabetical prototypes came from your knowledge of the alphabet, and now it rests solely on your spatial perception skills, which are innate.

A similar mechanism is used in most current music games: the on-screen representation matches the physical arrangement of the buttons you need to press, instead of resting on an abstract system, like musical notation. This is the source of their accessibility and success: the immediacy of the stimuli-input system shortcuts complex brain functions, giving the player the impression they are “feeling” the music rather than “reading” it.

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.

I was in the process of seeing through the release of the first commercial game I’ve worked on, kinda kept me away from the blog.

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.

Alphabetical proximity

You must find the right letter. By the way, do you know your abc?

Click here to show/hide the prototype

Hinted alphabetical proximity

The same goal as above, I’ve just changed the way proximity is shown.

Click here to show/hide the prototype

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.

Author’s note: I’m attempting to develop a method for game analysis around irreducible game elements (gamels). This and all the other articles are a sort of log of my thought process, and are not definitive truths. Please feel free to react or comment in any way.

Q: It might seem irrelevant or useless to build a tool for game analysis. I mean, don’t game mags do that already?

A: NO, they don’t. What the gaming press (paper or other) does are game reviews: short and subjective descriptions of a product in order to guide consumers into buying (or not) a game.

Q: Ok ok… So, what about all the talk on game criticism there has been lately?

A: Yeah, that’s a good thing, but it’s not what I’m looking for. Game criticism is very important because it helps us define what games are and what they can be, but since a critique is a literary exercise about a finished product, and since most media critiques are “weak” canonically speaking, they cannot be used as a tool during a development.

Q: And what about Aki Jarvinen’s work on game elements? Isn’t that kinda what you’re doing now, only done better by a guy with more credentials?

A: Well… First off, I must admit I’m a huge fan of Mr. Jarvinen’s work. I think it is a groundbreaking, smart and thought provoking read that should be mandatory in every gaming degree out there. Of course, I also slightly disagree with him on the matter of game elements. It is a very useful tool for analysing a completed game, but I find it too complicated and cumbersome for it to be applicable in the day to day work of a game designer. This is why I set out to find my own model, which is more “tool” oriented than Mr. Jarvinen’s doctoral dissertation.

But the main reason behind it all is that during my studies, I’ve never been taught how to properly analyze and criticize games, focusing on the “craft” of the business. In other media courses, you learn to de-make (analyze) before you get to make. So now I’m trying to learn that by attempting to find a dedicated method to analyze games as games, and not by adapting or borrowing from film or literature (the common method so far).

In a nutshell, what I’m writing about won’t probably become a best-seller (best-blogger?) or change the world, but will at least help me understand what I’m working on a little more .

Author’s note: I’m attempting to develop a method for game analysis around irreducible game elements (gamels). This and all the other articles are a sort of log of my thought process, and are not definitive truths. Please feel free to react or comment in any way.

I had previously stated that a game element could be classified according to two criteria: whether it is abstract or concrete, and whether it is implicit or explicit. I’ve been giving this idea a little more thought now that everything is quieter on the job front, and would like to expand on it.

First off, I think it is necessary to clarify the labels applied to the criteria.

Concrete: Anything that can be seen, heard, touched, or felt in any other way. An object which has a physical manifestation.

Abstract: All that is not covered by “Concrete”. Abstract objects exist only in someone’s mind.

Explicit: Elements that have a direct, measurable or objective effect on other elements. Causality, correlation and deductive relationships.

Implicit: Elements that have an indirect, non-measurable or subjective effect on the player. Belief, emotional and intuitive relationships.

What emerges from these definitions is that the Concrete/Abstract axis is really about the passive nature of a gamel while the Explicit/Implicit axis is about its active nature. These divisions should be general enough to be all-inclusive and non-ambiguous; a gamel necessarily falls into either category and can’t be both at the same time. If an object appears to have characteristics in two opposed categories, this means it is in fact composed of two different gamels.

I doubt these “containing objects” need any description other than “contain gamels”, their in-game function being determined by their contents. Think of them as your computer’s directories.

The next logical stop from here would be looking into how gamels interact with each other…

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.