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



Joined: 13 May 2005
Posts: 110

PostPosted: Wed Apr 26, 2006 4:13 pm    Post subject: Mob Taxonomy Reply with quote

One of the big additions in D20 over the earlier versions of D&D was the system of monster types. The rules gave about a dozen types, and if you knew a monster's hit dice (a measure of how tough it is) and its type you could work out roughly what its stats were. We implemented something similar in our mud; I wonder what other people have done in this area?

Our system has about 25 types. It was a big effort to go through our five thousand or so monsters and classify them all, but I think it was worth it. There are two big benefits to this: first, you can demand "the eye of a dragon" as a component for a spell and let the player decide which dragon he wants to slay. Second, you can make whole classes of mobs behave differently, e.g. all demons get a certain level of fire resistance, or all plants are subject to a druid spell that withers plants. This makes combat more interesting and makes more stuff the players can learn about how to play your mud.

I have occasionally thought that I would like a more detailed classification system, maybe organized as a tree, or as something more complicated (like an oop system with multiple inheritance, so you can have a demonic spider that has both demon and spider traits). Under our 25-category system, I'm often unable to definitively say "does this thing have six legs or eight" so when players start cutting legs off the corpse the count is right.

Recently in another forum there was some discussion of automated combat and it occurred to me that some nice combat verbiage could be generated if you knew the species of the participants.

Spark Mud, which unfortunately never took off, had an even fancier implementation of this: when creating mobs, you specified the level and species (from some list of categories, I think perhaps identical to the list in D20) and it spit out a baseline monster. I never tried it, but I would think that could make creating reasonable, balanced mobs a lot easier.

Does anybody have other approaches to mob taxonomy, or other uses they have put it to?
Back to top
View user's profile Send private message Visit poster's website
Author Message
Nornagest



Joined: 08 Jan 2006
Posts: 12
Location: California

PostPosted: Thu Apr 27, 2006 12:02 am    Post subject: Reply with quote

My former MUD created NPCs from modification scripts applied to a small set of base objects, and typically went through several scripts for a single NPC: one for the NPC's behavior (applied to an AI object), then one for its basic physical shape, one for its racial traits, and one for its individual abilities and quirks of appearance. The idea was to reduce code duplication and make adjustments to low-level traits easier.

It worked pretty well at the NPC level, and particularly with NPCs belonging to player races, since there were typically a lot of different NPCs inheriting from any particular player race. It didn't work so well at the racial level, or for nonsentient NPCs or monsters; by the time I left, most races had their own shape script (since a lot of fine adjustment, like the quality of natural weapons and precise mass distributions for limbs, took place there), and many nonsentient NPCs had only one or two high-level types built off of their race and shape.

I think it can be a positive addition, but you have to be careful about the uses to which you put it at each level of complexity in order to avoid complicating things unnecessarily. I also think using scripts instead of actual code was a bad idea (it was an LP MUD, so giving builders access wasn't an issue), and you'd probably need support for multiple inheritance to do anything really interesting with it.
Back to top
View user's profile Send private message
Author Message
Ashon



Joined: 11 May 2005
Posts: 86
Location: Seattle

PostPosted: Thu Apr 27, 2006 6:11 am    Post subject: Reply with quote

It seems to me, that the best way to handle it a decent inheritance scheme for your NPC's. It's been awhile since I broke out my d20 books, but with inheritance files that handle species, subspecies, subtypes, you should be able to create a full range NPC's.

If your base NPC object handles Limbs, then it wouldn't be too difficult to go through and add limbs to each specific race include (or however you decide to implement your inheritance) Of course as you point out the hardest part is going backwards and adding a good inheritance scheme to an already existing system.
Back to top
View user's profile Send private message Send e-mail Visit poster's website AIM Address Yahoo Messenger MSN Messenger
Author Message
KaVir



Joined: 11 May 2005
Posts: 565
Location: Munich

PostPosted: Thu Apr 27, 2006 9:28 am    Post subject: Reply with quote

Quote:
One of the big additions in D20 over the earlier versions of D&D was the system of monster types. The rules gave about a dozen types, and if you knew a monster's hit dice (a measure of how tough it is) and its type you could work out roughly what its stats were. We implemented something similar in our mud; I wonder what other people have done in this area?


To be honest I think the D&D "templates" would be of more benefit to a mud - want to turn a mob into a vampire? Give it the 'vampire' template. want to make it a half-dragon? Give it the 'half-dragon' template. Want a half-dragon vampire? Give it both.

The approach I use is to give each mob a "form". This defines what sort of equipment the mob can wear, and what sort of body parts it has (for cosmetic messages). For example if a player transforms into a wolf, they can only wear collars, the 'clap' social will describe them clapping their paws, getting headbutted in the face will break their 'snout', weak blows fail to cut through their 'fur', etc.

The drawback of this is that if I want some sort of crossover form (eg a skeleton wolf) it needs its own shape - it would have been far nicer if I could just include both shapes and have the mud automatically combine them.

Quote:
Our system has about 25 types. It was a big effort to go through our five thousand or so monsters and classify them all, but I think it was worth it. There are two big benefits to this: first, you can demand "the eye of a dragon" as a component for a spell and let the player decide which dragon he wants to slay.


This also suffers from the whole crossover issue - a dracolich wouldn't have an eye, for example, but if the component was "the fang of a dragon" then a dracolich should work just as well as a dragon.

Quote:
Second, you can make whole classes of mobs behave differently, e.g. all demons get a certain level of fire resistance, or all plants are subject to a druid spell that withers plants.


Yeah, that's pretty nice, although once again there's the crossover issue. If I want the dracolich to be vulnerable to both the Sword of Dragonslaying and the "Protection from Undead" spell, it's going to need to belong to both categories.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Sandi



Joined: 13 May 2005
Posts: 94
Location: Boston

PostPosted: Thu Apr 27, 2006 11:37 am    Post subject: Reply with quote

KJ,

You might want to look at ROM, const.c


Keri
Back to top
View user's profile Send private message Visit poster's website
Author Message
Kjartan



Joined: 13 May 2005
Posts: 110

PostPosted: Thu Apr 27, 2006 3:18 pm    Post subject: Reply with quote

Yeah, I like templates too. I vaguely think the aforementioned Spark Mud had those, not sure though.

The dracolich thing is exactly the problem my simplistic system has. I would have to classify that as "intelligent undead" (one of the types) and lose the dragon characteristics. (If I said it was a dragon, then you wouldn't be able to use anti-undead magic on it). We have some hacks in place that effectively further refine the type list by adding bits, e.g. a wraith would be intelligent undead with the "ethereal" bit set, so it doesn't leave a corpse at all, but those are hacks.

I think there's a lot that can be done with this taxonomy stuff to make an old, huge, stale mud a lot more interesting. For instance, we are also in the middle of taxonomizing our rooms - we have increased the number of terrain types from the base diku 7 or so to around 100, and we're going through the world classifying everything. We have thus been able to add things like making necromancy create more powerful undead in graveyards and crypts, and making room-type-specific hiding places for mobs to keep their treasure, for example in a "throne room"-type room there might be something hidden behind an arras, whereas in a boudoir it might be instead behind an heiress.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Kjartan



Joined: 13 May 2005
Posts: 110

PostPosted: Thu Apr 27, 2006 4:36 pm    Post subject: Reply with quote

Sandi wrote:
You might want to look at ROM, const.c

Thanks. The race stuff in there looks very nice! Except... why are there so few races? Is it usual in a ROM to add a bunch more? It has stuff at the level of specificity of centipede, but it doesn't have anything that would cover a fish, or a demon.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Sandi



Joined: 13 May 2005
Posts: 94
Location: Boston

PostPosted: Thu Apr 27, 2006 8:09 pm    Post subject: Reply with quote

Unfortuanately, I think it gets ignored, but most ROM IMPs are coders, not builders. Myself, I added quite a few more, as well as more fields, to what was there. But then, I chose ROM over MERC largely because of Gabrielle's additions. Smile (then promptly cut the levels back to 30, separated the classes, and removed some overly helpful conveniences, like recall)

What may not be obvious from a quick glance is, those are indeed "templates". That is, they are used when the game boots to load characteristics to each mob, but there's no inheritance. So, you can't make a shapeshifter by changing the mob's "race" value from human to bat.

I'm impressed by your terrrains, though. I admit, I never thought of getting so fine grained as to define different kinds of rooms. I think you'll have a lot of fun with that.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Massaria



Joined: 14 May 2005
Posts: 31
Location: Denmark

PostPosted: Fri Apr 28, 2006 11:18 am    Post subject: Reply with quote

The taxonomic system I'm planning (though for characters), is as close to the real thing as I can reasonably get without making it purely educational.
I've set up a tree where each branch represent an evolutionary step towards the most advanced, or complex, animals on earth: Primates.
Make bad choices and you might end up as a coral or sea slug (of course, these have use in the game too, although they're not as versatile as primates).
Once a step is taken, I tell the player about this new characteristic - what it means to the organism and give examples of RL animals that possess this trait.
What I don't do, is to have each step actually mean something within the code. That is, while I might change the type of the character from a jellyfish to a sea urchin, it doesn't convey any new stats or abilities directly. This is all done only when the player finds his way to a 'dead end' (no more branches). At that point, the character receivies all his abilities and stats, the diet is set, metabolic rate given, modes of locomotion, viable habitats etc. etc. There are just over 40 taxons, or dead ends.

This approach is obviously limited to only the 40-something types of animals, but it makes certain I have no fantastic creatures and it's fairly easy to decide which abilities each type would have. All I really have to do is read a book.
But I've often thought about how you might build a system where the player has more freedom to design his own animal, realistic or not. A system that would allow for hundreds if not thousands of different 'races'. A system where each additional trait obtained has an impact on what and how the character does things.

I'm still thinking.
Though, I believe I have a decent starting point.

I imagine a basic set-up of Head, Torso and End (for a lack of a better term). Some choices may lock out the Head or End slots, but you'll need a Torso always.

Before deciding what goes into each slot, we'll need to figure the basic build of the char.
I'm fairly certain that the first choice in this process would be one of symmetry. Is the char radially or bilaterally symmetrical? Having a radial symmetry is, in nature, a sign of a primitive animal - but it needn't be in a fantasy setting.
The most obvious effect of symmetry is one of orientation - radial creatures have no front, back or flanks; only an 'up' and 'down' can be identified. This would have a clear impact on combat, for instance.

Not all animals are segmented, but I think we'd have to make such an assumption to make this work, as the next choice would probably be one of repetitions - how many times does the creature reflect a certain characteristic. Jelly fish have four rays, but the body of centipedes are repeated many times over - each segment along the longitudinal axis identical to the one before.
This would decide the number of limbs you have, for example.
You would probably limit segmentation to the torso only, but I guess having two heads on top of each other, or for radial creatures, one face in each direction, is conceivable.

Another point of decision would be how the creature is organized. Some animals, primitive ones, have no organs, and are said to be organized on the tissue level. This would include jellyfish and sponges, for instance, and characters with such an organization would be akin to a blob of fluid, which have different kinds of cells, but without these cells actually grouped together in organs with specific purposes. It certainly wouldn't have a head. Seems like a poor decision for a player, but such animals usually have incredible regenerative capabilities, and are pretty much indifferent to internal damage (there's no heart, lungs or spleen to rupture!)
Creatures organized on the organ level would be more vulnerable to damage, but much more adaptable and versatile in it's choice of habitat - would generally have far more options.

Hm. I guess that would be it for the basic build of the character or creature.
Naturally some combinations would be more versatile or powerful than others, so some form of point system might have to be introduced. Making a radial creatures would not cost as much as a bilateral creature, having a lot of segments would cost more than having just a few, etc. etc.

Come to think of it, the remaining procedure probably wouldn't be very different from the designing of space ships in sci-fi games. Once you have your basic set-up, with at least a Torso and probably Head and End too, you'd pick from a list of basic types of libs - possibly with some degree of customization. In any case, I imagine you'd fill up your segments with tentacles, arms, feet and whichever monstrous limbs you might think of.

To finalize your creature, you'd have to chose an exterior shielding to keep your environment from entering your organism (e.i. skin (types?), fur, feathers, exo-skeleton, horn etc.), you'd have to pay for your senses and how sharp they are, you'd have to decide on a diet, possibly a life-cycle and metabolic rate as well.

Obviously this is more of a brainstorm than anything, but I think I could make the above work. The two major problems I'm having is one of creature size and intelligence.
I guess they could both be bought at hefty costs, possibly in relation to the evolution of your Head (int) and number of repeated segments (size), but somehow that just rubs me the wrong way. Can't really put my finger on why.

I feel like I'm still struggling to get out from under a blanket, so I'll halt here before it all get's too vague (probably too late for that anyways Wink

Excellent topic. Hope to see more on it!
Massaria.
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: Sat Apr 29, 2006 4:34 pm    Post subject: Reply with quote

I think Massaria, those his posting and his game structure are probably far more in depth than most people want to go, makes an intersting point.

If one is going to use templates, heirarchy or inheritance to create mobs, there arises the problem of which is the dominate aspect. For example a Demon Spider or Spider Demon, It could be seen that whichever comes first, the Demon or the Spider would be the super-set and the following the sub-set, but which parts do we mix and match? For example, the Demon Spider may be vaguely humanoid but have eight eyes and limbs, walk erect and be able to spit webbing to ensnare the opponent, while the Spider Demon may be octpedal(?) but have a long tail and horns and be able to breathe fire, but where and how do we draw the line? It seems like a lot of coding if/then circumstance to make sure that all of your "Types" of creatures, which can all be interchanged, add up to something that actually makes sense.

Of course, if we're not worrying overly much about dynamic descriptions and rather just on what abilities and stats a creature has, it becomes easier to use the super/sub setup, but still, problems arise with limbs and the like.

What instead should be looked at is a dynamic description scenario with an in-depth creation engine that allows builders (or possibly players if your game warrants it) to select which features of each type the creature has. So our demon, though limited to four limbs as a result of its humanoid archetype, would gain the ability to have up to eight limbs as a result of inheriting the spider subtype. But then further distinction must be made over whether these limbs are arms or legs, to determine what wear locations and wielding and locomotion type and whatnot we're dealing with, all to figure out, how many limbs does a Demon Spider have?

Then to further complicate matters, are the Demon Spider's limbs all demon limbs? Are they all spider limbs? Does it have two arms and two legs with four long spidery arms coming out of its back (reference Doc Oct from Spiderman)? However, this system might be a lot of work to do, but I think in the long run you're looking at a lot of time saved by letting builders just select from a list of components and let the computer generate the descriptions. I know from previous building experience that especially when dealing with something fantastic from which you may have no reference to draw from, it can be rather time consuming and difficult to adequately describe the creature, let alone go through the trouble of trying to determine what its stats and all that should be.

So in summary, I think Massaria has and can in much greater depth, testify to the fact that it quite an undertaking to create a complex character generation system, but I do think that in the long run, it would be worth it. It will certainly require a lot of work, and there will doubtless be countless bugs, errors and general hair-ripping-out situations on the way to success.

My two cents, something to chew on,

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



Joined: 29 Jun 2005
Posts: 134
Location: Emily's Shop

PostPosted: Tue May 02, 2006 10:28 am    Post subject: Reply with quote

Where this gets tricky is that a system like this not only has to be multi-dimensional (something can be both a demon and spider) it would also have to be dynamic. If you consider, for example, a "vampire" template: what happens if a previously non-vampiric creature is bitten and becomes a vampire? You need to be able to superimpose the "vamprism" traits on top of the basic creature state.

What that means is that your inheritance/templating system cannot be hard-wired at the moment of creation. These things have to be dynamically assigned and removed over time. And this has to work in such a way that the rest if the system doesn't have to know too much about how any of these things are operating. Being a vampire might increase a creature's "speed" attribute. So might a "haste" spell. If a haste spell is cast on a vampire, this needs to be handled in a way that doesn't require any of the haste spell code to be aware of the existence of vampires, or any of the vampiric code to be aware of the existence of haste spells.

You can't have code in the basic "living thing" class which says "my speed is basic_speed + 3 if I'm a vampire + 2 if I'm hasted" - the basic living thing code shouldn't know anything about haste spells or vampires. Instead there needs to be something in the haste spell code which overrides the normal code for returning a creature's haste and says "return normal haste + 2".

This has some interesting implications on what sort of programming language would comfortably support a system like this. Traditional C++ type inheritance, for example, is useless: not only is it static rather than dynamic, but subclasses override superclasses, so adding a new superclass to the object doesn't let you change behaviour already defined in the subclass. In this case you need to add a new "flavour" to an object on the fly which overrides the object's default behaviour.
Back to top
View user's profile Send private message
Author Message
Kjartan



Joined: 13 May 2005
Posts: 110

PostPosted: Tue May 02, 2006 3:10 pm    Post subject: Reply with quote

D20 handles the demonic spider case in a fairly graceless manner: you basically pick one of "demon" or "spider" (probably "spider" if it's nonintelligent, "demon" if it's intelligent) as "what is this thing" and then add templates to it like "demonic". A template is basically a patch list, like "change hit dice from d8 to d12, add fire resistance 20, etc." This mostly works. In 3.5 they found it necessary to add a bunch of "descriptors" which were a further breakdown of some of the types, like "magical beast (aquatic)" or "outsider (lawful)" and the system is starting to look strained. In addition, there are clearly some creature types that were treated by the game designer as types even though they aren't mentioned as formal types in the rules, for example there is definitely a "canine" type that applies to a wide variety of mundane and magical dog-like creatures (not all from the same basic type) who all get the same special attack (an improved ability to drag people down to the ground) and some other bonuses.

I think a system that has a big pile of basic types and a big pile of templates might work pretty well for a MUD. So, for example, instead of "outsider (lawful)" being a basic type, you would have "outsider" be the type and "being of law" be a template. It's perhaps easier to slap three or four templates on something in a computer environment than a pen-and-paper environment where many of the users might be applying the diffs by hand. My mind is a bit fuzzy as to what goes into a type as opposed to a template, but maybe anatomy and basic life processes (like, undead or alive or elemental) goes into the type (so "outsider" is actually a pretty crappy type) and everything else is template. That's not great either, since there would need to be several undead types to cover undead horses vs dracoliches vs wraiths vs zombies. But on the other hand, the system doesn't have to work perfectly for everything - it may be that any system capable of organically generating a dracoich is going to be too cumbersome for everyday use.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Kjartan



Joined: 13 May 2005
Posts: 110

PostPosted: Tue May 02, 2006 5:13 pm    Post subject: Reply with quote

shasarak wrote:
Where this gets tricky is that a system like this not only has to be multi-dimensional (something can be both a demon and spider) it would also have to be dynamic. If you consider, for example, a "vampire" template: what happens if a previously non-vampiric creature is bitten and becomes a vampire? You need to be able to superimpose the "vamprism" traits on top of the basic creature state.


It is probably ok to have for each being a base type and a bunch of templates, where the list of templates is dynamic (just a linked list of pointers to template objects) and where you simply apply the patches from each template whenever anyone asks a question about the critter. For instance, whenever any creature moves, you can check if it's got the "damaged by sunlight" trait by checking its base type and then traversing its list of templates, and if so then check if the new position is sunlit, and if so take the appropriate action. This sounds inefficient, but really a bunch of walks of shortish linked lists (I doubt anybody will be walking around with more than four or five templates) is not going to be a big cycle hog.

And so you can use FORTRAN or whatever it is the kids like nowadays. FORTRAN 95, I guess.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Vopisk



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

PostPosted: Wed May 03, 2006 1:29 am    Post subject: Reply with quote

Kjartan wrote:
shasarak wrote:
Where this gets tricky is that a system like this not only has to be multi-dimensional (something can be both a demon and spider) it would also have to be dynamic. If you consider, for example, a "vampire" template: what happens if a previously non-vampiric creature is bitten and becomes a vampire? You need to be able to superimpose the "vamprism" traits on top of the basic creature state.


It is probably ok to have for each being a base type and a bunch of templates, where the list of templates is dynamic (just a linked list of pointers to template objects) and where you simply apply the patches from each template whenever anyone asks a question about the critter. For instance, whenever any creature moves, you can check if it's got the "damaged by sunlight" trait by checking its base type and then traversing its list of templates, and if so then check if the new position is sunlit, and if so take the appropriate action. This sounds inefficient, but really a bunch of walks of shortish linked lists (I doubt anybody will be walking around with more than four or five templates) is not going to be a big cycle hog.

And so you can use FORTRAN or whatever it is the kids like nowadays. FORTRAN 95, I guess.


This plan works well for assigning traits, adding flags to something and slightly changing the description to make the bat a "vampire bat" are easy enough things to do, just make them permanent effects rather than temporary.

However, how would you change one's complexion to be pale and give them fangs and the like? Of course, I think this system can still be put to use, with the "base"/"template" work. For example, our "Demon Spider" would be a demon as its base class, with a spider template added on, since our demon already has four humanoid limbs, our added "spider" template adds four spider arms to the creature, makes them have six more eyes, etc... If our dynamic description system automatically compiles a description based upon a set of variable factors, it would be easy enough to tell the object/mobile or even player character to recompile their description based upon some change in their appearance. It would make such things as a vampire masquerading or a werewolf changing form really stick nicely I think...

My two cents, something to chew on,

Vopisk

Edit: This would probably result in a large amount of work with creating base classes and templates, to make sure everything played nice with everything else, but could be worth the work if it makes creating mobiles easier.
Back to top
View user's profile Send private message AIM Address MSN Messenger
Author Message
shasarak



Joined: 29 Jun 2005
Posts: 134
Location: Emily's Shop

PostPosted: Wed May 03, 2006 10:23 am    Post subject: Reply with quote

Kjartan wrote:
shasarak wrote:
Where this gets tricky is that a system like this not only has to be multi-dimensional (something can be both a demon and spider) it would also have to be dynamic.

It is probably ok to have for each being a base type and a bunch of templates, where the list of templates is dynamic (just a linked list of pointers to template objects) and where you simply apply the patches from each template whenever anyone asks a question about the critter. For instance, whenever any creature moves, you can check if it's got the "damaged by sunlight" trait by checking its base type and then traversing its list of templates, and if so then check if the new position is sunlit, and if so take the appropriate action. This sounds inefficient, but really a bunch of walks of shortish linked lists (I doubt anybody will be walking around with more than four or five templates) is not going to be a big cycle hog.

No, that doesn't work. Well, okay, it does work Smile but it's not a nice way for it to work.

The problem with doing it this way is that every single effect that might be influenced by the presence of templates has to be coded in a way that anticipates the possibility of a template affecting the outcome. In your example you've got code that determines whether or not a creature is damaged by sunlight; that code has to be specifically written to check for the presence of templates which have an influence on that.

This is bad encapsulation. What should happen is that you can add a "template" or "effect" to the creature which overrides the creature object's default behaviour in a way that doesn't require either the creature code or the sun-damage code to be aware of the template's existence.

So, by default, creatures are not damaged by sunlight. If you query the creature object:

Code:
creature.damaged_by_sunlight()

that returns false.

You add a "vampirism" object to the creature's list of overrides, and that changes the behaviour of the creature's code. So if you now evaluate:

Code:
creature.damaged_by_sunlight()

it returns true. But the code that calls the damaged_by_sunlight() function is entirely unaware of the existence of templates, and the code that returns false from that function in the default creature code is also unaware of the existence of templates.

With a system like this you can arbitrarily modify any aspect of any object's normal behaviour with a newly coded "effect" without ever having to make any changes to the default code, or to the code that invokes it.

This is something you really can't easily do in Fortran, or in C++. You can do it in a language like Smalltalk or Ruby, but you'd need to hack about with proxies, which still isn't the nicest way of handling it. I think a language like Self might be neater: something that does away with the idea of an object being a member of a class for its entire lifetime, and regards each object as possessing a unique (and dynamic) combination of methods and properties inherited from an arbitrary selection of other objects.
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 1, 2, 3  Next
Page 1 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