Check me out!
It's a framework whose contributors are friends and ex-colleagues of mine from Crytek. It enables you to recompile specially-crafted code in your project without having to restart the executable. It supports crash protection (if the come you compile in crashes, it'll just stop executing that new code and keep the application alive) and the framework itself looks to be quite non-intrusive.
I want to incorporate this from the get-go, because I think it'll prove to be invaluable later on. The promise it gives, is that I can implement my new ideas rapidly without fear of the simulation crashing down if something doesn't go right. This sounds ideal for AI development.
If I can use this to tweak and extend a new behavior, or a new pathfinding system, or a new conditions wrapper, without having to restart the simulation each time or rely on the shoddy edit-and-continue feature of Visual Studio, it seems to me I'll save a lot of time and energy. In the past, I've achieved this same result (to an extent) using external scripting like Lua. But that always came with its own set of problems. If I were to put the behavior of the AI in Lua - that is, catch the inputs from perception and events from the rest of the engine, and determine the next output for the AI, like where to run to or where to look and shoot - then I would need to expose all of these inputs and outputs into the Lua language. It's a lot of extra baggage and it means every time I add something new or change how something works, I also have to deal with the Lua API. If you encounter an error in a Lua script, that Lua chunk stops executing and your simulation might become stale or, worse yet, your application might crash from something not being executed at the right time. You've also got your standard performance issues, your distribution issues and your multi-platform issues. Blech!
But if I could get all the benefits without having to use another language - if I can get the "rapid prototype" benefits of Lua within C++, sitting right next to all of my inputs/outputs/whatever-puts in the Game Engine, so I don't have to do any additional work to get there, then sign me up!
I might have missed it in the documentation somewhere... but one thing I think I'll want to add support for in it is responding to assertions in the same way it handles crashes. It'd be great if, on assert, I can ask it to stop executing that code until the next recompile. Crashes can sometimes happen too late, and a properly-placed assert can help you understand what bad things are about to happen long before it comes to that point. To stop the code from degrading and leading to that future crash, I think, will help me out down the road.
Kevin
You sound like you're coming at this from just the same angle as me Kevin :-) I also like that there are various XML-parsers etc that I just needn't bother to write - I can just "soft-code" it and change it at runtime.
ReplyDeleteYou make a very good point about asserts. When I realised the same issue, I immediately wrote a new assert macro that just dereferenced a null pointer! This worked just fine for a start! Very satisfyingly, I was able to swap in my new assert over the whole runtime codebase without restarting ;P
Thanks Matthew! Don't get me wrong: Lua, Xml, even INI files are still important when you need to expose some conditions to designers or support an intermediate file for an external tool. But for soft coding jobs, they're so not needed anymore with this framework in my opinion.
ReplyDeleteI do agree, especially re intermediate files. However there are a couple of things I want to look into in this area. I think that when you create a graphical tool for, say, a behaviour tree, you need an XML format as intermediate so you can easily read it back into the tool - but in terms of what is actually used by the game, it could generate C++ on the fly.
ReplyDeleteThe other is that perhaps - just perhaps! - designers could be given a subset of C++ that they could use as a scripting language. Think of a function they can fill in, with evil things #defined out, objects passed in they can use, a library of useful available functions, and crash protection. I think that presenting a well-defined context for designer functions is probably more important than the language itself.
Oh, and a simple case of that: one-line evaluation terms in something like a flowgraph, or as parameters in editor objects.
It's something I plan to toy with! I wonder if you think it's plausible.