Right, I’ve had enough of the sad kitten at the top of the blog now; you can only stand so much cuteness before the mind rebels. Time for a quick update on status, as I’ve been quite heavy with the waffling and opinionated posts recently.

This post is written courtesy of the wi-fi in a B&B in central Reading, where I’ve been installed for the last week. It’s not my favourite accommodation in the world, I’ll admit (far too many chavs hovering outside the window when the pubs kick out). Luckily, I’ve found a decent room to rent which I’ll be taking up from the end of next week, where I’ll be for the majority of the next few months. Why? Our new client of course – the behemoth that is Microsoft Games.

This is indeed the tools gig I hinted about previously, but sadly that’s as far as I can go in terms of details; not because I’m working on anything super-secret, but because the contract is just generally confidential. Suffice to say it will allow me to indulge my passion for making process improvement tools and automated build systems, and deploy them on a scale that is far beyond our range as a tiny software shop.

Sadly though this requires me to be away from Edinburgh for much of the time, which I’m still getting used to. I’ve lived in Edinburgh for so long it’s hard to adjust to living elsewhere, it’s a city that spoils you for anywhere else. This will also leave Tim minding the office in Edinburgh on his own, but hopefully he won’t be rattling around the place too badly. I’ll still be working with him remotely on our work with Evolution, but he’ll have to keep Bertie alive on his own…

On the bright side, since I’m kept away from all of my usual distractions in the evening, I’m hoping to use the time productively to get some serious effort into our internal prototypes. That being said, in the 3 weeks away so far, I’ve managed no more than a few hours, but I put that down to the fabulous selection of pubs in and around the Rare studio in Warwickshire where I spent the first fortnight – it’s really hard to feel creative and productive when you’ve just had an exceptionally tasty portion of steak and chips for dinner! I’ve settled for keeping the usual pile of paperwork under control. Speaking of which – I must sort out last quarter’s VAT return before I miss the deadline…

Bah humbug. The new office on Rutland Square was looking better and better, and we were days away from signing the lease. Sadly though, delays in organising things amongst the three companies to be involved meant that someone else has seen the place and signed the papers all in the space of a week, and now we’re back to square one in our search for an office. Boo hiss. On the bright side though, the new office would have been a tad smaller than the current one, so at least now we’ll have the potential of finding somewhere with a bit more room to grow.

In other news, our prototype games on WiiWare are now looking like actual games, although I’ve left it in the capable hands of Pete and Tim while Charlotte and I have been taking care of our clients. So as not to be left out of all the fun though, I’ve taken on a bit of hobby coding and am converting our somewhat ungraceful build process (a combination of Lua scripts, makefiles for Wii/PSP and Visual Studio projects for Win32), and am converting it over to use JamPlus. There has been a lot of debate on the sweng-gamedev mailing list and elsewhere about getting build systems which cope with the rigours of game development. Jam had the most potential but development of the main version of it has pretty much died off, and the patches and work required to get a Jam build suitable (performance and flexibility-wise) for games development is enough to put everyone else off.

The helpful Joshua Jensen however has done some sterling work in putting together all that existing work in a practically off-the-shelf tool called JamPlus. I’ve been most impressed with its speed and flexibility so far, and thanks to Josh I’ve learned enough of the scripting logic to convert our quite specific build needs into Jam logic. Once it’s done I’ll publish our scripts to serve as an extra example for folks (minus all the Wii and PSP stuff that’s covered under NDA of course), hopefully that will help others and get it to be a well accepted tool. As always, I think anything that helps efficiency of games developers in general is good, but really it’s because as our prototype games have grown, it’s become clear that we need a proper dependency-checked build tool to manage our asset->game toolchain.

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.