It has been awhile since I last posted something, but I’ve not been out of touch with game development. In fact, I’m doing something related to it every day.
So what have I been doing?
I’ve been working with a team of game developers at a company that develops educational games.
I’ve been very busy and truth be told I could barely get the energy to continue working on my personal projects and games. I was really depressed. This internship is pretty fun but it can be very tiring and I have very little free time compared to before which ultimately eats into my sleep and my health takes a hit. Juggling work and my personal projects is tough (and hey, I need time to relax sometimes too you know). It took me several weeks to adjust to this lifestyle, but I believe I am now back on track!
Earlier this month, I was deciding whether to create a new game, and what game to create at that. With Web Player shutting down and WebGL far from being a stable platform to build games on, I realized that now is the perfect time to make a mobile game. Flash and web games are growing less popular by the day, but I decided to do one final push to put a game on the web. I was thinking really hard what I should do.
I looked up my old project, Idle Heroes, and finally decided that I should wrap it up and finish the game.
It was a game I started making when I was still in the army, back in 2015. I worked on it for two months before my army ended and I stopped.
1 year has passed. But now I have decided to finish what I have started.
This was my first Unity project, and though I had used Unity while I was studying in school, I barely did any programming then and barely touched the game engine itself. I took on the role of an artist in my final year school project and the programmer was the one who did everything in Unity.
So yea, it was only on April 2015 did I officially start to learn Unity and started this project, Idle Heroes.
It’s funny looking back at work you did one year ago because you’re going all “I wrote that code? That’s so inefficient!” Yes, I was spending a lot of time cleaning up my code and optimizing it for mobile devices.
‘Idle Heroes’ is no longer the game’s name, but it is still the project name and I will refer to it as such for consistency purposes. (I will show the new game name and main menu in a future post.)
What is Idle Heroes?
Here is a video (gif) taken during the first week of development (therefore, no animations yet). It demonstrates the game’s core gameplay effectively.
Idle Heroes is an idle incremental game where you hire heroes and upgrade them in order to slay increasingly tough enemies. As you progress to higher zones, you meet new enemies and fight bosses. The gold you gain can be spent to upgrade your character or in the shop to further boost your gold or experience gain amongst other buffs. Each character is a unique class with a set of unique skills which can be upgraded as you gain experience.
As you slay bosses,you also gain gems. Gems are used in very powerful upgrades in the Secret Shop. If you beat the final boss, you can ascend and you will restart the game, but gain a huge boost in power as well as gain access to Guardians, mysterious powerful beings who grant you special powers to help you run through the game quicker and more efficiently.
There are 3 + 1 characters in the game and you unlock them with time. Each character has three tiers.
You can advance into a higher class if you are powerful enough. For example, the warrior advances from a warrior into a paladin, which enhances his tanking abilities.
If you don’t understand, it’s okay because here is some information about the characters.
The warrior is able to attack enemies up close.
Characteristics: High health and defense, his skills boost party members’ defense and when he advances to a higher class, he gains ‘orbs’ when attacking enemies which can be used to increase his defense even further.
The priest casts spells and magic and shoots magic bolts at monsters.
Characteristics: High mana but low health and defense. He heals party members and casts various buffs to boost allies’ offense and defense prowess. He is more of a support class at first but he can advance into Wizard later on which boosts his offensive abilities. (BTW, the animation above is sped up. He doesn’t attack that fast in the game.)
The thief throws shurikens at the enemy from a distance. When he advances into a Ninja, he can inflict poison, which gradually drains the health of monsters.
Characteristics: Average health and mana, has high attack speeds and good against bosses. He has evasion to prevent getting hit by an enemy’s ranged attack and has a chance to steal additional money from monsters. His buff increases the critical rate and damage of all party members.
Last but not least, the Warlock. He is an unfinished character. He is a very powerful end-game character and cannot be hired with gold. He also has an interesting storyline, being once a human until a mysterious curse turned him into an evil Warlock. Hint: You have to fight him in an epic boss fight.
Characteristics: High health, mana and damage but low attack speed. He can cast various auras on his party members. The stat boost depends on what aura he is casting.
I initially intended to have only the first 3 classes in the game, but after making a Warlock boss, I felt that it would be cool that once you defeat him, you get to learn about his backstory and eventually get to hire him as one of your party members. It made the game and story a lot more interesting. A player who played my game was excited to hear that he could actually choose to save the Warlock (in a story dialogue) and in doing so will be able to hire the Warlock.
I think this character is very interesting and based on more player feedback I might eventually add him in the game. For now, his skills and stat balancing is incomplete and I decided to take him out of the game for now.
This game is pretty simple and each character only has 3 states:
While I had initially used Unity’s default Animator class, I realized that it fell short of what I wanted to achieve with my characters.
Because my characters could advance and they would switch sprites, the Animator class required me to use 3 different idle animations, 3 different death animations and 3 different attack animations. It is a limitation of the Animator. I didn’t want to just copy paste the animations because they are all just the same action, just repeated with different sprites. So I made my own animator class and called it SpriteManager.
Here, I can define which sprite the character should use.
It’s actually pretty nostalgic because it’s how I used to animate in Flash. Aside from animations, I also had to consider how the different class tiers would look.
When designing the thief, I asked two friends to rate the colour schemes. I wanted them to rate and arrange them on two criteria:
- How powerful the character looked
- How nice the character looked
I asked them to rate each character from 1 to 5 on each of those factors (you can see I marked the ratings separately in RED and BLUE in the image above)
The purpose was that I wanted “strong” colours for the higher tiered thief, and “weaker” colours for the lower tiered thief. I’m just going by feeling and observations when I say this but I felt that desaturated colours make the character look weaker and saturated colours closer to the reddish tone look more powerful.
The game has different ‘settings’ and ‘themes’. You start off in the grassland and eventually progress through higher level areas like the Forest and the Swamp. Each area spawns different enemies.
You can see here that I did not do anything different from other games. Like in most Idle incremental games, the scenery changes every 10 levels.Most games have areas like Desert, Antartica, Forest, City, and other really normal typical designs.
I have to admit, I wasn’t too creative with the area design for the first few areas, but I decided to do something different for the last few areas. I scrapped out some of the normal areas and made areas like ‘Outer Space’ and ‘Candyland’.
Those areas obviously don’t make much sense even in the game world (how is the mage breathing in space without any helmet?), but my friend who playtested my game said his favourite was Candyland because it was something special and unique and the monsters were special too.
I think I put a lot of love into the monster and area design for Candyland.
I even made the area boss a giant cupcake! I must have been high when creating these graphics because just for this area, I made a secret boss which is a chocolate yeti. I hope players find him!
The idea of chocolate yeti came when I drew an ice yeti and accidentally hit the colour invert button. This caused my yeti to change into a brown tone. It was amusing to me so I saved it as an image and named him ‘Enemy100’ which was an arbitrary name. It was later turned into an official enemy in the game and he received a proper name (and a candy cane).
Candyland and Space are my two favourite areas in the game. I had the most fun drawing them. I like futuristic things like Star Wars and such, so I knew I had to include a futuristic themed area. It was so delightful drawing these that I had more monsters in this area than any of the other individual areas had.
Just of note, each area has roughly 10 monsters and there are 10 areas. I didn’t go to each individual area and do a count, but this roughly means that there are over 100 enemies in the game! This figure is excluding the 20 area bosses and another 10 unique bosses (like the Guardian, Choco Yeti and other storyline-related one-time appearance enemies).
You might be wondering why the monsters do not have a ‘HIT‘ animation or why the monster only has a simply scaling idle animation. Am I just LAZY? Did I just simply could not be bothered to create more animation frames?
The reason is this – I simply do not have the resources to commit to animating several states for each monster, for 100+ monsters. It would require the game to be structured differently (maybe more enemy oriented, to have less enemies but make them have more detail.)
To be fair, some of the special monsters and bosses have attack animations, and it’s what makes them really stand out from the rest so people know they are fighting something significant and they retain a kind of special ‘status’ which differentiates it from even the area bosses. Currently only the storyline enemies have an attack animation and I intend to keep it that way.
At this moment this game only has 1 artist, programmer, designer and they are all the same person. It’s a lonely one man show and while I would want my game to have all these nice things and animations, sadly there is a limit to how much I can do in so much amount of time and I have to prioritize what goes in the game and what goes in the bin.
These are compromises that I have to make all the time and some of these decisions are not easy to make, such as having to scrap an entire equip item looting mechanic because some things look good on paper but are actually really unrealistic or just plain bad in actual implementation. (more on the item mechanic below)
If I had all the time and resources and manpower in the world, sure I could idealize the perfect game to make but I can’t. In making games, I learned that I have to exercise a lot of self control because if I don’t, I tend to go crazy and start adding content and features that the game was not initially designed for. Many people may think it looks trivial, but it can have very serious consequences.
The most painful decisions to make is to have to scrap something that had gone through so many iterations only to realize that it cannot be done and you have to acknowledge that despite all the time spent, something may just end up going out the window. But if there’s any consolation in that, it’s that you will (hopefully) be a wiser and more experienced person to know not to repeat the same mistake again. I think I talk about these things once in awhile in my posts and sometimes it is these invisible processes which most people do not get to see. Hopefully this didn’t come off as a rant, but if it did, the next time you see a long paragraph without pictures…you may want to avoid it haha.
Anyway, moving on…
As mentioned above, each character has skills. Above is an example of ‘Wisdom’, a buff that increases EXP gain for a short time, an old version of the ‘Weaken’ skill, which weakens an enemy, and ‘Dragon Skin’, which raises party members’ defense. The game has about 12 active and buff skills.
Skills in the game fall into three main categories:
- Active Skills (attack the enemy with huge damage or multiple attacks)
- Passive Skills (give you a stat)
- Buffs (gain a boost in a particular stat for short duration)
Above were pictures of two buff skills when they were a work in progress.
The challenge came when some of the skills were really special and required me to do a few conditions. Take the Resurrection skill for example. When cast, it resurrects dead players, and restores some of their health (depends on the resurrection skill level) and gives them a protective buff.
This meant that Resurrection was not only was an active skill, but it also classified as a buff skill. It was tricky to code because the way I designed the skill structure did not cater for a skill that fell into two categories. But I managed to pull it off in the end. This is the same for drain, a passive skill that has a x% chance to cast a buff – is it categorized as passive or is it a buff?
Proper categorization is important because it affects a lot of things, such as whether the skill is able to be added to the skill tray or not.
The skill tray is where all active skills are displayed and the player can click on them to use them. Later on in the game, you can purchase AUTO-CAST which makes your skills cast themselves once the cooldown is over, a feature I felt was necessary in an idle game.
The skill tray was originally a scrollable interface which scrolls endlessly to the right when you acquire more skills, but I felt that was bad design and instead removed the scrolling while making excess skills roll over to a second row. To reduce clutter, skills on auto cast don’t get added to the skill tray, so even after the double-row implementation, the skill tray never leaks to the second row now.
My favourite skill is an attack called Eviscerate.
It decreases a percentage of the enemy defense and deals high damage. The skill has a cooldown of 1 minute, but each time you kill an enemy, its cooldown shortens by one second.
I used TexturePacker to pack my sprites before I learnt of the Unity SpritePacker.
Early on in the game, monsters dropped loot and you could collect basic equipment to upgrade the characters.
However, the design was very confusing for playtesters and they did not get the idea of the drop mechanic. So I scrapped it. I was kind of disappointed because quite some time was spent on this feature, but the game was better without it. I was not skilled enough then to make a good design work together with the UI and it was a nightmare on mobile trying to display this information to the player.
When the characters attack the enemy or are hit, damage numbers should appear over them or the monster.
While I had worked with bitmap fonts in Flash before, it proved to be something slightly more tricky to do in Unity. The font required alphabets because I had to do number formatting for big numbers (eg 1,200,000,000 displays as 1.2T)
When attacking, damage is displayed which floats up and fades off. In fact, I can take it a step further by making the number bounce, making it bigger as it first appears then shrink back as it floats up. Most standard web games don’t do this, but you can see that in some MMORPGs and takes the text quality up a notch. This was something I learned at my company 🙂
Because the damage numbers can be pretty resource intensive, there is an option to turn them off in the settings. This is true for particle effects as well which has a toggle on its own.
Speaking of particle effects, I went a step further and added a blood effect on players recently.
On the left is a continous blood effect which could be displayed when the character is low on health but it looked weird. On the right is a burst of blood that only appears when the character gets hit. I also changed the shape so it looks more like droplets than just circles. The blood effect was an idea by a friend that I thought would not fit well with the game graphics, but I made it cartoony and it ended up looking pretty decent and somewhat comical. This was actually a very interesting suggestion.
The Ascension System
This is a very huge feature but in summary, it basically resets all your characters’ stats and you start over from the beginning. Any unspent gems you have collected are converted into Enchanted Gems.
And as you can see, they give really huge bonuses to your character when held in possession. And not just that, they can also be used as a currency to purchase powerful upgrades from this guy:
Yep, he is the Guardian and when you meet him, you have to first defeat him as part of the storyline before he shares his powers with you. The fight takes place in a unique zone called ‘The Crossworld’ which you cannot access through normal means.
If you win, you get to own the Guardian and upgrading him will improve your prowess. Of course, this means sacrificing some of your own power since spending the Enchanted Gems means you get less boosts from it.
There are plans to have more guardians in the game, each one offering different abilities. Currently the other guardians are just colour reskins of the first one but I may add new abilities if the game gets enough attention.
When I make a game, there is a high chance that you will see achievements in it. It is not something I will leave out of my games, unless it’s a simple enough game. Even my first flash game, which was a platformer game, had it.
In a lot of incremental games, they tend to duplicate achievement icons. It’s understandable – you have 100 achievements and drawing 100 icons is a lot of effort. It also makes it easy to identify what achievement it is. This game currently has 120 achievements and each achievement gives different rewards.
I don’t know if it helps, but I actually went to try and make it such that even when I duplicate the icons, I at least change some stuff like their saturation levels and hue so no two icons are exactly identical. The better achievements have more ‘powerful’ icons while your starting easier achievements are more dull. It may not look like it but just adding a little extra detail takes time and effort.
The achievements in this game are probably the most complex I ever made. There are two groups of rewards, one-time rewards and passive bonus rewards. One-time rewards are give you huge amounts of gold/EXP for achieving something. Passive bonus rewards are given by harder achievements, but they last a lifetime! Here are some of them (with arbitrary numbers)
Examples of One-time rewards:
- Gold +1000
- Experience +5000
- Gems +5
- Enchanted Gems +1
Examples of Passive rewards (these are permanent and last through ascensions):
- Gold gain +2%
- EXP gain +3%
- Hero damage +4%
- Hero HP +5%
The rewards are defined in the Achievements class.
As you can see it is possible for an achievement to give 5% hero HP and 3 enchanted gems (combining both passive and active rewards), but for simplicity’s sake and not to confuse the player, it is best to limit one type of achievement to give one or two types of reward at max. It keeps things organized and creates interesting gameplay like “the boss killer achievements give gems, they should be prioritised if you need gems, but if you need gold you can farm the other achievement”.
Each achievement’s rewards are entered in the editor, (see the green and pink fields above).
The other fields are set in the script because it’s more tedious to go through each item and enter their names manually.
The whole achievements system is pretty wacky. I categorized them by achievement type to keep them neat and to keep them displayed in a sorted and orderly fashion in the game’s UI. It also makes it easy to add a new achievement tier without messing up the order.
But because there are so many different tiers of achievements and different reward types, something can easily go wrong if you are not careful. For example, mistyping dmgMult *= 105 increases damage multiplier to 105x when it’s probably intended to be 1.05x. This really happened by the way, I kid you not when I say my damage inflated suddenly after earning an achievement.
Thankfully, there is a panel that summarizes your passive achievement bonuses, which is actually as useful to players as it is for me to see what the heck went wrong when something goes wrong.
The thing about this game is there are multiple sources of stats. For damage as an example, there is:
- Achievement damage bonuses
- Shop item damage bonuses
- Guardian damage bonuses
- Enchanted gem damage bonus and
- Party damage Buffs
This is why it is actually very easy to screw up. They all have to work well with each other to keep the game balanced and working as intended. In my next post I will talk about the hero class and how all those different boosts work with each other.
While this game did not require a loading screen initially, loading times significantly increase on mobile devices and it required me to have one. I made this today:
A random tip is displayed when the game is loading. This screen is disabled on WebGL though as WebGL does not support multi threading. I’m not an extremely technical person, but from what I understand, how it works is that the game runs the loading screen on one thread and is asynchronously loading the game at the same time. The loading screen fetches the progress of the other thread and displays it on screen. However at the moment, WebGL cannot run two threads at once so it will wait for the loading screen to finish loading before loading the game scene. Thus, it defeats the purpose of loading a loading screen if it cannot load the main game scene simultaneously.
Game balancing has always been something important. This being my first game that had a lot of stats and complexity, I learned how to use excel and its formulas. Later on, you’ll see some of the things I’ve done with it (plotting graphs and using those data to compare the power of the different classes at different stages in the game.) But for now, here’s a simple screenshot of the basic math when the game was in early development.
It calculates the health of the enemy and how much time it takes to kill it. Then, it uses the gold gained to simulate upgrading of your damage, and with the new damage, writes how long would it take to kill the next enemy. My friend wrote this, but it helped me get to see the power of math and excel and made me see how useful these tools were in game design. He even colour-coded the time column so one can easily see where the values are at their lowest/highest – aka where progression peaks and drops.
This gameplay was inspired by other idle incremental games, like Clicker Heroes and Tap Tap Infinity. I wanted to go with a different approach – instead of having so many heroes, I wanted to focus on having only a small number of heroes and focus on their character instead. In Clicker Heroes, each hero isn’t very unique and to achieve maximum DPS, I found that I only needed to upgrade the top 3 strongest heroes. So I was only upgrading a maximum of 3 heroes at any one point in time.
This is somewhat applicable to another game I played as well. In Tap Titans, you always aim to upgrade the most powerful character until you get stuck and eventually return to upgrade previous characters. But at any one point, one character is contributing 99.9% of your DPS and the other characters are rendered obsolete.
There is of course nothing wrong with that design. I’m not saying it’s bad or anything. They work really well for Clicker Heroes and Tap Titans and they are really good games and my game likely will have similar problems. But I personally wanted my characters to stand out and have some depth, so I gave them mana, skills, unique abilities. Additionally, instead of making the enemy just a dummy for you to hit, they can fight back! I also added a storyline which reveals more about the game’s world as you progress.
I don’t know if this idea will work well, but it is of course a risk I took when I decided to walk down this path in directing the game’s design! You don’t need to look hard to pick out the flaws in my game’s design, but I’m still learning and my next game will definitely improve! I’m pretty sure there may be other games that may have done this. One of the games that has done this is Tap Heroes, which I drew inspiration from too.
It’s a very simple game (the characters don’t have skills and there is no ascension system or any complex features really), but it inspired me.
How long have I been working on this?
The short answer is… 1 year.
But that includes the time which I did not actually actively spend on making this game. I did not really dedicate a whole year to make this game… that sounds exhausting. So for a more precise answer, I looked through my update logs.
I write down any changelogs in the game and I keep track of every significant and here’s what I got from my change logs. The changelog is viewable in the game to anybody who plays, so they know what has changed since the last version.
Anyway, here’s a summary of the significant dates in the project timeline:
- 11 April 2015: Idle Heroes created
- 11 June 2015: Pushed a final update and stopped working on it
- 13 May 2016: Revived the project
- 28 May 2016: (Now)
So basically, I worked for two months, then stopped.
Then returned to work on it in May 2016, till now. I suppose if I were to count the actual production period, excluding the time which I did not work on it, it would be…
3 months spent to make this game!
It was a much shorter than I expected. I felt like I had worked on it for ages.
For comparison, my Tower Defense game was made in 10 weeks.
When I create my games, I often capture many screenshots of my development process. I don’t take screenshots all the time, but when I notice something really cool and worth talking about in detail, I take a screenshot and save them to talk about in my blog posts. I will look through my images as I’m writing. I even take videos sometimes.
Some of these screenshots are really interesting to see and I can’t wait to share some in the next few blog posts!
I’ll also write more of the behind-the-scenes technical issues I faced when trying to run this game on mobile and basic stuff I did to try and optimize a battery-draining and turn a slow, unplayable game into something playable. I’ll perhaps also talk about other stuff like texture crunching to reduce memory consumption on WebGL.
There’s also other features in this game I want to talk about that I was unable to cover in this post, like:
- Offline progress
- Character/NPC Dialogue system
- The Journal Book
- Hero Stats
- Buff system
- Main Menu design
- Level 101+ Area Design
- Clicking/tapping mechanic and upgrades
- How all the systems/reward mechanics stack and work together
But for now, that’s ALL!