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!
Two Updates in One
We’re in the endgame now…
At the time of this writing, there are exactly 10 days remaining until the midmortem presentation. Myself and the rest of the team have been hard at work the past two weeks getting the rest of our features finalized in game and polishing existing features with art, audio, and more! Due to the busy nature of the past two weeks, I missed the weekly update for week 12, so this update will be longer and cover both of those weeks! An absolute ton of work has been done in such a short amount of time and it really shows, as the game has finally come together (for the most part)!
Lets get right into it, starting with week 12!
Week 12's Work at a Glance
At the start of Week 12, we were in a good spot as far as the main interactions the player has with the world goes. Grabbing, loading, and shooting guns was completely finished and feeling good as reported from game testing feedback. The van was driving around the map with a car chasing it. There were enemies in the car that the player could shoot, which would add to their “score”.
We were missing two very major things, however; enemy AI that shoots at the player and can damage them and multiple cars following the player around the level. Additionally, a majority of the audio was not implemented in game, and the sounds that were in were not properly spatialized for VR. Given that our core systems were complete at this time, we decided as a team to focus on getting the audio in the game, getting the enemies shooting at the player, and fixing the problems with the cars not going around corners in order to get multiple cars following the player. Additionally, we wanted to get a start on getting Adam’s art into the game, since we now had a lot of the final assets needed to bring the game’s aesthetic to life. I was tasked with the following this week:
- Implementation of simple enemy shooting behavior tree and player damage
- Creation of all game audio assets, from gameplay sounds to voice overs
- Implementation of audio assets with spatialization
- Start on implementing art assets into the game
This was quite an undertaking for me, as creating audio ususally takes a reaaaally long time, especially for a game with as many assets as this. Additionally, I had never had previous experience programming AI before, so creating the shooting AI while simple proved to be challenging at first. However, once I got going on these tasks, they all fell into place rather quickly!
As for the rest of the team, Adam continued creating assets for us to implement as well as all of the textures and materials for all the in game assets. Emmett continued working on the level layout and road tiling, having devised and implemented a finalized layout of the map. Josh helmed his car chasing AI in order to figure out a solution to the corner collision problem while simultaneously helping me out with the shooting AI. As always, Austin continued to make sure we were getting our stuff done on time and keeping us all organized on task, while also helping me out by testing in VR as I implemented the AI, art, and sounds.
Enemy Shooting AI
There’s surprisingly not too much to say about this task. All it entailed was creating a basic line trace shooting system and behavior tree when the player entered the enemy’s line of sight. I was able to make the behavior tree pretty quickly, giving the AI a short delay before and after shooting with some random deviation to make it feel more natural between shots. I also added a random offset to the end of the line trace so enemies aren’t laser accurate. The player can take cover behind the van doors in order to avoid being hit. If the player is hit, they will take “damage” in the form of a loss of cash taken from the heist. If the player runs out of cash, the mission is failed. While the cash and fail state weren’t implemented yet this week, the collision detection was, meaning once that system was in it could be easily hooked up.
I’m by no means an AI programmer, but the system is functional for now and was working as intended when we took it to the testing lab. When I implemented the audio effects, I added cues when the player got shot to indicate that they were taking damage.
First Art Pass
Nothing makes development feel more awesome than when you finally take the shitty looking gray box models and dull generic textures and replace them with your artist’s beautiful meshes and textures!
I was absolutely stoked to start doing an art pass on the game with Adam, as his assets had been coming along so nicely for such a long time. After he imported and created all the models and materials for us, I went into engine and started swapping all the placeholder with the final….
…and man what a difference it made! Just compare these next couple images with the gif above and the pictures in previous posts and you’ll see just how much nicer the game looks now. For this week we only really got a chance to get the van furnishing, skybox, gun textures, and the enemy cars implemented, but it was a much needed first art pass that really spiced everything up!
Audio Creation and Implementation
Last but not least was by far my largest task for the week: creating and implementing the audio assets for the game. While it may have been daunting at first, thankfully I created an audio asset list early on in the semester that allowed me to easily see what I needed to get done as well as the priority and status of each asset. Austin also created a script for all of the various voice over lines we wanted in the game, from one liners and death noises to progress indicators (“we’re taking a left!” “we’re halfway done!”) and other cues. We managed to record all of these voice lines in about 30 minutes, leaving the rest of the audio time to creating and implementing the gameplay sounds.
I made pretty much every sound we needed for the game in about 5 or 6 hours or so. Around 80 sound assets were recorded, edited, mixed, and fed through a 70’s filter before being exported and imported into the game. These assets range from gunshot sounds (made with a mix of 70’s and modern recordings), weapon interactions (made with some staplers), grabbing sounds, vehicle sounds, ambiences, UI indicators (hitmarkers, kill confirmed sounds), and more. It was a lot of fun to make all of these!
Implementing the sounds went swimmingly as well. I had originally planned on using Wwise for this project but instead decided to use Steam Audio with Unreal’s built in audio suite since it seemed robust enough. The majority of the sounds have now been implemented and properly spatialized if they need to be, with the only outstanding assets being some tire screeches, the ambiences, and other sounds I haven’t made yet like doors opening and such. All in all, I got all of the important audio in game during week 12 which added a ton to the experience.
Week 13's Work at a Glance
I won’t lie: although we made big strides during week 12 with the audio, AI, level, and art, we were all a bit worried about the game coming into week 13. A lot of the core features were still missing, like several cars chasing the player (Josh figured out the cause right at the end of week 12) and the safehouse area with buying and upgrades using cash earned from the main game scene. We all knew that week 13 was essentially the final week to add any new features to the game, as the last week before mid mortems would be focused on polish, the presentation, and the trailer for the game. Thankfully, the last of our core features was implemented in week 12 (the AI shooting), meaning we could entirely focus our efforts on creating and refining the game loop, adding the cash system and buying, adding user interface elements and feedback, as well as the safehouse level to make the game into an experience with a clear start, middle, and end point.
- Fully script all events in the safehouse map, from the tutorial and start menu, practice range targets, vault room with the player’s money, and the transition to the van and back again as well as polish to these events (doors opening, sound cues, voice overs, etc)
- Rework teleporting in the safehouse to a “gaze” system (player looks at point and teleports there)
- Create the cash system that shows the player how much money they have in both the safehouse and the van
- Create a rough version of the buying systems based on the cash system
- Add car damage and explosions
The Safehouse
Hoo boy, where to even begin with this part of the week…
The hub level, or the “safehouse” as we decided to theme it in context, was the biggest missing element that would take the game from being more on the tech demo side (e.g, having players start in the back of the van, immediately shooting enemies with no context, training, or explanation) to being an actual experience. Our capstone professor brought this up to us pretty much everytime we presented in class up until this week, and every time we all agreed something had to be done.
In the previous post, I mentioned that we wanted the safehouse to allow players to have time to familiarize themselves with the controls, check their understanding of the core systems before going into the main scenario, and to tease the systems we want to implement next semester (e.g upgrades) while simultaneously serving as the tutorial and “main menu” for players. Since this is a VR game, one of our biggest design goals is to keep as much of the UI/UX as diegetic and rooted in the world as possible. The intended design of the safehouse would do just that.
Before I went in and scripted the tutorial, firing range, teleport, and other scripted scenario features of the safehouse, Emmett refined the old test scene “firing range” layout into the layout below. While Josh and I were bug fixing the car chase AI, Adam managed to set dress the entire safehouse level and make it into the beautiful area you can see below!
Safehouse: Tutorial Room
At the start of the game, players are spawned in a room with a locked door and a desk with a gun on top of it. This room serves as the “tutorial” room as well as the “main menu” for the game. In order to leave the room and start the game, players must learn how to load, charge, and fire a gun before they can move around the safehouse and engage in the main scenario.
I created several UI prompts to guide the player through the gun operation process. The controller prompts explain the two buttons players use; the grip button for grabbing objects and gun parts and the trigger for shooting. Once the gun is loaded, two “targets” appear on the blackboard in front of the player. These serve as the “Start” and “Exit” buttons. Shooting the “Start” target opens the door and allows movement to take place, while the “Exit” target…well…quits the game.
Once the door has been opened by shooting the “Start” target, players are able to teleport throughout the safehouse by looking at the pulsing carpets on the floor. When the reticle is over a carpet, a small meter will fill up; once full, the player will teleport to the desired location. I made this system based off of the default Unreal VR teleport code and then moved teleport points around the map accordingly.
We decided to go with this method of teleportation since the safehouse features several distinct “stations”, meaning a more regulated form of teleportation would be best at guiding players to the correct spaces. We opted to avoid a joystick locomotion or button press teleport to reduce motion sickness and button complexity respectively, at least for the time being.
Safehouse: Firing Range
This was my personal favorite area of the safehouse to work on and also the most fun; the firing range! Here the player can practice what they learned in the tutorial in order to get more comfortable with the way shooting feels, two handed aiming, the accuracy of the two guns, and most importantly, reloading empty magazines with new ones.
I scripted two types of targets that have essentially identical behavior when shot. The larger red targets fall over and turn green when shot. After a few seconds, they pop back up and turn red again. The smaller targets spin around to the opposite side when shot; shooting them back and forth is really satisfying! I also made a little metallic “ping” sound effect that plays when targets are shot.
While we didn’t get to it this week, it is intended that the player must shoot some of these targets before they can get in the van and go to the main mission. This is a sort of “progress check” that ensures players are familiar with the game mechanics before getting into a dangerous scenario.
Safehouse: Vault
Next up is the vault, which in itself doesn’t have any scripted function yet apart from the vault door opening when entering the room. The vault contains a visual indicator of how much cash the player has available to spend on items (currently only guns and magazines) as well as the future Upgrades board that for now is only a tease. There’s also some money bags and stacks of cash strewn about in there as a diegetic representation…but more on that in a bit.
Safehouse: Van
The van serves as the transition from the safehouse to the main getaway scenario, in which players must use what they learned in the safehouse (shooting, loading, reloading, gun handling) in order to succeed in their goals (escape without losing all the cash). When the player moves to the van, a UI prompt on the van door handle displays to inform them that it is grabbable. When grabbed, the doors open and transport the player inside the van, shutting behind them shortly afterwards. After fading to black and some transitional audio while the map loads, the main part of the gameplay loop begins.
This was one of the more complicated scripted scenarios to create for the safehouse level, as there’s a lot of moving parts and variables to keep track of and precise timing to get right. Thankfully, the level blueprint and timeline features exist in Unreal, both of which significantly sped up this process.
Cash System
The cash system is one of the more important systems in the game that we had yet to develop to this point. It is designed as a “risk/reward” type of system in that it is used to purchase weapons and ammunition (as well as upgrades in future iterations) but is also the player’s “health” in the main scenario. Josh and I tag teamed this system at the beginning of the week, first by creating the “cash spawn” effect seen to the right. This is used as a piece of reward feedback when completing a level successfully and spawns different meshes based on denominations (e.g 10’s spawn money stacks, 100’s spawn money bags). We also created the “rolling” effect on the text to make it apepar as though the cash is accumulating for an even more satisfying effect.
The cash system tracks two different cash values: vault cash (or total cash) and last heist cash. The vault cash is how much cash is currently spendable in the hideout and is the total of itself plus the cash earned from the previous heist. The heist cash is what players are defending in the main scenario and is the “take” from the off screen heist. Once returned from a mission, the heist cash is added to the vault cash.
These two values aren’t separate only so they can give player feedback. The heist cash acts as player health in the main scenario and is the “goal” of the game. When players are shot by enemies, they lose a chunk of the heist cash; if the value falls below a certain number, the mission is failed. To counteract this, defeating enemies and performing trickshots (e.g headshots) awards some cash back. This is to balance the economy and reward players for their skill with more “health” and potentially an even greater take than they started with, which leads into the buying system…
Buying System
The last major system for the vertical slice is the one that ties the cash and weapon systems together; the buying system. Using cash in the vault and earned from the heist/defeating enemies, players can purchase guns and ammunition (and upgrades of varying kinds in future iterations) to assist in defending the stash of cash. This is where the risk vs reward comes into play; as a player, do I risk buying a second gun and more ammo to increase firepower at the cost of less health, or do I conserve cash and play more cautiously to maximize my rewards?
We wanted this system to be as natural as possible, as buying systems in other games tend to be really menu driven. To buy items, all players have to do is simply press the grab button when their hand is inside the buyable item outline. That’s it! I created a simple buyable item component to achieve this result, which can be used for any buyable item we create in the future. When an item is purchased, a copy is instantiated and placed in the player’s hand. The cost of the item (determined by a modifiable component value) is then subtracted from the vault cash value, provided there is enough cash at minimum in the vault to complete the purchase.
Car Damage
The last and least important (but definitely most cool) task for me this week was to implement the damage component I previously made onto cars. Since the component is modular, this didn’t take very long to do; just tweaked the values and added custom script for the component’s OnDeath event…which plays an explosion sound, spawns an explosion particle, kills any enemies in the car, and launches the car into the air! The explosion particle is just the temporary Unreal one for now, but in the future we’d create a custom (and groovy) one to match the rest of the game’s art style.
(Mostly) Final Art Pass!
While I was working on all of this, Adam and Emmett were hard at work on the level, with Emmett finalizing the car and van movement paths and level triggers for audio cues and Adam doing another lovely art pass! Here’s some pictures of the mostly final art pass, only missing a few minor prop details here and there!
Upcoming Week Plan
Phew…that was a lot…
Since we all managed to meet our task goals for this week and complete the game loop, we’re in a good position coming into the final week of the semester. What’s left now for everyone to do is polish all of the systems as much as possible, fix any seriously game breaking bugs, and implement any last minute quick game improvements like sounds or visual effects. Additionally, we’ll be spending a lot of time making the presentation slide deck next week as well as getting footage for and editing a little trailer to show off at the mid mortem presentations! Busy times indeed!
See you next time,
-Karl
