Growing up playing on older video game systems, there are certain games that stick out in your head because the game play itself was simple and addictive. One of those games was named Artillery for the old Apple ][e. It was a simple game in which you try to guess the correct angle and power of your cannon to hit your opponent. This is the inspiration for our next game, Castle Clans! We want to try and keep the game pretty simple but at the same time put our own spin on it as well. Because of my fascination with 3D graphics and the mathematics that are involved, I’ve always wanted to delve into that side of game development. Some years back I had created a simple transform and rotation class in C++ for basic 3D objects by utilizing matrices. The code didn’t take visual perspective into account, so what you saw on the screen was only orthogonal in nature but it stoked my interest in learning more. I haven’t had a chance to really play with that side of things since then but I believe this game will be a good opportunity to get back into that. We’ll be using Blender for all the 3D models that are created along with Gimp to help with the textures our models will use. I had used Blender off and on in the past just because I was curious about it, it’s nice I can put some of what I learned to use in this game. Importing models from Blender is as easy as copying the .blend file over into Unity. There are some things you still need to do with the model before creating a prefab out of it, especially if you have animations attached to the model. You also have to be a little careful in that Blender considers “up” as the Z-axis while Unity considers “up” as the Y-axis. There is a trick I found that helps with this “up” axis issue. Unity implements a lot of the groundwork for physics and detecting collisions to your meshes just like it does when you create a 2D based game. That will let us concentrate more on the game content and less on the boilerplate code.
Speaking of game content…we want to try and embody the simplicity of the original game but give it a bit of our own twist. You’ll be protecting your own castle with a couple of different types of weaponry that can be purchased. As you destroy enemy castles you can take their gold and use it to upgrade your stuff or even buy bigger castles. We don’t want to make the management part of the game too detailed and cumbersome as we think it’ll take away from the core of keeping the game simple, instead, we want to use it to give the player a longer game play experience and more challenges. I’ve already created some of the initial 3D models that we’ll be using and finally got a chance to play with Inverse Kinematics in Blender to create some of the animations we’ll use in our game.
This is a sort of “first go” at creating an animated ballista. I’ll use the multiple animation sequences I have to make it look like it’s loading up a boulder and shooting it out…no boulder just yet on here, it’s just the animation,
I plan on adding some other things to this ballista, but it gives me a basic animated model to work with in the game so I can flesh out some other parts. The challenge will be to keep the complexity of the models down to a minimum while still making them look decent so the game can be played on a wide range of mobile devices. The terrain for each map area (I call them domains) are on the scale of 2000 meters x 2000 meters…there are quite a few vertexes/triangles that make up the landscape alone. Your castle will use a “magic portal” to move from one land to another (how else are you going to attack enemy castles in other parts of the world?) Magic solves everything, right? I see it as sorta the duct tape of the fantasy world.
Optimizing each mesh’s material (the actual texture used on the 3D object) was also something I had to take into consideration. I had read about it before in the past but haven’t dealt with it yet until now. Essentially, the more separate textures per model, the lower the performance of your game. I saw it explained as each texture you have for the same model is like the device having to take a pause to “dip” it’s paint brush into another color so that it can paint that part of the 3D model. The idea is to have one texture for your whole model and specify areas on that texture that the certain parts of your model use for it’s particular texture. For instance, the castle has multiple rock/stone textures but they all reside on the same texture file. The bricks will just grab from one part of that texture while the base of the castle grabs from a different part of it. Here is an example of what the texture for one of the castles look like. So instead of there being three separate textures, I combined them all into just one.
Needless to say, I was able to significantly improve performance once I figured out how to do it. There is still a TON of stuff to do on this game, it’s going to be a a great adventure!