Content, tracking and data insertion

The types of content came in three possible flavours – videos, stills and swf animations. They were all slightly different, but shared a lot of common elements, so I created an abstract segment class to handle all the base elements.

This abstract class was set up in such a way that it would automatically load all of the resources you specified in the XML. This allowed the me to load in the main resources for images, videos or swfs, as well as any audio tracks, tracking data, support elements, etc. The basic XML structure for a segment looked a bit like this:

<segment type="video" duration="10">
<resources>
<item id="main">url_to_video>/item>
<item id="audio">url_to_audio>/item>
<item id="other">url_to_other_item>/item>
</resources>
</segment>


Basically, I could get it to preload anything I wanted. Once I had this set up, I simply extended it to suit each of the different types of segments, each of which I will go into now.

Video Segments

Video segment were the most interesting type of segment. A plain video segment was simple in that it just had to be able to load and play the required file. The fun part was the videos that had content dynamically overlaid.

To do an overlay took a number of steps.

Firstly, our video guru (JB) tracked the required areas in the video (and also gave them a clean up while he was at it). This dumped out a massive txt file with all the co-ordinates for the tracking rectangle’s corners. I think he used an app called Mocha?.. not sure about the name.

Next we ran this text file through a python script (that Rob created) that reformatted it into an XML document that we could use in flash.

Alrighty – now that we had it in a format that flash could understand, we could hook it up in the segment XML using a method similar to this:

<segment type="video" duration="10">
<resources>
<item id="main">url_to_video>/item>
<item id="audio">url_to_audio>/item>
<item id="trackdata">url_to_overlay_data>/item>
</resources>
<overlays>
<item userdata="user" trackingdata="trackdata"/>
</overlays>
</segment>


From the above XML you should be able to see that I had an ‘overlay’ set of nodes that linked to a tracking XML file I loaded as a resource to this segment.

I wrote a class that would take in the XML, parse it into a Vector of Point objects (because it was faster that working with the pure XML), and then I would use the current time of the video over the video duration to create a percentage that I would use to figure out which set of points to use for the overlay. I had to do it that way because video’s don’t have a frame property, so we had to kinda fudge it using percentages.

For the most part this worked well, but on some videos there was a slight jitter, so I set it up so that when the XML was parsed into Point objects, I would interpolate an extra Point data between each node so that it would smooth out the motions a bit.

Because the rectangle shapes were never perfectly square I had to use the drawTriangles() method to distort the BitmapData. I wrote a small class to handle the actual drawing of the BitmapData where I could set any of the four corners of the rectangle (based on the Points we looked up) and the number of horizontal and vertical segments to use, and it would spit out all the data I needed to for a drawTriangles() call, including the vertices, indices and uvData info.

So, that’s how we did the actual overlays, but because the images weren’t always the same for each video I had to come up with a way to process the images on a case by case situation.

For starters, I made it in so that in the XML you could specify what data should be used to generate the overlay BitmapData. You could specify the user’s profile pic, the cropped pic, a random friend or a specific friend.

Then, to give myself some more control over how the images were displayed and help them blend in with the videos more, I added in some optional attributes that would adjust the actual BitmapData before it was displayed.

First I added in some basic width, height and rotation attributes to allow the images to be resized to a ratio that better suited the video overlay. Then I hooked up Quasimondo’s ColorMatrix class so that I could adjust the hue, brightness, etc. of the image at run time.

Adding in these properties made it really easy to adjust the overlay images so that they blended in with the videos and looked pretty damn seamless.

Finally, not all of the video overlays were to use the profile pics of the different users – some of them required things like the users name or a custom design. To do this, I came up with a ‘preprocessor’ approach that allowed me to do pretty much whatever I needed.

The way that the preprocessors worked was that I set up a interface that all processors would use. They would take in the FacebookUser object that was based on whatever user data they were told to use, generate a new BitmapData and then return it to the overlay object.

To make the processors more re-usable, I made it so that the actual XML node was passed to the processor as well, so you could add in extra custom data for the processor to work with (A good example of this was all the newspaper headlines that used the same processor, but passed in different titles as extra data in the XML)

What you ended up with them was some XML that looked like this:

<segment type="video" duration="10">
<resources>
<item id="main">url_to_video>/item>
<item id="audio">url_to_audio>/item>
<item id="trackdata">url_to_overlay_data>/item>
<item id="processor">url_to_processor_data>/item>
</resources>
<overlays>
<item userdata="user" trackingdata="trackdata" processor="processor" width="100, height="150" brightness="-50"/>
</overlays>
</segment>


This approach meant that we could basically generate any graphic or style we needed for any video overlay in the entire site – all with a pretty minimal fuss

SWF Segments

The other semi-complex type of segments were customised SWF segments.

Instead of trying to overlay the data on a SWF, we found it better to actually insert the data into the actual SWF- that way, we could lay out any basic animations using place holder graphics, then simply replace them at run time.

The process for this was to set the SWF up so that it implements and interface. Using this interface the app would pass in the data specified in the XML in a similar fashion to the way that the video overlays worked.

There was no real need for preprocessors with SWF objects because the SWFs could apply whatever effects they needed internally. I did leave in the ability to do the usual effects like resizing and brightness though, just in case.

<segment type="swf" duration="2">
<resources>
<item id="main">url_to_swf>/item>
</resources>
<overlays>
<item userdata="user" width="100" height="150" brightness="-50">
</overlays>
</segment>


Image Segments

The final type of segment used in the site was an Image segment. These were the most basic type of segment in that all they did was load and display an image. There was no need for any sort of data insertion with this type of segment so I was able to keep it very simple.

<segment type="image" duration="0.15">
<resources>
<item id="main">url_to_image>/item>
</resources>
</segment>


The image was simply displayed on screen using a timer that ran for the amount of time that was specified in the duration.

Conclusion

So, that is how the Lynx Fastlife website pretty much works. By combining the random story generation techniques described in part 1 of this post to create a story, and combining it with the techniques I described above, we were able to generate a pretty cool customised experience for the users that in theory should never be exactly the same twice.

I could never have finished this project on time or to the standard it was at without the help of all the guys at VJ – namely Erik, Rosy, Cookie, JB, Vincent, Michelle and Simon – it was a massive team effort to get it over the line and hopefully the whole campaign will be successful!

If you haven’t done so already, be sure to check it out at http://www.lynxfastlife.com.au

In regards to flash/actionscript there were two main areas to the site:

• the logic for building the sequence
• content, tracking and data insertion

I’ll give a bit of a run through each of these sections and explain some of the techniques used, but first a bit on info about how things were set up.

Quick Intro

Before I actually began work on the project a lot of the Facebook elements had already been set up. Erik, the lanky Swede I work with, had already created a bit of a shell for the site and created a Javascript bridge to handle all the logging in and gathering of user information.

Once the data was collected from Facebook it was marshalled into objects for use inside the app. Each of the friends featured on the site had their names and profile pics collected, whilst the main user had their name, age, profile pic, some alternative profile pics (if available), a cropped profile pic and some pics from of their gallery.

Once I had all that information I could start building the sequence.

Generating the sequence

The sequence of the story generated for each user always followed a similar story arc consisting of 9 main chapters – Introduction, Breakthrough, Rise, Fall, New Life, Comeback, Golden Years, Death and finally your Funeral.

Each of those chapters was split up into 3 sections for the purpose of the logic. These were main videos, support segments/videos, and then a large collection of photos.

All this content was laid out in XML in a style that kind of related to this structure. Each piece of content was marked up with a url to the content and the duration (there was bunch of other things, but for the purpose of generating sequences they were the main ones).

<chapter>
<main>
<segment duration="2">...
<segment duration="1.5">...
</main>
<support>
<segment duration="2">...
</support>
<photos>
<segment duration="2">...
</photos>
</chapter>


When I generated a new sequence, I would loop through each of the chapters and select 1 main video, 1 support segment, then as many photos as was needed to populate the required amount of time for that chapter. I then ordered them so it would follow a sequence of Main Video, Some Photos, Support Segment/Video and then Remaining Photos.

Sounds pretty simple huh? Yeah. I thought so too. Then came some changes

After reviewing the content it became kinda clear that a totally random approach wasn’t going to work. Some elements just didn’t seem to fit with other elements, and others didn’t make sense without particular backup elements.

A great example for this was the situation where the story took you to prison. It didn’t make sense to show picture of the countryside when you were supposed to be in prison. Conversely, it didn’t make sense to show pictures of prison when you were in a retirement home.

Sooo… what to do? I had to make it smarter.

I added in some extra optional attributes to the XML and came up with a linking system to help tie it all together.

Firstly, I added in a ‘link’ attribute where you could write in a keyword. If an element was selected that had a ‘link’ attribute, the link would be stored, and then any other segments with the same link would be given preference when the app was randomly selecting pieces.

That worked pretty well, but I needed a bit more control. Thats when I created the ‘ignore’ and ‘required’ attributes. If a segment has an ‘ignore’ attribute and it matches a previously selected ‘link’ attribute, it will be removed from the possible pieces that can be used. In a similar fashion, a segment would not be considered for selection unless a previous segment with a matching link had already been selected.

To help prevent users being shown images that weren’t age appropriate to them, I added in ‘minage’ and ‘maxage’ attributes that would be compared to the user’s actual age. If they were outside the range then they would also be ignored.

Finally, I added in an ‘order’ attribute. This was used to force some elements to appear before or after other elements.

<segment duration="2" link="jail" ignore="model" minage="30">
<resources>
<item id="main"&gtpath_to_video</item>
</resources>
</segment>


All this was done using the power of E4X and regular expressions. I won’t go into the gritty details, but basically I did an E4X query on the XML to gather a list of possible segments, then did multiple calls on that list testing each of the conditions until I had either a filtered list to randomly select an item from, or an empty list which meant that there were no more suitable elements.

The code looked a little bit like this:


// instance vars
var regExp:RegExp = new RegExp([previous found links here])
// inside method var list:XMLList;
list = chapter.story.segment.( (hasOwnProperty('@link') && regExp.test(@link)) || (hasOwnProperty('@required') && regExp.test(@required));
if(!list || list.length()==0) list = chapter.story.segment;
// trim back the list
list = list.(!hasOwnProperty('@ignore') || !regExp.test('@ignore'));
list = list.(!hasOwnProperty('@minage') || Number('@minage') < user.age);
list = list.(!hasOwnProperty('@maxage') || Number('@maxage') > user.age);
// bail if there is nothing
if(!list || list.length()==0) return null;
// select a random segment from what is left
var node:XML = list[ Math.floor(Math.random()*list.length()) ];
// if this segment has a link attribute, add it to the reg exp now for future selections
// delete this node from the xml so it cannot be selected again
// return the selected node
return node;


And that was that. I would just loop through each chapter, then through each subset of main images, photos, etc. selecting segments and generating a list.

Once I had a list it was onto the fun stuff – the actual content – but that will have to wait for another post because I’m really tired right now :p

You can read the second part by clicking here

After a bit of messing around with prototypes I finally came up with something I thought looked pretty cool and it ended up getting used throughout the entire site.

The effect was created by taking in a BitmapData of the text I wanted to reveal and then building around that.

First of all, I created two larger versions of the original BitmapData with extra transparency around them. Then I added a GlowFilter to thicken them up a bit before applying a two different levels of BlurFilter to the BitmapDatas.

Next, I lined these up with the original BitmapData and used them as masks for a gradient filled shape I generated (everything was set to cacheAsBitmap so I could do alpha masking). I animated the gradient through the blurred masks with a slight delay between them – this gave an effect of a tapering off type of brightness.

After that I created a gradient filled mask for the original BitmapData which I used to reveal the base image behind the two blurred glows. I had to play around with the timings a bit, but eventually came up with some values I thought worked pretty well.

Finally, just for a touch of class, I added in another small gradient to act as a shine to the text. It used an instance of the the original BitmapData as a mask and simple past over the length of the text a second or so behind the reveal.

And that was that – my pretty cool glowing text reveal effect thingy.

For the transition out of the text I did something a bit different. I wanted the text to decay away, but I didn’t really have a lot of time to get the effect right. What I came up with was a bit of a Frankenstein approach that generated an interesting result.

I started by creating a bit of a mask/guide in an off-stage Sprite. It consisted of a BitmapData generated from Perlin Noise as a base, and a gradient-filled shape that was big enough to cover the perlin noise base.

I then set up another BitmapData as a mask for the original text.

Here comes the fun part. I animated the gradient mask in my guide sprite to slowly slide across the perlin noise. As I was doing this, I did a BitmapData.draw() of the mask/guide into the BitmapData mask of the text, using BlendMode.MULTIPLY as the blend mode. This caused the the areas of the perlin noise that were revealed by the gradient to build up in the mask, hence slowly hiding chunks of the original text.

I hope that makes sense – I am pretty tired as I write this.

And there you have it – the glowing text effect with an added perlin noise dissolve thrown in for free. Hope you enjoyed it

Here is the code – it’s not pretty, but should show you how it was all done – Glow Text Class

You will need to download a couple of support classes – namely TweenMax from Greensock, and the ColorMatrix class from Quasimondo

Here is a quick summary of some of the techniques I used when building this game.

Performance

The first thing I had to figure out was how to manage all of the models and assets for the game. I knew there would be a lot of 3D going on – which is not exactly flash’s strong point.

Initially I started out by setting up a basic camera controller and loading in as many models as I thought I would need. This gave me an indication of what level of detail I could get away with without sacrificing too much detail. This formed the basis for pretty much the rest of the game development.

The next thing I played with was the frame rate. Originally I ran the entire program at 60fps, which was awesome, but as I added in more and more features I discovered that it was pushing the CPU pretty hard.
I dropped the frame rate back down to 30fps which made little difference to the visual display of the game elements, but unfortunately made the UI elements seem a bit sluggish.

To get around it this problem, I split the game up into a variety of different renderers, each running at the minimum speed possible.

The render layer used for the for the GUI elements were set up to run at 60fps, whilst the ‘boats / islands’ and ‘water’ layer ran at a much slower 25fps. There was also an under water layer for a while when I had transparent water, but that had to be removed due to performance issues.

A unexpected positive side effect of this approach was that it prevented a lot of the clipping problems that were occurring between the boats and the water.

Ripple Effects

The ripples around the boats and islands were created by putting a simple 3D plane under the loaded in MD2 models. The benefits of this approach was that it allowed me to keep the complexity of the MD2 model down a bit, as well as making it easy to edit and animate the texture.

Having a plane for the ripples under the boat came in handy for the collision detection as well. It game me a simple shape to check projectile collisions against (there is another invisible vertical one as well).

Explosions

The explosions were a key part to the game. We wanted them to be big and look awesome, but at the same time we were limited by the rendering powers of flash.

We decided to take a billboard approach, which is basically some planes that would always face the camera. Usually this technique looks pretty flat, so I experimented with some different styles and finally came up with a way that I think looked pretty good.

The 3D / After Effects guys created and rendered out some explosion animations that were split into two parts – the main explosion and the flat ripple effect on the water. I created an object that had two similar planes – one for the ripple and one for the explosion. The ripple laid flat on the ocean and never moved, whilst the main explosion rotated around a point at the base, an was angled to face the camera.

Depending on the explosion animation, the pivot point would sometimes be moved to compensate for alignment issues.


To make it look better, I got the 3D guys to render out explosion animation from an angle that was similar to that used by the games camera. This helped give the explosions the look of volume and depth.

Although technically the perspective is not quite correct, it is only really noticeable when the explosions are in the closest corners of the view.

Path finding

Path finding was a big part of Warfare Officer – and a part I put off for too long because of fear… I had never done any kind of path finding before so it was all a learning experience.

I did some reading and found a really good post explaining the A* path finding technique – A* Pathfinding for Beginnners. It explained the technique very well and I was able to knock up my own basic system one Sunday afternoon.

I soon had the boats moving around the world following the A* grid, but it didn’t look quite natural. This was mainly because the ships would move to the centre of each grid cell, moving in an almost robotic manner. I set about figuring out a way to smooth out the path to make it a bit smoother and more boat like.

The technique I came up with was to start by generating the A* path. Then I would draw a line from the first node to each subsequent node until I hit an obstacle. If an obstacle was hit, I would store the last point I reached, before starting the process again from this new point.

What I ended up with was a path that smoothed out a lot of the diagonal movements, making the boats move in a much more direct manner.

Artificial Intelligence

AI is another one of those things I had never attempted. For a first attempt, I think that the computer puts up a pretty good fight.

My approach was to break the AI into two separate parts that worked together – a boat AI and a master AI.

The master AI would run over everything about every 10-15 seconds looking at everything the boats and base could see and figure out a basic game plan. In most cases this would be to have one ship patrol the defensive third of the map, whilst the other two wander out towards the enemy base. The AI would sometimes call for a full on charge at the enemy base when it recognised that the defenses were weak.

The boats would take the master AI’s objective for them and then decide what exactly they would do. If there was an enemy ship near by they may choose to ignore them or engage depending on what their weapon status. The would also occasionally focus all their attention on the enemy base which helped make them a bit less predictable.

When a boat AI engaged the player it would loop through all of its available weapons and would test to see what had a chance of actually hitting them. Once a collection of possibly successful weapons was collated, it would choose one at random, then attempt to fire it.

The position that the AI would aim for was based on the position of the players boat, with a random X and Y value applied to make it slightly less accurate.

To try and make the battle a bit more even, the enemy ships use a slightly shorter range on all weapons. I found that this was necessary to give the user time to engage computer, otherwise they would usually die before they even had a chance to fire.

To stop the game from ‘cheating’ the AI tracks the player’s boats itself rather than using data from the actual game. It stores the last known position of each boat based on what it can see, so if the player destroys a ship, the AI will store that position as the last known position of the enemy and may consider sending a ship there to seek revenge.

In the end, the whole thing runs of a complex set of if/then statements and is governed by a bunch of random number calls to make decisions. I basically just kept plugging in values until I got a result I was happy with.

That sums up most of the main parts of the game. I hope it has given some insight into how some of the systems work. If you have any questions about a particular part, please feel free to post a comment and I will get back to you!

The rest was a combination of some basic 3D and a few little tricks. To find out more, read on

A lot of the inspiration for the coding side of things came from the ABC Flyer experiment over at wonderfl.net. It was a very simple little experiment that went a long way to setting up what became Strike Fighter.

The original ABC flyer used a pretty insane custom 3D stuff which was well above my head. I got the jist of a lot of it, but not enough to be able to work with efficiently, so I started looking for an alternative.

Around the time that I started, Away3D lite (away3d.com/) came out. Up until that time I had only ever used PaperVision 3D, but I kinda wanted something smaller and faster to keep the game running smoothly. I found Away3D Lite to be really easy to use and was soon up and running with a demo similar to the wonderfl example.

The Main Scene

The main scene for the game was made up from a combination of 3D planes laid out at about 90 degrees, with one main plane for the ground, and another two set up for the background / horizon.

The ground plane was simply one big plane that had a bitmap texture applied. When simulating the motion I used a technique I picked up from the ABC Flyer – offset the bitmap rather than moving the plane. This proved to be much more efficient and gave a better result.

The background / horizon was originally set up as one large single plane, but because I used a texture that faded out to transparency I noticed that there was a bit of a slow down. I ended up splitting it into two planes, with the major area using a non-transparent texture, and a much smaller plane for the graduated fade. The visual look what pretty much identical with a noticeable performance increase.

All of these elements were then placed inside a container so that I could rotate and tilt the entire world when the jet banked etc.

The F35 Jet

The model of the F35 jet was a 3D model that the 3D guys at VJ built. I added in a 3D cone at runtime to act as the flame for the After Burner which I simply scaled up and down to suit the speed. I also added in some contrails to the wing tips by generating a series of semi-transparent white planes that were laid out to form a line – (this was done using the missile smoke technique I explain later)

To make the jet change colour to suit the scene I simply applied a predefined ColourTransform to the BitmapData used for the jet’s texture. This of course lead to the rather stupid problem of the jet’s engine flame being tinted as well. To get around this, I measured up the exact spot in the texture where the engine was and reapplied the original colours from that area to the tinted version I had created.

Missiles

The missile were one of the more challenging things to get working the way I wanted.

I started by trying a few simple ideas on how to simulate the motion of a missile, but they all tended to look too circular in their motion. Then I started searching the web for some ideas – it took ages to find something that worked, and it took even longer to tweak it until it suited my game. I would normally link to the site now, but I don’t know where I got it from – most likely gamedev.net.

Once I had the motion working, I started on the graphics. The idea was to draw some planes along the path to generate the smoke trail. This was simple enough to do, but it hit a couple of major problems.

Firstly, the sheer number of planes I was creating / destroying meant that the CPU took a pretty big hit once you started firing lots of missile. To get around this I came up with a pretty simple solution. Each smoke trail would only ever have 5 planes created for it. It would stretch and recycle these planes for the life of the trail.

The second problem I had was that a lot of the time the planes would be draw in such a way that their edge would be facing the camera, resulting in path that looked like it was missing pieces.

To get around this, I simple made it so that each segment of the smoke trail was always rotated to face the centre of the screen. This resulted in smoke trails that tend to work from every position on the screen, except maybe in the dead centre.

Once I had a class set up to handle doing the smoke trails for the missiles, it was easy to port it to contrails on the wing tips, etc.

Enemy Jets

These are actually pretty boring. They are basically just a bitmap texture applied to a plane that is position way off in the distance and scaled up to match the game speed.

Each of the jets actually use the same class, but have different constraints loaded in at run time via XML. This meant that it was easy to debug because there was only one class, and I could also easily tweak the behaviours of each type of jet.

Enemy bosses

The enemy bosses were like a a cross between the enemy jets and the players F35.

The jets themselves are some designs that the 3D guys and VJ modeled up. Like the F35 they are loaded in as MD2 files at runtime.

Their behaviour is a bit like the enemy jets in that there is one common class for all of them, with each being given individual attributes via XML.

Last little bits

Once I had all of these elements built and tied together, I had to create a way to script what would happen when. I came up with a simple xml structure that listed what type of enemy jets to spawn, how many to spawn at a time, when to save a checkpoint and when to fight a boss.

Then it was just a case of creating a manager class that parsed through this xml and triggered the correct items at the right time.

In the end this made it really easy to set up various stages and test out the different enemy units.

Summary

Strike Fighter was the first real serious game I had created in flash and I think it came together pretty nicely. Of course I couldn’t have done it without the hard work from the team of guys at Visual Jazz or the guys from wonderfl and Away3D.

If you have any question about anything I’ve mentioned here (or failed to mention) please feel free to drop me a line.

Whith a very unique style and heaps of options you are sure to create some very cooky characters.

This first release consists mostly of the Jayvatar builder, which is where you can create your custom jayvatar by combining any of the various pieces of clothing and accessories. You can also choose between male and female body types, as well as different attributes, such as height, weight and arm length.

There is even a ‘random’ button for the less visually creative that generates a random jayvatar automatically.

Once you have completed creating you Jayvatar, you can save it and share it via facebook, twitter and email. You can also save a version onto your computer for whatever reason you have in mind.

You can also play around with your Jayvatar in the Javatar Playground.
Here you can make your Jayvatarcan fly around the screen, bump items, crash down, etc.

At the moment the playground is just a Beta version so there is only a limited amount of interactivity happening. There full release will allow you to do a lot more.

As a bonus, those people from Australia and New Zealand that sign up soon will be given a free $10 voucher to spend in store… BONUS!

So what are you waiting for? Head over to the Jay Jays site and create your own..

To help make the learning for fun and keep the kids interested, a major section of the site was a series of mini games with a planet saving theme. It was my job to build those games… I love my job

Read on to hear about the games, and then check them out at VISY Enviromaniacs.

Each of the games had a different theme, focussing on different ways to save the environment. To keep things interesting, we made sure that the games were also different in the way that they played. We didn’t one to have 5 of the same game with just a graphics changed.

As always, deadlines were tight, but the managers and designers that I worked with were right on top of things, so it all ended up falling into place.

Here is a quick run through of what we made:

Recycle Frenzy

Recycle Frenzy was the first game we made. It was a bit of across between Bejeweled, Tetris and a sorting game. Pieces of litter would be added to the bottom of the screen, one row at a time. The player would have to drag the pieces of litter the appropriate bin – general waste, recycling, paper or green waste.

If the rubbish made it all the way to the top of the screen, the game was over.

To add a bit of spice to the game, the player could swap the positions of litter by dragging them around the grid. Arranging litter into larger groups before dragging it to the bin would result in bonus points being added to the score.

Also, by filling up the bins the user unlocked ‘power ups’ that allowed them to do things like remove an entire row or column with a single click.

Keeping with the tradition with these types of games, the speed would gradually increase as the game went on, causing for some very frantic game play – hence the ‘frenzy’ part

Energise the Earth

Energise the Earth is a bit of a strange game. It is a very simple concept, but proved to be a bit harder to build then initially thought.

The basic idea of the game is to collect the energy that is escaping from appliances around the house. As you look around the room, ‘energy tokens’ will jump out from different appliances and you have to roll your mouse over them to collect them.

Each room you enter has a specified number of energy tokens you have to collect to successfully pass the room. If you reach that amount, you move onto the next room. If you don’t, it is game over.

There are 5 rooms in total, including the living room, study, kitchen, laundry and bedroom. If you pass all of the rooms, you start again, but with higher umber of tokens required in each of the rooms.

It is surprising frantic and keeping up with the pace can be quite stressful. Good luck!

Wild About Water

Wild About Water was the second game I had to build. This one was a bit more complex and confusing, but one you get the hang of it, it is quite addictive and satisfying.

The idea behind it is that you have to keep on top of all the possible water wasting events that occur around a house. Everything from fixing dripping taps to covering swimming pools to prevent evaporation. When something goes wrong, you are alerted and given an amount of time to fix the problem. The longer you take to fix the problem, the more water you will lose. If you run out of water, the game is over.

It’s not all bad though. When you fix a problem, you are given the chance to collect that water with your bucket, adding to your overall water total.

If that wasn’t enough though, there are a couple of side tasks you have to keep in mind. Firstly, you have to keep the plants alive by giving them some of your water at regular intervals. Secondly, you have to drag dishes to the dish washer and clothes to the washing machine, making sure that the machines are full before they start so that you don’t waste water.

As I write this, it does sound overly complex, but like I said at the start, once you get used to it, it does prove to be a challenge.

Bitter About Litter

Bitter about Litter is all about collecting and sorting litter. Sounds like fun, I know, but the game does go a long way to making it so.

You control a guy, in a park full of litterers. As they drop throw their litter on the ground, you run over and pick it up. You then bring it back to your bins where you quickly sort it into either waste or recycling.

When there is litter on the ground, your health begins to drop. The more litter that is there, the faster your health will drop. When you put rubbish int the bins, you get a bit of your health back – as long as it is going into the right bin. When your health runs out, the game is over.

To add some more interest to the game, the player is awarded bonus points for sorting items of rubbish into the the bins without making mistakes. There are also bonus points for returning with as much rubbish as you can carry.

Another nice feature we slotted into the game is that the character in the game actually takes on the look of the player’s ‘enviromaniac’ avatar. A small thing I know, but still pretty cool.

Pick Your Packets

Pick Your Packets is all about learning and identifying the different packaging types you may encounter in the super market.

The player is given the task of sorting the various products into either good or bad packaging types. Good items get scanned and added to the shopping basket, bad items get returned to the store. To help them out, when ever they pick up a product a small description is displayed on the check-out display.

As the game goes on, the items on the conveyor begin to come out more rapidly. If the player is not fast enough, the products will begin to back up, causing the players health to drop. If the health reaches 0, the game is over.

Thats pretty much it so far. If you are interested in checking them out just head over to the VISY Enviromaniac site. Also, big Kudos to the team at Visual Jazz who I work with. They did an awesome job on building the site. You can read a bit about it on the VJ site here.

Visual Jazz was rebuilding the entire Baker’s Delight website, and as a bit of a side project we were given the task of building a virtual bakery in Flash. The bakery was to be a high gloss virtual representation of one of their stores, allowing visitors to browse through a sample selection of their products.

It was a simple project with a pretty cool looking result. Read on to find out some of the features, and then check it out at http://www.bakersdelight.com.au/virtual.html.

Going through in a chronological order, the site starts off with a steaming loaf of bread. The loading progress of the site is spelled out in the steam coming off of the bread. This neat little trick was created using DisplacementMap filters in Flash. It was a pretty simple trick, once I learned out displacement maps actually worked.

After that, the user is presented with the store front. All of the different categories are laid out on display in the store. The store was set up such a way that it panned and distorted based on mouse movement, giving the slight feeling that you were looking around a store. It is a very subtle effect, but took some careful cutting out of graphics to make it work without looking like a room made of rubber.

A staff member is situated in the store holding up different promotional signs. These signs can be easily swapped out for different promotions, and linked to any external pages required.

As an extra subtle little thing – if you look closely at the counter you will see that it reflects the mouse along its curved surface. This again was created via the use of displacement maps.

When the user clicks on a category, the camera zooms in on the staff member, who holds up a board displaying all of the products. The products are displayed in a traditional paged grid system. Nothing too fancy going on here – but it does look pretty clean.

When a product is selected, the grid collapses down to a single line so that the details of the product can be displayed. This looks like a simple enough effect, but getting this grid to figure out how it should collapse and expand proved to be one of the most difficult tasks on this site.

The detail view of the product displayed the usual information you would expect. The cool, and possibly over the top, part of this page was that some of the products were shot in a 360 degree fashion, allowing the user to spin/rotate the product around so it could be seen from any side.

That about sums it up. I love it when I get to work on projects like this

Source : www.tugaskita.com

Some interesting 3D modelling and animation coupled with my first attempt augmented reality in flash made for some puzzling times. Drench all that in a healthy dose of girly-ness and you get www.livinmyworld.com.au.

Read on to find out more some of the more nerdy details

The idea behind the Liv doll site was to invite visitors to try out some of the different clothing accessories on a 3D version of a doll. Once they have found a look that they are happy with they can use a webcam and augmented reality to take a photo of themselves posing with the doll. This photo can then be saved, printed or sent on to their friends.

My job as the ActionScripter was to take all the designs, models and animations and make it all work. Easy peasy… sort of.

The base of the site was pretty simple. It followed a basic page structure using on lots of flat colours, shading and bouncy transitions to help bring the site to life. Overall it was a very ‘happy’ site and I had a lot of fun putting it together.

The tricky stuff started with the 3D. Papervison was my weapon of choice. Mostly because I had used it before, but also because we hit some early snags with Away3D and I didn’t have time to try and resolve them.

Because we were allowing the user to change the hair, top and pants on the 3D model, each part had to be imported separately. The 3D guy had loads of fun generating the different clothes, animating them, and then splitting them up for me.

These split up files meant that I needed to create a way to manage the loading of models and the related textures. That was easy enough, but part way through the process we noticed that some of the model combinations resulted in clipping. This didn’t look very good and actually had an impact on the performance.

I discovered that if I applied an alpha channel to the offending model’s texture, the clipping went away and the performance improved (Sounds strange right? Adding transparency made it run better? Go figure). With this in mind I created a data management object which would load the required models and textures, then figure out what masking was required to make it all look good.

Sounds easy when I write it like that, but it actually got quite complex. I basically had to write a matrix that would look at what clothes you were matching up, load the required textures, then merge the alpha channel with the textures before finally applying it to the model.

Next big thing was the animation of the models. Not that playing the animation was hard, but keeping all the models in sync as they were swapped around was. The animation controls in PaperVision weren’t the greatest for what I needed to do so I ended up using the DAE MC2 classes. They allowed me to treat the animations a bit more like a MovieClip, so it was a lot easier to keep everything in sync.

The final big hurdle was the Augmented Reality (AR). For this I used the awesome FLAR ToolKit for this. Unfortunately, a lot of the docs were in Japanese, so I ended up hunting down a tutorial/example over at Mikko Haapoja’s Blog. This got me up and running in no time.

Out of the box it didn’t perform as well as I would have liked, so I spent a bit of time tweaking the code to make it run better. Nothing too spectacular, just simple things like shrinking the size of the webcam image to reduce the number of calculations required and only calculating ‘every other’ frame.

Another little tweak I did was to apply a basic ‘ease’ to the model position. This helped smooth out the little motions that the camera picked up and helped make AR feel much more responsive.

That’s about it.

Overall I am extremely happy with the site. The designers and 3D modellers I work with at Visual Jazz did an awesome job of building the assets and despite the technical difficulties I mentioned above, it all came together well in the end.

If you haven’t checked it out already, go have a look at it here. You can also read a bit about it on the VJ Site.

It was my job to do all the flash programming to make this site come to life.

Read on to hear me ramble on a bit more about some of the details.

The main base for the site was split into two different sides. One side was the rough and tough ‘work’ side, full of rough, dark, industrial areas. The other side was the brighter ‘play’ side with a much more fun feel.

Different sections of the site were related to either work or play. When a section was navigated to the entire background would pan left or right using a pretty cool parallax effect, with all the elements moving at slightly different speeds. To help give a bit of atmosphere, I did some quick little animation effects. These included some random floating clouds the work their way across the screen, as well as a random flock of birds that can occasionally be seen flying in the background.

Page elements animated into place using quick, almost ‘bouncy’ motions, tweaked slightly to make the elements feel as though they had some weight to them. The panel that is used to display second level information is a very good example of this, as is falls into place like a heavy bit of steel.

I set up the base code for the buttons in such a way that the designers could easily create custom animation effects. Examples of these can be seen throughout the site, as every major button tends to have a unique animation applied.

One particular page of note was the accessories page which used a series of photographs to generate a 360 degree view of the vehicle. As the user drags the vehicle around, different features come into view, allowing more information to be displayed. I wish I could say that this was done using some fancy coding, but it is actually a carefully laid out timeline animation controlled via some code.

Full credit has to go to the designer for this site. The rough ‘manly’ feel of the site really worked well, and the elements he gave me to work with made my job a pleasure.

Although it was created a while ago, it is still a pretty cool site and can be checked out at http://www.holdencampaign.com.au/colorado/. You can also read about the project over at the Visual Jazz site.