Call of the V.O.I.D.

Student Project for CPI 211. Version 1.14 
From The True Conglomerate

Call of the VOID is a first-person action-adventure game developed for CPI 211. Set in an alternate reality where tensions of the Cold War boiled over into a worldwide conflict. This resulted in the crippling of society and fractured world governments into small localized organizations attempting to keep society functioning. The lingering radiation has caused a reliance on large V.O.I.D. mechs operated by humans to recover technology and resources as well as settle territorial disputes.

You have been recruited by one such surviving organization, to work in their mech program and eventually secure a better life for yourself in orbit. You will use a variety of weapons to go into desolated regions of the world and recover vital technology and hopefully not encounter too much resistance. Good luck soldier.

Controls And Clarifications Below

9 - Swap left hand Weapon

0  - Swap right hand Weapon

F1-F4 : Swap left arm ammo type

F5-F8 : Swap right arm ammo type

You do not need a VR headset to run this game. The version uploaded in the PC build with PC controls

It is not mentioned in the tutorial, but you can swap weapons on either arm with 9 and 0. The weapon pickup system works in the editor, but for whatever reason does not work during the build due to a severe memory leak. This is our solution so you can try the weapons we spent so long making.

Post-Mortem Write Up

Our development team learned a lot over the course of development that will be instrumental in future game design endeavors. Some major takeaways are as follows.

- Compartmentalization : Unity is object oriented, utilizing this property will prevent script conflicts and make the project easier to debug. For example, a grenade launcher could either spawn objects, track their positions, and detonate from a singular script, or the script could be saved to the instantiated grenade prefab, and just inherit values on instantiation. The second is a far more viable strategy.

- Division of Labor : Handing systems between developers leads to a ton of headache. The weapon system should've been designed by the AI developer and player developer in tandem, so they knew the inner workings of the system and didn't require as much back-and-forth for integration

-Frame-rate dependent code : Time.DeltaTime is fine, but if it can run in FixedUpdate that is usually the superior option. Its far easier to diagnose behavior when it is not being constantly compared to frame-draw timing

-Shaders graphs rule : First time diving into shader graphs, we made some fantastic visual effects using the Universal Render Pipeline and shader graphs

- Non-specialized scripts : Scripts should be as generalized as possible. For example, our weapon system had independent scripts to handle each weapon type, this means that if we wanted to change a singular property across the entire system we were going to need to change a massive collection of scripts. This makes iteration time skyrocket.

- Build early, build often : Some systems broke when the build changed load orders for scenes. Some objects were reliant on grabbing references on load, and the hierarchy loads differently during builds, meaning we had to revise a bunch of systems the day of submission to make sure they worked properly.

- Serialized Fields are garbage : Serialized fields are terrible, they are super prone to breaking when pulling assets from Git. Their reliance on metadata information means its super easy for developers to overwrite other people's fields, and prefab updates clear all fields. Direct object references, particularly through tags, are the superior way to handle this.

- gameObject.root : You can get the root gameobject (Top of the tree) using gameObject.root, which makes it easy to load scripts during runtime. Just make sure its indicated to the level designers so the scripts don't populate parent empties due to organization structure

- Navmesh generation layer : Forming a navmesh generation layer lets you calculate navmeshes off of basic geometric data, it makes the AI less finicky when determining routes, and allows you to add things like invisible walls to prevent enemies from wandering into areas they shouldn't. It also reduces calculation time

- Check all imported assets before integration : We had typos in our spoken script for the voice lines that made it all the way to the first build before one of us noticed the line was wrong. We had to rerecord it way too late, and it added a whole extra thing to do at the last second

- Idiot-check your programming partners : Many of the issues the coding team faced were extremely simple fixes, but they were looking for complex solutions. Asking the other programmers for their ideas on problem solutions often helped create innovative and efficient solutions simply because they were coming at the problem with fresh eyes.

- Inverse kinematics are hard : Inverse kinematic systems are very difficult to develop, and even harder to get looking correct, this is definitely something we should've dedicated a developer to do alone due to their complexity. It was stacked on AI development, and consumed a ton of time that could've gone into making the AI state system more engaging.

- Team incentives : Buy trinkets or snacks to distribute when designers meet individual goals helped raise team morale. Throw them a packet of gushers or a some skittles if they complete one of their goals. It raises the spirit of the developers in the room, and creates casual competition for the most candy.

Enjoy, please leave comments since we are all proud enough of this project to want to improve it.