Interesting post here from Hypnos at Puzzle Pirates about the increasing dependency we have on our internet connections. I certainly know this one – every time I have to uproot and wait for a new DSL line to be installed I go a little bit stir crazy from the fact that I can’t check my email or do all of the things that normally make up my day to day work and life. Luckily this time round (less than a month away now), I have a laptop with wi-fi, and will most likely be haunting one of the free wi-fi coffee shops around Edinburgh to get my daily fix of Internet goodness.

So I must admit to being a bit of a luddite when it comes to embracing the new languages and technologies available for developers now. Partly this is because I’ve read (and heartily agreed with) No Silver Bullet by Fred Brooks, and partly it is because I’m much more comfortable knowing exactly what is going on ‘under the hood’ when I write software.

That being said, having good tools is a vital part of games development, and to write good tools you have to build good user interfaces on top of functional software. No amount of clean, efficient and well structured code is going to get you past that final hurdle, which is to interact with the user. I have spent too much time on too many different projects faffing around with inadequate UI libraries to want to spend any more on it now. I would say I am comfortable with MFC based development, but I would never claim that it was easy or pleasant.

So when I keep hearing other developers evangelising the merits of tools based on managed code (C#, etc.) and the .NET platform. Apparently it should take the pain out of making tools, and user interfaces, and should let me concentrate on the important things instead. Well, that was enough to tempt me in, and to give it a try.

The thing is though, our engine and game code is all based on C++, simple and clean, and we’re not going to change that (no matter how much XNA and Microsoft try to tempt us otherwise). So any tools we build have to be able to leverage all that pre-written code, and play nice with the other parts of our engine. So we needed a way to make the managed tools work with the un-managed engine, and that was where my headaches began.

Straight out of the gate, building a tool application with Visual Studio 2005 was simple and easy, and it took less than 5 minutes to have a skeleton UI that had all the right hooks for exercising some of the engine functionality needed to pre-process our assets. But then I had to figure out how to link those hooks to our pre-existing code, and that wasn’t nearly so simple. The problem was this – a C++/CLI based application (i.e. our tool UI) needs to jump through a few hoops to talk to native (C++) code. The documentation rabbits on about mixed and pure assemblies, DLL building, COM linking and a whole ream of pages about how to build a managed application. All of which is total overkill for what we needed – a simple wrapper layer between the managed UI application, and the native core code.

Now that I’ve found out how, it’s not as hard as I thought; as I work through the details, I’m going to note them down and post them here, because it was immensely frustrating to continually search for tutorials and references (I gave up on the MSDN documentation), only to find lots of people talking about how simple it was, but no-one bothering to let on how it was done.

Anyway, in lieu of a later, better post, here is what I have so far:

• Make a library DLL, making sure that it has managed (/clr) support enabled. This will form the wrapper layer
• The library DLL can statically link to the native libraries you have.
• Build a wrapper class which uses pointers to your native classes to route commands/requests to the native code. Make sure this is a managed class (it should take the form “public ref class WrapperClass” if you’re using C++/CLI)
• NB: You will have to follow the managed rules about not having native value types in your wrapper classes, but you are allowed to have pointers to native types and use new/delete as normal
• In your fully managed UI application, use the Reference system in the Common Properties for the project to add a reference to the wrapper library. This will automagically allow use of your wrapper layer classes, no need for headers or static linkage. [this is the one annoying step that really wasn’t clear from the documentation]

Anyway, a better picture should emerge from this experimentation, and I’m hopeful that once the basic pattern for managed/unmanaged tools emerges, that we’ll be massively more productive and be able to build up a nice tool-set using this new technology.

Interesting post here from Richard Bartle on problems in games industry education and the new games academy that TIGA has been pushing. I agree with most of it, especially the focus on the need for an education, not training. I don’t need people who have worked through a ‘my first game’ tutorial, and it seems like that’s what the computer games courses in the UK provide. The quality of graduate from these courses are rarely better than the wider pool of people who either studied a more traditional course, or who have come from elsewhere in the software industry. I don’t think that’s because the courses are bad at teaching, I just think they are focusing on the wrong things.

What we need are people who has learned the importance of structured programming, or the fundamentals of databases, or any one of a hundred other things that are vital to understanding exactly how to develop software for games. Basically what I need are people who have been educated to the level of a Computer Science degree, but with all of the extraneous parts taken out. Games developers rarely need to know formal proof notation for languages, or details of the electronics behind the hardware on which their software runs. They also need to be aware of the constraints under which they must develop – fixed memory environments, designing algorithms that never take longer than a fraction of a frame to execute, etc. Possibly the hardest thing to learn about games programming is how to make things happen with all of those shiny tools and bloated constructs unavailable.

Of course, my idea of an ideal course for a games developer is probably a bit of a hard sell for universities. After all, if you signed up for a games course, you’d expect to be making games for at least some of it. But the fundamentals of making games are the same fundamentals for all software – it is only when you reach the high-level concepts do ‘games programming’ and ‘regular programming’ diverge.

Nowhere is this more obvious than the field of Artificial Intelligence. I gave up the Artificial Intelligence part of my degree after second year, when it became clear to me that the fields on which it concentrated were not going to help me make games. Neural networks, machine vision, genetic algorithms, knowledge based systems – are all good for cutting edge research programmes, but utterly out of place on even the highest-end hardware for playing games. As such, the AI that you find in games bears little relation to the AI that you would research in a university. Sure, maybe you can build an all-singing all-dancing AI that can respond to your questions and think and act like a real person; but if you can’t make it run in less than 3ms and occupy less than a few hundred kilobytes of memory, then you might as well forget it.

Regardless, it seems that the good people, the ones who shine in their job, are the ones who would do well in games regardless of the course they studied at university. They are the people who make games on their own, who code them in their spare time and learn by doing, not just by being taught. I think there is very much a place for games courses, but they should be far more like Computer Science degrees than vocational courses.

So, I decided to add a bit of PHP to the bottom of the web site pages that displays when the particular page was last updated, and the About page hadn’t been updated since August 2006! That’s pretty bad on my part, so I must apologise. It annoys me when other people let their website go stale, but it’s a bit hypocritical to expect it of others when we don’t do it ourselves. So henceforth I pledge to keep the site more up to date and freshen things more regularly. That goes on the pledge list, probably somewhere around 600th or something. But I’ll try. In addition, I’ve added a Jobs page for the future, although it is empty at the moment, I thought I should have one. We certainly get enough CVs and people fishing for jobs, at least now I can filter out the ones who don’t read past the front page and just spam email everyone.

A little hint for anyone thinking of contacting us about a job: those who show that they’ve actually read the site and done at least some research into the Company are immediately rated above those who just have a list of emails and send off a form mail to all of them

We’re transitioning between projects this week, so Pete and I have been going over what we’ve done for the last few months, how things have gone, what we’ve got and where we’re going. And things are looking pretty good – we’re quite proud of the work we did with Add Knowledge; while there was the usual mad rush to wedge things in, looking back on it we can do some quick re-factoring to turn it into something maintainable and re-usable. Our internal code-base is looking reasonably plump with functionality for making games with, and we’re happy with the style and content. Unit-testing could be more wide-spread and thorough, but that will have to be a long term goal. All in all, I’d rate our performance probably a B for the last project – good, but room for improvement.

Coming up in the near future – well, starting our next project hopefully. Also I’ll probably be looking around for some small cheap office space for us to set up in – a more permanent base from which to grow. And grow we shall – there’s lots for us to do, and only so much time in the day.