Jaketastic

With the wonderful Voronoi implementation by Alan Shaw I’ve managed to get the destructible blocks in my game crumbling in an elegant manner. The initial shattering of the breakable blocks splits them into the convex Voronoi regions, subsequent breaks are less complicated.

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.

flash, Flash Game, glaze physics, voronoi

Despite it’s being a gawd-awful mouthful to describe, I’ve attempted to heuristically develop a real time, semi-informed, pathfinding technique using the ray casting in the 2D glaze physics engine for Flash AS3. Pathfinding in games is usually accomplished with a waypoint network or navigation mesh, and a little algorithm called A*.   These techniques work great, but I don’t want to bother with constructing nodes for my maps, and I wanted an excuse to mess around with the ray-casting built into glaze, so I approached the problem from, (ahem), a different angle.

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.

AS3, Flash Game, glaze physics, pathfinding

Bitwise Operations
For those of us without computer science degrees, a lot of the lower level guts of programming often remain a benign mystery until we encounter them in some code we need to borrow. In the Glaze physics engine, layers delegate which collisions will happen between the bodies in the physics simulation. The layer object is a unsigned integer expressed as hexadecemal:  “0xffff”    The function used to determine if Rigidbodies collide is a bitwise AND.

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.

AS3, bitwise, glaze physics

I’ve been experimenting with physics engines for Flash AS3 with a mind to upgrading the one I made from scratch for my parallax scrolling game.

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.

AS3, glaze physics