Step 1. an open game that creates and changes its rules
In a very early state we had the idea of a game without any pre-specified rules. Instead of defining what needs to be done we wanted to encourage the players to discover the different ways of interaction for themselves.
Our concept is therefore rather a toy than a game. As we were provided with a GPS receiver it was very clear to make use of the possibility to make the toy location-aware. Based on that starting point we went for a ball-shaped toy since our location-awareness implies a high degree on moving and dynamic elements.
Furthermore the ball offers different embodied ways of interaction. Without any explanations or manuals every person finds his own way to interact with a ball. Be it by throwing, kicking, bouncing, balancing and so on.
We systematically listed the possible ways to take action on the ball and the reactions from the ball itself. This relation of action and reaction between toy and player is two-sided. On one side the action of a player can cause a specific reaction of the toy. On the other side the toy through its signals can provoke a particular action.
This relation leads us to the behaviour ot the toy where we link some actions and reactions. “Throwing a ball” could be linked with “Change the color of the ball”. This set of implemented behaviour can now be used for a own gameplay. For example: The player who can throw the ball 20 times on a wall and catches it, gets the point.”
Step 2: Urban Defender
This concept offers a huge amount of possible games. Games in a way we never played before. The aspect of location-awareness in toys brings real world gaming into a new level.
To show how this might look like, we created a complete concept of a game which we now call “Urban Defender”.
One idea we had was inspired by gangs in urban places. Gangs are mostly concentrated in one area and they often show where they belong to. They even claim to own their streets.
So we made a concept which was about claiming streets or buildings. But instead of already existing board and computer games we wanted to play it outside in the real world. What if you could run through the city and capture all the buildings. What if you could take over the buildings of your opponent to extend your territory?
You can see in the following video how we imagined the gameplay of “Urban Defender”.
Until now, when thinking about various zones and districts we thought about parks, streets, business buildings - the purpose of the zone. We tried to change this point of view. For our game, not the purpose (business, travel, recreation, eating, entertainement) of the zone is important. The people who identify themselves with the district are important (I live in there - it is my home, i love/hate this district, I eat / work / go to school here). A person who identifies with a district, want’s to own the district. Point 1: Personal Relation instead of Purpose
The second point for us was: Who plays such a game, who would play, would love to play? We found that kids and young adults like to think in areas - they are an important part in their live. They define themselve by borders (which they want to break), they like to form groups, (playful) gangs in order to play. And they like to challenge themselves.Point 2: Challenge and Gameplay
The third point, which seemed very important to us, was that the entry into the game should be very easy. After “buying” the device, the player should just be able to start the game. There should not be an “official” start or end of the game, the players should not have to wait for each other. Urban Defender has no official start or end. Because the city and its inhabitants are always there, it does not matter when the game starts. It just is. Point 3: Simple Introduction
Step 3: Concept Development
After the concept presentation, we planned and organized the remaining twelve days. We wanted to finish the project with a working prototype of our toy and game. We broke down our concept to something we were possible to achieve in the remaining time. Below you see our initial setup:
As you can imagine it was hopelessly oversized, it included full wlan or GPRS client-server communication, a sophisticated online, web-based visualization, and a zone editor. Luckily we managed to trim down the game to a minimum (which was challenging enough to implement.)
This restriction were:
- The Beagleboard and the GPS device will not be inside the ball
- Only one ball is built, we simulate multi-player by changing a parameter inside the ball
- All data is stored on the beagleboard and is not synchronized to a webserver
We made a project plan which included usabilty and interaction tests. Although we had some problems we were able to reach our goals and finished our prototype within these 12 days.