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

The idea behind it was that it was meant to look like when you take a sparkler and move it around really fast in the air – the glow leaves a line of light behind it for a few seconds.

After a fair bit of messing around I finally came up with something I think looked pretty cool, which you can check out here…

The way it works is kinda simple, but in a slightly complicated way… if that makes sense..

Basically, I created a round BitmapData that would act as a ‘brush’. It was a simple circles with blurred edges. I then had a second transparent BitmapData that would act a canvas for the brush to draw into.

Every frame of the animation I would check for a change in the brush position, and if it had moved I would draw a line between the two points with the brush. Unfortunately, there isn’t a built in way to draw lines using a BitmapData so I used some basic math to divide up the line I wanted to draw into equal steps, then drew the brush BitmapData at each step along the line.

That gave me a basic soft edged brush effect, but it didn’t fade out over time. That is where the BlurFilter comes in.

On every frame I would apply a BlurFilter to the canvas BitmapData – I can’t remember the exact amount, but it wasn’t too big. By itself it didn’t do too much to the canvas, but by applying it every frame, the blur would accumulate and slowly fade the drawing out to transparent.

That’s the basic gist of it.

To make it look a bit cooler, I actually ran two versions of this effect over the top of each other – one for a soft glow, and the other for a hard edged central colour – I thought it gave it a nicer effect. I also started adding in some basic scale changes depending on how fast the mouse was moving, so the lines would thin out on fast motions

You can download a FlashDevelop project here that has all of the assets I used – Light Writing Project

I think it looks pretty cool and it worked with the designs really well. Just to make things tricky though, they made be rebuild the whole effect using AS2 so that it could be used in some banner campaigns. I had forgotten how much better AS3 is

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

For the sake of others I have compiled a list of these here, along with the solutions I found, when there was one.

Levels are bad

I don’t know why, but they just don’t seem to work right. To get around it, I replaced I loaded external movies into the _root level, and then manuallky changed all the _levelN references. That was lots of fun. Good luck with that.

globalToLocal() may not work

This is a bit of a strange one. There appears to be a bug in conversion when the Loader that you use to load in the AVM1 file is positioned anywhere other than 0,0. Looking at the numbers it is almost like the position is offset by whatever amount the Loader is offset by.

Work around? Nothing really fun. You could write your own conversion thing that recursively climb up the _parent() tree – that’s all I came up with

MovieClip.hittest()

This seems to be related to the globalToLocal() bug in that the collision position is offset by the Loader offset. If you are just using the MovieClip.hittest(MovieClip) method, it will work fine because the co-ords are messed up fro both objects. Where it really fails though is when you are using the MovieClip.hittest(x,y,shape) approach. That just doesn’t play nice at all.

Steve, a guy I work with at VJ, came up with a bit of a work around. Basically you take the bounds of the object you are testing and then compare it to the point you want. This means you miss out on the shape flag, but it was good enough for a lot of the things I was doing.

Static classes / variables – (Updated – see note at end)

I still haven’t figured this one out fully yet, but there does seem to be a problem with static variables, etc.

One of the projects I was updating was using a Singleton style approach to one of its classes. It all worked fine the first time you loaded it in, but when you unloaded and reloaded it, it would fail.

I poked around for a fair while and I discovered that the class reference was staying in memory despite the AVM1 file being closed and unloaded. They by itself wasn’t that bad. The real issue was that the reference to _root and _global inside that class was totally lost.

Don’t get me wrong, _root and _global still exist in the project, but the static classes just didn’t see them at all – they kept coming up as null.

The work around for this wasn’t very elegant, but the only way we could get this to work was to pass in the _root reference to the static classes via an .init() call. Like I said, not pretty, but after a couple hours of experimenting it was the only thing that worked.

UPDATE This is just a quick update – I did a bit more research and it would appear that this bug is worse then I first thought. It has nothing to do with static classes and more to do with a bug in the player. Check out this bug notice on the adobe site, then pull a sad face if it is effecting you…. I know I will

That’s the list so far – if I find any others I will add them in as I go. Hopefully it will save people a bit of time.

source : www.tugaskita.com

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!

Take control of three Australian navel ships and lead them on a mission to destroy the enemy base whilst protecting your own.

When you first start up the game you are requested to select a fleet for your battle. You are initially presented with 3 preset fleets – Offensive, Defensive or Balanced. Each fleet is made up of three different vessels from a collection of Australian navel vessels – an Armidale Class Patrol Boat, Anzac Class Frigate, Collins Class Submarine, Hobart Class Air Warfare Destroyer or a Canberra Class Landing Helicopter Dock.

Each vessel has its own set of attributes in regards to speed and strength. Some also have some extra features such as support vehicles. Each select vessel also has an Australian Navy personnel member assigned to it which provides the vessel with an extra feature, such as better defences or a support craft.

After that, the game begins. You are given control of your three vessels and pointed in the direction of the enemy base.

The goal of the game is to find and destroy the enemy base before they destroy yours. The map is filled with a number of islands so it is not too difficult to sneak past your enemy without getting into a conflict.

To control a ship you simply click on it with your mouse. Once selected, a list of possible actions are displayed along the bottom of the screen (with move being the default action).

Selecting an action will either carry it out straight away, or trigger a targeting radius showing the area in which the action can be carried out.

If one of your ships is destroyed in battle, it will be reconstructed after a period of time – as will your enemies ships. it is important to take advantage of this time because the ships will be rebuilt at their base and are made invincible for a short period of time.

There is a single player campaign where you go up against a rather ruthless computer opponent – or a multiplayer game where the enemy is controlled by another player. Both are online now and playable at Defence Jobs.

This was the second major game I got to build for defencejobs.gov.au whilst working at Visual Jazz and it was definitely the biggest game I have ever worked on.

Source : www.tugaskita.com

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.

It was actually completed months ago, I’ve just been lazy about adding it to my site.



The basis of the game is pretty standard – fight your way through wave after wave of enemy jets, and get as many points as you can.

To help keep things interesting there are two different styles of play – Campaign and Survival.

The ‘Campaign’ mode is set out in a stage by stage basis.
There are 7 stages set across 5 different scenes, with each scene containing a different set of enemy aircraft that get progressively more difficult as the game goes on.
At the end of each stage your score and bonuses are added up. As you score more and more points you unlock new skins for your jet.

You are also given the opportunity to spend the credits you collect on upgrades for your jet. These are spread across three key areas – Armament, Avionics and Electronics – and include things like faster lock-on times, multiple missiles, radar jamming, agility upgrades, etc.


At the end of the last three areas you are confronted by extremely large ‘bosses’ that almost fill the screen. They attempt to ram you as well as bombard you with multiple missiles. Arghhh!


Survival mode is kinda the same except that instead of a ‘mission’ based approach, you get just one life and fight through as many waves of enemy jets as you can. You also get to choose which scene the game will be set in, so you can practice with the various sky lines.

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..