In Octave Devlog #4 - Evil schemes

Once realized I was too sensitive and empathetic to conquer the world and cause any chaos and misery, I renounced to become a lord of darkness and instead went to a software engineering school. But now, as a game developer I can finally fulfill my dreams of being evil without causing any actual harm! Behold, the power of game-deign!

This week, I've worked on the game balance. The goal was find the good sizes and speed so that the game feels and look right. It was also a way to measure its difficulty. It should be hard, but not too frustrating. I've ended up with some satisfying results. I also worked on colors and some other minor aspects. The game aesthetic is now complete!

But I also planned to add some variety to the game. Because as it was, it was actually too easy. And I want the players to suffer a bit, hehe. So how could we achieve that?

Spinning walls

So far, there was a huge breach in the game-design. The player's goal is to make the balls bounce without hitting them. So what prevents them to do this?

This doesn't seem very exciting… And yet, it's the best winning strategy. Not even so hard to find out…

Even before starting the development I was pondering on this issue. Should I change the way the balls bounce? Add another rule? Think the whole thing again?

But then I found the solution. A simple, wonderful, awful idea.

MUHAHAHA! Eat this, player!

Surprisingly, this wasn't as easy to implement as expected. All of the eight walls were in the same group object, and my idea was to simply rotate that parent. Unfortunately, this wasn't working with the P2 physics engine, who doesn't read relative positions. There's actually an issue on that matter. (And I certainly didn't create one on the wrong repo before realizing I had opened the wrong tab. Those are lies!)

So my backup solution was to rotate each wall individually. Yeah, feels pretty weird. But hey, it works marvelous! And the math behind aren't so complex.

As you can guess, this has also an incidence on the melody created by the balls. I have yet to test the configurations I described in my post on the subject. I might stay with number 2 though, as it currently create nice melodies.

Okay, we have now balls that bounce in unpredictable ways. But this is still not enough. We can be even more sadistic!

Many balls

Actually, the initial idea behind this feature was in good intentions. I wanted to have more than one instrument. After all, at the end of the game, there will be eight balls bouncing constantly. It would sounds a bit messy if they were all playing on the same instruments. Why not having some balls that make different sounds? Yeah, they would have different colors too, so that the player can understand that they are different.

Uh-oh. If there are different kind of balls… Shouldn't they have different properties too? The player might be confused if it is just aesthetic. There has to be a game mechanic too! So… Welp, let's make three types of ball! For the Greater Good.

Cry, player, cry!

Here are the types: The blue balls are the first and default one. The player starts with them, until level 3. Then they get orange balls, that go way faster. Three level later, purple balls are introduced. These ones move in curves instead of straight lines. By the end of the game, the player will have to deal with 3 blue, 3 orange, and 2 purple.

The purple were the most special to build. The way they work is that they have some kind of gravity applied to them. This makes them go in curves, but also make their speed inconstant. I didn't want to have a too complex solution (the player might be confused, and me as well). It was pretty tough to balance. At first, they were attracted to the center of the octagon. However, the results weren't really satisfying: either the ball was hitting the same two opposite walls (making a very boring melody), either it was almost stopping once it was too far away from the center. Solution 2 was to make the force repulsive instead of attractive. This is what you can see in the gif: the ball is pushed toward the octagon's extremities. This has a downside too: it doesn't venture that much in the center, and hit consecutively adjacent walls pretty quickly (making challenge easy). So I tried two other solutions. One was to make the ball attracted to the player instead of the octagon's center. Like an auto-guided missile! Well, I quickly threw that out. The more the player tried to get away from it, the more it was accelerating! It one point it was impossible to avoid. Giving it a maximum speed could have been a solution, but again, it was getting too complex for my taste. The fourth idea was to alternate the gravity each time the ball hit a wall: attracted, repulsed, attracted, repulsed, etc… It ended having somehow the downside of both solutions. Plus, the balls behavior wasn't making any apparent sense, and the pace was really inconstant.

So I decided to stick with the second behavior, a repulsive force from the center. It's the least problematic. And after testing the whole game, it's not so bad to have a “easy” ball after the 3 orange ones. It makes the player breathe a little. The arena is already crowded, another ball, even a slow one, still makes it harder! Plus, having it staying on the edge is not so useless. I discovered that staying in the center was a risky strategy, because there's a lot of balls that go there. So staying near the edge is safer… But then a purple ball might run pretty quickly along the walls, making them difficult to avoid! So, while I planned to have a weird and unpredictable new adversary, it's more like a regular ball with some oddities. My main concern is if the player will see how this ball is different. This is also why I wanted the trails: they are making clear that the purple's path is curved. However it is a very slight curve… I hope it's still noticeable! I couldn't making it more tight without breaking the balance.

Speaking about the balance… The game is pretty hard! But it's also short. It's easy to get stuck on the last two levels, but with enough perseverance they can be passed. Well, at least I could pass them. And I know I'm not the best one at bullet hell! I also noticed that the game seems easier played with a joystick, which is not so surprising after all. I might release an open beta soon to have some feed-back on the difficulty. But I'm confident with what I've obtained here.

At worst, players will loose their mind on the last level, and I will laugh at them! This is truly why I make games!

Tying up loose ends

There was some fixes that has been done this week. Some more important than others… For example, I talked last time about some performance issues… Turns out it wasn't because of the particles of the trails, but the gradient from the background! When the background is animated, each frame has to calculate a radial gradient. And radial gradient are CPU consuming! I still wanted to have those progressive gradients though… So I used a, albeit cheap, but simple solution: making them asynchronously (with a good ol' setTimout). This way if calculating a gradient takes too long, Phaser can still run the game. However I had to make sure that the gradient wasn't behind the action! Thus, the drawing is done separately from the calculations, so that the second one is always sync with the game, and the first one follow what is happening. This way, while gradient still consume as much CPU, they don't slow down the game. And if too many gradient are drawn, they “skip” some frames, making the background animation less fluid, but not impacting the game action.

Also, as the pointer on my previous screenshots bothering you? Me too. It has been replaced now. You can see it on the first gif of this post. Just a circle (another one ). There are also some updates I've done on the game's look. You might have noticed the ammo circles on the player are heavier, and use balls' color. Same thing for the wall when they are hit. And you can't see it here, but I've added the same effect for the player, making the impact more clear. Overall, it gives some nice visuals and feed-back.

Next week I intend to work on audio! Deciding on the instruments, the sounds effects, and beginning to program the background music. Which, like the background, will also be dynamic. I might be able to release a beta after that? We'll see. Stay tuned! (haha, “tuned”, hem…)