YYZ

This is the 2-month anniversary of my game. Exactly two months and 1 day has passed since I started making this game and this post will cover what I have done in the past week.

Updated tutorial

In case I have not shown a screenshot of the tutorial and keyboard settings I drew, well, here they are! I personally love the Shortcut Keys information pane

It took 2 hours to draw the keyboard settings because I was trying to get the placement of all the text right and also yeah, I wanted to do something colourful. But I spent most of the time trying on alignment and moving the different buttons and text around to find the best placement to display the information in a tight space.

Buildings that summon monsters

I added a new building type to the game, an underground bunker. This is one of the coolest things because it actually aids balancing rather than hamper it. This mysterious building has its doors locked at first, but you can open it and it will let out creeps!

This makes the map harder but more creeps means you get higher scores and EXP.

This is more for hardcore players who want a challenge. This was not as easy to code as I thought. This was identical to making a duplicate map spawner – this spawner spawns a fixed creep type and adds a fixed number of creep spawns every wave. It also has its own pathing and I now track enemies on map separately – normal enemies and bonus enemies from building spawns.

As a bonus, if you win the map with this added challenge, the underground bunker reveals and unlocks a secret map – Area 52.

I didn’t call this map ‘Area 52’ for nothing. It is definitely one of the coolest Challenge maps I have drawn.

Epic Map #4

I began production on the fourth epic map. (This game has 5 Epic Maps in total and the fifth one is the last level). I toned down on the special effects for this map. However, this map has quite a few story panels and the runes at the center will eventually appear. This map is pretty challenging since it is the first Epic map to feature four entrances. But take a look at the next map.

I love big, epic things. If that wasn’t obvious enough while making this game, it probably is now:

Behold, the biggest map in the game. Four times the size of a normal map. It’s hard to imagine the scale because every picture in this post is the same size -_-.  The screenshot above was resized just enough to be able to fit within the blog window, so I had to put a few creeps and turrets on the map for scale. To view the entire map while playing the game, you need to zoom out to 0.5x ZOOM, which makes everything look really puny.

This, this is the only one level of this size and it is the final level. I am finally here. It took forever to implement the last few levels. This is probably one of the last few fun things to actually draw for my game. After this, I would be mostly polishing, sounds/music, and a lot of the important, but not so interesting stuff: Bug fixing, Testing the game and Balancing. These are the stuff that I don’t usually talk about because there isn’t much to say about them when I work on them.

I had been saving the monstrous task of drawing final map to when I have inspiration to do something cool, and also to when I got sick of coding (which I have been doing plenty of the past few days – it’s just so exhausting).

I kept a notepad of what I wanted to do with the final map – accumulating all the cool ideas. It’s really overflowing with ideas that I got to tell myself to STOP or this game will never be done.

There’s something subtle about this map and it’s that it uses a new texture – I realize I had been using the same map texture for over 30 maps. Though I have to say, drawing such a huge map was a nightmare and not actually as fun as I expected.

It was extremely laggy trying to draw it on my tablet. Photoshop also takes nearly half a minute just to compress the map in each time I export it.

‘MagiCreep’

The final level also introduces the last creep type in the game. I didn’t draw him ‘just’ to get another creep type in the game. It came purely out of inspiration and I guess it’s what made him look pretty cool and different from standard creeps even though he borrows his basic shapes and features from one:

I can’t wait to actually see him in-game. His body is actually completely transparent. I called him MagiCreep because he looks very fantasy-magical like. Yup, only the visuals were inspired, not the name ideation. I had to make one up on the spot when giving it a name in the script and I went with MagiCreep because the default name is “Creep” and after donating all the cool creep names to my previous creeps, I simply ran out of ideas. Way to go, brain!

The Nullifier

I don’t think I talked about this in the previous post. The Nullifier is a turret I made. It has a special ability – it can convert any creep into a Normal Creep. It will lose its special ability, and its stats (speed, health, armor) will be reset to that of a normal creep. I think this kind of special things can be hard to do in some game, but thankfully my game was setup in a way that I realized this wasn’t hard to do at all. Because I use a single enemy prefab and switch between animation states depending on its identity, it turned out I just needed to flick a few switches and reset the creep’s initialization code to ‘transform’ a special creep into a normal one.

This code resets everything from its name to its core stats.

Crystals

  

I added a new currency called ‘Crystals’ this is ONLY usable in the last and final level. It isn’t introduced until then because it has a very special and unique purpose that players who reach Map 30 (the last map) will discover. Also unlike gold, you can’t get it from normal creeps – it would defeat the purpose of adding another currency if you could and it’s what makes this currency special.

I’ve also added special buildings that can harvest crystals from the “Crystal Spots” on the map.

Together with crystals, I added a new turret to the game. (not referring to the Mining Turrets above as those are technically buildings)

There is now a 13th Turret. The game had all along planned to have only 12 main turrets, from beginning to end. My intention from the beginning was not to have more than 12 buildable turrets in this game and that intention hasn’t changed.

This final turret cannot be built by the player and appears only in the final map. Therefore, it is essentially a turret that only appears on one map. Apart from the Hero, this has got to be the most unique turret of all. It can only be upgraded with the new special Crystals currency.

And just for an added ‘twist’, this turret starts off as something insignificant – a destroyed building. I really love how this structure looks – the cracks and broken roof.

The turret also has a very unique way of firing. This is the first turret in my game to have a unique bullet property – Electric Arc. Talk about saving the best for last, I hope players actually make it this far to experience all this stuff. Especially the map – that monstrous map alone probably adds half a megabyte to the game size. Using asset bundles would have really helped shave off a few megabytes off this game’s size, especially for players who don’t manage to reach the last map.

I was going to use this tutorial to create lightning arcs for the new turret. But ultimately I adopted a simpler approach. When this turret fires, it creates an electric arc between itself and its target, which then slowly fades away.

After getting that done, I was about to dive deep into a really complex world. Behold…

Game Size

This was surprisingly fun to talk about despite it being something more to the technical side, but this is important stuff to a game artist.

From here onward, I shall hand over to my programmer alter-ego, who will talk about the steps I took to reduce my game size – and explain how my game dropped from 84MB to JUST 33MB, a real feat in my opinion. And at the end, I’ll let you know whether it dropped further and what my final game size actually is at the moment!

It might be interesting to read if you’re into computer graphics or something like it, and pretty much related to artists as it can be to programmers. My post from here on gets kind of wordy because there isn’t much visuals I can use to illustrate what goes on behind the scenes because it’s more to the technical side and yeah, art does get a bit technical even in 2D graphics.

The Magic of Power of Two

A Power of Two (POT) sprite is an image that isn’t just a square, but it must also be in sizes of:

• 64 x 64
• 128 x 128
• 256 x 256
• 512 x 512
• 1024 x 1024 and so on

Here’s an example:

Essentially, you could convert any image to a POT image just by adding some extra pixels around it, but I was exploring better ways to generate POT textures.

I previously thought that there was no clear advantage to use NPOT (Non-power of two) textures VS POT textures. But today I learnt that using POT textures are a tremendous advantage for a game made in Unity. There are other side advantages like performances and mipmaps, but file size was what I was most interested in.

My game had grown to a whopping 84,968KB (85MB) after the latest map additions (mostly thanks to that giant 2.5k by 2.5k pixel map) and this is really bad.

All my maps use NPOT RGB 24bit textures without any compression applied to the map textures. I decided to just cheaply convert it to an unoptimized POT texture just by adding some blank pixels. The image grew from 6400 x 6280 pixels to 8192 x 8192 pixels:

So now you got two of the same images, but one is ‘enlarged’ to have extra pixels for the purpose of making it a Power of Two image. Previously, my ‘MapBackgrounds’ had an uncompressed size of 152MB. But thanks to POT, Unity is able to apply DXT5 compression and the size of the texture has reduced to 85.3MB.

So in summary, with this new data, this is what the updated comparison of the two images looks like side by side:

The new image on the right has a larger file size and is bigger (because it has more pixels) but I was curious to see what effect compression had on the build size. I built my game, and when I saw the size of the output, I could not believe what I was seeing.

 

Game size: 33,861KB, or 34MB. My game had less than HALF of its initial size!!! You won’t believe how overwhelmed by excitement I was to see that. For a game to actually drop by HALF its size is miraculous if you ask me. Of everything I had done so far, I was only able to shave off the game’s size by a few MB at a time, yet this just took a huge 40MB chunk out of the equation with very little work. (Most of the effort was actually me trying to understand what it takes to make compression work and what is going on when the game converts all the textures and generates the game file)

From what I understand, Unity was able to apply DXT5 compression to compress my POT textures, resulting in a drastically smaller final game size.

But were the quality of my textures compromised?

The only problem with POT textures, which may be more of an annoyance would be that it looks pretty ugly. But more than just an annoyance, it’s also a huge waste of image space where the empty pixels could have been used for something.

The reason for the unused space is due to inefficiently expanding the spritesheet for the purpose of getting a POT texture size. This was the slightly unoptimized way of doing things. I made the sprite above for testing purposes. But when it comes to officially creating the actual texture, I use TexturePacker.

I used TexturePacker for lots of development work in OldStory, a game where I heavily relied on spritesheets for animations, but the time has come to now use it again. How it works is you dump a bunch of pictures  TexturePacker and it uses an algorithm to rearrange them in a single image that uses the least amount of space possible.

Image courtesy of YYZ

The software also leaves you the freedom to choose how you want your images to be packed

• Allow image rotation?
• Constrain final sprite to square?
• Add padding between sprites?
• Any max size?
• And the most important: A checkbox to force the final output to be Power of Two

Instead of having two map backgrounds, I now have a main map background that fully utilizes as much of the 8192 by 8192 POT texture space.

Then I have another secondary sheet which optimizes the space for the leftover maps. The same can be done for UI too. You’ve probably already seen me trying to generate a texture atlas before by putting multiple sprites into a single image.

You can see how well TexturePacker actually divides the sprites so there is actually very little unused space even when everything has varying shapes and sizes. Most of the transparency actually comes from my individual spritesheets.

Last week, I used TexturePacker. But it was for fun and used to judge assets by size, but perhaps I will actually be doing this for real for some of the assets in my game. However, I can’t just paste all my sprites into a single texture and expect my game to know how to reference them. There is still more work to be done to achieve something like that.

But assuming I get something like that to work,  rather than having blank space, I might be able to squeeze in assets using this to tightly pack my textures together before slicing them respectively with Unity for use in the actual game.

Having converted my maps into POT textures, I decided to move on to converting other assets of my game: The Creeps.

After importing my latest creep assets, my game size increased slightly, to 34,488KB. At 34MB, it is already pretty small, but can it drop further?

I decided to apply POT atlases to the creeps. I wanted to do a trial test by converting half of the creep assets. I had to figure out what was best for my game – having two smaller atlases (512 by 512 px), or have one huge atlas (1024 by 1024 px).

I decided to try them both and here are the results:

34,488KB – Normal creeps (individual sprites)
34,468KB – Two smaller POT atlases of 512 x 512
34,401KB – (POT texture atlas-ed creeps) -> one big 1024 x 1024 creep atlas

Amazingly, the bigger, but single atlas worked best, but not by much. It does show that empty pixels don’t matter much to game size and is more of an eyesore, but still it’s best to avoid them when possible. Even though the atlas-ing was only done for less than half of creeps, the results were underwhelming – only 87 net KB saved.

It seemed like I had stretched the limits of compression. But then, I was just about to encounter a huge gamechanger…

The Magic of SpritePacker!

While TexturePacker is a fantastic software and was my first time using a software of its kind, I realized that Texture Packer had some limitations, mostly because I was using its Lite version and some of the best features were locked. It was at this point that I was told about SpritePacker, which is essentially a ‘TexturePacker’ that is built into Unity itself.

From what I understand, SpritePacker does what TexturePacker does, but reduces several steps I normally do. I can tag several images in my game to compact into a POT texture. Then, Unity will actually automatically add it into an Atlas!

<pic>

It actually seemed too good to be true. Why didn’t I use this for my maps? However, according to Unity, this is actually done behind the scenes automatically all the time. Having me manually do it, I wondered if I would actually be able to save space at all. I decided to take a look at UI.

In my previous post, I did a bar chart estimation of my asset sizes. UI ranked highest as the single-most space consuming asset bunch (after Backgrounds), compared to my Turrets and Creeps. I decided to do both my UI and turrets.

So I used SpritePacker to convert them. Here’s the results:

34,468KB – Default UI textures
33,305KB – UI POT
32,549KB – Turrets POT

AWESOME! 1MB saved from UI compression and another 1MB from Turrets compression. I was amazed!

At 32MB, it seemed like the game could not go any lower for what it has.

But there was one more thing to compress – InfoPanels. InfoPanels are basically story panels. They are like pictures that tell the story as you progress through the game, like a comic and its individual panels. I have 62 panels in the game to date. Prior to today, I had a temporary 4k x 1.5k graphic sitting in my assets folder containing all the panels. I decided to first uncompress it to its original format, then try to see what effects both TexturePacker and SpritePacker had on it…

32,767KB – Default Panels without spritesheet or atlas (aka uncompressed)
32,549KB – Info Panels NPOT spritesheet by Texturepacker
25,141KB – Info Panel POT atlas by Sprite Packer
23,264KB – Without InfoPanels

The sizes in red is the important stuff. I added a ‘size without infopanels’ to see what the game is like without the InfoPanels at all. In a sense, it’s a “control” variable. I was really amazed by what SpritePacker did.

Without compromising quality, SpritePacker had taken 25% OFF my game size like some discount from a mega sales. I was really ecstatic to see this. Just when I thought the game couldn’t get any smaller, TADA! SpritePacker comes to save the day.

TexturePacker does have its advantages though and I still use it – it all depends on what game you’re making and very project dependent and also depends on how large your textures are. For example, Unity’s SpritePacker doesn’t go higher than 2048px (unless I missed a max size setting), so for my Backgrounds, I still continued to use TexturePacker to pack them and I also pack with it some miscellaneous background environment props to further conserve space. Since the props are smaller, they are VERY good at filling up the extra “empty” space usually caused by the background atlas. I didn’t even need to switch on the built in algorithm that TexturePacker had and I organized the props by max height because it is easier on my eyes – empty/transparent pixels don’t take up much space ultimately. It just looks ugly.

After using TexturePacker again to optimize the second round of leftover backgrounds which were not included in round #1, and using a combination of Unity’s automated slicing to slice some of my environment props, I managed to push the game size to slightly lower. Guess how much it saved? Slightly under 1MB I would say.

Final game size: 24,432 KB ?

With every 1MB I take out of the game, it gets harder to reduce the next MB, so after so many reductions, being able to take out another final Megabyte was satisfying.

That is, until I realized I had yet to convert my bullets/object atlases, so I went to convert them!

New current final game size: 23,987 KB

 

Well, I think this is the lowest the game can go. There has yet to be music added to the game and based on my previous experimentation, 4 (uncompressed) music tracks added 20MB to the game size, so it still isn’t “safe” from hitting 50MB. I still have yet to explore sound compression at the moment. The game also lacks a few InfoPanels which I have yet to draw so the art assets can still bump up in size.

Before I end the topic of game sizes, I thought that maybe you’d want to know an earlier attempt I had at reducing  the game size.

The Magic of Spritesheets?

There’s just so many things I want to say about spritesheets, but first, I was testing a lot with compression. This was back when I had just added SUPER HUGE map to the game and I had yet to do any sort of compression so my game was whopping 78MB.

Unity uses a very complex compression technique – LZMA. I didn’t read up on it and I’m fully aware that any attempt I make to try to understand it will only lead to more confusion.

Compression has always been a very mysterious thing. From what I learned, the advantage of using a spritesheet (a single PNG containing 4 frames) as opposed to having 4 separate PNGS with 4 images has two advantages – the game makes lesser draw calls because it references one texture instead of 4 when rendering your sprite as it animates, and secondly, a well made texture atlas/spritesheet can help reduce the game size slightly.

I had always been confused by compressed vs uncompressed sizes –  but over time I am trying to understand it bit by bit. From what I understand, when I export an image out from Photoshop into Unity, the image is compressed by Photoshop (for JPG) to a lossy format. But when it enters Unity, the image is uncompressed, so a 1MB JPG can become 5MB in Unity. Unity then applies its own compression which more efficiently reduces its size and results in the final build size usually being much smaller.

(Sidenote: This is partially why I later converted to using PNGs, because I lose precious image data and quality when I save my maps as JPG)

The tricky thing is, putting textures together can reduce file size, but it might not be a lot. I decided to test it out – I did this before with my maps, but it resulted in a net size improvement of less than 1MB.

This time, I tried again and exported a spritesheet of 30 huge maps. The image’s file size was 20MB, and when I put it in my game. A miracle happened.

My game went from 78,705KB to 27,771KB.

I was totally shocked. Nothing makes sense. I don’t actually know how this huge drop in file size is attributed to. File format? Spritesheet? I guess there’s a lot about compression I have to learn, but I did the same thing to my Story Panels…

And my game went from 27,771KB to 24,174KB. For something pretty small, a 3MB drop is still pretty significant. I of course tested the visual quality of the game. There’s always tradeoffs when you see such a huge drop in file sizes.

The game was not as fantastic-looking as before and started to blur out when I ran the game at full screen resolution. Then I realized why….

In my rush, I had forgotten that I had the max size of my spritesheet set to 2048, which greatly reduced both size of the game AND the quality of the spritesheet.

This caused my 6000 by 6000px map texture to be supercompressed from 150MB to 15MB and this resulted in a final game size of 27MB.

I was very disappointed in myself. I got all excited for nothing.

Anyhow, the game is also currently pretty funky on fullscreen, but it’s a last priority to fix since this will not happen if I deploy to a fixed resolution on the web.

Sure, my game’s final resolution will only be 800 x 600, but the loss in quality is noticeable. Plus, I heard from my friend there is Retina display for PC as well, but aside from the complex issue with resolutions, this just doesn’t look good at all. Setting a 2048 x 2048 max size is a NO-GO.

When I was experimenting with a UI Atlas before actually implementing it with SpritePacker later on, I wanted to first get an overview of all the UI I have in my game and I found something interesting.There is a particular blue button that is 700 pixels wide. I highlighted it above. That’s almost as wide as the default screen resolution of my game. It’s crazy. I must have forgotten to resize it on oversight. Although SpritePacker does a lot of the atlas work for me, I was actually thinking of doing t manually at first because I had no idea that SpritePacker existed. I was looking at the UI atlas summary,  identifying which UI buttons could be grouped together and which were better left off alone. The overview allowed me to see which buttons are similar in sizes so I can group them together in a texture atlas if I were to do it manually. Or rather in this case, a UI atlas.

PNG vs JPEG – in a game

Now that I know more about compression, I figured that it would be best to use PNGs in my game. They are not lossy, and since I use POT textures, Unity will apply its own DXR5 compression. Thus, I want to save my image in the highest possible quality before compression takes place.

So I spent a good hour convering all my JPG backgrounds into PNGs. I would actually gladly hire an assistant to do all these miscellaneous tasks. Hey, it’s not an easy job you know – you have to open dozens of huge PSD files, resize them and crop out unecessary background. Then you have to stare at the loading bar after each process because it can take quite awhile to resize and save each file. Repeat this step for 44 maps.

First, you stare at this loading bar:

Then this one:

And finally wait for the file to save (which takes as long as it does to read the file):

Now imagine doing this another 43 times. Though there is an easier way to do this – there’s a shortcut to automate saving PSDs to PNGs, I’m not sure if it is able to automate cropping and resizing, and I do have multiple maps saved in some of the PSDs.

I got to admit, it was fun for awhile multi-tasking operations on my secondary monitors, but it got pretty repetitive fast. (I was typing this post as my images are being resized and saved). I also do a visual-check to make sure my exported PNGs do not have any missing detail from their JPEG counterparts. (Sometimes I have multiple versions of a file because I save final touch ups or small changes in details and I store them as alternate PSD files – v1, v2, v3, but I may end up using V2 as the final version because it looks better and I do not delete the v3 file, which is probably bad working protocol on my part. But we all learn from mistakes, right?).

To add even more complications, I was also experimenting a lot with file sizes with just PNGs alone this time. To showcase it, here are 3 PNG images.

They all look the same (and I overlapped them in Photoshop just to make sure). Unlike Lossy formats like JPG, if I were to go through them pixel by pixel with a color picker, they probably are identical. But they have 3 different file sizes and were saved in different formats/software.

(A) was the output of Texture Packer: Size 6.2MB

(B) is a non-interlaced PNG saved in Photoshop: Size: 6.17MB

(C) is an interlaced PNG saved in Photoshop – Size: 8.2MB

All this time I had been using interlaced PNGs and only today did I actually learn that it does not have any advantage in my game. I can’t assume that interlaced is bad because it generates larger file size because I’m not too sure if the disadvantage of larger file sizes means anything – Unity might just ignore the extra data in the image and compress it just as much either way. The world of compression is just so complex…

 

One last magic trick…

One last amazing discovery – I had a bunch of 220 x 110 px images. I enlarged them so they could fit in with a spritesheet of 440 x 220 images. Even though the resulting file size was bigger, and should theoretically result in a larger final game size, it ultimately resulted in a smaller final build size – likely due to the way Unity compresses textures that are grouped together.

So voila! Blowing up an image to a higher res to make it fit into a spritesheet actually makes the final game size smaller. I don’t think this always works and may probably only work under the right conditions in certain scenarios. I did this not with the intent of saving space, but to try and find the best practice for packing my spritesheets. Though it saved only a few KB, it was a pretty amazing discovery and it just goes to show the complexity of compression.

The Atlas Dilemma

There are a few instances where I actually have to decide what’s best for the game. Take the very early example of when I was trying to fill up an enemy atlas.

On the left is a huge 1024 x 1024 POT texture, and on the right is a 512 x 512 texture. (Look at the area represented by ‘white’ space representing the actual texture). Mathematically speaking, the one on the right is more efficient in terms of space usage. It squeezes 6 enemies to one atlas, and only requires three 512 x 512 atlas, using up only 75% of the space that an entire 1024 x 1024 texture uses.

But though it is more efficient (in the sense that it has a smaller ratio of empty space) the disadvantage is of course not being able to access the fully array of enemy sprites from one texture atlas, and packing very few sprites kind of defeats the point of the atlas.

Though transparent pixels don’t take up much space themselves, I don’t think anybody likes to have too much transparency. I have a very ambitious idea on how to actually pack every single sprite into an atlas, including actually removing the empty space between the individual sprite frames! This ambitious idea also allows me to automate sprite slicing – a somewhat tedious technique to do if I have varying sprite sizes in an atlas where some creeps are sliced into grids, and some aren’t. For those creeps, I have to divide the sprites into multiple ‘frames’ in Unity manually.

Sadly, this idea is too late to do now and requires a lot of manual work (therefore ambitious).

If I ever make another game after this one, it will definitely be more optimized.

Though most of my week was spent on optimizations, compressions, here are some other things I did:

Math!

I love Math, but only when I’m able to solve it. This particular game has lots of Math involved.

Due to the Math involved in some areas of this game, I sometimes use my WACOM to draw out diagrams to countercheck in-game values. The diagram above is to calculate the game camera’s boundaries while panning and to recalculate boundaries based on the current zoom level. (More on this later)

Misc Stuff

I’ve been finetuning a lot of things. I can’t remember all of it but just recently I added right clicking to center the camera at a particular spot. I also wondered if I should add detailed statistics to individual turrets, but decided against it since it got very messy.

Some difficult to understand options have [i] buttons to learn more about them.

I can’t remember what other things I’ve done. They are mostly the little things I feel would make playing the game a better experience.

Lots of bug fixes

In the past days I have been fixing bugs. Lots and lots of bugs. The game has grown pretty complex and there’s just so much going on.

I really look up to programmers. I sometimes wonder how a team of programmers work together. For me, I know my entire game code inside out so when a bug occurs and when I’m lucky, I can almost immediately tell which script the bug lies in and how to rectify it. But this is rare and usually only for bugs caused by oversight, like this one:

The Booster turret I added previously ends up being able to buff turrets of its type. Sure, it is not able to buff itself and I thought that code was sufficient. But if you build two boosters, they buff each other, which increases their range, and if you have like 10 boosters, they start boosting each other, which increases their range to be in range of more boosters, which boost their range, to boost your range, to boost their range to boost  yours! And suddenly you got a booster which has a range covering 75% of the map!

Keep trying and trying…

I’m probably the last person you would turn to to get motivation, but here’s a short story. I was up late night coding. (I was rewriting my entire camera code to support even more dynamic zoom for the final level with the huge map)

I was trying and trying again and again to get my camera bounds correct a.k.a trying to fix a bug with the game camera.

Every time I thought I nailed it, I’d say “This should do it.” Then I’d run the game and something would go wrong.

Then I’d go back to code, change a few lines, then go back and run the game, and then another thing would go wrong.

Then frustrated, but determined, I’d go back to the code, check through it, change more stuff, and I’d say “Okay, this should work.” Then I run the game, and BAM I’m back to where I started. You can imagine me looking at the screen in frustration at this stage.

But after looping through the steps above like as though I was in a for-loop myself, I get a bit more ‘attentive’ each time and just a tiny bit closer to tracking down the bug. I get closer and closer to a solution each time. And even if I don’t, I’d at least cross out what ISN’T causing the bug. Programming is really tricky though, so sometimes I can spend a really long time trying to find the bug. It’s even more frustrating when you find out it’s something stupid.

But after a few hours, BAM success! So yea, you sometimes just got to keep trying and trying. Not blindly though – you got to know where your mistakes lie and not make the same one again. I do that sometimes and it really bites you, so instead of a ‘Once bitten twice shy’ kind of bite, it became more like ‘Once bitten, twice bitten…’ or something. Whatever.

So that’s what making this game is all about – I just keep trying and trying until I get it right or else if I don’t get it right, I make a terrible game. This is true for everything I do. Even for balancing. The balancing was really horrible at the start. It’s still not perfect now, but it is much better than before.

I don’t think I have as much problems with art, but I guess that’s a really subjective matter. I remember struggling a lot with the pixel art and character sizes in Introvert because I was really inexperienced with Flash and character sizes. (This was back in 2013, when I was still studying and Introvert was the very first game I made).

I do acknowledge that this game does indeed have a few flaws, mostly with balancing and sadly I don’t really have the knowledge to solve these issues at this point in time. It is times like these where I really wish I had a team to work with, because it would mean being able to create better games of higher quality. But teams don’t grow on trees nor do they fall from the sky. It has been very fun though getting first hand experience at all aspects of game development, and a great experience nevertheless.

Only 24 hours a day

I guess the other problem of not having a team is that you got to do everything yourself. There’s the issue of time – I work about 14 hours a day at full speed. But even still, there is only so much stuff I can do in a day, and I believe a lot of people would wish days last longer.

I’m not even sure if developing games can be a hobby (more on that later). Developing quality games is not a very good hobby to have and I mean that in the most positive way. A hobby like drawing is something much more reasonable comparatively. When you want to make ‘developing quality games’ as a hobby, it means you are drawing, coding, designing, sounds-ing and handling overall production at once. That’s like multi-tasking 5 hobbies in one.

Assuming in the future I work a regular 9am to 5pm job and each day has 24 hours.

8 Hours is lost to sleep.

8 Hours is spent working.

1-2 Hours is likely spent on transportation to and fro from work.

1-2 Hours is spent on miscellaneous self-maintenance tasks like bathing, eating and leisure activities like watching TV or Star Wars videos. Yes, I call this self-maintenance because these are essential for survival – including leisure. I could work on my game all day but I always spend time doing miscellaneous tasks to rejuvenate myself. Writing on my blog, reading Quora, watching funny videos people share on social media, re-watching The Star Wars Force Awakens trailer, you know – the typical breaks that most average humans need.

Deduct all those hours and you have about 4-6 hours leftover for your hobby. And that’s the maximum time. Working overtime, social gatherings, family outings, miscellaneous commitments are other important essential events that are going to lessen the ‘free time/hobby time’ you have.

 

During National Service, I was able to keep it up somehow. It was a miracle. Though I took long breaks from game developing, I always returned to it somehow. Even as I stayed in camp on weekend duty, I would sketch out game designs and ideas in the bunk. I guess even from camp, my projects were always calling out to me.

So at the end of the day, and most likely, once I start working, developing games is a very challenging hobby. I wish it could be easier, but at this point in time and with current technology, making a game takes tremendous effort and plenty of commitment and rightfully so because if that weren’t the case, the standard of games would drop.

When games became more easier to make with the introduction of Flash years ago and  commercial game engines like Unity in recent years, many games have sprung up. At the same time, a lot of people seem to be monetizing simple games. I see games on STEAM selling for $10 despite having lesser quality than some Flash Games I played years ago.

My personal thoughts / Reflection

I’m probably finished talking about the game and there are no more pictures below. So if you came for the pics, you can quit reading now. Instead of talking more about my progress on the game, I am going to write about what I have experienced in the past few weeks and really just let out some of the things I feel and reflect on when I was making this game.

First off, a question that I think I get most from people close to me (or not): How long does it take me to make a game and when am I going to publish this game?

To make a good game, I would actually need at least 6 months. If you reacted negatively to that statement, either by thinking “that’s long” or “you’re lousy”, then you’re probably one of those people who (hopefully I’m not insulting anyone) don’t really know what it takes to create a game, or a quality game for that matter. If you’ve made a quality game by yourself, then you would be better qualified to judge other developers and, I’d also salute you because making a quality game takes lots of effort and skill and probably experience as well. And this isn’t limited to just games – if you want to make something good, either if you are a fellow app developer, an engineer trying to create a product, it’s going to take time. 

I think when people see me making a game (or at least it happens to me), they expect that I’m going to finish and publish it in a month, which may not sound crazy if you’re making a simple ‘Roll a Ball’ game with only one level.

But the truth is that to make a game with depth, balancing, has sufficient content and looks good with sound effects and music… that is going to take awhile. You don’t just say  you want to make a game in one month and go”I’m going to design the levels for 1 week, code for 1 week, then draw+animate the characters and backgrounds for 1 week, then finish up the optimization,sounds,polishing,balancing in the last week.” Again, depending on the scale of the game you are making, that can be incredibly feasible, but not for most games. Not one for the scale I’m making anyway and definitely not with the manpower I have: one.

I guess unless you are a fellow developer yourself, it’s easy to underestimate the effort and time it takes to make something. If my game does get published, things like the camera zooming, honing onto a target, the special effects on boss maps, the little spawn animations of the epic bosses, the story panels, tiny popup animations/fading effects… they’re all going to be overlooked by people. Things that took 10 hours to make will only appear on screen for 10 seconds and it doesn’t matter to me. As long as it makes the game fun to look at and enjoyable to play, I really don’t mind working 10 hours on the little things. And if you have read the entire of this post up till this point, you would have realized by now that a lot of time and effort goes into things you don’t see on the screen. Precious development time and effort are spent on many things behind the scenes, things you don’t always see and take for granted, like: optimization to make playing more smooth, size reductions so you don’t wait forever to play the game and balancing.

In the scale of time, 6 months to make a game is not very long, but neither is it very short. 6 months is half a year. For the record, I spent 2.5 years developing Introvert, a lot of that time apparently was from when I was serving National Service and working on other games too. At a rate of 1 game every 6 months, it means that working alone at a 14 hours a day, I make two games every year, which is actually really pathetic, and looking at the number of games out there, it’s easy to assume that making a game is meant to be fast, simple, easy process, and it probably is to an experienced developer or a team of people, or a company. But I’m no company or group of people. I’m just a one man team, a guy trying to make a game that people would want to play.

I saw this ‘Make a game in 10 days’ competition and I would have joined if I were not involved in my own project already. I took the time to see some of the games made by participants. There was one game I spent a good 20 minutes on, and that’s astonishing. It really amazes me what people can do in 10 days and truly inspiring to look at. If I still have time after my game is done with development, I will embark on making smaller games. But chances are studies would take over by then and time will probably become my greatest enemy.

The truth is that as a game gets bigger and has more stuff, without a team it just gets exponentially longer and harder to make. In smaller games a lot of things can be taken out or minimized – there isn’t as much need for insane balancing, or progression, and file sizes become less of a burden. Some of these can be offset by experience though.

 

It’s like a snowball effect when you make a big game – each new feature multiplies the development time, not just flatly adds it and if you don’t exercise self control, things are going to get out of hand very quickly. You got to be careful about the decisions you make. Speaking of which…

Decisions, decisions…

When making a game, (or anything really) you got to make your own decisions for the betterment of the game (or the thing that you create) and it can be something very hard to do. While I get to call the shots in everything from the art to the design, and especially design, I also want input from other people. I’d in fact be very happy to hear what other people feel or think, which is crucial during the design and development phase. The closer the game is to completion, the harder it is to change and modify core mechanics without throwing off the balancing on a huge scale.

But there’s a greater decision that I have to make – my future.

I went to take a look at two university courses at an Open House today. There was one talk I sat for by this particular speaker. I expected it to be some standard pep-talk, but this speaker was fantastic. Not once during the talk did I feel bored at all. I sat there listening intently. He spoke really well and presented himself excellently, probably the result of year after year of speaking to students and parents. It was unlike any of the previous University talks I had been to. But after the talk, it was time to actually look for the right course for me – what should I study?

After a few talks with a few people, the question quickly turned from “what should I study?” to “what is my goal?”

Apparently, the job I am looking for doesn’t exist. Or to be clearer, it doesn’t classify as a real working, stable job. And it makes sense. The job I was looking for is too ‘perfect’. I was really very sad. I didn’t make this Tower Defense game -or any of my previous games- for money and there always will be at least a few people going to tell me that it’s an unusual way of doing things.

Nevertheless, life presents a lot of options to each of us, and I guess that was what I was meant to realise. Yet out of the many options we have in life it is often difficult to find the best one. And having eliminated one of the best options I was looking forward to, there’s not much motivation for me to study actually, but I guess that remains to be seen.

THAT’s ALL!

So what’s left to do? A lot it seems. But getting the game size down is really a huge load off my chest. The game went from an (impossible to publish) 80+MB to a (reasonably acceptable) size of 30MB.

Still far from actually publishing it though, and with life commitments starting to kick in, it will take even longer to finish the game and publish it.