Weekly State of the Repo

Work on Capstone has continued at a steady pace. This week was mostly spent putting “polishy” touches on our prototypes to make sure that we could take them to QA and get feedback on the items we actually wanted more information on, which sometimes requires a more complete experience than you really want to build this early on.

All tasks last sprint were completed successfully, rounding out to a whopping 28 hours logged including team meetings. At this point, most of our major mechanics are implemented in the prototype in some form or another, although most have a lot of room for iteration. This week was spent on the items that follow, as well as writing our technical risk document. A summary of all our mechanics listed in the doc can be found at the bottom.

Two of the most important things done this week, as you’ll notice in the video below, were the addition of real placeholder art assets (rather than just Unity primitives) and very placeholder audio, meant simply to demonstrate the viability of our audio framework rather than be meant to represent actual effects that will be in the game. Real audio from the design team will be coming soon.

New Weapon Parts

We chose to add two new parts this week which we thought would be key to getting the core experience across: a shotgun barrel that automatically creates multiple projectiles in a wide spread, and an RPG mechanism that fires rockets.

In a testament to how flexible the weapon system for our unnamed project is, the RPG mechanism took about 15 minutes and did not require any code changes, just changes in the inspector to the existing grenade mechanism (and a new placeholder particle system). The shotgun barrel required a minor code change in how the guns work, allowing the barrel to define a “number of projectiles” to create every time the weapon is shot. This, however, was the only change, and took a very short amount of time; the stereotypical shotgun-style scattering was done through the existing spread mechanic with no code changes necessary, just numbers adjusted in the inspector.

This is one of the few cases where I will brag about not doing much work. The weapon system is flexible enough to make iteration very rapid going forward, which is something everyone on the team is very happy about.

Prototype End States

End states were a “quality of life” issue that made getting results at QA significantly easier. Without end states that allowed restarting and quitting back to the main menu, testers would get frustrated when asked to test a level more than once. End states were also imperative for the multiplayer prototype (not shown above) to ensure players understood when the round was over and who had won.

Going forward, we will alter what qualifies the player for a win and how this will be communicated. The window popping up immediately when you are killed or when you kill all the enemies is too jarring at the moment, and doesn’t give the player much feedback. Improving the end states is definitely a Deep Dive task, however.

Pause/Options Menu

This is another “quality of life” issue that was required by QA. It is impossible to find a mouse (or controller) sensitivity that will satisfy all players. For one of our builds, half of the comments were “the look is too sensitive” and the other half were “the look is not sensitive enough.” Oftentimes, a response like this was repeated throughout the QA form even on unrelated questions, giving us significantly less useful data for the test. The solution to this was to add a sensitivity slider, even though this would generally be considered polish.

Field of view was a similar issue. Many players become motion sick or otherwise uncomfortable when playing a first person game that does not match their usual field of view settings. The solution for this was obvious: add a realtime field of view slider to the options menu as well.

Movement System

This week also saw the overhaul of our movement system. Originally, we were using a player with a Rigidbody and physics-based movement. This has been refactored and rewritten to use Unity’s CharacterController instead. Though there are physics-quirks when using CharacterControllers instead of Rigidbodies, the added control over how the player moves is indispensable for a first-person experience like this.The new system functions similarly to Unity’s Standard Assets First-Person Controller, but there are some significant differences and it was written from the ground up to make it compatible with our Action-based Input system rather than Unity’s default polling system.

Technical Feasibility

Overall, writing the Tech doc for the potential challenge on Thursday was simple with the help of the rest of the team. Most of the risk boils down to our mechanics being easy to prototype, but difficult to make “feel” good and the way players expect. Below is the current draft chart from our document.