The end is near and now it seems like the only thing I do is to try and fix, clean up or rework the different crazy and broken programing solutions in our game. It’s early pre-alpha code, dressed up for alpha, repainted for beta and now we are having the great task of deciding how much to fix with just duct tape and a paint job and how much we need to fix “for real”.

One of the many things that has been getting my attention this week is our “sonar blast”. This is when the bat unleashes a powerful wave of sound that destroys most of the obstacles in its path.

This is one feature of our game that hasn’t been getting that much love and attention from us. Mostly because it’s just a solution to bypass the projectile requirement. But when the game is starting to look better the contrast of our crappy sound wave sticks out really bad.

The way it worked in the beta was that whenever the player pressed space five objects (each with an individual id) with the wave-sprite would spawn on top of the player. The first wave object would start right behind the bat and from that object the rest was created with an increasing horizontal offset. Making them look like some type of wave. After spawned these waves would travel to the right on the screen and increase in size. The visual effect of this was okay but definitely not good enough.

The reworked version still has the five wave segments but I made some changes to enable me to control each independent of each other. So now the bat has a timer that enables me to spawn each segment at different times. This means that when the sonic blast is activated it spawns one small wave segment in front of the bat that grows over time. Then every 9 frames four times the rest of the segments are spawned in the same way, one at a time. This gives the effect of a growing cone-shaped wave that is smallest towards the bat and biggest on the opposite side.

The look of it is pretty much how we wanted it now but I still have some problems with the collision boxes of the wave segments. I’m trying to achieve a synchronized scaling of the collision boxes that follows the sprites scale but somehow, however much I try correcting it with my mighty shotgun the boxes keeps getting out of sync with the sprites. This is probably the result of three programmers working on top of each others codes so somewhere there will be a small bug-ghost hiding from 3-4 weeks ago. Most likely this will not be solved in a great way in the final game. Just as long as the player feels like the sonar blast is working correctly I’ll leave it. So much to fix, so little time.

The beta-crunch is on and this week our group have been totally focused on adding the last, important features to our game. But also cutting the features that we won’t be able to add in time for beta or final.

In our game the players avatar, the bat, has many different states that are all represented by a change of animation to the bat. Examples of these is: “flying” -the normal animation cycle of the bat flying without any powerup, “greenP” –the effect of the green powerup, the bat is covered in a green slime-like glow and “dashing” – the bat is inside a sparkly field that should indicate the amazing speed of the bat while dashing.

One of the things I’ve been working on this week is a collection of functions we call “wanted animation”. What this does is actually manage the different animation cycles of mainly the bat and change it according to some set rules of priority.

This basically means that instead of just switching animation for the bat when something happens, we actually, whenever an animation event happens, instead send a message to our wanted animation. The wanted animation then decides if that animation is applicable to the bat in that situation.

There is actually two reasons for this. First we don’t have to have the many animation switching events individually keep track of the many different rules and priorities that govern if the bat is able to go in to that state. And second we have a system to actually hold back the triggering of animation that might not be able to apply at the moment, but a bit later.

So, if the bat hits a green powerup that powerups animation is added to the wanted animation. In next update the engine will check if the current animation is matching the wanted animation. In this example let’s say it doesn’t. Then the current animation will change to what’s in the wanted animation. If some seconds later the player decides to do a dash while the green powerup is still active, the dash animation actually has higher priority than the powerup allowing the animation to be switched once again. But, if the short dash animation is finished before the green powerup has run out that animation would actually still be in the wanted animation so the bat would go from dashing to being “greenly” powered up.

For the future I also hope to make this system actually transition between the right frames within the animation cycles. So if the bat is on frame four in an animation cycle, the system should be able to start the upcoming animation on frame five to make it look really smooth. The “problem” is that it actually already look pretty good so this will probably not be prioritized.

This week we have continued our journey towards the beta-version of “Dash Bat” (originally “Heartbeat Bat”). My main objective for this week has been to include the mosquito swarm -enemy into the code. These are tightly packed clouds of super aggressive mosquitoes that will slow down the bat.

These enemies will be very useful in our levels since without them we only have obstacles originating from the ceiling or the floor. These swarms will give us the ability to place extra obstacles in between our regular rocks and icicles. The swarms will also give the player a little more to think of when playing. Since the bat can dash we want these enemies to be “dashable”, that means that the player can either avoid them, or if he/she has a dash-move available, dash trough the swarm of mosquitoes that will disburse.

At this point they are just classes in the code, not really implemented but they will work basically the same as any other obstacle in the game. They will have a sprite and a hitbox, they will also be placed in the same basic grid as the other obstacles. The different with placing the swarms is that they will not be placed on the top or bottom of the screens, instead they will be placed in either 3 or 5 different lanes in the center portion of the screen. Like this:

000001000000010001

001000001000100000

000001000001000001

Think of each number in a row as a horizontal coordinate in the level. The rows itself represent a set vertical coordinate (lane) on the screen. In this example “0” represents an empty space and “1” represents an enemy.

The other things that makes this different from the static obstacles is that these swarms have their own movement. Some of our obstacles already have vertical movement like the spiders that attack from the ceiling or the icicles that drop on the bat. But none of them has any horizontal movement. By giving these swarms movement we can give the player two different types of variation from the usual level. If we give them a speed towards the goal of the level, then they will move slower on the gamescreen giving the players obstacles that they will have to predict. If we give the swarms movement speed towards the start of the level they will move faster than the static obstacles. Disrupting the players planned route making them have to make even quicker decisions.