#There are all kinds of design patterns,

1 messages · Page 1 of 1 (latest)

woven trout
#

Ill make a thread so i dont spam general

#

Okay so my main issue is im doing a MOBA and I have to make the structure of the characters and the abilities. Right now I have player and enemy that inherit from entity (Entity has name and stats). I also have weapon, armour, trinket, race and class classes which are introduced in the player by composition

#

Now the problem is right here every ability has variables and some of them might share with other abilities some of the variables

#

and other abilities share other variables

#

or even methods

#

so if i start doing inheritance it will get really big and hard to manage, not even counting that if later on i want to add more variables or methods everything collapses

latent tinsel
# woven trout Now the problem is right here every ability has variables and some of them might...

How many of these are actually shared, that need to be accessed from a class outside of the ability?
Itd make sense if abilities all defined stuff like cooldown. but if you just so happen to have a "radius" in a projectile ability and a "radius" in an explosion ability, then these arent shared. And they definitely shouldnt need to be accessed externally from only having a base class (which is where inheritance would come into play)

#

To me it just sounds like you've created your own problem of seeing the same variable name in multiple places, when they are not necessarily related variables.

woven trout
#

like projectileRadius and explosiveRadius

#

btw, if for example I have stats on weapon, armour, race and class, should I name them all _stats on each class or names should be different? Like _raceStats, _weaponStats... etc

latent tinsel
#

The naming doesnt actually matter. If what I assumed above is correct, that you're referring to variables that seem similar, then this truly isnt an issue.

latent tinsel
woven trout
#

so how

#

can I make sure im doing a good design

latent tinsel
#

You tryitandsee
If it's a pain to use your own code, then it's bad design.

#

For what you were asking about shared variables, first think about what problem youd be solving by even grouping them. Let's just imagine you go the inheritance route and complete it all. What issue is now solved?
At what point would you even be referencing an ability by anything other than the base class? The base class which should have no knowledge of things like "radius" or other ability specific things. If you are referencing it by a more specific class (something that defines a radius) then this goes against inheritance already.

woven trout
#

which are the skills

#

with all the variables and methods

#

every other skill which has a child is just abstract

#

cause each skill will have its own methods and stuff

latent tinsel
#

Unless you're making a very complex AI that can decide what to do based on its abilities, I see no reason why you should need to reference specific fields of an ability.

woven trout
latent tinsel
woven trout
#

they are related, you thought they arent but im telling you all the variables that i want not to get duplicated are the same

latent tinsel
#

If you arent actually referring to them externally, this is a non issue

woven trout
#

okay, and one more thing

#

If I have a object and I use DontDestroyOnLoad(object), after i change the scene the object shouldnt run Start again right?

latent tinsel
#

No it shouldnt

woven trout
#

So why after I change scene all my stats are lost

#

if the _stats from entity are initialized on start?

#

It doesnt happen if i do it on awake or right where it is right now

#

Btw Player is just a child of entity

latent tinsel
#

Your start method is empty, whatever is happening here is completely unrelated to the start method

woven trout
#

the problem exists if i do it this way ```CS
public abstract class Entity : MonoBehaviour
{
[SerializeField] protected string _name;

[SerializeField] protected Stats _stats;

protected virtual void Start()
{

_stats= new Stats(0, 0, 0, 0f, 0f, 0, 0, 0f);
}
protected virtual void Update()
{

}

}```

#

but it shouldnt if start is not called when using dontdestroyonload

latent tinsel
#

Add a debug and see for yourself if start is being called again. Print the instance ID too so you can see if you have multiple instances
I also have to go, so I suggest posting this outside the thread as it's own question

woven trout
#

okay thx

cyan scaffold
#

I'm a bit late to reply, but here's another approach you can take:
Instead of having a class tree for all your abilities, define them in data. Have one class(a ScriptableObject would be great for this), containing all the possible properties, like range, radius, damage, effects, vfx, etc, and define them in instances of this class. This way you can have a wide range of abilities defined as data, instead of being hardcoded. This also aligns with composition well.

woven trout
#

And for methods can I do the same?

cyan scaffold
# woven trout how do i define them on instances so i can just take the attributes i want?

You could use enums or something, but maybe not separate the use from don't use. For example, if it's an area of effect ability, it would have are > 0, so when you run the check whether it hits something or not, you know to make an overlap sphere with that radius or something. On the other hand, if it doesn't have an area of effect, then set the property to 0. Then when you get to the area of effect check, you see if the area is 0, and if it is, skip the check entirely.

cyan scaffold
#

Aside from maybe some utility methods.

woven trout
cyan scaffold
woven trout
#

Yeah but that variable will be on that stat

#

And never use

#

Why would you have variables y don't use never

cyan scaffold
#

It would be used. To tell that there's no need for a an area check.

#

And it would be used in more general sense, assuming you'll have abilities that do have an area of effect.

#

It's a property of the object. It being 0 doesn't mean that it's useless. It describes something about the object.

woven trout
#

Yeah but there will be more variables

#

That don't have a real use

cyan scaffold
#

For example?

woven trout
#

imagine its a magic arrow, it has range, cd, dmg as variables that use

#

but in stats if we get all the stats of all the abilities there might be also areaEffect, effectDuration, percentageAttackSpeedBoost...

#

an infinite amount

#

btw is a bad practice making 1 constructor for each case of stats so u can just build whatever u need?

cyan scaffold
cyan scaffold
cyan scaffold
# woven trout imagine its a magic arrow, it has range, cd, dmg as variables that use

So, as I said, might want to think of your abilities in a more composite way. For example, consider the ability as just a means of delivering certain effects, whether it's damage, healing, buffs, environment modification, or whatever else. The delivering methods are not that numerous: it's either a projectile or a melee/touch ability and it can either have an area it affects or not. Cool down could also be handled here. Then you have the list of effects that it applies. You could even have several lists for different timings or conditions and you could even pull this data into separate data container as well. Then the effects themselves could be more spread out with inheritance if needed.