Artists: can't live with 'em, can't live without 'em

So much quality work done today. Features like the code screen for unlocking and using new cars and powerups, the powerups system itself, auto-lane changing for the players car when a lane closes, and so many little additions and tweaks.

It is unfortunate, then, when the final road artwork is delivered just hours ago, on the night before hand-in, and it doesn't tile properly. So many misshapen and misaligned pieces, and we are going to have to live with it, because it's the last minute and there comes a point when the whole thing needs to be locked down.

/RAGEQUIT

Rest In Peace, Accelerometer, We Hardly Knew Ye

The accelerometer controls just weren't cutting it. I tweaked and fiddled and even tried to optimise a bit, but in the end the inaccuracy and lag was just no fun. In a twitchy arcade style game, laggy and imprecise controls are death, so they regrettably got the chop. Now they lie dormant, commented out like so many other shelved ideas.

In other general progress news (on my end):

• FlexGlobals are in place to make overall app settings and cross-view data a bit easier.
• There is a "game over" state (view, technically) which displays your score, tells you whether you got a high score (by consulting a global highscore XML object) and gives you some nav options.
• The highscores table works, and while the game is being played new scores can be added to it. There is still no read/write using an external XML file, but the way is well paved for it.
• Some bugs ironed out with traffic collisions, generally it's now fun and makes sense. This is tron-style stuff so there are no explosions, it's much more a bumper cars feel.

Sam has been polishing up the other views, my High Scores and Game Over views are coded skeletons and he is adding the visual detail and cohesiveness. Ken has all the cars drawn, and has started the tracks. We have also given him the all important task of making a HUD image to plaster across the bottom of the screen to house all our game information to hopefully let the player understand things better. A good deal of time was spent finally nailing this down today, as we had been going back and forth with ideas and concerns and changes of heart for ages. Even on an iPad screen, information presentation is tricky, and my games do have a tendency to have abstract mechanics and values that need good visual cues to be well understood by the player. Our design for this is exciting though, and I think will enhance the feel of the game dramatically.

The only major things still lurking unfinished are power ups and the codes/options screen for add-ons. Power ups are tricky in that they need to hook into many different areas of code to be effective at tweaking the game rules. They may also require timers, and display of timer information to the player in some cases. We have a raft of powerup ideas, but at this stage of sweeping compromise I expect to be going with the simplest and most elegant of these ideas. Things like a quick speed boost or the ability to fly over other cars. The codes screen is coming along, but needs to actually integrate with the game to change what car image is used (and the cars stats) and what powerups will appear on the road. Obviously this needs the powerups to function too...

Update: Feature Progress

I've finished many of the major additions to the original game concept, in terms of features. Here is a list!

• Dynamic road system (lanes)
• Updated player class (to use extra lanes)
• Dynamic traffic (more and better AI)
• Speed zone detection / game health
• Game timer

The new road system is a queue of scrolling road pieces which fit together, and are randomly generated. I am using probabilities to get the output I want (low chance of opening another lane) and each RoadSection object has an array of 'valid successors' which allowed the RoadHandler to know which road sections are allowed to come next. This keeps all the graphics tight and tiled nicely. It will look dandy with proper art, rather than my quick hacked together test art. It's pretty flexible with height and width of road pieces provided, so it should be an easy transition to new art. We had toyed with the idea of roads that actually turn, but once I fully sketched out the implications of that I decided against it. The AI would have to know how to navigate corners, for a start, and there is an issue with player turning. With accelerometer turning, I had decided to make the only option 'head for the next lane', because otherwise the player could carefully position the car on the white line and accelerate to their hearts content without fear of failure (just like the original GTA!). But with a curved or turning road, the player's car would need it's own intelligence to navigate the moving lane, because the player's only job is deciding when and how to switch lanes. With weaving through traffic and making noises at the iPad all the time being enough of a challenge, I decided corners weren't vital enough to warrant the work cascade caused by implementing them.

The player class can now use these lanes, and detects whether or not there is a lane to switch into. The AI sticks to the central lanes, making these sides lanes a handy occurance. The lane switching speed is much higher now, which is both more satisfying and harder, since it makes it harder to hold the centreline by switching lanes rapidly (thanks Ken for showing me this exploit!).

The traffic AI is simple, but pretty neat. Like the roads, they are in an array and get culled once off the bottom of the screen. They all spawn with a random speed and lane, and are placed always in front of the farthest car (to avoid being stuck on top of one). The issue, and beauty, with random speed is that the cars can catch each other up. So I have made them all check ahead for cars, and match speed with the car in front if they get close enough. This makes really convincing looking traffic line behaviour when the car numbers increase, so that's a big win for such a simple behaviour.

As I showed at the interim, there are speed zones being tracked now. The player starts with 100 health, and when this reaches 0 it's game over. This is a game abstraction, I'm still wondering how to explain this well to the player (what is this thing?), it's something like 'how close are the space police to catching you'. I guess the story of Speed Freq has been glossed over a bit....Anyway, the health will decrease when speed is under 50kph, and increase back up to a max of 100 when the speed is over 70. This bracket will increase as the game goes on (although it doesn't yet) with a graphical indication of how extreme the chase has become. EXTREME! This is the kind of word Dangerlabs can get behind. This little dance is the main game tension, and the timer (which equates to score) shows how long you have managed to maintain it. These figures are just numbers at present, displayed as such for debug purposes, but they can easily take different forms now that they exist in code.

You'll also notice the Back button, provided by Sam, which hints at the other views that are in place. The game has a main menu screen and several other screens besides the one I posted, but that is Sam's area so I'll leave it to him to post. Our task split is more solid now, with me on just the core game view and Sam concentrating on all the things that wrap and support the game itself (of which there are a surprisingly high number). Ken is still on art, and as you'll notice there is no final art in the game yet! He has prototypes and a near-completed car, but this is lagging a little behind what I had hoped. I remain optimistic however.

In other good news, Dangerlabs.co now correctly routes to the site, so we can use that in our presentation. Yuss!

Next to tackle in earnest: Accelerometer controls. Must must must have these.

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.