Optional parameters include update interval (in milliseconds) as well as the color of the data/border.

Source: SWFSpecs.as.

The algorithm itself is just a simple breadth first search. I think this algorithm is the best for this type of game because each edge has a constant weight thus eliminating the need for more complex algorithms. Furthermore, like Dijkstra’s algorithm, it generates the shortest path from all nodes to the destination (when initially called from the destination node). Optimizations include using a one dimensional array to represent the map and thus reduce access times as well as generating a border around the map. This border eliminates the need to check whether or not you are accessing an array element that is out of bounds. This check would normally be done many, many times so this simple optimization shaves off a couple milliseconds.

Using straight BFS has one drawback — it doesn’t handle diagonal paths by default. Thus I have created a simple “relax” method to determine whether a new edge can be relaxed to a diagonal. This slows things down a bit, but the performance is still quite good. In the current demo, the map is 35×35 and I get all square paths in 1-2ms and all paths with corner clipping in 2-3ms. That’s pretty darn fast!

View Pathfinding Demo.

Source: Main.as, BFSDemo.fla.

Also, here is a version which uses 2D arrays and Points which makes it slightly easier to understand but it runs about twice as slow (still pretty darn fast though ).

Other than the engine, I still have to create all the art for things such as the title screen, the menus, buttons etc as well as program the actual game play. Finally I will have to look for some ambient music and sound effects to bring the game together. But right now I am focusing on the technical aspects of the game to make sure everything is running smoothly in the background. The final piece to be added to the engine will be collision detection but that won’t be too big of a deal (to implement or speed-wise) because of the way I have designed the engine.

One thing I am happy with is how the erie atmosphere came out. I was originally going to use some form of raytracing to generate the view but quickly abandoned that idea knowing that flash couldn’t handle it. Instead it is coloring the objects based on distance. So if the object is far enough, it wont be visible to the bat (and its echo location). The sight factor is a variable which will allow it to change during the course of the game with power ups and upgrades. Once I have the bug sprites floating around as well as a big full moon, I think the game will look pretty nice.

*UPDATE* I have finally finished most of the optimizations. The trees seemed to be the biggest problem and I’m happy to say that I was able to double the tree count from the last demo as well as make it perform better with those extra trees!

View Engine Demo.

I probably won’t release the source for this game unless I decide to scrap it or no one is interested in licensing/sponsoring it (which is more than likely).

As you can see by the demo, the game will be in 3D and the trees will be randomly generated fractal trees. I’m a little worried how my implementation of the echo location will turn out. I have a couple of ideas how I will program it, though I’m not sure how well flash will be able to handle them speed-wise. This project should be complete soon (if my ideas work) since there is very little artwork to be done other than the title screen which I will attempt to do on my own.

View TBW Demo.

Since I plan on making some cash on this game, I’m afraid I won’t be able to release the source..

The engine is actually a stripped down version of my J3DApplet which I wrote a while ago, which is also a port of an earlier engine zylum3Dv2. You can find a copy of zylum3Dv2 somewhere on compsci.ca though it’s written in Turing. BB3D is currently made up of two classes, the main BB3D class as well as a Vector class to manage all the vector operations. Ideally there should be a transformation class as well as a polygon class to store more polygon properties other than just the vertices. Currently, polygons are stored in a 2D array so there is no information for color or anything else.

Source: BB3D.as, Vector.as.

One of the more challenging aspects of the texturing was mapping each drawn pixel to a pixel in the square texture. The rotation of the ball is represented by 3 perpendicular unit vectors. One vector is points to the center of the texture, another helps determine the polar angle from the first vector to the point that is being drawn, and the third vector aids in figuring out whether or not the angle is greater than 180 degrees since a dot product alone cannot tell you this.

With this outta the way all I need to do is write the physics engine. For the most part this shouldn’t too difficult as I’ve written a tutorial on perfect circle-circle collision detection as well as understand the physics of 2D and (for the most part) 3D collision reaction. The only thing that I have yet to study is the effect of applying a spin on the ball (ie not striking the cue ball perfectly in the centre with the cue stick). I want this game to be fairly realistic physics wise as well as visually. I’m thinking of adding RPG elements to the game where you start off as a noobie and as you play your shot becomes more accurate over time. If you tend to shoot more long balls, your long shot will improve faster than your short shot etc.. I’m still thinking about the design of the game so no code has been written yet. I’d be glad to hear any suggestions as how to enhance the gameplay.

In the task bar of your browser, the applet should display what kind of load it is experiencing. I have manage to optimize it to the point where it only loads the applet 36% when all the balls are on the screen. When the physics and further drawing is added, this should stay below 50% for my 2 year old laptop. At the moment this applet also takes up 25% of the processor.  I was hoping you guys could let me know the numbers you are seeing so I could do more optimization if necessary.

View Phong Shading Demo.

Source will become available when the game is released.

To manage the complexity of this game, I designed a condensed finite state machine. There are four states in the FSM, though there are many more states in the actual game. I used the current state along with other game information to transition to other states. I played the game for a little while and didn’t find any bugs, though I’m sure I probably missed something. To move a gem, you can click on it and then click on the destination, or you can simply drag the gem to it’s destination. If you don’t make a legal move in a certain amount of time, you will be given a hint but will be penalized 10% of your score. If you reach a position where there are no legal moves, then you are penalized 50 points and a new board is generated. I managed to get a score of around 450 but only played a few times, so I’m sure you guys will do much better.

Play Gem Swapper.

Source: GemSwapper.java, Game.java, Gem.java, Move.java, FPS.java

Note that the source isn’t commented yet as I am tired and a lot of the code is quite complex so there will be tons to comment. I will be glad to comment if anyone requests I do so or answer any specific questions about the code.

So far I am pretty happy with the way it is turning out. Having some shiny animations like the original game would be cool though. I am going camping this long weekend (leaving this afternoon) so when I get back on Tuesday, hopefully I can find some time to add the finishing touches.

Play Gem Swapper.

Ill post the source when it’s done as I have to clean up a couple of things.

To create the effect, I used an adaptation of brownian motion. Basically, you draw a random path from one point to another. Each squiggly line consists of smaller incremental lines. At each stage of drawing the squiggly line, the path chooses a random direction based on the current position of the end point. This ensures that the path doesn’t go too far off course. Once the path is within the incremental drawing length of the desired endpoint, we connect the current position with the end point.

The main challenge of this project was ensuring that each line segment is drawn only once. For example, at each frame the game draws the border, the food and the snake (in that order). Thus, once the border is drawn, if the piece of food is generated on the border then one of the sides of the food should not be drawn. If it’s generated on the corner, two sides should not be drawn. Furthermore, if the snake is along the border, or moving along a portion of it’s tail, many line segments should not be drawn. If in any of those cases the lines were drawn, then the effect would be ruined because the squiggly lines would overlap and create thick, ugly lines.

To solve this problem, I keep track of which lines have been drawn. Specifically, the lines are stored in a TreeSet which is implemented as a red black tree. This ensures fast queries which is good since there could potentially be hundreds of lines drawn per frame. Rather than creating a new class which defines the x-position, y-position and orientation, I decided to generate a unique number for each line based on each of these variables. This way I save some memory and avoid having to write a comparator for the new class. Since each line has a semi-unique position (a horizontal line can share a position with a vertical line), the integer generated is the location of the line plus an offset of N if the line is vertical (where N is the number of positions). This scheme ensures that each line gets a unique number since the problem of shared positions is fixed by adding the offset to vertical lines.

All in all the effect turned out quite nicely. I don’t know why, but I find snake a very addictive game. After I completed it I played it for quite some time. I managed to get a highscore of 63 — see if you can beat that!

Play Hand Drawn Snake.

Source code: Snake.java, Game.java