Here is yet another (verbose) idea listing that I've been working on. I hope that this will either stir up some discussion/debate or actually incite coders to get to work on changes :) I personally am interested in seeing 'learning mobs' and will write up pseudo-code for it if there is anyone seriously interested in tackling it (nope, I don't code in C *yet*, but ~5 years of programming in Turbopascal should allow me to do most of the logic and details work for a C coder to work from with minimal effort). Anyhow, here it is... Enjoy! Some ideas I've had on how to deal with some of the trouble that CHARMed MOBs and pets cause, as well as some nice mods for them both... Have the CHARM spell also make the MOB act wimpy while charmed; have the spell "broken" if the MOB does ever flee. Alternatively, give the mob an 'Intelligence check' to see if the spell breaks - this'll give the MOB about a 55% chance(with the "base" 11 stats) to break the spell - which is a bit more "mage friendly". See the 'charm vengence' note below... Make charmed mobs and pets automatically ASSIST their master when their master is in battle (unless the follower is resting/ sitting/sleeping, of course). Be sure that this only works for the duration of the charm, and not simply because they are followers of a PC. If the MOB has MEMORY, then when the charm spell runs out the MOB should have a chance to "remember" the person that has subjected them to slavery and forced combat. This chance could be based on MOB and player levs, or simply be a set chance. The "memory" would work by putting the players name/whatever (I'm a architect, not a coder...yet) into the MOBs memory (replacing/bumping off others if need be). This would make it less clever to have a whole platoon of cityguards with you (though I think that I may have made them anti-charm by giving them a CHARM flag to start with...) in hopes that they'll stick around and help you kill evil things even after the charm runs out (heh..if you think that trick is good, you haven't heard half of 'em!). Don't allow charmed mobs to either change in alignment or affect another mobs alignment. Pets affecting other mobs alignments can be abused...and sense charmed mobs are basically mindless slaves, they really don't _have_ a true alignemnt beyond neutral. Doing what the master orders is basic training, not a thoughtful attack, and therefore shouldn't affect alignment IMO. Likewise, no mob is going to aggressively attack another mob, so the attacker shouldn't be "penalized" alignment-wise for self-defense. Heck, mob alignment changes due to killing something else as a whole seems a bit shaky, and perhaps could be junked... Pet Items - currently in circle code pets cannot get/be given any items. Implementing a PET_ITEM object flag could add a bit of flavor to the mud, as well as providing yet-another outlet for the players money. 'Pets', for this purpose, will be considered any mob that has IS_CARRYING_W set to 1000 and and IS_CARRYING_N set to 100 (which the pet shop proc does automatically). Only pets will be able to wear these PET_ITEMs, though they still will not be able to pick up these items - being given the item is OK (will require a couple of additions to the GIVE and related procedures, possibly allowing for NOT adding the PET_ITEM to the total weight/items carried). These items could be such things as some types of barding or additional weapons (such as metal claws, which could either be 'worn on hands' to add damage or wielded as a weapon, depending on how you want to build the items themselves - though the natural weapons may be better in some cases; the PCs won't know...). non-pets loaded with this armor on should also be possible (ie, the were 'E'quiped with it by the .zon file upon loading). Unless you want to implement mob types - humanoid, quadraped, blob, flying, etc - then this is the best way I see to handle allowing armor and weapons to be used by pets (though it does leave out "charmed" mobs, I can't see a good compromise - a charmed Cityguard shouldn't wear Leather barding and wield metal claw extenders, while a charmed fido could... it's easier just to settle on pets, which have the distinctive 'full' setting - also, currently the charmed fido could end up wielding a long sword and wearing full leather armor, so.... ;) Modify the Pet Shop to actually deal with supplies - ie, randomly generate the number of each type of pet present to be sold at start-up (based inversly on mob exp, so there are fewer wolves, more kittens) and allow for a random "replenishing" of stock weekly by 0-3 new pets of each kind, never exceeding some set maximum number of each kind. This would keep players from having huge "kitten trains" following them in an attempt to simply out-fodder and brute-force a mob to death, as players wouldn't always be able to buy up all that they can afford... Could even have the ratio of pet-price:pet-exp raise from the standard 3:1 when supplies begin to run low (like when only 15% of max number are available) Alternatively, limit players to a certain number of pets at one time, giving the players a random bit of appropriate sagely advice from the petshop owner (ie, "Them kittens just play too much to be any good in a fight if ya has more than 5 of them together... " or "Didn'tcha know that when ya get that many canines together all they do is bark and fight with each other... "). Dealing with the business of MOBs and experience is rather tricky IMO. My interpretation of experience points in Diku is "knowledge and skills gained through some course of action, and the further refinement of such" (yeah, not the most clear def., but it's the best I can put into a short statement ;). Thus, at least upon first examination, it seems to me that a MOB *should* earn experience in a fight; however, MOBs cannot advance levels, so they really are not becoming harder to kill due to this increase in "knowledge and skills". (I'd love to see a mud that had mobs that could learn! Hell, that'd probably even work as a great justification for having the MUD running on a University machine [No Mr. Root, it's not a MUD - it's a human-aided machine learning simulation I'm working on; those people logging in to port 4000 are my research assistants] ;) Therefore, short of keeping track of a MOBs original Exp Value and granting it hitpoint and toHit bonuses based on what percentage of their original Exp they'd gained (hmm...the more I think about it, the more I want to see it in action!!), then there is little reason to pass on the exp that a fido gained from killing Joe the Spell-less to Bob the Sword Dropper who later kills the same fido. With no reason to pass it on, there is no reason to even mark it in the first place by adding it to the MOBs exp. -- Getting to the point.... Charmed MOBs/pets help out in battle, both through attacking for and often taking the hits for their master. This, unto itself, is a great boon to anyone lacking a group, or simply light on firepower/cannon-fodder. However, the general attitude that players take is that they should also be able to gain more exp than they normally would by "splitting" a tough kill with a pet and then later killing it for at least a percentage of the exp that the pet earned. IMO, a wolf that has helped kill 20 cityguards but is just as easy for a player to kill as an un-blooded wolf should be worth the same amount of experience. Several ways to handle this come to mind: * Make mobs 'transparent' to exp gains - they simply do not gain exp from fighting. If loyal to a PC, they will automatically ASSIST the PC in battle or attack on command, but they will stop attacking when their victim is within 2 average-dam rolls (from the attacking, charmed mob - basically they are trained to stop just short of killing something) from death (or maybe just when victim is at 5% of their max hp). If the mob is being attacked by the victim at this time they could either flee or simply sit still and take the hits until their master kills the victim. See the notes on "pets" fleeing above. * Again, prevent mobs from earning exp, but instead of having loyal mobs stop attacking, allow them to keep attacking even if it will kill the victim. If the mob is grouped with their master (who *should* be in the same room at least, if not also fighting!) then the kill is split amoung the group with a share subtracted for the pet (include the pet's lev in the total if exp division is level based, but never actually credit the pet with any exp - simply provide a bit less to the players to reflect the added ease of the kill), though if the pet actually delivers the 'killing blow' do NOT figure in a bonus share for this! (I'm not entirely sure that the actual "killer" gets extra exp compared to the group, but if so the "pet" should not get this; ie, extra should not be subtracted just because the pet made the kill - it should be just the same split as if someone else made the kill...I hope at least *someone* can follow what I mean!) * Add a 'exp gained' field to all mobs. Any exp earned by a mob for fighting be added into this field (exp lost for fleeing should perhaps be subtracted from the field, though at a slower rate...not sure, as subtracting may make it too complex). As the ratio of 'earned exp' to 'base exp' increases the mob will gain HPs up to their max (ie, max for 2d5+45 is 55), slowly gain damage up to +their lev (ie, a lev 9 mob could end up going from 4d3+2 damage to 4d3+9 damage, at a slow rate), or gain thAC0 (not sure where to max this one out; I only really forsee a few bonuses to thAC0 and Damage, while most go towards increasing the mobs HP to their max lev, and perhaps a *little* beyond in extreme cases). Killing such a mob will grant you the original exp plus some percentage of the mob's "earned exp" (as in this case they actuall have to work harder to kill the mob). Charmed mobs/pets should gain "earned exp" slower IMO, simply to reflect that they are primarily following orders. Lemme know if you want more ideas/details on something I said here, or if I seem to have left something out... Danny +---------------------------------------> | Danhiel Baker // Derkhil CatSpawn /) /) Fade away | dbaker@harpo.dev.uga.edu ( o o ) into the | dbaker@jb.ucns.uga.edu = x = ethereal grey... | Work: 542-0123 Pager: 369-2781 m m +--------------------------------> ***(=======-
This archive was generated by hypermail 2b30 : 12/07/00 PST