Cash Force is a high-octane arcade VR shooting game where you take the role of an undercover cop gone rouge fleeing the scene of a heist in a colorful 70’s crime film esque setting. Defend your stash of cash from pursuing thugs using an assortment of highly intractable weapons. Lock, load, and shoot your way through waves of pursuing enemies as you engage in combat out of the back of a moving heavily armored van, using the doors and other supplies as cover. Carefully plan your escape route before fleeing the scene of the crime, but remember, the higher the risk, the higher reward! Earn cash from performing skillful shots on enemies, allowing you to purchase upgrades and gadgets to improve your weapons and van. But be careful: the more damage the van receives, the more cash you lose, and its game over if you run outta’ cash!
Weekly Update #2
Another week, another update!
Working on Cash Force this past week was equal parts exciting and busy. Everyone on the team put in a lot of effort this week as we start to inch ever closer to the mid mortem presentations. All of us got everything that we wanted to have done by the end of the week implemented in a functional state, with a few bugs here and there (as usual, such is game dev).
So without further ado, lets get into it!
Goals for this Sprint
As a team, we defined three major goals that we wanted to accomplish for this sprint. We’re all (painfully) aware of how little time we have left to get our vertical slice setup (about one month!!!), so all of these goals focused on getting closer and closer to reaching our plans for the vertical slice as possible in a week. As I talked about last week, we also wanted to define exactly what we want our players to experience in the vertical slice on a minute-by-minute basis, breaking it down into several categories involving game interactions, context, feel, and more.
Our main goals for this sprint were to:
- Create the node based movement system for moving the van, player, and AI enemies
- Functionally complete implementation of gun systems, including using the weapon bolts when reloading, recoil animations, and a “highlight” sequence when loading to teach players how to use the guns. Additionally test if players could shoot targets from the van as its moving
- Define exactly what we want to have in the vertical slice, breaking it down minute-by-minute
As usual, the work for the guns was in my domain. Josh was tasked with creating the node movement system for the vehicles, while Emmett was tasked with making a level using those nodes. Adam worked on the model for the van while Austin continued refining our documentation, leading our testing sessions, and helping me debug/tweak stuff by playing the game while I’m in editor.
This Week's Work at a Glance
I made it not only a team goal but a personal goal to functionally complete the features for our guns this week among other smaller things. We settled on just having the two rifle like guns fully operational for the vertical slice unless we find time to do the shotgun and revolver, but that’s unlikely at this point. I also wanted to some more audio into the game, mainly for picking up stuff and using the parts of the guns as well as some better shooting sounds. Here were my tasks for this week:
- Procedural Recoil Animations
- Gun Bolt Interactions
- Reloading sequence highlights
- Implementing audio
- Gun Bug Fixing
- Vertical slice breakdown w/ rest of the team
- Improve enemy hit feedback for testing purposes
The biggest of these tasks were the interactions with the gun bolts. I knew this would be a bit difficult to pull off but I’ve got a system going now that while a little buggy still (mainly because of the grabbing…but that’s another topic entirely) is functioning, feels good, and adds a lot to the experience. A lot of my time was spent fixing bugs with the grabbing and recoil animations, once of which I still can’t figure out but I have a lead to investigate now. Lets get into some more detail for each of these big tasks!
Procedural Recoil...and bugs...
My first focus for this week out of all my tasks was to get the guns feeling like….well, guns! While the shooting came out great last week, it was obviously missing the characteristic recoil that firearms have when they’re operated. Having done procedural recoil animations for recoil in my Unreal summer project, I already had the math figured out as well as a way to implement it.
The animations are broken into two parts: horizontal recoil and vertical recoil. Horizontal recoil is calculated by using the equation for recoil energy, which involves the grain of the bullets, mass of the weapon, and its muzzle velocity. These values are then normalized to the 10’s place and sent to the guns relative location using a timeline float curve for the lerp alpha. Pretty standard stuff, which was working pretty quickly and is highly tweakable.
The vertical recoil works very similarly, but…like literally anything to ever involve rotations, its way harder than it seems at first. All it needs to do is use the grain value to offset the rotation of the gun on the Y-axis using the same lerp values as the horizontal recoil. Easy enough to setup. Its actually applying those values that’s been causing me issues for an unknown reason…
I’m currently applying this offset to the relative rotation of the gun using “Add actor relative rotation”. This makes sense because its adding an offset based on the rotation of the gun’s parent, which will always be the hand when shooting. It worked totally fine! Yes! I did it!
… and then we packaged the project for testing.
Suddenly, for seemingly no reason whatsoever, the vertical recoil no longer functions. Horizontal works just fine and looks great, but the vertical recoil just doesn’t. But sometimes it does…meaning we have an inconsistent bug on our hands.
I showed this to both Josh and one of the capstone professors and they were also both confused. Why does it work fine in editor but not when packaged? The professor we showed this too speculated that it might be related to the way Unreal handles parenting to motion controllers, suggesting that I try making the gun shoot when not parented to the hand in a packaged build to confirm that its the issue. Hopefully Josh and I can figure it out together…but hey, at least we know the animations are actually working and feel good!
Gun Bolt Interactions!
I cannot stress how absolutely stoked I was to finally make this feature. Its something I’ve wanted in the game since we started making it, and now that myself, Josh, and Emmett figured out the best way to do it after much discussion, I was finally able to implement it.
When the player inserts a magazine into a weapon (or fires a round in the case of a shotgun), the gun is still not ready to fire. Much like in real life, the guns must have their action operated before a round is chambered and ready to fire. We designed this feature in an effort to leverage the power of VR; good VR is all about highly interactive and physical gameplay that fully immerses the player in the experience beyond visuals. What better way to do that with VR guns than to replicate the kinetic-ness of loading a magazine and racking the bolt before shooting the baddies?
Since this is a fast paced arcade shooter, however, we wanted to ensure that racking the action doesn’t feel overly complicated; we’re not making a simulator here. The biggest VR shooters on the market right now that has these types of action interactions (H3VR, Pavlov, Onward, etc) has the action follow the hand one-to-one as its grabbed and pulled back.
This is too complicated for the gameplay of Cash Force, so we devised another solution:
- When the player grabs the action, the hand mesh is attached to it.
- If they pull their hand back above a certain threshold, a procedural animation for racking the bolt plays.
- When its over, the hand is detached.
Its a perfectly simple solution and delivers the same exact effect as the simulation approach! Once I figured out all the other logic using a blueprint-esque flowchart, implementing it was pretty easy; I made a new actor component to handle all the logic for it just so the gun class wouldn’t get cluttered up with it. All we had to do was adjust the timeline lerp values until it felt nice and snappy! We’ll be continuing to refine the values after getting feedback from testing, as well as continuing to fix some jankiness with the grabbing logic (might as well be a perpetual task at this point).
Reloading Sequence "Highlights"
Rounding out my big tasks for this week was something simple yet absolutely essential: teaching the player how to reload the guns. We understood early on that having manual loading interactions (while streamlined to an arcadey degree) is going to make it difficult for some players to use the guns and engage with the core loop of shooting the baddies. Players who either aren’t used to VR or don’t know how guns operate need to be able to clearly see how these interactions work and when they need to be carried out. So, we designed a basic system to rectify this: whenever a gun is picked up and it isn’t loaded, it has a little flashing “ghost” highlight of the magazine in the spot where it should be attached. This indicates to the player that before they can shoot, they need to insert a magazine into this slot. Once that is done, yet another “ghost” highlight appears around the bolt area, grabbing the players attention to let them know they still need to operate the action before they can shoot.
We haven’t received testing feedback on this yet so it remains to be seen if this will help in the long run, but we received positive feedback on it in class. Hopefully it will help players unfamiliar with VR and/or guns with doing these cool interactions, and if it doesn’t, we’ll simply iterate and test until it does!
Upcoming Week Plan
Now that the guns have all their features implemented functionally, I’ll be diverting my attention to getting a lot of our audio assets made and implemented into the game this coming week. I’ll also be helping Josh with the AI, as they’re the last of our three core pillars that we need working for the vertical slice. I’ll be making a component damage so that enemies and the cars they’re in can take damage and send data to the score system Emmett is going to start working on this week. As always, I’ll also be working on the bugs with Josh to make sure we have as much polish as possible when midmortems come around!
See you next time,
-Karl
