I have been extremely quiet for the last couple of months and I feel bad that I’ve neglected this blog (especially since I promised I wouldn’t). I’ve been extremely busy with work and my AI prototype and I havent really had too much time to work on anything at home. To be entirely honest, after staring at Visual Studio for 10+ hours a day, the last thing I really want to do when I get home is fire up visual studio.
It was a lot easier when I was in academia, to a large degree academic work is tedious and boring, I couldn’t wait to fire up VS and fuck around with some ideas or whatever. Now I pretty much much get to do that at work (and get paid for it). Dont get me wrong I’m still working on things outside of work (more on that later) but unfortunately it’s pretty hard to discuss them since they are built in our in-house game engine and as you can imagine I cant really post any of that stuff here.
I’ve spent the last 10 months working on Hitman: Absolution ( out 20 Nov 2012). I started out on the crowd team and helped to get the base system built. After that I jumped around between system but firmly stayed in AI land. I now find myself the owner of our navmesh, pathfinding and avoidance systems. The last few months have really opened my eyes to the reality of game AI and the actual problems that need to be solved. The picture painted by hobbyist game dev books, research articles and academic work is extremely misleading especially for larger projects. I almost want to go back and slap myself for some of the academic nonsense that I wrote in my thesis. There are much bigger, unsolved problems out there other than faster pathfinding (or how to build a behavior tree) but you can’t really see them from the outside.
It is these problem’s that primarily interest me, I find myself not really caring about how blazingly fast my A* is but rather worrying about extensibility and scalability of the AI systems. I worry more about code-data dependencies more than my decision making data structure. I worry about workflows and designer control more than how to rate a cover node with respect to a threat. I’ve realized that I’ve moved closer to the engine team than the game team and that is where my primary interest lies.
I’ve always been more about the frameworks than the content, even in my PHP (*shudder) days. Back then, I built a complex template framework system with auto sql generation and access control systems, I didn’t really focus too much on the content but rather on the system and the overall architecture. I find myself in the same position, I’m not as interested in making games as much as I am in building the tech behind games. I guess that I always knew that but it never really hit home until I read a forum thread about an article I had written about higher education and game dev. A childhood friend described me as never really being interested in the local indie game scene and someone that never really built anything. And that was true, I found building little game prototypes boring when compared to screwing around with graphics programming and engine components. So why am I mentioning this? Well because I’ve noticed a rather disturbing trend where game AI is undistinguishable from gameplay code.
In a lot of games there is no real seperation between the AI systems and the gameplay systems. The AI systems are built hand in hand with gameplay code and extended/tweaked as needed arises. Decision making systems are integrated with game specific knowledge systems, dialog systems and animation networks. At the end of the project, it’s extremely hard if at all even possible to decouple the AI systems from the game code. It can potentially be a lot more effort to try and untangle the mess than it would be to rewrite the systems for the next project. If you take a look at the major licensable game engines, none of them feature any AI system past maybe a basic navmesh generator, hell even the bulk of the game AI middleware is just a navmesh generator, some steering behaviors and if you’re lucky some flavor of state machine editor. Considering the large reliance on middleware systems in the industry, AI code can often become the glue code that ties everything together and so the term AI programmer can actually mean middleware integration programmer. I guess that the distinction between gameplay programmers and AI programmers can be quite fuzzy and I’ve heard of some companies that dont even have any “AI programmers” on staff just gameplay programmers.
All of this, in my (possibly naive) opinion is a waste of effort and can be greatly reduced with some fore thought and tech effort. We can, and should, try to generalize and seperate certain AI systems away from the game code. These systems should be moved to the game engine layer and be extended and maintained by a core group of tech programmers. Gameplay programmers should just focus on working with designers to pump out awesome behaviors and make a kick ass game without having to waste time building debuggers, decision systems, job systems, schedulers and so on.
Now the trick is how to identify and seperate away these systems. There is always the danger that you over generalized system and there by make to rigid to achieve the required result and thereby you hurt the game, on the flip side if you under generalize then its super hard to reuse anything for another project.
This is exactly the problem I’m working on solving in my spare time. I’m basically focussing on improving AI workflows, performance and debugging tools. I think by now it is obvious that data oriented programming and parallelism is the way forward and so I’m focusing on building what I like to call a deferred AI framework, with a dependency-aware asynchronous job scheduler at the core! I’m also super lucky that I have some awesome guys at work that I can bounce my ideas off of. I tend to get excited and run wild (I’ve also come up with some amazingly stupid ideas) and my colleagues have been an amazing sanity check for me ( i.e. slapped some sense into me ). Anyways, my progress so far has been that I’ve built a very basic AI framework in the glacier 2 engine as well as a generic AI Knowledge system and while I’m not really ready to demo anything yet (I have a todo list as long as my arm), I can at least start to discuss the overall system architecture.
I’m really hoping to throw out some design ideas over the next couple of weeks, and see what people think. There are a couple of problems that I havent exactly figured out how to solve as well as a couple of crazy ideas that might need additional sanity checks.