Week #8: Fix, Improve, Repeat

Personally, this week has been focused on improving existing systems and fixing known issues. I adjusted the reusability of the interactable systems. I applied it to dialogue characters so that they are triggered when the player desires and not when he accidentally passes through a collider somewhere on the scene. After making talking NPC's part of the interactable system, I realized the outline animations had a bug. The package we used and previously adapted from the asset store did not support objects using multiple composed mesh renderers. After some reverse engineering, I found an easy and effective solution that required no hammering, and now the outline works with complex NPC Humanoid models as well as it does with simple geometries like cubes. The code could be more efficient, but when I tried fixing that issue, I started suffering from null pointer exceptions. I am aware of unity's lifecycle system, and I know how to use Awake, Start, etc.. Still, somehow a list I saw being populated in Start method with desired non-null objects using breakpoints and Rider's debugger became empty when accessed later. No big deal, the current code works, it's not as efficient or elegant as I would like, but works and does not cause any performance issues. I might look into this at some other point in time.

Figure 1 - Outlining Humanoids and other complex Shapes

Other tasks included extending the menu system with the capability of unlocking Levels as the player progresses through them in-game. Meaning that he can only access Level 2 if he completes Level 1, and so on. This mechanism can be bypassed by manually altering the JSON file in the streaming assets folder for testing. Still concerning the menu, it now includes an option to modify the sensibility using a slider to the liking of the player. Some play testers complained about how jaggery and fast the free look was, but with this functionality, it should no longer be an issue. Player preferences are kept through his sessions, and he does not need to customize his game every time he executes it.

Figure 2 - Better tool-tips

Other UI improvements include presenting the key the player should press to interact with or grab an item that is highlighted in the world. While this is not an essential feature for players who dedicate some time to the game, as they start associating the keys to each action, newer players will feel lost and did so in the play tests, if they are not presented the key binds during their session. 

Figure 3 - Before Exchanging the Player Model

Figure 4 - Exchanged Player Model

Finally, I implemented one required feature tied with the core of the game. Which is allowing the player to select and change is disguise. Two solutions were available. Exchange the skin mesh renderers, or change the player model at runtime. The first approach yields better results but has many prerequisites that the team is not capable of fulfilling, e.g., clothes would need to be explicitly designed for the models, which is not possible since we are using mixamo models and they don't bring any replaceable clothes. I still tried to make them work by reusing clothes from different models, but this solution did not work very well, because not all dresses were made alike. By this time, the 3D Artist Humberto replied to my consultation and agreed that the second approach was more comfortable and faster to implement for both of us. Hence, right now, exchanging clothes means that we are changing the player model, which has the downside of having a different body shape and a different face. This, however, should not be an issue once we start using our own models instead of free ones downloaded from the web.