Balthazar Auger

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.

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.