This is Part 7 of my Journey in making a Tower Defense game. And for the first time, I was hardworking enough to make links to all the previous posts.
And Part 4, Part 3, Part 2 and Part 1
At this stage, the game is getting quite technical. I am working on getting the final game size down, compressing my sounds, decreasing scene load times, and grinding down the technical issues – most of which are stuff that programmers would love to do to get their hands dirty, but well being an artist, this stuff totally bores me. But someone has to do it!
But let’s talk about the fun stuff first.
Drawing new Maps
As the game starts to draw to an end, I am finishing up on the map drawings. I have only about 5 more maps to draw before I can wrap up the background art.
A lot of the work remaining now leans more to the technical aspect more than the art.
I’ve also added more complex movement animations to my previous boss.
Draw Order
As the game grows, I started to get sorting problems – as more objects are introduced to the game, their distance to the camera has to be sorted properly. (e.g. Turrets have to be behind the enemies, enemies have to be behind the environment trees but above the map background)
Because I had so many objects, and each object can have its individual sorting layer (e.g. The enemy has a background sprite, then it has its health bar sprite, and a health bar background sprite), and turrets have its main sprite, its equipment (The hero has a hat that is on top of the main character sprite), other UI icons like a star, a disable icon, it got pretty messy. Then there are some enemies that can fly (planes), so they have to be ordered to the top most layer – above trees that would normally ‘cover’ the pathway and other ground enemies.
Because my game is 2D, I make use of the 3rd Axis to determine the ‘draw order’. The Z-axis determines whether an object is in front or behind objects in my 2D but 3D space.
Z = 0 represents the center of the worldspace.
Z = 1 represents something further from the camera (will be obscured by objects at Z = 0)
Z = -1 represents something closer to the camera (aka higher up on the draw order)
To allow my game to expand without having sorting layer issues, I documented all the objects in my game that had their z-axis values adjusted. So when I add a new object, I know exactly what its Z-value should be.
In Unity, there is even an ‘ORDER IN LAYER’ property, which sort of is like an override – no matter what your Z-coordinate is, an object with higher ORDER IN LAYER will automatically be drawn on top of something with lower Order In Layer. This can be changed in code too, so it allows me to do some bizarre things, like my oak tree special boss. Now here comes the exciting part:
SUPERBOSSES!!!
(Superbosses are officially called Epic Bosses in the game)
I was making a new boss and I kinda wish I took a real-time video of me drawing this superboss – I had a lot of fun drawing this boss and it is currently one of the largest and most complex enemy I’ve ever drawn for the game.
Like my other superbosses, this one has a lot of unique features and abilities. I don’t call regular bosses superbosses for a reason. When I call something a superboss, it usually means it can do something really cool, like my previous superboss who could do this:
This boss is part of the background at first. His eyes are hidden so hopefully the player thinks “hey, that’s just part of the environment”, but when he comes alive (and hopefully the player will be surprised by that), he spawns additional animated sprites. I had to be careful of the sorting. (Think of it like a human and his body parts – the eyes have to be rendered on top of the face, and branches have to be rendered BEHIND the body) – and to achieve the correct sorting order, I actually set in code the body part’s “Order in Layer” property so that a sprite within a sprite knows how to order itself relative to the main object. Hopefully that didn’t sound too confusing.
It lags badly in Photoshop because the map texture is 3200 x 2400 and I have a lot of tree groups.
Anyway, I wanted to make an animation such that tree branches grow out of the superboss.
I used Onion Skinning to animate the growing branch. I first drew the full branch then ‘erased’ parts of it for the different frames. (You can see the different transparency layers above. Each transparency layer represents one frame of the animation).
This was a rather simple animation with only 5 frames. I know some people may think I should make more frames to make the animation smoother (and I really want to!), but having a large spritesheet for an almost insignificant part of a minor boss wouldn’t be worth it (my game is over the 50MB limit and spritesheets use up A LOT of space). So when making my animations, I have to take game size into consideration. (More about game size below)
Also, I accidentally imported the wrong size of the Oak Tree into the game, causing him to be doubled his actual size, which makes him look even COOLER:
I was considering to make the bigger version his actual size. I mean, just look at the size of the other trees and creeps compared to that monster! But well, sadly I can’t do that. Apart from the glaring issues like having a superthick outline and the level of detail being somewhat lacking for something that huge, it’s simply overkill. The final boss isn’t even that big, and this isn’t the final boss. He is technically the second last superboss in the sequence of superboss appearances in the game.
But this tree doesn’t need to be big to be special.
The Oak Tree Boss is the first enemy in my game to actually have ‘body parts’. Its eyes are animated and saved as a separate spritesheet from the body, both to save memory and space because the body does not move. I used some tricks to actually make this happen. (When he spawns, you can only attack his eyes).
This Oak Tree Boss was not part of the original game scope, but I thought it would be cool to have a boss that is different from other bosses (having multiple body parts), and this is also the first ‘plant’ boss – it’s not creep or animal! It is also the first enemy that cannot move. But it can still threaten you with its summons.
After spending half a day drawing, it was time for the excitement (and frustration) of coding the actual boss. Surprisingly, it went pretty smooth. There were still a few bugs with the initial run and they were all caused by oversight and were easily identified and fixed:
Bugs:
- The boss’ arms did not appear at first – because I forgot to set their references in the inspector
- The boss’ eyes were rotated (see the screenshot) because the boss is trying to rotate to its next waypoint
- Lastly, every creep that spawned was a boss, because this wave is a ‘boss wave’. This was unintended.
- Boss’s tree branches were blocked by turrets (I only set the ordering for the main body, but forgot about its body parts, so its body parts were still mapped to the background and covered by turrets)
It took awhile to actually test out the boss, and to make sure that everything was working. Once that was done, I added some special effects and automated camera movement / zooming that trigger when the boss spawns.
And finally, SUCCESS!
The camera effects start once you call the last wave. And there is a brief delay before the boss actually spawns (when the green Health bar above his eyes appears, that’s when he actually spawns).
While this whole idea of an oak tree boss was really cool, I should really stop sidetracking since every day I spend working on stuff like that is a day later the game will be ready to play and publish. It’s pretty hard, sometimes I just get so passionate or fixated about certain things and I can’t stop myself! But there is only so much I can do in a certain time-frame and my ‘holiday’ is not infinite in duration, so sadly, I do have to get strict with myself in what I choose to develop.
I have thrown away a few cool ideas and maps, trying to combine them or just eliminate them altogether from my game scope, partly due to the pressure of trying to compact the final game size to under 50MB (more on that later). Weeks ago, when the game was in its early stages, one person implied to me that I was ‘JUST’ making a game that looks like every other TD out there. I was a little offended by the remark. Many people seem to think a game has to be different or special or else there’s no point making it. But I feel that’s not true. Then again, it kind of depends on what you mean by ‘different’ – gameplay wise? Graphics wise? If you just want to exactly replicate/make a clone of another game, then that does sound pretty pointless. But some games try too much to be different and end up with a very bad design that can put players off rather than attract players – I guess it depends on what is ‘different’. Angry Birds was a copy of Crush the Castle. But it received more attention and became a sensation because it was similar yet different. At its core, they are the same, but their presentation (cartoony graphics) and execution was what made them different. Games are pretty magical. You never know if a game design will succeed – you can’t “predict” accurately whether your game idea attracts or repels players – you’d need a lot of Beta testers and a very wide target audience is hard to please. You can’t please everyone.
Ops, sorry I ranted too long about my thoughts. It’s just that while making this game or any of my games in general, I tend to think a lot about this kind of things. There’s a lot of things involved in making a game behind the scenes, beyond the graphics, beyond the code. It’s the stuff that people don’t always see. People think that making a game is all about- oh crap, am I ranting again? Anyway, back to development.
Beware! BigFoot – the next boss? I’m not going to make anything complex anymore though. Takes too much time.
Dancing Creeps
Okay well, I added a new status effect called ‘Stun’. Status effects are negative debuffs you can inflict on creeps. So far, 3 status effects exist in the game. They are ‘Slow’, ‘Burn’ and the newly added ‘stun’. I drew a simple stun circle that appears when you stun a creep.
Then I decided to add a behaviour to the stunned creep. But what animation should I give it?
A) Just freeze the creep at its current animation frame so it does not move
OR
B) Have the creep continue playing its current animation, but loop it rotating 360 degrees so it looks like it is dazed
For some weird reason, I went with Option (B), since I was curious how that would look like. So while experimenting, I decided to make the monsters turn while they are stunned. And the result was pretty hilarious.
The creeps look like they are dancing around on the spot.
The crazy thing is I actually want to call my new status effect ‘hypnotize’ instead of ‘stun’. Not only is stun pretty overused in games, but call me weird, I actually like this animation. I’m not sure though. Hypnotizing creeps sounds way more interesting, but it doesn’t fit well in my game since the turrets are mechanical, so it doesn’t make sense for a turret to be able to ‘hypnotize’ the creep. So for now, I’m sticking with stun.
In the meantime, I had a mock description for the stun – “Hypnotize creeps at a chance, causing them to stop attacking and break out in a dance.” It’s not meant to be a serious description but something more light-hearted. Dancing creeps are better off as an easter egg. (The rotating stun circle around the creep does make it look like the creep is conducting some sort of dance ritual…)
The Ultimate Level?
I spent about a full day on balancing ‘advanced’ skills, which I added in the previous week. I also had to balance many of the new special Challenge maps I added.
But most of all, I got to finally test and win against Map 20. It was previously too tough, but after the changes, I managed to win on the first try. It was almost too easy – the final boss barely made it halfway through.
Also, notice that I added a new ‘Tip’ dialogue at the bottom. The tip generated will change if you lose a battle. If you lost on a wave of Knights, it displays a tip on how to defeat Knights – it’s pretty dynamic and I realized I needed this because the game is pretty challenging. I replayed my earlier levels from scratch and while doing so, ignored strategy which resulted in me losing twice at Level 4 !!!
I was trying to brute force it by just spamming damage turrets but it did not work because you can’t just spam one tower and hope to win in early-game. I hope this doesn’t make the game too tough. I noticed (sadly) that many people prefer a casual, easy game, one that offers little challenge or just allows you to grind and win levels. Some TDs I played make you replay levels again and again to get EXP and get stronger to win a level. It’s brainless and requires no strategy – all you need is time and endurance to repeat the same level over and over, get your character to Level 100 and suddenly everything is easy.
In my game, you can’t grind to a high level and breeze through levels. So you got to think of how to beat a level, not just grind your way to the top and take the strategy out of it.
Because of that concept, I had to mark levels with a ‘Recommended Level’ tag so people at least know what level they should be before attempting it. It was very accurate at the beginning, but as you progress, there are more factors which makes recommended levels inaccurate – a player can get bonus SP if they get highscores, their skill setups change, and completing Challenges will also increase your damage without increasing your level. 
These variables I guess are the reasons why games don’t generally put a ‘recommended level’.
It also requires a lot of manual testing on my part to find the appropriate level needed to attempt the map.
Deep Profiling
I’ve also explored deep profiling, a tool which I can use to monitor the game’s frame rate and CPU usage and draw calls. I haven’t exactly used this much since the game seems to run pretty smoothly so far, save for a few lag spikes.
Game Size
Since my primary intention is to publish this game to web portals, I intend to build my game on the Web Player platform. I *may* publish it to mobile, but for the moment it is not a priority. Even on the Web Player, there are a few technical issues that I have to resolve – one of which is game size.
Game Size refers to the final size of your playable game – the bigger it is, the longer it takes to load it and you potentially lose players. Web portals also do not accept games that are too big. My game currently sits at 60-70MB (with music and 1600×1200 target resolution). I can probably squeeze it to under 50MB with a target resolution of 800 x 600.
But before talking about Game Size, I actually flashed back to when I was still in Polytechnic, back in 2012.
I remember back in school, our final year project was to make a game. For the most part, I found it pretty fun. I looked forward to it and was really excited. It was the first time we were actually making a game in a team. But we were not taught the importance of keeping the size of a game low. Heck, we weren’t taught a lot of things – it was only when I started developing my own games did I realize there were a lot of things school did not teach us. I ended up having to learn a lot of things by myself, a lot of times the hard way.
I think our final year project submission was likely over 100MB, and for comparison, sites like Kongregate only allow uploads of up to 50MB. Our final project game was made by 5 people over a span of 16 weeks. But the game wasn’t 100MB because it was a ‘big’ game.
To be honest, (and I’m really not trying to brag), but I actually think the scale of this tower defense game is currently about the scale of our final project – what I’m trying to say is that the 100MB wasn’t the result of the game we made being more complex or actually having more content, it’s due to us not being taught that bigger = bad. I think ironically some of us even felt that a bigger game = better, because it means more potential marks because it has more stuff in it?
I guess I was just so disappointed that a lot of things I learned in school did not really apply to the industry or were irrelevant to actual game development. Though it is possible that I’m just not skilled enough to see the connections. Hopefully, and this is if I decide to pursue game development in University, things will be different.
Game Size (Technical)
From here on, my programmer will talk about the technical side of game development. My programmer is pretty weak, so forgive him.
—*Puts on programmer’s hat*—
When I finally got to build(compile) my game to web player after multiple attempts at reducing the file size, experimentation, researching, I was shocked to learn a few things.
Removing four music tracks from my game shaved off roughly 20MB off my file size, dropping it from 57MB to 36MB.
There were actually two things to look at when looking at game size – uncompressed size and compressed size. Unity gives me a list of assets and sorts them by their uncompressed size when I build my game.
The problem I later realized is that this does not accurately reflect the size of the final game. For example, sounds are listed as 0.0% in the Log above. But this sorts by uncompressed assets. It was very fishy because my music tracks were pretty big. In the end I removed music to compare the size difference and going from 50MB to 30MB showed that sounds was definitely bigger than “0.0%” of my game.
And plugging in the size data of my assets revealed another shocking piece of information.
Going from left to right in the bar chart:
- Background – contains about 30+ 800 by 600px map backgrounds and environment props
- Bug – My creep spritesheets. Bug was the ‘codename’ for creeps from an earlier build
- InfoPanel – Tutorial panels, but mostly story panels, sort of like comics in a sense that they tell a story in picture form
- Bullets – Self-explanatory. They also contain AoE effects.
- Turrets – Spritesheets of all 12 turrets in my game, buildings, as well as the Hero character’s idle/attack animation sprites
- Misc – Misc mostly contains UI elements – buttons, skill icons. The tutorials take up a lot of space. Thankfully there aren’t a lot of them.
After manually compressing my backgrounds to 25% of the original sizes, they were now so small they were even SMALLER than the turret graphics! And I was amazed that 11 turrets actually consumed more space than 20+ Creeps, but well, the turrets are drawn in pretty high-res and they do have a lot more detail and their animations more complex leading to bigger spritesheet sizes.
As for bullets taking up so much space, I was puzzled at first, but realized the three biggest bullet sprites are larger than most creeps, because they are AoE effects, not bullets, but I put them into bullets because they function similarly to bullets. I might trim the AoE effect sprites but there are other stuff to trim first.
And shockingly, about 1.5MB of my Miscellaneous assets is from my oversized placeholder HD game logo, which is to be removed from the final build just before publishing.
Before I decided to compress my backgrounds, I actually heard of something called Asset Bundling from my (expert programmer) friend.
Asset Bundles
As time passes, I have to prepare for when the game gets published. There were 3 problems:
- Game Size
- Scene Loading Time
- Build Settings
The uncompressed game size sits at 300MB. I used the Editor Log to determine what was causing the size and thankfully managed to find the cause.
The map art assets were a huge contributing factor. I decided to try and learn something called the Asset Bundle to actually load my graphics during runtime, something I have never done before, and it is pretty advanced to me, in the sense that Unity categorized it as ‘Advanced Development’:
Unity probably labelled it ‘advanced’ because it is used mostly by bigger games that get more complex and have larger output sizes.
What the Asset Bundle does is instead of putting the art in the game itself, I load the map graphic from a server via code, only when it is needed.
This keeps the game’s loading time to a minimum – it only loads what is needed. So far in my asset bundle, I have just my backgrounds because they are the largest textures I use.
Asset Bundles (Technical)
(Warning: I found this to be a bit technical. Skip this section if you don’t want to read about the technical aspect of developing games)
After an entire night, sadly my efforts of trying asset bundling were in vain. The amazing thing is I actually got asset bundle to work partially – somewhat, and it was a pretty big achievement for me to actually understand something I considered to be pretty technical – it’s something programmers would probably love doing, but I ain’t got much love for programming so it was literal torture every step of the way.
The thing that stopped it from working was that I needed an actual web hosting site and a domain containing a crossdomain.xml file that allows other domains to retrieve files from it because of a security feature that Unity, (as well as Silverlight and Flash) had. Well, sadly I realized at this point that this was getting way too complex. One problem was leading to another and though I managed to solve the ones I faced so far, this one was beyond me.
I did actually attempt to use a few web hosting sites. The first one I used was 000webhosting. But it had a limit of 5MB per file, which is around the size of 3 of my map graphics (compressed). This defeats the point of using asset bundles if I cannot upload large files. I could use the hack solution of uploading 3 maps per bundle, but then I would need 10 bundles if my game has 30 maps. Totally uncool.
Then there was Filezilla. I spent a lot of time reading up on it and learning about something called FTP (File Transfer Protocol) but it was for naught once again because Unity requires a browser URL to load the asset from the server. Filezilla only gives you the FTP url, which is not the browser URL because Filezilla does not support HTML urls. I was really sad.
I actually tried a few more – Lokad, Load.To, DataFileHost. They were decent but each one lacked what the other had. But my most interesting encounter was with JumboFiles. It boasted 500GB of free space,and more importantly, FTP support which was what I was looking for.
I registed for an account, and guess what? Yep, the servers were down. I could create empty folders, but I could not upload anything. They boasted about having 70,000 users, but to me hat’s just biting off more than you can chew. Not to mention, I had the ‘luck’ of witnessing a DDOS attack happening on 000webhosting‘s server, the first web hosting service I used earlier.
After today’s experience, I really learned to appreciate Dropbox a lot more. Paying $99 for reliability, automated project syncing and limitless file size and customization is reasonable. It’s just too bad it lacks the support I need or I would definitely use it to host my game’s assets. I may give up using Asset Bundles since I am building my game to WebPlayer, which compresses all my textures – my final game size sits at 57MB now, which is slightly above the 50MB limit and is expected to grow, thus the need for Asset Bundles, which would push my game below the 50MB size limit and to make for reasonable download times.
I was extremely frustrated at the end, not because of the quality of the sites I found, but because I didn’t understand a lot of things about crossdomain, xmls and the restrictions of web player. Fortunately I had a lot of brainstorms going on on how to reduce my build size without the need of Asset Bundling.
After compressing my maps once in PSD and prior to Unity’s auto compression, I decided to make my entire map a spritesheet, which is something I didn’t do yet because it was not a high priority.
A hard limit of 4096 x 4096 texture size means I can squeeze in 6 x 7 map backgrounds. That equals to 42 maps!
It turns out it DID actually save some space, but it amounted to less than 1MB. It was too insignificant. I was hoping for greater size drops for the effort it took (not much actually). Maybe I could try Texture Atlases.
I do not understand much about Texture Atlases at this point. People say they are similar to spritesheets, but apparently not exactly the same. I can’t seem to get an answer on how much space it is estimated to save – it’s probably too dependent on the project.
—*Takes off programmer’s hat and lies on the floor in exhaustion*—
Behind the ‘Behind the Scenes’
I actually try to keep each post as short as possible – lesser words if possible because I don’t want to bore people, but sometimes I can’t help it. I kind of realized I love writing (or typing in this case). Just simply talking about the process and the things I love to do makes me happy because I really love drawing and animating and making a game is just a very magical process for me. As for programming, as long as it does not involve technical stuff, I truly enjoy it. Coding creeps and bringing them to life in my game is like sugar rush, and when I work on Superbosses? That’s like feeding me heroin, not that I take drugs. Why would I when I already get super excited from making a game? Making this game has given me more fun than most games I’ve played.
That’s ALL!
To be able to write about ‘Behind the Scenes/The Making Of’ this game is really enjoyable. At this stage, this game is a summary of 8 weeks of hardcore drawing, balancing, sounds, coding, animations and miscellaneous technical stuff.
So far, I am happy with the art and I’m content with the features. I guess my favourite thing in this game is the upgrade system, the maps and the bosses. Especially the superbosses. The only thing I’m worried about is currently the game’s design and balance – I’m not sure if players will find the difficulty okay and I am also unsure how fun people will find this game. As the game progresses, I personally found it to get less exciting because I no longer unlock new stuff. Well, I guess I’ll have to see how this game turns out.
God I’m tired. But HAPPY!
YYZ 