Now that ABMV is out on the App Store, I’m starting a series on the development process behind making it. In this first part, I won’t detail too many technical things, but more the reasoning behind deciding to do such a project, and how different the end product ended up compared to what was originally scoped.
It’s all Unity’s fault!
Not in a bad way, of course. Before I started work on ABMV, and even before the game’s existence, I was working on my other projects. I have been tinkering away with Unity and iOS for the better part of 2.5 years, but still yet to release anything (let alone “finish” a product). Why I never finished one will be left for post someday in the future, but in a nutshell I scoped my games too big. Too big for one person to handle on his own in a part-time capacity. (Again, I’ll leave the details for all of that for another post.)
So, while working on what I had thought of as the lowest spec game I could design and develop (this particular game is largely complete actually, I will definitely be talking about it soon), Unity releases the Angry Bots (AB) demo in an update to their SDK. I downloaded it, played it and studied it hard for a day or so. Although the gameplay was fairly simple, I was impressed by the graphical fidelity the devs were able to achieve. So I thought, “I wonder if I could hack this up and turn it into a proper game?”. And that’s how ABMV started.
But why shelve what I was already working on, when it was so close to completion?
My decision to move focus to ABMV over my current project was because I was stuck on one element – enemy AI. I noticed that ABMV has enemy AI in it, and does it quite well (including path following). So I thought that at the very least, working more with ABMV would give me a better insight into enemy AI scripting and when I do finish it I can return to my other project and add in the enemy AI knowledge I learned. This would also come in handy later on, for many other games that will require AI scripting.
Another reason was the visuals. I wanted to learn how AB looked so nice in Unity, and if it was possible for me to create a game looking as good. It is possible, but I’m not sure I will ever have enough time to dedicate to the graphics to achieve the same result. I believe I could get close though. One major thing I did learn about it was how to tile textures without seems (really quite simple and makes perfect sense when you see it). This was something that somehow slipped by in my own 3D training, so it was good to at least pick this up.
How can I make it my own?
So I needed to figure out how I would change AB into my own game. The first thing I thought of was to have a Metroid-like door locking system (where you shoot the doors) instead of the key/control panel lock found in AB. This would then allow me to create a Metroid like level system, where players can backtrack to gain upgrades and such. The next thing was having a controllable camera. I figured that if I could get the framework for these two systems in place, I would be able to start work on the game.
As luck would have it, creating the rotating camera was very easy. I achieved it by parenting the main camera to an empty object that always followed the player’s position and rotation. When you rotate the camera, you’re actually rotating the empty object. The object is set to always lerp (or was it slerp?) back to the players rotation along the x-axis, so when you released your finger it would smoothly rotate back to normal height. About the only issue with the rotating camera was that it would sometimes be easy to trigger it while you’re just being too aggressive with the move/attack pads (so you’d control the camera while also controlling one of the others). But I figured that this was an issue more with the platform (iPhone/iPad) and how people use it than something I could easily fix, so I didn’t worry too much about it.
The door shooting was pretty easy too, but the locking mechanism with upgrades was a little trickier. I ended up creating a whole system of lock levels and made the doors respond to only their lock level or above. I could set any door to any lock level, and also set any door to either permanently re-lock, one-time lock, or never re-lock (so you can just walk through it after one initial unlock). But in the final game, I ended up not using the one-time locks, and only made the base level red doors never re-lock, while all others re-lock.
Building from a framework
So with the basic concepts realised and working in the base game, I embarked on designing my AB inspired game. My idea was to have all new models for the player, weapons (one for each upgrade), enemies and possibly the environment. But with the environment, I decided to just use AB textures and assets for now while I do the others first. I figured that the time to design and create my own assets would be fairly easy if most of the programming was already done. I was wrong.
You see, although I’m a competent 3D modeller and animator, I’m a terrible texture artist. So creating these assets weren’t as simple as it seems. But even worse still, the more I tried to create something new, the more I saw that it didn’t have the nice professional look and feel of AB. I probably could create my own assets with a pretty close quality to AB, but it would take far too long (I need to focus on one aspect at a time when game developing, so either programming or art, not both).
So I instead did pallet swaps of everything. Weapons would just change colour, along with the laser sight; enemies would have variations that are basically just pallet swaps and new stats (more HP, attack damage, speed etc). I figured if I can at least visually convey changes (armour and weapon colour changes and firing rate for player, enemy pallet swaps etc), that should be enough.
Another thing I wanted to do was have the weapons selectable (and maybe even have environment changing weapons like an ice shot of some kind). But I liked the minimalist HUD approach of AB too much, and decided it was just simpler and easier to just have the weapons increment sequentially and have them unchangeable (but higher powered weapons will always work on lower powered doors/enemies etc).
About the only other thing I should probably mention is the work I needed to do to the health pack. I changed the way it behaves a little, so now has green to red fade for health (figured this made more sense than yellow/orange to red) and regenerates much faster than in AB. But to be fair, ABMV has a completely different health ratio than AB, so this part of it should feel quite different.
Stay tuned for part 2.