Text-Based Battle a la Mushu
v0.01


0. Legal Stuff

Everything contained within this document is the sole
intellectual property of L Campbell ("Mushu") and MAY
NOT BE USED WITHOUT EXPLICIT CONSENT.

By viewing this file you implicitly agree to not
redistribute, steal, implement, or otherwise claim as
your own WITHOUT EXPLICIT CONSENT.

Glad that we got that out of the way! On with the show...


1. Overview


1.1 - Purpose

To create a text-based psudo-RPG battle system, that will
allow for a variety of user-created diverse commands, each 
generating a unique response, culminating in epic melee
fights... in text.


1.2 - Requirements

Since this is to be text-based, there is no need for fancy
APIs such as D3D or OGL. It does, however, require a MUD 
Server to run off of, and a capable one. TA would do nicely,
however, it appears there is already plans in action for
a XML-based text/graphical battle system.

The client-server system must contain provisions for player
stats, such as HP, STR, EXP, etc. These *should* be contained
within the server, and forever stay in the server. See
Security Provisions (TODO: add section # here) for more
details.


1.3 - Minimalist Structure

Preferably, all "battle commands" would be contained within
a single command, such as /attack. /attack would then have
several parameters:

/attack   (special)

The attack would be launched, the effects calculated, and
a string displayed about the attack, the effects, etc.

EXAMPLE:

 .attack dcower poke Haha

 In one fell swoop, Mushu reaches forward and pokes 
         dcower, all the while yelling "Haha". In spite of 
         this formidable attack, dcower only takes 2 damage.

 .attack Mushu poke

 In retaliation, dcower returns the favor by poking
         Mushu in the eye, resulting in a critical hit.
         Mushu takes 14 damage.

Presumably, the battle would continue until a player is
killed, the fight is broken up (TODO: add section # here),
or a player withdraws.


2. Battle Details

2.1 - Basic Rules

The following is a short list of easily-implemented rules
to help against abuse of said battle-system.

- Battles may only occur in defined areas. Other areas
  (such as common areas) will not allow battles.

- Players (users) may elect to not participate in battles
  through their own player options. This should help prevent
  abuse through forced-battle.

- There are limits on the number of times you can use any
  given attack within a certain amount of time. Since the
  attacks are used to generate response strings, limiting
  the frequency an attack can be used will increase the
  probability of the use of new attacks. This can be achieved
  either by simply denying the use of a given attack until
  a certain time limit has expired, or decrease effiency of
  that attack (or both). This will force players to learn
  a variety of attacks to become more "skilled".

- Since the attacks are inputted through a simple /attack 
  command, there should be a delay between attacks. This
  delay should vary by attack - an extremely powerful attack
  should cause a longer delay than a simple jab. Additionally,
  this should prevent scripting (since we're all programmers
  to some extent) killing humans through sheer speed.

- Attacks should be user-modifiable, but verified by an
  administrator.  Allowing users to create their own attacks
  adds customizability to the game, however, they must be
  verified to make sure they are appropriate (fair).

- Limits should be placed on the number of user-added attacks
  per user per day (or other time period). This will prevent
  server swamping and other such things resulting from
  insane amounts of attack-creatoring.

- Attacks should be given prerequisites. Ie, the attack
  "slash" should not be available unless the character has
  a blade-weapon equipped. Likewise, some attacks should
  remain unavailable to characters with low stats.


2.2 - Experience Points

Experience points can be earned in two ways: by defeating
your opponent, or by putting on a good show and earning them
from your audience.

A player who has a "dead" or "reviving" (see "Death", 2.3)
status cannot earn EXP.

2.21: Calculating gained EXP 
When you defeat another player, EXP can be calculated in a
number of ways: by the level the player was in comparison to
your own, just the level of the player, or simply a fixed 
amount (there are others). 

2.22: Distributing EXP between players
One key point to address is that in a melee system, where 
multiple players could all be attacking one another, the 
EXP must be distributed somehow. There are two main ways
to do this: all-to-one which is given either to the final
slayer, or the person who dealt the most damage, or mixed.
In a mixed system, the EXP can be divided by how much each
player dealt, how many times that player hit the vanquished,
or the % of attacks.

2.23: Level Growth
Well, there are so many different ways to do this, and since
Pouya has a minor in Statistics, he should know what's he's
doing, but in all honesty, these can be arbirtarily calculated.


2.24: RECOMMENDATIONS

- EXP gained should be proportional to the level difference.
  A higher level killing a low level should gain the killer
  minimal EXP, while a low level killing a high level should
  gain more EXP. HOWEVER, while the difference should be enough
  to encourage same-level PvP fights, it should not be insanely
  high.

- Distribution should be based solely on who has hit the player.
  Each player who has hit the vanquished will receive an 
  equal share (reducing all other shares) no matter how much
  damage was done, etc. What should happen is that if a 
  low-level randomly steps into a high v high level combat, 
  the two high-levels will kill the low-level in order to 
  get the most EXP.

- EXP required to level up should follow a quadratic relation,
  so that the amount needed will increase each level, it will
  not increase as fast as an exponential relation. The 
  reasoning behind this is in the method of gaining EXP - based
  on DIFFERENCE between the levels. Thus, if everyone is the
  same level, they will always gain the same amount of EXP.
  An exponential relation would yield an eventual max level,
  while a linear relation would make levelling too easy, 
  ultimately making players who easily outmatch all the others.


2.3 "Death"

Sometime or another, a player is going to lose a combat. Duh.
This will place the user in a "dead" status. A PERSON WITH
EITHER "DEAD" or "REVIVING" STATUS CANNOT GAIN EXP!

A person in dead status has 0 HP, and cannot engage in battles.
After a set amount of time (recomment 10 minutes) the person
goes into "reviving" status, during which HP slowly recovers.
When the person's HP reaches max, their living status is
restored, and they can once again take place in battles.

In all honesty the "dead" and "reviving" statuses can be simply
combined into one. But that's a minor detail.

There must be a delay between dying and re-entering the battle.
While some games use a EXP-penalizer, I think that a delay is
much better. Oh well.


3. Security Provisions

Well, not much here, just a little to prevent haxxoring.

- ALL CHARACTER STATS MUST BE KEPT ONLY ON THE SERVER!

- ALL DAMAGE ETC IS TO BE CALCULATED ONLY ON THE SERVER!

- ATTACK VALIDATIONS MUST BE... YOU GUESSED IT! ON THE SERVER!

Basically, the only thing the client should be doing is 
sending the server the attack command. The attack lists
should be contained in a read-only folder on the server.
The attack command should be validated, executed if valid,
results calculated, and results outputted to all clients
that should receive it.

Screw what lag may happen. It'll be funnier that way.


4. Conclusion

Well, you've made it all the way through this little document
of mine. I hope I've been at least somewhat coherent throughout
this rant, and I hope that eventually I'll know enough to
implement this kind of system. Or get someone else to do it
for me. You know what? I think I'm off to the Help Wanted
section of GDNET.

Have a nice day! ~Mushu.