Ahoy! I've returned from a (short) voyage back into the engine and have returned with... vaulting! And some new movement options I'm still tweaking, but so far they feel good even with the prototype animation.
You can check out all the major updates in the video below (I admit I enjoy making the videos too much, but it helps motivate me, ok?):
Vaulting Cover - Design
Alright, let's start with the biggest addition, which is vaulting over cover. There's a lot of thought I'm still putting into how I'll tweak this, but I just wanted to get something roughly close to what I envision for now. Having the ability to move over a wall of cover is fundamental to a cover system, so considering how fast that happens and some of the surrounding actions (can the player reload, change directions, etc. while vaulting?) is super important.
These are some of the big decisions I've made with regards to the design:
- Vaulting should be fast (no more than 0.5 seconds after vaulting to regain full movement control).
- No shooting while vaulting, however reloading and switching weapons while vaulting is possible (logic for this is already implemented, but the anim transitions look awful right now so I didn't show it in the video).
- Vaulting should be key to moving around the map, and therefore it should take precedence over moving left and right in cover in terms of which is more "sticky".
Let me expand on that last one. The player can vault while they're inputting the left stick towards the wall. I can also control in code how much the player needs to rotate the stick away from the wall to start moving, and while they're moving they can't vault. That means that if I give too much leeway in terms of movement, the player will expect to vault because they think they're pressing the stick towards the wall enough, but they'll just be moving in cover instead. This is a huge issue when trying to move fast, especially. Making movement more "sticky" (you have to press the stick more along the direction of cover to move) makes it feel much more polished, because it's easier to slide and vault quickly.
I'll be continuing to tweak this as time goes on and the game fleshes itself out more!
Vaulting Cover - Implementation
Here's the basic run-down of what happens when a player vaults cover in my implementation:
- Code checks to see if the "bCanVaultCover" variable (which is set by the CoverCollisionBox that the player is currently in) is true and that the player is inputting the left stick towards cover.
- If so, a replicated "bIsVaulting" variable is set true and the vaulting animation starts playing.
- A value is retrieved from the CoverCollisionBox that tells the MoveComponentTo function how far to go to get across cover. That value is multiplied by the player CapsuleComponent's forward vector, which creates the final location the pawn should move to.
- Tick is enabled and the MoveComponentTo function is used to move the player forward across cover over a slightly variable amount of time (depending on the length of cover).
- The callback for the MoveComponentTo function occurs ~0.3 to 0.4 seconds before the vault animation ends, opening up the possibility for animation canceling, as seen in the video above.
Thus, vaulting is now a reality!
The implementation itself is not too difficult, because the surrounding design makes it easier. Having these CoverCollisionBox actors means retrieving information on any particular piece of cover is easy, making the implementation more simple, while the possibilities for design are more dynamic. I'm not regretting these choices so far!
However, I did find some limitations to my original design that I'd like to briefly mention as well...
Cover Collision Box Changes
Originally, I was using a combination of overlaps and line traces to get information from the cover boxes, but I've switched to using almost exclusively line traces. As the player moves along cover, line traces are shot out in the direction opposite the wall's normal (i.e. towards the wall) to retrieve information from the box that the player can use when performing different actions. This is much more consistent than using overlaps by a long shot and had literally 0 impact on performance when I checked using a development build and 3 different clients.
In fact, the only thing I'm using overlaps for now is moving to an adjacent wall. I can't think of anything else I'll need overlaps for *shrug* Good riddance!
I've also added a couple new friends to the mix, which I call the "CoverAimBlocker" and "CoverTracer". The CoverAimBlocker blocks the player from moving past it while they are aiming. I plan on using this for walls where the angle is really harsh, because it feels better to just stop at a 90-degree angle rather than be forced out of your aiming and moved to the other wall.
The CoverAimBlockers are the red boxes shown in the screenshot below (kind of hard to see, but they're near the pillars):
The CoverTracers are used to fill in the gap that is created as a result of using overlaps to detect when the player should move to an adjacent wall. When the player traces one of these actors, it provides the same information that a normal CoverCollisionBox would, and moves the player to its ArrowComponent (which is situated directly on top of the ArrowComponent of the box next to it).
You can see a couple screenshots below showing the trace and the resulting position in cover:
Aiming In Cover Changes
Some of the answers to questions I posed in my last article with regards to aiming...
- Do we allow the player to hold the aim button while sliding into cover and automatically start aiming? Should they have to time the button press properly to aim only after the slide is complete? Should aiming cancel the cover slide?
I allow the player to hold the aim button while sliding and they will automatically start aiming afterwards. I want motion in and out of cover to be fluid, so this just makes sense. It makes even more sense when I consider new movement options like Vault Cancelling (talked about below), because the player should be able to cancel their animations and start aiming right away to take full advantage of those options. Slow cover movement is for squares!
- If a player is in high cover, should they be able to aim behind them while still in cover? Should we automatically take them out of cover when they try to aim in the opposite direction of the wall's normal?
As shown in the video above, when a player aims away from cover, they get pulled off automatically. In low cover, rotating away from the wall's normal will also pull the player off of cover. Naturally, I plan on associating getting off of cover with a small particle effect and a sound, so it won't be confusing, but more important is the philosophy behind the decision.
In the final game, players will want to move around and make flanks because staying in cover for any extended period of time will actually be dangerous (I will be talking about that a few more months down the line when I hopefully get to start implementing magic abilities). Therefore, I want getting off of cover to be really easy and fluid, and this is a step in that direction.
In most cover-based games, you get in cover and there's an immediate feeling of "hunkered-down"-ness. I'm trying to make the feeling of getting in cover in this game more airy and smooth, like you want to slide in to cover just so you can quickly vault over and move to a new area of the map. A lot of that will be animation and effects, of course, but there are lots of programming tweaks still needed to accomplish this. For example, vaulting while running, which has yet to be implemented.
So that's where I'm headed with it! And as part of getting a head start on that...
Roll/Vault Cancelling
As I mentioned in the section on my Vault Cover implementation, the callback for the MoveComponentTo function happens before the animation actually ends. This is so that I can incorporate some cancelling into the player's movement to allow them to move about more freely. Vaulting is typically a risk by design in most cover-based shooters, but I want to avoid that in this game; on the contrary, I'd like it to be a solid tactical move in almost any situation (when combined with other good movement, of course).
Two movement options I'm working on right now to encourage this, which you can see in the video, are "roll cancelling" and "vault cancelling". Roll cancelling means a player can choose to roll before the vault animation ends, in any direction that is away from the wall normal.
It's intended to be used to make moving between cover, crossing large distances, and getting out of harm's way easy:
The other option is vault cancelling, which is harder to pull off because you can't just spam the action button to do it. The player will need to press and release the action button just before hitting the ground on the other side of cover while simultaneously pushing their left stick towards the wall. This lets the player cancel the end of the vault animation and immediately take cover on the other side of the wall. It saves about 0.3 seconds over finishing the animation and then taking cover normally.
It's more of an advanced option intended for players to use defensively against long-range attacks:
Conclusion
The base logic for cover movement and actions away from the edge are pretty much implemented! Next up is going to be actions at the edge, including peeking around cover and moving around the edge of cover.
What more is there to say? No time to waste...!
-Flash <3
