Only Using objs as NPCs

ID:151944
 
Aug 25 2008, 4:31 am
Well, I noticed a lot, that several people are using mobs when making NPCs for games. I realized that I only use objs, because the main thing that separates them is the client var. If you wanted to effect them both as well, you can simply alter atom/movable variables and such.

So, I see no reason whatsoever to use mobs for anything other than actual players, everything else should be made as objs. (Even though some have said they were meant to be used as inventory items or something.)

There is the idea of body switching with an NPC, but it doesn't seem quite right giving NPCs the client variable and then having to check each time. (Though I suppose you check anyways.)

I guess another thing, though is that many of the functions should simply be defined for the client only anyways, which again validates the use of mobs as NPCs.

In my opinion, though, using a mob as a training dummy (training dummies are horrible, over-used ideas anyways) or as a store clerk or something seems pointless, as there is no possibility of having a client connected, and various loops that go through players shouldn't be looping through them as well.
Aug 25 2008, 4:38 am
BYOND's obj/mob limits should factor into any decision here. Typically one good reason to make NPCs out of mobs instead of objs or even turfs is that you leave room for other limits to be filled. Most RPGs have way fewer mobs than objs.

That said, a training dummy can probably be done as just about any type. They really should be limited in number though because games that focus on training--instead of earning experience by actually doing something--always suck. In a well-designed game a training dummy should mostly be for scenery, and at best perform some limited one-time benefit in the presence of a teacher.

Lummox JR
Aug 25 2008, 4:50 am
In response to Lummox JR
Well, what specifically adds to the obj limit?
Just the countless items that you may or may not have in the game? (Armor, potions, scrolls, etc.)
Aug 25 2008, 4:52 am
Naokohiro wrote:
So, I see no reason whatsoever to use mobs for anything other than actual players, everything else should be made as objs. (Even though some have said they were meant to be used as inventory items or something.)

You are correct, you could say there is no reason to initially, or "by default" (for a lack of a better term). But I think people, at least me, do it for the sake of object inheritance. Consider this implementation, of fightable NPCs (as objs) and players (as mobs): 
mob/player
   var
     HP
     power
     resistance
   proc
     Attack()
     TakeDamage()
     Die()

obj/npc
   var
     HP
     power
     resistance
   proc
     Attack()
     TakeDamage()
     Die()


This is very, very messy for the reason you need to copy all the definitions, declarations etc and have them twice in your code. Also, the 2 sets of definitions can't interface with the other set, etc.
Of course, you jump at the alternative to define it all under /atom/movable. This works, but then is bad because if you have eg, this: 
mob/temp //for login screen or whatever - dummy mob
obj/item
obj/tree


All of them now have battle system vars (and procs), but they don't need any! Therefore, people often resort to scheming their design like this: all fightable objects under /mob, rest (or some of the rest) under /obj.

There is the idea of body switching with an NPC, but it doesn't seem quite right giving NPCs the client variable and then having to check each time. (Though I suppose you check anyways.)

If you don't have something like body switching that messes with client.mob's (or have it, say, insignificant, as maybe only a GM power that'd be rarely used or some such), you do have the liberty of not having to validate clients/keys (unless you're about to access a client var/proc of course) and stick to istype(X,/mob/person/player) to see if its a player, and 'else' or istype(X,/mob/person/npc) to see if it's an npc.

I guess another thing, though is that many of the functions should simply be defined for the client only anyways, which again validates the use of mobs as NPCs.

Yes, some, but not all. Battle system stuff? Definitely not, as you do know.

In my opinion, though, using a mob as a training dummy (training dummies are horrible, over-used ideas anyways) or as a store clerk or something seems pointless, as there is no possibility of having a client connected, and various loops that go through players shouldn't be looping through them as well.

Well, regardless of the above if I had something like a training dummy I'd implement it as an /obj, and have the Attack() verb intercept relevant objs and mobs instead of only the latter. But I won't implement that obj into my battle system at all, it will have its own separate, insignificant implementation that is just called by the Attack() function. 
mob/person/verb/Attack(atom/movable/X)
   //...
   if(istype(X,/obj/attackable)
     var/obj/attackable/O = X
     O.Hit(src)
   //...

obj/attackable
   //quite minimalistic, though it could be more as you wish:
   var/hits = 10
   proc/Hit()
     if(!--src.hits) del src
   training_dummy
     hits = 50
     Hit(mob/person/M)
       M.GiveExperience(10)
       ..()


As for the store clerk, since it's an actual person you may want to really define him as one (/mob/person !). First, remember that the language is very flexible (well, you know this part enough) and you are not limited to having an idle, not-apparently-living, not-moving shopkeeper. You could have the shopkeeper move around his shop to display / talk about his wares, you could have him with his own inventory that is accessible after he has been killed ( --> ) you could have him fightable (which now warrants him being a /mob/person), if, say, the player was caught attempting to steal an item, etc.
But, what's more important is if I've answered your question enough, not the potential feature ideas which are not that hard to think of on your own anyway. :P
Aug 25 2008, 4:58 am
In response to Naokohiro
Naokohiro wrote:
Well, what specifically adds to the obj limit?
Just the countless items that you may or may not have in the game? (Armor, potions, scrolls, etc.)

Only the ones that are instantiated. If a given type of obj hasn't actually been created in the game world, then there is no obj to count toward the limit. But if you have 10 scrolls, each one counts. (This is one reason "stacking" systems are popular, where some objs have an internal count.)

Lummox JR