Oh How Far We’ve Come

Hello any and all, welcome to the new (and long overdue) Battle Tracks devlogs. These should’ve happened earlier, but as I’ve only recently started managing a lot of the social media aspect and everything it didn’t occur to me. Thanks to several of my friends (Alphelion and Nardandas) for suggesting the idea.

Hopefully these will help give some insight to the innerworkings of the game, the troubles within the game and how I’ve handled fixing them. For note, I am not the only one working within the project, but I am the primary developer. As a bit of background, I was approached by my now-teammate Ethan to work on this on a commission basis a little over 2 years ago now. It was originally just to write the AI for the enemy tanks.

After a long series of conversations and continued progress, I ended up as the full lead developer on the project. Whoops. Ethan had made a lot of the base of the project that would end up being the basis for many things such as how bullets work, the scene setup, etc. This would have its own share of problems, Ethan is a bit of a newer developer and doesn’t have as much experience in making projects for the long term. We’ll slowly get into different aspects of that over time.

I should also note there’s another member of the team, Brian, though he is less of a developer and more of a manager. He does a lot to handle getting resources I require, setting up Steam and Kickstarter pages, etc. Ethan handled the team building, getting people together and organizing them, and communication between groups.

But because of how I was introduced to this project, the realization of the state of the code grew worse over time. I setup the AI working within the existing systems, with the expectation that it would be someone else handling their system in the future. Spoiler: It would be me. Not to say I wrote the AI lazily, or anything of the sort, but I wasn’t going to try to rewrite the code for shooting a bullet, or anything else for a commission to make tank AI.

So we’re now at today, everything is a mess, and held together with strong strong duct tape and redundancies. The project runs fairly well, but not without many hours of past struggles. There has been more than once I’ve thought of rewriting systems, or the entire game even from scratch, but they’re so ingrained within everything now I don’t want to touch when we’re getting closer and closer to completion.

The game has come quite far from its initial state. This is the first “progress” video I ever sent to Ethan. A lot of the game has reached a point of polish now. But I’ll certainly be reflecting on both past issues (and their sometimes hacked together solutions), and my current concerns and features happening more recently.

The Past – The Bullets

It’s hard at points to look at past code, and wonder “How did it come to this??”, but that’s the bullet script. You might argue it’s one of the most important scripts in the game, after all everything in this game works off of them. You shoot bullets, you’re dodging bullets, bullets are bouncing off the walls.

So it’s sad that they’re such a god damn mess.

So the major issue here (at least I would say) is their basic implementation was flawed from the start. This is one of the issues I mentioned where Ethan setup a system that I didn’t want to change until it was too late to properly change. The game is locked to a single perspective, and while it is 3D, the logic doesn’t really need to be 3D. Despite its perspective fooling you, really the game should all happen in 2D, from a logic and development standpoint. It would make things simple, consistent, and we wouldn’t have run into quite so many issues.

But here we are, approaching three years later, and the bullets scare me. So because the bullet is not 2D, and instead 3D and everything is handled in 3D, at the time I had simply continued the method that Ethan originally employed. I believe he probably followed a Youtube tutorial or otherwise for this, which if true would sum up the state of quality Youtube tutorials.

So the script has grown and changed since those days, like a nasty infection that just won’t leave you alone. Most of the changes came from a time of my attempts to fix one particularly nasty bug that took me months to figure out. This should’ve been the first sign that I was in danger, but man I am bad at reading signs.

At a base level, the bullet is spawned by another script based off whatever, and then it starts moving forward at its set speed. Right before it moves, it does a ton of shit. It basically fires a raycast the distance that it would move that update cycle. It then checks against like 30 different objects to be like “should I do something cool here?”, and if it doesn’t it just keeps moving. Even now I can think of easier ways I could’ve handled this. Like an interface. God why didn’t I just use an interface.

But no, no interfaces here, it is instead a series of if/else checks for each type of object. Worse? It’s comparing by tag, not even like a script type or anything. If any of my programming friends are reading this, I’m sorry.

So theres a long list of things this goes down. I check for the player tag, I check for the AI, I check for something called “BossTankFiveCannister” that I don’t think we even use anymore but I’m too scared to delete it.

Again to my dismay most of these do something very similar, destroy the bullet, destroy the other object. Sometimes instead of just destroying the other object, I call a script on that object so that it has a cool VFX. God why didn’t I just use an interface.

But it gets worse don’t worry. So our bug, that’s one of the reasons for this next set of mess. Essentially at very very slight angles if you shot between where two walls connected, the bullet would simply.. go between them. The colliders were perfectly touching, even overlapping sometimes, but that didn’t matter to the bullet. The bullet didn’t play by my rules.

So first I tried quite a few different checks. At the end of this big if/else chain, theres another else if that fires another cast, this time a SphereCast. Many checks for other things are done here as well to be fair, like checking for a larger radius to hit some things such as other bullets and the like. But I do many checks, checking for if we’re hitting two walls at the same time and other silly things.

However even the many things I did to try and fix it within the bullet didn’t work. So I would go on to write a huge script that basically took all small individual colliders and combined them into a mega collider. It would go from this: 

to this, during the game start:

Honestly this worked pretty well. It fixed a large percentage of the issues since the only time you had colliders connecting were at corners.

But fuck those corners.

I originally thought this was fixed when I did this, but it was later in coming months that we would discover the corners. You had the same issue essentially, where two corners connected, the bullet could sometimes bounce inside the wall. Even more redundancies were added to the bullet. It slowly became harder and harder to reproduce.

But it never truly left. It would still happen, even sometimes to playtesters they’d show me it had broken.

I left it for months, there were still so many things to do at that time, and it was very frustrating, and now everything was so ingrained in these bullets, that trying to change them would lead to a lot of instability. There would eventually come a time that I returned to the bug, and I added a few things that I’m fairly confident has actually fixed it. I’m not even sure what I added anymore, but I haven’t seen it in months. But it still lurks in the back of my mind, threatening to reappear.

But that’s the bullets. I’m sorry if you’re a developer and you’ve read this, I know they’re upsetting. They upset me too.

The Present – Polish, Polish, and More Polish

Let’s move onto the present shall we? I think this is how I will try to structure these devlogs, an excerpt about a past struggle that haunts me, and what’s been happening recently.

So what has been happening? A lot of polish, as the title indicates. We do still have some major ticket items, but they’re coming along nicely and not quite my domain. We’ve recently had a discussion about our level select, and we’re redoing the way it works. We’ve had some cool ideas that we think will be more fun, interactive, and give it a purpose. I however am not the art guy, so Ethan will be handling that. I’m sorry Ethan.

Additionally our levels are coming along at a decent rate. I was originally also designing and making all the levels myself (I made all of the desert biome levels), but now we have a proper level designer whose sole job is to do that! Courtney recently came on, and has just finished up the snow biome levels, which makes half the levels completed for the game. She’s also contributed various helpful ideas for improving some mechanics, which helped to introduce the idea of sleeping tanks which awake only when the player comes into view.

All her levels are reviewed by me for feedback, and as we move forward we’ll be trying to get playtests done on a biome basis so we’ll be able to get even more feedback going forward. Additionally I added some nice quality of life features, suggested by some friends (Thanks Alphelion, Nardandas, and Snoopdoge). Some extra camera shakes added when killing enemies, changes in sound effect timings and the like have been helpful to get the perfect vibe.

Game Details

Thanks for reading the first Battle Tracks devlog! I’m going to try to keep these going on a fairly consistent basis, either weekly or biweekly depending on how busy I am. If you want to follow the game’s progress you have several options!

Follow the Battle Tracks Twitter, I actually run it for the most part posting misc. things about development, levels, or otherwise. You can also join our discord, here I post updates, often times before the Twitter itself. Our dev team is all on Discord for communication with each other and anyone else.

We’re looking to setup our Steam page soon, and there’s the potential of a Kickstarter in the near future. Keep an eye here, on Twitter, etc. for more details on all of that.

Questions?

Have questions about the game and want answers? Message @BattleTracks on Twitter and I can either answer on Twitter or post about it here.

The Team

A quick shout out to various members of our team, and their socials!

• Cory (Me! I’m writing this), Lead Programmer – @The7ark
• Courtney, Level Designer – @artofmcgee
• Ethan, VFX Designer, Environment Artist – @Ethan__Chester
• Brian, Manager Stuff? – @Beamer_02