Korv makes games

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.

This week my main objective has been focusing of managing how our game handles entities (basically objects of the game like: obstacles, powerups and background objects). The way our game works now is that in the beginning the entire level structure is imported from a couple of text files and straight after that we create new instances (copies) of the objects and places those instances at the spots specified in the text file.

This might sound all good and great but it’s really not. With this system our game engine will have to make calculations with and between several hundreds of instances. So my work this week is to solve this problem by making a system that actually builds the level in front of the bat and deletes the level behind it. The tricky part is also that instead of deleting unused entities completely, the engine will actually just mark them as “unused” and place them in a pool. This pool is then available to the level creation code so before a new instance of an object is created the pool is checked. If an unused object is found in the pool it is reset and placed to act as the upcoming object.

Now let‘s make this concept a little more clear with an example.

The bat eats a lot of fireflies in a level, these acts kind of like the coins in a Super Mario game. Throughout a level there might be anywhere between 50 to 200 fireflies that the bat is able to pick up. With the dynamic level creation tool the fireflies will appear into the gameworld when they are just outside of the right border of the screen. If they are eaten by the bat or leaves the left part of the screen they will be placed in the pool. Since there’s never more than maybe six to eight fireflies on the screen at any given time the game will only have to create about ten fireflies that are used and reused throughout the level.

Hopefully this will result in some noticeable improvements in the performance of our games but most likely it will just be behind the scenes glory of a more agile game engine. It will also enable us to make huge (or infinite) levels if that is wanted.

The deadline for alpha is closing in on us and our little bat game. Still the stress to get the features needed into the game isn’t really that bad. We have the situation under control, I think.

This week my main focus has been on the controls of the bat, our game’s avatar. After the playtesting session we got a lot of feedback that our controls felt sluggish, slow and that the bat was to difficult to maneuver through the level. We also had a move related mechanic that wasn’t present in the pre-alpha that I had to implement.

So first thing first, the bat’s movement system. The feedback we got was that the movement was slow and also that counteracting the momentum from a move was to difficult to do. I basically had to rework the entire movement system. I sped up the bat a bit but mostly I focused on reducing the problem with counteracting movement. The way the movement system works is that if the player holds down a directional key the bat keeps gaining speed in that direction. I the player lets go of that directional key the speed in that direction will gradually decrease and eventually the bat would stop moving completely in that direction. Therefore before the bat could start to move in the opposite direction it would first have to overcome its current movement. So the solution for this problem was just to make the pools of speed drain faster. This makes it so that the controls feels a lot more responsive which might be good, but for me personally, also makes the game feel a bit to controllable. This avatar is a bat and should not really control like a well-oiled fighter jet, I liked the concept of having a pretty difficult to control avatar but I guess some times you have to listen to the “customers”.

The mechanic that needed to be included was the dash mechanic. When the player doubletaps a directional key the bat should do a quick little dash in that direction. First I had to solve the basic functionality of being able to double click. I made this work with a timer, so if the player presses a key it starts the double click -timer for that key, if the player then presses that key again before the timer runs out it counts as a double click. If double click (dash) is activated the player gets a speed boost in that direction for a short time. This isn‘t the perfect dash system as we envisioned it but it‘s good enough for alpha.

Now for the alpha showing I hope that the controls are good enough to show at least, which was the point of this week. Now it‘s time to start making things work well and clean for the beta.