A few weeks ago, a promotional trailer was released for Brothers in Arms 2. It’s interesting from more than a marketing perspective because it reveals many challenges that should be familiar to developers working on first-person shooters. A big thanks goes to Remco Straatman for pointing out some of these issues and the original video. It only hit me a while later that this would make an awesome video blog post.
In this first part of my analysis, I look into destructible cover, in particular how it becomes much harder for the AI to handle if it’s simulated using a regular physics engine. When raycasts are too computationally expensive as a solution, then a behavioral approach is always a good fallback. Watch the video below for more details; it’s 7.8 Mb and lasts for 2:47 minutes.
Note that I’m not trying to pick holes in the game or the AI; these kinds of situations happen in many games that have shipped already. Also, this first part of the video is the only I’d really consider to reveal a “bug” in this game — but it could probably be fixed in a few hours anyway.
Anyway, video editing always takes longer than I expect, so stay tuned for parts two and three in the next two weeks! In the meantime, if you have any comments, feel free to post them below…
7 Comments ↓
I don’t agree with your assumption that because the fence is being torn apart using a physics engine, then they only way for the AI to know this is to use ray-casts.
The fence seems to be composed of dozens of “fence bits”, which remain as static geometry until a “destroyed” event is triggered by the game (e.g. getting hit by ‘x’ number of bullets). When this happens, a “fence bit” stops acting as static geometry and is handed over to the dynamics system.
Seeing that this hand-over from static to dynamic is triggered by the game logic, it seems quite feasible that the game-logic could easily record which sections of fence are still intact, and which are not.
Meaning that the AI characters could quickly and efficiently query the number of “fence bits” in front of them - if this number is above ‘y’, they know their cover is ‘good’, if it’s between ‘x’ and ‘y’ the cover is ‘acceptable’, and if it’s below ‘x’ the cover is ‘bad’ not non-existent and it’s time to move!
Assuming that once a fence bit becomes damaged that it will never again act as cover, I think this particular examples has just been solved ;)
I love the video blog.
Although raycasting isn’t necessary the only solution as Hodgman pointed out. In both Alex’s example and the former, a character would not consider moving if only the small top piece of the geometry (clearly exposing his head). Of course a precise check like this also isn’t necessary, to ignore it would take away from the immersion and quickly summarize the AI (formations, cover, planning) into being “stupid”.
Nice post. I just feel that hiding behind a fence while they are shooting at you is a bad idea no matter how many “fence bits” are missing… :)
Techical note: I can’t see the embedded video using Opera. I had to dig through the html source to download it.
Even if the physics is dynamically broken you could use the volume of the bounding box as an estimator of how much cover was removed. So, at the start the fence is ‘100%’ cover. Then as pieces are removed it will decrease. AI tracks the cover ‘probability’ of the object it’s in cover with. As bounding volumes are very conservative you will reach 0% a lot faster than the actual visual representation suggests, but in practice that shouldn’t be a problem (it makes your AI appear smarter the earlier it leaves cover which is getting destroyed). At some point your behavior will just decide that cover is getting blown to bits and the AI should do something. This could also take distance to attacker into account (as well as angle of attack). The guy will likely die anyways within the next 2 or 3 seconds, but getting some reaction out of him will make him appear smarter :)
Looking forward to parts 2 and 3.
They’ll never use a wood fence as a cover, period. :-)
My first thought to get around raycasts was to simplify the way the AI handles it a bit. Instead of doing expensive line of site checks, take what you already know: there is a piece of cover here, and it has this shape of hitbox. You also know that you need to take cover FROM something, and where that something is. From that, you can look at all the available cover around you and ask "does this protect against attacks from that direction? How much?"
I'm short on time, and I probably am not thinking this through properly, but I'd think that you could map out safe areas fairly easily just by assigning the back side of cover (ie, whichever end is facing AWAY from the target) some kind of influence on the environment, be it via some kind of grid or some other, better tool. You don't need to know that a specific piece of cover halfway across the map regardless of distance (which raycasts would do), you only need to know what area a piece of cover makes safe, and probably limit it to a specific range from the object.
Reading over my comment again I think it sounds a bit harsher than I intended…
Dynamic cover *is* a serious issue, and my work-around only holds up for this particular situation (the breakable wooden fence) - if the cover in question was made of metal boxes than can be pushed around, you’ll need yet another solution.
Also, while I’m at it, the wooden fence isn’t in fact cover at all - in military terms it’s only concealment, and a soldier should never try to use it for protection from bullets ;)
Leave a Comment
You can also reply to this thread in the forums.