CONCEPT:

Our concept was to have a game that’s unlike most of the screen based games and to test out how much can we ‘play’ without visual cues.

We had a simple idea and had figured out pretty quickly how we wanted to do it – using Processing, MAX MSP, A joystick and an arduino.

We were on top of all our sounds and had a pretty decent library of sounds we thought could be informative and make for great gameplay.

We had a few small hiccups setting up the Joystick, reading its output and figuring out what switch is what, but once we had that down, it worked great and was reliable.

We spent the most amount of time going back and forth over coding and what to send to MAX MSP and getting MAX MSP to accurately output the sound based on distance and angle inputs.

In the end our demo looked like this:

Critiques and Reflections

At the very end we still couldn’t decide on a good name for the project and the only ones we thought of were too punny and corny.

1. The Dark Night rises?
2. The Deadly Hangover?
3. Dark Ops?

SETUP:

Our setup had to change slightly from the initial idea.
We setup the speakers on 4 chairs but were forced to ask the user to sit on the floor with the joystick so that the speakers would be at ear level roughly.

It took us about 20 minutes to get MAX MSP and the 4 output audio interface functioning for the demo.

HARDWARE:

We were quite reliable on the speaker quality being able to output the small subtle changes in sound as well as being able to handle multiple sounds layered on top of each other. It was only during the night before the demo that we realized we’d made an awful error.
We’d created the sound radii based on what we thought was a good distribution on a visual map. However, when we were testing it out with the speakers, we began to notice significantly larger amounts of dead audio when moving.

CODING:

While we did have a check for standing, moving, walking, running we didn’t make use of the sound files and actually give this information out very well.
Another problem was our movement. It made sense visually, but there wasn’t a clear enough audible clue whether or not the character was moving or for that matter turning.

SOUNDS:

We really needed to inculcate more of the sounds we recorded to give more audible cues as to what was going on.
The biggest mistake we made was to not have a party sound so that you could know whether or not you were getting closer towards it.

Things we think we did right

Getting Ambisonic codecs to function and having a Processing sketch that could take in input and being able to output how far and at what angle an object is from the player.

Things we could have done better

Not leaving gameplay to the last minute and working only on the hardware and code.

We should have used a multimeter but we were fairly confident it was just a bunch of switches so we hooked up our joystick to the digital pins. When the reading made little or no sense as it was almost entirely arbitrary, we decided to test out Analog.

It was quite counter intuitive as the reading would show ’0′ when we turned it any particular way. I.e. pushing top would result in to the top reading of 0. We decided to go with it nonetheless but still was noticing some significant variance in each of the inputs when nothing was being pushed. We tested for nearly an hour, wiring and rewiring, swapping analog and digital, testing out resistors and all kinds of stuff to figure out why sometimes it would show things as ‘ON’ which clearly were not. Turned out that holding the joystick in our palms as Tony and I were doing was causing a connection between soldered bits of wire at the bottom and making connections that were not intended. So we did the obvious thing and made sure it was impossible to touch.

The final setup was fairly simple.

We divided the coding up between Tony and I so that I did all the Processing coding and Tony the MAX MSP.
At first we decided on a simple algorithm:

then we decided to change it as follows:

This turned out to work a lot better as there was less calculation to be done by MAX MSP which then only had to handle the inputs and play the appropriate audio using the ambisonic codecs

The Processing code also had functions to calculate if the Player was standing or moving as well as a speed function to calculate if they were walking or running and was outputting these values to MAX MSP.

Seeing how this entire game is audio based Tony and I sat down and made an extensive list of the sounds we will be needing which we broke down as follows

1. Dialogue from Protagonist

a) Story Intro
b) On reaching the map edge
c) On getting to close to the element
d) On heading the opposite direction from the party
e) Memories from the party
f) What sort of sounds to look out for
g) What the party sounds like

2. Character effects

a) Footsteps
b) Breathing
c) Heaving breathing/panting
d) Heartbeat
e) Ouch
f) grunt
g) pain

3. Natural Background
a) Crickets
b) Frogs
c) Owl Hooting
d) Wind

4. Scary Elements
a) Lion
b) Monkey
c) Zombie
d) Snake Pit
e) Wolf

James, my talented husband and voice actor came in and recorded all these sounds for us one night and we had a fairly sweet library of sound effects

What’s in a name? Tony and I are working on an entirely audio-based survival game that uses Ambisonic technology.

The basic setup for the game is a player sitting with a joystick, surrounded by 4 four speakers. The gameplay is very audio centric and very minimal information is conveyed visually.

The story we currently have for this survival adventure game is as follows:

An ex-CIA agent is in the countryside for a party. Retirement has been pretty brutal on him and he’s taken to drinking a lot to get through the dullness of everyday life. Unfortunately he gets ridiculously drunk, in a matter of hours and wanders outside the party and passes out somewhere. He wakes up and it’s too dark to see anything. However, he has excellent hearing. He’s aware that the party is nearly over and he needs to make it back soon or else he is going to get behind in the dangerous countryside for a very long time.

The setup of the game is very minimal. The physical interaction is between moving a joystick and listening to the speakers.

We’re thinking of using Ambisonics for Max/MSP to create a 2D sound field around the player using 4 speakers. The Max/MSP externals for Ambisonic encode a monophonic source to a specified azimuth and elevation and transforms the incoming signal into an Ambisonic sound field by rotating around axes.

They can be downloaded here.

Our initial idea was pretty epic. A game in which you could bring any object to the table on which a  simple pong gameplay was projected, and you could use these objects as paddles.

As much as we thought we were on top of this, 10 days before it was due, we realized we couldn’t get the kinect to work quite the way we wanted to. We had switched back and forth between MAX msp and processing. Our projector wasn’t strong us and well, we were nowhere close to refining our gameplay.

We abandoned our idea and agreed on a simple two player spaceships game

The basic gameplay was this – Use your hand to move your spaceship left and right. Try and avoid all your opponent’s LEDs (it’s a PComp project afterall!) and try and hit your opponent with your LEDs.

Each of your health bars are displayed on the left and the right. The one who lasts longest wins.

The fails

We still had a few hiccups. One was the game speed increases every 30seconds so it gets harder, however we forgot to reset to zero every time the game wasn’t being played. This caused a bug wherein when the user were just setting their spaceships for motion tracking, the speed would increment every 30 seconds , causing some players to start in a higher difficulty mode than others.

The wins

People really enjoyed it. Quick gameplay, had a bunch of arcade game sounds and music. They didn’t pay attention to difficulty level but automatically acclimatized themselves to it.

Multiple levels of interactions – Sound, visual and of course movement.

All in all, we started off well, couldn’t get it going and finally saved it by using our skills (tony-sound, sean-coding, me-graphics and gameplay) into something simpler but still just as engaging.

I started off with a simple potentiometer setup on the arduino

Then played around with processing and its Serial library till I got it to continue drawing the line only when it noticed significant change in the input. Shouldn’t be too hard to create a breadboard based etch-a-sketch, I reckon.

The story goes that occupants of a multistoried office building here in New York began complaining that the elevators were slow and especially during peak hours.Management looked into the problem but it turned out that there was no viable engineering solution that was within their budget to solve this grievance. When the problem was put forward in a staff meeting, one employee deduced that the reason behind the complaints over a relatively short wait was quite simply boredom.
So he suggested installing mirrors in elevator boarding areas as a way to give them something simple to occupy their time pleasantly as occupants could look at themselves and each other discretely and politely. This low cost solution was welcomed by the manager and very soon the complaints about waiting came to a stop. Now mirrors in elevators lobbies and in elevators are commonplace.

This is a favourite story of mine as it illustrates just how importance it is to be able to look at the surroundings of your product to make your product more usable and balancing it with aesthetics. Often we tend to jump too quickly to modify our product because of a small usability complaint that has nothing to do with the crux of how the product functions. The “customer-is-king” approach would dictate that you do what the user is asking – i.e. change your product to make it better. But often we need to take a moment, step back and assess if whether that’s really required is fixing the user’s experience that exists in a network of place and time or the product that we try to create such that it’s functionality is independent of place and time.

Continue reading →