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.

Disney Sing It is a karaoke game across all the major platforms (PS2, PS3, Wii, XBox 360 and PC) which allows you to sing along to Disney hits from the likes of High School Musical, Camp Rock, Hannah Montana, and Aly & AJ. It’s been a great experience working on it, particularly dealing with the peculiarities of multi-platform development and the issues involved with vast quantities (think many terabytes) of asset data. I’m afraid I must also confess to near-fluency in the Disney repertoire now!

I have added the game to my portfolio page.

As a result I’ve now moved to Brighton and am due to start work on Monday. I’m looking forward to finding out what I’m going to be working on – I don’t even know yet which platform I’ll be dealing with. All will be revealed, though, in a mere three days!

The timing was pretty good, too. We were just coming toward the end of the current project at Virtual Playground and there wasn’t too much pressure on any of us, so I didn’t have to leave everyone scrabbling to hire a replacement. Also, my graduation from the University of Teesside fell neatly in between the two jobs, last weekend. Naturally, I had the cheesy graduation photo taken.

I hadn’t been back to Middlesbrough since July, so it was nice to see old friends. Unlike many of my colleagues at the University, I don’t really miss Middlesbrough at all. It was nice being able to get lunch at Etsuko for £1.99, but the Japanese restaurant here in Brighton, Pompoko, is really much better – although four times the price and cheap at that! No, Middlesbrough as a place doesn’t hold any appeal for me at all, but I do have good friends there.

I stayed for the first night with my former housemate AIDS, and his girlfriend Kaz. They have recently had a daughter – I believe she was two and a half weeks old when I visited. Her name is Kaitlyn, and it was a pleasure to meet her. I’d been warned that she could make a lot of noise, but she seemed very well-behaved during my time there! She’s an absolutely gorgeous baby, so of course I had my photo taken with her, too.

My computer is still broken, but I’m now thinking it’s the PSU which is on the blink, and that’s pretty easy to replace. However, right now it’s both broken and on the other side of the country to me, so I can’t test this theory. Meanwhile, I’m using my laptop, but as my desk is also still up in Newcastle I don’t have the best working environment at home. As a result I’ve not really used this week off for anything much useful, just a bit of reading and a bit of writing, and some exploring around Brighton.

I was recently reading about GOAL, though, as it was mentioned in passing on the sweng-gamedev mailing list. I quite enjoyed my brief experimentation with Lisp during the AI module in my final year at Uni, so I’m intrigued to see how it would be applied in a games scripting environment. I’m tempted to pursue my understanding of Lisp once I get set back up with a desk and so forth, but on the other hand I can’t escape the feeling that learning Lua would be far more practical.

We’ll see how it goes… for now I’m probably going to concentrate on work at my new job before I take on any other major programming projects. I also have a load of other ideas which I’ve started and not fully developed – some with friends, some on my own – so I may pick one of those up again.

Anyway, as a result of my computer woes I’ve not been playing it nearly as much recently – luckily it didn’t die until shortly after I completed Portal – so for the past few weeks I’ve been sticking, for the most part, to playing games on my PSP. I’ve only got three games for it so far, and I must say that while I still prefer the Nintendo DS overall, the PSP does have something to offer, and with the new slim & lite edition the problems with battery life and price have largely been done away with.

Against all expectations, the PSP’s greatest asset is its quirky puzzle games. We expected this of the DS of course, but the PSP? As far as I can tell, apart from myriad cutdown PS2 games (yuck), puzzlers are about all it has going for it. I had a choice of four games in the PSP bundle I purchased, out of which I selected Lemmings. I won’t say much about that, because you pretty much know what you’re getting with lemmings – though moving the cursor with the D-Pad and the camera with the analogue stick seems like utter madness in my opinion. I also won’t talk about Wipeout Pure, except to say that it’s actually quite good.

Which leaves the third game in my extensive PSP games collection: Crush. I recently interviewed at the studio which developed this game, Zoë Mode, which if I’m honest was the main reason I bought it in the first place. I was pleased to discover that it’s actually really good, making me all the more keen to make the move to Brighton. You play a guy called Danny who suffers from chronic insomnia, and after having exhausted traditional therapy decides to try an experimental new system called C.R.U.S.H. The machine allows Danny to enter into the world of his psyche and explore the issues that are keeping him up at night.

Quite a story, for a puzzle game! Indeed, the storyline is one of the things I love about Crush. It’s really very engaging, and encourages you to go through the trials and torment of completing some of the ridiculously tricky levels later into the game. That plus I share the main character’s name, so I really felt like the doctor was talking directly to me in all the soundclips.

The main mechanic behind Crush is that of moving between 2D and 3D. By rotating the camera in 3D and then “crushing” the world into 2D you can move into areas that would have been impossible to reach otherwise. The crush mechanic is a powerful one and, surprisingly, doesn’t descend into being a simple gimmick. The level design is awesome and it’s obvious the designers have put a lot of effort into really exploring what this mechanic gives them to work with.

All in all, then, I’ve been pleasantly surprised since buying the PSP. It’s almost a shame it’s been so universally unsuccessful – I imagine those games which have come out for it exclusively have suffered as a result. True, the DS probably deserves its victory – it’s more innovative, brilliantly marketed, and generally cooler – but the PSP… it’s not that bad.

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.