What is the best programming pattern for a Strategy Game?

For the last two years I've been working on a strategy game for mobile- kind of like Civilization 5 but with potatoes instead of people. It's currently based completely around over fifteen singletons that manage different systems in the game.

Even though I'm very far into the project, I'm thinking about refactoring my code base into something more manageable, especially with the thought that more programmers could eventually hop onto it.

I've been looking into some patterns that depend on DI like ZenJect, but I'm not sure if that's the best option for my genre of game (nor am I completely sold on the value of DI for the mechanics I've implemented). A lot of values and functions in my strategy game are spread a little haphazardly throughout the project, and are referenced for a lot of different systems. I believe that means that there's tight coupling basically everywhere, and it may be difficult to refactor.

Any suggestions for design patterns to refactor my code in?

Thanks in advance.

 

ECS

 

Is there a specific reason why you would suggestion ECS?

 

ECS allows amazing performance. You can render many units without an issue. ECS with DOTS is new and will only get better. Is competitive. Is good for mobile battery, if targeting such platforms. And is dead easy for multithreading.

Also, you don't relay on some third party assets, or patterns.

Just to point out few ...

 

Ok. I'm a little scared of completely switching to a new system. Will it require that everything depends on the entity component system, or can I gradually change things over to ECS?

My wacky system currently has a bunch of singletons for handling player interactions, and only a couple for the AI. I don't see a direct correlation to how ECS will help me because my game isn't unit intensive. All the examples that I see for ECS show thousands of entities doing navigation across a map. While I'm sure ECS helps tremendously there, I'll have around 30 units at a time that run on coroutines.

Will I have a noticeable difference in terms of performance for ECS?

 

Firstly, you can start using jobs rather ECS to begin with. It would be first step of conversion.

Then you will force yourself, to reorginiase and rethink game structure. Potentially leading to massive work flow improvement.

Lastly, you can remove this crappy coroutines, for every single thing. These are not any magical tools. Still require CPU. And are harder to debug.

For 30 units maybe no much improvement. But I you consider going mobile, then is something worth to think of.

Keep in mind DOTS Burst for performance bust.

 

Ok, I'll definitely have to look into those. The job system seems interesting, may have to implement it for the AI's computations. I am going for mobile, so it's definitely something that's on my mind.

I'm not exactly sure what the DOTS Burst compiler does, or how it makes my code necessarily better. From what I can tell from unity.com/dots it takes c# jobs and magically turns them into optimized code.

But if it's better, then it's better!

I think in general I'm having a very hard time with figuring out how to divide my project up into an ECS system.

If I break my game down like so:

• A whole bunch of UI for the player to make decisions with to easily change variables.
• Static visual components that get generated at the start and rarely change.
• About 100+ random events and calculations that fire every X seconds within coroutines to make things happen in the game.

In regards to the third bullet point, I think that I can replace a lot of those coroutines with the job system in ECS. I am not sure if I can/need to replace the UI interactions, because they don't change very many coroutines. At most they would signal another coroutine to start, which I guess would turn into an addition to a job that's already running.

Are there any patterns that you can vouch for that would help me with the way that I use UI? I currently have a Menu<> class that inherits from an IMenuManager that describes what the menu does. I think it's a couple levels of abstraction too high.

I haven't seen a good example of ECS being used to control UI, but then again I'm not very familiar with how ECS is used at all.

 

Currently there is no ECS UI. So you will use what you got.
In terms of DOTS, Is important what you got in terms of game core and how you organise code.
You still can use classic MonoBehaviour along with DOTS. You just need have some form of information flow mechanics, between these two paradigms.

To work wit ECS, you need switch your mind from Object Oriented Programming, to Data Oriented Programming. That will be you first main challange. Therefore, converting one by one systems to jobs first, can be good starting point.
Don't do all at once.

In terms of burst, it does code optimization at low level. So you don't need to worry what it exactly does. What is important, to follow few rules, to comply with burst, if you want to gain benefits of it.