/* You are not expected to understand this. */

Moving To The Country, Gonna Eat A Lot Of Lemons

Posted: April 17th, 2017 | Author: | Filed under: Hermit, Projects, Soapbox | 3 Comments »

What is the most resilient parasite? Bacteria? A virus? An intestinal worm? An idea. Resilient… highly contagious. Once an idea has taken hold of the brain it’s almost impossible to eradicate. An idea that is fully formed – fully understood – that sticks; right in there somewhere.

– Cobb (Inception, 2010)

That idea for me was to drop everything, move out into the middle of nowhere, and make games out of nothing. It’s not a new idea. It’s been stewing around in there for a long long time. When Gameloft Auckland closed its doors, that provided the impetus to move it along. I spent a good year tossing it over, discussing it with peers and (former) colleagues. The general sentiment was, “If I could, I would.” The catch was, of course, that we are never really truly prepared. Sometimes you have just got to take the plunge. So I jumped. What’s the worst that could happen?

A few were tempted to jump with me. There were quite a few late night discussions on where to go, what to do, how to set up a community of indies so that we can feed off each other’s creative juices. We even had a big road trip down to Taranaki just to scope out the place and see how comfortable we would be there. Reality has a way of crashing down on dreams, and that happened for many of my compatriots. They are still keen to come down in a couple of years when their earthly affairs are sorted, but for now, I am the pioneer.

So… the idea of moving out here is of course for the cheap rent, fresh air and uninterrupted coding time. I scoped out the cheapest places I could find, and spent a few days down in Hawera to look at places. Some were downright nasty, while the good ones were snatched from under my nose mere hours before I was due to inspect them. The very last place that I was scheduled to look at, however, wasn’t too shabby. It was a spacious three-room house with a reasonably large garden and yard. It was old, and needed some cleaning up, but certainly serviceable. The other catch was that it’s out in the farmlands 20 minutes drive from the city. It also came with a very bountiful lemon tree. That was the sign. Life literally gave me lemons. I took the deal—$150 a week… eat your heart out Auckland!

The move itself went fairly smoothly, but there was a lot to take care. It appears rural folk take great pride in their ruralness (rurality?). I had to sign up at the post office for Rural delivery. Internet is not through fibre or even copper lines, but via Rural Broadband (which is really just glorified 4G with a dedicated cell tower). If it tickled your fancy, you could even fill your car up with Rural Petrol. Then there was the war on the creepy crawlies. With my trusty spray can and dustbuster, I expanded my territory from room to room, eventually claiming the entire house. There are still guerilla insurgents every now and then, but nothing that can’t be shocked and awed. The garden is still wild territory though, but I have a good excuse…

In the two weeks that I’ve been here so far, not one, but two cyclones (or as they like to call it in the news, cyclone remnants) have rolled lengthwise through New Zealand, causing flooding and closing highways across the country. My choice in lodging was validated, given that the house was in no danger of flooding, and I didn’t need to get evacuated. How traumatic that would have been! So while it wasn’t the most auspicious of signs, there was plenty of silver fresnel.

One other thing that killed a lot of momentum in my personal efforts, was some contract work I’ve taken up. Before I left Auckland, I made arrangements with a few choice game companies to take up contract work from time to time, with the stipulation that the work either be lightweight (~2 days a week) or short (~2 weeks). As it turned out, one of them wanted me to start on something right away. So for the first two weeks I’ve been here, that has been the main focus. Looking on the brighter side of things, at least it gives me spending money to cover the cost of the move and settling in.

Nevertheless, having committed to my course, I’ve started a dev blog to track my progress which you can access by clicking here. Unlike this one, that will be focused on the project itself, with daily updates and weekly thoughts, which is why I have not been talking much about it here. Right now, it’s mostly full of excuses for my lack of progress, but hopefully things will kick into high gear once I’m settled in.

Here we go again…

Posted: July 14th, 2013 | Author: | Filed under: Hermit, Projects, Tutorials | 1 Comment »

Once upon a time, there was a project called Darwena. This was to be a game engine built from the ground up with the aim of reducing our reliance on that other group of people that are kinda crucial to game development. (the artists!) That project started up fairly quickly, with cross-platform input and rendering implemented, even a little text. However, that project died just as quickly when I joined the ranks of Gameloft. Many factors contributed to that. There was the fear that as a generic employee in a generic evil empire, my work would simply get assimilated into the host. There was the lack of time and energy due to the crazy scheduling of a freshly started-up studio (albeit under the umbrella of said evil empire). Most of all, I start learning a whole lot and discovered (i.e. had my nose pushed into, gently) a lot of concepts that made my previous work look like the inane doodles of a three-year-old. (no offense to three-year-olds, you rock!)

Well, most of that has changed now. The wild schedule has been tamed. The powers that be have given their blessing to my pursuit of non-commercial project work. Most of all, I’ve learned enough that I just need to write something to congeal all those disparate concepts into a contiguous body of knowledge. Also, I now have a conducive work area in my apartment, all ready to get those creative juices flowing!

Design Goals

  • It will be cross-platform across Windows, OSX and Linux, though most work will be done in Linux. (because we can!)
  • It will be multi-threaded, and data-oriented, and component based. (I was told that component models tend to not work well. Time to test that!)
  • It will emphasize procedural generation. However, we’re not targeting the sort of procedural generation that we find in the demoscene which creates a lot of pretty stuff with very small code and assets. Instead, we will be generating assets non-realtime (unless things go exceedingly well), mutating and splicing them with genetic algorithms using human input as the fitness function, in order to produce not-so-abstract-looking visual and audio assets. This is not a new concept, but it sounds like fun and worth exploring.

Target Features

  • There will be an editor for creating content, possibly including game levels.
  • Text input and editing will be highly emphasized as the main means of control. The target users are programmers, so there’s no fancy drag-and-drop-connect-the-dots nonsense  going on. Command prompt ftw!
  • There will be a scripting language for fast prototyping, most likely AngelScript because the C++-like syntax might be easier to copy/paste into actual finalized code. Also, the exposed debugging interface would allow us to do breakpoints, watches, etc. within the scripts through our custom interface.
  • The first asset generation milestone would be creating X different assets with different mutations for the human to select and filter through.
  • The second asset generation milestone would allow splicing of two or more assets into one.
  • The third asset generation milestone would be finer-grained gene manipulation.

Basic Architecture

Despite all the fancy stuff, a game engine is still a game engine and will need the same basic things. Our design will emphasize mulththreading while trying to steer away from excessive mutex use or double-buffering of data. Instead, we apply the data-oriented paradigm and look to transform data from one form to another with each module. On a very high level, it may look something like this:

High Level Model

The Simulation module is basically a huge collection of cascaded step functions. This would can be thought of as a physics process. For example, you use acceleration to step velocity. You then use velocity to step position. However, this could apply to HSV color, audio frequency, emotional state, etc. This is very likely to eventually comprise of many submodules to handle different types of algorithmic relationships. I’ve still to sort this out in my head.

The Steering module takes the output from the simulation in order to generate control inputs for the next simulation step. It can also take additional input from its internal stored state or from external sources like human or network interfaces.

The Rendering module simply takes the output from the simulation and splats it on screen, speakers or whatever other output device so that we humans can perceive what’s going on in there. In a sense, this is just a slightly twisted MVC model.

The whole pipeline will run as if it were in a single thread but each of the modules that execute will be threaded. This will allow us to scale dynamically as more processors become available, and will also let us collapse back down into a single-threaded system for easy debugging. Each of the modules or submodules will load balance by simply dividing the number of tasks by the number of processors. We can do this as long as all the submodules are homogeneous in the sense that each task will take about the same amount of time to execute. The only exception to this is rendering which generally likes to run from the same thread, and is thus run in parallel with steering since they operate off the same immutable data. This may cause bubbles in the pipeline, but that’s another worry for another day.

Where are we now?

Currently, we have rendering up on all three platforms, as well as a modicum of input processing. Project/makefiles are generated through CMake. This includes the main engine library project, as well as a project for the editor that runs on the engine.

The next stop is the resource system. Stay tuned!

Project Update!

Posted: February 6th, 2013 | Author: | Filed under: Projects | 3 Comments »

Hi everyone! It’s been a long time since I posted. In fact, it’s almost been ever since I joined Gameloft. The corporate hush-hushness has been keeping my lips sealed. However, now that several games have already hit the markets (for some time), now would be a good time to list them out and add them to my online portfolio. If you are looking for amazing revelations and insights, sorry. This is more of a “Look what I did!” post.

First, the ones that didn’t quite make it, and hence I can’t say much about. The first is  an the Android port for the very first game published by the Auckland studio. Unfortunately, the port was later abandoned for reasons we shall not say. I also worked on an experimental project which, for blogging purposes,  we shall call “Mystery Island”. Unfortunately,  Mystery Island did not make it past the prototype stage, but it was very pretty. (We were definitely carried by the amazing art team for that one!) Ah well, rough start!

Playful Minds and Men In Black 3

In the meantime, I did contribute to two games that did make it to the market. Playful Minds: Math, and Men In Black 3. While I wasn’t a main developer for either of these, I contributed via bug-fixing in the former and performance optimization in the latter. Apparently, that was good enough to get my name in the credits, so yay me! Playful Minds is an educational game that was inherited by our studio. A lot of sweat and tears went into making it as it was one of our first projects, and nobody was quite sure which way was up yet. MiB3, on the other hand, was developed in another studiol, and they were under tremendous pressure to release in time for the movie premier.

Wonder Zoo, My Little Pony and Littlest Pet Shop

Now for three games that I did play an active role in: Wonder Zoo, My Little Pony and Littlest Pet Shop. Note that they are all freemium games. Yes, the exact kind that you can get off the AppStore for free, but extract money from you later by exploiting your psychology. It’s a diabolical scheme, but a good coder puts himself beyond petty things like good and evil. It’s all just 1’s and 0’s in the end, and the weak-willed will always be susceptible to mind tricks anyway. They all run on both iOS and Android. We do not discriminate! (except against Blackberry, Palm and Windows… oops!)

All of these games were developed on a framework that I helped architect and wrap around Daniel Stephen’s RKEngine. (I can say that because it’s in the credits!) Note that when I say architect, what I really mean is that a few mates and I wrote some of the initial base classes and processes, but because our engine team was tiny in its infancy, everybody (and I mean EVERYBODY) chipped in bits and pieces. A true Frankenstein framework, but it LIVES!

Now would be a good time to give a shout-out to Remi Akilapa, who passed away unexpectedly during the very early formative years of this framework. He was a brilliant coder and engineer, who had a tremendous stabilizing influence before we found our footing. We kept each other sane through countless meetings with designers, artists and producers, sharing the mantle of technical leadership that neither of us really wanted to bear. Thankfully, I don’t  have as many meetings to attend now that the studio has had time to mature. I would much rather be writing code. RIP my friend!

MechWarrior: Tactical Command

Finally, a note on a game that was not made by Gameloft. MechWarrior: Tactical Command was released by Personae Studios in September 2012. I worked with them part-time for a year, departing roughly 2 years before the release date. By that time, we had  established their base engine tech, as well as a couple of (very) rough prototype levels that the team put together during one amazing week of glory. I don’t know how much of our work made it to publication, but I’m glad it did finally hit the store. The sad news is that it is iPad-only, so I won’t get to show it off.

The Big Red Button Game

Posted: February 15th, 2011 | Author: | Filed under: Projects | No Comments »
Big Red button

Big Red button

Alright, this isn’t really a full-fledged project so much as an experiment with technologies. I was contracted to construct a Facebook game The tool of choice was Unity3D, and it was to be a web-based game. As with all public-facing projects, it always pays to know exactly what happens when you hit that publish button and release it to the wolves. Hence, I created this nonsense game and launched it, just to see what would happen.

As for what it is, there’s a big red button on the screen. When you press it, you win the game. I’m sure I can make up some philosophical BS  about it given enough time. It has a high score table, and is integrated with Facebook, using the API to grab both the user details, as well as post personal best high scores to their wall.

Unity 3D

Unity was chosen because the proposed ‘other’ game was to comprise of both 2D and 3D components. It was uncertain if it would later extend to other platforms. Also, the development period was rather short, encouraging the use of rapid development tools.

From my previous rants on Unity, you can probably tell I am not a big fan.  I would probably still recommend it for project teams that are artist heavy and programmer light, but generally demur from using it myself.  However, this time I bit the bullet and gave it a go.

Developing a web app is easy. Just set a target in the build settings and say what size you want the window to be and voila! Automagic! In fact, most things are like that. The UI system was pretty ugly, but I spent some of the project budget on SpriteManager 2 and EZGui which significantly increased the automagicalness.  All the dragging and dropping somewhat irked me and made me feel unclean, but that’s just me. In truth, it was quite easy to use.

The editors, UniSciTE on Windows and Unitron on Mac, were considerably underwhelming. I ended up going back to my full-screen Vim which I love so much. However, every now and then, I’d accidentally double-click a script and the editor would jump out in my face as if it were Halloween. An integrated text editor would do wonders for a product like this.

Communication between the Unity web-app and its home web page scripts was fairly straightforward. Communication and fetching other web resources via PHP scripts was equally  easy. The unfortunate thing is that a built-in security “feature” prevents you from loading pages that are not in your domain. Which means that if my PHP scripts are on my web server, I can’t access them from a local build but have to either upload the build to server or install PHP and Apache and whatever else on my local machine, which is decidedly not cool.

One other thing is that the Mac build of Unity is significantly less polished and clunkier than the Windows build. Importing of assets takes longer. Certain windows seem to lose their graphical context until you grab the window and drag it around the screen. Also there are slight differences in workflow. (e.g. You can’t name the webplayer object when you build it under Mac Unity, but you can under Windows) It’s almost as if Unity has two teams. They put the ‘A’ team on the Windows build and the ‘B’ team on the Mac build, gave them the same specifications and let them develop independently.

Facebook API

The Facebook API has changed considerably since I last used it scarcely more than a year ago. You no longer have to put weird strings in the Application settings. Instead you can access all the functionality through their Graph API. Feed your query to the specified URL and things just happen! It also comes with JSON support, if that is your thing.

However, I had to give up on quite a bit of scripting because the Unity web player appears to render on top of everything, no matter what fancy CSS tricks you play. In the end, simplicity wins.

The tools that Facebook provides includes statistical information (they call it ‘Insights’) which gives you a rough idea of how many people are playing the game,  the number ‘likes’ you are getting, and the volume of comments.

One unfortunate thing is that there are actually 2 pages for each Facebook app. One is the actual application page where you can play the game. The other is some sort of fan page for posting comments, news updates and the like. A big mistake I made was promoting the fan page rather than the actual app page.


Unity is certainly a viable platform for developing Facebook games. Facebook and server integration are relatively simple, and there is a high degree of automation. Webplayer installation is seamless for the most part. SpriteManager 2 and EZGui are must-haves for any sort of 2D or UI work. If your programming team is small and in numbers not very experienced in general development, this is the ideal engine to use.

The final ‘game’ can be found here.

Introducing… Darwena

Posted: September 21st, 2010 | Author: | Filed under: Projects | 2 Comments »
Darwena was named after a friend's succubus in WoW. It's pleasing to the ear and all the good names were taken.

Darwena was named after a friend's succubus in WoW. It's pleasing to the ear and all the other good names were taken.

New pet project! Given that I’ve been most mercenary and haven’t really had many projects of my own, that’s a big deal! So what is Darwena? Darwena is going to be a new game engine. “Blasphemy!”, I hear you mutter under your breath. Indeed, we put indie developers who want to develop their own engine in the same class as those who want to make an MMO. Stupid stupid waste of time when there are excellent free engines like Ogre3D, HGE and many others.

And you would be right. But nevertheless, I’m pursuing this for a few reasons. First, for education. Think of the kids! This will be my new platform on which to teach OpenGL. Modern engines are either too complicated to dissect easily, or miss the boat when it comes to practical game development. Secondly, this will be a lightweight platform for development of Casual downloadable games for the desktop and iPhone platforms. Ogre is great for 3D, but it’s pretty heavyweight, especially for the smaller apps. Last but not least, it gives me a playground to experiment with procedural techniques designed to make artists redundant in a totally malleable framework.

So, what’s the plan for the engine? These will be the guiding philosophies:

  • It will be based on OpenGL soley, with provisions made to extend to DirectX at a much later date.
  • It will run on Windows, OSX, and IOS. It might run on Linux too, if I have the time.
  • It will be lightweight. Specialised utility libraries like libpng, zzip and freetype may be employed, but we will strive to avoid the bloat of bigger, more congested APIs.

Phase I will be a pure 2D framework where we take advantage of GLSL shaders and scripting to provide a fluid 2D gaming experience. Heaps of attention will be poured onto the material and GUI.

Phase II will be the shift to 3D, with mesh imports, terrain and animation. High hopes of having procedurally generated meshes, but we will have to see.

Phase III incorporates networking for multiplayer play as well as social networking aspects like Facebook postage, high scores, achievements, etc.

So will this take to the sky and make me as rich as the folks over at Epic? Or will it crash and burn like the thousands of hopeful projects we politely snicker about? Only time will tell.

It breathes! It breathes! http://www.darwena.com


Posted: February 3rd, 2010 | Author: | Filed under: Projects | 7 Comments »

Oversight is a stand-alone mod made for World of Warcraft. It is a unit frames Addon specially designed for arena and battleground play to present data in a way that is easier to assimilate by the average or beginner player. It may also find use by advanced players when making videos to better illustrate their strategies and swaps as targeting is made very visible to the user.


Latest Changes in 1.02(a)

  • Fixed issue where in BGs and raids, the team members would be wrongly locked.
  • Updated to be compatible with patch 4.01
  • Temporarily disabled spec detection.
  • No default buff list provided till I have time to weed through the spell ids. Existing buff lists on old characters however, will remain. You can still copy profiles between characters.

Latest Changes in 1.01

  • Pet health bars and bars in general made more responsive.
  • Removed now-redundant Russian translation for buff list.

Latest Changes in 1.0

  • Coloured health bars to turn red with health status
  • Made default buff list local agnostic
  • Bugfix for DRs not always disappearing when expired
  • Bugfix for not all frames updating if the same unit is in multiple frames
  • Coloured player names with their class colours

Latest Changes in 0.91

  • Added option to turn off cast warning sound
  • Bugfix for said warning sound not always going off
  • Bugfix on PvP Trinket indicator to make it locale agnostic
  • Added Russian translation for default buff list. Translation courtesy of Кагасиро – Вечная Песня E


  • Movable, scalable unit frames arranged in a pleasing circular formation.
  • Original Blizzard unit frame artwork, because circles are cool.
  • Enemy frames are party targets during normal use, but are arena opponents when inside an arena.
  • Spotlight targeting system to visibly show who’s targeting whom, with a number of spotlight options.
  • Cast bar for each tracked unit.
  • Aura configuration so that specific buffs/debuffs may be displayed for ally or enemy players. Aura’s may be shown in a ranked list of seven, or may replace the character’s portrait.
  • Configurable Unit Frame highlighting for poison, curse, magic and disease debuffs on friendly players, as well as dispellable buffs on enemy players.
  • Race portraits for all units except pets.
  • Raid target icons display.
  • Spec detection and display.
  • Locking of party member frames so that the same party members are displayed in the same order and same raid target icons when entering battlegrounds or arenas.
  • Sound alert for when the focus target is casting a spell, or when the target is casting a spell if there is no focus target.
  • Diminishing returns tracker that tracks up to six diminishing return types.
  • PvP Trinket tracker.
  • Profile manager to copy configurations from other characters.
  • Extremely low resource usage.
  • Does not depend on the combat log.

Known Issues

  • Diminishing returns will count down on a selected target if the target was previously selected and had a non-expired debuff of that DR type. This is because Oversight has no way of knowing when exactly the debuff expired unless somebody had it targeted at the time.

Ninja Assassin

Posted: November 5th, 2009 | Author: | Filed under: Projects | No Comments »
Title Screen

Title Screen

This is an iPhone game based on the soon-to-be-released movie of the same name. It’s basically a horizontal scrolling action fighting game that uses swipes and gestures to control combat moves.

Menu Screen

Menu Screen

Interestingly, for this project, I worked on everything but the main game itself. The accelerometer physics-based main menu to the Facebook highscore upload functionality. I even coded a bonus feature that is multiplayer over bluetooth and wifi (the main game, interestingly, is single player only) that involves throwing virtual things making use of the in game accelerometer.

The movie is due to be released at the end of November, and the game is already out at the iTunes Store.

J2ME Virtual Machine

Posted: November 5th, 2009 | Author: | Filed under: Projects | No Comments »

This is a mobile J2ME project. From a central Midlet, users can download various games in the form of scripts and resources from a central server. This midlet then interprets the scripts on the fly to execute the game content.

The project makes use of the JSR 75 File Connection API as well as tools such as LWUIT and FScriptME. I basically took all these components, and welded them together into a functional scripting system through which you can create simple animated games. This was then handed off to the UI artist/programmer who I suppose will make it pretty and add polish.

They are probably still doing that now, so no names, no pictures, all in the name of the mighty NDA.

Crane Simulator

Posted: November 5th, 2009 | Author: | Filed under: Projects | No Comments »

This program simulates dock-side cranes, and is used as a training aid for aspiring crane operators. The hardware resembles the interior of the crane cabin, with 3D graphics and physics simulating the actual dockside environment. There is also a trainer station, from which trainers can both modify environmental effects as well as observe the progress of the trainee. Multiple trainees can work within the same simulation.

There was a small team of developers working on this, and my job scope was to engineer the input system, interfacing it with the hardware, as well as providing a “virtual console” which can be used to test the product on a PC. I also provided consultation for the programmer who was in charge of implementing the physics using the PhysX engine.

The graphics implementation was farmed out to yet another company, which was pretty screwball. In the end, it was a huge project that employed a few individual disparate teams. It would probably have been much simpler to have all the development done under one roof.

I’m not sure if the company has gone live with this, so no pictures or names for now.

Virtual Store

Posted: November 5th, 2009 | Author: | Filed under: Projects | No Comments »

This is a shopping store simulation where customers can browse store products and purchase them through a realistic 3D application. The virtual environment is an exact replica of the brick-and-mortar store itself. The purchasable products are also exact look-a-likes of the real goods. Customers can manipulate these products, rotating and zooming in on them in full 3D.

This was all done using… wait for it… the Unreal Engine 3! Say overkill? It’s amazing what can be done when you have budget. We were sent to Shanghai for a 3 day training course and consultation. After that, we rolled up our sleeves and got to work. Our artist was going balls-to-the wall with all the fancy shader effects. I’m pretty sure he was in a constant state of artgasm.

Meanwhile, I got to touch on the finer points of Unrealscript and the underlying engine. What we came up with in the end was pretty darn good looking. But from what I know, it isn’t really launched (yet?). So no pictures. *shakes fist at NDA*