CORRUPT ELDRITCH ORDER
ROLE
UI/UX Programmer
DESCRIPTION
My second project for WolverineSoft was as part of the UI/UX squad as a programmer this time. This project was made entirely in one semester and we had a lot of work to do because of it. I worked on many aspects of the UI including the main menus, pause menus, game over screen, boss health bar, and the HUD. The biggest task I had was programming the permanent upgrades menu which required in-depth knowledge about scriptable objects, enums, and data serialization. I did not end up getting it to completely work but after asking my lead for assistance we got it working, while it was very hard I got quite close to solving it and learned a lot about not only the technical aspects of the task but how to ask for help properly in a team based setting. Aside from that we worked a lot with the new Unity Input Action Manager to allow for controller and keyboard support.
PAUSE MENU LOGIC
One particularly nasty bug I had to resolve involved the pause menu. We wanted the player to be able to select the same button they used to pause to also unpause. This caused problems because of the new input system in Unity not having a simple way of checking if a button was pressed on a specific frame (such as GetKeyDown). If you pressed the pause button for more than one frame it would pause and unpause every single frame.
In order to fix this I had to create a coroutine that waited for a very small amount of time (could have been a frame) to clear the wasPressedThisFrame check before switching the input action map.
Also to prevent the pause button check from happening every single frame we just used an event from the player controller script which calls the PauseGame function you see here. I also put a check in the update function so it doesn't look for input every frame just if the pause menu is active or not.
UPGRADE MENU FUNCTIONALITY
This is the logic for an upgrade button. We had 25 permanent upgrades and in order to create an efficient system which designers could change as needed I had to really design my code well. The basic structure was I had an UpgradeTree class which contained a list of buttons defined by type. So there was 5 scriptable objects which served as our trees and designers could alter each upgrade as needed in editor. Then there was a larger UpgradeScreen class which handled navigation, application of upgrades, and had a list of UpgradeTree objects.
Using object-orientated design patterns of encapsulation and inheritance I could create a base Upgrade which had a cost and a type. The type was defined through an enum and the cost was an int which the designer could set in the scriptable object.
You can see in this screenshot that buttons are initialized at the start, setting whether or not they can be bought and changing their text to be the correct cost/level. There is also logic for purchasing a specific upgrade.
This was easily the largest system I worked on in the entire project but it taught me a lot about good systems programming practices and thinking of the impact code has on designers.