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

It is a pretty awesome video / facebook / integration site that pulls data from your Facebook account and generates a glimpse of what your life would have been like if the world wasn’t going to end in 2012.

It was a massive effort from a number of people from different agencies and it all came together beautifully in the end.

I will be doing a bit of a write up on some of the technical stuff I had to deal with soon, but in the mean time be sure to go and check it out at http://www.lynxfastlife.com/

The concept was to create a section of Cuddles Town – the home town of the Bananas and all their friends – using the new design style of the revamped show.

The design gurus I work with at VJ came up with a pretty awesome horizontal layout for the entire town, with each of the characters from the show being represented in the scene.

Each of the characters houses represented an area to explore, with some areas containing information about the show, and others containing fun little games for the kids to play.


To give the world a bit of depth, we built the entire scene in a parallaxing style using Alternativa3D. All of the hills were laid out on planes and when the user clicked on a hot spot, the camera would zoom into the area to reveal extra details, etc.

A few of the sections had some small games and activities for the user toe play with. Each was a little different and tied in with the site quite well.

Topsy’s area contained a dance along game where the user had to click the mouse or press the space bar in time with the music. If the timing was correct, Topsy would dance along. There was also the option of just playing the songs and watching Topsys dance without the need to press any buttons.

Charlie’s area contained a game where the user had to fix the machine by selecting the piece that matched the missing shape. If completed correctly, the user was awarded with an award of a colour in printout of the object the machine generated.

Bernards house contained a story book where the user could select from one of three possible stories to read along with. Each of the stories were narrated by the Banana’s and had actual sound samples from the episodes.

The Banana’s area had two games. One was a simple dress-up game where you could select clothing for the Banana’s to wear. There is also a simple treasure hunt game where the user is given the task of finding items hidden around Cuddles Town.

Other areas of the site contained other types of information for the user. One area contained the ‘Watch’ section where the user could watch various episodes from the TV show streamed directly from the ABC.

The ‘Make’ section contained a number of various printouts and activities that the user could use to create heaps of different things such as gift cards, colouring-in pictures and photo frames.

The ‘Meet’ section contained a small bio on each of the characters from the show. There was also a small animation of each of the characters introducing themselves.

As a nice little touch we added in a night-time mode for the town where the sun went down and all of the houses lights came on.

This feature was later extended to ‘sleep time’ where a parent could set a timer on the site so that after a certain amount of time the entire site would go to sleep preventing any further interaction stopping the child for playing for too long.


So that’s the Banana’s site in a nutshell. It was a lot of fun to build and I had a lot of help putting together all the games. It was also my first project where I used Alternativa3D which was also a bit of fun.

I don’t think I need to mention it, but all the characters etc. are the respective property of their owners.

If you get the chance you should go check out the site by clicking here.

Why someone would want to hack my site, I don’t know. Looked like they were trying to redirect some traffic their way.

Hopefully I have patched up everything now – I guess I’ll find out soon enough if I haven’t :p

Sorry to anyone that may have been effected by the site being down. Hopefully there will be some new posts coming soon

Some of the clever guys I work with at Visual Jazz (looking at you Tom) have taken my AS3 code and reworked it to play nice with Apples nifty little machines. Best of all, you can download them for free!

Strike Fighter was the first one done – it is only available for the iPhone at the moment. You can check it out by going here: http://itunes.apple.com/us/app/strike-fighter/id389734422?mt=8


Warfare officer has been completed more recently. It has been set up for both iPhone and iPad and can be checked out here: http://itunes.apple.com/ca/app/navy-warfare-officer/id393458494?mt=8

Be sure to check them out!

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!