I’ve put it on Flash Game License. This is the first time I try out their service, but I’ve only heard good things. I’ll put a link up after the game’s live.

The soundtrack was done by my brother, Jonathan Rock. After the game’s out, I’ll put the music here for download.

The game is entirely blitted (using a single bitmap display instead of many sprites), which allowed me to fill it with action without any worry of slow-down. The framerate is a solid 30fps. It even seemed to run well at 60fps, but I didn’t want to alienate anyone on a crappy machine.

You can see in the screenshot that enemy movement is very fluid. That’s because I used timeline animation to guide everything. This was done with a ‘puppet’ system that updated blit data based on played movieClips even though they weren’t on the stage.

The background was generated from 4 different bitmapData objects. The 3 star layers were scrolled down (bitmapData.scrollTo(x , y)) by a given distance (their velocity) every frame and the gap left at the top was filled by an image of randomly generated stars using the setVector function which is extremely fast. The most efficient way to handle that was to constantly refresh the values of uint vectors with lengths fixed to exactly the value needed to fill the space of each bitmapData object.

There’s also a layer of perlin noise used to generate the smoky nebula effect that drifts by all the ships. Just as the stars were generated one piece at a time, the perlin noise was generated just at the top as a slice and then scrolled down as it ‘moves’. However I couldn’t use setVector to generate perlin noise, so I had to have a separate bitmapData object just for generating perlin noise that was only big enough to fill the space left by the constant downward scroll. Each time the perlinNoise function is called, it is passed an offset array so that the noise always represents the portion that should exist above what came before it. I ran into an annoying problem here until I realized that the ‘stitch’ argument in the perlinNoise function was set to true and should not have been. Generating perlin noise is very processor intensive, but I was pleased to find that if you generate it just a little bit at a time, you have no problems at all. I would like to use this same technique in the future to create infinitely large maps that are only generated one slice at a time as the player moves in any particular direction.

I based collision detection in this game on my work in the Bad Bones demo I showed at IGCW a couple weeks ago and found the bitmapData based technique to be very effective. Each ship filled a rectangular area which represented itself on a bitmapData object. They filled this area with a color that acted as an ID tag for that specific object. Other objects could then check a specific part of the bitmapData object to see if any other objects are there. The checker finds a specific color registered with a specific object and a collision is detected. The only limitations are that you cannot collision detect outside of the area of the bitmapData object and if you want collision detection for anything other than a rectangular shape, you must get a bit more complicated than the fillRect function (and lose some efficiency). This technique has proven to be so effective that I expect to make it a standard part of my game development process and recommend it to others.

Check back for the full game.

-Christopher J. Rock

I’m releasing the source code for a Papervision3D game I was putting together. This project was meant to be an interactive visual for a party my friend threw last weekend, Friendly Integration. This game was meant to be projected onto a wall and controlled with a DDR pad for each player. There were also plans to have additional panels that could be stepped on that changed the “theme” of the game.

Below is a sketch of my initial idea for the project. I wanted to play with the idea of 2 people interacting with each other. Being side by side with the pads I wanted to give the players the ability to be friendly, or the opposite. I didn’t get to the point of executing these ideas as I barely had enough time available to get the basic engine running.

Conceptual sketch

This turned out to be more fun than I expected and I look forward to continuing development on it. It’s not a priority right now but I learned a lot about Papervision in the 15 hours it took me to put together. I didn’t get to doing a serious art pass on it which is unfortunate because it’ll look a lot cooler with some polish.

My inspiration for this was Bomberman and Poy Poy for PS1. I lifted the bomb artwork from a Bomberman drawing I did a while ago.

And the important part…

Play it here: http://blog.sokay.net/stuff/friendly/friendly_04.html

Download source: friendly_integration_src.zip

Note: This uses the Papervision3d 2.0 Great White code library. There are some fine video tutorials at gotoandlearn.com if you need help getting started with that.

Hans was right about the usefulness of a function wrapper, but I didn’t feel like getting into it . . . until now. A couple days ago I brought up my old TraceManager and decided it was time to revamp it.

//Wrap class
traceManager.wrapClass(testClass , “testClass”)
//Run class function
var diff:Number = testClass.Subtract(6 , 3 , “trace:Infinity”)

The testClass.Subtract() function above was not capable of producing sophisticated trace data until the traceManager.wrapClass modified it and every other function in the testClass class.

I’ve taken Hans’ proposal one step further, by creating a ClassWrapper (using the undocumented ASSetPropFlags) that will automatically apply tracing capabilities to all functions within a given class instance. Finally, I feel the TraceManager to be a tool that all actionscripters could use in any project:

TraceManager.zip

I’ve added those 2 new functions, modified formatting a bit, and made a few other slight adjustments. If you used the previous version you probably will barely notice the differences outside of the 2 new wrapper functions. For a review on the basic ideas check out the original post. Now I give you an example of a trace out and will explain use of the new wrappers.

The formatting here makes it look a little wobbly, but I assure you the actual trace out is nice and neat.

TraceManager: traceManager
_________________________________________
Time(seconds):      Depth:  Function:
—————————————–
0.001                   +0       testClass:Subtract : (6,3){
0.001                   +1       .    testClass:LoopFunctions : (6,3){
0.001                   +2       .    .    testClass:Conditional : (6,3,0){
0.001                   +3       .    .    .    testClass:Increment : (3){
0.001                   -3       .    .    .    } (4)
0.001                   +3       .    .    .    testClass:Increment : (0){
0.001                   -3       .    .    .    } (1)
0.001                   -2       .    .    } (4,1)
0.001                   +2       .    .    testClass:Conditional : (6,4,1){
0.001                   +3       .    .    .    testClass:Increment : (4){
0.001                   -3       .    .    .    } (5)
0.001                   +3       .    .    .    testClass:Increment : (1){
0.001                   -3       .    .    .    } (2)
0.001                   -2       .    .    } (5,2)
0.001                   +2       .    .    testClass:Conditional : (6,5,2){
0.001                   +3       .    .    .    testClass:Increment : (5){
0.001                   -3       .    .    .    } (6)
0.001                   +3       .    .    .    testClass:Increment : (2){
0.001                   -3       .    .    .    } (3)
0.001                   -2       .    .    } (6,3)
0.001                   -1       .    } (3)
0.001                   -0       } (3)

0.004                   +0       function1 : (test1){
0.004                   +1       .    function2 : (test1 1){
0.004                   +2       .    .    function3 : (test1 1 2){
0.004                   -2       .    .    } (test1 1 2 3)
0.004                   -1       .    } (test1 1 2 3)
0.004                   -0       } (test1 1 2 3)

0.005                   +0       function1 : (test2){
0.005                   +1       .    function2 : (test2 1){
0.005                   -1       .    } (test2 1 2 3)
0.005                   -0       } (test2 1 2 3)

0.005                   +0       function1 : (test3){
0.005                   -0       } (test3 1 2 3)

This is the trace out you should get after compiling the TraceManager Test fla (contained in TraceManager.zip). The testClass functions listed at the top are used in an unnecessarily complex attempt to subtract the second argument from the first. Obviously a class is overkill for subtraction, but it shows the results of the class wrapper. In the example above, the testClass is used to find 6 – 3 = 3. As you can see, the first arguments are (6,3) and the result displayed at the end of the function is (3). The traceDepth given to the testClass:Subtract function is “trace:Infinity” so every nested function is traced.

Before these traces could be created, the testClass instance had to be updated for tracing using the classWrapper. The following details that portion of the code:

//Importing and initializing TraceManager at the _root level.
import TraceManager
var traceManager:TraceManager = new TraceManager(“traceManager” , true , 0 , undefined , getTimer() / 1000)

//Import new class
import TestClass
//Create class instance
var testClass:TestClass = new TestClass ()
//Wrap class
traceManager.wrapClass(testClass , “testClass”)
//Run class function
var diff:Number = testClass.Subtract(6 , 3 , “trace:Infinity”)

The next group of function traces are due to a single function being run multiple times with different traceDepth values. The first traceDepth is 3, the next is 2, next is 1, and after one is run with a value of 0 and another with a value of undefined. The 0 and undefined values are not traced, so only 3 versions are visible above. As you can see, each trace from function1 displays fewer nested functions than the one before it.

The following is the code that led to the 2nd half of the trace out:

//Defining new functions.
//////////////////////////////////////////////////
function function1(input){
var output = input + ” 1″

output = function2(output)

return output
}

function function2(input){
var output = input + ” 2″

output = function3(output)

return output
}

//This is the last function, with no nested functions in it.
function function3(input){
var output = input + ” 3″

return output
}

//Wrapping functions.
function1 = traceManager.wrapFunction(function1 , “function1″)
function2 = traceManager.wrapFunction(function2 , “function2″)
function3 = traceManager.wrapFunction(function3 , “function3″)

//Running functions
function1(“test1″ , “trace:3″)
function1(“test2″ , “trace:2″)
function1(“test3″ , “trace:1″)
function1(“test4″ , “trace:0″)
function1(“test5″)

Notice that these functions were wrapped individually because they were not contained in a class.

One of the added benefits of implementing the wrapper functions is that by flipping the TraceManager onSwitch variable to false, you can prevent the wrapper from engaging and therefore the TraceManager will be prevented from having any effect on your program. You don’t need to remove the code before  publishing, just set onSwitch to false, and TraceManager becomes completely harmless.

Anyway, I’m happy enough with its functionality that I’ll be working it into my standard procedure. Pretty soon I’ll finally be shifting my work to AS3 so there ought to be another version coming up fairly soon.

Let me know if you have any other ideas, Hans!

-Christopher J. Rock

A couple months ago I decided I would begin working toward my long time dream of producing a real-time strategy game. I actually finished NorthStar and had this written a few weeks later, but I’m only posting now because I’ve been hard at work with the rest of the game! Now working on unit logic along with a new Sokay project (more on that later) and editing a new film (later still), so I been a little busy. Expect Demos.

I planned on basing the RTS engine on some of my previous work with physics (perhaps that sounds strange, but it makes sense). Step one was coming up with a pathfinder.

Demands:

1. Irregular Polygons: I dislike tile-based systems and I already had groundwork in my physics engine for handling irregular polygons. I decided the RTS should implement the same ideas and therefore it cannot use traditional, tile-based pathfinding techniques.
2. The Illusion of Intelligence: Paths must appear to have resulted from intelligent decision-making. I didn’t want to see units going on crazy birdwalks for no apparent reason like they often do in popular RTSes. I’m disgusted by the presence of such awful pathfinding in blockbusters like Blizzard’s Warcraft and Starcraft series. I want my units to use paths that make them appear intelligent.
3. Forethought in Navigation: The path must be relatively efficient, demonstrating a knowledge of the overall terrain unless I specify otherwise.  If I want a unit to appear ignorant or lost, letting it wander is fine, otherwise it should not bother with any path that will not eventually lead it to the goal.
4. Efficiency: I can’t have units lagging every time they decide to move somewhere and ideally I can have lots of units deciding to move to different places all at the same time. That means it’s gotta be quick.

A* Logic

I didn’t have any background in pathfinder’s, but Bryson had used the popular A* (“A star”) for his Liquid Generation puzzle game a while back and it seemed to work well for him.

The essence of A* is decision-making. It navigates a network of nodes by rating each one available and selecting the node with the best rating (making it a “best-first” algorithm). The rating function can be customized for a given project, but generally it is an optimistic estimation of the cost (in distance) of a path through a given node.

So imagine you have to walk around a car. The car may have one node on the left and another node on the right. If walking through the left node costs at least 15 steps, but walking on the right costs at least 10 steps, A* chooses to go right. It is “optimistic” in that walking to the right may eventually cost more than 10 steps, but walking to the left will cost at least 15 steps.

A*’s simplicity and effectiveness made it a good model from which to build NorthStar. But the reason A* is so easy to implement in so many games is because its nodes directly translate into tiles in a tile-based engine. I needed a way to describe a field of arbitrary polygons as nodes before I could apply any of that logic. This proved to be the real challenge.

Creating a Node Network from Arbitrary Polygons

Polygon Data

Using my old physics engine systems, I constructed polygons from movieClip points organized into groups. I drop the point movieClips onto the stage and convert groups of them into new movieClip instances, then the points automatically arrange their data into arrays at run-time. The result is a single array (_root.PolygonArray) indexing each individual polygon (_root.PolygonArray[p]) which are represented as arrays indexing vertices (_root.PolygonArray[p][v]) which are also arrays containing x and y values of the points (_root.PolygonArray[p][v].x , _root.PolygonArray[p][v].y). This is the polygon data I’m converting into nodes.

Some pathfinder’s handle this process by identifying all vertices as nodes and creating links between all of them that have no walls between them. That works, but it creates a very wasteful network. A pathfinder has to scan through all the options available before it can make a decision, therefore the pathfinder works most quickly with the least number of options. So yes, you can simply convert all polygon corners into nodes and link them all, but your pathfinder will be much more effective if you only create the most useful links. Plus, having extra links lying around may occasionally put pointless Sunday strolls in your path instead of keeping it nice and tight.

If a link is unnecessary, don’t create it! Having extra links around will just bog down your pathfinder while it scans the entire network for the best path.

Identifying a Good Link

I came up with this set of steps for determining whether or not a pair of nodes (A and B) should be linked to one another (read Filtering Links for a Lean Network for justification):

1. Draw a line connecting vertex A to vertex B. Call this “lineAB”
2. Find the two vertices neighboring vertex A and make sure they are both on the same side of lineAB.
3. Find the two vertices neighboring vertex B and make sure they are both on the same side of lineAB. (They do not need to be on the same side as vertex A’s neighbors)
4. Check for polygon walls blocking lineAB.

If each node’s neighbors are to one side of the link and no polygon walls are penetrated by it, the link is worth having.

The Math

You may be wondering how I applied those steps mathematically. To “Draw a line” between vertices A and B, I found the line in Slope-Intercept form that contains the two. To find out if their respective neighbors were on the same side of that line, I ran the x values for each neighboring vertex through the line’s equation. The result is the y value of a point (call it pointL) on the line with the same x value as the neighbor. If pointL has a y value that is greater than the a neighbor’s y value, it means that neighbor is below the line. If pointL has a smaller y value than the neighbor, the neighbor is above the line.

The only exception to this is when the slope of the line is Infinity (it points straight up and down when the 2 nodes being tested have the same x value and different y values). In this case, because the 2 nodes being tested have the same x values, you can detect which side each pair of neighbors is on by comparing their x values to the x value of either of the 2 nodes being tested.

Organizing Node and Link Data

I arranged link information in a new array called “nodeMap” which indexes each individual node. Each node is an array with point information in addition to being associated with a “link” array (nodeMap[n].link). The “link” array lists each of the nodes to which the current node is linked (nodeMap[n].link[m]). Each element in the “link” array is an array containing a reference to the linked node (at the zero position, [0]), and the distance between the two nodes (at [1]). A pair of linked nodes must have a reference to each other otherwise the link will only work in one direction.

The nodeMap grows as loops cycle through every vertex on every polygon, checking them against every other vertex in the field, converting polygon data into node data.

Pathfinding

Linking the Start and End Points to the Network

Now that the polygon map has been converted into a node map, the pathfinder must be given start and end points to represent the desired movement. These points can be anywhere on the field.

NorthStar uses logic just like the node linking process to link the start and end points to the node network. The start and end points are not vertices so they do not need to compliment any nodes to form a link and their linking process is a bit simpler than detecting links between nodes.

1. Draw a line connecting startPoint to node A. Call this “lineSA”
2. Find the two vertices neighboring node A and make sure they are both on the same side of lineSA.
3. Check for polygon walls blocking lineSA.

(Run the same process with the endPoint in place of the startPoint.)

Finally, the network is ready to be analyzed.

Blazing the Path

Starting from the startPoint, a path is drawn from one node to the next, through link after link, until a node is reached that is linked to the endPoint. When the endpoint has been reached, the search is over. The path has been found.

NorthStar is continually updating a library of available options, starting with each of the links of the startPoint. Each time it moves from one node to another, it deletes the new node from its library of options and adds all of that node’s links to the library (except the one it came from).

When selecting the next node, it sorts the entire library by node rating. The one with the best rating is chosen to have its path grown until that path attains a worse rating than another option in the library. All available nodes are constantly checked against one-another so that NorthStar quickly abandon’s any paths that seem wasteful and returns to old paths with better ratings.

The Rating System

Breeding A* with a few other methods, I rated nodes according to an estimated cost in distance in addition to a few tie-breakers and special cases that would probably change from project to project.

I put rating data into arrays (you can probably tell I use arrays a lot). The first element in the rating array is the path distance required to get to the node. The second element is the estimated distance to the endPoint. These two are added together to get a rating value.

In most cases the estimated distance to the endPoint may simply be the distance of a straight path between the node and the endPoint (an optimistic estimation), however if possible, other information may be used to find an exact distance, like when the current node is indirectly linked to the endPoint. An indirect link is when a node can lead to the endPoint if at least one other node is used between the two.

Indirect Links

I implemented a check for indirect links into my rating system. It just scans to see if there are any links that a node has in common with the endPoint, then selects the one with the shortest path (if one or more exist). When this is used, the resulting rating is exact rather than an estimation.

Another way of taking advantage of indirect links is to create them between nodes as soon as a path is found between them. If the path has already been proven to be effective, you can indirectly link all the nodes within that path to each other and the path can be easily reused in the future without requiring a complete rescan of the network. I did this by adding a third element to any links between nodes that are indirect. This element is an array containing all nodes along the path between the two indirectly linked nodes, in order.

Finding Indirect Links Pre-emptively

I have a function for scanning a node network ahead of time to find all the shortest indirect links between all nodes on the field, but it’s a little buggy. With that implemented a ton of time can be saved because as soon as the start and end points have been linked to the network, you can instantly find a path between them by picking any of the nodes they’re linked to and finding the precalculated indirect link between those two nodes.

Why is the path so close to the obstacles?

Fair question. I haven’t bothered with checking unit thickness yet, so right now the path goes right up against walls and corners (offset by 1 pixel, just so it’s always clear when a unit is outside or inside a polygon).

There are 3 ways to solve this problem:

1. The Ugly Way: Make the art for the obstacles smaller than the actual boundaries. Voila.
2. The Bad Way: Add an outward extension to node locations by a given distance (equal to the radius of your unit). You may want to make that distance a value you can easily change so you can have units of different sizes.
3. The Good Way: This requires that you do the same as in #2, but you also run checks to find out if the units have enough room to fit through all of the passages. Your pathfinder will have to ignore passages that are too thin to fit through. Do this and you never have to worry about units penetrating walls as they walk. (I’ve postponed this, using The Ugly Way in the meantime)

Result

As you can see in the demo, NorthStar’s workin quite well. It’s not 100% bug-free yet, but I’m very pleased with the results and it can easily be implemented into some games. After optimizing it some more, I’m confident I can have it running quick enough that it can be used for pathfinding in pretty huge settings. One method I haven’t seen in other pathfinders would involve generalizing start and end points so you don’t have to calculate linking them to the network so often.

More posts comin.

-Christopher J. Rock

Filtering Links for a Lean Network

The only way to clean up our network is to set up some rules for identifying a useful node link. Our pathfinder will work from the startPoint to the endPoint, but that order is not necessary. If we find a good path, it shouldn’t matter whether it started from the startPoint and worked to the endPoint or started at the endPoint and worked to the startPoint. Keep this in mind when I refer to “direct access” between points. If point A has direct access to point B, point B has direct access to point A.

1. Links cannot penetrate polygon walls: Since you don’t want paths that lead directly through your polygons, you must check to see if a wall is blocking the path between a pair of nodes before declaring them linked.
2. Nodes are only important as potential waypoints: Say you’re traveling from startPoint to endPoint. If an obstacle is blocking the way, you must find a waypoint with direct access to startPoint and endPoint. However, if startPoint has direct access to endPoint, it is unnecessary to use any waypoints when moving between them. Therefore, linking to a node is only useful if the node has direct access to a place that you currently do not. This rule describes finding links to your start and end points.
3. All vertices must be recognized as nodes: Vertices are formed by walls. Walls block nodes from directly accessing areas of the field, but when two walls form a vertex, they do not block that vertex from accessing any point on the field. Therefore, a vertex formed by any two walls will be useful in providing access to spaces around those walls.
4. Nodes must compliment each other: When the startPoint does not have access to the endPoint and linking to a single node achieves access, only 1 node is necessary. But if that node also has no access to the endPoint, it must use a 2nd node to achieve it. If the startPoint has direct access to this 2nd node, the 1st node can be skipped. In this case, the nodes do not compliment each other. On the other hand, if the startPoint does not have direct access to the 2nd node, it must use the 1st node to obtain it. Another way of looking at it is to say that the 1st node must have direct access to an area that the 2nd node does not (the startPoint) and the 2nd node must have direct access to an area the 1st node does not (the endPoint). The nodes must be linked to share their potential as waypoints. In this way, the pair of nodes compliment each other.
5. Nodes will only form links on one side of their vertex: Every vertex forms a “V” shape pointing in some direction. As a result of rules 1 and 2, a node can only have links on the outside of the “V”. Therefore, vertices pointing into the polygon can be labeled “internal” because they will only link to other nodes within that polygon. External vertices, pointing out from the polygon, are only linked to nodes on the outside of the polygon.

The Eco Zoo

This is the best executed 3d Flash site I’ve seen so far. Just check it out. Apparently this isn’t created with any open source 3d engine out there, it’s a custom engine by this guy.

3D on the web is sort of a gimmick right now, as Flash itself was seen as a gimmick in the past (i.e. your site wasn’t cool unless it had a Flash intro). All it really takes is some progressive individuals to define what’s possible with the advances of the medium — beyond spinning cubes and globes. Right now I see opportunities to tell stories in new and exciting ways. I’m hoping to take design elements from motion graphics and create interactive visual masterpieces. Couldn’t you imagine CartoonNetwork.com as a fully interactive playground? Kids would love that stuff. How come we aren’t seeing that yet??

Clint Hannaford’s Papervision Character demo

This demo impressed the hell out of me. It was proof that 3d character animation could be awesome in Flash. I’ve been dabbling in Papervision stuff lately. It’s an extra layer of complication on top of AS3 but the payoff is worth it. I created a model in Maya, textured it, and loaded it into Flash and made it interactive. Unbelievable…

For animation, I figured I could either setup some complicated character rig by separating the character at the joints and linking the pieces together. Setting all of that up and creating a system to animate the keyframes would be much to time consuming. renderhjs, from the Flashkit forum, was creating his own custom system of animating the character in the 3d software and exporting the animation frame by frame and playing through the keyframes. I don’t exactly have time to figure that out either so I found Clint’s post searching Google in distress.

Clint explained to me that his character demo uses .md2 format, from Quake 2. It’s similar to, if not the same as, renderhjs’ method of character animation. He linked to this Papervision md2 parser and recommended that I try loading in some Quake 2 models and seeing how it works.

It’s been a while since I updated on the old Liberty Engine so here it is with a lot more polish than the last demo. You still can’t modify the objects or forces just yet, but I sharpened up everything else. It’s running much more efficiently, with stats, an improved console and new keyboard commands. It also includes a “Help” button that will explain all of its functions on mouse-over.

Here is a swf copy as well as an exe. I haven’t seen much of a performance difference between the two:

• liberty-engine-demo-041708.swf
• liberty-engine-demo-041708.exe

The default “memory” setting is 60 seconds, so if you play more than 60 seconds it will begin deleting old data. This is meant to prevent the program from filling your computers memory and lagging or crashing. However, you can set the memory value to Infinity and see how much you can hold without slowdown. I found a loss of about 2 or 3 fps with 1 hour of data. I average about 6 or 7 calculated seconds per actual second (Scalc/S) so you should be able to set the rate of time passage to as high as 6 without playback time ever passing up calculation time. But play around with it and let me know how it runs on your machine. I could use the feedback!

With your time rate set to 6, you can get through an hour of simulation in 10 minutes.

Design

There is a great deal of idealism in the design of the Liberty Engine. You might say principles had more to do with it than technical goals. These were my priorities:

1. Precision: All data and specifically collisions must be precise. At this point the only rounding off occurs due to flash’s technical limitations, but I’ve aimed for accuracy to the 10th decimal place. No collisions are missed, regardless of velocities, and all are calculated exactly.
2. Repeatability: As a result of high level precision and uniform methods of rounding off data when necessary, experiments in this engine are entirely repeatable. No matter what machine is used to run the software, the same events will occur.
3. Preservation: Data is treated as sacred and preserved for potential use in any number of ways. The most significant acknowledgment of this priority is the engine’s “memory” of past events. This allows you to scrub back and forth over hours of animation. Data is compressed in different ways to keep it from costing too much space.
4. Simplicity: The soul of the Liberty Engine concept lies in its ease of use. In the early stages this was a great challenge, but since then its rewards have been great. Engine operation is entirely cut and paste, drag and drop, with minimal for scripting. This engine is built to give the little guys the power of the big guys and the big guys the freedom of the little guys.
5. Efficiency: The framerate must be stable. Even if it drops down, it must be stable. A stable framerate is predictable and provides for a much better experience than one that varies between high and low values. Also, due to the high level of precision, calculations can suck up a lot of processing power so logic must be employed to make as many safe assumptions as possible and minimize unnecessary work. On the other hand, there are a number of high efficiency coding practices that I’ve ignored for the sake of simplicity. I hope to fix some of this in the future, but clearly it is not high on my list.
6. Power: Power is the #1 concern of every engine out there, but very few games even take advantage of it. I decided that if you need a powerful physics engine you can take from plenty of others, but I would not set it as a high priority until later in development. Fortunately, the nature of the Liberty Engine gives it a significant advantage from the start. It can’t yet handle as many events as other flash engines, and still doesn’t have contact forces, but in the right circumstances it can blow them out of the water.

How It Works

Everything is coded for a quick pipeline. You drag and drop objects and force vectors from the flash library and they automatically submit themselves to a library of data at the initiation of the engine. This is what it looks like in flash:

Equations

Based on the force vectors and object data, equations are calculated to describe the trajectories of each object relative to time. Equations are arrays with lengths equal to the number of terms they contain. Each term is described by a coefficient that will be multiplied by time. The exponent of time (t) is determined by the number and order of terms in the equation.

e = [2,3,4,5]

position = e(t) = 2 + 3t + 4t^2 + 5t^3

Each term represents a derivation of position (position, velocity, acceleration, jerk, yank, etc). Since objects can move over the x and y axes as well as rotate over the z axis, 3 coefficients are needed for each term. These are described with arrays nested in the equation array. Each contains an x, y and z value.

e = [[2,2.1,2.2] , [3,3.1,3.2] , [4,4.1,4.2] , [5,5.1,5.2]]

position.x = e[x](t) = 2 + 3t + 4t^2 + 5t^3

position.y = e[y](t) = 2.1 + 3.1t + 4.1t^2 + 5.1t^3

position.z = e[z](t) = 2.2 + 3.2t + 4.2t^2 + 5.2t^3

In other words, the equation is made up of coefficient vectors multiplied by exponentially increasing values of time. An EquationAnimator function uses those equations to find the position of each object at a given time and update the stage. That allows the engine to function independently of the actual animation state.

From there, it’s only a matter of making updates due to collisions. My collision algorithms are geometrically based, so they don’t yet function for curved movements (accelerations and further derivations of position), but I’ve plans for that update so hopefully I can get on it pretty soon. The circle-circle collisions, for example, assume each circle to be moving linearly.

Circle-Circle Collision Calculation

The circle-circle collision algorithm takes advantage of relative motion by combining the movement of each circle into a single vector and applying it to one of the circles (resulting in C-static and C-moving). The nearest point to C-static along the trajectory of C-moving is then found by calculating the intersection point of the C-moving trajectory and a line penetrating C-static and perpendicular to the C-moving trajectory. Let’s call that intersection point N.

It is assumed that at the time of collision between these circles, their centers will be separated by a distance equal to the sum of their radii. That means that at the time of collision, a right triangle will exist with 2 vertices at the centers of each circle and 1 vertex at point N. The Pythagorean theorem is then used to calculate the position of C-moving at the time of collision by finding the length of the edge of the triangle opposite the vertex located at the center of C-static (the edge which lies along the C-moving trajectory). The resulting length is the distance between point N and the center of C-moving at the time of collision. That is subtracted from the distance between the center of C-moving at start and point N to give the distance between C-moving at start and C-moving at collision. Finally, that distance is divided by the length of the entire trajectory of C-moving (from start to end) and multiplied by the total change in time (from start to end). The result is the exact time of collision, which can then be applied to position equations to find the exact positions of C-static and C-moving at the time of collision. A vector with magnitude equal to the radius of either circle, and in the direction of the opposite circle, can be added to the center’s position to find the exact point at which collision will occur.

This is not just a “detected” collision, it is a calculated result that tells the exact time and place of the collision. Therefore, objects may be moving at any speed and the logic will still apply accurately (as opposed to frame-based or time-stepped logic which only functions accurately at very low speeds or very high framerates). It also saves time because after a collision is known, it never needs to be checked again so the engine doesn’t need to be vigilantly checking objects every frame. Instead, it jumps ahead into the future and continues calculations from there. The downside is that this kind of calculation sucks on your processing power so you need to find ways to stay accurate while only committing to the fewest calculations possible.

Impulses and New Equations

For every collision, an impulse must be calculated. That impulse leads to the formulation of a new equation that takes effect at the time of collision. The new equation is added to an array of equations with “start” and “end” values indicating when they accurately describe object movement and when their usefulness expires. Each array of equations is nested in an array with elements representing each individual object. When the playback time minus the “end” value of an equation is greater than the engine’s “memory” value, that equation is deleted. This only applies if the playback time is less than the most recent calculation time.

Matters of Optimization

As you can see, arrays are nested like crazy, which is not at all the most efficient way to handle things. I’ve been wanting to use something like a linked list, but arrays are a good temporary solution.

Calculations are capable of predicting collisions indefinitely, but there isn’t much point in having the engine predict events that won’t occur for an hour, so it is built to only go 15 seconds into the future before pausing. Then it continues calculations when the playback time is within 10 seconds of the last calculated event. If you pause the animation and push the scrubber far ahead of the calculation marker, you’ll see it kick into high gear to catch up. Like any arbitrarily selected value in the engine, these numbers can be easily modified.

When predictions are ahead of schedule, the engine will relax by stopping at partial cycles to allow the frame to pass. At the start of the next frame, the engine will continue where it left off. This helps prevent crashing and constant lag due to the engine voraciously seeking results that may never see the light of day anyway.

The engine is self-regulated. It keeps track of the average run-times of each portion of itself and later uses that data to determine whether or not it is necessary to interrupt a cycle for frame passage. If it expects the next segment of calculation to take too long, it ends the sequence, otherwise it continues.

The engine is also capable of running multiple cycles within a single frame (as in the first Liberty Engine Demo), but that function has been turned off for now.

More to Come

I’ll go into more on the math and methods later, but for now I have enough work to do that I shouldn’t be blabbing on. If there are formulas you’re looking for, don’t be afraid to ask. It’s a bit of a trick to find all the physics you need for this kind of thing. I was shocked to find out how rare it was for anyone to consider time-based physics instead of frame-based and that adds hours to your research.

I was happy to find this article from gamepoetry.com last week. That’s really the reason I felt compelled to post this update. Apparently Panayoti will be doing a much needed series on this topic.

Next time I’ll definitely incorporate some more interactivity so you can drop in some forces and objects. I’d also like to allow the engine to run backwards, calculating the past in addition to the future. With that capability, it wouldn’t be necessary to save as much equation data because it can easily be recalculated when necessary.

Too much to do, not enough time to do it.

-Christopher J. Rock

P.S. At 3491.9 (58 minutes, 11.9 seconds) an error occurs! This is due to simultaneous collisions. Simultaneous collisions are only accounted for in some circumstances right now. That’s one of the fixes I still have to make, but I think this shows how rarely it actually comes up. Thousands of collisions occur in that first hour before a single error rears its ugly head. Not bad.

I allowed it to calculate 10 hours of data without significant drop-framing. Unfortunately, there seems to be a bit of erroneous energy loss at an extremely gradual rate. After 10 hours, objects are moving much more slowly they they were at the start. That should not be occurring! . . . On the other hand, it’s not often that you run an engine for 10 hours anyway. . . .

UPDATE: I did the same 10 hour test with memory set to 60 seconds and there was no loss of energy! . . . Flash calculations are becoming less accurate due to all the equation data I was storing. . . . How strange. All the more reason to implement backsolving rather than saving all the information.

CUBOCC face demo

Anyway, I saw this demo at http://cubo.cc/ today and it kind of shocked me. Apparently it’s a bit viral already, spreading around the net as it should. Some awesome coding, brilliant texturing and a simple design goes a long way, doesn’t it? The future of Google Adsense? Unfortunately, most likely! haha

But wait… that’s not all!

renderhjs’ 3d texturing demo

A dude that’s always impressing the hell out of me is renderhjs from the Flashkit forums. He’s always doing incredible tech demos and applications and his artwork kicks ass as well. He’s currently working on a 3d engine with a custom 3d format, with UV texturing. Now all he needs to do is an IK animation system. Check out his thread for it.

Papervision3d 2.0 site

Just in case you’re not familiar with what the open source 3d Flash engine Papervision3d is capable of, check out the official website. It’s a 3d underwater scene rendered realtime in Flash. Expect to see interfaces like this more often as developers embrace this technology even further.

Finally I put some code up here:
“TraceManager.as”
“TraceManager Test.fla”

This is an AS file I put together for some big engine work. When your jamming together a lot of code and a big library of functions, it becomes difficult to keep track of what’s working and what’s breaking. For me, constantly turning traces on and off and having to figure out the meaning of traces that I wrote weeks (or even months) ago gets old fast.

Lately, my physics work has me running more functions than you can shake a stick at; functions within functions within functions, nesting like you wouldn’t believe. This leads to the most hideously complex tracing, almost nullifying the reason you trace data to begin with. So I put together this TraceManager to end such problems once and for all:

_________________________________________
Time(seconds): Depth: Function:
—————————————–
0________________+0____function1 (test1){
0________________+1________function2 (test1 1){
0________________+2____________function3 (test1 1 2){
0________________-2____________} function3—RESULT( test1 1 2 3 )
0________________-1________} function2—RESULT( test1 1 2 3 )
0________________-0____}function1—RESULT( test1 1 2 3 )

-This trace is from the example fla. It runs like so: function1 takes a string (“test1″) and adds a ” 1″ to it, then passes the result to function2; function2 adds a ” 2″ and passes the result to function3; function3 adds a ” 3″ to the string and returns it. Each function returns its own result to its parent function until all functions are complete.

The new system just requires that the file be initiated, then at the beginning of each of your functions you run “TraceCheck,” and at the end, you run “TraceResult.” Traces are automatically formatted to resemble AS code, including indentation to show function nesting.

Since you may not want to see all your functions traced at the same time, you can limit the “traceDepth”. This will determine how “deeply” your nesting will be traced out. If you don’t want to see all those nested math functions, just set traceDepth to 1 and only the highest level of functions will trace out, otherwise set it to Infinity and see every step in the greatest detail (or use 2 to see only the top 2 nested layers, etc).

Using the tracesUNIVERSAL element in the constructor will automatically define all traceDepths, while tracesTOP will only define traceDepths for functions that have an undefined traceDepth. In other words, you can easily go between tracing only a specific few functions, tracing all functions except for a few, and tracing every single function you have.

The “Time” values allow you to estimate the processing time spent on a single function. Time values will even change within a single frame of flash activity, so you can easily see what part of your code is lagging.

You can also save on processing power by delaying all your tracing until after your program is done running. All the trace data is saved as an array of strings until the “TracePrint” function is run and everything is converted to a solid string variable and outputted. This comes in very handy because constant tracing can slow your framerates way down. You can also use it to give your programs a “command line” kind of output by linking the TracePrint function to a key or manually accessing the outputted string (returned by TracePrint).

When your development phase is complete and you don’t want to spend any unnecessary processing on the TraceManager, you can set the constructor’s onSwitch variable to “false” and TraceManager functions will no longer run.

There’s a more specific explanation of the TraceManager in the comments at the top of the file. I’ve also included an example fla for experimentation. If you’re still confused, you found a bug, or want to share your own update to the file, comment here. I’ll comment whenever changes are made to the original files.

Those links again:
“TraceManager.as”
“TraceManager Test.fla”

Check it out!

It might not be the first Flash port, but it’s definitely the first that resembles the original in speed and resolution. I could totally imagine playing some deathmatch in this thing. Can’t wait till something like that is available.

It’s also worth nothing that this was not created using Flash. It was developed on Linux using open-source/free Flex tools.

This reminds of back in 2001 or so when I saw a demo for a Quake 3 looking engine in Shockwave running incredibly fluidly. I recall it being a Q3 port of some sort because it was created by the same company that ported Q3 to Dreamcast, Raster Productions. I’m assuming it was some kind of port because they removed the demo after a short while, I believe because of legal matters.