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!
The Final Stretch
Here we are at the end…
The final week of the semester. Its been long, busy, and incredibly fun to say the least, but this past week was quite stressful to say the least. The last week of senior capstone is all about making the game as polished, playable, and presentatble as possible for the faculty to play and judge. The games that are the most viable and feasible for another full semester of development with a substantially larger team will be selected and move forward; those that are less so will be cut, with their team members being absorbed into the selected teams. We all really love this project and wanted it to go through, so we all put our best foot forward and fixed as many bugs and added as much polish as we possibly could in a week.
We also had to split our efforts between working on the game and creating not only a presentation slide deck to present at the Mid Mortem presentations but also create a trailer video to show off the game and its concept. This was a huge undertaking in and of itself and required all hands on deck from all of our team members. It was truly a busy and stressful week for everyone, but we all managed to still have a lot of fun with it!
Week 14's Work at a Glance
At the end of Week 13, we were essentially feature complete with what we wanted to have in Cash Force this semester. The safehouse was working, we had a full game loop with decently polished gunplay, functional enemy AI, score in the form of cash, and a basic economy system to tease our plans for next semester. This put us in a great place since we didn’t have to worry about implementing full gameplay features in at the last minute. However, there were a couple of tiny things that we considered a part of the “polishing” phase that we wanted to add as well as some bugs and framerate issues to solve.
Besides the polishing and bug fixing of the game, we all needed to focus on creating the presentation slide deck and the trailer. Since I’m more of an audio guy than visual, we decided to have Adam and Austin take the helm on the presentation since Adam could easily create presentation assets and arrange them while Austin worked his producer magic and organized everything. Meanwhile, Josh Emmett and I would focus more on the trailer side of things; Josh setup the game scenes to record footage, I played the game to record the footage, and Emmett edited the trailer together with Adam’s help. Mainly though, I focused on creating and editing audio for the trailer once the video part was edited.
All in all, here were my tasks for this week:
- Add small polish features like car swerving and an “objective board” to progress check players in the safe house
- Fix as many bugs as possible
- Handle the audio side of the trailer
This seems like far less of a workload than last week (and it was), but the bug fixing in particular took up a lot of time. I’ll dive into my individual tasks next, then we’ll take a look at the presentation and trailer as well as a post mortem for the semester overall!
Polish Features: Objective Board
One of the small polish features I was tasked with adding was rather simple; create a small “progress check” in the safehouse that prevents players from going into the main gameplay event until they prove they understand how the game mechanics work. I discussed this a bit in my previous post about Week 13, but to recap, the design of the “progress check” would simply involve checking if the player had shot a certain number of targets in the firing range before being allowed to enter the van. Creating this was as simple as creating a new variable in our game instance class and incrementing it when a target was shot, then having a check for it in the van’s door scripting.
The code was the easy part: the polish took a lot more time. To make sure players understood that they had to shoot a few targets before they could leave the safehouse, we designed an “Objectives” board in the safehouse that outlined what the player must do in the game, including the progress check. We wanted to ensure players also understood how to buy guns so they could do so in the van, so the first objective on the board is to Buy a Gun. Next is the progress check involving the targets; shooting a target ticks up the left number to indicate that progress has been made. Third is instruction to get in the van after the targets have been shot. This shows the player that before they can enter the van, they must complete the prior two objectives. Lastly is the objective for the main gameplay scenario; defend the cash and make it to the end without running out.
To further polish the objectives, myself and Austin recorded voice lines that play when moving to each carpet in the safehouse or when objective conditions are met. These voice lines serve to present information to the player related to their objectives on the board or about the different areas of the safehouse. For example, if the player moves to the van before completing the progress check, a voice line will play explaining that they need to shoot some targets before they can leave. When the targets are shot, a new voice line will play telling the player that they are now able to enter the van. These voice lines were really helpful to players in our playtesting sessions, and there will certainly be more of them in the future!
Polish Features: Car Swerving
The second little feature we wanted to add for polish was also relatively simple; when the enemies in a car are both killed OR the driver side enemy is killed, the car will swerve out of control and explode after a few seconds. This would allow the player to target specific enemies and cause more carnage when the car swerves out of control, since it would collide with other cars. Josh and I managed to get this working fairly quickly, and it added a nice touch to the gameplay!
Bug Fixing
Where there is development, there are bugs.
We knew that the game wouldn’t be 100% bug free before the deadline, but that doesn’t mean we didn’t try our damnedest to iron out as many of them as we could find. We did a LOT of play testing this week to make sure there were no game breaking bugs, and if any did happen to show up, we would work to fix them immediately. Sure enough, during testing we had a few critical bugs with the grabbing system (surprise: its still super buggy!) that we hadn’t seen before. Josh and I managed to get them as reduced as we possibly could for the time being, however we vowed that if we made it through, we would remake the system in a more efficient way next semester, as it would save us far more time than trying to fix what already exists.
We also were slapped upside the head with the still emerging problem of optimizing games for Virtual Reality. Before we added all of the enemies to the scene, we had no trouble reaching the target 90fps, even on my older GTX 970 system. However, all of a sudden framerates started dropping to sub 30 during gameplay on my machine, which is almost unplayable to say the least. It took me a long time to figure out the problem; I started by disabling the enemy AI code (no change), disabling the car code (no change), disabling all enemy related code altogether (still no change), and finally tried just deleting all the enemies from the scene (ding ding ding!).
What was causing the issue was the rendering; since our enemies don’t “spawn” in yet (they will if we continue development), the scene was rendering all 70 of them at once without any level of detail settings. I fixed the problem by transforming the enemies into a single triangle when they got out of VR viewing range with the handy LOD tool in Unreal. Crisis averted! By this point it was already Sunday, so we decided to code lock for this semester since the game was as stable as it was going to be for now. Play testing after code lock went smoothly, with no crazy bugs or serious framerate issues!
The Trailer
The most exciting (and time consuming) task for myself and the rest of the team in the final week was creating a trailer for the game to show off at the Mid Mortem event during our presentation. The school doesn’t give any specific guidelines as to what the trailer should be like other than that it should demonstrate what the game is conceptually and how its played. This gave us a ton of freedom to be as creative as we wanted. After much discussion, we came up with a storyboard for the trailer in the style that we settled on; since the game is inspired by 70’s cop shows and movies, we opted for a cinematic style trailer with snippets of gameplay mixed in!
Emmett drew up a cool little storyboard that visualized the shots and footage we needed while Josh setup the engine and a new scene for recording. Once all that was ready, I played the game to get the footage we needed for the gameplay segments while Josh and Emmett got footage for the cinematic segments. When we finished recording, Emmett and Adam edited it together following the storyboard and later sent it to me to do the audio. Before editing the audio, Austin and I recorded some more voice lines for the trailer. We then found some music online to use temporarily for the trailer (if we make it through I will be making some groovy 70’s tunes) and I edited it to sync up with the footage. After several hours of audio editing, we had a finished trailer, which you can view below!
The Presentation
While we were making the trailer, we were also focused on creating our presentation slide deck that would go along with it. I didn’t have much involvement in making the presentation as my focus was on the design and polish of the game and the trailer stuff, but I did help with arranging some of the information in an optimal way. Here’s a link to the full slide deck as well as some screenshots from certain slides below.
The purpose of the presentation (apart from showing off the hard work we did all semester!) is to not only show off what the game is and how its played, but also to show how we as a team iterated on the concept, mechanics, and gameplay to achieve the current result, as well as the decisions and goals that led us to make these iterations. Additionally, the presentation is used to present the viability and feasibility of the game for an additional semester of development; what additional roles do we need and for what reason? Is there potential beyond what currently is in the game for another 4 months of development time? We provided answers to these questions in the presentation with some fun graphics.
Mid Mortems
After days of careful revision and practice, the night of Mid Mortems finally came. It was a bit nerve racking at first, especially since the school uses a weird randomizer thing to select who goes next (as if we aren’t anxious enough already!). We were selected as the second to last out of 22 games, and the presentation went super well!!!
Well…mostly…
We started the presentation with the trailer, which the audience had a super positive reaction to. Everyone seemed to really enjoy it and we recieved quite a lot of cheers afterwards! During the slide portion of our presentation, the speakers (mainly Austin and Adam but also Emmett) were precise and made a lot of jokes that got great reactions from the audience. We all had a lot of fun with what we were doing, which was really the goal all along; if we’re not having fun talking about the game we just poured 900 hours collectively into, why even make games at all?
But, sometimes too much enthusiasm can be a bit risky. We ended up having a bit too much fun during the presentation and as a result we had some time added on that we were not prepared for (namely waiting for the audience to finish reacting to the jokes and slides and such). Right as we were about to present the roles we needed (two slides left), we exceeded the 10 minute time limit and had to leave the stage. This was rather disheartening in the moment, but it turned out not being too much of a big deal when all was said and done. We ended up just sending the slides to the rest of our peers so they could see what roles we needed.
The Results...
The following day was demo day, where all of the game studio faculty converged to play our games and later vote which ones went through. After several hours of this, we finally found out which games and teams went through…
…and we were one of them!!!!
The whole team was elated to find out that we made the cuts! After some celebration we started to reach out to people who’s games did get cut and who had the roles we needed. Eventually, we ended up with 8 new team members, each of whom I will introduce in the first post next semester!
First Semester Post Mortem
Something I like to do with my projects, whether their solo or in teams, is write up a post mortem after we’re finished to see what went well, what went wrong, and what could be improved in order to learn from my (or our) mistakes so we can do even better next time. Here it is for this semester:
What went well?
- We were able to remain adaptable throughout the course of the semester and address serious problems with not only the game but any communication errors as they came up.
- Team communication was constant, consistent, and efficient throughout the course of the project’s development. Each team member was aware of what each other’s tasks were, when they were working, and what they were working on to not only allow for coordination and assistance with tasks but to also prevent any issues with the repository and overwriting work.
- Initial design and iteration of features and mechanics went very smoothly. We were able to quickly conceptualize, implement, test, and iterate on gameplay features according to feedback from players to ensure the game was as best as it could be.
- We were able to meet all of our first semester goals for the project and deliver on what we had promised in the given timeframe. The game turned out the way we wanted it to in such a short amount of time.
- Even though we encountered some trouble with bugs, the quality of the game at the end of the semester was high. We were (and still are) very passionate about the project, and I think it really shows in the results thus far.
- Our players and the faculty enjoyed the gunplay and interactions with enemies as well as the safehouse map and voice lines. Gameplay was described as satisfying and punchy and the overall experience was described as successful in achieving the 70’s aesthetic and charm that we had shot for.
What went wrong?
- While our communication was effective, oftentimes we all had struggles with procrastinating our work until the second half of each sprint. This is mainly due to the fact that we all had other classes to work on apart from this project, which is understandable, but it oftentimes put a lot of unnecesary stress on each of us towards the end of the sprint as we had to get a week’s worth of tasks done over the course of 3 to 4 days.
- Due to the technical scope of this project and the team’s unfamiliarity with not only virtual reality but also Unreal Engine, we had to spend a lot of (needed) extra time learning how to use Unreal and specfically its VR features. This resulted in some poorly planned implementations of things that will have to be redone next semester (e.g the grabbing system, which could’ve used a custom component, but we didn’t know about them at the time we built the system). This also caused a bit of a slow start in terms of efficiency that eventually went away once we overcame the learning curve.
- For me personally, I failed to optimally plan enough time for things to go wrong. I estimated the time for my tasks based on how long I thought it would take to complete them assuming no bugs were detected, which was almost never the case; there was always a lot of time I had to spend working on fixing bugs and other such problems. This was mainly a problem at the beginning of the semester, as I started to plan extra time into my time estimates to make sure I wasn’t overscoping for each sprint and had adequate buffer time to fix issues as they came up.
- Perhaps the biggest issue this semester, as both a team and for me personally, was a lack of effective prioritization of certain key tasks. Towards the beginning of the semester, I focused alot more on the gunplay and the details/feel of it than core game features like the safehouse and the AI combat. While we did manage to get all of these features in in the end, if we had prioritized them earlier in the semester the last few weeks would have been a lot less stressful than they ended up being. Creating the functionality of the gunplay first, then moving onto the safehouse and AI and combat immediately afterwards would have been a likely better route to follow, since these are the features that define the true core of the experience.
What can improve?
- Increased foresight and planning ahead for the priorities of tasks. Instead of assigning tasks based on interest/finishing one thing before doing the next, we could refer to our documentation and create a priority rating for each feature/task and assign them accordingly.
- Consistent work schedule spread throughout the course of the week, especially in my case. Instead of doing other course work first and then moving onto this project’s tasks, we could instead do smaller increments of work spread more evenly throughout each day of the sprint.
- Research engine features more in depth before jumping in and creating a game feature. This could increase efficiency for certain tasks that would prevent them from having to be remade, like in the case of the incredibly buggy grabbing system.
- Always have a contigency plan and extra time for if a specific task just isn’t going according to plan or working out like it should be. Bugs and outside conflicts are always going to happen, so its vital that we plan extra time for each task just in case!
That's All For Now!
This concludes my College Capstone Dev Diary for the Fall of 2019! The next post will be at the start of the spring semester, where I’ll introduce the new team members and their roles as well as whatever we’ve worked on up to that point.
See you next time,
– Karl
