Update: In Charles’ own words:

During our multi-year relationship, we have leveraged Matthew’s expertise to transform our engineering team, CryEngine3 and our AI toolset. Our frequent videoconferences have been invaluable as he constantly helps us expose existing functionality in the CryEngine3 AI framework. Additionally, we use Matthew’s on-site visits for detailed problem solving, process optimization, and cross-discipline benchmarking which, among other things, allows us to continuously evaluate ourselves and recently resulted in streamlining our character prototyping pipeline by 50%. As a relatively inexperienced AI team, Matthew provides expert validation for our approach to AI regarding our specific game requirements. He has now become a virtual member of our Engineering team.

Charles Hollingsworth, Engineering Director, Xaviant

After my presentation at the Game/AI conference in Paris, I headed on over to Vienna where I’ve been lending my experience to a new team at AiGameDev HQ. We’ve been developing new features and demos for their internal AI prototyping environment, the AI Sandbox.

I’m also continuing work with some other clients, including Enodo, a visualisation company based in Nice. More on that to come.

It’s fantastic being at the hub of the games AI community and sharing the experience of veterans such as Alex Champandard and former EA physics expert, Phil Dunstan. I’ll be here until shortly before Christmas.

In our presentation, Doug Binks and I talk about the headaches AAA studios find down the line with scripting languages. During the conference, it brought a smile to my face on several occasions to hear other speakers mention that they just used pure C++, or had dropped their scripting language, or in the case of one FPS developer, ask why on earth anyone would use one anyway? This may sound alien to you – hot-reloadable scripts seem like a no-brainer for the rapid iteration they allow. However, the bigger the project, the more headaches they seem to entail – the API maintenance, lack of good debugging tools on a multi-million line project, lack of multithreading support and the performance problems.

In the RCC++ project, we show how you can get that same hot-reloading functionality from pure C++. We don’t use any interpreter. An enabled project can compile as normal to a single DLL, but it watches it’s own source code, and as you make changes to it in Visual Studio, it recompiles itself a file at a time into tiny DLLs. By linking these in at runtime – and making use of serialisation – it can bring in your changes in just a few seconds. All the state of the running game can be preserved, while you bring in whole new features to your live C++ application.

We had a few more things to show. When you can make small rapid changes so easily, it’s important you don’t bring the house down with your first null pointer. In RCC++ we allow you to debug crashes in Visual Studio as normal – but then to catch them and carry on running. Your app keeps on running even if the game objects have to stop, until you fix the code – and it all sets off again.

As you play around with it, you start to realise all the simple tricks you can use this approach for. We show how you can create a C++ interactive console that lets you interact with your C++ objects – without having to add reflection code or a complex API. And how you might not need all those XML parsers or GUI tools any more, if you can just edit the source freely. As an independent developer without a tools department, these bang-for-buck solutions really appeal!

So there’s the summary. But if you’d like to hear more: check out the teaser video below, the Runtime-Compiled C++ blog, or fetch the MIT-licensed source code and play with it yourself.

First Steps from RuntimeCompiledC++ on Vimeo.

I’ve been asked to lend a hand with the Paris Games AI Conference, sitting on the advisory board and reviewing submissions. It’s been fascinating – so many good proposals and a reason to sit down and read a whole bunch of research papers.

It’s an exciting time to touch base with Frankfurt and a good opportunity to catch up with everyone, see how they’re faring and how development is going.

[This work saw the light of day with the 3.3 release of the CryEngine SDK]

For an in-depth treatment and technical details you can read the original article “Code Coverage: Informing the QA Process” in Games Programming Gems 8 or watch a discussion with Alex Champandard in a masterclass video available at AiGameDev.com. You can also check out the C++ source for an example implementation mcover.