Sunday, 4 November 2012

Formal Design Abstract Tools


Formal Design Abstract Tools


Evening, mortals.

Straight onto the primary matter today, I think; I'm tired and I have other things I want to do. I have little time for dry wit or humorous monologue that no-ones going to read.

I have just finished reading the Gamasutra article, "Formal Design Abstract Tools", which attempts to convey the fact that a comprehensive language for game design doesn't exist, and suggests ways in which one could be created, and some examples of potentially good additions.

Before I began reading, I was given a quote from the end of the article and was asked to explain it once I had finished reading.

"Games are not books, games are not movies. In those media, the tools used... are used to manipulate the viewers or readers, to make them feel or react exactly the way the director or author wants them to. I believe the challenge of computer games design is that our most important tools are the ones that empower players to make their own decisions."

The tools that Doug Church (the author of the article) mentions are the "tools" which are available to a designer, and both metaphorically and in the form of similes relates them to the tools that might be used in science or construction. For example, he says that not every tool should be used for every game, and should rather stay in the "toolbox" waiting to be needed. These tools should be identified across a wide range of games and game types. For example, one should be able to take a tool used in a Real-Time Strategy game and utilise it in a Role-Playing Game.

The tools Doug offers as examples which could be used in a video games design language are:

  • Intention - "Making an implementable plan of ones own creation in response to the current situation in the game world and ones understanding of the gameplay options."
  • Perceivable Consequence - "A clear reaction from the game world to the action of a player."
  • Story - "A narrative thread, whether designer-driven or player-driven, that binds events together and drives the player forward toward the completion of the game."
Church explains that some of these and other such tools work well with others, while others don't. For example, Intention and Perceivable Consequence work very well together when the player knows what they want to do, and can anticipate one or more outcome of this. Say, for example, that a player is attempting to cross a pit; they attempt to jump across, taking the game's physics and their character's abilities into account. If they fall into the pit, the game is telling them that that strategy doesn't work here; the player can see why it doesn't work, and that they should try a different tactic.

However, if Consequence is used without Intention, it can have a negative effect on the player's experience. For example, if the player makes an arbitrary decision without being warned of the outcome, and the consequence is a negative one, then the player will become frustrated because they had no way of knowing that would happen.

Therefore, Perceivable Consequence is most effective when used in tandem with Intention, as this adds depth to the player's decisions, and can make them feel more integrated into the game world.


In my opinion, this article offers a very interesting point. While it seems to take game design as a science rather than an art, it also offers many insights into what can be made into good game design. It's very true that consequences without the player's intentions aren't very good design, while consequences based upon intention can improve a player's experience. Overall, this is an article worth reading, and actually makes a lot of things clear which were previously difficult for me to understand. Formulating something like game design into identifiable qualities can be a big help, though I have to wonder what kind of an impact this would have on a game when put into practise.


NOTE: I've literally JUST noticed this wasn't published; this blog was written on Thursday 1st November. My apologies.

2 comments:

  1. Hi Steven.

    This was an enjoyable read and demonstrates an understanding of the article. You can also use it to refer directly to games you know and have played as examples. This also helps to lock down your understanding. Overall, good stuff.

    ReplyDelete
    Replies
    1. Thank you, Rob, I always appreciate good feedback. One very small thing (I've always been a little sensitive about this): my name is Stephen, not Steven. I know I'm nitpicking with this, and I apologise for that, but I do prefer to have my name spelt correctly wherever possible. Sorry again.

      Delete