I’m going to do an AI cover generation system for the AIJam this week and I wanted to ask you peeps about the UI for it.
Basically the cover system isn’t the issue here (its pretty simple to do that thanks to Mikko Mononen’s excellent presentations about how to do it from the Paris AIGameDev conference back in 2011). My question is concerning the UI to provide for devs to use.
The idea is pretty simple, it generates a number of cover regions (essentially rectangles that sit on the navmesh) that provide cover. The cover is annotated (which direction etc).
But as with most things AI, I always feel uneasy doing a system that is entirely procedurally generated. Because there’s always some edge case that doesn’t generate in quite the right way. Plus designers usually want some way of simply disallowing specific generation artefacts or regions.
So my thoughts are:
Add an “AI Tools” button to the main tool bar in the editor. Have one of the drop-downs of that be to regenerate cover, which is only available if a navmesh volume is selected. This would be the automated pass.
Clicking the button would repeat whatever was the last selected action, so if you just generated cover, it would do that.
There would be an “options” dialogue you could popup that would allow you to set some filter parameters. So stuff like how often it sampled the cover, what height “high” and “low” cover would be etc.
Allow the designer to simply delete cover generated (so each cover region would generate an actor that could then simply be deleted)
OR
Add a new volume type “cover generation” that would have properties for the options presented in 3) above. It would generate cover within the volume (assuming it would only sample the area that overlapped the navmeshbounds)
Designer would have to click a “generate” button on the volume for it to actually generate cover. Cover items generated would be (optionally) added as children of the volume.
OR
Have a “cover generation” mode in the modes tab (basically similar to the landscape mode)
Designer would “paint” the regions they wanted cover to be created for. With cover being generated as they painted and then filtered out over time (so you’d see a bunch of circles created and then removed as they are checked for validity)
OR??
Any ideas?
One thing to note, is that designers will be able to manually place cover regions by hand. Not sure how yet but possibly by dragging out a volume or polygon as you would in a 3D app.
Just wondered how other people saw these toolsets being used. Or if anyone had any experience/preferences. Honestly the code is going to work fairly similarly, its more a matter of how the designer might use it.
Oh, the other thing is, does this need to be runtime regenerated? I mean the navmesh itself is runtime rebuildable, so it makes sense that cover might be. But then it suggests that procedural cover placement is more important than the designer versions.
I think the easiest code to upkeep over time and the system that would give you the most flexibility for later additions + easiest system to debug would be to use volumes!
if you just extend APhysicsVolume then your new volume will magically appear in the modes->volumes section, and you can add your uproperties there so people can instantly be modding the behavior of individual cover volumes
The reason this becomes so easy to debug is that the volumes have per-instance data that is part of the runtime world, in the form of volume actors. So you can easily iterate over your volume actors in-game and get all the data!
Using APhysicsVolume volumes you can combine your preferences for auto-generation and user customization with a ui-setup that is instantly ready to go and editable per-instance without requiring an editor mode or even any engine code modifications
That would surely be the fasted place to start and the easiest way to get others involved, and all code could be stored at the project/plugin level, not requiring any custom engine version stuff.
Then as you go that route you can gauge community response and only make stuff more complex for yourself if you find there’s a real need to!
But with a custom project-level APhysicsVolume extending volume, you will already be able to tweak cover system per-volume, per-instance, while also providing auto generation for places were volumes are not placed!
Rama
PS: Only reason I specify APhysicsVolume is because that is the class that I know, if you extend it at project level, the new volume gets auto-added to Modes->Volumes section, effectively requiring 0 engine code modification to get all the benefits listed above.
I’d go with the second set of bullets with the volume generation so designers can disable certain volumes for certain combat encounters/situations. I’d also be interested to see how you find the cover regions using Epic’s recast wrapper. I’ve been meaning to attempt it on my own but too busy in crunch mode at work.
I’ve manage to do cover generation system , for me I would
personally prefer a system where I can add cover to any type of actor.
So technically If you ask me , I would prefer a 'right click → enable object as cover "
In my own system :
I’ve made a BP component called cover system.
For any asset that require cover. I will add this component and set the mesh’ to block
a custom trace channel.
I then have another object that I’m using the blutility to generate the cover. I also use this object
to preview. Of course this isn’t ideal , since I’m not going to be making custom engine modifications. I don’t
have much choice.
But If I have a wish , I would make it so that I can right click add cover and it would automate.
Regarding previewing cover , I would certainly prefer to use the Visualize Tab(with a shortcut key ) on epic’s viewport options.
Thats quite an ingenious setup, but it feels far too manual to me. I’m using the navmesh edges to know where the edges of cover are then doing a bunch of raycasts along the length of the navmesh edge to determine cover height.
I’ll post it as a plugin once its working properly.
