This Deepvelopment Monthly post will cover my work on Deep throughout May 2015.
Bumper Bar -Content -Balancing
This wasn’t actually on my todo list for the month, but while I was playing through the game to test out [future content I can’t talk about yet!], I realised that the Bumper Bar was actually entirely useless against actual enemies! Its main purpose is to push boulders around so that you can use those as weapons, and it’s not really meant to be a super useful offensive tool on its own, but during my testing I was finding myself instinctively trying to use myself as a last resort to protect myself against close range attackers when I was low on ammo. But I designed it too small compared to the robot! I even tried making it stick out a little further at full charge but I just ended up getting hit by enemies more often than I could hit them. So I redesigned it entirely and I think it looks really cool now! Here’s a before/after comparison because those are fun.
(I also like doing these so that you can see how the visual style and animation has evolved!)
It’s much less choppy, the bar comes out faster, it’s larger and it has a cool dust effect!
Attached Projectiles -Programming
Some of what I worked on also had to do with projectiles! (again, sorry!) This time it was all about creating projectiles that could be easily attached or separated from other entities. It’s a little hard to explain in words, so I’ll demonstrate by showing off a new enemy type!
Check out this guy! He’s actually not an enemy you normally find in the early game Caves. The reason the attachable projectiles were required to have him function is because of how he attacks.
You’ll see it’s the actual spikes and shell that you have to worry about, not the head. But they don’t stay attached to him!
As I demonstrate here, this isn’t really a problem you can tackle from close up, which is why you won’t be encountering them until a little later on in the game. Even if you use your bumper bar to shove a boulder at them, the spikes will often destroy the boulder before it can hit the Snell itself!
This is going to be a long one!
If you follow me on Twitter (why wouldn’t you?) then you’re aware that 90% of the work I’ve done this month has been on Boss Battles! You’ve probably seen this guy before:
I’ve shown little bits and pieces of him before (the second ever post on this blog featured a very early depiction of him!) but you could consider this his official introduction. His name is Bandit, and despite his size, he’s technically an insect. He’s an evolutionary mistake though, and the only one of his kind, which is part of why he’s so gigantic. Here’s a little size comparison:
(The robot is 1.7m tall, so this is a big bug)
Boss battles were one of the first things I implemented when I was coding Deep, so this fight has kind of existed for a while, but in a beta state. After this month’s work I’m happy to say that I’ve finished the work on the fight entirely! There are 3 increasingly difficult phases, which will test your puzzle-solving skills and reflexes. I’m REALLY excited about the boss battles in Deep, maybe more than any other part of the game. I’m trying to make them as dynamic, creative and unique as possible. I don’t want to spoil too much of course, but I will say that Bandit is the first boss in Deep. The exact location you find a Boss in will of course differ from save file to save file, but you’ll always encounter him in an Ice themed area early on in the game, and I can guarantee that you won’t have anything to battle him with other than the Bumper Bar you start out with! Even at full charge, that won’t be enough to affect Bandit, so you’ll need to get kind of creative… Things will get pretty crazy as you deal more damage to him, and through his sheer size and power he’ll be able to damage the arena you fight him in beyond recognition. That will, of course, play a key part in the fight’s progression. I’m getting carried away! But please please be excited for Deep’s bosses!!
Bandit Glitches -Glitches -Programming
The downside of trying to do unique and complicated cool things for each boss fight is that it means they’re really complicated to get working properly. Hence spending almost all month on just finishing up Bandit’s fight (and the second boss! He’s a secret though…). Boss battles generally do a lot of things in the game that the game engine doesn’t already support so you have to do a lot of hard-coding, which isn’t a term that refers to the difficulty level of the programming! When you hard-code something it kind of means you are programming it to work without the help of what the game engine already does. So for example, if I added a new enemy type that could walk up walls, I don’t have to hard code that, since the engine already supports it. I just have to flick a switch that says ‘yes this enemy type can walk up walls’. But if I wanted to make that enemy mess up your vision, there’s nothing in the game that does that, and my engine doesn’t really have any way of easily adding that feature, so I would have to write very specific coding statements that change the screen’s rendering under the circumstances of that enemy attacking you. As a general rule, you should avoid hard-coding things where possible, since it adds to the complexity of editing or changing your code later down the road if you need to, as well as the total size of your compiled code. Unfortunately with bosses though there’s not always a way around it, since the whole point is that they do things that are unique from anything else in the gameplay. What I’m getting at is that glitches are frequent when you’re working on bosses, and that for a while Bandit would do nothing but this:
…and that I couldn’t fix it for several days. It was tough.
Again, you’ll already know about this if you follow me on Twitter! But it’s pretty exciting news so I thought I’d include it here. I’ve actually started work on an entirely new side project. It’s a puzzle game I’ve decided to call ‘Limiter!’ (including the !), I’ve had a fair few people playtest it now and received pretty overwhelmingly positive feedback so far. It’s by far and away a #2 priority to Deep, which will be completed before Limiter!, but I have to say it’s nice to have a smaller scale project to work on from time to time when I’m feeling really burnt out on Deep. I’m not at the stage yet where I’m ready to publicly talk about the mechanics of the game, but here’s a cool .gif to demonstrate the aesthetic style I’m using!
aaand the logo!
This is definitely something you can look forward to checking out when Deep is finally all said and done.
That’s all for this month and I hope you’ve enjoyed today’s post!