Dynamic level creation and pooling

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.

Making the bat fly (and dash)

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 isnt the perfect dash system as we envisioned it but its 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.

Master of prototyping

Picture of the prototypes (1. & 2. Bat with sonar, 3. final prototype version, 4. bat in wheelchair, 5. multiplayer, 6. QWOP-bat, 7. Bat & Pig)

During the first phase of this project my main assignment was to prototype different features for our bat game. I don’t think I will have a more enjoyable task throughout the development cycle. Prototyping, or rather experimenting with different features and mechanics is definitely my preferred method to game development and design.

We had a lot of different ideas of how our version of “Heartbeat bat” should be. Some of the ideas where clearly bad and was scrapped instantly other ideas went on to a prototype phase. Here I had to, in Game Maker, quickly make playable prototypes so we could test how a certain feature worked. This blog post will cover the entire prototype phase and I will try to explain how I worked and what that work meant for the design of our game. This is not

At first we tried to make the game play as close as possible to the game described in the concept document. This was mostly based on the sonar mechanic where the bat would use sonar pulses to detect the level obstacles. This was a pretty cool visual effect to see the level appear in front of you, but it also made the game a bit slow. In order to make the game playable and still have a meaningful sonar effect we had to both decrease the complexity of the levels, and the speed of the bat. We wanted to have a bit more speed to our game, so we tried a couple of prototypes with full vision. In these I tried different versions of a more physical control scheme where the bat was controlled almost like a glider. Here the bats angle would affect both the bat’s speed both vertically and horizontally. I really saw potential in this type of movement, it added a big skill element to controlling the avatar. Big dives would give the player a huge boost in speed while ascending quickly would slow down the player to a near stop. But this method of moving the avatar was not received well in the team. They found it way to difficult to control the bat and wanted the player to have much more direct control over the avatar. So the final prototypes was based on a more controllable bat with a more complex level design.

Outside of these above mentioned prototypes we also tried some others that was a little more “outside of the box” for more unique takes on the bat game. Among these were one multiplayer prototype with two bats racing, a QWOP-styled game that let the player individually control each wing of the bat, a physics game with a bat in a wheelchair rolling down a hill and one version that let the player control two characters simultaneous (a bat and a pig). These (except maybe the multiplayer one) did not have substantial impact on the game we are working on now but they made us let go of ideas that weren’t feasible and therefore they worked. Showing that something doesn’t work is almost as important as the opposite.

Extensive experimentation and prototyping might not be the way to go in a well-oiled team with a unified vision and a strong leader. But in an inexperienced team with democratic structures for decisions it pretty important to try out the different ideas of the group. Both to find the good ones but also to leave the bad (or too hard) ones behind. Also, although it is a pretty sloppy way of designing a game, it is pretty fun.