THESIS BLOG

Over the past term, I’d been working on a number of utilities and algorithms to put to use in the game. More recently, I’ve been compiling everything including these new assets into the latest full build of the game, which I will also be posting over on the build page.

The first test I did involved a new way to calculate the drawing points for the surface of the planet. I’d run through a number of methods, including trying to use the curve drawing functions built into flash. I determined, however, that their functionality was too limiting, and wouldn’t work for what I needed. Flash gives you the ability to draw a curve by specifying two points, and a third which connects 2 tangents from those points. This unfortunately does not allow for any cubic curves, which I would need at points.

As a work around, I spent a good amount of time developing a quick and rough algorithm for computing interpolated points between “knots” on a continuous spline-curve.

After this first, rough pass, I run a smoothing algorithm that re-aligns the points based on their neighbors. The result is something similar to a b-spline, drawn from control points:

Next I started to try and tighten up the over-all playing concept for the game. I needed an end goal for the player to try and accomplish in while on the music planets, and inside this universe as a whole. I came up with a scenario where the player would have to change the size of the planet’s body-mass. As the mass would grow, the planets atmosphere would remain the same amount, creating the illusion that it is shrinking slightly, as it stretches to wrap around the larger planet. Eventually the planet breaks through it’s own atmosphere, and that how the player will complete that song/level/planet.

The following example also shows off a dynamic slider I coded to help me rapid prototype different effects in the game. With sample values driven by these sliders, it will be easy for me to determine the best default values for new features I make in the game.

Next, I did some more research on object pooling. I had already gotten working my first version of a pool which I used for the intro screen. This pool however could only accept one type of object at a time, which I was occupying with the glowing orbs on the title screen. My game world, however, needs to be populated by several different classes of objects and enemies. Firstly, I want to be able to cap the total amount of objects on screen at any one time to save processing. Additionally, I don’t want to have to make a new pool for each object.

The answer I came up with was an auto-recycling multi-type object pool. The pool starts out with nothing but an empty custom object inside it. I can add array variables on this object dynamically each time I need a new type of item to put in the pool. Essentially I set up a global managing-pool which has several simple pools inside it. Each smaller pool has it’s own limit which I can define per-object-type. While the pool itself has no strict cap, I do cap the amount of objects I have on the screen at any one time. Any time I make a new call for an item, and these limits are exceeded the oldest member of that object-type is called back into the pool for recycling.

In the following example I add 4 different types of object to a pool as they are called on stage randomly. I also only 8 items to be on screen at one time. Once the 9th item is called, the first is recycled back into it’s own type’s array in the pool. This test shows the resulting ratios of items that build up inside the pool. It also shows the total size of the pool as compared to the total items on screen. For 4 types, it can essentially grow to 3 times the screen-total, but this test shows that this takes an incredibly long time for that to actually happen. The real total does not accede the screen total by much.

Over the past couple of weeks I’ve been going back into many of the scripts and functions I had put together for my previous game Pulse, in preparation for the newest music code from the METLab. I’ve also been studying up on numerous optimization techniques for flash and Actionscript, which I’m hopeful will show a boost in the performance of this new game.

Below is the almost finalized start screen fir the game, which features an object pool of the light orb objects. The objects do dissapear, and respawn, but by keeping the instances around in a consistent pool, I eliminate the need to rebuild them or perform any garbage collection. I plan to use this technique for the various enemies and collectibles throughout the game.

This particular visual with the light orbs is what I imagine the void space between two music planets will look like once you break through the atmosphere layers.