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.

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.

Final Design Notes

Due to some domain propagation issues/misunderstandings, I can't use the domain I bought yet (dangerlabs.co) which is a real shame! I really like it. Luckily I intend to use it past this project, so that's something.

Visit my site via the direct link in the mean time.

Major improvements + changes since the interim design:

• Glow on the logo. I feel that this puts across a sense of danger through heat and energy, very brand appropriate.
• Orange/yellow on dark greys colour scheme. I took this from the logo, but the stem of that is in warning signage. Blue is just not dangerous enough.
• Low contrast checkered background. I really like how this looks on the www.minddesk.com site, so I pinched the idea since making my own graphic for it was trivial. It really helps the content sections to pop, and breaks up the flat colour blocks nicely.
• Round corners and bevel-style borders. Trying to learn about and incorporate as many modern CSS features as possible, I experimented with these and found they lent a slick yet slightly cartoony feel to the page - perfect for Dangerlabs.
• Main nav up top. How did I forget main nav in my original design?
• Font choice. I simplified to two fonts, Arial for the body and something similar to Helvetica Narrow from Google Web Fonts for the headings. Caps were a branding choice, they tie into the logo with its warning signage references.
• Full width showcase. The comments on my interim were spot on, when I actually made this card-like design, the real estate I actually had for content was pitiful. I scaled it up to full width and incorporated the nav and title into the block.

How the showcase works:

• Uses jQuery to move a giant <ul> along. It tests the current page container width to figure out the numbers.
• Skips back to start/end when attempting to navigate past either end.
• Reads game title information from an attribute in each <li> and displays this in the title-bar. This way I can change the title without it having to be part of the sliding area, since I wanted the nav to be static.
• Uses a jQuery swipe gesture plugin to capture swipe events in the showcase area and trigger the same <ul> movement functions as the nav buttons.

Interim Layouts

I went back the drawing board on my original layout ideas to simplify and make them more plausible in the time frame we have. This time I designed with the framework in mind, and considered scaling more at every step.

There are 4 layouts for the site: desktop, tablet, wide mobile and mobile.

Front Page
An interesting and interactive gallery/slideshow for pushing Dangerlabs' games is the most important feature, so it goes front and centre. Users will scroll through the series of 'cards' to see info about the different games.

Below that, there are obligatory about, contact and news feed blocks. News will be more relevant to returning users who may already have a Dangerlabs game and be looking for news relating to new releases or updates.

Games Page

The games page is about displaying the game first, and telling you what it's about second, so a big useable gallery is key. Besides those, links to download the games for various platforms are important. These would disappear on smaller form factors, because the games do not support iOS or Android.

Logo Studies

More Aesthetic Inspiration

I remember liking this sites approach to flat coloured design, and they are using light text on a dark background like me. The checkered grid helps break up the flat colour while still fitting into the style overall, I'll have to try that out.

http://www.qubicle-constructor.com/

Discarded Designs

I discovered recently that my workflow for this was backwards. I should have looked at frameworks first, and designed my site around a framework. This would have been much faster. I also came to the realisation that the kind of site I was aiming for was far better suited to a static flash site, and was not suited to scaling at all. Heavily graphical and themed sites tend to be made in flash for a reason I guess.

This was my first design for a front page, with horizontally scrolling sections at the top and bottom. I was unsure how this would scale to mobile, and later heard scary things about absolute positioning etc on iOS, so abandoned it as needlessly difficult.

This design was more static, and was all about having interesting graphical transitions between content blocks. There is a pipe system, with animated sections of liquid, which ties nicely into the branding. The idea for mobiles was that the content blocks would fit within a landscape mobiles screen at 100%, with some space left over to show the little connecting pipes going offscreen to another content block. I felt this was overly static, and the graphics between content makes using any frameworks difficult because there are no gutters. The more I thought about this, the less it seemed suited to the technology we are learning about, so I abandoned this in favour of a site designed specifically to a framework.

Spying on the competition

What do other indie game developers have on their websites? What styles do they employ? I shall examine a few.

Mojang.com

The creators of the revered Minecraft understandably have a Minecraft-centred site, but the branding is separate. They appear to be using a simple blog platform with a few sidebars which are mainly about other social sites and communication in general. It seems more like a hub site to gather other links related to the company, and pushing their merch seems to be their main concern over advertising their games. This is not really surprising given the enormous brand power of Minecraft itself, and the high traffic that minecraft.net receives.

Having separate sites for the games seems to be the norm here, so I suppose I'll have to make the call on whether Dangerlabs is adopting this approach too.

I enjoy the flat, (mostly) two-colour graphics, and the use of greyscale for structural bits and bobs. However, I feel Dangerlabs needs MUCH stronger branding to stay true to the name.

thatgamecompany.com

The makers of highly experimental games like Journey would seem to have something in common with my goals, however there is a major difference in our branding goals. thatgamecompany take themselves a little more seriously, and their dreamlike aesthetic is almost in direct opposition to the punch I want.

In terms of content, though, each page has a layout tailored to its needs and seems to work well. The pages for specific games in particular are very nice, with smoothly scrolling content in several panes and a lot of information accessible without ever seeming cluttered. Their approach of having a landing page to further push the branding is interesting. It has the bare bones of some content, like a mini mission statement, but leaves a lot of room for that bloomy white hand. This could work for me.

thatgamecompany differs from Dangerlabs in that their games are PS3 exclusives, so they provide as much information as possible but do not need to worry about patches, sales or download links. The PC market is a bit different in that respect.

Dangerlabs is open for danger

Well, not yet. But Dangerlabs seems to have won the brand battle, both by popular opinion and my own preference, so that is locked in now. I still don't have a suitable logo, but I'm close to one I think, I know what I need it to say. My fav concepts currently are some combo of a skull and a lightbulb, and packaging it all as warning signage.

One keyword that has come out of me explaining the Dangerlabs concept to people is cartoon science. I'm going to make this the primary touchstone to come back to when making aesthetic decisions from now on, to help anchor everything and get a cohesive feel.

Brand and logo brainstorming (thus far) below.

Ubiquity

Ubiquitous computing has commenced! First mission - make a website for a fictitious company that can adapt to mobile platforms.

Instead of a fictitious company doing things I don't care about, I am choosing to create a not-yet-real company that does things I care very much about. Unsurprisingly, this company is going to make games. I am thinking entrepreneurial thoughts about the next stage of my life so it makes sense to construct something now which I may actually use in the coming years.

First Step: Company identity
Important facts about my company:

• Game developer
• very small team
• interested in experimental gameplay, especially play involving creation and construction
• on the spectrum of cute to cool, we are probably in the middle, incorporating a little of each
• light-hearted
• making games primarily for a niche PC market

Branding

First comes the name, then the logo will follow. Things I want the name/branding to evoke:

• Playful
• Exciting
• Creativity / Construction as a focus
• Experimental / cutting edge

Considerations when choosing a brand name:

• Makes for a good searchable keyword. Hybrid words are best.
• Memorable. Fewer characters are better, and easy pronunciation.
• Not already in use in the same industry (Trademark concerns)

Top ideas thus far, in order of preference:

1. Dangerlabs
2. Octoworks
3. Superplex Industria
4. Bitsmithy

Research & Inspiration

Companies to look into:

• Mojang
• Polytron
• Capy
• Superbrothers
• Data Realms
• thatgamecompany