submit to reddit
Follow ToxicBlob on Twitter

We'll be at DIG London!

DIG 2011

I’m super excited to be bringing Sin or Win to DIG this year. We’ll be there with a playable preview on Wednesday 16th from 5pm to 7pm. So come hang out and get hands-on with Sin or Win. And if you’re interested in game design, development or the Unity game engine please stop by with your questions. I’ll try to help.

I would have loved to attend the whole conference as there looks to be some great speakers and events, but someone has to stay back and finish up Sin or Win.

I also had two posters printed up for the event. And I’m very pleased with how they turned out. I don’t tend to work in print, so was astonished to see how big 24”x36” really is. That’s 5574cm2 of Sin or Win glossy goodness!


Thanks to Greg Picken of Gamer Pops for inviting me to DIG.


Publish Automator

DSC_3768 - Version 2

I’m back from sunny San Francisco after my first Unite conference. It was a wonderful trip. I visited old friends and met new ones. At the conference I gave the talk, “Artists as Programmers”, then helped out with the “Artist Discussion”. Lots of fun. I’m already looking forward to next years Unite.

During the talks I mentioned a tool I had written that speeds publishing assets to the Unity assets folder. It’s a python script I’ve written and embedded in an Automator task.

Here’s how I use it:

All my work-in-progress images, animations and meshes I keep organised in my Development folder (marked in grey below). As an example the background daytime & nighttime image is located at Sin or Win/Development/Environment/Artwork/Environment Art v019.psd. I tend to work at least double the desired size, and enjoy layers so this Photoshop image is 500+ megabytes. To export to Unity I save the image using Photoshop’s Save for Web interface, dumping the png to Sin or Win/Development/Environment/Publish/Environment Art v019.png.

I’ll work away in Photoshop updating several different images at a time. When it’s time to copy them all into Unity I’ll use my Publish Automator script. I select the updated images in the Publish folders and drag them all onto my publish tool in the Finder toolbar. My script then copies the files into the appropriate location in the Unity/Assets folder while also stripping their version number. This last bit is important. If the image retained it’s “v019” Unity would see it as a new image and I’d get a messy Unity/Assets folder as well as have to manually assign the image to existing materials. Working with the publish tool enables me to work outside the Unity/Assets folder with version history, and easily publish to the Unity/Assets folder with Unity updating automatically. The script also automatically creates any folders in the Unite/Assets folder that are needed.

It’s saved me a tonne of time by simplifying my workflow. Hopefully it’ll help your development pipeline.

Instructions for Installation
  1. Download, unzip and store where convenient
  2. Drag the icon to your Finder toolbar
  3. To change the Python script within the Automator action, right click on the Toxic Blob Publish Automator application and select “Show Package Contents”. Open the Contents folder. Then open document.wflow in your favourite text editor
  4. On line 74 is the variable “devPath” which is my “/Development” folder, and on line 75 is the variable “publishPath” which is my “/Unity/Assets” folder. Change both to suit your paths & save the file
  5. Drag any file(s) onto the tool and relax as it copies them into your Unity project. Note, I haven’t tested dragging folders onto the tool, and that may not work as you would expect, so stick to files
  6. If you find this tool useful, drop me an email or a tweet and let me know where you’re using it. Thanks!
Toxic Blob Publish (220 KB)


Sin or Win Gameplay Trailer

A game of heavenly/devilish consequences. Fast paced and tactical, can you save the cavemen from falling into the pit of doom. Or will you be a sinner? For those who are brave enough...

...Coming soon for the iPad

Optimising with Unity for iOS


I’ve found it’s often the unexpected that takes time. Cuban customs agents, downloading in Canada, and bureaucracy in Norway. And so it has been with optimising my game for the iPad. Unity provides two useful pages to get one started on optimising; one for optimising scripts and one for optimising graphics. There are still further, and often simple, code changes that help squeeze more frames per second out of the iPad.

Use Strict
Use #pragma strict at the top of all your scripts. It’ll initially make component access more awkward but as you’ll cache those lookups it’s a one time hassle. So with #pragma strict: GetComponent(Rigidbody) would become GetComponent(Rigidbody) as Rigidbody.

Avoid Object.Instantiate() & Object.Destroy()
Instantiating is bad. Destroying is bad. Both require memory allocation changes and cause a hiccup in performance when an object is created or destroyed. So instead of creating and destroying objects when needed, I predetermine what is required and my SpawnManager class instantiates all required objects at the beginning of the game - causing one large hiccup when it can be hidden. Then it disables the spawn, but they’re kept waiting in memory. When they’re needed the game object is enabled and ready to go.

Cache Component Lookups
This is an optimisation recommended by Unity on their optimising scripts page, and I whole heartedly agree. I’ve found casual component lookups performed often enough cause a slow down.

Use iTween Sparingly
I hadn’t used iTween until midway through production, then after some positive encouragement I gave it a try. And it was awesome. Very easy to use and easy to chain together to create complex behaviours. I loved it, and I quickly incorporated it into my movement scripts. Then the performance hiccups followed.

A call to iTween typically happens midway through a game. An iTween component is instantiated, makes some expensive component lookups and then is destroyed. Each of these steps causes a performance hiccup, the worst being a substantial garbage collection on destruction. Instead of using iTween in my performance critical areas I now use my own easing and interpolation classes that slip into existing Update functions and can be called with cached nodes.

Avoid SetActiveRecursively()
My SpawnManager class used to execute gameObject.SetActiveRecursively(true) on any node that was being spawned. The first disadvantage to this was sometimes I didn’t want all children to appear right away, so I’d hide them again. More performance offensive was that SetActiveRecursively performs several expensive component lookups.

To solve this I now cache the hierarchy in Awake for any game object that will be spawned by SpawnManager. SpawnManager then simply enables the top most node and the top node is responsible for enabling whichever children it needs. And because the children are cached in that initial Awake call, there is little to no performance hit during the game.

Use Builtin Arrays
Unity isn’t kidding when they recommend using Builtin Arrays for critical code. In my SpawnManager I was tracking which objects were active and which were not using the handy ability of Javascript arrays to resize. SpawnManager.GetActive() would then convert and return those arrays as Builtin arrays for other scripts. But the return activeObjs.ToBuiltin(GameObject) was using 108B of memory and taking 1.3% of a frame’s time. Not ridiculous amounts, but more than I found acceptable. Converting my code to use Builin Arrays took four more lines of code and now uses less than a quarter of the memory and is 5x faster.

Avoid String Comparison
Initially I had plenty of conditionals using tags to query objects. I’ve collided with you, are you tagged with “The Fancy Cliff Over Yonder”? Great, lets form a club. Lets also slow down the game, because the longer the tags, the longer it takes to compare against. This may seem trivial, and for a few tag comparisons here and there not really a problem. But in an Update function with several objects this suddenly becomes several hundred queries a second. So if(collision.gameObject.tag=="Cliffs") became if(collision.gameObject.layer==9) which isn’t as easy to read, but a few explanatory comments nearby and the problem is solved.

Avoid Vector3.magnitude & Vector3.Distance()
Every moment of my game I’m comparing the position of the finger to the position of the interactive characters. Several characters on screen at once and this starts to amount to an awful lot of Vector3.magnitude checks (Vector3.Distance uses .magnitude and is essentially the same). This becomes an awful lot of slow square roots calculations. So, wherever possible compare distances using Vector3.sqrMagnitude.

My game is programmed in Javascript so those using C# may find subtle differences. Performing the above optimisations has helped increase my average frame rate from 30-60fps to 100-200fps.

Unity 3.2


Unity 3.2 is out! The most exciting new feature for me is the ability to profile standalone player builds directly in the Editor. Including iOS builds. Previously I optimised my code based on how my game ran in the Editor. But things on iOS often run differently than they do in OSX. Now I can play my game directly on my iPad while keeping an eye on the Unity Profiler.

But keeping one eye on the game and one eye on my monitor has proved awkward. By the time I can move my hand to the keyboard to pause XCode whatever caused the frame rate spikes has passed. Sure, I could scrub back in Unity to see the code, but my spikes are of a rendering nature - all lumped under a single time consuming line in the profiler. I need to go back in time to see on the iPad what visually changed to discover the cause of the spike. I need a time machine. And that time machine is my Nikon. It’s now set it up to film while I play, then I scrub through the resulting Quicktime to easily determine how to best optimise the game. The above is a screen shot from one of those quicktimes.

I still have lots of optimisation left, but with the help of the new profiler in 3.2 it’s a much more enjoyable job.


I’m a Film VFX Artist by day, Unity3D Game Designer by night, and commercials director by occasion. Toxic Blob is the outlet for my games.

A brief history: I’ve always wanted to make games, but apart from a summer creating image for
Celtica, I never landed a job in the game industry. Instead I ended up with a job in the film industry first, so I put aside my game dreams. Skip ahead to 2008. A friend introduced me to Unity, and I then enjoyed geeking out by reading their docs. My game dreams awakened. When my PC up and died I bought a Mac and Unity. It’d be two more years before I’d be able to find the time to start developing a game.

With the programming, painting, animating and planning experience I learned while in the film industry I would make a game. An iPad game.

On this blog, and on
twitter I’ll publish my thoughts and w.i.p. images during my developing. I’m already midway through my production, so I’ll be catching up for a bit. I hope everyone enjoys this “behind the scenes” and, ultimately, my game.