Cover System Implementation Ideas

Unity Engine
1

Hello,

I have spent quite a bit of time researching implementation of a cover system within Unity. There doesn’t seem to be a huge amount of literature on the matter. What does exist seems solely concerned with AI decision making (which cover is best etc). That is why I have come to these forums in search of help.

What I’m trying to achieve is two-fold.

  • The ability for a player-controlled character to enter and interact with cover (including features similar to those in Gears of War, Mass Effect - the typical things expected from a heavily cover-based game)
  • The ability for AI characters to select and enter cover that protects them from the player.

In some cases, the player may have allies and therefore needs to interact with them in situations where a single piece of cover is occupied by both the player and any number of allies (for example, if the player tries to move about in cover and is blocked, the suspect ally should move out of cover).

I have come up with two possible solutions, that struck me as making most sense.

  • The main idea I was considering is heavily editor-based. It involves setting up any number of Cover Slots at each cover object, which can be occupied by either the player or AI characters. Characters could move from Cover Slot to Cover Slot assuming the path was clear between them. Clover Slots could also be linked together to allow switching between different cover objects. This system seems*more suited to AI characters, as I can envisage difficulty when the player moves (de-occupying then occupying different cover slots may prove difficult ti implement perfectly). Tools could be provided for design-time to speed up the process of creating cover nodes.
  • The second idea was a ray-casting system. This would be almost completely dynamic, with very basic specification of which object could be used as cover at edit-time. I imagine this would best be suited to player-only cover usage, as it would perhaps enable more fluid movements etc. However, I can imagine it would be significantly more complex, slower to run and contain more bugs than the former system. It would also take much of the control out of the designers hands, which may either be a good or a bad thing.
  • I suppose a hybrid could be done, but this may be more trouble than adapting one of the other systems.

What do you think of these ideas? Are there any other ideas you can think of to best implement the cover system?

I’d really appreciate any advice you guys have on this matter.

Thanks,
JITB

2

Hybrid would work well. Even though I’m against the chest-high-wall approach of all games after gears of war, I did spend some time thinking about this. One pointer should be to watch how existing games like Mass Effect deal with the aforementioned problems. ie. when you’re trying to take cover on an already occupied slot by an NPC, the collision triggered forces the NPC to move to the next empty cover spot, and failing that, to move out of cover (game should be biased in favor of the player in such behavioral decisions, otherwise you’ll get a lot of angry players).

In addition, note that one cover node could provide cover towards more than 1 directions (circular bunker walls, corners, etc). You can use a dot product calculation to determine the angle of the player relative to the wanted cover direction, in order to apply the appropriate animation and setup. I have yet to see a cover based game handle corners fluidly. I guess Mass Effect’s middle mouse button to change corners is the most fluid but also less intuitive, and leads to situations where you want to exit cover but can’t because the game expects you to corner-move. Player controls should decide the appropriate cover position, not intermediate button mechanics.

You should basically use level editing for setting up the cover nodes (and which sides provide cover), tagging them with appropriate tags, so you don’t run for cover on whatever you collide with, and blend this with raycasting for NPCs, and some algebra for corners. I think only opting for one method will cause more issues than it will solve.