Mob Taxonomy
Goto page Previous  1, 2, 3
 
Post new topic   Reply to topic    mudlab.org Forum Index -> Design
View previous topic :: View next topic  
Author Message
thyrr



Joined: 18 Apr 2006
Posts: 7

PostPosted: Fri May 05, 2006 2:17 pm    Post subject: Reply with quote

You're right about generalizing the code, but I don't think it should be done entirely through attributes. If you had 30 different things that could happen when you eat something, and each could be modified in a dozen ways, you're looking at a lot of code, possibly all stuffed into the on_eat() function. And maybe "exploding" is extremely uncommon; perhaps only loompa-oompas explode in that particular fashion. I don't want to add a body-part-blow-distance=4 and smellslike=duck attribute just to differentiate between normal explosions and loompa-oompa explosions, and an I-am-a-loompa-oompa check in on_eat() is plain ugly and unmaintainable. What's wrong with custom code on the relevant class?

So ideally, if I made smorfs grow magical warts that produce confusion-inducing pus (useable in potions) after eating poisonberries, the code would be localized to smorfs and automatically inherited (or not, according to the rules) by smorf descendents. Maybe there could even be a generic illness-that-produces-magical-body-fluids function that looks at the attributes, and would be attached to the smorf class and the one or two other classes with this odd trait. But it'd be a little silly to have on_eat check for say, "poisonberries:poisonous:warts:confusion:can-be-harvested" and call the code there, IMO. Or even to have a table of effects+callbacks outside the on_eat function.

Now yes, for the numerous common cases, it makes sense to have a centralized table of effects. But for something like sunlight-damage, which pretty much only affects vampires and vampire-lings, it just seems to harken back to the MERC days (or maybe ROM) of flags, flags, and more flags for every custom behavior. Or a table of spec_progs. And there has to be a better way.
Back to top
View user's profile Send private message
Author Message
KaVir



Joined: 11 May 2005
Posts: 565
Location: Munich

PostPosted: Fri May 05, 2006 3:28 pm    Post subject: Reply with quote

Quote:
You're right about generalizing the code, but I don't think it should be done entirely through attributes. If you had 30 different things that could happen when you eat something, and each could be modified in a dozen ways, you're looking at a lot of code, possibly all stuffed into the on_eat() function.


You'll have the same total amount of code regardless. The question is how you want to break it up - and how many times you want to repeat it.

Quote:
And maybe "exploding" is extremely uncommon; perhaps only loompa-oompas explode in that particular fashion.


And what about vampire loompa-oompas? Or what if, in the future, someone wants to add another exploding mob? You're either going to have to go back and change the previous code, or add new code which performs exactly the same functionality as existing code.

This is the sort of thing the design should take into consideration. If you're absolutely certain that no other mobs will ever explode, then sure, overload it. Otherwise you're just you're just limiting your future options.

Quote:
I don't want to add a body-part-blow-distance=4 and smellslike=duck attribute just to differentiate between normal explosions and loompa-oompa explosions,


If those are important factors, why not? Either you have a "smellslike" attribute which you can assign to replace the default, or you have a "smellslike()" method which you overload to replace the default. The amount of effort is the same.

Quote:
and an I-am-a-loompa-oompa check in on_eat() is plain ugly and unmaintainable.


Obviously you wouldn't have that - the on_eat() method doesn't care about the species, only its attributes.

Quote:
What's wrong with custom code on the relevant class?


The three main problems are:

1. It can potentially result in lots of redundant code.

2. Each species has to be specifically handed-coded, leading on to:

3. You can't reliably generate a new species on-the-fly.

Quote:
So ideally, if I made smorfs grow magical warts that produce confusion-inducing pus (useable in potions) after eating poisonberries, the code would be localized to smorfs and automatically inherited (or not, according to the rules) by smorf descendents.


A simple 'create' response, no different from a human producing vomit after drinking too much alcohol. I can't see why it shouldn't be generic, and I certainly wouldn't want to have to hand-code it for each and every species.

Quote:
Now yes, for the numerous common cases, it makes sense to have a centralized table of effects. But for something like sunlight-damage, which pretty much only affects vampires and vampire-lings, it just seems to harken back to the MERC days (or maybe ROM) of flags, flags, and more flags for every custom behavior. Or a table of spec_progs.


I'm afraid I disagree. A vampire gets burnt by sunlight - but so might a shadow beast, a night hag, a cave troll, a black goblin, and so on, yet I don't want to make them all types of vampire. More importantly, even humans can get burnt by sunlight if they're exposed long enough, and the severity varies even further based on their skin type. Wouldn't you rather be able to create a 'vampire orc' and have the code automatically determine on-the-fly that his thick green skin allows him to resist the sunlight better than a human vampire?

From an encapsulation perspective, this information can be handled equally well with my property approach as it can with your overloaded method approach. The difference is that your approach requires the same code to be added for each case (the vampire, the shadow beast, the night hag, the cave troll and the black goblin will each need to overload the exposedToSunlight() method and include the same code), and because the code is added for each case you'll have to code each species (and species combination) by hand.
Back to top
View user's profile Send private message Visit poster's website
Author Message
thyrr



Joined: 18 Apr 2006
Posts: 7

PostPosted: Fri May 05, 2006 3:51 pm    Post subject: Reply with quote

Quote:
From an encapsulation perspective, this information can be handled equally well with my property approach as it can with your overloaded method approach. The difference is that your approach requires the same code to be added for each case (the vampire, the shadow beast, the night hag, the cave troll and the black goblin will each need to overload the exposedToSunlight() method and include the same code), and because the code is added for each case you'll have to code each species (and species combination) by hand.


It wouldn't exactly be overloading, because the standard OO overloading mechanisms are pretty much all-or-nothing. You would have a base class for things-annoyed-by-sunlight and drill down the specifics without rewriting code. Probably with hooks. It would not necessarily require hand-coding if designed properly, although I'm not really up for that right now. They're essentially properties, but the code for dealing with it is attached to the properties and classes, not scattered throughout the code. You do have a point in that overriding is messy, but that's perhaps more a symptom of current programming language design.

I don't really like either method.

Quote:
Wouldn't you rather be able to create a 'vampire orc' and have the code automatically determine on-the-fly that his thick green skin allows him to resist the sunlight better than a human vampire?


Well, I'd rather have an absorbSunlight() method attached to GreenSkin called by exposedToSunlight(), but I guess one thing the properties has going for it is that you can easily mix and randomize numbers. If your game is all about numbers, or you want to be able to combine green and yellow and end up with completely different attributes, then I guess that works. But if you want complex behaviors, I'm not sure it's good to keep it all centralized.
Back to top
View user's profile Send private message
Author Message
KaVir



Joined: 11 May 2005
Posts: 565
Location: Munich

PostPosted: Fri May 05, 2006 6:29 pm    Post subject: Reply with quote

Quote:
It wouldn't exactly be overloading, because the standard OO overloading mechanisms are pretty much all-or-nothing.


I'm not sure what you mean by that. Can you please elaborate?

Quote:
You would have a base class for things-annoyed-by-sunlight and drill down the specifics without rewriting code. Probably with hooks. It would not necessarily require hand-coding if designed properly, although I'm not really up for that right now. They're essentially properties, but the code for dealing with it is attached to the properties and classes, not scattered throughout the code.


Hmmm, but how is that different from my proposal?

Quote:
You do have a point in that overriding is messy, but that's perhaps more a symptom of current programming language design.


I don't have a problem with overloading - I use it quite a lot myself. I just don't feel it's appropriate for certain situations, and feel that this is one of those situations.

Quote:
Well, I'd rather have an absorbSunlight() method attached to GreenSkin called by exposedToSunlight(), but I guess one thing the properties has going for it is that you can easily mix and randomize numbers. If your game is all about numbers, or you want to be able to combine green and yellow and end up with completely different attributes, then I guess that works.


Any mud with an interest in this sort of detail is likely to be about numbers, even if those numbers aren't presented as such.

And yes, mixing colours could also be a possible advantage. For example skin colour could be represented by an RGB value and an intensity. When you want to combine two creatures, you'd take the average of each of their red/green/blue colours, weighed according to intensity.

Thus a vampire might have completely white skin with a low intensity. A human vampire would get a bit paler, an orc vampire would become a lighter green, a drow vampire would become dark gray, and so on. A werewolf on the other hand would have no intensity at all, meaning that whatever it merged with would retain its original skin colour. A blood demon might have top intensity, so that anything merging with it would suddenly get bright red skin.

The really nice thing about the solution is that it's generic; you don't need to hand-code a vampire version of each species. Better yet, you could apply the exact same system to all sorts of other racial hybrids - you wouldn't need to create a half-orc species, for example, as the mud could generate it for you. And quarter-orc? Seven-eighths-orc? Not worth the hassle for most muds to implement, but this system would support it by default, without any additional coding effort required.

Ever wished you could have an 'animate dead' spell which created a zombie or skeleton version of whichever mob it was cast on? Not a problem with this system - you simply merge the creature's current species with the appropriate undead species.

Quote:
But if you want complex behaviors, I'm not sure it's good to keep it all centralized.


If you want non-unique behaviors, then I believe it is. My proposal could provide exactly the same level of complexity as yours, but it does a better job of dealing with default behaviors.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Kjartan



Joined: 13 May 2005
Posts: 110

PostPosted: Fri May 05, 2006 7:53 pm    Post subject: Reply with quote

I suspect that the lion's share of the effort of implementing generic mix-and-match mobs is independent of whether it's done via inheritance or not: you have to figure out how to mix each trait, and what has precedence over what. KaVir's color-mixing example illustrates this: he had to think up a fairly complicated system just to cover one trait. Imagine the effort in coming up with a mixing system for every single possible characteristic of mobs! And yet, to actually mix mobs, this is what would be needed.

I think maybe there's not much call for it, because while there's a very large number of base mobs you might want to mix things in to, the number of things to mix in is much smaller. Nobody wants a half-wolf-half-bull; it's just not a compelling mob, it's too random. (Although it would be called the "bulf".) One of the pieces needs to be something with a lot of social weight, like a human or a dragon or a demon. I like the D20 approach of templates: have a zillion base mobs, and some templates for mixing in "half" or "a little bit" of various important things like demon, angel, dragon. Then all you really have to design for the system to work is the templates.

I think that vampire and werewolf are not best treated as mixtures, they would be much better handled as something like D20 templates. You can't really have a pure vampire that isn't part something else; "vampiric" isn't associated with a complete set of traits, for example there is no characteristic number of eyes. (But I guess you could use KaVir's intensity system and just put the intensity of its number of eyes at zero, and add the requirement that any legal mixture must have some nonzero intensity for every trait from one or the other piece).
Back to top
View user's profile Send private message Visit poster's website
Author Message
thyrr



Joined: 18 Apr 2006
Posts: 7

PostPosted: Fri May 05, 2006 11:02 pm    Post subject: Reply with quote

Quote:
Quote:
Quote:
It wouldn't exactly be overloading, because the standard OO overloading mechanisms are pretty much all-or-nothing.



I'm not sure what you mean by that. Can you please elaborate?


I mean that if you have a vampire class and a Superguy class (who gains his power from the yellow-green sun), standard multiple inheritance would force you to pick one behavior. If you had multiple dispatch, you could execute both exposedToSunlight() methods from the vampire and Superguy. That could make for some interesting behavior, actually -- a vampire with super-strength and laser-beam eyes in the sunlight, but constantly takes damage.

You could of course make laser-eyes another flag to check off when you're creating a new species. I guess maybe where our opinions diverge is that I'd like to make traits fairly unique to each base species.
Back to top
View user's profile Send private message
Author Message
Vopisk



Joined: 22 Aug 2005
Posts: 99
Location: Golden Valley, Arizona, USA

PostPosted: Mon May 08, 2006 4:23 am    Post subject: Reply with quote

thyrr wrote:
Quote:
Quote:
Quote:
It wouldn't exactly be overloading, because the standard OO overloading mechanisms are pretty much all-or-nothing.



I'm not sure what you mean by that. Can you please elaborate?


I mean that if you have a vampire class and a Superguy class (who gains his power from the yellow-green sun), standard multiple inheritance would force you to pick one behavior. If you had multiple dispatch, you could execute both exposedToSunlight() methods from the vampire and Superguy. That could make for some interesting behavior, actually -- a vampire with super-strength and laser-beam eyes in the sunlight, but constantly takes damage.

You could of course make laser-eyes another flag to check off when you're creating a new species. I guess maybe where our opinions diverge is that I'd like to make traits fairly unique to each base species.


I think making laser-eyes and super-strength seperate abilities was exactly what KaVir's system proposed. With priorities and blocking, you could have all three blend seamlessly together with ease. Exposed_To_Sunlight() would give the SuperVampGuy str +5, laserbeam eyes attack but 5%/tck damage from sunlight. It's all a matter of how you design things to work together. If you want Sunlight Allergies to block everything and automatically override, then you would give it highest priority and make it blocking, therefore, no other affects, for good or ill could be applied from the exposed_to_sunlight() call from the entering room instance.

I think I got it right that time, thanks to Shasarak making the OO make a little bit more sense than it did previously.

You mentioned a few times a call back to the old days when everything was flags but that is exactly what this system is designed to eradicate and prevent. In this instance, we're NOT giving every mobile a boolean true or false for everything that could possibly happen, we're saying this GenericMOB does absolutely nothing, he just has health but is really just a gelatinous cube in form and ability. But, we're going to give him human traits mixed in with orc traits, meaning that a call to exposed_to_sunlight() would do absolutely nothing with our Half-Orc Human, rather than having the room check to see whether or not the player has AllergicToSunlight toggled on or off.

The same would go with the blueberry code, the blueberry itself would not check to see if it is poisonous to whoever ate it, whoever ate it would check if THEY are allergic to it.

Please, correct me if I'm going off on the wrong tangent here again, but I think that's what we're talking about...

Vopisk
Back to top
View user's profile Send private message AIM Address MSN Messenger
Author Message
thyrr



Joined: 18 Apr 2006
Posts: 7

PostPosted: Mon May 08, 2006 11:43 am    Post subject: Reply with quote

Well, this topic *is* called Mob Taxonomy, which I suppose by definition of "taxonomy" should be about using attributes/flags to describe traits. So we're probably slightly off-topic anyway.

I use the term "flags" in a broad sense: if you have an attribute like damageFromSunlight=20, you're describing the behavior in a rigid numerical way, and somewhere you're going to have to write a check that says if(npc.damageFromSunlight) etc. Kavir's system is not particularly object oriented (whether that's good or bad is up for debate.)

So you'd have something like
Code:

class MOB {
  void exposedToSunlight(intensity) {
    if(damageFromSunlight)
        if(shade && halfDamageInShade) damage(intensity * damageFromSunlight / shade);
        else damage(intensity * damageFromSunlight);
    if(laserEyeVision) vaporizeEveryoneNearby(laserEyeStrength);
  }
}


An object-oriented approach would be more like:
Code:

class BaseMOB { void exposedToSunlight(intensity) { // do nothing } }
class Vampire inherits from BaseMOB {
  void exposedToSunlight(int intensity) {
    if(shade) damage(intensity * 20 / shade);
    else damage(intensity * 30);
  }
}
class SuperGuy inherits from BaseMOB {
  void exposedToSunlight(intensity) {
    vaporizeEveryoneNearby();
  }
}
dynamic class SuperVampGuy inherits from SuperGuy, Vampire {
  // this class would be generated on-the-fly
  void exposedToSunlight(intensity) {
    Vampire.exposedToSunlight();
    SuperGuy.exposedToSunlight();
  }
}


Generic MOB + flags/attribute approach:
Pros: Easy to mix numbers, e.g. a 34.7% vampire might have 23% vuln sunlight.
Cons: Custom mobs are a pain.

Object-oriented approach:
Pros: Clean separation of different behaviors.
Cons: Mixing attributes is a pain.

So if you want your game to have all sorts of hybrid creatures and random traits, then flags/attributes are the way to go. Custom behavior works better with OO though. But if you want something in between, I'd still want more of an OO/inheritance approach. It could be something like:
Code:

class Solarphobic inherits from BaseTrait {
  int severity;
  exposedToSunlight(intensity) { // do stuff }
}
class YellowSunUberism inherits from BaseTrait {
  int severity;
  exposedToSunlight(intensity) { // do stuff }
}
dynamic class SuperVampGuy {
  traits = YellowSunUberism(33%), Solarphobic(10%);
}


Also, the functions don't have to be so specific. If you wanted a creature that goes insane when it hears a N'Sync song:
Code:

class CantStandMusic inherits from SoundEventFilter {
  string hatedArtist;
  on_sound (sound) {
     if(sound subclassof Music && sound.song.artist = hatedArtist) goInsane();
  }
}


So by making the event very general and leaving the specifics to subclasses, you can have reusable custom behavior without stuffing it all in one big MOB class or scattered around like in putting it in the Room class. Furthermore, if you had a dynamic hybrid mob generation system, and only FailureTheMusicCritic happens to have a trait as esoteric as going insane on hearing music, you could put the CantStandMusic code in FailureTheMusicCritic.c file and leave it blissfully separate from the rest of the world. On the other hand, dynamic subclassing with multiple inheritance can be pretty hard to do in practice -- by the way, you'd probably want to use prototypes a la Self or Javascript if you're doing any dynamic class stuff, and even then it's a huge mess.

So isn't this just "flags" spun off into their own objects? The key thing is that the flags are code objects, not simple numerical attributes, and can be subclassed. So if you want a bunch of mobs to become itchy in sunlight, you subclass the existing effect and use the new ItchyInSunlight trait where you want it. You also take a very general event filter, like on_sound or on_light, and handle specific cases on subclasses.

Now for an equally challenging task, how about componentizing things like effects? Imagine hearing a loud BOOM that gives you a temporary deafness. It could accomplish this, rather than by checking isDeaf(), but by installing an event filter that stops sound events from reaching the player's on_sound. Or a poison blade event filter that attaches itself to on_hit and applies the poison, rather than having the the blade check if it's poisoned? And if you have a Chainmail of Resist Poison, a resist-poison filter on the apply-effect event would reduce the severity. And then the poison would install an on_tick filter on the victim to do damage every tick.

When you localize the poison code to the poison class, none of the code for dealing damage or the armour or the character's tick function have to know anything about what "poison" is. If you had a similar "nanobots" snippet or were adding poison for the first time, you'd just include the file -- you wouldn't have to touch any of that other code. This is called aspect-oriented programming, although you'd want to do it explicitly designed into your MUD rather than as a hackish afterthought that many AOP solutions try to do (dynamic bytecode injection, intercepting arbitrary function calls by regular expressions, other black-hat voodoo kind of stuff.)

I think you can apply the same concepts to mob traits, e.g. you just stick the poison resistance trait on the mob. Or make subclass the trait to only resist certain types of poison. For something as low-level like this, there's not much difference between trait:resist-poison:types=ivy,spider and resist-spider-poison + resist-ivy-poison; in fact, it'd be kind of silly to create a new class for every kind of poison. I don't know if you could get away with resist-X though, and if you start adding conditions like only-after-X-minutes-in-the-sun and only-if-full-stomach, etc, it gets messy to do things exclusively through attributes.

But I should point out that going for the simplest way, if not the prettiest or most powerful way, will get you fairly far. You have to think about what kind of MUD you're writing and how far you're going to customize things. With MERC/ROM, you have a list of damage types like slash, blunt, psychic, etc, and things can be vuln/res against any or all of those types. But there's really no difference between them -- they're handled through a very generic piece of code, with a only couple small exceptions that people bothered to add in. You might as well say that your armour is weak against "attack #2" but strong against "attack #5" and it wouldn't make a difference if they were called "slice" and "headbutt", although you DO want to watch out for "bash" because it might stun you -- rare piece of special coding there. Now imagine if all of them were unique, and furthermore you could customize how certain types of mobs were affected by each damage type, again in unique ways.
Back to top
View user's profile Send private message
Author Message
Massaria



Joined: 14 May 2005
Posts: 31
Location: Denmark

PostPosted: Wed May 10, 2006 3:22 pm    Post subject: Reply with quote

Spurred on by this and other threads, I’ve been considering how to mix together a system of mutating mobs/characters and a combat system that has strategic elements while still being automated (no action needed during).

It’s far more simplitic than what I had in mind to start with, but I’d like to get this on the thread while rigor mortis is still present. As I think, and write, about this, I’m seeing a strategy game, whether graphic or not – but not really close to any mud I’ve seen. Still I believe there might be something in it for a mud’ish system.

There would be a number of basic animal types, templates if you will, and these would form the basis of any player’s “breeding program” (the players, naturally, are dreadful aliens who breed creatures for sport or war).
This list of animals probably shouldn’t be very long, perhaps no longer than:
    - Primate
    - Quardroped
      Horse
      Lion
      Goat

    - Mollusk
    - Crustacea
    - Insecta
    - Aves
    - Reptilia


Now all animals (in this system), have at least two parts, but usually three: Head, Body and Tail. The player starts by choosing two animals to form the stem of his pedigree. Half of it, anyway, as the result of those two could be coupled with the result of two other basic forms, or a pure form, or perhaps even itself (in which case the alien sports manager has decided that this particular animal is fit for mass-production. Just in time for the first batch to mature before the next game. Whew).

The basic forms would need information such as:
    - Name
    - Head (type)
    - # Body segments / # supporting segments
    - Limbs on each segment (type)
    - Tail (type)


Thus, a horse would read:

    - Horse
    - Grazer
    - 2/2
    - 2 * Legs = 4
    - Flyswatter


With each trait that might carry over to a new animal, there would be a ‘dominance rating’, which would indicate the likelyhood of that trait being passed on (when matched against the rating of the other parent, if that parent has the trait at all)

The types of head (predator, grazer, nibler, piercing, …), would have different biting-capability, perhaps affect a diet (thereby maintenance), but otherwise have little impact. Their one big point might be that biting is a very powerful, piercing attack on organs which most other natural attacks cannot hope to equal. See below on types of damage.

Tails would probably play an even lesser part, with most results of the ‘flyswatter’ type, but a scorpion’s tail might be interesting, and tail-feathers a necesity for decent flight-capability.

Then, if two animals were to cross, they would simply produce a head and a tail based on the dominance rating of that trait in the parents. The segmented body (two limbs to each segment. A human has two segments, four limbs – so does a horse or bird), would also produce results based on dominance (I’m thinking that pairing up the limbs will make life easier, so no left lion-paw and right chicken-wing), but if we introduce a couple of variations we might have the groundwork for a strategic set-up. We might say that sometimes, the segment is left completely limb-less, that both pair of limbs from the parents are present in the same segment (one pair growing from the back, like an angel (wings+arms)), or we might <em>add</em> a new segment. Thus we’d grow centaurs, driders and basillisks (in some traditions).
The addition of a new segment should be a rare and prized event, as it will obviously allow for more attacks, or a more secure footing, during fights. To keep things from growing too fantastic, there would be a rule to the effect of needing at least half your segments for support, if the remaining half should remain at full capacity – imbalances in this regard might lead to penalties and immobilization.

The players would probably end up with creatures that are pretty hopeless more frequently than not, but that’s alright, because that would be a major part of it all: To weed out the undesired and culture the powerful.

The combat that I’ve considered is quite unsubstantial, and, I believe, better fitted for a mud than the large-scale battles of a war-game.
In a one-on-one fight, I imagine two L-shapes (back-to-back: _| |_ ) of arbitrary length in both height and width, but always proportional: The height of the “L” never longer than the width. The width of the “L” is the supporting segments of the animal, and the height represents the segments that are free to do combat.
Each pair of limbs would attack once (possibly parry once too), at the limb directly in front of it (default) or perhaps out of criteria set before the fight (e.g. attack pinchers before paws). Limbs would have reach too; a simple 0-3 number which represents the number of segments that that limb can reach (a limb in segment 3 with a reach of 2 could attack segments 1 through 5 on a foe of equal length (segment 1 = first after head, thus segment 3 would be the hind legs of a centaur).
Limbs could be associated with additional effects upon successful attacks, like pinning a limb (squid tentacle), poison/irritant, continual (most bites), etc.
If limbs grew in dominance over time (a creature who’s ancestors has had the scorpion’s tail for 10 generations, would be more likely to impart that characteristic to the offspring than a tail with a 5th generation history), some creatures will naturally become more disirable and might earn the owner large sums for breeding or selling it.
In the plans for my mud, I’m trying to make a destinction between loss of blood and fatigue on one side, and tissue damage on the other (flayed muscle, broken bone, pierced vital organs), but a simple implementation of Hit Points would probably be to prefer here, allowing severance and incapacitation of limbs, possibly whole segments (collapsing any segments resting on that segment, forcing the foe to ‘come down a notch’ and incurring manoeuvring penalties).

As vague as this sounds, it can get worse. I’m still missing a good way of doing size, and thereby speed (I’m sure I’m missing a lot of other things too, but these worry me the most). While having a measure of limb size would be nice, it’s a distant feature even if a proper system for total mass is done. I’d rather like if there’d be something to the idea of breeding a horde of smaller creatures at a low individual cost, and have them effectively gang up on larger types of animals. That would add invaluably variation to the strategies at hand, but it’s so damn hard to account for the relative mass between two combatants.

I’d like to divide damage into the three standard categories (Slash/Piercing/Bludgeoning). Not because I want to make armor/weapon penetration values (but that would be nice too), but moreso because they represent different kinds of damage to an organism.
Of course, by doing this, I’m moving away from the standard HP system, where only one factor determines if a limb or creature can function (how many HPs it’s got left).
As hinted above, there’d be a distinction between the structural integrity of a limb/creature, and the ‘vitality’ or energy left in the organism. Hit Points, therefore, could be seen as an arbitrary measure of the blood or energy left in the organism, while Structural Integrity Points would represent the state of the foundation through which this energy flows.
The aim, naturally, is to have the three types of damage do different amounts of damage against HP and SIP.
While HP would be more of an over-all measure of the creature’s state, SIP would be used to measure if individual limbs are working – allowing us to penalize the cripple justly, to the extend of collapsing the structure and life functions completely.
Piercing damage would be a fairly rare occurrence, limited to bites only (I can’t think of any animal who actively uses a piercing technique for attack or defense (discounting passive defences, such a the spikes of a porchupine (and bites, obviously)), even horns seem to be used as a butting force rather than to penetrate flesh). It would cause significant organ/HP damage, and may occasionally hit a bone (SIP-dam), but usually won’t.
Slashing damage would be much more normal, inflicting a roughly even amount of damage to HP and SIP.
Bludgeoning force seems prevalent in the natural world, and inflicts a lot of structural damage, but has little effect on energy levels.

Hm. I think that’s most of it.
Sorry if it came out all jumbled up, but it’s my two cents, something to choke on Wink

Mass.

PS: Found your post very informative thyrr, but it's a bit too techy for me to have anything to add.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    mudlab.org Forum Index -> Design All times are GMT
Goto page Previous  1, 2, 3
Page 3 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2001, 2002 phpBB Group
BBTech Template by © 2003-04 MDesign