Refactor Code

Design Challenge

This devlog contributes to the design challenge: "Improve the sustainability and expandability of an existing game so future developers can add and edit the game more easily in the future."

Context

Whilst working on the virtual opponent, I noticed some major flaws in the code which prevented me from easily adding new features. Also, comments with explanations were either excessive or non-existing. This made it really hard for me to understand what was going on in the code and to eventually expand on it. 

How to change the code design to make the code easier to understand and to work with, keeping in mind further expansion by other developers?

Methods

Workshop - Gap Analysis

By experience working on other parts of the game, I noticed quite a lot of weird things. For example, most actions were tied by their respective UI. This led to code snippets where throwing a dice was depending on checking for morning medication. Every action in the UI even had their own slightly modified version of a popup where the only purpose was selecting an amount. On top of that, the gamemanager class contained of 800+ lines ranging in functionality from moving a player, to throwing a dice, to managing player actions. This has been solved by another intern (read his devlog).

Library - Best, Good and Bad Practices

What even is "good code? According to some sources (linked down below), good code consists of a few principles. One key importance is the SOLID design principle. This principle implies a class should have one responsibility only and should be able to operate without depending on another class. Unity's system is component-based which means it uses classes as components each with their own responsibilities and functions. In the current code, this isn't the case.

Workshop - Decomposition

As I said before, Unity's component-based system, requires the developer to think in components and add functionality where it is able to be reused. That's why I changed many different variants of UI, into one which can display any consumable instead of just the prefab ones. 

Showroom - Peer Review

I asked my co-intern to take a look at the changed code. He gave me valuable feedback about the way the UI is handled. He told me to split parts of the UI apart from the hard-coded mess it was. Because of that, I changed the way some UI elements were called to prevent a dependency on other UI elements.

Lab - Usability Testing
Finally, the most important thing after a rework of code, is the testing when all changes are applied. I tested the game multiple times and let another intern test the game as well. In this, we did find some new bugs (some didn't have anything to do with the rework). I fixed the ones regarding the rework and the other intern fixed the other ones. 

Result & Validation

Scriptable Objects - Before

Every time an amount should be showed to the player, it triggers a separate popup. This leads to overwhelming amounts of popup prefabs and specific methods to show them. This same principle was used with displaying different kinds of meals to the player. 

Scriptable Objects - After

The many different popup methods are replaced by one generic method. All meals are put into scriptable objects so they can be easily referenced and changed in one centralised space. This also allows for more generic popups as shown below.

UI Dependency - Before

Every method in this array is depending on the other one's callback. Notice how the last method (displayed separately), uses the callback to show a dice popup. This way it's hard for new developers to find where a dice popup is actually showed.

UI Dependency - After

Using coroutines it's easier to spot, edit and add medication in the routine check. It clearly shows the order in which checks are executed and provides a clear view of what's going on. It also prevents duplicate code and instead reuses a generic method to check on any type of medicine.

Next step

Now this rework is finished, adding new features or expanding/ changing old ones, is a lot easier. Not only is the code easier to understand, but classes are a lot more independent of each other. For example, when a new medicine would be added in the past, it would need a lot, including UI, to add it. Right now, with the changes in place, someone can easily create a new medicine and just call a popup to show for it. It's also much easier for new developers to understand the code and apply changes to it. 

Sources

Replay Virtual Opponent. (2022). Daan van Eijl Graduation Internship Portfolio. Retrieved 11 March 2022, from https://daan-van-eijl-graduation-internship-portfolio.webnode.nl/devlog/project-rework/ 

Janssen, T. (2021, April 5). SOLID Design Principles Explained: The Single Responsibility Principle. Stackify. Retrieved 11 March 2022, from https://stackify.com/solid-design-principles/ 

How to Improve Code Quality, Best Practices. (2021, October 26). Encora. Retrieved 11 March 2022, from https://www.encora.com/insights/best-practices-to-improve-code-quality 

Omeyer, A. (2022, January 7). The Software Engineer's Complete Guide to Code Quality. Medium. Retrieved 11 March 2022, from https://betterprogramming.pub/the-engineers-complete-guide-to-code-quality-dfa8d490c05e 

Comprehensive Guide to Code Quality: Best Practices and Tools. (2021, July 1). CodingSans. Retrieved 11 March 2022, from https://codingsans.com/blog/code-quality