Creature properties

 
Post new topic   Reply to topic    mudlab.org Forum Index -> Design
View previous topic :: View next topic  
Author Message
KaVir



Joined: 11 May 2005
Posts: 565
Location: Munich

PostPosted: Fri May 04, 2007 3:12 pm    Post subject: Creature properties Reply with quote

While designing quests, I've come to realise that I need a way to identify certain creature properties - for example if you're supposed to cut the still-beating hearts from five beastmen, I need an easy way to know which mobs are classified as "beastmen", which would include creatures such as minotaurs, centaurs, harpies, and so on.

The approach I've been considering is to give each creature a properties object which can contain zero or more property flags that are generally initialised upon creation. Some examples of properties might be:

Human, Goblinoid, Giant, Animal, Centaur, Fish, Bird, Elemental, Insect/Arachnid, Beastman, Ogre, Troll, Demon, Undead, Construct, Snake, Dragon, Lizard, Fire, Air, Earth, Water, Mind, Flesh, Clay, Wood, Stone, Iron

Thus a fire elemental would store the "Elemental" and "Fire" properties, while an iron golem would store the "Construct" and "Iron" properties. As less obvious examples, a treant might store the "Elemental" and "Wood" properties, while a phoenix might store the "Elemental", "Bird" and "Fire" properties.

The quest to kill 5 beastmen could then simply specify 5 creatures with the "Beastman" property. Equally, a quest which involves killing the 4 elemental lords might require you to kill one creature with the "Fire", "Elemental" and "Boss" property, one with the "Water", "Elemental" and "Boss" properity, and so on.

The same properties could also be used for other things - for example a "heat metal" spell might only work on creatures with the "Iron" property, while a "warp wood" spell might only affect those with the "Wood" property. A "sword of dragon slaying" would work on all colours of dragon, a "shield of undead protection" would work against all types of undead, and I wouldn't want to the poor dracolich who had to face someone armed with both.

Certain properties could be automatically applied based on the shape of the creature (eg a werewolf transformed into a wolf would get the 'Animal' property), but others would need to be defined explicitly - for example a fire elemental might have a 'Mindless' property, but a mage who transformed into a fire elemental still retain his mind, and thus wouldn't get the property. As I don't explicitly have races, this would also allow me to differentiate between (for example) giants and dwarves, both of which have a humanoid shape.

The idea of properties was also discussed in the Mob Taxonomy thread, but this system isn't intended as an alternative - it's designed to work alongside something similar to what was being discussed there, incorporating data which isn't specific to a single race. Thus I could distinguish between two otherwise-identical creatures without having to add new races, as well as group different races into the same category for certain purposes.

As the number of possible properties is practically limitless, I was considering just adding them as needed - for example adding the 'metal' property when I create a 'heat metal' spell, or a 'beastman' property when I create the beastman quest. The major drawback is that this would require me to add it to each monster file every time I create a new property, although I suppose some of the properties could be automatically tied to body shapes by default (eg all centaurs and minotaurs might automatically get the property).

How have other people handled this sort of thing? If you wanted to have a quest which required you to slay 5 dragons, how would you define 'dragon' for the purposes of the quest, so as to include all colours as well as dracolich, wyvern, etc? If you had a 'heat metal' spell, how would you determine which mobs could be affected?
Back to top
View user's profile Send private message Visit poster's website
Author Message
ide



Joined: 21 Feb 2006
Posts: 105
Location: Seattle

PostPosted: Sun May 06, 2007 11:06 pm    Post subject: Reply with quote

Quote:
If you wanted to have a quest which required you to slay 5 dragons, how would you define 'dragon' for the purposes of the quest, so as to include all colours as well as dracolich, wyvern, etc?


I've been mulling this over for a couple of days. I don't know if this is an issue with GW2 but the main question I'm having is not how would you define 'dragon' (for it seems like the most suitable definition of 'dragon' is 'I know it when I see it' in this instance...that is you just add the dragon property to the creature you want to have the dragon property), but how would builders go about creating new creatures so that they fit into the system.

As I said I don't know how creature creation works in GW 2 but I suspect it's done basically the same as in ROM, i.e. hand crafted, and the developer chooses the body form for the mob (whereas in ROM you choose a race type usually). With a property system you also would need to apply the appropriate properties (unless you used a template system?), but more importantly you would need to know which properties to apply.

This may sound trivial but I'm sure some of you know what a mess huge long lists of properties, objects, mobs, etc. can become. Look at most muds and you have to ask yourself, why do we need 20 different kinds of 'cloak' objects when it would be perfectly suitable to have just one cloak object we can reset at will? It's because each builder created their own cloak object and didn't bother trying to find an old one that would work. In addition there are other problems with using objects from old zones in new zones, but I don't think that's normally why builders don't reuse objects.

OK, that was something of a tangent. The point being that there should be an effective way to manage properties. With this in mind it might be a good idea to apply the taxonomy idea to properties as well, so you could have trunk categories for properties, which could then branch out into property trees merely for the purpose of organization (so not for inheritance, that is). I don't know if this will encourage developers to use these trees, but it will make it easier, and that's something.

The second thought I had about this was that while some quests will work just fine to say, 'bring me the heart of 4 elemental lords', many quests are fun because they say instead, 'bring me the heart of Fingelbor Lord of Fire, Phaidowyr Lord of the Sea, Aeleron Lord of the Air, and Burngiwyl Lord of the Earth', etc. However this should be quite easy with a property system, the game just needs to run through the available mobs with the element + boss properties, make sure they're in the game (or reset them when the player accepts the quest), and you're off. The point here simply that players should get the higher level report from the game that uses names and so on.

In this respect (and to go off on a tangent again) if you want to make quests that make a little more sense it might be good to have some kind of relations between properties. For example you could have a quest, kill 10 enemies of the elves. You could then define that the elf property is an enemy of orcs, trolls, ogres, etc., or if you want define them separately, so that elf enemy is a separate property itself -- this would be more work but could be a bit cooler, with for example some troll tribes that are enemies, neutral, or even friendly. On the other hand it might be a better idea to make relations totally separate if you want them to evolve dynamically. Just thinking out loud.
Back to top
View user's profile Send private message Send e-mail
Author Message
Vopisk



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

PostPosted: Mon May 07, 2007 3:11 am    Post subject: Reply with quote

ide wrote:
In this respect (and to go off on a tangent again) if you want to make quests that make a little more sense it might be good to have some kind of relations between properties. For example you could have a quest, kill 10 enemies of the elves. You could then define that the elf property is an enemy of orcs, trolls, ogres, etc., or if you want define them separately, so that elf enemy is a separate property itself -- this would be more work but could be a bit cooler, with for example some troll tribes that are enemies, neutral, or even friendly. On the other hand it might be a better idea to make relations totally separate if you want them to evolve dynamically. Just thinking out loud.


Well, seeing as the original suggestion was to keep these "properties" stored as basically a list of flags, I see no reason why they couldn't evolve dynamically even as they are. You could set up something pretty generic like "<race> <enemy/ally>" and then go from there. So, if the bargaining didn't go well, now all of a sudden, that whole tribe of orcs just became the enemies of the elves, but over time, they might slowly drift towards neutral (losing the flag all together, thereby giving them no important signifigance) and over time, they might gain the elf ally flag.

Things get a little bit more tricky if you're wanting to address specific groups of people, like: You are a friend of the Llanowar Elves. If you have to keep a flag for each tribe/organization of elves or otherwise that you're friends with, then things could get costly. However, I imagine that you could make the flag a structure actually so you would have the "Elf Ally" flag, which denotes you as an ally of the elves, but that structure would also have an "organizations" variable (of type array, vector, dictionary, whatever) that could report that you were only the friend of the Llanowar and Silvertree Elves and no others. This would also allow you the distinct ability to also have the Elf Enemy flag if you had previously pissed off a separate group of elves.

I guess it's a bit like the way I view all things, stemming from my heavy basis in White Wolf style games, stats, skills, abilities, traits, feats, merits and flaws, all of them are umbrellas that can cover more specific things inside. If you lack the umbrella, then you can simply use that to represent neutrality in regards to that subject/skill/whatever. In this way, you could also get creative with your flags, such that you might only want, scaled, slimy dragon hearts, so only dragons who have the Dragon flag with the "sub-flags" of slimy and scaled will meet the criteria for the quest.

This is definitely an interesting idea, it would present the opportunity to make quests much more open-ended then they currently are. Where as with current systems you are often charged to kill X amount of Y mob, who may be in short supply (especially if other players are doing the same quest), then you can simply look for other valid candidates. While at the same time, you can also have the specific quests like ide mentioned with Flafgar, Lord of the Earth Elementals.

Another interesting point I would like to make before ending this post is that this could also make players themselves valid quest targets, such that player Bob might be an enemy of the elves you're doing the quest for, and the quest being to slay five of their enemies, taking Bob's heart will count for one.

The question is, with such a system, how does the "group" say elves for example, keep track of who is doesn't like? The list could get rather large, rather quickly if it is handled on an individual basis. However, I imagine you could make "super-flags" acceptable as "sub-flags" in such a way that you could have an umbrella "enemy of" flag that could contain anything from "orcs" to "player Bob" to "winged" as valid people/beings that this particular entity or group of entities dislikes.

Good idea, a lot to think about,

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



Joined: 11 May 2005
Posts: 565
Location: Munich

PostPosted: Mon May 07, 2007 7:39 am    Post subject: Reply with quote

Quote:
I've been mulling this over for a couple of days. I don't know if this is an issue with GW2 but the main question I'm having is not how would you define 'dragon' (for it seems like the most suitable definition of 'dragon' is 'I know it when I see it' in this instance...that is you just add the dragon property to the creature you want to have the dragon property), but how would builders go about creating new creatures so that they fit into the system.


In short: When adding a new creature, you'd have to make sure it had the appropriate properties for any existing quests, and when adding a new quest, you'd have to make sure any existing mobs had the required property. So when you add a 'hydra', you'd have to go through the quests and see if any require specific properties which a hydra should have - and when you add a 'dragon slayer' quest, you'd have to go through the mobs and add the 'dragon' property to all of the appropriate creatures.

Obviously that's going to become an increasingly large amount of work, and is also highly error prone. However for the vast majority of cases the property could be added to the creature's shape rather than the individual creature - thus I could give the hydra, dragon and serpent shapes the 'dragon' property, and every type of hydra, dragon and serpent mob would then automatically receive that property.

Other properties could be applied on-the-fly - a special event which involves killing Bubba the Beholder could also give Bubba the 'Beholder Event' property.

Quote:
In this respect (and to go off on a tangent again) if you want to make quests that make a little more sense it might be good to have some kind of relations between properties. For example you could have a quest, kill 10 enemies of the elves. You could then define that the elf property is an enemy of orcs, trolls, ogres, etc., or if you want define them separately, so that elf enemy is a separate property itself -- this would be more work but could be a bit cooler, with for example some troll tribes that are enemies, neutral, or even friendly. On the other hand it might be a better idea to make relations totally separate if you want them to evolve dynamically.


I'd rather handle this with a separate system entirely - I'll post my ideas for that in another thread.
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    mudlab.org Forum Index -> Design All times are GMT
Page 1 of 1

 
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