Custom Design Spells

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



Joined: 18 May 2005
Posts: 71
Location: SC

PostPosted: Fri May 20, 2005 6:55 am    Post subject: Custom Design Spells Reply with quote

I'm sure a number of people here will recall previous discussions about this topic, but I've still failed to find a solution I really like. What I find most games lack is a sense of something similiar to exploring, but with regard to magic. A large part of typical magic-involving fantasy involves researching and developing magical spells, but I can't say I've ever seen a similar system in a multiplayer game.

Below I've listed what seems to be required for an interesting (versus boring or simply time consuming) spell research / development / design system:

Large search space - working (or useful) spells make up only a small percentage of this space
Consistency - if doing A chills the room, any small deviation from A should not cause a tornado (more on this later...)
Refineable - If A + B + C + D causes Q, but C = -B, then A + D should cause Q

I began writing the below with the intention of outlying a number of systems I've thought out, but due to time constraints, I've only listed one I really like - more so as I wrote it out. Any comments / critiques / suggestions would be appreciated. Below I've outlined spell-design as if it were software-design, a spell could simply be the sum of results as magic follows a set of magical pathways where it is systematically stored (or accumulated) and selectively released (causing a desired effect). I think the model allows for some nice possibilties / views.

First, it intuitively (for us programmers) allows for generic batch spells, much as we use a compiled language, while allowing for on the fly spells, much as a scripted language. Lacking any compiler, the spell-designers would have to manually convert to some much harder to understand, but more fine-scale and powerful medium for the batch spells. This idea is quite promising, since Magic Missile being common knowledge (or a teachable, if poorly understood spell by the newbie) is readily explained (a distributed program for all new spellcasters).

Second, the construction of spells would depend primarily on understanding the system vs random guessing. Even more so, a very knowledgeable player could craft custom solutions to problems (much as a programming guru) as they occur; or at least have a very good idea how to go about finding the solution.

Third, it easily extends dependence on mage spell / power. Imagine the mage as the computer (cpu, main memory, etc) for a program and this becomes rather intuitive. Much as a program requires a certain memory footprint or X cpu cycles, a spell could require more energy-capacity for certain spell sections or more time for certain complex sections. A mage lacking enough energy-capacity, simply couldn't succeed at casting the spell (perhaps they keep storing and storing the energy until no more energy can be 'held' or contained, then page fault - memory is overwritten, unexpected effects, etc). Dependent on how we model mana/energy, this could allows spells to have the vital energy vs time trade offs, I could cast it sooner, but it would cost more mana; if I don't have that much mana, I can only make it take longer as I build up more energy.

Some other issues I've been trying to tackle to really love this system are preventing a lot of information-sharing (ie, Player A figures out UberSpell, how to prevent A telling everyone, besides vested interest)...and I lost my train of thought for the 5th or 6th time, which is what doing all this at 3am does to me. At least two of the other problems I was considering were preventing UberSpell from existing and making the system _fun_.

In regards to the information-sharing, it should be possible to slightly modify the programming language / implementations per player without causing them to completely re-learn the thing. Modifying the language is probably more trouble than it is worth (now...why does Xu cause fire for me, and Xu causes feather fall for you?). Rather, modifying the implementations / player means that the symbol compositions (due to character elemental-tendencies, I suppose) do not mean exactly the same thing. As in A + B + C for KaViR != A + B + C for Kelson. Now, both Kelson and KaViR's systems should be independently consistent, but they don't need to be consistent with one another. I'll admit, I'm not quite sure how to do that yet.

And...I honestly don't know how much fun real players would have with such a system. As long as it were a system they only jumped into for beefing up their mage's spell inventory beyond the Guild-distributed 'compiled spells', it shouldn't be too bad. And yet, what percentage would really be interested in crafting spells?

As tangential note, such a spell-casting language would probably best be modelled as a functional language (versus imperative or logical languages). This would (hopefully) work in preventing huge spell compositions (which would necessarily appear if it were imperative) while allowing for a large set of possibilities. Which actually reminds of another problem: spells should be short. Unfortunately, we know a finite language with 'finite' length means a finite possibility space. Thus the language would need to be quite large to provide the large search space - this could be accomplished by mages undergoing a ritual in which they gain access to several dozen such language-components (as in, they get a subset of the language to work with) and they can expand this by other means (questing, mage-specific research - it was mentioned in the last thread about battling in the elemental worlds for such knowledge). Unfortunately, then this causes the program-model falter, since then the players are mostly assembling random symbols and...damnit. Of course, if the symbols were actually the underlying language's symbols in discrete sets (as in, my new QUR symbol represents the following action on the data immediately following, c, such that QUR c ==> STORE ENERGY(c+3) IN REGISTER1).

Kelson
Back to top
View user's profile Send private message Send e-mail AIM Address
Author Message
KaVir



Joined: 11 May 2005
Posts: 565
Location: Munich

PostPosted: Fri May 20, 2005 7:14 am    Post subject: Reply with quote

Have you considered using a 'proper' programming language to support such a spell system? To draw inspiration from C++ Robots again, you could could break spells up into CPU timeslices, use library functions to represent researched IC knowledge, and allow the player to distribute their spells in either source code or 'executable (or unreadable/obfuscated) form.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Kelson



Joined: 18 May 2005
Posts: 71
Location: SC

PostPosted: Sun May 22, 2005 10:10 am    Post subject: Reply with quote

My only problem with such a system is the size of a spell that would entail. Lets suppose you want to do a general Magic Mouth spell - what would such a "spell" require in C++ with all commonly available libraries?

Code:

#include <stdio.h>
void main() // where my spell begins
{ printf("I am a mouth of magiking.\n"); }


Okay, not too bad. Most of it would be the standard spell-header (void main(){, for example) with a specific spell-domain selection, and one part of the domain utilized for an affect. We could call stdio.h our magic-mouth domain. This magic-domain happens to very easily form mouths that talk the indicated words.

Now lets try to create a fireball.

Code:

#include <fire.domain>
void main(char *targetID) // where my fireball spell begins
{ // could also use direction, etc, but this is my spell...
   FireEnergyStore myStore;
   for(time_t now=0;now < 0+10;now++)
     myStore->Accumulate();
   Focus(myStore->Release(),targetID);
}


I don't like it too much. Of course, this is using an imperative language and I knew I'd dislike it implicitly. Lets use a 'functional' language - Scheme (6 months not using it makes you forget a lot...).

Code:

(define fireball (lambda(targetID manaCharge)
  (move (create Fire of potency manaCharge) to targetID))))


Code:

(define torch_light (lambda (objectID manaCharge)
  (maintain (attach (create Light of potency 1) to objectID) until cost >= manaCharge)))

(define light_to_fireball (lambda (targetID manaCharge)
  (redirect torch_light at maintain to
    (spell-effect-list
     (alter Light type to Fire)
     (alter Light charge to manaCharge)
     (alter Light size to 10 m^3)
     (move Light to targetID))))


It looks a bit better I guess (even if I did stick a non-pure-functional-call in the second one). I'm still not sure how I like the system though, since I'm not a huge fan of creating page long spells. Perhaps by limiting spell-progress to x 'commands' / y time and obviously costing more mana the longer the spell was. Unfortunately, I don't really see how this would prevent anyone from coming up almost instantly with UberSpell (simply string together 3-4 cursing effects with some damage...ie, what happened with Godwars spellbook casting - mage would link several pages of curses together to blast the enemy with it all at once, unfortunately...it meant there was a clear cut best tactic since you could use everything at once essentially).

I'm still not sure this is the right path to be travelling down since I'm trying to keep spells 'short.' Perhaps my expectations are conflicted though; one only creates something actually interesting from legos or programming languages or coloring or singing by assembling a set into something particularly ordered.

Kelson
Back to top
View user's profile Send private message Send e-mail AIM Address
Author Message
Greggen



Joined: 16 May 2005
Posts: 36

PostPosted: Sun May 22, 2005 10:24 am    Post subject: Reply with quote

I've been playing 'Eternal Darkness' on the Gamecube recently (good game), and I like the runes system it has. You select an alignment (represented by colours - e.g. red), a function (e.g. protect) and a target (e.g. self). You place these runes on a board to create a spell.

Eventually you get bigger boards and you can fit more runes into a spell. This turned out to be pretty disapointing in the end as instead of creating more complicated spells, you just used the same spells as you did before with some extra 'power' runes added on to the end.

Anyway, to tie it into this discussion, I have been thinking about turning it into a mini language of sorts for my game. As well as alignment, function and target runes, you will be able to get more exotic runes that branch. When the spell reaches the rune it will either go to the next rune, or skip a rune. You can make this as complicated as you want to.

For example:

rune 1 - opponent vulnerable to fire? (yes - 2, no - 3)
rune 2 - alignment: fire (skip to 4)
rune 3 - alignment: ice
rune 4 - target: opponent

This may be a good alternative for the non-programmer gamers out there. They're programming a script and don't even realise it!
Back to top
View user's profile Send private message Send e-mail Visit poster's website MSN Messenger
Author Message
eiz



Joined: 11 May 2005
Posts: 152
Location: Florida

PostPosted: Sun May 22, 2005 12:32 pm    Post subject: Reply with quote

I'm not sure how fun (for others) it would be to have a programming language for
doing spells. Nonetheless, I've been thinking about it a bit. Basically the
problem with existing systems is lack of generality. I am trying to come up with
a basic set of elements that can interact with each other to produce interesting
things without destroying game balance. So far I have a basic set of 'data
types' which would be used. This is a first pass obviously, as I started
thinking about it this morning after reading the post. So here they are:

Energy source - Self explanatory. Primarily the player himself but could be some
other resource.

Collector - Takes input from an energy source. A sort of magical
capacitor/buffer. Has an inherent charge time. Output may be 'typed' (i.e. a
particular element)

Reactor - This would trigger a spell when prodded with some kind of
stimulus. What kind of stimulus would be dependent on the reactor.

Effector - Takes N inputs and produces some kind of physical effect. Well, what
sort of inputs? Not just energy inputs, but also physical components and...

Pattern - Imagine you're trying to summon the Sword of Foo into existence. A
pattern would encode that inherent Foo-ness (and Sword-ness). This would
basically be a set of attributes that an Effector would use to produce an
affect.

Spell - Any combination of the above. This allows for higher-order effectors.

Target - Something to blow up, enchant, curse, whatever. Certain Effectors will
require these. Targets would probably be handled by an external system (e.g. the
command parser).

Now, these could actually be game objects. Some (especially Reactors) could
represent player skills. Some of them might be found in the game world directly
(fundamentals) or created through other magical processes. So a spell to create
the Sword of Foo might be a two or three step process: first you would need to
create the Pattern(s) and then use those to produce actual Foo.

So how do we take this and produce something that's actually flexible (rather
than just combinations of canned spell effects)? I think the trick is to make
the basic component objects very simple. Let me try to come up with an example
set...

Energy source: player, Magic Rocks(TM), Artifacts of Power(TM), etc. For now
we'll have the PC and a magic rock which is a renewable energy source, suitable
for enchantments.

Collector: Out of all of the types, this one is probably the most abstract. For
the sake of simplicity I will not add in any 'elements' or anything like that,
so 1 kind of colored light only for now. It will be an all purpose collector: N
seconds of input equals N points of abstract nonsense. Actually I need to think
about this one a bit more. So please, imagine that the gaps in my logic do not
exist.

Reactor: These could represent the PC's reflexes and other perception skills.
We'll say for example that our mage can react instinctively to someone hacking
at him with a big knife. So this would be directly prior to damage dealing.
These could also represent "I'm about to hit someone", "I am in a potentially
embarassing situation" (just try coding THAT one!), etc. See below. These could
also represent explicitly activated spell effects.

Effector: Okay this is the one I glossed over. Basically this is where the fun
happens. These represent the fundamental changes to the game world that can be
made by a PC's spells. This includes, but is not limited to:

- Creating stuff
- Blowing stuff up
- Turning things into other things
- Changing various properties of things
- Attaching spells to things. This has to do with Reactors. I'll explain in a minute.

So this is where the problem of making the system general comes in. Since
there's a fixed set of possible ways to affect the world, you've got to make
sure that those ways can be combined to do interesting things. This is probably
the single hardest part of any user-customizable system, programming language or
no. I'm not going to try to solve this problem directly. Anyway, here are some
examples, but first I should point out that when I say 'takes N points from
a collector' I do not necessarily mean all at once. For a 'duration', it
might, say, take 1 point each second until the collector is empty. On the other
hand, it might actually use the whole thing at once. Common sense applies.

- Apply Spell: takes N points from collector C, a spell S, and a target T. For N
seconds, all reactors of S apply to T.

- Decrease Stat: takes X^3 points from collector C, Y points from collector C2,
a stat S, and a target T. Decreases S on T by X points for Y seconds. This does
_not_ stack with other changes to the same stat.

- Increase Stat: Same as above, but reversed.

Any effector with a duration may be made 'indefinite'. In that case, each second
the number of points it uses per second is taken from the collector, until the
collector becomes empty.

So here's example 1. Say I want to make my wizard hat increase my intelligence.
Simple, right? First I need a power source for the enchantment. Magic Rock A
provides 7200 points per hour: 2 per second. Using Lispy syntax:

Code:

(defspell make-me-smart (target)
  (let ((c (collector 4 $magic_rock_a))) ; Collects 4 points at a time
    (apply-spell-indefinite c target
      (spell ()
        (reactor 'worn
          (spell (wearer)
            (apply-spell-indefinite c wearer
              (spell ()
                (increase-stat wearer 'int 1 c c))))))))


Okay that syntax really, really sucks. But you get the basic idea.

I glossed over a lot of details here. And I haven't gotten into patterns and so
forth yet. And the syntax is obviously pure trash. But does the basic idea seem
sound? And assuming so, what sort of effectors would you use?

I wonder if such a general purpose system might be useful even if user created
spells weren't supported. It might make a halfway decent internal tool if done
properly.
Back to top
View user's profile Send private message Visit poster's website
Author Message
eiz



Joined: 11 May 2005
Posts: 152
Location: Florida

PostPosted: Sun May 22, 2005 12:34 pm    Post subject: Reply with quote

Kelson wrote:

I'm still not sure how I like the system though, since I'm not a huge fan of creating page long spells.


IMO, this is not a problem. It's not something you're going to be doing constantly - in fact, someone else might do it for you. There's talk about preventing information sharing but I think information sharing is absolutely 100% the most important thing. If you need to prevent information sharing that means there's a solution to the system, a best way. But if the system allows for true innovation, players will want to keep their tricks to themselves without any help from a coded system, simply due to the advantage it gives them. Now I certainly am not sure if it's even possible to design such a beast while maintaining game balance. I think it's an interesting problem. But I think that should be the goal, rather than to prevent people from sharing knowledge.
Back to top
View user's profile Send private message Visit poster's website
Author Message
BobTHJ



Joined: 19 Nov 2005
Posts: 31

PostPosted: Sun Nov 20, 2005 10:43 pm    Post subject: Reply with quote

I know this is an old topic, but i just stumbled across these forums and wanted to add in my 2 cents.

While writing a mud engine a while back I halfay coded (before abandoning the project) a component based spell system that allowed for customized spells.

Players could learn various spell components. The specifics of each component would be unknown to the player, but could be discovered through experimentation. Each compoment was represented by a single syllable, for example "FOO", "KAR", RO", "MIP". When a player wanted to cast a spell the would type CAST followed by two or more spell compoment words. For example "CAST FOO KI RAL".

Each component word had 3 functions (effect, modifier, or distribution), but only one would be used based on that word's placement within the casting spell string.

The first component used in the spell would determine the general type & effect of the spell. Some examples:

energy
morph
heal/restore


Any components used in the middle of the spell (you could optionally include one or more) would modify the base effect in the first component by adding aligned damage, reducing/increasing cast time or mana cost, requiring new factors (such as a focus object, physical movement or speech), etc.

Finally, the last compoment used in the spell would determine the delivery of the spell: who/what it affects. Options include:

targets self
targets opponent
targets all oponents
targets the room
targets all allies
etc.

Spell data would be generated by the first component and passed in turn to each component on the list to build the final spell. Each of the middle modifiers would build upon the spell data feeded to them by the previous component on the list. Thus casting "FOO KA RE TEY" would result in a slightly different spell than "FOO RE KA TAY" or a largly different spell "RE FOO TEY KA".

Obviously, many combinations would be unhelpful or downright harmful. The trick would be to finding combinations that would lead to potent spells. To prevent players from learning and sharing the "best" combinations and thus preventing experimentation (or at least to make it more difficult), the modifiers all were based on some outside factor such as:

The player's race/sex/lvl
What armor the player is wearing
The player's alignment
Terrain of the room
number of mobs in the room
current phases of a paticular moon
if a paticular moon was visible
time of day

I figured this would make things really interesting. FOO KA RE could be a 5000 point fireball at 7PM if exactly two moons were visible, you were a Gnome, and you were wearing at least one peice of fire resistance armor. However, if you cast FOO KA RE at 3AM using your Dwarf and wearing a tunic of Water Resistance while during a solar eclipe, it would then act as a resurrection spell.

Of course, the above changes based on outside variables were on sliding scales. Therefore, the difference between casting FOO KA RE at 7PM and at 8PM would be barely noticable. I realized that having such a random effects system for magic would be interesting to some players, but very frustrating for others who just wanted some simple "pre-made" spells to cast. Therefore this custom spellcrafting system was designed to be added in additional to a more traditional "pre-made" spell system to reward those players who wanted to experiment carefully structuring their own spells.
Back to top
View user's profile Send private message Send e-mail
Author Message
Kelson



Joined: 18 May 2005
Posts: 71
Location: SC

PostPosted: Sun Nov 20, 2005 11:46 pm    Post subject: Reply with quote

BobTHJ wrote:
I know this is an old topic, but i just stumbled across these forums and wanted to add in my 2 cents.


Don't worry about it in the least - to be honest, I've been working on this even more of late and never found a solution I was a big fan of. I tried the spell description language eiz described above (similar to my original favorite), but found that it was far too predictable for my likes. There is nearly no researchability in a fully deterministic and obvious system. Take real programming, if a programmer needed to make a binary search function there is a set pseudo-code for achieving that. Naturally, modifications can be made to enhance or degrade performance, but one would not happen upon a binary search function while trying to write to the screen. How the system works is too intuitive (although, perhaps this is merely due to my familiarity with the subject - it certainly isn't the case for freshmen CS students I've seen).

BobTHJ wrote:
Players could learn various spell components.


This sounds very similar to KaViR's Godwars rune system, with the exception of being generated by rune-properties instead of hard-coded and being environment dependent (fireball vs res). Unfortunately, such a system is vulnerable to brute forcing and storing the results in a table (with the exception, perhaps of the strong environmental affects which I feel would confuse players worse than KaVir's A+B+C != Kelson's A+B+C). As eiz mentioned above though, the hardest part of the system seems to be generality and flexibility of effects. The same system that generates a fireball needs to generate a fly spell, pass door, identify, enchant weapon, invisibility, detect magic, detect invisibility, magic mouth, gate, etc.. It isn't necessary it create them all, but the majority should be possible without hard coding - which is hard to achieve without hard coding messages to players, damage and reaction effects (how does detect invisibility make itself known to the 'look' code to allow the player to see the invisible players - or even find out they're there?).

Granted, I can't yet answer the above conundrum, but I wanted to toss out two models for a spell system's implementation side details - an RTS and a chemical reaction. As an RTS, we can imagine a magical battle between mages as building up in stages until releasing magical effects to affect the world (the mage isn't necessarily aware of building a nexus and two pylons then probe rushing, but that is essentially what happened when they cast a magic missile). While I think there is potential here, I'm not currently a fan.

Instead, I prefer visualizing spells rather as molecular reactions with the mage creating a molecule then having it propagate into the local region. For example, creating a fireball spell might involve creating a surplus of a highly reactive (phosphorus) molecule in the region which then ignites. Clearly, the environment and everything in it must also be described with some magical set of molecules to determine the explicit effect of each spell. For example, a spell targetted for a specific person may pick up on a specific "PersonA" antigen which causes it to bind to that person and cause it's specified reaction with just them (versus the entire room). Spells would thus become a matter of creating and positioning the atomic pieces of each molecule to form the proper chemical composition and physical form to bind and react with other entities. A counterspell might involve simply attaching to the offending spell molecule and blocking it's particular targetting site. Or perhaps it forces a change in the other molecule's chemical structure to remove it's lethality or simply reverse its effect.

- Kelson
Back to top
View user's profile Send private message Send e-mail AIM Address
Author Message
BobTHJ



Joined: 19 Nov 2005
Posts: 31

PostPosted: Wed Jan 31, 2007 4:13 pm    Post subject: Reply with quote

Here I am, reviving this old topic yet again...

I was actually coming back to re-read a good portion of these forums after resuming work on my mud (after about a 1 year hiatus), and while reading this thread I hit upon an idea.

What if you combined the spell construction language described above with a series of in-game casting steps (like Bartle's mage game, the system that God Wars II uses, IIRC). So, over the period of several commands, a player would assemble and cast one or more spells. It seems this might help solve some of the "UberSpell" problem: Since actions happen over time, you would have to be reactive.

For example, I might start casting UberSpell by entering the first two commands, but the enemy caster recognizes the start of that spell, and responds with a counter. I am then forced to find the best way to use the magical energy I have started to accumulate so it is not wasted.

To flesh it out a bit more (borrowing heavily from ideas listed earlier in this thread):

Each caster has a "spellbook" comprised of all the spell components that they know. Spell components can be quested for, earned through leveling/skills, etc.

Each spell component has zero or more inputs, which are entered as part of the command.

Each caster has an Active Memory (think RAM) where completed spell components are stored until they are used. If they are not used within a set period of time, they degrade (or perhaps overload, causing harmful effects).

Each spell component would build in power, by using the components already stored in memory as it's "inputs".

Components could have side effects as well, such as elemental energy, that would also be stored in Active Memory for use as an input to another component.

Components may have ongoing effects that would continue as long as that component remains in Active Memory.

Each component may have a spell effect (fireball, heal, etc.)

So combat would look something like this:

> CAST Foo

COMPONENT Foo
INPUTS: None
OUTPUT: X Arcanum Points
ONGOING: Siphons 3 mana from your personal reserve each second. X = the total amount of mana siphoned this way.

MEMORY:
1. Foo

> CAST Bar Foo
(Casting Bar, using Foo as an input. Foo is consumed from memory)

COMPONENT Bar
INPUTS: (Arcanum)
OUTPUT: X / 2 Destructum Points (X = amount of Arcanum)
SIDE EFFECT: 2 Instability Points
ONGOING: -1 Arcanum every 3 seconds (degradation)

MEMORY:
1. Bar

> CAST Tee

COMPONENT Tee
INPUTS: None
OUTPUT: 3 Stability Points
ONGOING: Degrades from memory after 30 seconds

MEMORY:
1. Bar
2. Tee

> CAST Fir

COMPONENT Fir
INPUTS: None
OUTPUT: 5 Fire Points
ONGOING: Vulnerability to cold increased by 10% while Fir is in memory.

MEMORY:
1. Bar
2. Tee
3. Fir

> CAST Gah Bar Fir Wizard

COMPONENT Gah
INPUTS: (Destructum) (Elemental Energy) (Target)
OUTPUT: 5 Dissipatum Points
SPELL EFFECT: Blasts the target with elemental energy causing X damage (where X is the Destructum x the Elemental Energy received)
ONGOING: Causes one Elemental damage of the element this was charged with each second to you as long as this remains in memory.

MEMORY:
1. Tee
2. Gah
3. 2 Instability Points (From Bar)

> CAST Mim Tee Gah

COMPONENT Mim
INPUTS: (Stability) (Dissipatum)
OUTPUT: X Neutralum
SPELL EFFECT: Sheilds you from the next X damage you would receive, where X = Dissapatum
ONGOING: Loses 1 Stability each second, while reducing your loose Instability points by an equal amount. When Stability = 0 this is removed from memory.

MEMORY
1. 2 Instability Points
2. Mim

Over the next two seconds, Mim would remove your loose instability points, and then degrade from memory.

It's not the best example, but I hope it illistrates the idea.

The actions of opponents during combat could make things much more interesting. For example, some spell effects might delete or alter an enemy caster's memory. Taking damage during battle could cause you to lose components from memory, or possibly "trigger" components to fire-off prematurely.

To lessen the learning curve, new players would start off with simple collectors (like Foo) and simple spell effects. Over time, they could learn more complicated components.

To add more challenge to players who master the system, you could introduce components that have variable effects based upon outside factors, such as lunar phases, weather, number of people in the room, race, etc.
Back to top
View user's profile Send private message Send e-mail
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