The compiled .swf is just under 4kB and uses a config_slideshow.txt file to get itself started.

The slideshow.swf looks for config_slideshow.txt in the same directory (as itself) and loads some configuration variables from it. (Don’t rename slideshow.swf or config_slideshow.txt.) The config_slideshow.txt will look like this:

The format for the magic string the slideshow will read is:

etc…
You can see the magic string uses carrots “^” and “#<br>” to break into usable data. The order of the elements in the magic strings is important, but you may leave an element blank if you like: “^^”

Here is an example with intentional missing images to show how errors are handled:

Here are the files:

Flash slideshow files and source

Still to do:
back/forward buttons. + configure in config_slideshow.txt file.
Fullscreen button. + on/off in config_slideshow.txt file.
Play music .mp3 or midi with the slideshow. +config_slideshow.txt file controlled.

P to attempt path solution
R casts a ray at the mouse and shows the first sidewalk.
The enemy will stop if it is to far offscreen.  It helps if you resize the flash window to make it bigger.

To avoid needless backtracking and cut corners when possible, extra tests are now performed each time a way point is reached. These tests  cast more rays at way points further down the list. The furthest way point touched without obstruction will become the next way point and the points in between discarded. Every second or third way point reached will probably need to trigger a completely new path finding solution, because of the time it takes to travel that far.

I’ve added a coefficient of average obstacle size that for now is just a variable, but might (eventually) be set automatically after a few solution attempts. The coefficient helps by hinting when the path should to turn off the ‘sidewalk’. In spaces with small obstacles, you’ll want to get off the sidewalk sooner and the coefficient will be smaller.

It turns out, that a sparse,  empty space is ill suited to the ray casting approach, because it relies on bouncing rays off walls. Luckily, featureless spaces are simple in every other way, and often require no path finding whatsoever.

I’ll need to do some observation and tests to determine what order of left or right turns in a row is most likely to make progress towards the destination.  I’d like to think that a lot of this can be done at runtime, but I need to be careful not to push this project towards the informed sort of pathfinding. I’m determined to keep the AI in the first person. It will have to learn it’s own space by casting ‘learning rays’. A lot of the tests I’ll need to make will be towards finding the important characteristics of obstacle filled spaces, and hopefully finding a few soft rules to follow.

It’s fun to program a solution with such unpredictable results.  As I fly around and press P, I can see the rays cast, but if they were not shown, I’d anthropromophize the behavior of the pathfinding enemy. If the enemy was a bit faster and deadly to touch I think it’d be fun to try outsmart it.

The problem is how to get the enemy to the player while the player is moving and obstacles (possibly moving) are in the way.

I’ve gone pretty easy on myself for the requirements of this particular pathfinding problem. The path finding solution can be wrong if the enemy’s behavior will look unexpected, unpredictable and interesting. The path can fail entirely and it can be interpreted that the enemy does not see the player or cannot perceive how to reach it until conditions change. Learning the weaknesses of the pathfinding algorithm becomes part of the challenge of the game.

The first step in my path finder is a ray cast in the direction of the destination.  I then use the line perpendicular to the  normal of the first obstacle obstructing the ray. This line follows the obstacle like a sidewalk until it encounters another obstacle, where another 2 rays are cast. One ray along the next  sidewalk, and the other in the direction of the destination. If the ray cast in the direction of the destination is obstructed, a waypoint is added. This process is repeated a few times until the destination ray is unobstructed or the algorithm gives up. The enemy then follows it’s waypoints to the destination, checking at each waypoint to make sure the player is not in line of sight.

Anyway, here is what a very rudimentary, and buggy start to a heuristic pathfinding algorithm using ray casting looks like:
Keyboard Controls:

Move = W, A, S, D
Shoot = SPACEBAR (if you kill the blue enemy you have to reload)
Press “P” to attempt to get Enemy Pathfinding solution…
Cast ray from ship to mouse = R
Amazingly, walking along the sidewalk and only taking right or left turns can sometimes get you in sight of your destination. More analysis is forthcoming.

jaketastic.com user interface

On the left is the file browser. It can be used to explore all the files and subfolders in the jaketastic.com/browse/ directory. When you click an item in the file browser, it will begin loading in it’s own little feature rich window. You can move this window around, resize, minimize and close it.  Tabs appear along the bottom for minimized items.

Because the file browser uses a php service to build the directory listings, content management is a snap. If I want to add an image, flash movie, .flv video, or html to the portfolio, I merely upload it to the browse directory and it instantly appears in the file browser. Furthermore, if  I want to add a description to a file, I need only upload a .txt file with the same name to the same directory, and that .txt file will load in the window as well.

Jaketastic.com also allows you to chat with anyone else on the site in real time with the handy chat widget that I’ve made. Just type in a message and press enter and the message appears for everyone to see!

Jaketastic.com uses Amfphp 2.0 and a modified version Strike Remoting for server communications.  For video playback, I’ve added a slider and fixed some bugs in FLVPlayerLite.

One needs to grasp hexadeciaml to binary conversion and bitwise operations to control all 32 layers of collisions.  I immediately wrote a function to  obfuscate these ugly bitwise things and assign a rigid body’s layer without suffering the unintuitive process of converting and comparing. I do appreciate that bitwise comparison is very appropriate for the collision layers, but it is very satisfying for me to spackle over it and never have to deal with it directly again.

Starting down the programming path by way of a flash designer, I have a rather mollycoddled perspective when it comes to coding.  I am not very interested in making a compiler, or noodleing with memory management or lower level tinkering… not yet anyway.

Box2D is well known, very powerful and has extensive documentation, but after taking a look at the manual, I decided that it left out too many common tasks for the sake of flexibility. Also I do not like converting pixels to meters. I may return to this if they get some more advanced features implemented for as3.

APE was ridiculously easy to use and wonderfully documented. I was able to set up my game engine to use this is just a few hours, however, I quickly ran into a wall† when it came to the features I needed.

Glaze is what I’m tinkering with currently. It has little to no AS3 documentation, but it is based on the chipmunk physics library and documented in it’s daddy’s C language. It’s amazingly fast, and so far, it’s making some sense to me. I’ve made it parse a MovieClip to build rigid bodies out of it’s children, sleep off screen bodies, and I’ve extended the RigidBody Class to handle different types of collisions.

Here is a little demo of where I am so far: (use keys: WASD, SPACEBAR)

adapting glaze physics as3

It’s still missing a ton of features present in my current game work in progress.

† What is the word for when a metaphor has 2 meanings? Like an idiomatic pun, but not a pun. UPDATE: it’s double Entendre or innuendo.