It is currently Day 6 of my journey in making a tower defense game. See Part 1 here.
A LOT of progress was made since Part 1, and I’m getting super excited every day just seeing the amount of improvements and new graphics/features with each passing day.
Here are some of the things I did over the past 4 days:
Setting up the Tower’s attack range and range visual graphic
The first thing I wanted to do was draw a circle on the screen that reflects the tower’s attack range. The easiest solution was to make a circle graphic and scale it based on its range in code.
Both the enemy and the tower has a circle collision box each, and when the enemy’s collider intersects with the tower’s, it triggers the tower to add it to its ‘list of hittable enemies’ and starts to attack it.
There was one problem though in the screenshot above, and it’s that the creep’s collision circle was too large. I can’t make it smaller because I intend to make the enemy ‘clickable’ and when I made the collider smaller, I ran the game and had trouble trying to select the enemy with my mouse.
The solution I had was to have two colliders. One for the enemy object, and one for the sprite. The inner collider is difficult to see in the bottom screenshot, but there’s actually two circle colliders over the enemy.
The bigger collider is for clicking, and the smaller, true collider is the enemy’s real detection box.
This way, the collider is flexible in that a bigger enemy can have a larger ‘hitbox’ while small enemies won’t be difficult for the player to click and the ‘click area’ stays consistent across all enemies.
Next, I moved on to something more fun – drawing the turrets!!!!
When it comes to things I love, towers are one of the the things I seem to really enjoy drawing. there was but a problem I forgot about.
I didn’t use the same resolution for the turrets. Above, you can see the inconsistencies in the turret’s size and outline thickness and visual quality. Although I use the same grid while drawing, I still draw some turrets larger when I add details like the muzzle, which looks ‘small’, but eats up grid space, compared to turrets which have no muzzle, giving more area for me to draw their ‘body’.
Example of case in point:
The turret on the left looks smaller compared to the right because its muzzle eats up grid space. I can’t really call it an optical illusion since it was error on my part. How I should have done it was to draw the muzzle outside of the grid area and adjust its pivot in Unity.
I had to spend quite some time fine-tuning the size, going to each turret and doing a scale comparison.
You can see above how some turrets’ outlines look thinner compared to those around it.
Because I didn’t do a size-check before importing, I decided to import every turret into the scene in Unity and manually play with their scale till they look the right size, then I went back to Photoshop to resize them to their true proper size at the original resolution. After resizing, I re-imported them into Unity. It was double work, but the end result was a hard lesson learnt and a game worth looking at:
Animating my Turrets and Graphic Tiers
When the turret fires, it has to play an animation.
Each turret has a unique animation and I also wanted my turrets to change its appearance when it is upgraded. Each of my turrets has 5 tiers, which means they have 5 different graphics and 5 animations respectively.
Here are some of the turret spritesheets before exporting. (The green background on the right was to check how the turret looks like against a standard grass map to check if it blends/color contrast, etc.)
This was PLENTY of work and took me 2 days. It was also a tedious chore to not only draw, but integrate the animation in Unity because it involves a lot of clicking and dragging files/assets here and there, setting keyframes, animation transitions and all. It was really, really boring to integrate the animations after having all the fun drawing the sprites.
There’s just so many things about each turret to do that this blog post makes it look way easier than it actually is. Oh god, and I still have to worry about sound effects?!
It didn’t help that Photoshop lagged a lot when drawing because the turrets were drawn at a huge size. It was extremely tedious to pixel perfect each frame when moving large turret asset groups in Photoshop.
It was important to draw the turrets in high-res for HD quality. I also try to lean more to using vector graphics. The real fact is that the turrets in-game are not nearly as big as you see above. Take a look:
My turrets are drawn in 290 x 290 per grid (original size), and I import them into Unity at a graphic that is 2x as large as they appear in game – I set my game to render at a size ratio of 1:2 (80 x 80 imported asset size), the advantage being that I can scale all my graphics up when needed and not lose quality or pixelate. It also helps if the game is run on higher resolutions. On the final game screen, which is 800 by 600px resolution, the turrets each occupy a gridspace of 40 x 40 px.
From 84100 pixels to 1600 pixels. That’s a 5256.25% size reduction!
I wish it meant that the quality would be 52.65x higher, but it actually backfired a little. I felt really sad that my turrets lost so much detail at the small size (I really didn’t expect it would look so small), but I am very happy with the way they look regardless.
The next thing I did was bullet sprites. I coded each of the upgrade tiers to be able to have a unique bullet assigned to it, so as a turret upgrades, not only does it change in appearance, its assigned bullet also changes!
Adding varying Turret Mechanics
I also coded a different way for some turrets to attack. Some turrets shoot at enemies, while others do not shoot. Some always face the enemy, while others are fixated to a spot. There’s even a tower that plays a ‘pulse’ animation which surrounds the tower with a special effect and attacks every enemy in range. I think it looks pretty cool.
It took a few hours to code this feature. I started when the sky was dark and by the time I was done, daylight had broken. But I think this adds some strategic depth to the game and gives towers a little more flavor and variety. Time just really flies when I am developing this game.
Below is one of the special FX spritesheet for the flame turret’s attack animation, which spews lava to the land below it. It’s a simple animation and I added a fading effect using Unity’s <Animator> component, but it works really well in-game!
I also added ‘status effects’ which you can inflict on the enemy, such as burning and slowing enemies. Again, these are things essential in a Tower Defense game.
When an enemy is inflicted with a status, a ring appears around it to denote its status type and the description panel updates. The UI above isn’t finalized in presenting the information, in case you were wondering about that. The next thing I worked on was something I had been dying to do.
THE MAP + UI!!!
I waited a long long long time to do this, and I was so impatient to start on it because I had been staring at a boring placeholder map screen for the 4 days! I had to also tolerate the ugly placeholder UI for 4 days.
I will not tolerate anymore staring at placeholder graphics! So I went to Photoshop and was so excited that it was finally time to draw the background map and UI for the game.
Icons for the UI
After getting the UI half done, the first thing I did for the map was design the pathway – the route the enemies will take to get from one point to another. I had a grid overlay on to define my path.
I did the map programming beforehand so that I didn’t have to worry about it when I start drawing the map – the map works on a simple grid system where each grid represents a Node that is either buildable or not buildable. I can also define each tile to have unique properties based on the number I assign to it.
It looks easy but I actually spent a lot of time thinking of the best way to code it. The tutorial I read creates a GameObject for every tile and attaches a BuildScript to each game object, which is not very optimal because if you have a large map, you’d need 1 GameObject per grid, and my map has easily over 100 grids and 100 Game Objects is more than double of what my scene currently has! I don’t even have that many enemy objects at once.
Instead, I put the script in a single Map object and created ‘Nodes’ to represent each grid, where each Node can be extended to store additional information if I need it to.
Anyway, back to drawing. The completed map looks really good in the game. I drew it at a super large resolution so quality would not become an issue. Here’s how the game changed over the course of the past 5 days:
As you can see, drawing the map graphic easily made my game presentable and combined with the UI, is the single biggest visual change in the game over the past 5 days.
Enemy scaling and Color coding
Also, learning from the mistakes about my turrets’ initial inconsistent sizes, I drew my enemies smarter.
I have a giant ‘Enemies.psd’ file which contains every single enemy which I imported after I draw. It acts as my size-checker. Before exporting the final graphic to Unity, I do a final size-check, by pasting all my enemies onto a map template.
This way, I can easily see an overview of how my enemies look and scale in comparison with one another. Is this enemy too big? Is that enemy too small? If I want an enemy to look large, what should I export its resolution at?
Those above questions need not be questions any longer! I can now see every enemy sprite here! This was something I should have done for my turrets. Thankfully, I didn’t repeat the same mistake with turrets on my enemies.
Here are some of the currently implemented enemies:
I decided not to be so detailed in my enemy drawings since they are going to be compressed into a tiny image in the game anyway, but I still couldn’t resist adding shading and other tiny details onto the enemies 😦
I also began color-coding my enemies to not have similar color tones. I spent a lot of time analyzing other TD games and games in general. I probably have never been this analytical in any of my previous games, but a good game doesn’t have to just look visually appealing and coded well, but also work well in a design perspective. UI design is one of the key elements of a game easily overlooked or ignored. They can confuse a player, or be intuitive to make him adapt to and learn the game mechanics quickly.
As an artist, your job is not just to make things look cool, but also make art that fit well in the game. As I am designing the UI and thinking about how to display information to the player, I know that the enemies have to be designed to be easily identifiable in my upcoming ‘wave summary’ UI and the best way to do so is by color of the wave.
I’ve played a couple of TDs which either dedicate lots of space to enemy wave information, or used vague icons to represent abilities that I didn’t understand. I never noticed how awkward the design was.
Some games clutter the UI with complex shapes, information and graphics which are unecessary, so I want to improve and have an enemy easily distinguishable by color instead of words, which really helps in presenting the game to a casual audience.
And here comes the part I hate the most. I’m not really a game designer at heart and I don’t like the complexity of game balancing. Oh and by game design, I mean designing the game mechanic and balancing.
Many people confuse game design with game art. Design has nothing to do with art and can get very technical. A good game designer has to be able to point what makes a game bad or good and analyze why. Intuitiveness, balancing, level design, the reward system and how the game flows are all part of game design. Unlike the work of the game artist, these are usually things you don’t see, but they work behind the scenes and can be what make or break a game.
As for balancing, sure, I could tweak values randomly until I find one that looks like it works, but it’s a short term solution. Since this game may have a ‘survival’ mode for near infinite levels, there has to be predictable formulas to know what happens when the player does go to a high level and to keep things in check.
Balancing can also be fun sometimes – I often tweak some base input values like ‘base tower damage at level 1’ and watch how my table automatically updates the projected tower damage for the rest of the levels so I can see how it affects early-game and end-game results.
What worries me is how deep the hole of game balancing can dive. Here is a screenshot of the balancing I had to do for my other game.
Thankfully, this tower defense may not need survival to be complete, so I just want to focus on the basic balancing for a standard range of levels.
The most important thing in a game is for it to be fun. A game that scales difficulty higher than you can manage or offers no challenge at all isn’t going to be fun. Just like programming and art, design is really essential to a game. A lack of any one of these 3 components and the game loses its potential to be great.
AND THATS ALL!
…for now. I hope you had fun reading (or skipping the text and just looking at pictures). I honestly had so much fun in the past 6 days creating this game that I cannot wait to see what I will have one week from now. It’s a lot of fun when you see your work being reflected in the game and it is very rewarding. Even though I get very happy when I add new art to the game, programming did have its fair share by giving me that sense of accomplishment when a hard feature is completed. I find myself jumping out of my sofa out of sheer excitement sometimes.
I guess when we are trying to do something challenging that you’ve never done before, it gives it all the more a greater sense of accomplishment.