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!
Preparing For Greenlight
Its been about three weeks since the current semester started, which means things are starting to ramp up quickly! In my last post, I talked about the new members of the Holo Hexagon team as well as some initial documentation we worked on to start getting prepared for the Greenlight milestone. Since then, the new team members have been fully onboarded and become accustomed to our workflow, structure, and atmosphere; and consequently, they’ve been doing a hell of a lot of good work these past few weeks!
Its great that everyone is up to speed and hitting the ground running with tasks, since two weeks from now brings our first major milestone; Greenlight. Greenlight is essentially a set of requirements that each sub-team and our professor defines for us, and we have until week 6 to meet these criteria before entering full production. These requirements are mainly focused on cleaning up remaining problems with the game from last semester, not only related to bugs with the code but also with a lack of clarity about the final, definitive vision for what the project will be at the end of the semester; no more, no less. In this post, I’ll be going over the major problems we identified with the design of the game and how the design team devised and documented solutions in order to meet criteria for Greenlight. Lets get into it!
Design Problems
Over the course of several meetings during the past two sprints since my last post, myself and the rest of the designers as well as the programmers have been meeting twice a week to discuss what features we wanted to have in the game as well as the outstanding problems from last semester. These discussions focused mostly on the core systems of the game, such as the weapons, enemies, user interface, and the overall structure of the game. As you’ll see, these problems mainly revolve around the Designer defined criteria for the Greenlight milestone I outlined in my last post as well as the criteria our professor gave to us. The three biggest problems we identified were:
- The game structure ranging from everything related to the full loop, player goals, progression, remained unclear. We had a lot of design related ideas pertaining to the game and its structure floating around from last semester as well as new ideas that popped up during meetings. We needed to definitely nail down and finalize what features were in the game, what the goals of players are mechanically and contextually, and the expanse of all content that should be in the game by the end of the semester. Our professors defined this as the “conceptual arc” definition, which is what I’ll refer to this as throughout the rest of the post .
- Our currently implemented grabbing/interaction system is incredibly buggy and leads to problems with combat and weapon systems like shooting and loading. This problem is rather self explanatory; last semester we implemented a quick and dirty interaction system that wasn’t architected properly. This led to a lot of problems with items getting stuck to player’s hands, objects not being held properly in the hands, guns continuing to shoot after being dropped, and more. The system needs to be created from the ground up, and our first step to solving this problem involved extensive documentation along with the programming team.
- Several UI/UX problems existed in the current build that prevented players from focusing on the gameplay/action. User interface and usuability for VR is still a mostly unknown quantity in terms of design; no one has really figured out perfect standards for it so far since VR is so new. We had similar challenges last semester when designing the basic buying system; in the current iteration, players have to reach to a table to get more ammo, which completely distracts from the main experience of shooting enemies. Another key user experience issue involved gun sights not properly being aligned in the 3D models; when players aimed with the sights, they wouldn’t be able to hit what they were aiming since the sight picture was not correct. These issues prevent the game from being as user friendly as it could be, and we put alot of focus into devising user friendly interfaces that remain diegetic elements in the game world; no one likes clicking through menus in VR!
These issues all stem from our focus on getting the core mechanics of shooting and loading working last semester as quickly as we could, as well as our initial unfamiliarity with Unreal’s VR features. Now that the original team members are very familiar with Unreal and the new team members are all experienced with it as well, we’ve been able to come up with several feasible and viable solutions to each of these key problems. All of these solutions tie in directly with our Greenlight criteria and have been proceeding smoothly so far!
For the rest of the post, I’ll be going into detail about each problem as well as its corresponding solution, starting with the first issue; defining the conceptual arc of the game!
*Since these past two weeks have been mostly documentation focused, I unfortunately don’t have as many pictures or gifs to show off as I’d like to, so I apologize in advance for the amount of text in this post!*
Problem: Defining the Conceptual Arc
Coming from last semester, we had a very basic idea of what we wanted the main objectives in Cash Force to actually look like. The player would be defending cash they earned during an off-screen heist from pursuing enemies. Before these scenarios started, players would be inside of the Safehouse hub map and be able to pick a route through the city which would determine level difficulty. That was really all we had, and it wasn’t exactly clear to anyone (professors, devs, and players) what the goal of play was while in the van. Obviously this was a major problem, since it essentially reduced the game to nothing but a tech demo full of solid yet contextually lacking mechanics. Major feedback we got involved a lack of a sense of urgency; players didn’t know why they were shooting at enemies, so why feel the need to do so? Players also didn’t feel threatened by enemies since there was really no way to “fail” the game other than “run out of cash”, which literally never happened during testing.
All of these issues are related to what we’re now calling the game’s “conceptual arc”. Before meeting with the design team to discuss how to best define the conceptual arc, I developed some guiding questions based on the professors’ definition of conceptual arc: “What is the overall structure of the game loop?” “How do players progress through the game’s various spaces and feel a sense of progression through the mechanics?” “What are the player’s goals and why should they care about them?” Having these questions at hand helped us to go through all of the outstanding design questions we had about the game that weren’t entirely locked down and finalize them, which led to the following solutions:
Solutions: Defining the Conceptual Arc
Our overall game structure is now focused on the four following phases: Calibration, Tutorial, Safehouse, and Van. Calibration and Tutorial are first time play features that set up the player’s height and arm span in game and teach the various mechanics of play respectively. The Safehouse is the level where players can get accustomed to the game mechanics with a firing range, purchase new weapons and upgrades with their cash earned from missions, and plan their route and loadout for missions before embarking on them. The Van is, well, the same as it was last semester; all main gameplay scenarios involving combat and shooting take place in the van along with player’s primary objectives.
Speaking of objectives and player goals, we finally nailed those down as well. Instead of the only goal being “don’t lose a certain amount of cash” in the van, there are now Main Mission Objectives for each van mission. There are three different types of main objectives to choose from each with their own context (which I won’t go too into detail here about); one is focused on killing a specific enemy target; the second is focused on defending the van from taking a certain amount of damage; the third is focused on earning a certain amount of cash before escaping. These objectives were conceived in order to give players an immediate, readable, and easily understandable goal for the main gameplay scenario. Each time a mission is planned, one of these three objectives will be selected and guide the rest of the mission’s generation. Supporting these main objectives are optional objectives for each mission. These are smaller challenges related to performing certain interesting gameplay criteria (e.g get 20 headshots to earn $2000) that add another readable goal for players to feel challenged by. Completing these goals, both main and optional, are designed to engage players since they provide a clear goal to work towards as well as clear rewards upon completion; the harder a mission’s difficulty level, the greater the payout. Additionally, an overarching goal now exists in the form of player health. This operates the same as pretty much any other shooter health system; player gets shot, they lose health; if health is below zero, the player is dead and the mission is failed; health is replenished with purchasable health items.
As far as player progression goes, from both a level and reward standpoint, we nailed down several indicators that instill a sense of progression as players play through the game. The main indicators of progress involve the mission system outlined in the last paragraph; missions are displayed on a Clipboard object in game that keeps track of objectives and their progress. When complete, objectives are checked off on the Clipboard to indicate their completion. The Clipboard is usable in both the van and safehouse so players can easily and readily see their progress. In addition, the van features a rudimentary map on one of the walls that shows the player’s current location along the level route. This was to aid in providing a sense of progression in terms of individual missions, as some missions end in success once the end of the level is reached. Apart from level/goal/reward progression, we identified another form of progression that’s inherent in our mechanics; mastery of the gameplay. As players play more and more, they will naturally become more skilled at aiming and controlling the weapons, allowing them to become faster and more reflexive in combat scenarios. This form of progression is rather important and will help make the actual cash reward systems more compelling; if players are incentivized to play just for mastering the core mechanics, the explicit reward systems will provide even more incentive to interact with the core mechanics and the game as a whole.
All of these solutions (as well as a few other less pressing ones) allowed us to finalize the design of the game; we now know exactly what we want in the game by the end of the semester and what everything should look and function like; no more, no less!
Problem: Interaction System Breaking Combat
As I mentioned earlier (and in pretty much all of my previous blog posts about Cash Force from last semester), our grabbing system is absolutely broken right now. Full stop. It is not implemented with proper architecture; when I originally made it, I hadn’t learned about custom Unreal components yet, meaning anytime any sort of grabbing interaction needed to be performed, the code is copy/pasted. Yikes! Believe me, I still have nightmares about it sometimes.
This problem has created lots of other problems with the shooting and loading mechanics; sometimes the hands get stuck to the guns, sometimes its the other way around. The recoil breaks sometimes because the hands aren’t attaching properly. Undesired objects are grabbing first because nothing is keeping track of the nearest object to the hands. Its truly quite a spectacular mess, and has led to problems with our combat loop being intuitive; its very difficult to shoot at bad guys when your hands are getting stuck to guns you’re trying to reload or the gun fly’s out of your hands and out the back of the van.
Myself, Josh, and Kelly worked extensively the past two sprints on properly designing the architecture for this system in order to fix all of these issues. The solution we’ve decided on is rather simple; its all about player intent:
Solutions: Interaction System Breaking Combat
The goal of the solution to these problems is to create an “intent system” that informs players about what they’re about to grab based on the object/point closest to the hands corresponding to a line-trace outward from the hand meshes. This will prevent players from grabbing objects they didn’t intend to, as a small UI pop up (among other feedback like haptics) informs players what the currently intended object is before input is received. Using this system for any grabbable object, whether its a gun itself or grab points on it (foregrip, bolt, etc), will completely alleviate all of these bugs while simultaneously improving the user experience. A very elegant and simple solution indeed. Now that we’ve design this system, the next step will be to build a prototype of it before Greenlight!
Problem: Unintuitive UI/UX During Gameplay
We didn’t have a dedicated UI/UX designer last semester, and neither Emmett nor myself are specialized in that area of game design. While we were both able to make some basic UI/UX features for things like the buying and gun loading systems last semester, what we implemented ended up not being the most intuitive of designs. A major problem with the item buying and weapon loading experience was that players had to stop looking at the enemies, turn towards the table in the van, and bend down to buy ammo off of the table. This completely broke the flow of combat, since players took a lot of damage during this process and were distracted from the main goal at hand. Speaking of taking damage, players never really knew when that was happening; we didn’t manage to implement a clear indication to players that they were taking damage, which led to a lack of a sense of urgency among other issues. It was also hard to tell when player’s were earning or losing cash, as the only indicator was a terrible floating text pop up attached to the VR camera view (yuck). Another smaller UX issue was related to the art side of things; aiming down sights with the guns wasn’t accurate at all since the sights on the models were not properly sighted in. While these features worked for proving a vertical slice, they were not anywhere close to being as intuitive as we’d like them to be. Now that we have two designers experienced with and focused on UI/UX design on the team (Lauren and Harry!) as well as an additional designer to help me with the weapon and combat designs (Joe!), we were able to devise awesome solutions to all of these problems!
Solutions: Unintuitive UI/UX During Gameplay
The solution to the item buying and weapon loading issues involves something I’m really excited about; a tactical vest and slings for ammo and weapons respectively. These features allow players to store their weapons on their character for quick access as well as grab/buy more ammunition directly from a vest on their chest, all without having to move to a different location! Here’s Harry’s sketch of what this system looks like, as it goes into more detail about how it works.
For displaying health and cash, we came up with the idea of having a watch on the player’s hand mesh which displays the remaining amount of health players have left as well as the current cash value they have in the van. This allows players to quickly check the two main values in the game by simply looking at their wrist; no more guessing if they took damage or not! Lauren took the reigns on designing this feature: here’s her final sketch of what it will look like in game!
Finally, for the problem with weapon sighting, I talked with Adam (as he’s in charge of making the gun models) about how the sights were currently misaligned and suggested an idea to both Adam and Joe; I would make 2D diagrams of the ideal sight picture for each gun in the game based on the artistic direction Joe and I decided on for each of the new guns as well as the two currently in game. This would allow Adam to know exactly what the sights should look like when aligned properly using an orthographic perspective in the modeling program, which would translate directly to correct sight picture in game! Here’s the diagrams that I made for each weapon (which by the way, we’ve mostly nailed down the direction for as well; I’ll be going into detail about them more in my next post). The green posts indicate where rounds will hit when properly aligned.
Upcoming Sprint Plan
What’s next is now clear to all of us; we now have the supporting documentation for everything we want in the game mostly finalized, so now its time to prototype each new mechanic or system that is currently unproven before moving into full production post-Greenlight. Some of the things needed to be prototyped like AI are already underway, but before we really totally finalize the design, we need to prove that each of these features works with the game; there’s no sense in trying to polish features or mechanics that were simply never meant to work in the first place!
For the next two weeks until Greenlight, the design and programming teams will be all hand’s on deck for prototyping, testing, and finalizing all of our planned features. Its going to be a busy but fun two weeks. I absolutely cannot wait to start making things in build again!
See you next time,
-Karl
