Responsibilities

  • Created gameplay prototypes, mechanics, and systems in accordance with design documents

  • Tested, debugged, and documented gameplay bugs

  • Documented game development processes

Details

  • Team Size: 8

  • Role: Gameplay Programmer

  • Engine: Unity

Player System

When I joined the project the player was a collection of Game Objects childed together with important components on each. When attempting to create a new gameplay feature it was difficult for developers to reference the needed component without having to travel through all of the Game Objects to find the correct component. In order to avoid this confusing and potentially exponentially growing problem I created an encompassing Player class that was a one-stop-shop for these important references. If something needed to access the forklifts forks, for example, they now only needed to go to this Player class instead of climbing down the Game Object tree to find it. This encapsulation significantly aided our development by removing unneeded confusion and creating a higher level Player class for use in other places.

New Gameplay

One of the new gameplay features I was tasked to make was an Air Strike item. This item when picked up would freeze the player in place and reroute their inputs to the Air Strike system. The issue? The player was closely coupled to the input system. Implementing this feature required decoupling the input into a more modular system. Instead of directly connecting the player and the input system I created a middleman manager. This allowed me to disconnect the player from the input system and reconnect it to my Air Strike Manager and allow the player to control it!

Debug Menu

A Debug Menu was something we desperately needed while developing. We had levels we wanted to test, mechanics, items, and more. We needed a way to quickly debug and test these features so I created a easily accessibly Debug Menu. This menu would allow you to change the level, spawn a fake player, and remove players with ease! Adding more functionality to it was super easy as well. This significantly increased our development speed.

Reflection

I thoroughly enjoyed my time working on Forklift Fury. The only reason I stepped away was to pursue my Masters degree at FIEA. I learned a lot about jumping into a pre-existing code base and helping make it better. Decoupling systems and making fun new mechanics is something I really enjoy doing. This game has a lot of potential, the people working on it are very good at what they do. I believe I performed very well in this role and would do it all again if I had the chance!