Devlog May 2022 - Refactoring, refactoring, refactoring and change in priorities
Hello and welcome to another devlog! This time there is not much to show in terms of advancements in gameplay features. However, we are currently working on a pretty big overhaul of the whole codebase, as it is quite old, and we have advanced a lot as developers since we started.
Obviously since we do not share code here, it becomes really difficult to show exactly what we have done to our code, but what we can do is share how we have gone ahead and refactored, and what methods we have used. This does however mean that we recommend you, the reader have at least low - intermediate level of understanding of programming and basic knowledge of the Unity engine.
One major issue with our codebase is that many scripts are tightly knit together. This makes it extremely difficult to find issues and extract information from certain classes. We would like to untangle the spaghetti, and thus reduce dependencies. We have been working on this through the SOLID principles, which we will not go too much into detail with, but it is often important to follow those principles. If you are truly interested in programming, which you probably are if you have read to this point, go and read up on it, it is extremely important in the programming space.
One issue we have throughout the codebase, is the reliance and use of MonoBehaviours, while this is not necessarily a huge problem, it does make the code harder to read, and suboptimal in places. What we are doing to reduce the use of these, is to split up our scripts. So in many cases we make use of a MonoBehaviour class for visuals/positioning and other things that needs to be handled through the inspector or component systems. Then we have an associated class that will handle general data of an object.
For example, we have a "Card" class that holds and handles data of the cards, such as stats. Then we also have a "CardRenderer" class, which handles mostly visuals, such as pointer events, animations and displaying stats to the player.
The MonoBehaviours can of course handle all these things by themselves, and can be especially useful for designers as well, because you could change certain pieces of data through the inspector instead of the code. However, the use of them everywhere can quickly become a mess, a MonoBehaviour is considered a component, which you can apply to a GameObject. That means that to gain access to a MonoBehaviour class, you have to call the "GetComponent<>" function, which also needs a reference to the associated GameObject. Also, it is a bit slower than accessing an object through normal terms, it is still not a huge deal, especially if you do not call that function every frame. This way we also follow the SOLID principles, make the code more readable and extendable.
These changes also allows us to test functionality without relying as much on the Unity engine, and it improves testing capabilities.
We also have general improvements to both performance and readability in the code. For example the frontlines Green/red fields on the battlefield (highlighted in the upcoming illustration) are technically a part of the battlefield and uses the same grid field, but they were very much disconnected from the battlefield itself in code. This made it hard to communicate between the frontline and battlefield in general, and checking whether something was safe from attacks and their movement from the frontline to the battlefield was a real mess in the code. This is just one example of many we could go through.
Once again it is only really improvements to future development, and does not change/improve actual gameplay other than performance.
Changes to priority
In the studio we have decided to change focus and priorities, so for now the settlement manager we talked about last month has been put on pause indefinitely in the development department. We still think the settlement manager has great potential for the future, but we want to focus more on card battles, as that has some great promise by itself.
That ties it all up for the month of May. Tell us if you learnt something new, or what we could do differently, any comment or reaction to this post is greatly appreciated.