You can’t lie to the compiler.

Oversight is now 4.01 compatible

Posted: October 13th, 2010 | Author: | Filed under: Soapbox | No Comments »

Yes, Oversight 1.02 is out with a few changes to keep it compatible with 4.01. I have disabled spec detection for the time being because of the plethora of new spells and buffs that I’ll need to weed through to reliably identify each spec. And anyway, that won’t be very useful until people start arenaing again. Similarly, the default buff list has been made empty as some spells have been taken away, making their spellids invalid. However, if you had an older version of Oversight, whatever buff list you had before will carry over with no problem. If you are new,  just type in the few buffs you want to keep track of for the time being.

As always, you can get Oversight from the usual places, namely right here at e-Goh, as well as at WoWInterface. Enjoy!

Webbifying Darwena

Posted: October 11th, 2010 | Author: | Filed under: Tutorials | 2 Comments »


As posted previously, I am working on a new OpenGL game development framework. Since it is my own personal project (at least for now), I get to decide how to go about documenting it. Like every other programmer out there, I hate documentation. Can there be a greater waste of brain power? However, it is a necessary evil that needs to be done. So since I’m a tech person (or why would I be in this industry?), I decided to go about automating it as much as I can.

The first thing I did was put up the wiki at I just used Mediawiki. The good folks at Dreamhost handily have a one-click install in their control panel. So I fill in a bit of information, click “Go”, and voila! I have a wiki!

I decided to give the wiki a very simple structure. The bulk of the wiki will be tied to the “Project Roadmap”. So as each module is completed, I just click on the link and add a little writeup about what it does. Easy. I imagine that as I begin incorporating more things, the wiki page itself will grow naturally.

For API documentation, I pick my favorite tool… Doxygen. I downloaded the frontend to my PC to generated the doxyfile (i.e. the configuration file). I then sshed to the webserver, downloaded the Doxygen source, and compiled it there. I had a bit of a problem with the language translator, but I found the right place to disable that. Don’t really need documentation in Norwegian anyway, do I?

I then made simple sh script to update my Mercurial repository, run doxygen and copy the contents to my web fol.. directory. (folder is Microsoft-speak!). Put up a cron job to run that every day and perfect! I did mess up a bit on this step though. The first time I did this, I enabled their “File Browser” thing, and all my ugly code got published to the web. OMG! OMG! I quickly fixed that. Hopefully Googlebot didn’t peek in while that was up.

Oh, I mentioned Mercurial didn’t I? Yes, that is indeed how I am managing my source control. Mercurial over ssh. Can I be more secure? What’s better is that I can push it to my portable hard disk for yet another backup copy.

I’m sure any company or organization could easily implement what I have on an internal web server. Not only do you end up spending less time writing documentation (well, it only seems that way), but it also automatically becomes available to the rest of your development team.

One last shout out for those of you who are not aware or who have forgotten about the Darwena Logo Design challenge. Make me a logo and win fifty bucks. What could be more easy? It ends at the end of this week, so hurry with the submissions.

Setting Up Your Macbook Pro For Development

Posted: September 25th, 2010 | Author: | Filed under: Tutorials | 1 Comment »
My new Macbook Pro!

My new Macbook Pro!

Recently (last night in fact), I had my new Macbook Pro delivered. This 15″ beauty was augmented with a matte anti-glare screen and a 7200rp 500GB drive. Boasting a 2.53GHz i5 processor and 4GB worth of RAM, it is truly a worthy development platform. However in order to convert it to that, a fair amount of preparation must be done. Sure, you could just install XCode and say you are good to go, but you can’t really say you are working at maximum productivity, can you?

This first thing I install, as with all Mac machines, is Quicksilver by Blacktree. This allows you to bind a hotkey that calls up quicksilver. Once done, you just type in the first few letters of the application, music, url, xcode project, etc. that you want to open. Autocomplete will find it for you, then you just press enter to launch it straight away. Not only is it tremendously useful, it is also extremely stylish with its bezel interface and all.

The next thing to go in is Visor, also by Blacktree. This provides me with a full-screen Terminal which I can toggle at the touch of a button. I bind this to my F12 key. Since it messes with OSX internals, it needs a bit of setup. You have to install SIMBL, and then copy the Visor Bundle in to a specified location. Once that is done, run Terminal and set up the preferences to whatever you like. At this point, I would create my .bash_profile and .vimrc files. The .bash_profile is mainly to customize my prompt. The .vimrc file of course, is for Vim, my text editor of choice.

Once the basics are in, everything else follows. I grab the latest version of Xcode from Apple’s Developer Site. In my case, I grab the one with the iPhone SDK. For source control, I install Mercurial. Subversion and CVS already come bundled with OSX. I prefer Mercurial as my primary source control for a few reasons. Firstly, it’s dead easy to set up. No weird config files or hooking up through Apache. Merging is also much better supported. Second, I can sync via SSH. Quite a few times, I failed to sync with SVN over http because of messed up proxy-servers on whatever ISP I’m connected to. Lastly and most importantly, I can sync to multiple locations. So I can have master copies on my server, as well as on my portable hard drive, and sync with either one of them. Of course, being a freelancer, you work with whatever your client uses. So having all three is good.

For my productivity suite (I wonder why they call it that), I use iWork. It’s cheap, compared to Microsoft Office. It is also simpler and easier to use, and more impressive to look at. There’s really no reason why I would want to use the travesty called MS Office because simple developers like myself have no need for mail merge or the other 1001 esoteric features that nobody uses anyway. Also, it means that for presentations, I get to use my cool apple remote (that came with my previous Macbook but is not included with this one).

Communications. For mail, I install Postbox Express. It is hands-down, the best free IMAP mail program out there. There’s both Windows and Mac versions, so I have it installed on my desktop as well as my Macbook. If you’re stuck with POP, default Apple mail works. For messaging, I use Adium. Why Adium and not the tonne of other messaging clients out there? Because it looks cooler. It’s not good enough to be awesome. You’ve got to be awesome with style!

The only thing left is a decent image editing program. The best, of course, would be Photoshop. However, given that I have the artistic talent of a gerbil, I can’t really justify the price. A free alternative is the Gimp. It looks as ugly as sin, but it gets the job done. My preferred choice would be Pixelmator. It’s just barely affordable, looks great, and has everything you need for programmer art and more. Alternatively, if you are expecting to get a Wacom for any reason anytime soon, Photoshop Elements and Corel Painter Sketchpad would probably fill whatever gaps you have.

System tweaks. Dump all your music into iTunes. Can’t code without good music, can you? Surf DeviantArt to look for nice-looking wallpaper. Open up your system preferences. Under Account settings, go to startup items and remove iTunes Helper. This prevents iTunes from annoyingly popping up everytime you hook up an iPod/iPhone/iPad. Disable Time Machine. Set up Expose and Spaces to work the way you want it to. Modify power settings to be less annoying. Require a password on login and when you exit a screensaver. Got to do your dues for those NDAs!

Now that you’re done with OSX, it’s time to look at Windows. You didn’t really think you could get away from that, did you? I bought VMWare Fusion for $10 (an upgrade since I seem to have been suckered into buying an early version long time ago). Set up a virtual machine with 100GB disk space 1GB RAM and 1 core, and installed an old copy of XP on it. Why XP? Fusion doesn’t support anything above DirectX 9 anyway, so why spend money on another Windows 7 license when XP will do fine? If you are into hardcore Windows development, a better approach would be to set up a BootCamp partition and install Windows 7. It means you have to reboot to get into windows, but the performance is better. Either way, after windows is installed, I install Microsoft Visual C++ 2010 Express. That’s probably the only reason why I need Windows, so I leave it at that.

And with that done, you are all set to dive into the code and do a few laps. If you get bored while waiting for things to install, why not blog about it? I did.

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!

A Fistful of Interns

Posted: September 13th, 2010 | Author: | Filed under: Soapbox | 1 Comment »

There is a strange phenomenon among the newer small game development studios in Singapore that I have worked with. This is the employment of interns in their development team. While this is nothing out of the ordinary, these companies take it to such extremes that the intern force outnumbers the full-time staff. In some cases, the intern force is the entirety of the development team.

Why does this happen?

There are a number of advantages to hiring interns. First and foremost, they are dirt-cheap. For S$400 – S$500 a month, you can get a warm body working for you full time. The allure of this is irresistible for smaller setups with tight purse strings. This means that for every entry-level permanent staff you hire, you could have gotten 3-4 interns.

The other major factor is that it is very difficult to find competent programmers, artists and designers in Singapore. Though the local polytechnics are churning out batch after batch every year, supply is still extremely scarce. Why is this? A significant portion of the students come to the realization that making games is hard work, and not the dream job they once saw it to be, resulting in them switching to other lines of work, such as selling insurance. Of the remainder, the big boys (i.e. EA, Ubisoft, Koei, Lucas, etc.) suck up the majority. This leaves for thin pickings for the smaller companies with more modest employment budgets.

Why is this bad?

The first bad thing is turnover. Internships typically last 1, 3 or 6 months. If you are lucky and on very good terms with the institution you got them from, you might extend this by another 3 months by setting your company project as their final year project. It typically takes about 2 months to train and fully integrate the said intern into your workflow. This does not leave much in the way of “productive time”. Also, given that the vast majority of the game development students are male and local, they will be gone for National Service after they graduate, killing prospects of hiring them full time.

Then there is quality. Hiring interns is like dipping into a box of chocolates, you never know what you are going to get. Of each cohort, roughly 10% is self-motivated and competent enough to jump right into the job and get things done in a timely fashion. 30% are your worst nightmare. At best they take up space and not much else. At worst, they impede production and demoralize the rest of your workforce. Fortunately, most institutes recognize these people and do not send them out for internships. Some however, occasionally slip through the cracks. The remainder require constant training and supervision, and even so, the quality of their work will remain sub-par and unimaginative.

Efficiency. After a few months of finding out that their interns cannot produce the quality of work they desire, many employers look to hire a senior staff to nurture their intern force. Quite often, that ends up as me or one of the other handful of freelancers operating in Singapore. However, little do they realize that if we were to handle the task solo, the project would most likely be delivered faster, and at higher quality, than managing all these interns.

Operational costs. If we were to assume that 3 interns = 1 junior developer, the company would have to provide three times the space and equipment for an equal amount for productivity. The higher maintenance cost may outweigh whatever savings you get from hiring interns in the first place.

What should companies know about interns?

Interns are a useful asset to have, but their usefulness depends on how you employ them. Know that your interns are going to sap time from your employed staff. If they outnumber your permanent staff, you may find productivity dipping significantly, especially within the first month or so of the internship.

When allocating tasks to interns, ensure that they have very specific and clear instructions on what has to be accomplished, and how it is to be done. It is also incredibly useful if you can define easy-to-measure KPIs to assess the level of their work. They will also require constant supervision, and somebody should be assigned to check in on them on a daily basis. Most interns are shy and hesitant to ask for help.

When deciding to hire an intern, plan out the tasks they will do during the course of an internship. Do have contingency plans as the intern may take an extended amount of time to finish their task, or if you are extremely lucky, may finish it well ahead of schedule.

Most interns will need to prepare reports and presentations for their schools. They will typically spend the last week of their internship doing this. These may also need to be vetted for reasons of confidentiality.

Pretty much all interns I’ve seen end up surfing YouTube and play web-based Flash games during office hours. Be aware, and strike a balance.

What the government and educational institutions can do to help

The major stick in the mud as far as internships go is national service. Ideally, you would want to use the internship as a testing ground for possible future employment. However, they are bundled off to the army for two years right after they graduate, breaking any continuity. If polytechnic education came after their time in the army rather than before, this would be much less of an issue. In Korea, outstanding students are allowed to serve their national service in game companies. That would be an excellent way to promote the growth of the game industry in Singapore.

Three-month internships are too short. Internships should be at least 5-6 months long for the companies to recoup the cost of training the students, particularly in highly technical industries like game development. The ability to extend this further by incorporating their final year project into the attachment time is an outstanding initiative done by quite a few institutions.

Interviews with students or at least some informal introduction to the students prior to taking them on as interns would be extremely useful. This would aid in getting the students with the right skills and interests to the right jobs. It may also open their eyes as to what is out there. Right now, the process feels too much like a lucky draw, especially from the perspective of the hiring company.

So where does that leave us?

Internships are useful, no doubt, partly as a means of accomplishing simpler tasks and partly as one of the company’s recruitment strategies. However, overdoing it can result in loss of productivity because interns are raw, need to be trained and won’t stick around long enough. Build up your core team first, and supplement them with interns rather than the other way round.

From 2600 to 3

Posted: August 19th, 2010 | Author: | Filed under: Soapbox | No Comments »
PS3 Slim

PS3 Slim

So after years of not owning a console since the Atari 2600, I finally went out and got myself a PS3. Actually, this happened 3 weeks ago, but I’ve been to busy to write about it! So why a PS and not an XBox? Well, like any other good consumer, I looked at the exclusive titles Most of the exclusives on the XBox are FPSes, and I don’t really think that FPS’s have a legitimate place on consoles. The controls are so obviously clunky, as opposed to the simple point and click action of the mouse. So FPS, RTS, and even some kinds of RPGs… those are for the PC.

Naturally, I bought a bunch of games together with it. Unfortunately, God of War III, which was one of the most compelling reasons to go for the PS3, was out of stock. But I’ve had plenty of others to keep me occupied till I can lay my grubby hands on a copy. So let’s see what I learned from my $700 investment.

Heavy Rain

Heavy Rain

Heavy Rain

This game by Quantic Dreams is definitely one of a kind, totally unlike anything I’ve played before. The closest I can think of is those adventure games like Phantasmagoria or Longest Journey. But this is so much more emotive. The writing was definitely top notch, and the game flowed very well, much like an interactive movie. The UI, I thought was spectacular. It was discreet enough not to be in your face, but distinct enough to hint you on as to what you are supposed to do next. It was also not quite 2D, but embedded into the 3D world.

Another interesting thing is that there are no game saves to return to. Every choice or action you make is final. The story is quite linear, but has enough branches to accommodate for your occasional failures. In my play-through, almost every one of my main characters died in some way or other, and not all of them intentional! I would definitely replay through this again to see what would happen if I did things differently.

Final Fantasy XIII

Final Fantasy XIII

Final Fantasy XIII

This was the next game I played. To tell the truth, I have never, ever, ever, completed a Final Fantasy game before. And this was no exception. Make no mistake, it is an incredibly pretty game, with all the colourful effects and striking attacks. The combat system was decent, giving you enough things to do, but not outstanding. Eventually, just like all the others, it became to repetitive. Soon, the only thing motivating you to complete the game is the storyline. The story, while cohesive, is not riveting. This is probably due to the large amount of repetitive combat you go through in between each scene, leaving little attachment for the characters, unlike Heavy Rain.

While I can say I like this more than VII and VIII as far as gameplay goes, that’s about all I can give it. There are much more interesting RPGs out there like DragonAge and Fallout 3 (both of which I played on PC ).

Dante’s Inferno

Dante's Inferno

Dante's Inferno

I was looking forward to playing this for two reasons. First, it’s probably the closest thing I can find to God of War till I can get that. Second, it’s toted as the game with the most amount of gratuitous nudity, which is never a bad thing.

It started out remarkably well. Full props on presentation and the depiction of hell. The 2D western-style-anime-panel-art thing was pretty dramatic, and the story made pretty clear. Combat was just like I saw on Youtube, running around crazily smacking things all over the place. The controller is indeed very well suited for this sort of game, especially with the dual analog sticks.

After a while though, it did start getting repetitive. It’s the same sequence of buttons you mash, wading through hordes and hordes of enemies. The atmosphere, while suitably oppressive, had no breaks or changes. As such, it ended up rather dreary, the combat becoming more a chore than enjoyment. I waded through Lust and partway into Gluttony before I set it aside for the next game.

Metal Gear Solid 4

Metal Gear Solid 4

Metal Gear Solid 4

This is one solid game. At the beginning, the controls were rather complicated and unintuitive. However, as I got used to it, it grew on me and I started appreciating the way they make use of every single button. The sheer amount of things you can do is pretty  amazing. More than that, the cutscenes all look amazing, even if they are played out using in-game graphics. This allows a smooth blend from cutscene to action without any pause or hiccups, resulting in a very slick and smooth flow.

The story behind the game is also one of the strong points. Not only is it suitably complex, but the characters are fleshed out enough that you can get attached to them and emphathise with what they are going through. I particularly liked the scenes where the small girl is frying eggs, for some strange reason. It’s just odd and is always there, much like the “Enchantment!” boy in Dragonage.

Sneaking around and getting the drop on the goons is definitely fun, somewhat like a hi-definition puzzle game. When I mess up and end up in full-fledged combat though, my feeling that FPSes have no place on a console only gets reinforced as I struggle to position my crosshairs accurately without the camera flying all over the place. Fortunately, the  game designers took that into account, making the goons stand still for suitable periods of time so you may get off a proper shot. How multiplayer console FPSes work is hard to fathom.




I can’t describe this game as anything but pure unadulterated fun. The presentation is highly stylized, reflected not only in the impossible dimensions of the lead character, but also in the choice of music. Never would I have imagined slaying hordes of angels to the tune of  “Fly me to the Moon”.

The heart and soul of the game is the combat system. Almost all the combos are there for you right off the bat, with a few special ones available for purchase. Every time a scene is loading you get to practise your combos in  a sort of test room. Boss fights feel like boss fights, with their distinct and sometimes whacky mechanics. They even return later as regular mobs in twos or even threes. The “witch time” system slows down time everytime you dodge something at the last second, giving you some sense of control in all the mayhem, as well as the illusion that you actually are skilled enough to pull it off.

The story itself is rubbish. Either that, or I completely don’t get it. However, the cutscenes are sometimes quite awesome in their own right. Even if they don’t make a lot of sense, they score on the “coolness” front. This is one game that I will be playing for quite some time!

Overall Impressions

There’s definitely a difference between console gaming and PC gaming. For one thing, not one of these games, at any point in time, crashed. I do not know what happens on a PS3 if a game crashes, and that’s probably a good thing. Not having to deal with a myriad number of hardware configurations certainly helps. You can see developers exploit this as much as they can when they go with over-the-top effects. Why not use every single cycle, eh?

Another point is the cultural difference. Most of the games I play on the PC are heavily western-influenced. On the PS3 however, I see a lot more Japanese games. The flavor is most certainly different. There’s a lot more attention payed to style and flash, and the humor is much more in-your-face. There’s a lot more button bashing, as compared to the more measured American and European games.

The next time round when I go on a shopping spree, I’ll be looking at God of War III, either Super Street Fighter IV or Tekken 6, Little Big Planet, and whatever else I can find out there. So far though, I do believe I have come away from the whole experience with a wealth of pointers and insights when it comes to game design and execution. Certainly a worthwhile business investment! ( yeah, that’s my story and I’m sticking to it! )

Oversight hits 1.0

Posted: July 10th, 2010 | Author: | Filed under: Soapbox | No Comments »



Just a short blurb that Oversight, the WoW addon, has hit 1.0 and is now available both here as well as at WoWInterface. Enjoy!

Oversight goes Beta!

Posted: March 20th, 2010 | Author: | Filed under: Soapbox | No Comments »

So the WoW addon finally made it to beta. For all you PvP buffs out there, the main Oversight page can be found here with download link and all. This is one of the few projects I’ve actually undertaken to do myself. I didn’t want to take on a full-fledged game as I would undoubtedly delay and defer. Indeed, even this one did get delayed in favour of actual paying work.

Also, in the course of doing this, I discovered Sony Vegas. It seems really popular amongst the machinima people, and rightly so. It’s sooo easy to use. Much easier than Premier Pro. I put together this second video in scarcely less than a night’s work. Also spent the $68 on it, and it feels well worth it. That’s how software ought to be made.

I also got new hardware. I’m now sporting double 22″ LCD widescreen monitors, and a back-lit Razer Lycosa keyboard. It’s so handy, but more importantly, it makes me feel more like a professional developer!

Taming Visual Studio

Posted: March 3rd, 2010 | Author: | Filed under: Tutorials | No Comments »

This is a guide to setting up Visual Studio to make use a folder structure that is flexible and portable across multiple machines. It is intended for students, which is why no templates are included. After all, you are supposed to understand what each of the settings do!

Stay Away!

A lot of SDKs have tutorials and guides on installation, and advise that you make changes from the Tools > Options  screen as shown here. Don’t do it! What this does is make global changes to Visual Studio so that all your projects will use the same copy of the SDK. This means that you will find it difficult to use different versions of the SDK on different projects on the same computer. Also, if you pass your code to anybody else, they will need to get a copy of the exact same version of the library you are using and install it on their machines in a similar way in order to compile your code. The only SDK where it is permissible to touch this menu at all is DirectX, and that is because it is installed in an anal OS-monopolistic fashion. For anything else, follow the procedure below.

Our target is to get a working folder structure something like what follows. The bin folder will contain your executables. The lib folder will contain all your SDKs. The obj folder will contain all your object files so they may be discarded later. The project folders will contain the source code and project files of the various projects you have in the solution. This allows you to distribute your work in the following ways:

  • For end users, just give them a copy of the bin folder. That is all they need to run the program.
  • For source code inspection, just give them the project folder(s). Useful if you have quick questions on code snippets.
  • For distributing your source code, delete the obj folder and the intellisense file, and send the rest. This will ensure the end user can compile a copy of their own. This is what I expect to be submitted to me for assignments.

Creating a new project

So let’s get started. First thing is to create a new project from the File > New > Project menu. This will give you a choice of various types of projects to create. What you want to create is either a Win32 Console Application, or a Win32 Project. The Console App will provide you with a DOS box that you can cout to at whim. The main entry point for this would be main(). The Win32 project, on the other hand, makes a standard windows application without any console (unless you hack it in). The main entry point for this would be WinMain(). Make sure to tick the “Create directory for solution” checkbox.


After you fill in a suitable name for the project and click OK, you will come to this screen. Do not Finish immediately. Instead click on Application Settings. The top 4 options lets you change your mind and build a console app or Win32 project or even a library… talk about redundancy. In the checkbox below however, you want to tick “Create Empty Project”. If you do not do this, Visual Studio will create a lot of junk for you that you will need to clear out later. After you are done, click Finish.

Once you are done, the project will be created. I personally like to delete the “Header”, “Source” and “Resource” folders so I can implement my own structure, but that is up to your preference. What you must do, is add a blank .cpp file to your project. It doesn’t matter what you call it or what’s in it. What this does is tell Visual Studio that this is indeed a C++ project, so it will show you all the relevant C++ options. Never mind that the application I installed was Visual C++ Express. After you have done that, go to Project > Properties to configure your project.


The first thing you should do here, change the configuration to “All Configurations” so that you affect both the release and debug builds. Next, expand “Configuration Properties” on the left, and select the “General” category. Here you will change the output folders, to comply with the specifications we have above. These are the changes I made:

  • Output Directory, this is where all the exe files are made. Set it to $(SolutionDir)bin
  • Intermediate Directory, this is where all the obj files are made. Set it to $(SolutionDir)obj/$(ProjectName)/$(ConfigurationName)
  • Character Set, this changes all your strings to wide character strings. For game projects, you really shouldn’t be depending on the compiler for implementing unicode anyway. So set it to “Not Set”.


After that, click on the “Debug” category. Here, there is only one change to make. However, this setting needs to be set up for every single computer you move the project to. This is because Microsoft, in their infinite wisdom, decided that this particular setting should be personalized to each user. So don’t forget this every time you copy the project from one computer to another.

  • Working Directory, this is where your application will launch from when run from Visual Studio. Set it to $(OutputDir)

Include Folders

Next, click on the C/C++ category. If you do not see the same screen as in the screenshot, expand it out and click on general. Here, you will only change one setting, which is the “Additional Include Directories”. You will set this up to point at the include folder of whichever SDK(s) you are using. Multiple folders can be included by separating them with a “;”. Alternatively, doubleclick on the box and you can browse to each of the individual folders. Make sure that all your folders are set up relative to your Solution folder. This will ensure that your project, when copied over, will still be able to find the include files it needs. This means that every single one of the entries here should begin with $(SolutionDir)lib/


  • $(SolutionDir)lib/ogre/include
  • $(SolutionDir)lib/hge/include

Linker Options

Next, expand out “Linker” and click on “General”, which is just under it. Here, just like the include folders, you will tell Visual studio where all the lib folders are by changing the entry “Additional Libarary Directories”. The setup is exactly the same. All entries are seperated by “;”. Examples:

  • $(SolutionDir)lib/ogre/lib
  • $(SolutionDir)lib/hge/lib/vc

Still on the same tab, the next bit is tricky. First, you will want to set the configuration to Debug, so that you only affect the debug build. It may prompt you to save settings, which you should agree to.  After that, change the “Output File” from “$(OutDir)\$(ProjectName).exe” to “$(OutDir)\$(ProjectName)_d.exe”. After that, apply your changes and set the configuration back to “All Configurations”. What this does is make sure that all your debug builds have a “_d” at the end of the exe names, so you can readily identify if your binaries are debug or release.

Additional Libraries

Next, still under “Linker”, switch to the next subcategory, “Input”.  Here, under “Additional Dependencies”, you will list down the .lib files that your SDK requires you to link into your project. These, in a great show of consistency, are not separated by a “;” like everything else, but are instead separated by a single space. Once you have added those in, you are done with project settings and can click OK. Your project is all set up… almost.

Do not forget to copy an .dll files that your SDKs might need into your bin folder. Also, if you need to include any additional assets in your project like artwork or sounds, the bin folder is where it’s all at. That is your base. And that… is all!

No longer United, we make an Ogre out of it.

Posted: March 1st, 2010 | Author: | Filed under: Soapbox | 2 Comments »
Unity 3D

Unity 3D

As the saying goes… it was love at first sight, then I took a second look! You had my first impressions from a previous post. It is indeed a very user-friendly platform for the indie developer working on smaller projects. However, when you scale up, there are several glaring issues.

First and foremost is asset management. When you have a team, or even just more than one person working on a project, you want some way to be able to synchronize your efforts. The defacto tool I’ve been using for this is Subversion. However, Subversion cannot work well with Unity iPhone. A lot of their linkage meta-information is stored in binary files that do not merge well in case of conflict. Unity Pro, for other platforms is supposed to have some switch to enable subversion support. But for the iPhone, we are bone dry.

The solution to this, is Unity Asset Server, which comes in at a hefty $200 per head in addition to your Unity Pro license. From the reviews I’ve been reading, it isn’t that good at doing its job either, making it difficult for me to recommend to my studio head.

The second problem is compilation and import times. As the number of assets grow, it takes a longer time for Unity to grab them and put them within the development environment. Also, the time it takes to compile to device also seems to grow almost exponentially. So not only do I have my developers hovering over one machine waiting to link their scripts in, but those that are actually on it are twiddling their thumbs waiting for the binaries to compile. Not exactly the pinnacle of productivity.

The final nail in the coffin is performance. On the iPhone 3G(S), our small demo level runs at a steady 30 fps, which is all fine and dandy. However, on first-gen or second-gen devices, this drops to a dismal 10 fps. We shudder to think what the bigger levels would run at.

So we bit the bullet and said goodbye to Unity, and all the licensing costs we invested in it, and looked to other alternatives. Shiva, being similar in concept, would most likely be the same deal. Irrlicht has reportedly been successfully ported over to the iPhone and used in a few commercial projects. Unfortunately, these ports are not publicly available, and I’ve no appetite for grinding my own. The SIO2 engine looks ready, but I didn’t quite like the structure and documentation.

In the end, it’s back to Ogre. Even though the iPhone port is on RC1, and getting it set up and ready to work in our production environment took a bit of legwork (so spoilt from plug-and-play SDKs), it seems fairly stable and performs reasonably well. With 20fps as my lowest cutoff benchmark, I could render 20,000 triangles onscreen on a first-gen iPhone. 30,000 for a second-gen. And a whopping 165,000 for a 3G(S).