![]()
Visiting guest. Why not sign in?
|
|
Reply to Message
Not registered yet?
The AI Depot has a focused community of friendly users. Rather than let anyone abuse the site at the brink of promiscuity, we prefer to let only those with an active interest participate... this simply requires registering.
Why not sign up!
Joining the site's community is completely free. You can then post messages freely, and customise your personal profile at will. Specific privileges will also be granted to you, like being able to access printer-friendly articles without restrictions. So, why not register?
Parent Message
Return to Castle Wolfenstein: AI Analysis
Review - Return to Castle Wolfenstein
This in depth review covers an AI analysis of the highly acclaimed game. The techniques used are discussed from a developers point of view; working techniques and pitfalls are pointed out, along with potential improvements for the future. I had to put myself through a lot of agony playing this game just to bring you this review :) But seriously, comments welcome! |
|
Return to Castle Wolfenstein
Great article once again, Alex :) It's been a while since I played RtCW last time, but I recognized many of the pitfalls you noted. I think the biggest flaw in RtCW AI (as in most of the FPS AIs) is the lack of randomness in their reactions. FSM's yield quite a dull behavior. I think much more interesting approach would be to use some kind of stochastic FSM, where there would be many possible transitions with different probabilities. Of course that would make testing and debugging quite a bit harder. |
|
Fuzzy State Machines
I didn't think the behaviours were dull. Admittedly, they did seem quite consistent (when you play a bit over and over), but they use lots of other tricks to make them interesting... - Varied Unit Placement All this contributes to making the AI less monotonous. |
|
Great job and a few comments
Hi Alex, great job on reviewing the game AI of RTCW. I enjoyed reading the article and recognized many of the events and behaviors you mention. On two occasions, however, I either fail to understand you or we disagree: I don't think it is correct to blame the _path finding_ subsystem for bad AI _path following_ / _steering behavior_ / _obstacle avoidance_. It is not the resulting path that is flawed, it is the AI behavior that does not respond properly to dynamic obstacles that it runs into while travelling the path.
Looking up cover positions from a table is over hundred times more efficient than issueing ray casts (and does not hit on (slow) memory and thrash the cache, as does traversing part of the BSP). Typically finding a good cover spot requires more than a handful of ray casts, because: I may be picky about these details, but as said above, I enjoyed this review and look forward to future reviews. William |
|
Path Planning + Seeking Cover
Thanks for the comments William. Regarding the issues you raised... 1) In an ideal world, the planning of the path is fully dynamic, and takes into account live obstacles. This implies a direct integration of path planning and execution, as I like to call it. This is why I blame the planner, as it should monitor and take into account the execution. However, this is naturally not yet possible for efficiency reasons... Since they had a static planner in AAS, they should indeed have some consistency checks; did we actually move forward? Should we recompute another different static path? This was not done for NPC, so I can see your point too. The reason it bothered me is that AAS cannot return different paths for different units (I think that's right, due to the global "cache" and static path parameters). Basically, one unit in the doorway would go through it, while the one just behind would go around (in theory). But AAS would return shortest paths in both cases, forcing both units through the door. Countering this would involve stopping one unit for a while (wait behind doorway), or getting it to do something different (if the obstructing problem is even identified). 2) About the speed issue, fair point -- though the BSP would be in the cache already, for physics computatations. It wouldn't be quite as bad as you make out when done at the right time. My experimentation with this is still in its early days (trying to get Piglet and Pooh to play hide and seek reactively :) but I've noticed spreading the traces over a few seconds makes the result more human like; first find cover approximately (body hidden), then fine tune when the bot gets closer. Thanks again for the comments, I really appreciate people actually reading and reacting to this ;) |
|
Back to the Artificial Intelligence Depot.