The Tiny Game Design Tooland other little useful things.

Written by Federico Fasce

Hi!Hello there! My name is Federico Fasce

And I’m one of the cofounders of Urustar, a small game design studio located in genova, Italy.

A game is a system capable to generate emotions through

agency in a ritual space.

Here is our little definition of what a game is. That’s just what a game is for us, and it defines what kind of games we love and we want to make.

Games like Ed Key and David Kanaga’s Proteus

Or like thathgamecompany’s Journey.

How we (don’t) work.

So, how we do game design? Let’s start saying how we don’t (always) work.

The Game Bible

We kinda hate the whole concept of Game Bible.

We feel it’s an enormous waste of paper and energy

Rule #1NOBODY reads the Game Bible.

That’s because of various reasons. First one is that you get always the feelings nobody really reads the Bible. Actually, is very difficult to cover all the complexity of a game system in a linear document. Even the game designers are often puzzled when reading the bible.

Rule #2The Game Bible is NEVER in sync with the

project.

Secondly, it’s very hard to keep the documentation up to date.

Rule #3You write the game OR you write the

Bible.

Third, you tend to write documentation when you have to write gameplay instead.

How we REALLY work.

Now, here’s how we are trying to work now.

The FIELD NOTES METHOD

(still experimental)

This is our experimental method.

Based on SCIENCE!

We took inspiration from the voyages of the Beagle

Where a young Charles Darwin was doing what every science and naturalist does.

To observe, take note and learn from what they see. Our methods works in a same way. The project is conducted in an iterative fashion. For each iteration the game designer publishes a document divided into two parts. Each part is further divided into two paragraphs.

Description

First part is descriptive. Here the game designer observes and describes how the game is like.

#1 Observations(What is right? What wrong?)

The designer start with general observations about what is right and what is wrong in a game.

#2 Results(What has been achieved?)

Then they state the results. What goals the team achieved with this release?

Prescription

The second part is dedicated to prescriptions: how the designer intends to address problems and improve the game?

#3 Hypotheses(What possibilities emerged?)

First, they state the hypotheses: what new things could the team add to the game? What stuff seems to make sense now?

#4 Corrections(What will be done next?)

Then, the corrections. Each problem emerged in the first part is now addressed with a possible solution.

Only two rules1- Each part of the field note is open for

comments.

2- Only the game designer can publish a new field note.

All this stuff has just these two simple rules.

The TINY GAME DESIGN TOOL

Another little thing we produced is the Tiny Game design tool

It’s a small tool meant to be used by beginners and in game jams.

For further information about this one, have a look at http://tinygdtool.urustar.net.

Mechanics Dynamics Aesthetics

MDA Framework

Hunicke, Zubek, LeBlanc – 2004

Playing a game is a voluntary attempt to overcome unnecessary obstacles.

Bernard Suits

http://tinygdtool.urustar.net

Everyday in our office.

To finish, these are some tools we use when in office

##MARKDOWN(because Word is too mainstream)

Markdown has quickly become the standard for all our documents. It’s fast, easy to use and exportable pretty much everywhere.

http://davidseah.com/

The emergent task planner

The ETP by David Seah (http://davidseah.com) is a great instrument for activity tracking

And Basecamp suite is unvaluable to keep all the team on the same page.

Just a little game.

AlienEater

This is our newest little game. We made it using the Field Notes system.

Thank you!

federico@urustar.net@kurai

@urustar