Making a Tower Defense Part 6

This is Part 6 of my ongoing journey in the making of this TD game. It is currently Week 6 since the start of this game’s development on 21 Nov.

The game is actually ready to play…sort of. I got balancing done (and this is the most tedious part) for the first 20 maps on the Normal difficulty and partially Hard Difficulty. For the record, I intend for this game to have 25-30 Campaign maps and 15-20 Challenge maps. I have yet to balance the Nightmare difficulty. Currently, it is impossible to attempt it, but with a few more features in place perhaps it will be possible.

But let’s start with what has been done for the past week. I’ll start with something really exciting.

New Bosses!

image (5).gifTheWatcherPlain

I managed to add a few more epic bosses (not drawn to scale). The first one is the Terminator, and the second is currently the most interesting epic boss:

Summoning Rune

I talked about using summoning runes as a story element in the previous post – they are objects on the map that can spawn monsters. And the epic boss I just drew can turn himself into a summoning rune! And when he does, he starts spawning monsters!!!

This was a very VERY tricky thing to do. To achieve this effect, I had to make use of almost everything I had coded so far – my spawn script, my rune script, my summoning rune animation, and this is the first enemy in the game to require an animation ‘controller’ to handle my different animation states and to also trigger the spawning at the correct frames.

Here’s a frame by frame animation I drew:

image (1).gif
AnimationClip 2 of Epic Boss

Also, a bit of deception – there isn’t actually a summoning rune on the map when the animation occurs. I actually wanted to make it such that when the animation is complete, the boss is set to invisible, then I set a summoning rune to the boss’ location, and enable the rune for 20 seconds because my summoning rune has an automated script to spawn monsters. In the end though, I decided to go with the boss = rune approach. This had pros and cons.

To date, all my enemies only need a single walk animation. But this beast has 3 animations:

  • Walking
  • Transform into summoning rune
  • Summoning animation
  • Transform back to normal (reverse of animationClip #2)

There was one con to my approach of making the rune and the boss the same thing – During spawning, the enemy will also stop moving and the tricky thing is, this epic boss flies – which means in his moving state, he has to be on top of all the ground monsters. BUT, when he is in a summoning state, he has to be BELOW the other monsters.

Illustration of the boss and creeps’ draw order when they overlap

Again this required some manual work by shifting the boss along the z-axis during the animation transitioning. I also modified my move script to make the boss stop all movement when he is summoning stuff.

Ultimately everything worked and the insane amount of effort was worth it when I played out my battle against this beast.

Map 20 – with Epic Boss III, ‘The Watcher

The boss is actually in the top left corner. You can’t really see him since I took the screenshot at a bad frame – he camouflages with the mobs underneath him. But the fight was very epic.


Sadly, I lost at my own game. I ended up having -17 lives too. Wait-what? That’s a bug. I NEED TO FIX IT NOW!!!!

I think this is the most time-consuming epic boss I have made. The map also lives up to its reputation. It has a gigantic rune in the middle and this rune too has some special effects up its sleeves every 7 waves. It also has its own animations! (If you want to read up about what runes are in my game, it is mentioned briefly in Part 5, my previous post)

Large Rune – originally drawn at 900 by 900 pixels, which is bigger than the game’s default resolution

I seriously cannot wait to let people try out this map! I used to say that Map #10 looked like the final level because it had 2 special effects.

image (4).gif

Then I made Map #15 and it had 3 special effects!

This is currently Map #20. And now that I’ve made my third epic map, I can say that Map #20 is totally badass.

I put a lot of effort into each of my maps and my creeps – and it’s not just the special effects, but right down to each of the creep’s individual animations, and I really hope some people who play my game will notice that because the creeps in the game are actually really small.

New Creeps

image (2).gifimage (3).gif

I have a few new creeps, some of them are for my Challenge maps. I’ve drawn golems, elementals, and upgraded versions of current creeps.

Evil Snowmen!!!

But there is one creep which is particularly interesting because it is the first monster that is able to debuff your turrets:

CorruptedCreep - Copy
Join the Dark Side!

Not related to enemies directly, but I added a neat visual display to show a red arrow on turrets that are debuffed and a green arrow on turrets that are being buffed.

New Turrets

I finished up the drawing my last second turret, The Arc. Unlike normal turrets, this turret occupies a gridspace of 2 x 2 grids. I may be changing this turret’s graphic in the final game if I have time for something better-looking.

image (6)
The Arc

The reason why I wasn’t quite satisfied with the final result is simple. You can actually tell that when I was drawing the turret above, I was confined to a tiny gridspace in the shape of a square. However, upon getting inspired and actually letting myself draw without limitations against an actual full map background, I was able to draw a few drafts of what I actually envisioned as the ‘ultimate turret’.

Summoning Rune

I for one, would like to see an epic turret capable of shooting swords to impale my enemies!

More special maps


One of the things I really enjoy is drawing maps. I try to make maps as cool and awesome-looking. There’s an ice map, a fire map, a boss-only map. I really stepped up on the map environment variations since my last post on drawing Maps.

There are also variations in the environment props – like the trees/skulls/flowers/cracks/ponds that litter the map.

My latest map, Map #26 features a special Oak Tree on it. The enemy can actually pass through it and go underneath it. A simple but pretty cool effect that stands out from my normal props which usually serve as decoration and lack any sort of enemy interaction.

image (7)There are even more interactable objects on maps – like the Hadron Pulsar I mentioned briefly in my previous post, which is an ‘environment prop’ that you can repair, turning it into a turret!

I also added other unique click-able / interactable objects, thanks to my Building script I coded last week. The cool thing about the script is that it can be applied to any environmental object to make it click-able. But I don’t do it often – it’s sparsely used to preserve the uniqueness of clickable objects and also I don’t want to flood the game with junk by littering every map with these.


The map above has a skull entrance, which is set to be on top of everything else. I also drew glyphs (the white glowing characters) leading up to it.

You must realise…you. Are. Doomed!

I also have a treasure map level. This is a side-quest, more of a side-story that is optional to venture on. But if you accept the challenge, you will get a very nice reward and unlock a hidden storyline.

Time to go bounty hunting!

Loading Screen when loading maps


I spent about half a day implementing this. It was a bit technical for someone of my caliber, but I did it. I’ve displayed “loading…” popups before in IdleHeroes, but it doesn’t tell you the current loading progress.

This time, I decided to go advanced. I used an AsyncOperation to get the current loading progress and created a loading scene. As the game loads, a few things happen:

  • The bar fills up left to right, and color leaps from red to green
  • The creep will walk from left to right
  • The background will light up (to 100% brightness at 100% progress)

The loading scene was actually unnecessary since the levels are loaded within half a second. It was so fast I had to go frame by frame to capture the two screenshots above. That’s right, the loading took 2 frames – out of 30 frames a second.

I guess the loading screen would help for those with slower computers so there’s at least feedback to say that the game has not hung, just loading. As the game gets bigger, loading times *might* increase in the future as well.

Skill Upgrades


The tutorial picture above says everything.

These are powerful skill upgrades rewarded by my Challenge feature. For many weeks the Challenge feature gave no rewards. The reason being I wanted challenges to give something special – not plain EXP or skill points, but extremely powerful stuff that you can’t get by playing the game normally – thus ‘Challenges’.

The maps of Challenges are uniquely designed to have special elements in them and special spawns. I’ve drawn unique enemies that don’t appear in the campaign mode, but appear in challenges. I sometimes think that the Challenge maps are far more interesting than campaign levels because I actually make Challenges when I have inspiration, and inspiration is a really powerful thing.


I guess the one good thing about being an independent game developer working solo is that I get to express my creativity a lot as I don’t have many restrictions. I get to inspire myself as I work and it really helps me to make better games!

More Story panels

As the campaign levels are being built, I am also developing the story in accordance to my story script which I drafted out weeks ago.

So far I like the story and enjoy drawing the story panels a lot. Sure, they take up a lot of time for something that is only on-screen for 2-3 seconds,  but visuals really tell the story.

Here are some story panels (in no particular order or sequence):


As I was drawing, I had some flashbacks to when I was drawing cutscenes for ‘Introvert’. Despite being my very first game, it had many cool cutscenes that I wish I could show to people I know.


I really enjoyed working on that game a lot, especially since it is a story-driven game and rather personal. I hope to someday release it to the public. Perhaps after I am done with this TD?


Sound Effects

For about 6 weeks, my game had been mute. No audio or music, till now.

I have begun adding the official sound effects in my game. I don’t have the money to hire a studio this time (though I might do it for the learning experience?), so I source for royalty free sounds. A lot of times when sourcing for suitable sounds, I don’t really get to find what I want exactly, so I take the closest one I can find and modify it (using Audacity).

But, there are moments when I do manage to find the exact sound I want, and I get really happy! It’s like the sound effect matches exactly what I envision my turret / object would sound like!

To keep things organized, I kept a table of the sounds I have in my game, where they are used (which script triggers it), and by what object


Creep Personalities?

My original intention was to use one standard death sound for all my 20+ creep types, but I learnt something from this experience of adding sounds to my game.

1 Sound for every creep?! Just one day ago I would say no. But well, I ended up doing it anyway

Sounds are just as important as music – sounds can add personality to the creep. A creep that has a human-y voice will appear more human-ish. It makes it give the vibe that it is kind, innocent, sound compassionate and almost makes you feel bad for killing it.

A creep that lets out a fantasy death sound removes the human element of it. It’s good for a non-human creature.

On the other hand, lowering the pitch or making the voice deeper makes it more ferocious. I gave this to the more evil-looking creep variations. I actually took a human-ish ‘OUCH’ sound used for a Standard Creep and modified it for one of the Corrupted creep, because the Corrupted Creep is basically a more evil-looking Standard Creep, so the sounds it makes should not be too different from a standard creep.

And finally, the sounds I used for the death of an epic boss is a very deep and long chilling death howl – to give a sense of satisfaction and to tell you that you just killed something really, really powerful, and you should feel good.

They look similar, but they produce similar yet different sounds

As I am sourcing for sounds, I also get a lot of inspiration. Sometimes, I hear cool sound effects that really inspire me to put them into the game and I also manage to find sounds that may not be what I am looking for, but I realize that it would be great for something else – like for a side feature or accompanying a mute animation – I go “Hey, this sounds interesting. Not what I’m looking for but it fits the ‘XXX’ really well”.

Sometimes, I also get the feeling of reverse Deja Vu – I find a sound that I know will be useful sometime in the future, so I save it anyway, just in case.

Audio Mixers

Unity gives me a lot of control over the audio I use with something called Audio Mixers. It allows me to group audio together, and I can control each group’s audio individually, or globally.


Previously, I used two audio mixers – one for BGM and one for sounds. But I combined both and instead used groups to separate them. Master, Music and Sound. Changing the Master volume changes the volume of every audio clip.


I have also updated my options with sliders for more flexible volume control – previously you could only mute/unmute every single soundtrack and I had no control over music vs sounds.

Options panel

Blog144 My options screen got bigger when there were more things in my game to customize – shake screen effects, camera movement were options added over time and I believe there will be more to come.





Also, a look at my taskbar:


Yep, just another average day in game development. Thank god I have three monitors and a supercomputer.

That’s All!

UpgradeButtonPlain.pngEvery day, I am making new stuff – I code new features, I draw new art. I don’t think there ever has been a full day where I’ve never drawn a single art asset or did not have a new line of code in my game. Every day, just so much is being done. And this really makes me happy, to just do what I love and to learn at the same time. I open and close dozens of tabs every day, browsing stackoverflow, forums and googling for art inspiration. I’m going to bet there hasn’t been a day where I did not learn something new.

It is such an amazing and magical experience to be making a game and to be part of this entire process.


Oh, I also went back to school today (the Polytechnic which I graduated from 3 years ago). I still don’t know what I want to do with my life.

Going back to school was quite a nostalgic trip and prior to today, I had written a full essay on my adventures in Polytechnic, the ups and downs I have been through in those 3 years and how I was first inspired to create games. I should post that here someday… I think it might be something exciting and maybe surprising(?) to read.

I think next to developing games and drawing, writing is my second hobby. It’s probably  the reason I started this blog, so I can talk about the things I love and maybe even inspire someone out there.





Making a Tower Defense Game Part V

This is part 5 of my journey in making a Tower Defense game. It is also 2 Jan, the second day of 2016 at the time of this post, so Happy New Year!

Special Buildings

Build something!

I added special turrets and structures to the game. I put a lot of time into the thought process behind the coding and design and managed to extend my turret class to house a new type of structure – Buildings.

Most of them don’t shoot at enemies, and those that don’t give some kind of bonus.

With this script, I can create different types of structures that do very unique things.


I can also convert any ‘building’ to a turret as well with my build() script.


The structures you see sitting out in the sea are oil rigs – they generate additional gold income at the end of each wave.



I have also coded runes. Runes are a different kind of ‘structure’ that you can build on top of.  Unlike buildings, they don’t occupy a grid slot and have a very unique effect. They boost the damage of a turret built on it. Their damage will also be highlighted in green to indicate the boost.

These can be upgraded to have increased effect on the turret built on it.


My runes were actually drawn too large that they appeared so small on the actual map. The funny thing about my previous game was how I always drew things too small, but in this game my graphics are drawn way too large that it became a problem.

New Turrets

I added two new turret types, so the game now has 9 turret types + 1 hero. The game had plans for 12 turret types, but thanks to buildings, there is enough variety in structures. This game is already getting a bit too complex in terms of turret types so I will see how it goes first.


The Gold Turret / Gold Factory will increase gold dropped by creeps in a certain radius. However, if there are more than 1 gold factories, I want it to always take effect of the highest leveled gold turret. So I made each creep stores a list of the gold factories’ gold multipliers, and when it dies, it checks through the list and multiplies its gold only by the highest multiplier.


The turret class was also expanded to house several new data with the introduction of the Booster turret – introducing a new mechanic where turrets can boost damage of other turrets.

It sounds sraightforward to code. But you got to make sure that multiple booster turrets buffing one tower are stacking the way you intend, and when you upgrade a booster turret, or sell it, you have to remember to update the turrets that were previously boosted – to take into account the difference between the new boost and the old boost and add or subtract accordingly. Or rather, recalculate the entire boost amount. The booster must also remember not to boost itself.

Story panels

Next up is another one of my scripts, the Info Script. It was named that way because of its original use – to display info panels.

However, I extended my simple info panels to be able to include story panels as well, have pictures along with text, and a very convenient class that stores every dialogue available for use to easily trigger when I need to and can be expanded easily:


Adding new panels is literally just typing what you want to read, and what you want to see by setting imageNames to the “picture name”. The field can be left blank if I don’t want to use any picture. I can even set the picture size to “BIG” or “NORMAL” or “NONE”. Most story panels use the BIG pictures whereas information panels use normal sized or no pictures.

Info Scripts can also be queued so I can stream story panels together seamlessly. I also added a fade in fade out effect as a final touch.


I really love the story panels by the way + it’s fun to draw the pictures. I put a lot of effort into the dialogue and hopefully it doesn’t sound too awkward or cringe worthy. I want to go with minimal dialogue for this game to tell the story and I’m pretty happy with it so far.Blog122.jpg

Monsters that spawn other monsters

Blog106.jpgI managed to code a SpawnScript. It is a script that can be attached to a monster, to make it a parent. A parent that gives birth to children. So basically in the script, I can set a couple of things just by flicking switches and setting values:

  • The HP requirement to start spawning
  • Conditions to stop spawning (eg HP drops below 50%)
  • How many monsters to spawn and max monsters if any
  • Spawn interval
  • Any break durations, for example, stop spawning for 20 seconds for every 8 monsters you spawned
  • The enemy type to spawn

This simple yet complex script is pretty flexible enough that it allows me to create a very unique first epic boss.

The Incinerator

The Incinerator has a couple of abilities. For one, it is able to spawn miniature ships. And the first fight with it was pretty epic.Blog115.jpg

This is only Map 10, but I really feel like making it the final map. This map has a couple of special effects – darkening on spawn, story panels and a very unique epic boss that is challenging to fight. In fact, this map is so special that it feels like a finale to the game already. I really am tempted to make this the final level. That’s how complex this map and boss is.

Sadly, I think I drew a couple of other epic bosses for the future levels, and I have a story script that pans out across 25-30 maps.Blog112.jpg

Lots of work I guess. Also, more monsters spawning more monsters:


Also, in league with the new epic boss, I made two specialFX functions, which I can use to trigger when a monster spawns, and when it dies. For example, when the Incinerator spawns, it triggers an event to darken the map.

Side maps

I also did manage to make a very wonderful side-map. In the screenshot, below you can notice a special building – the Control Tower. It is another one of my unique buildings that uses my new Building class script. It was initially non-interactable – i.e. just a decoration , but I programmed it to be an actual turret instead.

The Airport

I really love this map a lot. I think it’s my favourite map so far. This isn’t a story map, but for some reason I felt like I wanted to put a lot of effort in each of my maps. I think that should be my goal – to make each map special and not just make maps for content’s sake. I have stopped drawing new maps for now and if anything, I have way too many map graphics. I will only draw new ones if there is really strong inspiration or good map ideas/designs.



I also made new enemies unique to this map.

Each map can be set to have a unique array of monster spawns. For example, I can specify that I want Ladybugs, Turtles, and Larva monsters. My enemy wave spawner will then loop these 3 monster spawns automatically.


My maps are getting more diversified enemy types as well. Waves can come in different forms and unique orders.

Next up…

Multiple Spawn Points!


I was really NOT keen to do this. In fact, there was no need to. My game is super complex already and I don’t want more stuff in it. But I felt obliged to do this because of several reasons. Let’s skip the reasons though.

Blog111.jpgMaking multiple spawn points is NOT an easy task. I want to make my spawn system flexible. And in the end, I managed to make a very robust spawning system. And this is one of the things I’m really happy about. When making games, I learned that you really want to make your game easily modified and expanded.

I can add new paths to my maps just by duplicating a current path, resetting the waypoints, and renaming it Map2A. That’s all I have to do. The code takes care of everything else.


In fact, I even coded a weight system for handling the distribution of monsters to the different paths. By default, all paths have the same weightage. But if let’s say I want like 3x more monsters to spawn from the left, and 1 from the right, I can simply do

“spawnRatio = [3, 1];”

My outdated spawnDivider function. I now have a better one.

I’m really happy about the spawn system because of its robustness. In addition, I can even enable/disable each spawn point individually, to stop them from spawning monsters at example, wave 10, during special story events, or re-enable them for like an epic wave at wave 20.

Monsters spawning from 2 entrances

A lot of this functionality is barely used in the game though – there just isn’t much maps that need it. But I believe it adds to the cool-ness when you encounter a map that does. It makes that map feel so much more unique.

Also, monsters can spawn in the middle of the map, from special spawn points called Summoning Runes (story-related?):

Summoning Runes

So monsters do not always necessarily come from the edge of the map. I have plans to use summoning runes as a story element.

Special Effects

Seemingly one of my favourite things to do in any game, and have done so for my previous games: Introvert, Idle Heroes, is to create special effects.

These are specially scripted story events involving camera movement, zooming, special animations and event triggering that do not happen anywhere else in the game. These special effects can take awhile to code, depending on the complexity and the code is often unique – unique as in the code executes stuff specific to this special effect. (5).gif

The special effect you see above is a combination of two individual special events. First, the monster movement animation. It is actually my first attempt at making a fluid movement animation by using rotation, position and speed.  It actually took awhile to do that because I wanted the animation to look smooth. I set keyframes during the animation of where I wanted it to move to, then switched to graph mode to try to fine-tune the values and tangents.


My original intention was to just have it fly from point to point, then rotate at each waypoint to face its new direction. But doing the whole thing as a fluid animation… it was just really special. (6)
Animation keyframes

NOTHING ELSE IN THE GAME moves like that. So it’s a very pretty special event considering every other creep or object moves on pathways. This is a one-time event that occurs once in the game. I think the animation can be improved though, but I’m still pretty happy nevertheless. It was really exciting to actually try something new and bold (to me at least haha).

The second thing you’ll notice is I incorporated the camera zooming function I coded in Part 4 of Making a TD Game.

I extended my Camera Script to allow it to do two things. First, follow an object I specify, and secondly, lock the camera and disable the player from trying to move it with WASD, scrolling with the mouse, etc.

When this event plays, the camera will automatically and gradually zoom to its desired position and zoom level, which is really, really cool because all this while the game is being played at 1x zoom and you don’t see the camera zooming in or out. The camera is also locked during zooming so you can’t break the zoom.

Here is another special effect of this map that plays once every few waves: (7)
“Ancient Glyphs”

This is actually what is categorized as an ‘Epic Map’ in my game, which is a special map with a unique boss and advances the story quite a bit. This particular map has 3(!) special effects. The last special effect is the river in the center of the map. With each wave you summon, the river turns more and more red until it beomes a river of blood. Creepy!

Game Performances / Lag

So I wanted to test the limits of my game – to see if it lags when I have a lot of monsters on the map. So I multiplied my monster count by 10. But it was a little underwhelming. My turrets were killing too quickly. (I have to have the turret shoot and kill stuff because I want to simulate them shooting and have monster death as potential lag variables as well).


The game didn’t lag above because my turrets were killing stuff at the same rate they were spawning. So in order to test mob count limit, I set all monsters to spawn monsters every second while alive and on death, spawn up to 6 copies of itself.


Worst idea ever. The lag multiplied exponentially. The game ran okay for about half a minute, but within the next half, it dwindled to 4 fps because everything that died respawned copies of itself.

Basically, don’t have monsters spawning monsters spawning monsters. What a horrible idea that was. Oh, notice the two screenshots above are actually the same map, just with different tints?

Map tinting

I actually tint my maps based on the mode you enter it on. There is a ‘Day’ mode, ‘Sunset’ mode and a ‘Night’ mode to correspond with my difficulty modes, ‘Normal, Hard, Hardest’. I really love this small little touch to the game. Nothing major, but it just makes me happy. The tints used to be more obvious, but I made them more subtle because the tint settings in Unity aren’t as advanced as Photoshop – they add color directly to the graphic, which make it look darker. Too much tinting makes the map look too dark and lowers contrast. I actually created a night color filter in Photoshop that automatically makes any of my maps look like night, and looks better without contrast issues, but the problem is that having the game use 3 map graphics means the game size will grow too big. Rather than doing it via Photoshop and saving each map on 3 different filters, I decided it was best to use tints, the tradeoff being that they didn’t look as good as color adjustment settings in Photoshop.

The Profiler

But back to the topic on lag, I think I managed to play around with the Profiler to try and see what are the top contributors to lag. In the end I did Object Pooling for my bullets and enemies. I think whether or not they contributed hugely to the lag, it is a good idea to pool them so they consume lesser resources.

Unity Profiler

Target Priority

I extended target priorities (options which allow you to customize what kind of creep you want a turret to target specifically). I added new targetting options and you can toggle a turret to fire or not and also, selecting a creep sets it as a top priority target, forcing all turrets to focus fire on it. It’s pretty cool.

Concentrate all firepower on that Super Star Destroye- ops I mean creep
Additional option: Disabling / Enabling turrets from firing

I also centralized a lot of my turret graphics. Probably a bit OCD, but previously some of my turrets were a little too much to the left or right, so when the disable icon appeared, it was ugly.

Anyhow, below is a portion of how my recalculateStats() function looks like.

I’m not even sure why I even put a picture of something I can’t even read

What it does is basically calculate how much damage a turret should do. Looks simple, but consider this. There are many factors that affect a turret’s damage:

  • Its own upgrade level
  • Is it built on a special power-upped grid?
  • Your hero’s skills can increase turrets’ damage (via a stat called Turret damage multiplier)
  • Booster Turrets – a special type of turret that boosts damage of nearby turrets
  • Special Upgrades – The sniper turret has a special skill to increase its damage

The same goes for other variables – range, attack speed, and turret cost.

There are other additional factors for damage of course, but they are calculated separately when the turret’s bullet is fired and hits the target. Things like:

  • Does the bullet ignore enemy armor?
  • What is the damage type? DOT (burn), A.P (Armor Piercing), N (Normal), INSTANT (e.g. from external sources that do instant damage like -% of enemy HP and possibly spells if added in the future)
  • Is the target affected by status effects that can multiply damage? e.g. shielded OR burning enemies

So when calculating damage and updating it, you have to make sure you account for all variables and that they stack in the way they are supposed to – additively, multiplicatively, or as percentages if two things stack in the same way.

So yeah, this game is really getting a bit ambitious I guess. It has a lot of things and I really don’t want too much stuff. But *sigh*

Multiple Save Files


Also, I actually made my main menu have a scrollable interface that supports up to 30+ save file slots. This was due to the fact that I have to extensively test and balance progression so I needed a lot of save file to test with. I also fixed a fatal bug in auto save where it did not actually clone itself when you try to load it into a currently empty save slot, but actually loaded itself. It was pretty hilarious when I had 3 save slots of the auto save and playing on one file modified the other two because they were all literally referencing the same thing.

More Balancing Blog92.jpg

The most boring part of game development to me is probably the amount of Math behind it. I don’t think many people will find it fun doing this, but it’s still something I put a lot of effort into. I just learnt that there’s even an entire module in University that teaches this kind of stuff.

Random screenshot of unrelated Math

Game balancing is not something common sense that you can brute force into your game. And neither is it something everybody can do well – it explains why some games are made imbalanced, and I think it’s something I might not be able to completely prevent in my game – there are just a lot of variables and different ways players can play that it can lead to unpredictable situations.


The game is pretty big now – the size of the project is about to be as big as Idle Heroes, which is my previous game and my very first game made in Unity, and I think it is about to reach as big in terms of content.


There are lots of problems about big projects – riskier, but perhaps more rewarding. But honestly, I prefer to work on smaller projects. It also gets harder to organize stuff in growing projects. I think it is inevitable no matter how organized you try to be, you tend to feel a little confused sometimes.

For example, I have a SpawnEnemy script and a Map script. The map stores data about the map, while the spawn enemy controls spawning. If I were to define a spawn multiplier, say make a special map spawn DOUBLE the amount of creeps. Do I set this multiplier in the spawn script or the map script? I actually went ahead and defined it in the spawn script because it seemed obvious, but my scripts worked such that all the map data is initialized in the Map script. The Map script contains all information about a map or level, such as number of waves, map health, difficulty, and such. It defines all the variables that make each map unique, and spawn multiplier is one of those variables that should be defined in the map.

It seems like a subtle difference, but considering that the game has a lot of scripts, they all need to initialize orderly, in a specific sequence to make sure all variables of all objects have the correct values when the game starts.

This is more of an organization problem. The code works fine and the game runs correctly whether I put the spawn multiplier in the Map or SpawnEnemy script.

So yeah, there were times I felt there was a better way to organize my code and so I actually spend some time shifting stuff around because I know I will be working on this game for a long time and it is good to at least have a very workable and easily understood codebase, even if I am working alone and I know the game code at the back of my head.

But don’t we all get forgetful sometimes?


Making a Tower Defense Game Part 4


This is part 4 of my journey in the making of a Tower Defense game! (I’m editing this post and adding more pictures as I go so check this post again after a few days and I will have added new updates!)

The game is currently expanding beyond the play area. I have begun adding new scenes /screens to the game!

This slideshow requires JavaScript.

Mainly, there will be many more screens, but currently, the game has 3 different screens: PLAY SCENE, LEVEL SELECT and UPGRADES.

I also worked A LOT on the map art. I try to only draw when I am really inspired because that’s when I get creative and really bizarre with my map art and ideas.

Map Art and Design

Above are some of the map types I drew for my tower defense. Although I do not divide my world into iconic areas like I did for Introvert, I do have maps for a Grassland, a rural village, Ocean, and I’m not sure what to call the red-tinted maps – The Burning Lands? The Scorching Plains? I’m bad at names, so if you got any cool ideas I welcome them.

My backgrounds folder is starting to get heavy too.Blog65.jpg

I try to put as much detail as I can in my maps, touching it up even post-production after I have put them in my game.


The above was one of my earlier maps which I went back to and actually made improvements on. Environment props, lighting and colour improvements are just some of the things that can make your map look that much cooler. There’s also animations but I’ll get to that next time when the game enters the polishing phase.

Also, not to mention that for every map created, I have to do the tilemap array – to set what tiles are ‘buildable’ on, what tile is an environment and what tile is a pathway. I can just use ones and zeroes, but I use different numbers to denote special tiles that I may have use for in future content addition. It tends to get very boring because it’s just  (almost blindly) typing 1s and 0s, but it is a very important job.

0 = Buildable

1 = Pathway (you may build traps on pathway in the future*)

2 = Environment / Obstacle

3 = High ground (turrets built here will have increased range in the future*)

*As you can see, although I have plenty of ideas for this game, I have to control myself from going out of scope – time isn’t infinite and for this game to be published, I have to stay within the scope I created for myself. But it’s always good to think ahead of time so you prepare for the possibility of integrating those new features in advanced.

Designing the Upgrades Screen (CONCEPT)


The upgrades screen underwent a few changes and I spent quite a long time deciding how the interface was going to be. I didn’t want the screen to be cluttered with up and down arrows for every skill icon because that is simply ugly. I also wondered if I wanted to do a ‘popup panel’ for each skill, but if I do intend to expand this game to the mobile platform, it would be a bad idea.

Adding Difficulty Modes!

image (1).gif

I also added something from the Impossible Scope. Each map can be played on 3 difficulty settings with HUGELY increasing rewards. The 3 modes are NORMAL, HARD and NIGHTMARE. The specific details such as rewards, difficulty multiplier aren’t decided yet at this stage. And yea, the purple ‘night’ graphic is for nightmare. Wordplay!

I figured that since I was doing the LevelSelect, I might as well have done this anyway. It is still a work in progress and I figure most of the work for adding difficulty modes will actually not be the art or coding, but with balancing the difficulty level and rewards for attempting higher difficulty modes.

Level Select, Upgrades, Stats and Menu


This slideshow requires JavaScript.

As of now, the game has a fully functional level select with map unlocking, a skills page with about 8 working skills, and a stats screen. The stats screen is filled with tons of useless information because I use it to debug hidden stats as well. The stats screen will be cleaned out eventually.

I also used my first ever particle system in Unity – to add some sparkly effects to the map selection. Just like the art, it’s just placeholder fancy effects for now.

I also have a main menu that I scripted in 5 minutes and you can see tell by the screenshot above (the one with the huge blue empty space). It has a working save and load system that’s uses serializable data. The menu was put in place because I foresee I may have to send my game to be playtested soon but more importantly, I need a working interface to load multiple files for me to test variables set to different values in different save files. Again, more for its debugging purposes. For example, I can set a savefile to have extra skill points just to see how it affects progression. This is useful if I want to test variables such as how many skill points each hero level should give.

Camera Zooming


One thing I noticed while watching the scene in Unity while developing was how much I wanted to zoom in. I have to admit, the turrets look a little too small sometimes. But adding a zoom mechanic meant I may have to do a lot of things. Other than setting the camera to a higher zoom, I also need:

  • A bounding box
  • Scrolling the map with WASD
  • A mini-map if necessary
  • Zooming in and out with mouse wheel function

This is a pretty late time during development to add such a major mechanic. But I did manage to code 3 of the 4 things in the list above.

I set the game to be fixed at a new 1.5x zoom and it does look pretty sweet on 1.5x zoom. 2x zoom is overkill.

1.5x Zoom Mode

I can actually see more details on the turrets. But for players who prefer to just see the whole map at an overview, then I have to add the ability to zoom with the mousewheel.

I actually went to search for tutorials because I wasn’t confident of my ability. But in the end, I couldn’t find a good camera zooming that fit my game well, so I made one myself!

And miraculously, it worked like a charm. I’m actually pretty proud of this code. Although someone posted a working code of adjusting the bounding box, it only worked if your map is at the origin. You couldn’t offset it, and you can’t use that code if you intend to adjust your zoom real time with the mouse wheel.

So I decided to try and modify his code to make it support dynamic zoom, and I did it! If you’re a programmer, this may not seem like much to you, but I was really happy to have figured out the code to dynamically adjust the bounding box for myself. There are probably other (better) ways to code this, but this was the way I did it.


This whole thing functions in a single script I attached to a game object containing the camera, so I can disable or enable zooming anytime with the touch of a button. I can even modify its min and max zoom level, currently the minimum zoom is 1x, and the max you can zoom to is 2x! It still is very clunky with my custom values, but this script will be very useful if I do make other ‘zoomable’ games in the future.


You can see me test out the finalized zoom mechanic here:


You can see that I kept clicking on things to see if I could select them properly. That’s because I previously used an alternate code and tried to offset the map, which caused problems where the mouse position or screen position does not sync with the map. The turret was built at a different spot from the mouse position when I had offset the map.


I’ve added extra functionality to the camera. Players without a mousewheel can zoom with the PageUp/Down keys or the + and – buttons. You can also use the mouse to click and drag to scroll the map in addition to the WASD/arrow keys.

Panning via mouse dragging

The mouse dragging was still very clunky in the GIF above, but I added a Lerp code to control the panning ‘speed’ based on how zoomed in you are. It worked perfectly.Blog86.jpg

Fine-tuning the Controls

This being a TD game, there are several shortcut keys that must be in place for the player’s convenience. As a player myself, I get highly annoyed by games that do not offer me shortcut keys – especially those that were built for mobile and the developers just blindly ported it to PC to reach another audience.

As I played my game, I noticed myself instinctively pressing ESCAPE to cancel my current selection. However, the ESCAPE key brings up the menu, and it was highly annoying. So I made it such that the ESC key cancels your current selection – if you selected an enemy, it cancels the selected enemy, and it works for turrets too.

And only when you press ESCAPE when nothing at all is selected, then the menu appears.

The other control fine-tuning is that if you press the same key on the keyboard, then press it again, it cancels its last action. So if you wanted to build Turret 2, but changed your mind,you can press ‘2’ to cancel your build. ESCAPE also works, but if you are rapidly placing turrets, this is helpful if you are lazy and don’t want to move your fingers across the keyboard, especially for Turrets 6 onward, where the ESCAPE key is far.

Yes, I realized I am one of the lazier players who just prefers to have my fingers over the keys I mainly use!

That said, I’ve also been in the shoes where I didn’t quite understand a particular stat. Some games display helpful tooltips when you hover your cursor over stats, but some games don’t do that and it can really confuse the player – one of the reasons players quit is when they don’t understand what is going on in the game and what all those numbers and stats mean. If the player doesn’t know what your stats do, he doesn’t know what to upgrade, he’ll feel lost and lose interest very quickly no matter how content-rich your game is.

This being a TD game and I have a hero character with an upgrade menu that’s growing by the day in complexity, I know I need to have to display information without obstructing the main gameplay by flooding it with tutorials / annoying popups and such.

Oh and talking about the hero…

The Hero Character (and its problems)

HeroHatHeroHat - Copy

Although I said that I did not want to implement a hero character at this early stage of the game’s development phase, I decided to do it now because having a hero character in the game will greatly affect the balancing and I have to tweak each map’s difficulty. So I want to finalize the hero’s role in the game before moving on to other key areas of development.

There are some features that make the hero special from normal turrets:

  • He doesn’t cost any gold to ‘build’, but he has a cooldown before he can be summoned to the map.
  • He can be sold and moved around the map, but with a cooldown so he isn’t exploitable by always putting him in a boss’s range
  • You can only have 1 Hero character on the map

Now when thinking about my hero, there were a couple of questions I had to ask myself.

  1. Should he be upgraded with gold like normal turrets?
  2. When you upgrade him and he is ‘sold’, does he reset back to Upgrade Lv 1 the next time you place him?
  3. If his upgrades persist, it may cause balance issues where player is able to repeatedly ‘sell’ or ‘move’ his hero to always be in range of a boss or creep

Then there was an even bigger issue was that because the hero can level up, he gets really strong compared to other turrets at the beginning of a game. The turrets start at level 1, but the hero can be at level 10 or 20 in the first wave! But because he doesn’t scale like other turrets, he gets very useless late game because giving him upgrades that scale the same way as turrets makes turrets useless! The player would just spend all their gold on the hero character and ignore turrets. But make the upgrades weak or disallowing upgrades makes the hero useless late game. So either way, I was pretty screwed.

After lots of discussion with my friend, we came up with the idea that the hero will be a special unit that is very powerful, but you can only use him for a short duration and he will ‘disappear’. It was the right thing to do and I loved the idea – there is no point keeping the hero on the map forever when he gets useless toward late game. Better to remove him once he starts to become useless. The hero is still very powerful despite his limited use, and he can turn the tide of battle when you deploy him in a critical wave. This adds strategic depth to the game that I never imagined before.

The implementation for the feature took very long. I spent a whole night finalizing the design and changes, and also pacing around my house thinking of and trying to predict if a change as major as this would cause any issues.

Skills / Upgrades!

One of my favourite things to make in any game is an upgrade system. I love a game that gives me a sense of progression and getting stronger with time, and I want my game to have this as well. To do so, I incorporated the upgrades system. I didn’t want to be too fancy with a skill tree.

I’ve had enough of that already.
No more skill trees this time!


Well, the thing about having skill trees is you probably make it for the purpose of unlocking stuff and pre-requisites. But they can get very complex from a balancing perspective. It has its pros and cons.

The last time I attempted skill trees, it didn’t go so well not much because of programming or art, but more so in how the tree was designed. This time, I really want to go as simple as possible, so I just want to use a simple unlocking system – by hero level and displaying all my skills in one screen.


Each of my hero’s skills contains a max level as well up to 3 variables which I define in the Skill class. These variables can function as passive damage, or gold increase, depending on what skill it is. These skills are added to my Hero class and my hero has a getSkill() so that I can conveniently get any data such as interestRate, turretPercentDMG, or any other bonuses from anywhere in the game.

Complete with cheats too!

I also spent a lot of time tinkering with what I feel is the final UI. You can hold SHIFT to increase/decrease skills by x10 without having to click multiple times. You can also hold down the mouse button on an arrow if your SHIFT key is spoilt. Additionally, the arrow keys on your keyboard increase/decrease all skill levels by 1. Now nobody can say I don’t have enough shortcuts!

I also love the UI in the sense that there is a bar below every skill that fills up as you increase it. It’s a very visual way to see how much of each skill you have your SP in.

I gotta make that skill glow or sparkle at max level…

Upgrades aren’t new to this genre, but doing it is not an easy feat either. It is much easier to create a sandbox TD than it is to create one with progression and a leveling / XP system. Not many TDs attempt this I guess because of how tricky it can be to try and blend a bit of RPG into a TD. Most casual TDs keep their upgrade system simple and straightforward.

If I were to make a sandbox TD, it would have been a lot easier. There would be no need to spend so much time on balancing. But because I have multiple maps, multiple difficulty modes and unlockables, the progression of the game has to scale properly. I can’t have an easy level followed by a hard level, or a gold formula where it is so hard to get gold at the start and then by late game you earn so much gold you insta-kill bosses, which is what is happening in my game right now. It’s ridiculous!

So yea, upgrades are a very treacherous territory I’m venturing into, but I will get it done!

Revisiting the Enemy

Other than the stuff I mentioned in Part II, I actually spent very little time talking about the enemy even though it’s probably one of the more outstanding things about this game. So I’ve decided to talk about it! Besides, I’ve made some changes to some of its statuses as well.


The enemy has two important scripts to make it work. A MoveEnemy script controls its speed, max speed and its position along its current path.

The Enemy Script is far more interesting. Here, every data about the enemy is stored and can be extracted. Things from its reward to whether it is immune to your slow turrets. The only thing missing is Health, Armor and Damage Reduction values which are stored in the Health Script, a separate script attached to the enemy’s health bar, which is a component of the enemy itself. I revisit the enemy script every so often to modify stuff – not so much to add stuff any more because it already has everything I need.

But there’s another very important thing in the game – Turrets. And there is one particular turret that is giving me a lot of headaches.

The Sniper Optimization Dilemna


Every turret in my game has two basic scripts attached to it – A Circle Collider component, which determines the range of the turret, and a Shoot Enemies script attached to it. When an enemy enters its range, it is added to its own list, ‘Enemies In Range’.

One of the more challenging turrets I added is the Sniper. Today, I ‘re-coded’ the Sniper’s special ability – it can shoot invisible creeps which hides itself from your turrets. It gets technical here on, so skip the next paragraph if you don’t want to read the programming aspect.

There were so many ways to code this feature, but I didn’t know what the most optimized way was. I decided to code it such that all enemies disable their colliders when they hide, and then re-enable them when they unhide. However, without colliders, sniper turrets will then require an internal function that does a distance check to continuously detect if an enemy is in range. But without a collider, again it meant I had to somehow get a list of all enemies on the map – not just the ones already added to my list of hittable enemies, but also the ones that aren’t – the reason being that without colliders, even the sniper turret has no idea when enemies enter its range. So there was actually a need to consider what was the better way to get a list of enemies spawned – create a List that is stored in the map object, adding enemies spawned to this list…OR… create an empty parent game object within which all enemies are instantiated in. Then the sniper will reference this parent to get the enemy list.

There are just so many things to think about when adding a feature like that. I did however, in the end get it to work. (3)
Zero damage Sniper Turret in action

Balancing Pt 3

You know your formula scales really well when even Excel decides to create a rainbow out of it

Jokes aside, balancing this game has been a pain. As the game grows, there are more and more variables to account for. And right now I spend more time testing than actually developing the game because I want to get the pacing and difficulty of the game correct.

Mobile Porting and Testing (13~18 Dec)

As I was overseas for 6 days, I did not manage to add anything for one week. But that’s not to say that progress was not made in these 6 days. Before I flew off, I managed to port my game to Mobile.

The reason was not because I want to launch this game on mobile, but rather, I needed a platform on which I could readily access my game (and show it to potential employers in the future I guess?).

It was pretty major to me because I know the difficulty of porting a game to mobile. Sure, Unity makes it easier, but if done incorrectly, it can cause problems. I spent about 2 hours trying to get a proper aspect ratio and resolution for an Android build because the game kept looking like this on my phone:


It was a hot mess with the UI jumping about and being in places they should not be. What’s worse that my flight was early in the morning and I was extremely sleep deprived as a result of burning midnight oil trying to port my game. I was EXTREMELY tired when I was doing the mobile porting. I think each time I waited for the game to compile to my phone, I would fall asleep for a few seconds. Seriously, I was just soooo tired.

Thankfully, it worked in the end! Though playable on phone and having the game work much better than I thought, it really isn’t very optimized. Nevertheless, thanks to this, I was able to test my game while overseas.

List of improvements (and some balancing notes) I took down during my playtesting while overseas

The improvement list contains stuff to make the game better – mostly quality of life and better UI / interactions to enhance user experience. I also wrote a lot of code on my phone. By the end of my trip, I had accumulated 40(!) pages of notes on my phone. Apart from improvements, I also had a bug list and other lists for different purposes.

Not to mention, I also wrote code.

Yeah there were apparently more pages of code than I thought as I was exporting all my notes from my phone to my desktop.

There’s code for an Equip class, even a Spells feature from my mega-impossible scope, but most importantly, an extension of my Turret script, for a very new feature I intend to implement very soon – BUILDINGS.

The reason why I wanted to pseudo-code on my phone was because in programming, I sometimes find that people sometimes can jump too quickly into coding a feature only to realize later on that there are better ways to code it. I’m no exception, especially when I am so excited about my game. Sometimes, I don’t think long term enough while coding and this makes it hard for me to expand the game.

Thankfully, having 6 days away from Unity gave me PLENTY of time to deeply think and analyse what I feel is the best way to code certain features in my game.

And I managed to code 4 scripts overseas! Yes, actual scripts that I could use in my game the moment I got back to Singapore. I had access to a laptop there, downloaded Unity and began coding. I didn’t manage to sync my project with Dropbox, so I mostly coded independent scripts that would work without my game – a script for an inventory system and an Equipment class that is able to be extended to house several equipment types like Wand, Robe, Glove etc.

This slideshow requires JavaScript.

I also have some pages on plans on a ‘Challenges’ feature and on the implementation of the ‘buildings’ feature.

Swtd2_16I also drew some mock-ups of some UI and visual diagrams (more for my own reading).

However, the inventory system and equipment script are for ‘impossible scope’ features, which have extremely low priority on my to-do list. I won’t be adding features in that scope to the game until I settle the things in my medium scope. I might even not add them at all but in a sequel because the current game really has a lot of features already.



Swtd2_28So I guess that’s all for now. The next time I write here will most likely be a new post about 1 week from this one. It has just been too much fun but I’ve got a lot of work to do now that I am back in Singapore and I really want to get on with implementing all the things above. I have already implemented Challenges and have a working Building script, which I am super excited to talk about in the next post!




Making a Tower Defense Game Part 3


It is now Day 10 of my journey of making a Tower Defense game. Read Part 1 here and Part 2 here.

Creeps Completed!


At last, I am done with the creeps! Everything from coding, implementation and its art/animations are more or less finalized! AT the moment, there are 14 creep variations, each with their own animations and abilities. With creeps in place, the next thing I had to do was the Wave UI.

Wave UI

The Wave UI serves a very important purpose – to display the upcoming wave information – creep type, health, gold, speed, description and its special ability stats (if any).

I first coded the wave boxes to move from right to left.

10 glitchy Wave boxes at the bottom of the screen

It was very buggy at this time of this screenshot, but there is a very neat shuffling animation. Basically, instead of ALL wave boxes moving together, they move one after the other. I think this is a really neat effect that though is small, adds that nice touch to the UI.

Everything was not smooth sailing. This wave UI is really one of the harder things to code so far It was deceptively simple, but complicated.

There’s this problem I had was that I never create my enemy before it is needed, so there was no way to obtain information about the next wave of creeps without first spawning a creep!

It would be cheap to simply secret spawn a creep without the player noticing, get its stats, then kill it, but it’s not a very clean approach and very hacky.

Of course, there are many ways to get those information without spawning a creep – like moving the functions that calculate HP value of a creep of a particular type at a particular wave number to somewhere more accessible. But these functions cannot go into my EnemyScript because the enemy isn’t spawned! Sure, I will have to put it in something like the WaveManager or GameManager. But to me it seems like counter-intuitive design because the Enemy will end up referencing another object to get its own HP value. It’s like the enemy doesn’t know its own HP and has to ask another object.Blog39.jpg

I even tried setting and obtaining values from the Enemy base Prefab and boy was that a horrible idea. For those that don’t know what a Prefab is, it’s like a ‘base’ object which you can create multiple copies of,  like bullets or enemies that are created multiple times and destroyed. What happened was that I ended up CHANGING the base prefab, essentially “corrupting” it and every enemy that spawned after it had its values OVERRIDEN. Of course, I did try to set it back in code, but it got really messy and weird shit started happening, so I gave up the idea.

I didn’t know what the best practice was so I decided it was down to preference at this point – I am after all, the game designer and I have to be comfortable and understand my own code.


My style is to use a DummyEnemy. This dummy enemy is actually not an actual enemy, but an empty shell containing the EnemyData class, a new class which I made to store every important detail that is needed for display in the wave UI.

The DummyEnemy can be initialized to ANY enemy type, and it will simulate the stats of that enemy. There may be a better way to code the wave UI, but I think this works very well for my game, plus I even intentionally allowed this ‘dummyEnemy’ to be seen by the player in the wave Info UI:


You can see the dummy enemy at the bottom right. It also plays its walking animation! HOW SWEET IS THAT? I totally didn’t intend to make the wave UI this fancy. Oh and by the way, that screenshot was 2 days after the first screenshot of the wave UI, so most of the bugs are fixed. I even got the wave UI to display the correct color codes of a creep and indicate if it is a boss wave!!!

I was really happy to have not only a working, but very polished Wave UI that may look like it will stick until the final game release.

Upgrade animation!

When upgraded, towers now get a green upgrade animation. This came out of necessity because I couldn’t tell when my towers were upgraded even though I was pressing ‘U’, there was no visual feedback on the tower being upgraded other than the damage numbers in the UI changing.

UpgradeButton2 - Copy.png

Target Priorities!

Turrets also get target priorities – whether to attack the first or last enemy, etc.


I was very reluctant to do this at first, but the variety of towers I have and the creep enemy specials means that I have to give the player the option of specifying what targets he wants his turrets to attack.

The coding ended up being so much simpler than I thought. I already had the script to target the enemy nearest to the exit, so I just reversed it, and made a bunch of if-else statements based on what target priority setting the tower has.

Icons for changing target priority

In fact, I was just copy-pasting the if-else statements for the code that it actually got boring to implement this feature. Nevertheless, I’m glad I get something easy to code once in awhile. It was a great break after coding the wave UI.

Map Generation

There are multiple ways to code the creep’s movement path in TDs. From using pathfinding AI to simple waypoints, it all depends on what kind of game you are making.


My game does not require dynamic path generation, so I used way points. It is always better to keep your game simple whenever possible.


Here, you can see that I am already starting to introduce multiple levels into the game (art in the screenshot above isn’t finalized). I started by first ensuring that I can dynamically create map graphics easily. Coding multiple maps is a matter of using 1 and 0, so if I create new maps, the bulk of my time will be spent on drawing. In my first ever attempt at Flash TD, I used tiles as a quick approach to render the map. The result was pretty ugly because it looked so… systematic. And using gridded tile graphics may make your map look artificially generated and repetitive. Nothing bad about that, but I wanted my game to look pretty, so I draw custom maps manually.

But can manually drawing be simplified?


Applying a set of filters and stuff actually makes me able to draw dynamic pathways easily + look good at the same time without having to resort to grids. All I did to draw those paths was literally pick up my stylus and just draw a path on my WACOM tablet, like how I would draw on paper.

I guess that’s one of the really godly things about having your own drawing tablet.

Although it looks easy, drawing maps still take time. The pathway takes a very short amount of time, but the map itself is very tedious – at least 30 minutes to an hour or two. Why? Because I want each map to try to use unique environment art. I mostly try not to use the same trees. No doubt some environment art will be duplicated, but I try to draw different trees and stuff for each of my maps.

Once the art is drawn, I add finishing touches like lighting and shadows to the map and the new map is ready to be implemented!

Yes, manually drawing maps is tedious, but I think it’s worth having pretty maps especially when it occupies 80% of the game screen, plus it is pretty fun! This of course, depends on the game’s design. I don’t intend for my game to have many levels so this design approach works fine for my game.

The HERO character


I have also begun work on an optional feature – the Hero character. The Hero is meant to be unplayable in my TD – just an invisible character, but I may add him in as a bonus playable ‘turret’ on his own!

At the moment, only the art is done and very minimal coding. You can call your hero to the map and hell, you can even put 10 heroes on the map because they don’t cost anything.


I have a HAT graphic that is not shown above. If I do implement equipment (super low priority), the hero hat object has to be stored separately because I will have to swap out the hat graphic when necessary.

I have LOTS of design work made for the Hero. In fact, I have MULTIPLE designs. And I’m not sure what the best way is to make the hero work in this game, so I have disabled the Hero feature temporarily.

I also have a backup sprite and side-view attack animation from Idle Heroes for use in this game.


Though I have about 50% of the hero coding done, and even have the hero sprite and idle/attack animations completed, I want to work on other more important features and the Hero is not a priority. At this stage, the balancing and game’s main reward system is more important.

As the game grows and there are more and more objects and states, many potential problem can arise if you are not careful.

Game Flow (Technical)

Unlike Flash game programming, in Unity there is no fixed order in which your game’s objects are created. In Flash, I create objects as and when I need and doing so lets me determine the order in which things are ‘created’ in the game. For example, I have to first create my map before I go on to create the enemies because the map stores important unique data like ‘number of waves’. Without knowing the ‘number of waves’, other scripts like the WaveManager or enemy spawner do not know how many waves the level has and the game runs awkwardly.

In Unity, Game Objects in the scene are created in a random order. That means if my map is created last, every other object referencing the map will get inaccurate values and the game behaves unexpectedly or worse – crash. But usually it just produces unpredictable results – and people refer to them as bugs.

So it was very important to use something called Awake() to determine the priority and order of the objects I am creating.

Awake() is the very first thing that happens to every game object and by using a single object’s Awake(), I can use it to call other objects in a specific order.

This is how my game flows currently:

Subject to change as time passes

Since this is my first TD, I realized that there are some things I could have coded better. If there was one thing I would change, it would be to create my waves in WaveManager rather than SpawnEnemy, which might have solved my problem above about getting an enemy’s stats before it is spawned. It’s a bit too late to change it, so I left it alone.

Here’s how the game works: First, I get my Hero. He has very crucial stats I need to reference for my Turrets, such as turretDamageMultiplier. If he has 150% turret DMG, that means my turrets have to store damage values 1.5x their base damage. These values, once set, do not change when the game runs because they are base values. Any additional temporary multipliers will act on these base values, such as buffs which I may code, like x2 damage for 30 seconds, etc.

Then I create the map where unique data such as ‘number of waves’, background are set. This way, the SpawnEnemy script is safe to start generating the waves necessary for the level.

When all this is done, the game runs START() on all the other non-crucial game objects and the rest of the game flows.

The game has to flow in a very systematic approach so whatever happens is predictable and having a clear flow chart will actually help me in debugging to know what went wrong and trace the problem as close as possible to the source.

Game Flow (Design)

Now that the technical part is over, I have reached the stage where the game is starting to expand outside of its play area. For example, the introduction of multiple maps to play means I need some sort of level selection screen or menu.

For the past week, every thing I have coded, drawn or animated is reflected in one scene(or one screen) – the Play State, a singular scene where all the playing occurs.

There are other ‘screens’ I intended to introduce to the game, but only when the game really needed them. I don’t want to pre-create screens that are outside the current scope. Such screens include:

  • Main Menu screen
  • Game Over Screen
  • Level selection (medium feature)
  • Statistics screen
  • Skills / Upgrade Tree screen (big feature)

In my previous blog post, ‘Making a TD Game Part 1’, I said that I had 3 game scopes, and now I am starting to actually implement features of the ‘Medium Scope’ – aka the things that are ‘nice to have’ in the game, but not necessary to make it playable. These are mostly content-based features, which are exciting to make, but jumping in too soon without planning can be disastrous, so I charted out briefly how the game states transition from one to another.

Like most design processes, they change with time

Again, I arrived at this chart after analyzing other games and how they flow. It was pretty fun to go to some games I played and restart, looking at how they introduce the player to the different ‘screens’ and what order in the game they appear in. I feel games are better off gradually show more stuff to the player rather than overloading them with so many screens, especially in my game where it may have the potentially to overload players when they finish a level and suddenly there’s up to four different buttons that take them to four different screens. This can overload and confuse the player – which buttons takes them to the next level? What do they press if they want to replay the previous level, etc has to be made obvious.

I did this unlocking design mechanic in my game OldStory and the longer players praised its design, saying that it was great to have more content unlocked as you got deeper into the game. It’s like when they think the game has nothing left for them to do, suddenly a whole new feature and range of options are unlocked and it’s exciting.

The following is just my opinion, but when a player just started, he isn’t interested to see everything your game has to offer. He first wants to learn how to play the game. And only when he becomes good at it does he start to want to explore and want to learn and see new features. Content is best generated only when it is needed. Which brings me to my next point.

Designing the tutorial…if there will be one?

Long tutorials like the one I wrote above also bore the player!!!

Rather than using words, visuals or even animations are great, but take effort to make. I would normally try to use as little words as possible because the truth is that most players will NOT read your tutorials. Even as a player myself, I skip games with super long text and tutorials. That’s why my game literally has no tutorial. The first form of a tutorial is actually in an optional-to-read text that can be read at any time. I put somewhat useful tips there, but for important details, I make it clearer.


The first compulsory tutorial I added is a quick animated popup drawing attention to key elements of the UI which appears only at the 7th wave, giving the player enough ‘breathing space’ to explore the game on his own.

I also lock and hide unecessary elements of the UI when the game first starts. The game displays only 2 turrets out of the 10 available when you first start the game. The minimalism effect worked really great because I could focus on what was important – the two turrets I can build. (Even the starter Hero character is locked from the start when you first play).


Notice I also color coded the ‘cost’ text to turn red when it is unaffordable, just in case the player attempts to try to build the second turret and wonders why the button doesn’t work / the turret doesn’t build.

Of the two starting turrets, the second turret is too costly to build. I intentionally made it cost 150, and give the player only 100 starting gold. This is because I want the player to build the first turret – Basic Turret – to first understand how turrets work. The second turret has advanced properties (multi-targetting) that the player may not understand yet until he progresses a few waves later and earns enough to buy the second turret.

I somewhat learned this from a Plants vs Zombies video I watched where the designer explained that he made Sunflowers cost only 50 Sun and Peashooters costed 100, which somewhat ‘forced’ the player to build more Sunflowers so he can farm more suns, which was what the designers wanted players to do because he noticed playtesters skipping sunflowers and putting peashooters when they were equally priced, causing them to eventually lose the game iirc.

While my game doesn’t have that kind of penalty where you lose if you don’t build the first turret first, I want the player to first learn the basics before moving on to using turrets with special traits.

So the next time you play a game like PvZ, you might look at the cost of towers and think those numbers were made up randomly by the designer, but watch – some games put a lot of thought into these seemingly ‘random’ numbers.

Victory Screen


With the game getting in the process of being balanced, I added a non-quickplay mode which has limited waves and is the foundation for the game’s main mode of play. And what happens when the player wins? There was nothing rewarding the player for the past 10 days! That’s why I need a victory screen!


I adapted it from my Space Shooter game’s victory screen and modified it for this game. I went from ‘concept art’ to ‘sub-par end product’ in like a few minutes, then spent the next few hours with implementation. Based on how the game goes, the victory screen will change to display different things.

Game Balancing Pt II

I spent an entire night figuring out how to make the values in the game work.


I enter my values in red boxes and this updates a very long table containing every single detail about a particular wave. On the top left, the values I can set are enemy base HP, base enemy count, base enemy gold, and powerHPG which I will talk about later. The blue boxes indicate the creep’s base HP increase from the previous wave.

On the right, I set the ratio of DMG to Gold for the turrets, and the player’s starting gold. Starting gold seems insignificant, but watch how it affects the graph below.


Starting gold looks like something that simply affects the y-intercept, but a high starting gold can actually turn the tide from a difficult early-game to a super easy early game. It turns a bell curve into a linear one. It is simply one of the most overpowered values that is used for early-game difficulty adjustment.

But it is a very hacky way to change early game difficulty so I avoid using it.


powHPG is a very important value in this game. It stands for power of HP to Gold. It controls the difficulty curve to a large extent and when doing my balancing, I extensively fine-tune this value because every other variable’s effect is largely based off it.


gold = Mathf.CeilToInt(Mathf.Pow(finalHealth, 0.9f) + 1

powHPG goes into my formula for calculating creep gold reward and a tiny change will greatly affect early or late game difficulty. There’s also a staggering effect in the second picture which is not caused by powHPG, but by the enemy count increment variable, which increases the number of enemies spawning in a wave by 1 every X waves:

Enemies spawned increases by 1 every 10 waves, up to a maximum of 12

This staggering effect creates a difficulty bump in the game every X waves that gradually eases back to normal difficulty (because more enemies = more gold, and the effect cancels out the initial additional difficulty boost).



By also adjusting powHPG, I can decide how difficult early game vs late game is. A higher powHPG has the tendency to make early game battles comparably harder while a lower powHPG increases the difficulty of the late waves more.

The problem I had was trying to balance both of them out and it took a lot of value setting and testing. It was such a pain because I was actually discussing with my friend what the best way to handle this was.

Despite having a lot of variables at my disposal to tweak, early game difficulty was always too high. You might think ‘why don’t I just decrease the starting HP?’. Well, decreasing the base enemy HP was a perfect solution for smaller maps, but didn’t work very well on big maps with 60+ waves because the difficulty scales up too fast regardless of how high or low I set the base HP as.


My current solution to fix early game difficulty being too high and fixing late game difficulty scaling up too quickly on bigger maps may be to set powHPG individually based on the map’s size and level. I noticed that a powHPG value between 0.8 and 0.9 work best.

Green = 0.8powHPG | Blue = 0.9 powHPG

A low powHPG value is used for early game smaller maps because there is a low threshold where gold dropped by enemies falls short of gold required for damage upkeep. This means enemies can afford to grow more in power per wave, and the easy early game is great for beginner levels with very few waves.

A high powHPG value is used for bigger maps which have more waves. A high powHPG eases the growth of enemy difficulty more gradually by allowing late game enemies to drop more gold. This makes it easier to reach and survive higher waves, but can have an added negative effect of making early waves harder – I intend to counteract this effect by introducing skills that increase the player’s starting gold and decreasing the cost to build starter towers. These skills will be more viable late game where I may use maps with higher powHPG.

Other solutions I explored were altering the health Multiplier increment per wave, but I wanted to fix those values at a constant 1.2 (+20% HP per wave) and changing those are a last resort.

The reason why I spend a LOT of time and math balancing was because my previous game had literally no balancing work – I put it off to the last minute and the balancing problems became too late and complex to fix.

After spending so much time on balancing, I hope I do not have to tread this territory again, but I think over time, the game will change and have to re-balanced, but this should keep the game pretty balanced for the moment.

Once I have decided on the values, I think this will be the last thing I will do before I step out onto officially starting implementing content from my Medium Scope!!!

Anyway, I am coming to the end of this post, so I’m putting miscellaneous pictures that I don’t really have much to talk about.

Behind the Scenes

Here are some other behind the scenes work.

(Coming Soon) Skill Tree?


Also a concept idea of what I may be adding soon ^

Time flies

Time has flown since the start of this game. 10 Days felt like a long time since the game was in its infancy.

Concept Art?

I am definitely looking forward to what this game will result in a week from now!

Making a Tower Defense Game Part 2

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.

Tower Variations

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.

Bullet Sprites

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.


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:


LarvaAnim Larva

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.

Game Balancing


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.


…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.

Creating a Tower Defense Game


It’s been awhile since I last blogged about my game development adventures.

I actually made lots of progress on IdleHeroes but it had just too much to blog about. Moving on, I’ve started a new project – a tower defense game!

I’ve always been a fan of TD games. I still remember my first TD game and how fun it was. It had always been my dream to create a TD game.


A dream

My first TD game was made in VisualStudio back in 2010. When I first learned how to type in code and still struggling with fundamentals, I attempted a simple text-based TD game. It had no graphics and didn’t really have anything. I re-enacted what it resembled in photoshop:



TD Game 1 (2010)

The second TD game I made was with FlashDevelop and Flixel, sometime during the development of Introvert in 2012 while I was still studying.

swtd ui.png

TD Game 2 (2012)

It was however, short lived. I ran into bugs and the game crashed non-stop. Frustrated at the programming aspect, I gave up.

Years later, I returned to Flixel sometime in 2014. I was tasked to make a TD game for a friend. He convinced me that I didn’t need much programming – he just wanted the art. I did however, code various features – pathfinding, tower placement, upgrading, enemy waves, shooting and killing. It went surprisingly well.

My art quality had also shot up since I first started Flash game development, combined with my new WACOM tablet. This TD was simple and wasn’t my personal project so the moment it was completed, I didn’t bother. It was a one-week project kind of thing and I just wasn’t ready to take up the challenge of making a full TD.


TD Game 3 (2014)

It is now November 2015. Picking up Unity earlier this year, I developed IdleHeroes. It features some of my best art to date, but I have now put it aside because it spiralled out of control. Now I want to try a shot at making a very simple TD game. Nothing complex, but something simple and fun.

I have learned a lot from trying to make a game overcomplicated and necessarily complex. It really bogs down the game and it gets very tiring. In fact I think I get overambitious easily. I just love making games so much that I form too big an ideal of what I want it to be, so I have to focus at a really small scale, then work on improving it once I have established the basics. And this simple development is the style I will use to develop the game.


This is also the first time I am writing a detailed scope covering what this game will have and will not have. I have 3 scopes:

  • Tiny Scope – at bare minimum, this game is playable (1 month development time)
  • Medium Scope – add some of my unique ideas (2 months+ ?)
  • Impossible Scope – adds all my crazy ideas (??? months)

This is more to keep myself in check so things don’t go out of hand. I can get really crazy when it comes to developing a game I really like that and working alone means I must be careful not to bite off more than what I chew.

So onto the development…

Now that I am more experienced and my skills have improved with better art and programming, hopefully I will meet with better success as well.

This is the game after 1.5 (2).gif

First attempt at top-down walk animation went pretty well

It doesn’t look like much to some, but honestly to me, it is fantastic progress. People often look at all the cool games out there and don’t realize how difficult it is to make a game. I have every function of a basic TD prototype working, and that is very important. From the enemies being able o be shot at when in range, to the turrets’ upgrading when you get gold…those are really important.

It actually felt like I took a long time, but only 36 hours had passed since the start.

And it has been a long time since I did something super exciting. I was really excited working on everything!

I had to restart from scratch because I had no knowledge of TD programming in Unity. It was like IdleHeroes all over again, reading tutorials and learning.

Here’s a closer look at the game so far. Mostly placeholder graphics are in place. I can’t wait to draw the official map!


The enemies are hiding from my screenshot

The game at this stage contains:

  • 1 Tower Type that can shoot and kill enemies
  • 1 Creep Type that can spawn in waves
  • Lives system
  • Gold
  • Towers can be upgraded and sold
  • You can select a tower and the panel displays its stats and stats update when upgraded

These are all the fundamental basics of a TD game and it was a priority to get these done because I wanted to gauge how long this game would take me to code, and also I wanted to get a feel of how difficult it is.

Needless to say, it all went very well. And now that the basics are done, I can move on to the fun part of adding more tower types and variety to the game. In fact, I already begun working on some graphics!

Take a look!


A lot of people don’t understand how difficult it is to make a game. It involves a lot of things and not just the common ‘programming’, ‘art’ and ‘design elements’.

It’s about making all of them work well together to create a  game that is:

  • Fun
  • Looks fantastic
  • Run smoothly

All of the games I made lack one or the other. I’m just more of an artist than a programmer or designer and it’s challenging to make a game alone and handle everything from art to programming. They are two opposite ends of a spectrum. I really wanted to get a job so I can work in a team that is capable of creating a game with all those 3 key elements above.

Oh and apparently, my game wasn’t the only thing crashing xD


Unity crashes a lot too!

I can’t wait to see how this game will look like in 1 week! Although I don’t really set a deadline for my personal projects, I don’t like it when things drag too long. I really want this game published and the key to that is making something that is simple yet fun.

OldStory published!


The picture above is the reason why I am writing this post. But before I talk about the picture above, I’ll start by telling you a wonderful little journey I had before I published OldStory recently.

It all started 3 weeks ago. I received an e-mail that said I had a private message on my Youtube account. It was unusual because I never thought I’d ever receive any messages. The last time I used my Youtube account was months ago, to upload a trailer and gameplay footage of OldStory.

I checked out the message, and it was from a random guy who asked if my game had been completed as he looked forward to trying it as he was an old player and like me, wanted to relive the experience of playing MapleStory.


His last sentence made me really sad because I had abandoned OldStory long ago. After attempting to publish it on NewGrounds sometime in February, it was removed shortly after. I suspected it was due to copyrights, but after confronting them that there were other similar flash game simulators on their portal, they did not get back to me, and I lost the will to chase them about it. I left OldStory in the dust after that nasty experience.

So when I read that Youtube message, I felt sad that OldStory had gone to waste just like that. Two of my friends really enjoyed it, and I hoped that other people would enjoy it too. So after mustering up lots of courage and willpower, I headed to an alternate flash game portal, Kongregate.

I nervously uploaded my game on Aug 5. It was the moment I had been waiting for for so long. I had lost quite a bit of hype because so much time had passed since I had last seen ‘OldStory’, but I was still eagerly awaiting what comments I would get from players.

It’s kind of interesting how it all turned out. I never was the type to make a Youtube account to upload videos or even make a wordpress. But in the end, it was stepping outside this little comfort zone that made this a wonderful experience. I never thought that a random youtube message from a random guy would actually change the fate of OldStory, a game project which I had long forgotten about.

That’s the power of the internet, that you can be influenced by someone miles away.


You can play the game by clicking here.

I wanted to write a post when the above happened, but couldn’t get the time to. Ultimately, it was when I received another wonderful private message on Kongregate did I actually feel like I had to write something, and the contents of that message is the picture at the beginning of this post.

It was the best comment I had ever received. In the past few days, I was quite demotivated because the game had received a much lower rating than I had anticipated. The players seem to come from the extreme ends. There are those who really enjoy the game, but at the same time I get equal amount of messages from players who didn’t enjoy it.

It is comments like the one above that give me the encouragement to make games and make my day. I never expected anyone to actually reach 100 new Game Pluses, because that takes a significant amount of time invested, so based on that, I was glad that there was someone who really enjoyed the game and I am grateful that he took the time to write such a heartwarming message.