Atelier
Challenge 5: Coffer Chase
The following project/game is called Coffer Chase
The following people who created this game are:
Ton Candido
and Marishka Zachariah
Project Logline:
Project Description:
The following
project is an experimental game involving a webcam, a projector, opaque
liquid (milk), interactivity of objects and people, and a Processing
GUI that recognizes a colourful tracker.
The player
controls a token, which is read as a ship on the processing GUI. The player can
view both token and the layout of the game on the dish.
The player
maneuvers the token by blowing on the token to advance the token. The player
must control their breath in order to control the distance the boat goes. Each
level is a labyrinth the player must advance through. If the player loses all four lives, it's game
over.
There are various
items within the game that affect the gameplay:
Door:
Doors guard the
entrance to the next level. They can only be unlocked with a key.
Key:
The boat must find
the key to unlock the door.
Rum Barrel:
This is a power-up
where the player gains an extra life.
Coffer:
The coffer or
chest, is the player's objective, as the player must reach the coffer to
advance the next level.
Mace:
This is an object
the player's ship must avoid while maneuvering through the level. If the boat
hits the mace, they lose a life.
The last level is
timed so not only must the player must retrieve the key to unlock the escape
route, avoid hitting walls and the mace, but get out of the level as fast as
possible.
Based on the cards we chose, the pirate/island/searching-for-treasure seemed most fitting, especially for a one-player type of game. Limitations on symbols also gave us some limitations on ideas (at first) but found that the set of cards that we finalized on made it easier to go with a ship-wrecked and search for treasure type of game.
Intended audience: people who love interactive
games that may have a similar concept to a game like Space Invaders but
involves mechanics that keeps them active and gain a different experience with
different controls.
Games with
devices and peripherals like Kinect allow players to be more engaging not just
with their game, but their environment. They not only develop increased
dexterity but also increased awareness of their interaction with an object in
real life that effects the game in real time
Exectutable/Download/Discovery Pathway:
There is no downloadable file: however, we the code used in Processing.
The following are Tom's notes:
On this game we used color tracking with
Processing and a Web Cam. The basic principle is that Processing analyzes each
pixel of the image of the camera and sees which ones have a color that matches
the pre selected color. After that, the software tracks the color and projects
the boat on the spot with that color.
In order to get the better contrast, we used
a bright fluorescent pink color and had the software iGlasses to intensify
the color, making the tracking more stable.
Part of the tracking code:
void Tracking () {
// Before we begin searching, the
"world record" for closest color is set to a high number that is easy
for the first pixel to beat.
float worldRecord = 500;
// Begin loop to walk through every
pixel
for (int x = 0; x < cam.width; x
++ ) {
for (int y = 0; y <
cam.height; y ++ ) {
int loc = x +
y*cam.width;
// What is current
color
color currentColor =
cam.pixels[loc];
float r1 =
red(currentColor);
float g1 =
green(currentColor);
float b1 =
blue(currentColor);
float r2 =
red(trackColor);
float g2 =
green(trackColor);
float b2 =
blue(trackColor);
// Using euclidean
distance to compare colors
float d = dist(r1, g1,
b1, r2, g2, b2); // We are using the dist( ) function to compare the current
color with the color we are tracking.
// If current color is more
similar to tracked color than
// closest color, save
current location and current difference
if (d < worldRecord)
{
worldRecord = d;
closestX = x;
closestY = y;
}
}
}
----
In order to have a maze, we used a Collision
Map image that prevent the boat from getting out of the path. The
collision map image is a blck and white file, in which the white color is the
path and the black color is the place where the boat can't go.
Processing analyzes the pixels of the map
and keep the boat in the maze.
color black = color(0);
color white = color(255);
// go through each row in our
collision map image
for (int i = 0; i <
colMapImage.width; i++) {
// go through each column in
our collision map image
for (int j = 0; j <
colMapImage.height; j++) {
// get the color value
of the pixel at our current position
color c =
colMapImage.get(i, j);
// if the pixel is
black
if (c == black) {
// we can't go
there
collisionMap[i][j]
= false;
}
// if it is white
else if (c == white) {
// it's good to
go
collisionMap[i][j] = true;
}
Development Notes:/Troubles
We were
inspired by the dynamic of a player playing a game with water. None of us had a
Kinect (nor did we want to fish out money for one) and decided to take similar
mechanics from Ton’s solo game challenge using a projector, webcam, tracker and
a dish full of water.
After some
thought (and based on the fact that we had to stick to one symbol) we used the
following cards:
Experimental
Game
About Time
Involving
Navigating
Regarding
sustainability
Involving
treasure
Involving a
projector (wild card)
Using these cards,
we formed out game into a labyrinth-like game where the player tries to collect
the treasure but must escape the island once it receives the treasure before
it’s too late.
It was simple
enough to come up with an objective using an object that the processing GUI
would track, but the main challenge was how to implement the most important
mechanic in the game: moving the actual token/tracker in liquid.
At first we
came up with the idea of moving the token with our hands. However, it seemed it
would make the game too easy and tried to think of a better challenge.
Using a fan
or something to create wind for the token to move came up, but thought it would
cause too many ripples in the water and kept that aside for now.
Another
obstacle that came up was the liquid to use in the game. The inspirational
video used bath salts so we tried a bath bomb/bath ballistic at Lush. However,
it did not produce the opacity required to view the game on a liquid surface.
The best
solution was opting for milk, as it had the most opaque white surface that
would project well.
To give more
substance to this searching game, we considered many challenges:
We thought of
sustaining the game during the game by having it so that it may sink in a
matter of seconds/minutes and had to get it to the end of the level before it
sinks. The player had three tries to salvage it but once it was used up, that
was it. This mechanic was scrapped due to getting a little complicated.
We thought of
using coins and have it so that the player can achieve a high score or complete
a percentage of the game based on the amount of coins collected throughout all
levels. We scrapped this in the end because based on timing; it was too much to
add on top of coding a tracker.
We thought of
having it challenging for players that if the token hit a wall, they lose a
life and the level restarted. However, this also proved too much to code.
We finalized
the mechanics to finding a key in the level that unlocks a door to the next
level, having moving maces as an obstacle to avoid, and having a countdown
timer at the last level when the player must “escape” the island.
Ton
programmed the game and Marishka designed the levels and did most of the design
work.
Programming-wise,
the big challenge was getting a portable webcam calibrated enough to recognize
the tracker. We experimented with various materials (pom-poms, film storage
container) and found the best tracker was a black Bristol board with red string
attached, as it was the most recognizable and the easiest to manoeuvre.
Design-wise,
we first used illustrator to outline the levels. Marishka outlined where items
should be place in the level (e.g. the door, the key, etc.). Both Illustrator
and Photoshop were used to create the objects and levels for the game. We had
to make sure that the levels and objects had no red colour in them or else the
GUI would red more than just the tracker and would mess up the gameplay.
We started by
making the pathway white to provide better contrast but opted for blue as the
boat/token “sails” through its course/quest.
For the title
of our game, we googled pirate glossary and discovered that Coffer meant a
chest containing treasure. We went with Coffer
Chase as alliteration tends to work well with titles as well as suited the
context of our game.
Setting up
the game was interesting as well. We used a shallow 28 × 45 cm dish and filled it halfway with
milk. Using a clothes hanger, we placed the dish at the bottom and attached the
projector and webcam* with tape. Their lens facing directly below the dish
*due to the
poor webcam quality, we have used a laptop as well however it can be risky. The
laptop running the GUI is nearby as everything is connected to the laptop.
Overall, the
final product worked very well. The levels were clearly shown, and the tracker
worked. Furthermore, the mechanic of the
player using their breath to move the token worked very well (Marishka and Ton
play-tested this with a food container and there were barely any ripples).
 |
| Testing calibrating using another file |
 |
| Materials used to set up the game. Pom-poms and string were tested as potential trackers. |
 |
| Example of outline of a level indicating where objects were placed, the start and end of the level. This is level two of the game. |
 |
| How we intended to set up the projector and dish. |
 |
| original notes outlining a maze, and equipment required for game |
 |
| this was one of our old ideas where the tracker/token eventually sinks over time and player is required to sustain it throughout the game. |
 |
| Design notes for levels and objects used to advance level (e.g. key) |
 |
| first level |
 |
| second level |
 |
| 3rd level layout |
 |
| placeholder for objects. At the time, we were still considering having coins in the game |
 |
| designing the key in Photoshop CS6. |
Future Directions:
Use a
different liquid that won’t expire/go bad easily. We only experimented with one
type of bath salt, so doing trial-and-error to see which bath salts produce the
whitest consistency would cease us from wasting nutritional food.
It would also
be interesting to include the mechanic /challenge of the token losing
health/lives if it hits the wall. This will help players strategize their
breadth control or at least be more pressured in doing so.
Having a high
score factor would be nice especially if the game was presented professionally
and make people more competitive with others and themselves by either
collecting lots of coins or beating their escape time.
Use dramatic
music when the timer starts.
Finally,
using a Kinect would product much more of a variety of mechanics for players to
use. For instance, we could introduce NPCs that players can kill by using their
hands to form a “power up charge” and direct it at their target (see
inspiration video above).
+-+Default+Texture.JPG)
