Chaintanks Devlog 7 – Slow but Steady

It’s been a few weeks since my last devlog, and despite not having a ton of motivation I’ve been plugging away at Chaintanks.

Since the last blog I’ve been working towards the new vision I set out last time; I’ve successfully eliminated infinitely long tanks and implemented an upgrade screen to allow the player to fine tune their much smaller chaintank:

Upgrade screen screenshot
It’s missing some values, and I’ve cut out the heat feature, but neglected to remove the text fields for it. It works though. Really!

As I said in my last blog, I’ve opted to go with a new implementation for vehicles that limits them to six vehicles each. Since the player’s chain is now so small, it’s not acceptable to let the weapon or upgrade level for each segment be random. This screen was necessary to let the player adjust the size of their vehicle, upgrade segments, and change what weapon each one is equipped with.

Removing or downgrading parts doesn’t have any penalty to it. I figured it would be best to let the player experiment with it as much as they wanted and not be punished, especially since it’s a small game that will probably only be played through once.

Implementing this screen was time consuming, and there’s not really a way around that short of going with a less complex UI. That’s not a bad idea really, since the one I’ve made seems quite crowded. I do have some ideas on how to simplify it a little bit, but I don’t plan to redo completely it at the moment as I want to focus on actually finishing the game. Revisiting this screen might be something I’ll do during the final polish phase, however.

Art time!

After finishing the upgrade screen, I focused my efforts on getting the new level system up and running. The largest part of the work by far was creating the art for the levels. It turned out okay, though not amazing.

New background screenshot
This looks a little plain at the moment, the level needs some love. Very happy to see that hideous sand background gone though!

Again, I may or may not revisit this. If my goal is to develop my skills in as many areas of game development as possible, I’d be better served by finishing Chaintanks so I can finally learn the process of actually shipping a game. Not only that, but I’d avoid falling into the trap of leaving a dozen dead games behind me as I try to actually finish one.

To call the game complete, I’d ideally like to have art for two more tilesets so I can have more variety in the levels. I may settle for one extra though if that takes too much time. One of the lessons I’m beginning to grasp in the creation of this game is just how precious time is. It’s entirely too easy to spend weeks on a screen or a bunch of art only to find in hindsight that it wasn’t very good, or that the game would have been fine without it.

Smaller Features

Lastly, I finished a few smaller features as well. The first was the actual implementation of the maps. For this, I decided to just make each map a scene in Unity. I’m not sure if this is the best approach from a programming standpoint, but it’s a lot less work than serializing data or creating a level editor. If it gets the game done faster then I’m all for it!

The new maps also required edge tiles that block vehicle movement. My solution was a bit hacky, but I was able to implement it quickly and get it working within an hour or so. They don’t block bullets at the moment, but that will barely take any time at all

Adding these edge tiles meant that my old spawning system needed to be thrown out. At first I had some weirdly complicated idea of trying to reuse the existing system of spawning an enemy somewhere in a fixed distance from the player, but also trying to detect if it was in a valid location. When I actually sat down to implement it, I realized it would be MUCH simpler if I simply added spawn points to the level maps and had the game pick one at random that isn’t too close to the player. This solution took less than an hour to implement!

After working for so long on Alpha Strike and taking hours to implement even the simplest features, working in Unity is a huge breath of fresh air. These features took so little effort to code, and yet they’re crucial in that they’re some of the final pieces needed to get the level system fully working.

Making my own engine was an interesting challenge and I’m a better programmer for it, but it takes much more than raw programming skills to make a game; most notably, time! Just by spending so much less time on programming my dream of one day making my own games for a living is so much more feasible.

In the meantime, there are a few bugs I haven’t fixed yet, but with this done the only major feature I have left is the final boss! That is, if I don’t choose to cut that feature.

More cutting?

At the moment I’m fairly sure that I’m won’t be cutting the final boss. However, if I can find a way of ending the game that isn’t just the same old ‘kill the big thing at the end’ trope that so many games have done before, then I’d prefer that over a standard boss fight.

I’m not too worried about it though. If I manage to think up a better way to end the game then great, and if not, I’m not too worried about it.

There’s still a good bit of work left to do, but it’s finally beginning to feel like the end is in sight. For now I’m going to continue to focus on getting this game completed, avoid adding new features, and make myself more comfortable with calling things done! With any luck, it’ll be done soon™!

Leave a Reply