The talks mentioned in my recent post have now come to pass! All in all, the first Teesside alumni day was a success. It was great to see everyone again and I must say I thought everyone’s talk was very interesting and thought-provoking.
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.
I’m very excited to announce a set of talks that have been in the works for a while, namely the upcoming alumni day at the University of Teesside on February 25th. I’ve kept pretty quiet (read: silent) about this while it’s been in planning because I haven’t known whether we’ll get the numbers / be able to book the room / and so forth, but finally it’s all been confirmed!
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:
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.
I’ve recently been moved across to a new project, one which I’m enjoying immensely. It has two properties which make its development particularly interesting: it is massively data-driven, and it is being developed across a multitude of platforms (five at last count). In order to accomplish this feat we are using make.
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.
Obviously: I’m a programmer; My primary programming language is C++; I like Object-Oriented stuff, like neat design patterns and small discrete modules and aggregate components and things. Obviously a post entitled “Method Programming” is going to be about programming class methods to maximum effect, right? Perhaps about reducing the size and increasing the number of methods, for clarity. Maybe I’ll go totally zany and start talking about how non-member, non-friend functions are the bees’ knees, or how protected member variables shouldn’t be allowed (both ideas I’ve picked up from articles by Herb Sutter and Scott Meyers, by the way, not my own crazy filth).
But no, that’s not it. Actually what I’m talking about is this…
It’s been an interesting and exciting first month, settling into life in Brighton and working at Zoë Mode. I’m working on a cross-platform title for Wii and PS2 which has a small team and a short development cycle. In some ways this is nice, and close to what I’ve been used to during my time at Virtual Playground, but there are some very definite differences! The most dramatic of these is probably the experience of working for console rather than PC. I’d never appreciated just how limited these machines are, especially with regard to memory. That and the lack of an operating system make for quite a different coding experience.
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! Continue reading
Well, my University life is over, I’m no longer a student, and I’m staggering, blinking, into the light, arms open and ready to embrace the Real World. In fact, the transition hasn’t been so difficult. I started work back at Virtual Playground – the company where I completed my industrial placement – almost immediately upon completing my course. Nothing had really changed in the year I’d been gone, so I was able to hit the ground running, already familiar with the codebase and the toolchain used there. We completed Prison Tycoon 3, and then moved on to do some refactoring concurrently with our next project.
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.