The Transparency of Mechanics

aibo x-ray.png

In Ian’s prior post on transparency and games he mentions three types of transparency: transparency of influence, transparency of construction, and transparency of reference. Cutting across these facets of transparency I’d like to add the transparency of mechanics which is particularly applicable to any consumer-facing journalistic software, of which games are one instance. To get a better understanding of (1) what the transparency of mechanics involves in journalistic software and (2) how mechanics are currently communication in software I analyzed a number of examples of serious games and info graphics including: SimCity 4, Democracy 2, Oil God, The Garbage Game, Energyville, Stop Disasters Game, The Chevron Energy Generator, Better to Buy or Rent, and Boston.com’s 2008 what ifs. In this post I will mainly address the definitions and in future posts I will consider how the model of the transparency of mechanics presented here has been and can be reified in interfaces.

What I mean when I say “mechanics” is essentially the internal and external state of elements and relationships between elements of a computer program, including the values or attributes and categorizations of elements in the software with respect to their circumstances (e.g. time, place, etc.). A state within a game is the instantaneous value of all elements and relationships between elements. For example, in Sim City the state of the game at any one time slice is the set of all values (e.g. low, med, high) of all attributes (e.g. pollution, education, fire protection etc.) for all games objects (e.g. power plants, residential areas etc.) including how those objects are interacting and influencing each other at that moment.

Transparency of mechanics can be broken out into different facets including:

  • State. What are the attributes and relationships of game elements?
    • The specific WHY of state: a precise explanation for an element’s attribute.
      • This gets at the notion of what the relationships are between elements and what their valence and effect on each other is. For instance, what attributes at the current time-slice contributed to the attribute of the object of interest?
    • The general WHY of state: a generic explanation for an element’s attribute
      • What are the general attributes which affect a given attribute of interest, i.e. what are the relationships and weights to other entities? How do you know the strength and directionality of those relationships?
  • Computation of State (How). How are changes of state computed? How does probability factor into the computation? What is the method of inference or equation governing state change?
  • Explanation for State Change (Why). What was the trigger, event, or decision that affected a state change?
  • Assumptions and Limitations of the Model. How is the model grounded and where does it fail to accurately portray the phenomenon of interest?

Being fully transparent about all mechanics in a game may turn out to be a daunting and in fact unproductive enterprise. This is because of the granularity of transparency that would need to be supported to show the attributes and relationships between all game elements at all time-slices. Do users really need to know about every little state change? The answer is clearly no, but the job is then up to the journalist / programmer to make decisions about which aspects of the model should be most saliently transparent in the final presentation. Another question to ponder here is whether too much transparency in games can ruin the fun of it? And if perhaps by explicating too much you undermine the medium’s abilities to get people to comprehend models via interaction?