Assets [Design Pattern] Unity-GameSystems: A ScriptableObject way to manage game states and events

Hi!

Unity-GameSystems is a set of tools made after the release of Warhammer 40.000: Mechanicus to fix and clean design patterns used in the game.

Unity-GameSystems propose a way to manage your game states (GameContext), your game events (GameEvent), your libraries of prefabs or any kind of data (GameLibrary), your log system and a way to handle your UI Button.
You can find at the bottom of the readme.md file a folder archictecture to follow to keep clean your project.

Here is the repo: https://github.com/BulwarkStudios/Unity-GameSystems/tree/develop

I will be happy to discuss with you about thoses patterns.

Have a happy coding day!

 

Hi, thanks for sharing! I'm always curious to see how other unity games handle design issues. Congratulations on the positive reception of Mechanicus!

I'm finding it hard to figure out the exact issues your system solves and how it fits together, to be honest. After a quick glance, it seems a bit like you used scriptable objects to implement singletons, e. g. for an event system. It also seems that it was done this way to enable runtime inspection?

 

Thanks!

The main objective here was to build an architecture to keep clean the codebase on a scalable project. Some design patterns are great but add too much complexity. When new employes join the team, it was hard for them to read and understand the project.
I tried to find what was hard to understand and why. With this system a new member can know in which state the game is and what events can be triggered during runtime just by viewing the ScriptableObjects in the project. This help to find where is the relative code just by searching the context or the event name in the codebase or just by click on the references in the inspector during runtime.

 

This is a great post, really.
I am honestly not surprised to hear that new developers were having trouble understanding the code.
I have > 20 years experience in programming. >10 managing teams. Many new people in the field nowadays - and they, unfortunately, have to learn on their own flesh the mistakes I learned a long time ago:
Mostly, above all lessons, my lesson is that the top priority, above everything else, especially for large and scalable projects with teams which change, and GROW:
- make everything easy to follow and understand.
Not *elegant* and *unit-testable*... instead of prioritizing the machine-code elegance - prioritize the human-readability of it.

What many developers do - is the same ancient mistake, made by all developers, since programming was born:
They want to impose their own OCD-born aesthetics and make "perfect" code - or at least "elegant" - or "scalable" - there are many different names.
But many of them cross the line - that invisible line when something that was actually really simple: like:
"build a map. instantiate enemies. start the game"
into a convoluted set of self-referencing instructions that are so many steps removed from the actual game domain itself, that a programmer hoping to make sense of the instructions finds himself delving deeper into a rabbit hole, just like alice in wonderland.

And there are so. Many. New. Developers.
And so many of them are so easily impressed by "clean, neat, elegant" code - but not many give two cents about the really important question:
Will johnnie the new developer take one week, or TWO MONTHS to understand how to solve a bug in his first task as a developer?

Once again -thanks for sharing, this is very interesting. I love seeing architectures - especially neat ones! And I always love learning about others in the market. I wish there were many, many other examples of commercial video game architectures made with unity