Gladly.

So here's the basics of the issue.

mob/player is the player
mob/enemy is a non-player enemy that you can fight.

Fighting is behavior that's tied to players and npc enemies only.

So why are combat stats higher in the tree than either of those two children?

To put it more simply:

Let's say you have reptiles and birds. Birds evolved from reptiles, so the family tree would look like this:



An avian is a child of a reptile. The avian can do everything that the reptile can do, but the reptile may not be able to do everything that the avian can do. This is called polymorphism.

Now, mammals are also a child of reptiles.



Both avians and mammals are reptiles, but reptiles are neither avian or mammal. Likewise, avians and mammals are siblings, and thus an avian isn't a mammal and a mammal isn't an avian.

Now, you might ask, why is this important? Biology cares about something called "morphology", or how an animal is shaped. We classify animals into groups and trees based on subtle changes in shape/function (morphology) over time.

In software design, though, we care about behavior. We classify objects into trees based on how they are structured and function.

Now, if behavior makes objects different from one another, that means we need a more in-depth example to really drive your problem home.

Let's define some behaviors: (some of these aren't always true, but for the purposes of this explanation, let's go with it.)

- Reptiles and Avians lay eggs
- Avians and Mammals are warm blooded
- Mammals give live birth
- Reptiles and Avians have scales
- Mammals have fur
- Reptiles are born without parental dependence.
- Avians and mammals care for their young after birth.

So let's look at how this works with some really bad examples:



Notice how mammal has properties inherited from reptile that don't make sense? Like "has scales", and "cold_blooded". Also look at how warm_blooded and care_for_young are both defined independently each in avian and mammal. This can be bad for general questions about an animal.

Your gut reaction would be to do something like this:



This is better, but it unnecessarily puts all of the behavioral burden on the reptile type. A reptile doesn't need to know how to give live birth in order to have children that do. This type of approach is not actually polymorphism, it's basically an interface-record design. It's not a bad approach all of the time, but in many cases it leads to undesirable behavior.


Now, basically, what's going on in your game is that you have combat-related variables defined under the base type because you want to use usr without compiler errors.

This is one of the areas that I will trash about BYOND. Verbs. Verbs are one of the main things that BYOND programmers learn that they can't seem to do right, and it ruins them on transitioning to a proper programming language. In a proper programming language, there's no such thing as "usr", and that's a good thing.

The reason so many people do verbs wrong is because they don't understand polymorphism at all. Think about it: Who needs verbs? Players. Players need verbs. A player almost always will be connected to a mob, but the player themselves is represented by the client. A client can transition between multiple mobs during its lifetime in a world, so mob-specific behavior should never be exposed to the client object.

That's where verb troubles start coming in. Because usr is always typed as /mob. Your player is /mob/player in your game, so any variables you define under /mob/player won't be accessible to usr. Most people, instead of learning to avoid this pitfall the elegant way, instead only cause themselves more headaches just like the little one you discovered (it's only the tip of the iceberg). They do this by jamming every variable into the lowest level possible. In proper polymorphic design, variables should always be embedded at the highest level possible, but the lowest level necessary. If you have a type that has no need of a variable, it shouldn't have it. Period.

So what's the elegant way, you ask? Well, that's actually amazingly simple. It's called typecasting.

You can actually treat an object as another type of object by typecasting. It's really easy to do.



That's called a typecast. We are casting from the default type /mob to a more explicit type: /mob/player. Now, our variable user has access to /mob/player specific variables.

But you have another problem. Both /mob/player and /mob/enemy need access to combat variables. Well, that's easy too. Let's create a child class of mob that is the parent class of both player and enemy. This child class will contain all behavior related to combat and will be called a combatant.



Now, player and enemy inherit combatant behavior from the root type.

So what about non-combatants? When would we want something you couldn't fight? Well, what about a quest-giver or a tutorial NPC that you don't want players to be able to kill? Sure, you could make it so that it regenerates health constantly at a rate that makes it unkillable, but that's just extra processing. Just don't make it fightable in the first place.

Alright, let's take a look at verb structure. I honestly argue that verbs should always be avoided except at the client level and for right-click menus (even then, the right-click menu is ugly and could be made yourself to look a lot better).

We should assume that verbs are always being called by a player. That means you should always cast usr into a /mob/combatant/player typed variable.



The above example is a relatively simplistic approach for handling polymorphic behavior in a game. I really dislike verbs quite a lot, so the AttackVerb verb is ugly to me, but it does to the job as an example.

Notice how we defined functions in Combatant and then changed their behavior further down in enemy and player? That's polymorphic design. We're leaving ourselves lots of room for customization and behavioral changes without the lower-level code having to be aware of what higher level code is going to do.


A not very important section:

Now, because every time I talk about polymorphism on these forums, someone like Forum_account shows up and goes on about multiple inheritance and how polymorphism prevents multiple inheritance. It doesn't. BYOND doesn't allow multiple inheritance, but you can fake it and it's pretty cool.

Let's say you want to implement a shopkeeper that does a bunch of shopkeepy stuff, but isn't fightable. Then you later want to make a shopkeeper that also does shopkeepy stuff, but is fightable. You either have to abandon my combatant type, or you have to make a combatant behavior for something not acting like a combatant which is silly.

There's a third option.



Okay, this is the basis for our approach. But it gets better. So you don't want to have to implement the same code twice? I hear you.

Let's take a look at how to make this easier to maintain:



Okay, so we just put a third type in with the same code. This is worse, not better dammit! Watch.



Now, while you are maintaining your code, the code in i_shopkeeper is called the "interface code". You should never create i_shopkeeper objects. Only use it as a type for casting. This is called an interface.

By reducing the required code to create a shopkeeper into a single line, we can include all of the code to create a shopkeeper with a single preprocessor rather than having to maintain the same code in multiple areas over and over again. You just need to remember to minimize any changes you make into a single line in the proper format and update the behavior definition.

Now you can do cool stuff like this:



the i_shopkeeper interface is never created. i_shopkeeper actually refers to an object that is an instance of either /mob/shopkeeper or /mob/combatant/shopkeeper. So you are actually directly calling that mob's Shop proc instead of the interface's Shop proc. You can do this over and over again with multiple behaviors and cobble together types that use a bunch of different interfaces to mix and match behavior across different object types without having to type it more than once.

Unfortunately, you have to reformat the code any time you change it, so it does require a bit of setup.