Thumb Stadium: Eight Games Using Just Three LEDs

I’ve recently spotted on GameSetWatch a note about ThumbStadium, a ultra-minimalist gaming console. With an interface composed only of three leds (green, green/red and red) and two buttons, we’re far from the “now-gen”, and yet this proves once again that you don’t really need so many bells and whistles to create a fun experience.

Continue reading

Burning the candle on n ends (with n > 1)

Picture this: after having graduated from a fairly prestigious public game school with a heavily academic and independent-development-oriented curriculum, you immediately land a job at a big-name publisheloper (publisher + developer) as a designer on a top seller, yearly released license.

As usual with that kind of gig, the pay is nice, you have lots of good workplace relationships, you have vast resources at your disposal and the overall quality of life is better than average. On the other hand, you also need to learn how to cope with the -sometimes Escheresque– logics of HR, Business and Editorial services. You also need to deal with yourself-from-two-years-ago constantly whispering you’re sometimes just reinventing the wheel and treading familiar paths.

Is there a way to reconcile what you were taught to do and what you are doing now? Let’s find out together.

Continue reading

“Borrowing” vocabulary: Diegesis

While working on games, I’ve come to notice how often the games industry borrows vocabulary to other media; mainly from movies and literature due to their shared strong narrative component.

I was thinking about game interfaces and HUDs and I remembered a word I had heard associated to film music. The example was a scene from Casablanca (1942) where Sam is asked to play “As time goes by”:

[google-video]http://video.google.fr/googleplayer.swf?docid=-4762321617067761203&hl=fr&fs=true[/google-video]

What you need to look out for are the two pieces of music in this scene: “As time goes by” heard when Sam plays the piano, and the ambient strings heard when Mr. Bogart appears and everyone starts chatting.

The difference between these two pieces of music is that, for “As time goes by” we can see Sam performing the tune, whereas the other piece of music comes from an invisible, intangible orchestra the characters can’t hear. Film people say Sam’s tune is diegetic, while the nondescript orchestral piece is non-diegetic (or extradiegetic).

The Wikipedia page for “diegesis” sheds more light on the matter:

Diegesis may concern elements, such as characters, events and things within the main or primary narrative. However, the author may include elements which are not intended for the primary narrative, such as stories within stories; characters and events that may be referred to elsewhere or in historical contexts and that are therefore outside the main story and are thus presented in an extradiegetic situation.

The concept of diegesis is embedded in Narration, as it was defined by Greek philosophers in opposition with mimesis, and permeates most narrative art forms. Moreover, since the Narratology vs. Ludology debate cooled down a few years ago, it has become widely accepted that narration (in its broadest sense) is present in most games, which leads to acknowledging the validity of the existence of diegesis/mimesis in a game.

But how does all of this translates to real-world game development and design? A simpler, more utilitarian definition given by Étienne Souriau (and mangled by me) goes like this:

Diegesis: all that is supposed to occur, according to the fiction which the [narration] presents; all that this fiction would imply if it were supposed true.

What this simpler, easier to handle definition allows us to do is to give some examples of diegetic and extradiegetic elements in existing games, which might give you (the reader) a better way to express what you mean when designing, criticising or just playing games. That’s the beauty of accurate vocabulary!

Game interfaces are the element that would most benefit from a better understanding of diegesis. Since they are used to convey most information related to the game state, they are instrumental in how the player relates to the fiction evoked by the game. Non-digital games tend to have interfaces (boards, cards or figurines) that symbolize game elements without being integrated in its fiction. Card  and dice games often have evocative names, but they are mostly abstract activities with little to none fictional elements, which might explain why their interface (cards) has derivated towards the purely mathematical. Their function can be thought of as mimetic, i.e. as a direct expression of the game system with no fictional component. Board games, however, have stronger fictional components and many try to let players develop a narrative. This led to their interfaces becoming highly specialised objects displaying different levels of diegesis. For example, let’s compare these two boards:

Diplomacy board

Diplomacy board

Chess board

Chess board

Both games are fairly cerebral, turn based strategy games built upon the same theme (war), and yet their boards show large differences, both in appearance and their diegetic levels. Chess is an old, old game and probably lost much of its narrative elements throughout his history. Its current form is fairly abstract and doesn’t reinforce the original theme, which remains only in the standardised shape of the pieces. Diplomacy‘s board, on the other hand, goes well with the fiction its designer intended for the players to play in. By mimicking the look of a WWI political map, the players are encouraged in buying into the game’s fictional world in which they are world power leaders plotting with or against each other. This leads us to say that Diplomacy‘s interface is diegetic, while Chess ‘s is almost entirely non-diegetic (or almost mimetic, if you want to see it that way).

As games become larger and more complex, their interface starts integrating objects of different diegetic levels. This might be because complex systems are easier to be understood via narrative (sequential) methods rather than by symbolic (simultaneous) ones. Modern non-digital games often feature cards, figurines, boards, books or any other material, some being used to reinforce the narrative while others are there just to help the player keep track of the game state. For example, in pen-and-paper roleplaying games, the rulebooks, character sheets and the dice are extradiegetic interfaces just because medieval -or space- heroes dont walk around with sheets of paper describing what they can or can’t do. But when the GM takes the role of a shopkeeper or hands them a map the players have been given, he or the map become diegetic interfaces to the game being played.

Video game interfaces are very interesting case studies. They can be roughly approximated as a combination of two elements: a display and an input method. The displays shows the state of some game objects (or all of them in simpler games) using a given perspective the player is able to modify (or not) by using the input method. This input method is also used to modify the state of game objects using predefined rules, which are very often opaque to the player (in opposition to non digital games). Both the display and the input method can have different diegetic levels. A good example for a diegetic input method is using a joystick as an input method for controlling a flight simulator. The associated display can also be diegetic if it simulates being in a plane cockpit, but not if it allows the player to see his plane from afar. First-person cameras are often diegetic while third-person cameras are often extradiegetic, with one notable exception:

Lakitu, from Super Mario 64

Lakitu, from Super Mario 64 (1996)

The reason why I’m okay with calling a tortoise-that-floats-on-a-cloud-holding-a-camera-on-a-perch a diegetic third-person display is because he is embedded in the fictional Mario world through a variety of cheap tricks (refer to the game’s introduction, or the mirror room). Strange at it would seem, thanks to these pirouettes the player just accepts the presence of a floating camera as something coherent with the game world he moves in.

Although interfaces are the most easily observable objects, it is important to point out that diegesis can also apply for game mechanics, if you think of them as narrative ressources. To remain with my previous example, the fact that Mario has an arbitrary amount of lives is extra-diegetic: we were never told why Mario was able to come back from the dead a limited number of times, nor why did he gain one extra life when he collected a certain amount of coins. Mind you, I’m not judging the quality of “n lives” as a game mechanic, I’m just saying that the designers of the game didn’t think necessary for that particular mechanic to be diegetic.

A recent counter-example to this is the new Prince of Persia (2008). Some have argued that this game heralded the “death of death” in videogames, but I believe that isn’t very accurate. You “die” a lot in that game, and you still get that old tinge of failure when you miss that platform and plummet into the void. The only difference is that your death is presented in a diegetic manner: When you fall, Elika’s superpowers (which have been properly introduced earlier as of divine and benevolent source) kick in and she rescues you at the last moment. The mechanic’s almost the same, it’s only it’s diegetic levels that vary.

Again, I could give many of different examples, but that would only lenghten this (already quite tedious) post.

If you had to take something away from this article (it’s okay if you skipped the above), let it be this:

Diegesis is applicable to all kinds of games, but there’s a simple tradeoff: an object with a high level of diegesis has more sense (narratively) and works towards the overall coherence of your game world. However, diegetic elements are harder to “read” and do not convey information in a clear and concise way.

Having precise and inambiguous names for our tools is half of the battle won. A designer aware of this property will be able to fine-tune the levels of diegesis of his game elements to strike a perfect balance between immersion and accessibility.

Hope it helped.

Eric Viennot interviewe Stéphane Natkin

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.

1pxg: Black/white + extended input ~ Alphabetical

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.

Gamels: Why bother anyways?

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 .

Gamel categories

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…

1pxg: Hold when black, release when white -with random successor and timer, and colored warnings

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!

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!

1pxg: Hold when black, release when white -with warning and random successor

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

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!