Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

Entry #33

Sign in to follow this  


  • Random Observation of the Day!!
    I can't run Maplestory anymore... I've tried everything! But it freezes after 10 minutes and after doing all kinds of messed up visual crap...

But anyway, I did manage to get some work done without it:

Text-Based Battle a la Mushu

0. Legal Stuff

Everything contained within this document is the sole
intellectual property of L Campbell ("Mushu") and MAY

By viewing this file you implicitly agree to not
redistribute, steal, implement, or otherwise claim as

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

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.


.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.


- 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

- 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

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.




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.

Sign in to follow this  


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!