Team Dangerlabs

The team for the Dangerlabs app includes such shining stars as:

• Luke Smith - Coding and UI
• Sam Dight - Coding and UI
• Ken T - Art and animation

After our preliminary meetings we have nailed down the core of our app, which is a game based on my driving experiment from the last project. The object of the game will be to survive as long as possible, while being theoretically chased by something. There will be speed brackets in which certain things will happen.

• At low speed, you will lose 'life', meaning the pursuer is getting closer.
• At medium speed, you are safe.
• At high speed, you gain back 'life', a reward for taking the risk.

Crashing into cars will slow you down, depending on the respective properties of the two cars involved, and this will in turn reduce your 'life' giving the pursuer chance to catch up. When your life has run out, it's game over, and your score is the time you were able to survive for.

There will be powerups to collect on the road, like missiles to blow up cars ahead, and advanced vision so you are warned of on-coming cars in particular lanes. There will also be a configuration screen before play, where codes can be entered to unlock different cars, control methods and powerups. These codes must be obtained from the website, and we might try to date-lock them so they only work on that day. We want to achieve viral marketing with this game, and also drive traffic to our main site, so this is the main business strategy of the game.

Byron also mentioned 'renting' unlocks, which you can buy later with points. Perhaps every day there is a different code, usable for that day, which allows people to try out different things in the game. Later on  they could use in game points (or real money if they buy the premium game) to unlock a certain thing permanently. I think this could work well for us.

We are wary of using the microphone too much, so an idea at the moment is to have a boost button that activates the mic and allows you to do an audio speed boost thing. This makes the game more fun and silly and entertaining, but also means the core game can be played in silence or in locations unsuitable for making silly car sounds.

Accelerometer steering and/or acceleration will be tested, and I definitely want accelerometer steering to be an option in that start screen (not an unlock). If it turns out to be much more fun, we will likely make it the default steering method.

The Finished (Experimental) Products

So here are the three experiments, what I was trying to accomplish with them, and how they differ from the original concept.

Speed Freq
Every game needs a good pun in the title, amirite? So I had to change the name to Speed Freq.

The concept has also moved away from the complexities of F1, and onto a nice straight piece of highway driving, featuring lane changing. The actual game layer (with points and goals) is not explicitly defined in the final app, but it is certainly implied by what is fun to do and what is not. With more space and a better sense of position, I found this view was more involving yet also encouraged experimentation, and it isn't too punishing. Making a sound that rises or falls continuously in pitch will make the car slow down or speed up accordingly, and this takes the majority of the brain effort, so the lane switching is kept simple - just tap the button and the rest is automatic.

The idea is less 'clinical racing precision' and more 'make silly car noises and have a laugh', which is indeed what happened a lot in testing. I demo this by whistling, the purest way to make a clean frequency with your mouth, but making various loud and strange car noises works just as good in most cases.

The cars are sprites from the original GTA, just so I could concentrate on the experiment itself rather than on graphical production values (which is not the point here) while still communicating the theme as best I could.

Tune Flyer
This ended up more abstract than it started out, but that just proves that this game concept needs no setting to anchor it, it just makes sense. There are 5 colours involved, all mapped to a specific frequency range. When the app hears that frequency (it ignores low ones to cut down on noise) it changes the colour of the player (the ball) to be the corresponding colour. Collecting blocks of the same colour gives a point, whereas crashing into other coloured blocks will take away points. Again, as with Speed Freq, there is the option to display mastery of the sound input or move the player out of harms way in many situations, providing a nice judgement call for the player but also different styles of play.

Ear Drums
This was earmarked to be the simple app that had some character, and initially I was planning to make a sort of multiplayer fighting game, but the further I got into detail with that system the more pointless and not-fun it seemed as a game. Basically the system just wouldn't work, and would always degenerate into all players recognising their cues successfully, and luck determining the winner every time. Lame.

So Ear Drums is a return to a previous idea about interacting with an on-screen character via audio. Whistling above a certain frequency will start to annoy him, and continuing to do it will aggravate him more and more severely until his head explodes. Sadly I lacked time to make the head explosion more satisfying, as this was the last app I made and the others were much more demanding to even make playable.

Image.move vs Image.y

It appears that Image.move(x,y) is much more reliable than Image.y. I found this out by pure luck, seeing the move method in the auto-complete. I say 'more reliable' because I have used Image.y and Image.x to move images in other parts of my program, and they are perfectly happy.

So odd.

This is beyond ridiculous

So my issues aren't to do with anything complicated I've done, it seems. They are to do only with this line:

this.y -= (speed - pSpeed);

This seems to be because I am using -=, since I have run some simple tests which work under some circumstances and get a white screen of DOOOOM under most others.

This works:
this.y = 300 + whiteLineOffset;  //whiteLineOffset is a variable used elsewhere that changes over time.

These do not work:
this.y = this.y + 1;

this.y += 1;

var temp:Number = this.y;
this.y = temp + 1;

I am stumped.

Dynamically adding/manipulating components

Man is this annoying. Right now I have written a class that extends the Image component, and can add it to the DisplayList with addElement, but the entire screen goes white if I try to move it's y position.

WTF.

Too Much Mic Control

I had another little freak out yesterday, when it seemed that my graphics would only update when the microphone was picking up signal.

I went off on all kinds of worried tangents about how it could be a limitation of one of the many things I am using that are outside my control (or outside my immediate understanding), but sure enough, there was a simple line of code I had written a while back preventing the updates (and other things) from running.

Freq Out

Awesome.

So it turns out that:

1. My new Android 2.2 phone does not support AIR, and is therefore useless for development.
2. Pitch detection is not a trivial problem and involves several steps and lots of signal processing maths to do right.
3. The built in spectrum analysis methods (SoundMixer.computeSpectrum) cannot be used with mic input.

Annoying point number one is at least mitigated by the fact that I am developing audio-based apps, which are perfectly testable on the dev machine. I'll just need to try securing an iPad at school a few times to test and make sure things still work.

Annoying point number three is mitigated by the generous Gerry Beauregard and the FFT that he wrote in AS3 that I am allowed to steal. He is using his own FFT to analyse mic data in realtime, so this suits me perfectly. Initial tests are promising.

So that just leaves annoying point number two. While I have had some success getting a pitch number to change as I make noises (whistling is definitely the cleanest so far), the numbers will need some serious filtering and the games will have to be designed around this. For the racing game, I think this is quite doable, but the Tune Flight game needs a bit more finesse than I can currently get. At least one of my concepts is not dependant on pitch detection.

Three Experiments - Concepts

After being shown some of Takeo Igarashi's intriguing and hilariously cute interaction experiments with sound input, I was inspired to create some games with this as the starting point. The following are my best three concepts for game-based interaction experiments using the microphone as the primary input.

Tune Flight

You fly up the screen in your triangle ship (or the blocks come down to you) and you must tune your ship to the right frequency to fly safely through a block, collecting a point. Colour is used as feedback for the current tune of your ship, because you have to hum or sing into the mic to tune it and you have no point of reference otherwise. Steering could also be possible, with soft keys or accelerometer.

Shouty Fight

Sprites by Oryx

In Shouty Fight, two fighting characters are oscillating automatically between five states, randomly. In a rock paper scissors fashion, each combo of states has either one winner, or it's a draw. If either player notices that the state is currently in their favour, they shout at the screen to attack, and will score a point.

F1 Racer

F1 Racer is about racing a car using the pitch of your voice to govern speed. Because this is inspired by the more strategic racing of F1, though, you don't just try to come first. Your team is shouting orders at you constantly to hold various positions for certain amounts of time, to pass cars, or to lap someone, so you have to stay on your toes and move around in the pack to keep getting points.