April 07, 2007
On the role of the die
On the Role of the Die: A brief ludologic study of pen-and-paper roleplaying games and their rules
by Joris Dormans
Extract from Game Studies - the online journal of computer game research
Today, there is a huge variety of roleplaying games. Almost diametrically opposed to the fantasy hack-and-slash play of Dungeons & Dragons are the games published by White Wolf. At the other end of the spectrum are the games of White Wolf, which advocate a very different picture:
We no longer tell stories - we listen to them. We sit passively and wait to be picked up and carried to the world they describe, to the unique perception of reality they embrace. We have become slave to our TVs, permitting an oligarchy of artists to describe to us our lives, our culture and our reality. [...] However, there is another way. Storytelling on a personal level is becoming part of our culture once again. That is what this game is all about: not stories told to you, but stories you will tell yourself. Vampire is about bringing stories home and making the ancient myths and legends a more substantial part of your life (Vampire, 1992, p. 21-22, my typesetting).
White Wolf links roleplaying to children's games of make-believe. The company states that the lessons of these games are still valuable for adults: "this play-acting helped you to learn about life and what it meant to be a grown-up. It was an essential part of childhood, but just because you have grown up doesn't mean you have to stop." In White Wolf"s view the rules of the game are only there to "avoid arguments" and to "add a deeper sense of realism to the story" (Ibid, p.22). The game-rules and settings provided by White Wolf certainly are designed to facilitate the publisher's focus on grown-up themes and stories. Players of their games more often report roleplaying experiences with a strong significance or emotional impact than players who stick to games of fantasy and science fiction.
April 7, 2007 in Design | Permalink | Comments (0)
March 25, 2007
BBC Clocks
The clocks went forward today and here is an animation of an old BBC clock from 1969:
You can see more examples at Cult TV.
March 25, 2007 in Design | Permalink | Comments (0)
February 12, 2007
A to z of Google Information Architecture
Here are 26 different sets of menu items for different Google Services. There must be one Information Architect at Google who has got the determination to bring some consistency to this hodge-podge of menu items.
There is an attempt at being consistent in the menu designs, but someone needs to sit down a write a style guide. The Googlers can't even agree on whether they should be using "Sign Out" or "Sign out". The font sizes are almost the same. Apart from Analytics they all agree on the text colour. The only people using FAQ instead of Help are Alerts. AdSense use Log Out instead of Sign Out, and they put it before the Help item instead of after it.
The A to Z of Google Menu Options | |
 |
AdSense |
 |
AdWords |
 |
Alerts |
 |
Analytics |
 |
Base |
 |
Books |
 |
Calendar |
 |
Co-op |
 |
Docs |
 |
Finance |
 |
Froogle |
 |
|
 |
Groups |
 |
History |
 |
|
 |
Maps |
 |
My Account |
 |
News |
 |
Notebook |
 |
Page Creator |
 |
Patents |
 |
Personalised |
 |
Photos |
 |
Reader |
 |
Video |
 |
Webmaster Tools |
And you may have noticed the new blue menu list that has started to appear in the left hand side of some Google pages.
 |
|
 |
Calendar |
 |
Docs |
They haven't even got the same entries. It is Mail or Gmail? Should it be more or all my services?
Is it so disorganised inside Google that they can't even get these basic items right?
February 12, 2007 in Design, Google, Information Architecture | Permalink | Comments (11)
February 11, 2007
Dreaming in Code - The longest software suicide note in history
I have only read up to page 50 of Dreaming In Code, but from bitter experience I already know what the eventual outcome will be.
Here are the lessons that should not be taken from the Chandler fiasco:
Software is hard. No it isn't. Thinking about writing software is easy. Writing software is easy. The hard part is actually delivering the software.
Design by consensus is good. "I'd like to teach the world to sing, in perfect harmony" may make a great Coke ad, but it's the road to hell on any software project. You definitely need a team to deliver software, but the vision and design should be clearly owned by one person. If it's too hard for one person to hold the design in their head and understand the implications of changes to that design, then how do you expect a normal human being to be able to use the bloody thing.
Big Design Up Front. Think very hard about what you want to do, and why your users want you to do it. Write a few dozen user stories and put them up on a wall. Then deliver those user stories, one at a time. Remember agile principle number one: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
The bottom line is this: Buy the book and read it, but don't expect to be seeing Chandler on a PC near you unless your watching old re-runs of Friends.
Perhaps Chandler needed something like this at the beginning of their project:
It's interesting to note that after Andy Hertzfeld left Chandler to write his book he then went to work at Google.
February 11, 2007 in Design | Permalink | Comments (1)
