We have moved!

Visit my new site!



What I forgot to comment out and memory optimizations

With the release of Make Toast, I downloaded it off the App Store and proceeded to play it.  Admittedly the play testing prior to release was to say the least not rigorous enough.  First there were FPS dips, and then the dreaded player prefs not being saved due to a rookie mistake:  I forgot to comment out a line of code I used to delete the player prefs for testing purposes during development.  Thankfully the fix to this was as simple as commenting out that said line of code.

The FPS dips however took a little more investigating.  It turns out that foreach loops are known to be memory inefficient and there’s a part of code in Make Toast that was poorly written to run a foreach loop to check if the player has toasted all the slices of bread, a part of code that was intended to be only run when all slices of bread have been spawned to trigger a game ending condition.  Unfortunately there seemed to be no good alternative to a foreach loop to check if a GameObject had children, therefore the fix here was to ensure the foreach loop was run only when it was needed.  The fix looked like it kept a much more stable FPS throughout.

While searching for ways to improve performance, I came across two other methods: object pooling, and disabling the accelerometer.  Object pooling is a method where you reuse a pool of objects to save from dynamically loading/instantiating them during gameplay, something that was sure to improve performance further but with the previous fix, it appeared unnecessary to put in the extra effort that could be directed towards the development of other projects.

Disabling the accelerometer on the other hand was as simple as selecting another option with a drop down menu and has said to improve FPS by 2-3.  Games that don’t make use of the accelerometer should simply disable the feature as on default Unity samples the accelerometer 60 times a second (or 60 Hz).  The option is found under ‘Build Settings > Player Settings’.


The aforementioned fixes have been applied to Make Toast in version 1.0.1.

When programming bugs are not (really) your fault.

Unfortunately I fell ill for a good while after returning from SF, but I’m back at it now!

Recently I’ve been trying to implement ads into one of my games, Make Toast, mostly as a learning experience but also because I intend to release the game free-of-charge and thought I’d experiment with this type of monetization.

But first, I recently updated Unity to 4.6.3f1 and encountered a really strange bug when I compiled from Xcode to my device (iPhone).

“You are using Unity Basic.  You are not allowed to remove the Unity splash screen from your game.”

Two things:  1.  Yes I am using Unity Basic, as of right now I can’t justify dropping couple thousand USD to get a Pro license (Unity Pro + iOS Pro), 2. I did not remove the Unity splash screen.

Looking for salvation online I came across some posts on the Unity forum about users experiencing similar issues with prior versions of Unity, where a developer claims to have the issue resolved in a later build.  I can only assume the problem cropped up again in 4.6.3f1.  One of the solutions which worked for me to remedy this situation is as follows:

  1. After building from Unity, open up the project in Xcode
  2. Delete these files from the project:
    • LaunchScreenImage-Landscape.png
    • LaunchScreenImage-Portrait.png
    • LaunchScreen.xib
  3. With Unity-iPhone selected in Targets go to the Info tab, select and delete (press the del key) UILaunchStoryBoardName~iphone under Custom iOS Target Properties
  4. Clean and rebuild the project.

Needless to say, I regret updating Unity as it seems I am bound to reenact this ritual every time I wish to test a new build, at least until they fix the issue in a later build.  Of course I can always install an older version of Unity without the bug…

Back to ads, my plan for ad implementation was to include both iAds and AdMob, where a request is first for an iAd ad and if it fails for whatever reason it will request for an AdMob ad.

Implementing iAd was a relatively simple endeavor, referencing the official documentation here.  AdMob on the other hand took much more effort as it was not officially supported by Unity itself.  With some scouring and cross referencing code written by other Unity users on the Internet I was able to eventually piece together what I thought was a working implementation of AdMob for Unity.  I wasn’t entirely right.  With a build from Unity to Xcode, I tried compiling the code in Xcode only to run into a legion of errors.

The first hurdle was that the latest Google AdMob SDK for iOS (7.0.0), which was the one I initially supplemented the project, did not work out of the box with Unity.  The solution I went with here was to simply download and use an earlier SDK (6.12.2).

Then there was the huge amount of Mach-O linker errors in Xcode that made little sense to me at first.  After some digging it turns out that I needed to link some additional frameworks that AdMob needed to the project.  These were the frameworks I had to add to rid most of the Mach-O errors:

  • AdSupport.framework
  • CoreTelephony.framework
  • Event.framework
  • EventUI.framework
  • MessageUI.framework
  • StoreKit.framework

I said most didn’t I?  Well there was still one left and with some more digging, trial and error, this was the final piece of the puzzle that smoothed over all the issues with implementing AdMob:

  1. With Unity-iPhone selected in Targets go to the Build Settings tab, under Linking, add -ObjC and -all_load to Other Linker Flags.

And that was it!  AdMob started to show banners in the game.

You didn’t think I forgot about making the two work in tandem did I?  Thankfully this was another simple implementation that looked something like this in pseudo-code:

  1. Load iAd
  2. Wait for some second(s)
  3. Check if iAd loaded, if not hide it and load AdMob

Step 2 is somewhat important as without it the implementation only loaded AdMob ads I’m guessing because there wasn’t enough time given for the iAd request to go through.

I’d like to end this post with the fact that I’ve reworked Make Toast, and with Game Center leader boards functional, and ads seemingly working, it won’t be long before I can publish my first game.  Please look forward to it!

On Replacing Placeholder Art

I can’t really draw, it even says so in my about me page.  But working solely by myself requires me to produce all the art for my games which simultaneously terrifies and excites me – I can’t really draw but I’d like to be able to.

On my way to becoming a proficient programmer, producing placeholder art or ‘programmer art’ seemed like a rite of passage.  But of course this is really done to dive straight into the implementation of a game’s features while also minimizing the time wasted creating art that may not be used in the final product.

In one of my upcoming titles, Animal Link, the production of art for various animals is required, one of which is a pig.  This is what a pig looked like in its earliest state:


Oink Oink!

Seen better/worse placeholder art?  Well at the time, it felt like the placeholder art I created wasn’t going to get any better (I’m glad I was wrong).  The placeholder art had two elements, the type of animal, and the theme, which is represented by the background color.

While I could have simply had animals color-coded/numbered for placeholder art, it was important to me that they held the same elements the final version was going to have in order to get a better feel for what the final game would be like.

This is what a pig looks like now (more or less final):


Oink Oink! 2.0

The improved pig conveys the same bits of information: type of animal, and theme, which allows the replacement process to be seamless.

On a final note, I find it very fascinating how a game’s appeal dramatically increases with better aesthetics whilst everything else stays the same.  And with that being said, there’s a long road of pixel wrestling and color matching for Animal Link up ahead!


Oink 1 to Oink 2


…on this blog.  I had another development blog that I started sometime ago but the company that hosted it shutdown sometime this year.

With this post it means I finally got around starting another blog which will also double as a personal website because well – we could all use some online presence right?

I’ll throw down a summary of my independent journey thus far.

I decided to go independent after a short break post grad school.  Having only taken a class or two covering the basics of programming during my initial undergrad years, computer language might as well have stayed a foreign language to me.  I wanted to change that – despite having vested interests in game design, it occurred to me (I’m sure much later than many others) that apart from being able to create games of your own, it had a certain synergy with game design, not to mention increases your employability.

The deep end I went.  Objective-C in Xcode was what I started with since I had at least some even though minute knowledge of C/C++ and wanted to target a platform that is friendly to developers of smaller numbers.  The learning curve was harsh for a non-techie like myself but I managed at the end of it to create a small game where colored ‘dot’ characters appear on screen at varying speeds, changing backgrounds, all depending on the order and frequency of which the player tapped the characters, and you got points for doing so.

It looked something like this:


And this:


While the game wasn’t seen to completion, this whole experience proved something: I could learn to code.  To me this was a revelation, something that I never thought I could ever hope to do I did.  Of course it’s not like I accomplished very much, but it was undoubtedly a personal achievement and dare I say milestone.

Around the same time, a good friend of mine approached me and suggested that we collaborated to make a few games for our portfolio if not for profit.  We were both to have creative input, him the art and myself the code.  This collaboration marked my switch to Unity3D (C#) for two reasons in particular: 1) Multiplatform capability 2) Unity3D offered a much friendlier development environment for people with less technical expertise such as myself.

Unfortunately due to reasons that will not be disclosed to the public, none of the projects we worked on came to fruition to this day and our collaboration has been in a state of stasis.  Despite this, I was able to learn a lot about working with Unity3D creating the many prototypes for our now defunct projects.

This brings us to the present moment where I’ve decided to continue to pursue development of my own titles in Unity3D with two titles currently on the way.