Of Videogames and Visualisations

Thursday, January 06, 2005

Envisioning Information

In his second of three books on graphic design, Envisioning Information, Edward Tufte says, "Credibility vanishes in clouds of chartjunk; who would trust a chart that looks like a video game?" -- I can only guess he meant that videogames contain a lot of unnecessary visual artifacts. But what is an unnecessary visual artifact in a videogame?

I thought it was interesting that in Cartographic Cartwheels Ernest Adams recommends Tufte's works to game designers, and in another article, The Role of Architecture in Videogames, makes the point that visual presentation (of architecture in this case) requires not just function, but also decoration. While videogames are visualisations of gameplay, they do contain a lot of what Tufte would term "junk", but it does have a purpose: to engage the player and not just give them, to borrow Adams' architectural reference, "bare grey concrete".

As Will Wright said in A Conversation with Will Wright, "we start wrapping graphics, sounds, scenarios an events around those numbers, and we're increasing the quality of the experience you have. It has more meaning to you. In some sense it becomes more evocative. You can start wrapping a mental model around that, as opposed to this pile of numbers". So the visual junk of videogames is actually integral to providing players with what Wright terms as a "consistent level of abstraction" without which their "mental model will start breaking down".

I would suggest that the visualisation component of a videogame should be a combination of Tufte's minimalist "data-ink" approach to graphic design with Wright's philosophy of providing players with an "overt metaphor".

Sunday, January 02, 2005

Towards a Definition of a Computer Game

The abstract of Towards a Definition of a Computer Game, by Jouni Smed and Harri Hakonen, reads:

"This paper approaches computer games from three perspectives: First, by defining the properties common to all games. Second, by fitting computer games into Model–View–Controller architectural pattern and discerning common software components. Third, by listing features that players expect from an enjoyable computer game".

I'm mostly interested in the first and second parts, as I see the third as being more subjective. Smed and Hakonen begin their definition games with a quote from Johan Huizinga's Homo Ludens:

"[Play] is an activity which proceeds within certain limits of time and space, in a visible order, according to rules freely accepted, and outside the sphere of necessity or material utility. The play-mood is one of rapture and enthusiasm, and is sacred or festive in accordance with the occasion. A feeling of exaltation and tension accompanies the action, mirth and relaxation follow".

This is followed by a dictionary definition of a game, and the authors' interpretation of what a game seems to be, namely: players, rules and goals. This is illustrated on page 2 of the paper with a figure of three joined triangles (like a fan), with vertices representing player, rules, goal, opponent and representation. The edges joining the vertices show how the concepts relate, e.g. "player" relates to "rules" via an edge labelled "agreement", and each of the three triangles represent what the authors refer to as aspects of a game: challenge, conflict and play. These are described as follows:

"Challenge: Rules define the game and, consequently, the goal of the game. When players decide to participate in the game, they agree to follow the rules. The goal motivates the players and drives the game forwards.
Conflict: The opponent (which can include unpredictable humans and unpredictable random processes) obstructs the players from achieving the goal. Because the players do not have a comprehensive knowledge on the opponent, they cannot determine precisely the opponent’s effect on the game.
Play: The rules are abstract but they correspond to real-world objects. This representation concretizes the game to the players".

The paper then goes on to discern between puzzles, stories and toys, with each being components of games, but not games in and of themselves.

The part of the paper I was inspired by mostly was the introduction of the Model-View-Controller architecture/pattern for describing the software components of a videogame. The View and Model components are relevant to my mapping idea:

"The Model part includes software components which are responsible for the co-ordination role (e.g., evaluating the rules and upholding the game state). The rules and basic entity information (e.g., physical laws) form the core structures. It remains unchanged while the state instance is created and configured for each game process. The core structures need not to cover all the rules, because they can be instantiated. For example, the core structures can define the basic mechanism and properties of playing cards (e.g., suits and values) and the instance data can provide the additional structures required for a game of Poker.
The View part handles the illustration role. A proto-view provides an interface into the Model. It is used for creating a synthetic view for a synthetic player or for rendering a view to an output device. The synthetic view can be preprocessed to suit the needs of the synthetic player (e.g., board coordinates rather than an image of the pieces on a board). Although rendering is often identified with visualization, it may as well include audification and other forms of sensory feedback. The rendering can have some user-definable options (e.g., graphics resolution or sound quality)".

I don't completely agree with the above designation of sub-components, however I like the Model-View-Controller conceptualisation of a videogame, and will use it in my dissertation, as it's likely to be familiar to, or at least easily understood by, the intended audience. There is more to the paper, however what I've mentioned here are the bits I found most useful.