This prototype adds an improved menu, configurable settings, a completely redone controller using Unity's new Input System, and rebindable controls for both keyboard and gamepads.
Settings menu prototype
The previous two updates weren't formally announced. a.04.01 focused on UI feedback and interactable object implementation, while a.04.02 focused on implementing shield, stamina, and armor. The first thing I worked on in this update was creating a guideline for the code and code cleanup. This was so that further development would be a bit smoother and quicker. Next I worked on re-doing the main menu. The most important thing to tackle first was the ability to configure settings, mainly for post-processing, so that the prototype is more accessible. I made an extension to sliders so that they can handle text much easier; this is available here (there's another extension I made previously to allow for HUD-based sliders to have smooth animation when their values get changed; this is implemented in the game's HUD). After the settings part of the menu was finished, I tweaked how interactable objects work so that they provide success/failure sound feedback (so that when the player tries to interact with something that can't be interacted with, a failure sound plays).
Testing sound system of controller
I then began to tackle the game's controller. About halfway through working on it, I decided to make it a completely separate project, as I intended this to become a generalized controller that I can use for other projects. (this is a part of the same repo linked above). I originally made a rudimentary controller for this game because I didn't care for the outdated Unity Standard Assets controllers, so when making this one, I tried to provide most of the features those had while expanding upon them and improving them. This new controller uses Unity's new Input System, which is more event-based (a bit more performant), allows for devices to change at runtime (e.g. if one plugs in a gamepad, it will work without restarting), and allows for using multiple devices at once with greater ease. Not all of the features of the full controller are used in UE2 (such as walking, crouching, and varying sounds), but at the same time UE2 provides proof-of-concept for certain features not present in the controller's demo (such as the animation system being expandable - UE2 uses it for animating weapons without any extra work besides the animations themselves).
Testing the controls menu, showing how images are placed to show what input is tied to what control
I took a break from UE2 for a while to work on other projects. UE2 is a large-scale project, and I don't have many finished projects because of the work I normally spend toward these larger-scale projects. Earlier in the year I worked on a self-imposed 'hackathon' where I created a program in under 24 hours, and one of the projects I took a break with UE2 to work on was an Electron port of that program. I also made an Electron app to build my LightVerse site using an HTML template and JSON content files. Once those were done, I resumed work on UE2. I transferred the latest work on the controller into UE2 and fixed any issues that arose (i.e. other code referencing variables that were renamed). I made the HUD fade-in/fade-out when needed or not needed (this was later made a setting). I also decided to reorganize the main game scene so that I could split it into smaller scenes that additively load, allowing for better lightmapping (since lightmapping a single scene takes a while and produces larger files). Once all these were done, I began work on the controls menu.
Using EventSystem.SetSelectedGameObject and UI Navigation to ensure menus can be used without a mouse
The controls menu was a very tricky task. First, I had to set up the data structure for storing controls. I also had to make a bunch of sprites to show different controls, as well as translate a myriad of other symbols into their actual symbol (e.g. printing a control directly may result in something like "leftBracket" instead of "["). I then had to figure out how to use the rebinding operation with Input System. This wasn't too difficult, despite Input System's inconsistencies and poor documentation (some things have no description on how to use them, while others provide scenarios that aren't very real-world or correct, an issue present in traditional Unity docs I've noticed some point out). It wasn't too difficult to grab these controls to save them (it was a bit tricky to figure out where exactly to grab them from, though). Saving/loading controls in the menu itself is easy because it only involves my own data structure, not Input System. However, the worst part (which took about 5 hours to figure out) was applying the overrides to the Input System (e.g. setting them back if the player decides to not save, or loading them when the game first starts). It was very difficult to acquire the index of controls (using Input System's method GetBindingIndex() doesn't work, had to use Linq's IndexOf()), and you HAVE to have it in order to use ApplyBindingOverride, the method for, well, applying a binding override for a set of controls ("action map") in Input System. Once that stress was finally over, I tweaked the menu some more and implemented the remaining settings (e.g. headbob, fov, sensitivity, etc.). I forgot to implement mouse inverting with this update, but that will be fixed for the next one. Part of those menu tweaks involved setting up both the main menu and the in-game menus to be able to be used without a mouse. This way, the game can be completely played with a controller, or one can use the keyboard to navigate UI. This UI navigation also uses the new Input System.
