Unity Turn Based Strategy Course - Overall Design Pattern

[Pkbitwise]

I’m about half way through the Turn Based Strategy course and I’m curious about the overall design pattern being used. My background is in control system design, so I’m used to a clear separation of tasks and services where decoupling and using interfaces is the name of the game.

With this course it seems like there’s a heavy leveraging of singletons and referencing anything from anywhere. For example, the UI buttons directly reference the UnitActionSystem rather than staying within the ActionSystemUI. Units also directly reference the LevelGrid singleton and bypass the UnitActionSystem for movement handling.

To me it feels like something like this would become hard to follow as it scales but for all I know it’s the way game development rolls. It is something I just have to buckle up and get used to? I saw that there’s a design patterns for game development course. Is the pros and cons of different strategies discussed there? I’m not trying to argue design patterns (like arguing religion, really), just looking for clarification.

I appreciate the work you all put in to the course.

[MichaelP]

@Pkbitwise

for all I know it’s the way game development rolls

It is and it isn’t.

Unity it basically a big component based system combined with a dependency injection system. Not everything works well in that kind of framework so you find a lot of what you do is working within those limitations. I like to say, you spend a lot of your time fighting with the inspector.

Inferfaces are a fickle thing with Unity. While they work, a lot of people feel they don’t necessarily work well with the inspector.

@Pkbitwise

It is something I just have to buckle up and get used to?

Yes and no. There are heaps of ways of doing everything. You can do it your own way. If you’re going to work solo, the only two things that matters is A). If it works and B) you can follow your own code.

The last part of the equation is Unity is made to work with designers who don’t necessarily know how to do much coding. Drag the component on to the prefab, use the inspector to change the variables to make it do what you need / drag to link to other components etc.

[Brian_Trotter]

@Pkbitwise

To me it feels like something like this would become hard to follow as it scales but for all I know it’s the way game development rolls.

I’m going to agree with Michael on this… it’s Yes and No. There’s a bit of disagreement in the OOP world about the usefulness of the Singleton pattern. As a great example, my personal preference is to avoid them because they can cause issues with debugging. As Hugo says, however, they are just another tool in the toolchest. When used properly, there is nothing wrong with Singletons. You’ll see folks on both side of that debate and some who don’t care. PS, with all my posturing on Singletons, I use them when needed. Sometimes, they really are the best tool of the job.

I’m a strong believer in sticking as close as possible to the SOLID approach to programming, dependency injection, strong use of interfaces, etc. That being said, it’s easy to get caught in the weeds of overengineering. I know because I’ve done it many times myself. As another of our instructors has pointed out: First get a working prototype, then pretty it up.

In the end, it’s practice and experience that will guide you to the patterns you use and the patterns you don’t.

[Yee]

I tend to avoid singletons like the plague, but you can totally scale things up as long as you know what you are doing, there are libraries that are built around singletons, like some HLNLs, so there’s no clear answer as to whether or not it’s a bad thing to use singletons.

So, I do agree, it’s “yesnt” for me too.

[Pkbitwise]

I hope I didn’t come of as hating on the Singleton pattern, I use it when I need to as well. What you guys say makes total sense. I had a feeling it would be a case of “it depends” like so much in the world, but I wanted to pick your brains.

@Brian_Trotter

That being said, it’s easy to get caught in the weeds of overengineering.

Oh boy do I feel you on this one. I certainly have overworked a solution and then came back just refactor my “good idea”.

@MichaelP

The last part of the equation is Unity is made to work with designers who don’t necessarily know how to do much coding.

That’s a really good point. I wasn’t considering the environment outside of the scripting and how that drives the design.

I appreciate you all taking the time.

[MichaelP]

@Yee

I tend to avoid singletons like the plague

With Covid, this phrase has kind of lost its meaning. From what I see, generally speaking, not a lot of people avoid the plague at all

[Jonathan_Borchardt]

@Yee I would love to see a post showing all that is needed to remove the singletons from the strategy project.

[Brian_Trotter]

It takes more than a post… I did it when the course came out, and ultimately, I used a hack for some things, specifically I used static classes and a LOT of static events. One could argue I still used Singletons.

[Jonathan_Borchardt]

I wonder if you could just have like 2-3 singletons. And route events through those.

[Yee]

Sounds like a fun challenge, I’ll see what I can do, but first I gotta finish a portfolio project I’m working on, that’s gonna take me a few couple of days.