Update report and a bit of an AI rant


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.

About these ads

About Bobby
I'm a programmer at Ubisoft. My work interests include Animation and Artificial Intelligence. All opinions are my own!

6 Responses to Update report and a bit of an AI rant

  1. Justin Paver says:

    “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 I wrote in my thesis. There are much bigger unsolved problems out there than for example faster pathfinding but you cant really see them from the outside”

    *slow clap* and quoted for being the truth :)

  2. Bobby says:

    Haha, yeh, it’s so silly looking back at it. I’m also to a certain degree disgusted with how much certain academic papers warp the truth just to justify their minor gains. I had to review a paper recently and even though I felt like it was a complete load of crap and totally pointless, I couldn’t find any technical reason to reject it :(

  3. sievandyk says:

    Bobby, your (really) old post of neural networks helped me in my last AI project at UP – thanks! It’s sweet that you’re posting again. Dude props for taking this on, must be hectic.

  4. Aye, the point of having an AI subsystem to begin with is so that game-play programmers don’t have to write scheduling code…heck, I’d always assumed that was the case with the majority of modern engines (from limited experience with some of the more stable ones). That said, there’s a caveat: suppose you want to reuse your engine for a title in a completely different genre. Such as, let’s say, an RPG-style game where only the simplest of the AI is combat-related (this being what I do currently), Sadly, in this case, even the most advanced behavior tree won’t quite cut it; no matter how interesting the behaviors are, they’ll seem strange and repetitive if they always trigger using roughly the same logic. Given that, how do you foresee what features need to be included in a “deferred AI system” so that it can be encapsulated, and then used and reused several times without almost completely rewriting the original subsystem?

    So you come to a crossroads, is my point: do you implement ALL the features in your isolated system (making it intractable to develop and stealing time from interface design) or do you only do multithreaded behavior trees, A*, and the usual stuff (and risk total deprecation when your studio decides to produce the next Skyrim with moar AI)? I guess there will never be an answer to this question, but surely one way around it, however undesirable and messy, is to incorporate features as needed into the gameplay code…

    Something to think about, anyway.

    • Bobby says:

      Yeh, changing genre is a problem but thats assuming you’ve done the game specific thing and wedged in a BT into the core of your AI system. Let me start by saying that a huge amount of a game’s AI is game specific and cant be pulled to the engine layer. That said, I feel that a BT (i’m using it as an exmaple since its what I’m currently using) or any other decision making system can be split into two parts: the evaluation, state and resource management, and the game specific actions/knowledge queries. If I build a BT, I can build the architecture for evaluation, state management and add some generic utility nodes (parallel, sequence, mutex, etc). The gameplay programmers can then extend this in the game layer by creating game specific nodes without having to worry how the tree is built or how the state is organized. If you swap genre, you can build a new decision making system (in addition to the BT) in the same manner, now giving your engine level AI system more flexibility in solving the game specfic AI problems by giving you the choices between both decision systems.

      The way I see it is that I’m laying the foundations for others to build an epic building on top of. I’m not building a shell and only letting the gameplay programmers pick out small things like the type of windows or the color of the paint. My current system allows a designer/game programmer to wire up (we use visual scripting exclusively) any set of game specific sensors to an AI core, as well as attaching a game specific actuator (usually just an animation graph driver), the decision making system is then also attached to the AI core. All these components have a base interface in the engine but are 100% game specific and will always be due to genre changes, animation system changes and so on. The point is to improve workflow for gameplay programmers that want to do all sorts of crazy wonderful things. There is nothing stopping me from building a BT evaluator in the engine as well as an HFSM system, then using a mix of both as I see fit on the game level e.g. use BTs for the UberEliteSpaceMarine and FSMs for things like pigs and chickens that just randomly walk around.

      At the end of the day most decision making boils down to a big if-statement, we just like to act fancy and claim that there are profound differences on the end result of the if-statement based on how we structure it. If I want to do some fancy utility based stuff then I just build a game-specific utility node. If that node turns out to be generic enough, we can then pull it to the engine layer just building a bigger tool box. If we feel that we need influence fields, we can build a generic system to discretize the game levels, and assign whatever values we want at the sample points. A lot of the gameplay guys here pretty much just want to write cool behaviors not spend 3 days, discretizing the navmesh. Again this is all just personal opinion.

      The deferred concept is a little bit of a personal joke since I have a bit of a render background, basically I’m just using to term to say that we basically pick some AI tasks to run each frame and defer the execution. It’s nothing fancy, just pretty standard async job scheduling.

      Again this is all just my silly opinion :P

      • Hmm, interesting. Yeah, honestly I’m not as current on some of the newer features and stylings of BTs…in fact, we don’t even use them for what I’m currently working on. It’s all weird utility stuff and planning. It’s designed for one game (well, mod) that, again, is largely not combat-oriented.

        So maybe I’m still thinking of BTs as sort of a glorified FSM (that is, after all, how they’re done in CryEngine 3 FreeSDK…more and more, I have a strong feeling that these tools don’t reflect industry state-of-the-art very well XD). It sounds like they’re more of a scheduling tool that can be used in all kinds of ways though…

        I think this is a very good way to structure it though. Thanks for the answer! Will definitely keep this in mind if (and probably “when”) I need to design something similar.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: