#game dev tip

[clowngames]

Game dev tip!

Improve the quality of your game by adding a buff woman

[drawbabybirddraw]

[oz-creates-and-explores]

Game Dev Tip

Don't try to make a perfect game - whether that means perfect art, programming, animations, or whatever - on your first attempt.

Getting to a point of completion is, imo, more important. To see a project to the end will give you a sense of satisfaction and a drive to continue creating. And learning how to improve the various aspects of a game will come with practice.

That being said - I really should try to finish my first game lol

🧙🏾‍♂️

[oz-creates-and-explores]

Single Responsibility Principle

The first principle defined in the SOLID principles is the Single Responsibility Principle (SRP). This principle is probably the most simple of the SOLID principles but one that I find myself violating way too often. SRP states that every class should be defined with a single purpose and not be responsible for a multitude of things.

When I wrote the first iteration of my game, I had a singleton class called GameManager and it was massive! In my mind back then, I was proud of it. *look at this huge class that is the brain of my game, serving as the entry point and flow controller of every action possible*

Among the things I'm now refactoring is this class... I'm trying to move away from using singletons and breaking the functionality into smaller parts. For example, I now have moved my main menu into its own scene with a class whose sole purpose is to set a boolean flag to alert the next scene if the player wants to start a new game or load one from file. And another class that draws the map of the current area the player is in. And one responsible for populating an action menu based on what is available at the players current level.

At first it seemed to me that I was cluttering my project by adding so many new classes but this is where a proper directory structure comes into play. Organizing my classes (something I still need to clean up tbh) helped to alleviate some of the growing pains of using the SRP but now my code is easier to navigate and I'm not even 50% done refactoring. If something doesn't work, I know exactly where to look because my classes are generally smaller in size and have fewer methods to scroll through.

So this is my experience so far with the Single Responsibility Principle. While the number of classes you have will go up, this principle helps your code become easier to read through and clearly defines and separates functions according to a purpose. Classes aren't crazy monolithic controllers of everything with a reference to everything else. And instead they contain what they need in order to perform a specific task.

The link above is one of the videos I went through in order to understand the SRP in the context of Unity. I hope this post helps and I'd love to hear your thoughts or experiences or even any questions! Next up will be the Open Close Principle

🧙🏾‍♂️

[oz-creates-and-explores]

Open Closed Principle

The second of the principles defined in SOLID is called the Open Closed Principle. It means that an object should be open for extension, but closed for modification.

Tbh this one is a bit harder for me to grasp. Like I get the definition, but I'm still trying to figure out how to properly implement it. So here is a link to a nice video on how to implement this principle in unity:

I really like the example given because for the longest time I was confused as how to use interfaces in unity mainly because they don't serialize into the inspector. But caching the components based on an interface type is one way that I'll definitely be implementing my towers and minions.

Also, as mentioned in the video. Using abstract classes can be one of the ways this principle can be used and an example of that in my game is how my action menus are defined. I have an abstract class (ActionMenu) that defines common functionality like how to transition between the menus but the subclass implementation (ie. TowerActionMenu) defines menu specific functionality like populating buttons dynamically. This allows me add new features to menus by extending the base class without having to modify the base action menu object.

I'm thinking of making TowerActionMenu a bit more generically named like DynamicActionMenu so that other menus that are dynamically populated can just use the same script with different parameters... but that's a post for another time

I hope this helps and as always, questions, comments, or advice is always welcome!

🧙🏾‍♂️