Almost at the point where I can dive into some more C++ oriented AI work for the summer. One of the bigger projects I’ve set myself is a cover generator. So i wanted to spitball some ideas regarding the cover system here with you lot, get some feedback if anyone cares to dive in.
So the basis for the cover implementation is essentially the stuff I’m going to steal from Mikko Mononen and Matthew Jack that they both did while doing AI at Crytek (I think Matthew did a pass on it after Mikko, but I might be wrong there). Anyway, the basic functionality is pretty clearly documented on the pages Matthew wrote for Cryengine. The main thing is to have a very configurable cover selection system, pretty similar to EQS in many respects, it generates and scores points. My plan is to essentially generate a bunch of cover locations with associated data (using user configurable data attributes and a way to setup a cover scoring class to plug into the system) and store them in some hierarchical data structure for quick lookup. Then implement an EQS generator that allows a configurable subset of those cover points to be selected and scored for the final cover selection.
But here’s where things get a bit tricky, because I am doing a Rainbow Six style game and I want to be able to support various scales of conflict, for instance some tight CQB in a single building, or some longer range hijinx over a larger terrain (hell why not if UE4 does it right?). So I’m thinking that from the outset I’ll need this to support dynamic generation (i.e. as things dynamic load for the landscape). My initial plan is to simply find the entry points for the Navmesh streaming/generating and grab the navpoly data from those to feed into an edge list for cover generation (cover by its definition only really exists where the navmesh has been carved by something).
Hooking the navmesh should hopefully give me the same sort of workflow, in that it will be mostly automated as the level is built. But then can be augmented with additional designer placed hints (one use-case for me, is door breaching for a swat team, where the door initially might block the navmesh, but then once the door is opened the cover points that might have been generated would naturally get changed). Designed hints for the door use-case are needed to make sure that the cover selected understands the relationship with the door state.
I’d love to do some work on implementing Ben Sunshine Hill’s stuff from AiGameConf 2014 regarding using volume sweeps for things like mantling navigation generation (essentially a really nice way of choosing where AI can vault over obstacles etc without collision). But I doubt that’s going to get done in my summer break.
So my main issues design wise are:
What data do we need to store for a particular cover spot. Do we want that to be designer/programmer configurable ala the EQS? (I’m thinking so).
What is the most rational data structure to allow rapid lookup of cover locations considering that the navigable area at any time might well be streaming out or changing. It might have multiple overlaps etc.
Does this cover generation need to be a user-chosen action. I.e. is it fully automated, or do you have to refresh it manually if you’re working on a level?
What kind of debug information is required for designers to know they can rely on the system when working on AI and level design?
How much designer input is needed overall, can we live with some simple trigger-type hints, or must they be able to literally manually reconfigure the automatic generated content?
What kind of programmer API is needed to provide the information required. I’m assuming a very EQS style system (generator, filters, output buffers filled over multiple frames, notification based etc), is there anything better?
Would love to hear your thoughts about this. I’ll probably give it away when its implemented, or submit it as a PR for inclusion in the normal build.