go to demo
Demo Controls:

WASD=move direction .. SPACEBAR=shoot bullets .. T=tractor beam .. ESC=menu/pause

click-> ‘start new game’, then, click-> ‘load test area’

Other new features include keyframed animation of physical objects, a new wall-hugger enemy type(he’s still buggy), some sounds, exits and entrances, a new control scheme for low gravity maps that uses the mouse to control direction, and numerous other things.

With such a wonderfully destructible environment I hope to put to good use my crazy ray-casting-path-finding experiments. I’m sure there is some overlap with voronoi and path finding here as well.

This screenshot really does not do justice to what is going on here.  Polygons are breaking all over the place. Also, loot is dropping.

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.

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.

Update: Unfortunately, encountering pitfalls can sometimes be more demoralizing than overcoming them is satisfying… I think I’ll stick with the simpler AMFPHP 2 for a while. It can’t be too hard to migrate the services if the need should arise. For now I just need to hack some stuff together. Technical debt be damned!

So I blast them!

Well anyway, shrimps now collide with walls and are pushed back by bullets!