How many stomachs does an interface have?

Interaction design for a game is a difficult task, because it requires the designer to create a classification system that has a limited number of classes yet is flexible enough to represent a great number of objects in the game world in an easy-to-access way. Often this is a matter of the distribution of the semantic workload between the graphic interface and the various other input peripherals (such as mouse, keyboard, or gamepad) Since each input device has a unique character, the result of the combinations can be highly different.

Looking at the various input devices that we have at our disposal today while playing games (keyboard, mouse, guitars, steering wheels, Wii controller etc), we see that they can work on very different levels of abstraction. For example a keyboard enables spelling on the phonetic level. On the other hand, the buttons of a mouse or a gamepad are more like ideograms. Combinations of these various input devices will be a basis for various naming and calling conventions, all of them constructing worlds with different qualities, quantities and behavior.

However, often the success of interaction design will depend a lot on how the graphical interface will digest the game world and decompose it into the semantically nutricious pieces that can be than passed over for further treatment to other “stomachs”, such as the menu bars, keys and controllers. In that sense it could be said that interaction design is like establishing a digestive system with many stomachs, like for example that of a cow (hence our initial question: how many stomachs does an interface have).

To digest or not to digest, that is the question!

To digest or not to digest, that is the question!

Here, however, the digestion works on a linguistic and semantic level. Often, the graphic interface will make the first big digestion and break down the virtual world into a group of semantic and narrative cores which will be then ready for processing on the next level, that of the button arrangement on the gamepad for example. The classification that decomposes the game world into units will set the constraints for key assignments or the type of input device that will be sufficient to turn around things (For example interaction design of RTS games for concoles is known as a true challenge). Through this digestion on several levels, the game world turns into a classified system of existents and interactibles that enable the player to take a course of meaningful action in the very context that the same digestion process has constructed. Achieving the appropriate levels of categorical sensibility through this process of decomposition will be mostly depending on the finesse that lies behind the design of this system of stomachs.

Through classification of random objects, the interface creates a world with recognizable patters

Through its system of classification, the interface creates an order: The random mix of objects turns into a world with recognizable patterns.

Let’s just remember some good examples for now (Who likes to think of bad examples anyway?): Diablo had a wonderful simple point-and-click interface which had classified the game world into three categories of existents (of which all could be simply unified under one universal category, “targets”): these were killables, collectibles and destination.  The player who used the mouse had no need to further explain what action she wanted to take. To click on the interface, depending on where the mouse was resting at that moment, either meant “kill this”, “collect this” or “go there”. A further category of actions could arise from an additional decomposition provided from the mouse: left-click and right-click could mean “kill this (with this)” or “kill this (with that)”. Continuos clicking would repeat the action, which meant that the number of actions was also easy to give in. In short: The various “stomachs” had decomposed everything perfectly, therefore the game had a very fluent process of “spelling”. It got particularily well along with the very addictive reward schedule. All this created a great, zero-friction game flow.

Another example is the infamous The Sims. The Sims also had a very digestive interface, but this time one which nested almost all “verbs” into the two interactible classes, “objects” and “characters” (the difference here is one based on humanistic assumptions, technically there is no difference between “character” and “object” in the way The Sims decomposes its world). It constructed a multi-layered deep world with this method. The player wasn’t bothered with much spelling procedures to express the actions she wanted to be done, she just chose them from a palette. The dominant “sentence structure” or grammar that allowed for communication between player and game world was:

Subject  – Object  – Verb

For example:

Character A – Character B – kiss.


Character B – Fridge – Prepare Dinner

Each sentence that the player constructs was displayed within the frame of the screen via a system of “uniform” icons on top of the screen, so that the player could edit the “paragraph” of events that he had just “written” through the orders she dispatch onto the characters. If she didn’t want a sentence to be carried out, she just deleted it from this “visual list” of future events. This high level of digestive groundwork was reducing the semantic workload of the controller a lot and gave the player great time and freedom for strategic thinking.

Modern gamepads can take over a lot of the semantic workload in todays games though. In fighting games like Tekken a player may “utter” a great number of attacking and defending moves without any procedure hat involves the use of the interface. But as much as it seems like the graphic interface does not do a lot of work in this genre, it is again the way in which the world was decomposed through it, that allows the game design in general to focus on detailed gamepad use during the spelling of actions.

The Snowflake: A Model for Stories with Branching Structures?

Today I was at the local bookstore. As I was looking for a copy of Homer’s Odysseia, I came accross a section dedicated to Orhan Pamuk, the Nobel-Prize winning turkish author. An illustration on the backcover of his book Kar (Snow, published in 2002) suddenly catched my attention. Here it is:

Illustration from the backcover of Orhan Pamuk's novel "Kar" (Snow, 2002)

Illustration from the backcover of Orhan Pamuk's novel Kar (Snow) dating back to the year 2002.

The cover artist combined a stylized snowflake with the names of characters and sections in the story. I don’t know wether it was Pamuk’s own idea. But suddenly I heard myself saying: “Stories are like snowflakes: They all look alike, but still each one of them is unique.”

More than that, I think a snowflake model could be useful for game writers that work on stories with “branching” structures.

Game Idea #10

Today I’m celebrating my 10th game idea in my marathon of 52 Game Ideas! Cool! Never thought I’ll make it this far!

This week’s game idea (originally prepared for the “Make Monopoly Fun” design challenge at Game Career Guide) is a board game. It is a derivative of  the infamous game brand Monopoly. Here, however, you’re not trading real estates, but internet domains. The rest is almost the same. Read more about the differences below!

Finally I also want to add that by submitting this idea three days earlier than I normally should, I have repaid the three days delay during the submission of game idea #8. We’re fit now, are we?

Game Idea #10



Times have changed. Monopoly Man is no longer the type of business man that is able to see the new opportunities out there. He simply belongs to a past world. But thanks god there is Will Gates, the young Generation X business man! He gives Monopoly Man a great hint: ” The new generation of businessmen invests into virtual estates. It’s no longer the age of Monopoly, but that of DomainZ! Nah, don’t worry; the rules of the business are still the same… errr, almost. We still invest in properties; but they’re virtual and located in servers. Neighborship works a bit different in virtual space: You use banners if you want to connect your domains; you don’t need to have them adjacent anymore. With enough server power you can run e-stores and link them for combined sales! It’s really very easy. And I tell you one thing: Those who visit your domains will spend lotsa money there! Got it?”

“Hmmm” says Monopoly Man, “to be honest, it sounds a bit complicated, but hey, I haven’t lost my spirit yet, so let’s give it a try! You’ll help me, Junior, will you?”

“Betcha!” says Will, “Why don’t you say hello to DomainZ! then? C’mon, let’s start by buying ourselves a server, then… Oh, a server? Well, Monopoly Man, a server is…”

Backcover art for Domainz! chance cards.

Backcover art for Domainz! chance cards.

General Description

In DomainZ!, the real estate squares from the Monopoly game are replaced by squares that represent internet domains. But like in Monopoly, players can buy as many domains as they desire. A major difference in DomainZ! is that before players can buy and start to make a profit from their domains, they must set up servers. A server can only manage three domains at one time; therefore each possible triangle of domains will require the player to establish an additional server. This will result in players growing their own server farm over time. A player who cannot afford the required server structure cannot buy new domains. There will be also server down-times (caused by luck cards “Server Maintenance!” squares) in which the affected domains will not be able to charge money from the “site visitors”. A player can further develop her domains by adding e-stores and banners to them. Both these methods multiply the income gained from “site visitors”.

The banners are placed on the board to connect the 'domains' to one server.

A "screenshot" of the game board: Banners are placed on the squares to connect the 'domains' to the server. Domain cards complete the process.

In contrast to the classic Monopoly game, in which players had to buy adjacent squares to build houses and hotels, in DomainZ!, players can link remote domains with banners (indicators with identical colors that can be placed on squares) to create groups of domains. In other words, the squares and property cards no longer have colors printed onto them as it was the case in Monopoly. In Domains!, players are free to link (and therefore neighbor) any squares they wish. All that players need to do is to buy banners and place them onto the related squares to show that they are linked with each other. Once the player has the money to add banners to his sites, a general indicator will also be placed onto the board, under a server token.

In DomainZ!, every player starts with one server in hand. The number of servers can be increased. But each time the player passes the internet gateway (start square) she must pay a maintenance fee for her servers. The first player who is, after selling all her assets, still unable to afford the fee for at least one server is the ‘absolute’ loser of the game. The player with most servers, domains or cash (in this order) at the moment of defeat will be accepted as the winner of the party.

Event sample from DomainZ!

Sample events from DomainZ!

Last Words!

If skyscrapers were the ultimate signs of the real-estate based economic imperiums of the age of Monopoly, today,  the world-wide recognized domain names of multi-billion virtual businesses are the signs of economic power. DomainZ! is a board game that tries to capture this change in the world. Instead of trying to bid for the Broadway, now you can bid for the precious’ of our new age, Facebook, Youtube or Google. 

Game Narrativity continued

I’m right now in a very fruitful process of writing and diagramming my thoughts on Game Narrativity. I don’t really know where it will carry me to, but I just feel somehow that something “programmed” in me knows the way. Whatever that thing is, it feels right and I feel I need to follow it.

 One of the diagrams I prepared this evening. Click to enlarge!

A diagram based on the completion levels concept in Barthes' structural analyses of narratives.

A diagram based on the concept of Completion Levels in Barthes' study on narrative.

There is a collection of little “theoretical tokens” and at some point I need to join them all together into a single framework. I don’t know yet when that moment will come…

Another theoretical token:

The three roles a game designer will have to construct while designing a game

The three roles a game designer will have to construct for the player of her game.

 And another one:

A classification system that enables the player to perform on all narrative levels

The Interface, a classification system that enables the player to perform on all narrative levels.

Oh my, I really need some feedback on all this!

The Actionary

Here is an example of a possible entry for the Actionary:
 1. n. the button aligned to the bottom of the right button panel of the DualShock Controller for the Sony Playstation. 2. v. graphic user interface. to confirm. 3. to continue (a sequence). 4. to skip or end (a sequence). 5. gameplay. to fire or send an object (ball) or projectile (bullets) into a often pre-determined direction. 6. to perform a basic attacking or defensive move against an enemy. 7. to activate or deactivate an object or process such as an elevator.
Genre specific uses might be treated like registers or professions.

Game Narrativity

On the night from September 14 to September 15, I wrote down the following:

“The video game is a narrative which requires additional levels of communication in order to allow the three basic narrative levels -functions, actants and narration- to engage into the necessary complementary relationship. Only after this complementary relation has been made possible, the process of signification can continue towards its ultimate level: that of the narrative itself.

And more.

One of these additional levels of communication takes place between the expositum (the “so-far” exposed) and the impostor (the one to respond to the logical system (situation, argument) that the game state equals to at a given moment). The “language” that enables the communication between the both defines a grammatical process that requires the matching of player actions (via the use of a set of tokens embedded into game controls) with world objects that are made present and accessible through a system of classification graphically woven into the texture of and presented as a user interface. Each combined system of controllers and interfaces equals to an unique language system with its own tokens, ways of coding/articulation, and the possibilities, limitations and sensibilies that it creates for the various “utterances” that it enables through its configuration. These systems do not simply reflect the world that has been designed; they actively construct the world with all its subjects, objects, verbs and adjectives.

The interface is basically the graphical embodiment of a group of binary oppositions woven into the texture of a surface through the establishment of figure-background dichotomies. It can be seen as an arrangement of “contours” that “exist” against a often “dead” background. Neither of them can be present alone; they require each other. However the “background” is silenced into a state of functional death as soon as the countour has created the functiomal figure/foreground. The figures which can be called/mobilized through the use of the controllers, divide the virtual world into two basic groups of objects which make up the highest rank of all binary oppositions in the world of the game narrative:  Existents and interactibles. The interface is calling these object classes into life by “naming” (objectifiying) them and is therefore turning them into “beings” that can be subject to the “verbs” (actions) of the “speaker” (the user) of the language (the figure-control key arrangements). Therefore, like in any other language, the interface (and the lexic body that it proposes) does not simply reflect the virtual world; but, like natural language, it does construct it. Using game controls to connect interface objects (or Names) with actions (verbs) assigned to certain keys, can be seen then as parole (an utterance) guided by langage (the sign system of controls and interface). This is a system with its very own grammar, since we have to “spell” our actions “correctly”, if we want to “mean” what we say. The possible “words” that can be said through this system of signs make up an Actionary, rather than a dictionary. Indeed, narrative are often said to be constructs made out of predicates.

It took so long. But it’s finally there. Now I have something to continue with.

Game Idea #9

This weeks game idea has been inspired by the Game Career Guide challenge “Marketing Bullets“, where you had to submit three selling points to be put on the back of the retail box for a traditional WWII FPS. As I tried to differentiate the game from competing products (that was what the challenge asked for) I throught that it’d be cool when the soldier we control is daydreaming when he travels through the environment or rests at certain spots in the game world. The idea came from movies like Jacob’s Ladder and The Thin Red Line, in which the heroes involved in the war are actually questioning human nature, violence and war and see visions during the process which can be both very poetic and very scary. This also comes a bit close to the first of the Max Payne series, in which our character had comicbook-style visions that were explaining the backstory and plots in the game, while also trying to deepen the character.  However in this my idea, I rather want to create a feel that is close to the stream of consciousness technique in literature: So I want cutscenes to be superimposed onto the actual game screen in sections of the game where the player is not involved in combat. Joining a group of soldiers that sit in a corner, staring at the sky or other “trigger frames” would start the daydreams and continue them until the player “wakes” himself by moving the mouse. The visions could vary, but they would be related to a puzzle that the soldier tries to solve: Maybe they will give clues about the shocking truth that the character we play was used in a  military experiment  without his consent and that he is actually already dead, and that all that he is playing through as he tries to solve the puzzle are his last visions as he is trying to be saved in a hospital by surgeons… without success though…  as it is the case in Jacob’s Ladder.

Well, this weeks game idea is, as you see, not very structured. It just tries to present a feature that could help distinguish a WWII FPS from the rest of the competition. And maybe another difference is that it is not really pro-war, although it engages you into combat.

I think I will give the idea the title Jacob’s Ladder for now.