Help with the conceptual logic behind upgrade and stats system.

Unity Engine
,
1

While playing my game the player has the option to purchase different upgrades to boost stuff like movement speed or to alter the behaviour of the weapon he carries. I need conceptual help on how to best implement such a system.

So far, I have three Master scriptbtable object scripts (Player, Weapon, Enemy) of which I can generate SOs for every new weapon, enemy or player character I want to implement. These SOs stay static aka won’t be altered and will be used to initialize the scene in a C# script. From there a runtime stats tracker takes the initialized values but also communicates via a delegate system with other game systems to keep track of enemy and player stats (HP, speed, etc.) Below is a small conceptual drawing of a solution I think about right now:

9850707--1418211--StatsSystemExample.png
9850707--1418211--StatsSystemExample.png1920×1128 190 KB

Safe to say, this gets complicated fairly fast. And here I don’t even have the full functionality drawn. For instance it would also be nice to alter the shop or the powerup system via permanent Roguelike upgrades. The number of connections between the different systems gets hard to oversee especially as additional systems need to be implemented. My main goal is to start with a scalable framework now so that it is easy to implement more content later. I am fairly certain that a runtime stats tracker coupled with an events/Delegate system is a good solution, however, I am also fairly new to OOP in general so if anybody has a better solution or other tips and tricks I would appreciate it.

2

Yep, that’s upgrades and stats in general.

Sounds like you have at least the start of a good system, so push forward and see how it goes, refactor as needed.

Don’t make 100 upgrades and 100 stats…make THREE, and learn from each of them, and imagine how well they will scale as you go forward.

This is also extremely well-covered ground in bazillions of Youtube tutorials.

ScriptableObject usage in RPGs:

https://discussions.unity.com/t/798767/2

https://discussions.unity.com/t/803356/2

Making a stats system is also a great time to consider Load/Save (persistence) of your game data. If you defer this you will likely have a much harder time of things when you get to it.

Load/Save steps:

https://discussions.unity.com/t/799896/4

https://www.youtube.com/watch?v=S_gE99yeK6c

An excellent discussion of loading/saving in Unity3D by Xarbrough:

https://discussions.unity.com/t/870022/6

And another excellent set of notes and considerations by karliss_coldwild:

https://discussions.unity.com/t/935169/6

Loading/Saving ScriptableObjects by a proxy identifier such as name:

https://discussions.unity.com/t/892140/8

When loading, you can never re-create a MonoBehaviour or ScriptableObject instance directly from JSON. Save data needs to be all entirely plain C# data with no Unity objects in it.

The reason is they are hybrid C# and native engine objects, and when the JSON package calls new to make one, it cannot make the native engine portion of the object, so you end up with a defective “dead” Unity object.

Instead you must first create the MonoBehaviour using AddComponent() on a GameObject instance, or use ScriptableObject.CreateInstance() to make your SO, then use the appropriate JSON “populate object” call to fill in its public fields.

If you want to use PlayerPrefs to save your game, it’s always better to use a JSON-based wrapper such as this one I forked from a fellow named Brett M Johnson on github:

https://gist.github.com/kurtdekker/7db0500da01c3eb2a7ac8040198ce7f6

Do not use the binary formatter/serializer: it is insecure, it cannot be made secure, and it makes debugging very difficult, plus it actually will NOT prevent people from modifying your save data on their computers.

https://docs.microsoft.com/en-us/dotnet/standard/serialization/binaryformatter-security-guide

1 Like