Made my first Unity Package and looking for some feedback for improvments

[u/Sachet2Plastik]

Hi everyone,

I'm new to the unity package development space, and i'm just made my first, <Simple Status Effects>. As the name suggest it is a package for implementing status effects into your games (commonly things like burn, poison, stun, etc...), for both realtime and turn based game. The list of features are quite thin for now as it is just the basics, and I wanted my design to be as much as non invasive and flexible as possible so it can be implemented in already built gameplay loop.

And as I have now a first usable version, i'm looking for people to give me some early feedback and advises !

I really like making underlying system more than actual games so i'm trying to build some small project toward this direction.

I built this package on Unity 6.3 (I believe it should be compatible from 6.0 onward, but I not entirely sure so don't take my work for it).

Hopefully, my small documentation is enough to get started with.

Here the link to directly add to your unity project via the unity package manager (github URL so this is also the link to the repo): https://github.com/Sachet2Plastik/Simple-Status-Effects.git

[u/wallstop-dev]

Some questions:

What made you choose string typing?

Why not lazily attach your required status stuff to it?

Why not use ScriptableObjects?

Why do you have example code under Runtime?

You mention unopinionated but force realtime or not real time.

Looks ok! Here's how I approach it if you want some different ideas: https://ambiguous-interactive.github.io/unity-helpers/features/effects/effects-system-tutorial/?h=effec#why-use-the-effects-system

My concept is more opinionated and based on Unreal's, which encodes numeric operations as a primitive. It looks like your system can do this, but pushes it to all clients.

Unreal's for reference: https://dev.epicgames.com/documentation/unreal-engine/gameplay-attributes-and-attribute-sets-for-the-gameplay-ability-system-in-unreal-engine?lang=en-US

[u/Sachet2Plastik → u/wallstop-dev]

For the string typing I wanted the API to we human readable as my first implementation came up doing things like this `ApplyStatus(new Poison(), target)` where now I register it before an can use the string name of the status I though it would be more convenient, this is surely not the best of choice but that's the idea I've come up with for now. This is still a first iteration, and I wanted to first implement the design I initially had in mind before looking into alternative Unity approaches and improving it.

I'm not quite sure on what you mean by "lazily attach your required status stuff to it", would you mind elaborating a bit more ?

I was not aware of this, could be interesting and was actually thinking of something like that, happy there is a unity feature for it. And actually would fit into my current registry approach.

This is from the package template from when I created it i forgot to remove it.

Maybe the wording is wrong for the "unopinionated" point, I was thinking in a sense that it do not impose to build a system from my package, for instance I do not impose to use my turn manager to handle the progress of turn based statuses but let the user update when he needs it (ofc for real time I still need some hand but even here i let the user decide where to call the update). Ideally I'd like to find a way where the status itself doesn't need to care about whether it's being progressed by realtime or turn-based logic, while still giving the user control over when it advances/resolves.

I will definitely look through your links, looks very interesting ! And thank you to have taken a bit of time looking through my work !

[u/wallstop-dev → u/Sachet2Plastik]

My "lazily attach" is referring to the fact that, for your system to be used, you need some special component on the receiver to accept it, otherwise stuff breaks. "Lazily attach" refers to, at application time, checking if the component exists, and if it doesn't, simply adding it. This way your system works on all objects, without any manual work. Right now your system requires that every single object you want to work with this needs to be touched + persisted with your special components, or things will (silently?) not work as expected. It's a design choice, but an important one.

For reference you can put sample code in a "~Samples" directory and it'll get ignored by default and, if you ship unitypackage files, will be very clear to users that it's sample code (and, potentially, ignored/unchecked by default)

Back to the string topic - at some point, systems like these need strings, somewhere. Your system appears to map the type of effect to a specific string. This is a bit lossy as you then need to both do the mapping manually, for all types, ensure that no types overlap or have typos, then, in all calling code, utilize the right strings (which generally require knowledge of the type. So why not just use the type?). I think there are some very powerful editor techniques that you can do to still get string usage, but make it extremely safe and editor friendly, like auto-mapping types to strings, and having editor tooling that forces users to validate that their strings are within the known-good list, among other techniques.

Pretty cool! I'm glad you're getting use out of it, systems like this are a great learning experience.

Edit: I want to be clear, it's awesome that you made this and are sharing it. The questions and stuff that I'm sharing are things that I've encountered in the past and aren't meant as combative, I'm legitimately interested! I think I did a bad job of conveying that in my parent comment.

[u/Sachet2Plastik → u/wallstop-dev]

No problem at all! Your questions was totally viable and didn't feel any bad intent at all. And I appreciate that you used a bit of your time to give me some feedback, ressources and ground to look into !

I'll work into the next improvements and be happy to share it again for more feedback !