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

The Meaning of Life

Posted: March 6th, 2011 | Author: | Filed under: Soapbox | 3 Comments »

Where do I begin? I am not a religious person. While I do not believe in God(s) per se, I do not deny that there could well be something out there. I also recognize that it is beyond my ability to determine what is what in the great beyond, so I choose to simply put that question to the side. Perhaps one day, when I recline comfortably in my grave, I will be able to shine some light on that issue. Today is not that day, or so I hope.

So what do I believe in? Some people believe that they are put on this Earth for a purpose. More power to them because it makes life or any other endeavour so much easier when there is at least a vague direction to follow. I do not entertain such a luxury. I believe that it is up to me to find my own way, purposeful or not, and live through life with no regrets but my own. I refuse to live at another’s whim, and would not expect another to live at mine. True, I do owe a great deal to a lot of people – family, friends and other people in my life. However, as much as I am indebted to them, I claim this life for my own and reserve messing it up as my own privilege.

I began my working life in a small company called Coaster Computer Services. My boss, Victor, was a shrewd small-time businessman who had me creating software solutions for other small businesses. He is also the man who had the ability (which he often exercised) to use the word “fuck” in the most gentle, non-vulgar and non-offensive way possible. I learnt a lot under his wing including how to deal with clients and how to develop software from design to delivery and beyond. As pleasant as working there was, I had far more ambition (in other words, I wanted more money, more fame and more glamour) than that job could offer and through a series of events moved on to the next phase in my career.

From a small-time software house, I spread my wings and starting working on multi-million dollar projects as an employee of IBM. I was part of the business consulting group, working in a large team spanning four continents creating and deploying backends for the largest banks in the world. I was part of the working class, with my formal (by today’s standards) shirt and pants, walking down the street to work with millions of other people just like me. The hours were gruelling, with team members turning up for work at the office at practically any time of the day or night. I was having the time of my life.

The group I was in worked under the absolute best project manager I’ve ever had the pleasure to work for to this day. His name was David, a former techie turned manager turned director. He was our guardian angel, protecting us from office politics, enforcing food and rest when we overstretched our limits and basically steamrolling through anything that got in the way of us doing our jobs. He is well-respected, probably filthy rich and obviously enjoyed his job. One day, I had a good look at him, where he was in life and the lifestyle he was living. Was this the role-model I could aspire to emulate ten or twenty years down the road? I looked deep into myself and realize that the answer was no.

It is at this point that I really started to understand myself, life and the world in general. Money, I realized, was only a means to an end. What is that end? Personal satisfaction. Many people go through their lives slogging through work mindlessly so that they may raise enough money to “buy” happiness in the form of material creature comforts and a better quality of life. While I am all in support of material luxuries (yes, I’m no Gandhi), what disagreed with me was the slogging part. Why spend a majority of your life doing an activity that you do not enjoy just for the sake of being happy during whatever time is left over? I decided to cut to the chase. I’d be happy first and worry about the money later.

I was always fascinated by video games, both playing as well as creating them. (though admittedly mostly playing them) In my university days, I had three main priorities. My top priority was… competitive Scrabble. Yes, I am and have always been nerd, thank you! We had a great team that trained hard together. The camaraderie was so great that I felt I was a significant part of a bigger whole. We played, we conquered, we celebrated. My second priority was the Leviathan. The Leviathan is an online text-based roleplaying game. Think of World of Warcraft but without the graphics. While I played that for a while, I soon went into development, becoming a Wizard (i.e. a coder) and created new areas and mechanics for the players. It was set up so that the development environment was part of the live environment. It is a coder’s paradise with the instant gratification of player comments and complaints as they explore your new creations and their moans of anguish when you inadvertently crash the whole game. My third priority was scraping through on studies so that I actually got my degree. I hardly attended any lectures or tutorials but studied on my own as well as in a study group. I admit this was mostly done so that I could devote more time to my first two priorities.

Alright, back to the career bit. During my days in IBM, I did somehow manage to eke out some personal R&R time. I played my first ever MMO which was Dark Age of Camelot. In this game, I had the pleasure of making the acquaintence of a fine fellow called Alvin. Alvin himself, was in the fledgling game industry in Singapore. He set up his own company, Nexgen Studio, and just simply went for it. With a mish-mash of interns and recent graduates, he managed to produce an FPS demo. It sucked (sorry Alvin!), but it was a good start for a business still in its infancy. Like all other fresh-faced developers with delusions of grandeur, he wanted to create an MMORPG. (admit it, everybody goes through that stage) He had a business plan, a design, and even a comprehensive background story. He showed me what he had, and I promptly quit my job and turned up at his doorstep to work for next to nothing (not that he could afford to pay anybody at that point). He expressed amazement at encountering somebody as insane as he was.

We worked hard for the next year and a half. Though the going was tough, it was also a lot of fun. I got free reign to do just about anything ranging from project management to marketing to meeting VC’s to programming. It was a blast. I gave the company a year to make or bust. Much to my chagrin, neither happened. Instead, we merely survived – somehow managing to subsist without going anywhere. It was a hard thing to do, but I informed Alvin that I was leaving the company. By then, we were good friends, almost brothers-in-arms. As I mentioned at the begining of this whole tirade, I live this life for nobody, good friend or no. So we parted ways and I went into the glorious world of freelancing. I am happy to say that after I departed, the company has done quite well for itself – a happy ending afterall.

Why did I become a freelancer? The honest truth is that I wanted to set up a company of my own but was too chickenshit. Instead, I would do the market research and find out how other companies operate from the inside, examine their challenges and mistakes, and learn from them while they footed the bill. Yes, I do not deny that I am an evil genius. You would think that making a living as a freelancer is difficult. In truth, it is disgustingly easy. All you need is the will to work hard and some semblence of discipline to maintain professionalism. You do your networking; shameless self-promotion. You make sure you do a good job and that your clients are satisfied, and word will spread. Business will flourish.

The lifestyle is great. I spend my days coding or meeting interesting people. I am seldom confined to an office for more than a couple days a week. I can truthfully claim to do game development in various branches of Starbucks Coffee and Burger King around the island. If I need a breather, I can simply take on less jobs. So it seems I have attained game developer nirvana. That is a bad thing.

If there is something that I have learnt about myself, it is that I dislike being comfortable. The freelancing job fits me quite well because I can flit from place to place, project to project, and it is always different. I learn new technologies and techniques along the way and all is good in the world. However, lately, I have been finding it increasingly difficult to sit in front of the screen and do actual work. If I were the typical Singaporean, I would grit my teeth, force it through with sheer willpower and get the job done. Obviously, having just said that, I did exactly the opposite. I have been spending a fair amount of time in introspection (i.e. sitting around and doing nothing). There is a reason for my failing drive and that reason is not laziness. I have always been lazy and that has never gotten in the way before simply because I love my job too damn much. So what do I want out of life and why does it feel like my current direction is off-kilter?

I definitely still want to make games. The original plan was to set up a company so that I can make the games I want to make. After all, I have already learnt so many lessons from all my previous suc… clients. Why not put them to their intended use? Have I not suffered through all manner of brain-dead or ludicrous “designs” and “concepts” that I have earned the right to make something on my own? To be honest with myself, I don’t even care if it sells or is profitable. I am past caring too much about money other than the occasional need to eat. Yes, there is a flaw in the master plan that I failed to perceive when I set out on this whole venture. As Steve Jobs has said, this changes everything… again.

If I were to set up a company, I would be too embroiled in administration to be usefully engaged in the development process. Sure, I would have the privilege of being the boss and well… bossing people around. “Yes, you should do this. No, don’t do that. This is the way to do it… Where’s your company spirit? Worship me because I pay your salary!” The truth is, as has been blatantly demonstrated to me, management messing around with the development process too much is a bad thing. Bad for the project, bad for the team. I would never have the fine-grained control over the project that I cherish.

To add to that, I want to do other things as well. I would love to learn how to draw/paint, play beautiful music, engage in creative writing. I have no illusions of being “good” at any of them, but these are indulgences rather than core skills. I want to experience life to the fullest and take in all that it offers me and then some. I want to always keep moving and never stop till day I cannot move anymore. For all this, I would be willing to be the serf instead of the ruler. Who in their left mind would not?

With all that said and done, where do I go from here? I have decided on two long term objectives. First, I want to make the shift to game design. Second, I want to get out of Singapore and move to somewhere completely different. Make no mistake, Singapore is a great place. It has low crime, good infrastructure, excellent quality of life and is probably one of the easiest places to make money in. However, with 6 million people crammed on a little red dot, all chattering and yammering as they go through their lives like automatons… I need a change.

Ultimately, is that not what life is all about? I pride myself on following through on arbitrary decisions made after a period of daydreaming and being non-productive. You cannot chase dreams if you do not have any and one dream is as good any other, no?

I wandered lonely as a cloud

Posted: February 19th, 2011 | Author: | Filed under: Tutorials | No Comments »

I wandered lonely as a cloud
That floats on high o’er vales and hills,
When all at once I saw a crowd,
A host, of golden daffodils;
Beside the lake, beneath the trees,
Fluttering and dancing in the breeze.

Continuous as the stars that shine
And twinkle on the milky way,
They stretched in never-ending line
Along the margin of a bay:
Ten thousand saw I at a glance,
Tossing their heads in sprightly dance.

The waves beside them danced, but they
Out-did the sparkling leaves in glee;
A poet could not be but gay,
In such a jocund company!
I gazed—and gazed—but little thought
What wealth the show to me had brought:

For oft, when on my couch I lie
In vacant or in pensive mood,
They flash upon that inward eye
Which is the bliss of solitude;
And then my heart with pleasure fills,
And dances with the daffodils.

– Willam Wordsworth

Put it on the cloud!  The not-so-latest trend of web-hosting has finally caught up to me.  Today, however, we’re going to take a quick overview of Amazon’s Web Services (AWS) so that we can dream of the possibilities it may bring to our own development projects.  AWS is, in fact, quite well used by some of the larger casual game developers like Zynga to manage their large user base.

Amazon provides its services not as one, but rather several packages. This can be is daunting to a first-time user.  However, upon closer inspection, we don’t really need to know about all the nitty gritty details. Once you activate one service, all the other dependencies are automatically bundled in, saving you from the headache.

Computing Power

This is the primary service we are concerned about, Amazon Elastic Compute Cloud (EC2). Amazon has a large number of servers that can provide a tremendous amount of computing power. What EC2 does is create a virtual machine instance on this server farm, on which you can basically run whatever it is you want. You get billed on the amount of CPU time you consume. So the more intensive your tasks, the more you pay.

EC2 instances can easily be set up via a web-based control panel called the AWS Mangement Console.  There are a variety of different types of instances that you can create, depending on your expected computing load, ranging from micro to large. You can create as many instances as you want to, as long as you have the $$$ to back it up. Amazon provides a set of images that you can have pre-installed on the newly created instance. It boils down to a choice between Amazon’s version of Linux, Suse, and various flavors of Windows. I went with Amazon Linux, since that was free and I’m cheap.

When I created the instance, it was up within about 30 seconds, with a bare bones OS install.  It handily creates an ssh key-pair for you, so you can readily ssh into your new instance via Amazon’s public DNS server.  Adding packages was easy as you simply use yum. Unlike setting up your own Linux environment, installing packages is pretty fast since they are all hosted on the same server farm. I just installed gcc and did the obligatory “Hello World”. Yup, it works!

You can assign up to 5 elastic IPs to your instances. By elastic IPs, we mean public IPv4 addresses. These come free of charge, and will stay constant as long as your instance is up and running. However, if you have an elastic IP attached to a stopped instance for more than an hour, they start charging you for it. Kind of like how those buffet steamboat places used to charge you for whatever leftover food you have. It discourages waste. Amazon does not provide domain name services, so you will need an external provider if you want a fancy non-numeric URL.

Once you have server configured, you can in theory, save the configuration as an image or AMI. This allows you to then spawn multiple instances with the same configuration if load gets a bit high.

Data Storage

Your EC2 instances come with some space for you they call ephemeral storage. What that rather long word means is that once that instance is shut down, all the data on that instance is gone. The purpose of that storage is more for run-time operation rather than long term operation.

What you can do is use something called Elastic Block Store (yes, they really like the word “Elastic”) or EBS. This is simply storage space. Each EBS can be attached to your instance and mounted as a volume, providing you with persistent storage. What’s more, you can image your data and create multiple snapshots for use as backup, or for other instances to serve up data. Via Amazon’s Simple Storage Service (S3), this data can be transmitted between Amazon’s four data centers (2 in the US, 1 in Europe, 1 in Singapore).

Load Balancing

Amazon provides load balancing via… you guessed it – Elastic Load Balancing. Unfortunately for us game developers, it does not automagically load-balance your homebrew MMO. It is instead, more catered for web servers. So if you are writing a PHP-based MMO, more power to you! If not, you will have to architect your load-balancing mechanism by yourself. What this means is that your server code will need to be written atomically enough so that multiple instances of your code can be run concurrently on different virtual machines. In addition, you will need to write load balancing gateways that dole out incoming traffic to the free servers.

To aid you a bit, Amazon Cloudwatch provides you with data such as CPU and Memory consumption so that you can gauge when you need to spawn additional instances. 3rd party vendors like Rightscale provide additional paid services to enhance scalability by allowing you to rapidly spawn a large number of instances from pre-written scripts, even allowing dynamic resizing based on server load.


Amazon Web Services are indeed fairly easy to use. The scalability means that you can transit from a development environment to a deployed one with relative ease. Signing up was fairly hassle free. Just provide your credit card and telephone number and they will verify you. Given that the first 750 hours of compute time on a micro instance are given to you free of charge, there’s no reason not to sign up and play around with it yourself. However, once again as we oft do learn, it is no silver bullet. Making your game truly scalable still heavily rests on the shoulders of the developer. All Amazon does is provide the infrastructure.

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.

Nerding Out The Windows Console

Posted: February 3rd, 2011 | Author: | Filed under: Tutorials | No Comments »
PuttyCyg to the Rescue!

PuttyCyg to the Rescue!

So you bought a Mac, and oohed and ahhed at the graphics and the user interface (or maybe you hated it, I don’t really care).  Then the inner nerd called to you and you started messing around with the terminal, loving the linux-like console and enjoying the power that a real OS command line gives you. Maybe you even went so far as to customize the look of your console, perhaps installing Visor in the process for a beautiful full-screen terminal. Ahh, how we love our text.

Then you turn back to your Windows 7 machine and oh how loathsome it is to work with now! MS Dos Prompt just does not measure up. Even their new-fangled PowerShell does not satisfy. We could perhaps forgive this if we could at least get it to run in full screen. But woe is you as  you realize they took out that full-screen mode feature when they moved from Windows XP to Windows Vista. So what’s a poor nerd to do?

Well, if you are a true nerd, you’ve probably heard of Cygwin. Back in the day, it was a way to run a linux distro on a virtual machine within Windows itself. Comes with X11 and all those fancy goodies. Well apparently, they had a change in philosophy when I wasn’t looking and it now comes with a minimal install. You have to choose the packages that go into your build, making it leaner and meaner from the get-go. So yes, go forth and download that. Additional packages to install would be inetutils (which gives you ftp and and stuff like that), as well as ssh (why Windows doesn’t have this natively is beyond me). If it so tickles you, you can get good stuff like gcc and automake as well. And of course, we can never forget good old Vim. If you’re an Emacs fan, that’s available too.  And if you are not quite so nerdy, there’s always stuff like Nano.

So you installed Cygwin and got it running and…UGHGHHH!!! You’re still stuck with that same lousy non-fullscreenable command prompt, albeit with Unixy power. Well, not to worry. Go and get a special version of Putty (this is the program that windows people use to overcome their ssh deficiency) called PuttyCyg.  This will allow you to start up a session in… you guessed it, your own Cygwin instance! Also, unlike the command prompt, you can maximize, or even full-screen it! Amazing!

An interesting side-effect is that since we installed the ssh package, we can ssh directly from our command window, thus voiding the original functionality of Putty. An irony that all true nerds can appreciate. To streamline the whole process, you can alter the windows shortcut to Putty, and feed in a command-line parameter to get it to start up your Cygwin session on the click of a button!

All this seems like an overkill if you consider my original intention. All I wanted was a full-screen Vim. Sure, there’s gVim, but it sucks in the full-screen department as depending on your font size, it’s not quite full screen. It also comes with fancy schmancy mouse and gui stuff that makes it quite… unVimlike.  So yes, I brought out the sledgehammer to squish the itty-bitty ant, and yay! It’s dead! Mission accomplished.

Taking Music Seriously

Posted: January 26th, 2011 | Author: | Filed under: Soapbox | No Comments »


Just the other day, the original Die Hard was shown on TV… and it was good!  There was one little niggle that bothered me though. During the action scenes, these weird orchestral swells would play in the background, supposedly to build up tension.  I supposed back in the 80’s, that was the norm and we never gave it a second thought.  Today, however, it just seems so out of place.

So I went through my video library and looked at two films that I really liked for their style and soundtrack… Requiem for a Dream and Lola Rentt.  In each of these, the movements on screen, be they full screen transitions or simple movements were carefully choreographed with the music. The music itself complemented the atmosphere in each of those films – dark and foreboding in the case of Requiem, speedy and action-packed for Lola.  There was a phrase to describe this sort of cinematography. It took a little while to wrack my brains before I got my “Ah hah!”… MTV style.

So for more inspiration, I flipped over to the MTV channel which I haven’t watched for years… decades even. And lo behold! MTV is no longer like that. All it seems to be now is music playing with general “stuff” happening on screen. There’s no oomph to it like I remembered from the 90’s. Youtube to the rescue… I found curiously enough that the Korean music videos actually do feature this style, as well as a lot of imagination put into it. Videos from SNSD, Wonder Girls, JYP… all had that cutting edge and were enthralling (and not just because of my inner perv). I also realize that this was something I was pretty conscious of in the making of my Oversight video, even without formal video editing training.

So how do we bring this over to game development? Other than rhythm games, we seldom see music tightly linked with the action on screen. This is partly because it is really hard to predict the player inputs. But it is also largely because we, as game developers, tend to treat it as an afterthought. Yeah, with my huge army horde marching in, I know I should play something majestic to add atmosphere. But do I ever go so far as to have them marching in step with the music? Not really.

Part of the reason why we don’t really think that way is because of the tools we use. Traditionally, we at most tie the playing of music pieces to certain events. We don’t have tools that, for example, generate an event with every bass beat in the music score.  Why? Because nobody ever thinks that way. We are stuck in a rut.

When I get around to the audio portion of Darwena, I would like to incorporate these ideas, and see if they have an impact on the type of games that get produced from it. Would it even go so far as to produce a signature style? “That must be a Darwena game because it has that rhythmic feel!” That’ll be cool to hear.

Programming, How To

Posted: January 11th, 2011 | Author: | Filed under: Tutorials | 5 Comments »
Problems in Programming

Problems in Programming

Good programmers, especially game programmers have this mystique about them.  They seem to be able to juggle ginormous amounts of machine gibberish and cobble it into an application or game that does all sorts of wonderful things, almost as if it has a life of its own. People think that they must be really really smart, and for the most part, they let them think that. Hey, if you can’t be handsome or muscular, at least you can be clever, right?

What they told us

Most courses introduce programming as a set of instructions that the machine follows. “Look, the computer looks for this keyword called ‘main’, then it does whatever you put in between the brackets.” And thus they are introduced to the wonder that is… “Hello World!” Hey look! you can make a couple of words appear on screen, therefore you are making progress! Wonderful! After that, they are introduced to constructs like branches and loops, maybe even functions and classes. The programs the student writes becomes more complex until they get stuck.

“Yeah, I get how these programming constructs work, but how do I put them together to make the program do what I want?” At this stage, they get taught UML. Yeah, this is what we call software engineering, where we plan out how the program will work by drawing pretty pictures! This gives rise to two new problems. First, how the hell do you know if your pretty picture is correct, given that you could draw it any number of ways and still be a somewhat decent representation? And after that, how do you translate it into actual usable code?

This is when they get introduced to design patterns. Hey look! These are like standard answers thought up by some four very smart people? How do we know there are only four people? They are called the Gang of Four, duh! Come see their voluminous tome of knowledge! For each problem that you are trying to solve, find the pattern that fits and plug it in. Hey presto! We end up with a group of programmers who think that programming is really really hard, cobbling programs together out of disparate pieces of other peoples’ code and tweaking the variables, hoping that everything will magically come together.

Take a deep breath…

and forget all that for now. Let’s go back to the basics. What is a programming language? This is the medium through which you direct the computer to do what you want. Plain and simple. It comprises of two parts, the “Programming” and the “Language”. Let’s go through the easiest part first.


Language is exactly what it sounds like. It’s just a different way of speaking/writing. It still does the same thing, which is conveying information from one party to another. There is no difference between a programming language and a normal language like Japanese or English, except that it is much much easier to learn. Why is it easier to learn? The vocabulary many times smaller than a traditional language. For example, if you want to understand C, all you need to understand are less than a hundred words. Compare that to the 171,476 (as listed in Oxford) words in common use for the English language.

If you want to learn Java, all you have to figure out is what words correspond to what you are used to using in C, and voila, you are a Java programmer! In fact the only time you find real major differences is when they don’t support certain features. These however are easy to categorise.

  1. Is it a generic programming language? That means you can use all the good stuff like templates to get around data types. (e.g. C++, Java)
  2. Is it an object-oriented programming language? That means you can use classes and objects. (e.g. Python)
  3. Is it a procedural language? That means you can use functions. (e.g. C)
  4. If it is none of the above, you are probably coding in assembly and have to conceptualize all those nice features by your onesome.

Whatever the case, the art of using a language is merely translating from your native tongue (which I presume is English since you are reading this), into the programming language of your choice. What’s that stuff that was in your native tongue that you have to translate? Why, that is the instructions you wanted to give the computer to tell it what to do, and this stems from the next big part… the “Programming” part.


Now that you know how to express yourself properly, you now need to tell the computer how to do stuff. Unfortunately, in spite of decades of technological progress that boasts of multi-core processors and terabytes of memory, computers are still as dumb as a brick. You need to explicitly tell them what to do each and every single step of the way. Unfortunately, due to our poor conditioning thanks to our exposure to ambiguous languages like English, most people struggle in drilling down to the absolute steps that are necessary to accomplish the task. It is, however, not a complicated process.

It starts of with a problem. (If you didn’t have a problem to solve, why are you writing a program? For fun? Blasphemy!). You take this problem, and you break it down into the steps you need to solve it. Each step then in itself, poses a problem. So you take all of those, and break those down, until the instructions become atomic enough for the computer to execute. That sounds a bit abstract so lets make an analogy.

Assume that you are on the couch, watching TV, when you get the overwhelming urge for a beer. So there you have a problem, need a beer. Let’s further assume that you, as the thinking programmer, are the brain, and you have instruct the stupid non-thinking computer, which is the body. So being so smart, you say, “Go to the kitchen, get the beer from the fridge and drink it.”. The body goes, “Go?” So you have to clarify, “Get up, turn right, walk two steps, turn right again, walk five steps, then turn left.” To which the body haughtily replies, “Get up?” So you have to go, “Flex both quadriceps, while pushing arms forward to maintain balance, until fully extended and upright.” Maybe this is something the body is finally capable of doing, so hurrah! Now you can go through the process of instructing it how to walk…

If you are lucky, some guy in the past might have already figured out that walking is a good ability to have. So he compiled as set of instructions on how to walk, which you can then feed to the body, merely having to tell it where to walk to. Well, isn’t that easier! These pre-made instruction packs, commonly called APIs or SDKs save you from having to laboriously go through each and every minute detail. However, before you use these instruction packs, buyer beware! The walk might not be perfect… it might have a limp! Or it might be only good for the first ten steps. Or it might leave you prone to falling down on certain terrain. Always read the fine print and test it to make sure it does what you think it is doing and be aware of any side effects.

So now you have the gist of how to program, you might find yourself encountering a couple of problems. The first is that you can’t figure out how to properly break down a problem or part of a problem. The second, particularly for game programmers, is that your set of instructions is so long and convoluted that the machine simply can’t execute it fast enough. Regardless of which, programmers tend to apply the same solution… “Think harder!”.  So you end up with these zombie programmers staring mindlessly at the screen, wracking their brains at the problem till their heads hurt and they slowly lose their minds.

The secret that eludes these programmers is that it isn’t matter of finding a solution. It is instead perceiving the problem. That’s right, it’s a matter of perception! Oh yes I see you, the artist giggling in the corner about our silly programmer post. Indeed, the artists have known these for years. Before an artist learns to draw, he is first taught to see. Once he can perceive the objects in our world in the correct way, he can apply it to canvas. Similarly, depending on how you perceive the problem, different solutions will become apparent. How do you change your perception? You have to identify and challenge your presuppositions. Tear down the things that you always take for granted and ask what if? Ask yourself what the problem is really about, and what else can it be about instead? The first few times, this can be really hard, but as you go on, it gets easier because *gasp* you are becoming a rational creature! And that is really difficult for a human being.

Good programmers take this concept and push it even further. Even when they are not stuck, they will view the problem from several different angles, and pick the best and simplest solutions that present themselves. That is why it seems that their code is always ten times shorter than yours, simpler, and faster to execute. The more angles they cover, the better pick they will have, and the less code they will eventually have to write. This is why when writing code, 90% of your time should be spent thinking about the solution, and 10% of the time typing it out in code. (Yeah, I pulled those numbers out of my ass, but you get the idea)

So back to our beer analogy, challenge your suppositions. Do we necessarily have to go over to the beer? Can we make the beer somehow come to us instead? Thus we fire up our trusty speech API and yell the magic words, “Bitch! Get me a beer!”. Wait ten seconds (during which you can do other stuff), and a freshly opened beer appears magically in your hand. That, my friends, is what we call elegant programming!

Top 5 Game Development Lessons of 2010

Posted: December 30th, 2010 | Author: | Filed under: Soapbox, Tutorials | No Comments »

As we come to the end of a new year, it is good to look back and observe what we have learned in the hopes that we can all become better game developers. Here, we refrain from looking at the techie nerdgasm bits that are at best transient, and look at fundamentals that we will want to keep through the years to come.

5. “No Nonsense Game Development” is not always enforceable

I thought that I would never say this, but I have met my match as far as keeping down the “nonsense” in game production goes. Under normal circumstances, this should never happen as it is kept in check by the management, who has a high stake in the success of the project. However, just because it shouldn’t happen has never stopped anybody before. The root cause in this case was so fundamental that it cannot be slapped away by throwing out catchy phrases like “agile development”. Instead it is the decidedly human (yes, somehow it’s always humans at fault isn’t it?) traits of insecurity and conceit. Unlike bad communication or management which can be remedied with proper instruction, the human factor can only be conquered by each individual from within.

4. The importance of technical preproduction increases with team size

I have always been a fan of individual programmer creativity. I generally like to modularize the components of the game, give each one a specification and let the programmer create the black box that handles that task. Landing in a project after pre-production and having barely more a week to create a basic framework is sheer madness. However, the pressure of an idle workforce and the hubris in my ability to consistently produce miracles convinced me to “rise to the challenge”.

Of course, it didn’t help that the team was about 10 people strong with a majority of junior programmers and interns. The correct course of action would have been to bite the bullet and halt production, so I could lend more in the way of structure and guidelines, as well as general team training. This oversight cost the project dearly. Would it have been enough to save it? That’s anybody’s guess. Will I learn from it? You bet!

3. Web presence is well worth the time investment for B2B marketing

This was an interesting year in the sense that I spent zero time on face-to-face big event networking, mainly because I was preoccupied with ongoing projects. However, the information provided on this website, coupled with maintaining a strong presence on networks like LinkedIn and Facebook appeared to keep the job opportunities streaming in at a respectable rate. Even now, less than a week after I stepped away from my prior post, I have not one but two offers from separate parties for my next endeavour.

The other advantage of online social networking is that it allows you to gauge the mood, disposition and morale of your staff. They are more likely to vent online, even if they have to do so obliquely lest they incur the wrath of the NDA-toting lawyers. Of course, if they don’t trust you, you will never get to see any of this, Facebook buddies or no. So yes, once again technology is no substitute for the human touch.

2. Time waits for no man

When we doing tests on the iPhone 3GS back in April, we discovered that it had superior graphical capabilities, an order of magnitude more than the previous model. This of course opened the door to a wide range of possibilities and hastened us down the road of ambition and scale. Eight months later, while we still have nothing more than a prototype to show for it, the Unreal Engine has made its way onto our platform, bringing with it the likes of Infinity Blade that while simple in gameplay, takes our breath away in awesomeness. We dragged too long and missed the window.

Perhaps a better strategy would have been to focus more on core gameplay fundamentals rather than technology. While tech is flashy yet fleeting, design is eternal and beautiful.

1. The number one priority for game development companies should be their core development team

Some years back, when Ubisoft was first setting up shop in Singapore, I went in for an interview out of curiosity. What they told me blew away for the totally wrong reasons. They stated that they wished to spend one whole year just training up the team and integrating it with the rest of the Ubisoft family before doing anything serious. At the time I was thinking, “OMG! 1 year without portfolio pieces!”

What I missed was the wisdom of this approach. Your company can only go as far as your team can bring you. If you have a strong team, you can do great things. If you, like many (I hesitate to say all) startup games studios in Singapore, just dive into it hoping to learn as you go along, that team can only accomplish that much. Worst still, if you fail to maintain the team that you have (i.e. high staff turnover), you will forever be stuck at that low but very flat plateau. A company’s crown jewels are not its assets or its vision, but its people.

I don’t know for sure if Ubisoft followed through with their one year program, but from the media I have gathered that they have contributed rather sizable chunks to the Assassin’s Creed franchise. I’ll say it again… you need a strong team to accomplish great things.

Power to the People!

Posted: November 14th, 2010 | Author: | Filed under: Soapbox | No Comments »
Power to the People!

Power to the People!

So, it’s a been a strange week, during which I was given the chance to observe (and occasionally partake) in the manpower issues faced by local development companies. In both cases, the major issue was in tapping the creativity and enthusiasm of the rank-and-file developer. It’s hard to say if this is the result of our uniquely sterile and reticent Singapore culture, or if this affects overseas startups as well.

So in company one, which we shall refer to as the Empire, has a very draconian top-down management style with multiple layers of hierarchy. Employees are not allowed to carry in data storage devices, required to store their personal effects out of the main work area, and are expected to carry out allotted tasks like any standard cog-in-the-machine would. There is a lengthy approval process during which the Emperor will personally appraise every minute aspect of the Death Star design and lay forth to his Stormtroopers what is to be done. This would not be so bad if the Emperor was talented at Death Star design. Unfortunately this is not the case. Every engineer he has knows about the fatal flaw in the design, yet cannot get the message through. As a result, they shuffle listlessly about the deck, engaging in activities like Youtube and Facebook to bury their misery. This in turn leads to a long drawn-out war against the likes of Youtube and Facebook, a battle that sees no signs of ending.

Company two, which we shall call the Alliance, is slightly more “enlightened”. They believe that every soldier should believe in what he is fighting for, and have a say in what that should be exactly. Unfortunately, there are no Leias or Ackbars to champion any causes. Everybody just sort of sits around waiting for somebody else to step up and take the lead. There are long lengthy meetings, where the fate of a planet in distress is discussed in a committee while it gets destroyed. Nobody really knows where the Alliance is going, so everybody treads water, carrying out the necessary actions to ensure survival and little else.

So the question is, is it possible to have a company like the Borg? (yes, I know I’m crossing references) A company where the collective makes decisions, yet they are so finely attuned to each other that there is a strong direction and everything seemingly magically clicks into place. What does it take to make such a company, and is it really for the best? What other sort of business models, sci-fi reference or no, would be suitable for a creative company? While there is plenty of talk about the virtues of Agile methodologies like SCRUM, these are merely processes. What we are interested in is the sort of culture that will give the company the resilience to forge down the rocky game development road, to go where no indie company has gone before…

*Note: Dramatizations have been made for entertainment purposes.

We are being repressed!

Posted: November 5th, 2010 | Author: | Filed under: Soapbox | No Comments »


When I first came up with Darwena, it was innocuous enough. An engine just like any other engine. Nothing outstanding or out of the ordinary. Altruistic in intent, meant for the education of the masses (or at least the masses that attend my classes). But you should never completely trust a game engine named after a WoW succubus. Tantalizingly, she whispered in my ear ever so softly, until at last I came to see reason. We are going to champion the cause of the game programmer.

It is true. We, as game programmers, are being repressed! Take a look at the bonus videos from God of War III. There’s a video for each of the teams that took part in the making of the game. The artists were showing off their character design and animation. The designers were showing off their levels and game mechanics. Then it came to the programmers. And there you see four guys sitting in front o f a bunch of screens. On the screens are IDEs with code on it only another programmer could find exciting.. The first guy starts talking and the words tumble out of their mouths, “The programmer’s role in the game is to help make everything a reality. We make tools that allow the designers and artists to actually make the game. If the designers the want to do something, or if the artists want to do something… If they are smart, they’ll consult and ask us. Often, we’ll say no, then they’ll say they want to do it, then we’ll have to do it…”

How sad is that? We have collectively gone from being the cool guys who created Spacewars and Pong, to serving as common laborers that create the foundations upon which others build their greatness! Partly to blame is the scale of modern games. Many employ large teams that relegate the programmer to the common rank and file. Even for smaller games like the popular iPhone ornithological physics simulation Angry Birds. Who created it? No. Clickgamer is the publisher. Yes, Rovio is the developing company. If you find the button that shows the credits, and scroll past the Executive Producers, producers and designers, you will finally find the lead programmer, Tuomo Lehtinen (bless his soul), and his motley team. At least he got mentioned before the artists this time.

So yes, how does this affect our darling Darwena? Darwena will be a rapid development framework designed for the programatically inclined. It won’t be a set of APIs like the illustrious Ogre3D or other similar engines. Instead, it will be a full toolset, somewhat like Unity or Unreal, but without the idiot-proof handholding. No flowcharted shaders or drag-and-drop AI. Instead, we expose enough of the system so that it can be exploited mercilessly at the hands of a wiley scripter. Also, we will focus more on procedurally generated content. Sure, we will occasionally have to import a mesh or texture. But if it can be created by a clever algorithm, why not?

Also, Darwena will have style. Something you won’t be ashamed of having floating around the screen when you have completed your hit game and they are shooting the “Behind the Scenes” video. The masses will look upon it and go, “Wow! That’s what I call code!” rather than, “That guy’s Notepad has coloured text…”

So watch out all ye heathens! The return of the programmer is nigh!

* This article contains some dramatization

The Art of Daydreaming

Posted: October 20th, 2010 | Author: | Filed under: Tutorials | 1 Comment »

Daydreaming helps!

So for the past week or so, I’ve been feverishly working on Darwena. I got my platform-specific code up for the PC and OSX, got my OpenGL contexts working, integrated FreeImage and FreeType. And then I stopped. For the past day and a half, I have been doing nothing but dreaming and conceptualizing. Professionals would call this design, but no, it’s all in the head. It is something that very few novice programmers engage in.

So what was I daydreaming about? It was how to implement my material system. Give this task to any graphics programming student, and they’d be right at it. How hard can it be? All you need are textures, maybe color and alpha bias. That and throw in some shader support if you’re ambitious enough, right? So why am I sitting here thinking about it instead of going straight to implementation, like I would do for any school assignment?

The reason is that I have hit a critical section. No, I’m not talking about multithreading. What I mean is that any functionality I implement at this point is going to change the whole texture of my entire engine. It is going to affect its capabilities, ease of use, and generally the whole design philosophy. Yes, I have set down the design philosophy ahead of the whole project, but subtle nuances at this stage of development can heavily influence the interpretation of this philosophy. This makes it worth a taking the time to put a little thought into it, no?

So how do you go about this daydreaming process? First thing I do is clarify all the design objectives of this particular subsystem, and how it will affect the texture of the whole engine. What do I want from it both now and in the future? My first milestone is a 2D engine, so it seems rather trivial. But when I want to extend to 3D and beyond later, I had better have a system that can either be extended or is already capable of that, yes? Also, there is a reason why I chose a 2D engine as my first milestone. I want to have a very dynamic fluid organic material system. If we focus on 3D straight away, this is usually glossed over. In a 2D game however, you do pay attention to animated textures, sprite systems and other things that will make your overall material system more robust.

That done, I start of with the most obvious solutions. Step through each one in my head, and weight the advantages, disadvantages and perceived problems. I also envision how this implementation will affect the design of other systems. It can be a bit much, but it is a system of thinking that I have developed over the years. Visualizing the code running in my head and seeing what leads to what. Then you start tweaking. How different are the results from what you can achieve? Can you make subtle changes to make things go the way you want them to?

Finally, after doing all that, it’s time to do some research. Hit the web and the periodicals to see how everybody else tackled these design issues. Note that this is done only after running through things myself. Most fresh programmers would go straight to the altar of the Google God, pick the first feasible solution they come across, and copy-paste the code, massaging it into their own code base. They then end up with the ideal solution for somebody else’s project. At the very worst, they have a piece of code that they do not understand and just seems to work like a magical black box. This is not good. Not good at all. Instead, what I do is see what others have done, and what benefits they get from doing it their way. Then I look at my own original solution, and fit together ingredients from the ideas I gathered from the wild till I am happy with the concept, and how it will fit in with the rest of my codebase.

And then after all that, I finally start writing code. This is actually the easy part because you already know what to do. All you are doing is translating the ideas into a language that the computer understands, like C++. If you have been doing this long enough, it’s a fairly relaxed and enjoyable process. You don’t have weird design bugs popping up because everything was thought of and conceptualized beforehand.

And that my friends, is what the art of programming is all about!