We’re hoping to put a similar event on next year, hopefully bigger and more packed-out, so Teesside students watch this space. In the meanwhile, I’ve put my slides up on my portfolio page here.

The idea behind the event is that alumni from the University of Teesside return to give talks on topics they’ve learned about since leaving the University and entering the world of professional games development. Unlike the typical, “This is my experience of the games industry after my first few months there” talk (one of which I gave back in in May), this offers the chance for alumni to talk about a topic that matters to them – whether it’s the particular aspect of games development they’ve been involved with, or a technology they’ve explored or developed, or a particular approach to design. And, of course, it gives students an insight into aspects of games development they wouldn’t usually encounter as part of their course. The planned talks this time round are:

• Me, talking about multi-platform asset and build management using make and other UNIX tools.
• Peter J. B. Lewis, talking about working as a programmer in middleware, based on his experience at Geomerics in Cambridge.
• Luke Nockles, covering a variety of aspects of design, including game design, level design, and HUD and UI design.
• Steve Lee, talking about the role of design, getting a job in the industry, the meaning and value of elegance, and games as education / art.

There’ll also be a panel at the end which will likely focus on our early experiences in the industry but will be pretty open, so we’ll just go in whichever direction questions take us.

I’m really excited about this event and I hope that, if it’s a success, it can become an annual affair. Naturally I’ll be putting my slides up on this website once I’ve given the talk, so anyone who makes it should be able to find them on the portfolio page.

make, and the UNIX-style command line environment it typically utilises, is often forgotten or even scorned by programmers studying games-specific courses, or even some of those I’ve met in the industry itself. We’ve become used to IDEs which enable us to drag and drop files, edit them, compile, run and debug all in the same window. These have their advantages: the initial learning curve is much shallower, and they can deliver a tightly integrated experience (which is rather the point). They have their disadvantages too, however, and console-driven build management tools like make shouldn’t be discarded out of hand.

Each of the platforms we’re working with at the moment has an IDE associated with it: Microsoft platforms use Visual Studio .NET, while Sony and Nintendo both have CodeWarrior compilers set up, as well as their own alternatives. It’s quite easy to build and maintain a project / environment / solution for each individual platform, but running five concurrently is a different matter entirely. You know the story: somebody creates a new file and forgets to add it to all the different project files, or they write some code and check it in after compiling for one platform, not realising that it breaks the build on some of the other platforms… and so on. We’ve all experienced it in one way or another; most of us have been guilty of it at least once or twice. And with five different IDEs to load up and hit “compile”, who can blame us? Every check-in becomes a chore, which leads to fewer check-ins overall, which leads to difficult merges and difficult-to-track revisions.

One problem with using IDEs for cross-platform development is that they force you into a certain way of setting up your build. Sure, they try to add some flexibility with pre- and post- build steps, but if you want to do anything other than a simple compile it all gets a bit voodoo. make simply lets you run shell commands, meaning that it is not restricted to doing things in a particular order, to using a particular compiler, or even to compiling a particular language! The same makefile could compile C/C++ source files, link them into an executable, and run LaTeX over any .tex files it comes across, generating beautifully formatted documentation.

Indeed, this flexibility means make need not be limited to building the application executable. It can also process asset data ready for transferral to disc. Each platform will typically have its own texture format which is optimised for that platform specifically, and may have native formats for other media such as mesh data, videos, and audio streams. It pays to use these formats if possible, and make makes this pretty easy. It can be set up to handle all conversion, and move the new native-format files to the correct location in the directory structure.

Often this sort of asset processing is done using a custom tool written to do the job; typically a GUI tool written in C# or Python. Consider coding such a tool in C#, for example. It’s not difficult, but it would involve an unnecessary amount of work to accomplish something really quite simple. Python may be better — indeed, another build system, scons, is built upon it — but writing a full GUI tool from scratch seems like a waste of effort when what we’re trying to achieve is an automatic tool; one which requires as little user interaction as possible.

make allows us to set up dependencies to automate the conversion of asset files and move them into the correct place with ease. In addition to that, it will only perform these conversions if the source file has changed, which is a massive boon when you consider the length of time it takes to convert, say, video assets.

There are plenty of places to learn make, so I won’t go into the details of how to use it here, but for those reading who’ve never coded outside of Visual Studio, I urge you to take a look at make and see what it can do for you. Indeed, get ahold of Cygwin and familiarise yourself with it. The command line is far from dead, and as you learn how to take advantage of its many powerful features, you’ll likely find it changes the way you work.

But no, that’s not it. Actually what I’m talking about is this…

That’s a screenshot of my working environment at Zoë Mode (the code itself is masked out using a simple regex). I do most of my work in Vim running under Cygwin across both my monitors. I’ve installed ratpoison so that I can utilise all the screen space available to me, as well as cut down on mouse usage.

All that is fascinating, I’m sure. But the interesting thing about this screenshot probably isn’t the software or the environment. It’s probably the fact that everything’s pink. Yes, my xterm is set to a pink background, vim uses that default background – I’ve even set Windows to use the “Rose” theme packaged with it, with some minor tweaks to make it a bit pinker. Why would I do this? Why would I subject myself to near-fatal levels of pinkery? The answer, my dear Watsina, is elementary. I’m simply getting into character.

Method acting is a well-known technique practiced by many actors including Robert de Niro, Al Pacino, Marlon Brando, and some others who weren’t in Mafia films. Wikipedia describes it as “an acting technique in which actors try to replicate real life emotional conditions under which the character operates, in an effort to create a life-like, realistic performance.”

The game I’m working on at the moment is aimed toward the young female market. You see where I’m going with this? That’s right, through making my computer almost entirely pink, I hope to arrive at a deeper understanding of what it means to be a young girl. It means pink, apparently.

Here’s hoping I don’t find myself working on GTA any time soon…

It’s nice though; fun. You get the feeling you’re much more “close to the metal”, and you have to be much more aware of the machine’s resources.

Of course, the other major thing that’s happened is Christmas and New Year. This year – or I should say last year, on December 31st – I went to Oxford Services for the annual Oxford Services New Years Eve celebrations! Started a few years ago by Dave Shearn, this small gathering of friends grew this year to include 59 attendees (and a puppet). Shearn’s dream is that at least once every year we will have the opportunity to see all of our friends. It’s a lovely idea, and our Welcome Break certainly made for a great way to round off the year. I saw some old friends, and I met some new ones – whom I look forward to seeing again next year at Oxford Services.

I did make one New Year’s Resolution this year, though I only thought to make it on the 4th, and that involved keeping closer track of my money. That doesn’t necessarily mean spending less, I should note, just being more aware of where my spending tends to fall, and perhaps using that awareness to redirect it toward more productive endeavours. With this in mind I’ve installed GnuCash, and I’ve been playing with it the past few days. It’s a reasonably nice piece of software – while not as powerful as the tool my mother uses, Quickbooks, or other tools such as Quicken or Microsoft Money, it seems to suit my purposes quite well. Since my desktop broke I’ve been using my laptop most of the time, on which my primary OS is Ubuntu Linux, so those packages weren’t really an option anyway.

As a result of all this, I’ve found that managing ones personal finances is not unlike playing a Resource Management Game such as SimCity. This makes perfect sense, of course, since these games are designed to simulate real-world economics – nevertheless, I hadn’t quite looked at it that way before. It’s really quite rewarding manipulating my budget to accommodate different things, and trying to improve my high score offers the real-world benefit of also increasing my wealth!

The only rather annoying thing about GnuCash is its reports system. If you want to define a new report other than those templates that come with the application, you have to write a script to generate it in Scheme. This is not a trivial task; one of the sample reports weighs in at 521 lines – and Lisp-variants are supposed to be eloquent! On the bright side, the reports that come with GnuCash are really very good, but I do occasionally come across functionality that would be easy to implement were I using a spreadsheet, but which are a pain to try and wedge into GnuCash. Maybe I’ll come up with some solutions as I get more use out of the program in the coming months, but either way it’s a nice piece of software.

The other thing I spent my Christmas break doing was helping my Dad with his website. This got me back into web design, or rather, programming for websites. I was using Zen-Cart, which is written in PHP, but what I really want to learn now is Ruby. It’s cool, glamorous, and everyone’s using it, which are rubbish reasons – but hey, it’s a hobby. It does look really nice though! I particularly like its stance on typing – duck typing is an idea I’ve been growing to like more and more recently without having heard the expression, since it’s essentially what C++ offers through templates, though C++ does it with a lot less style. I’m really intrigued to see how Ruby feels to use, since it was designed with this style of programming in mind. At the same time, I would feel a lot less safe doing this sort of thing within an interpreted environment. One thing I love about templates is that they are a compile-time flexible typing mechanism.

We’ll see how it goes…

Probably the biggest part of this refactoring effort has been the move to an aggregation-driven object system. That is, up until now we’ve had a classic deep hierarchy, adding functionality by deriving new classes, pushing functionality further up the hierarchy when we need to share it, and so forth. This is not ideal. We’ve been told time and again how composition is more effective, more flexible, and generally safer than inheritance. Many of us are already comfortable with the inheritance-driven model, though, and are used to working with it and finding ways round its flaws.

Since reading Mick West’s March 2006 article in gamedeveloper magazine, “Evolve Your Hierarchy”, I’ve wanted to try out composite object systems, and see how much extra flexibility they give you, and whether usability suffers as a result. I was finally given the opportunity a month ago, when I was asked to take our existing inheritance-driven hierarchy (from basic objects that can load and save down to AI-driven characters that can make decisions, have FSMs, pathfinding, and spline-following capabilities), and start writing aggregate equivalents. Since the current title is quite simple I’ve only had to replicate a limited subset of the functionality that existed in our original system, giving me more time to focus on the design issues involved.

We’ve gone for what West calls a “Component Container” in his article, whereby we still have the idea of a game Entity as a concrete object, to which we can attach Behaviours. These Behaviours consist of small, very specific classes adding a particular function to the Entity. We’ve tried to be quite strict about limiting the scope of their abilities – if a Behaviour gets too hefty we split it up into two separate Behaviours. So far it’s been very successful. We’ve been able to replicate all the functionality we’ve needed so far from the old system, and we quickly got used to the idea of creating a new Behaviour and attaching it, rather than creating a new class and deriving it. We’ve taken the old object factory, which allowed artists to specify how the objects they were adding to the game should act, and added the notion of Behaviours – so objects of each type have a set of default Behaviours, after which more can be attached to extend functionality for that item in particular.

The main difficulty we’ve come across is communication between these Behaviours. In an ideal world, the Behaviours would be entirely self-standing, and we could simply depend upon their standard clone()/init()/update() interface to run themselves. Tragically, the world is not ideal: the Animation Behaviour will need access to the mesh in order to animate it, but the mesh is stored within the SceneNode Behaviour. The FSM Behaviour (when we write it) will need to tell the PathFind Behaviour where to go, will need to pass the path found by PathFind to the SplineFollow Behaviour, will need to tell the Animation Behaviour to start the walk animation, and will need to update the position of the SceneNode. There is a lot of intercommunication. So far, we’ve been fairly flexible about giving access to Behaviours – they can be retrieved from the Entity storing them, and since each Behaviour has a handle to its parent Entity they can be accessed from within or without.

All in all, I’d highly recommend this style of object composition. It’s easy to use, and quite intuitive for those of us coming from an inheritance-oriented background. After a while, you realise that the Entities are not really necessary; a component manager could be used to store a variety of Behaviours which have an entity ID to describe how they fit together, in what West calls “Pure Aggregation” in his article. The Entities in our system essentially act as localised component managers. West recommends this as an intermediate solution, and to a degree I agree – the purely aggregate system has an abstract and simple beauty to it, and is incredibly flexible and powerful. However, the idea of concrete Entities can be a useful one, and I think so long as we are limiting this system to in-game objects (as opposed to all game functionality, including scripts and triggers, etc.) we will probably keep them.