[MUD-Dev] Re: Combat

Jon A. Lambert jlsysinc at ix.netcom.com
Mon Apr 28 15:08:37 New Zealand Standard Time 1997


> From: Chris Gray <cg at ami-cg.graysage.edmonton.ab.ca>
> [Jon L:]
> :D&D/AD&D
> :Cyberpunk 2000 
> :Rolemaster
> 
> Can you use any of those without getting into copyright problems? I thought
> I had seen posts in the newsgroups about TSR getting upset with MUD people
> using their system too closely? 

While I am not a lawyer, although I have role-played one ;-) , it is my
opinion that many of TSR's claims to copyrights is ridiculous.  That 
being said, its a moot point for most of us, since they can and have 
shut down many FTP servers in the last 3 years.  With the exception of
armor, DIKU looks like and feels like D&D campaign run amok from 
the player perspective.  Should TSR decide to press the issue, I think
they could be successful in proving DIKU to be a derived work 
(kind of a "might makes right" issue).

Iron Crown, Palladium and Steve Jackson Games to name a few have 
far more liberal policies than TSR.   Some of these companies web pages
even provide links to "un-official" gaming aids.  Iron Crown has even
distributed independent software relating to their games for a reasonable
charge, even though said software is freely available on the net.
IC has acknowledged in their gaming material relating to rolemaster that
play over the internet occurs and mentions that it sometimes this is 
automated (tacit approval?).  IC happens to hold a significant interest
in the gaming rights to Tolkien's Middle Earth material (MERP) and rather 
tightly as you might imagine.  I would imagine all of  the companies
would oppose any commercial venture in regard to running a muds based
on their systems or direct quoting and publishing of information from
a literary standpoint.

I plan on informing Iron Crown in any event and inviting them on for
comment.   Worse case, they ask me to remove the offensive beast
else they'll sue for 5 gadzillion dollars and imprisonment of 10 years
with Bubba the troll with CL writing the script. *yikes* 
I plan my server to be easily configurable enough to adapt to another
FRP system with no pain.
I can think of a whole range of other more pleasant outcomes, too. :-)

> Also, those three seem to be round based.
> My current system has no concept of "is-fighting" - the player can issue
> any command at any time. Implementing such a state sounds like a lot of
> work, perhaps moreso for me, since I have no states at all right now.
> 
> I sort-of get the same effect with a couple of main things:
> 
>     - the NPC's keep track of who last attacked them, and continue attacking
> 	that PC, regardless of what the PC does
>     - if the PC runs away from a fight, an NPC they were fighting has a
> 	chance to either block them or get in one last free hit
>     - if the NPC encounters the PC again, they will continue hitting
> 
> So, the state is on the NPC, which is a lot easier to handle!
> 

I've always considered a combat round to mean the division of combat
into segments with the intent of allowing more or less equal participation,
decision making, and granularity in the result.

I would venture to guess that if your NPCs make their attacks regular time
frames of duration X and your PCs attacks/commands are processed at a 
regular rate of Y(orX) duration you do indeed have rounds.  

I use a combat state on all participants to note that time has changed for them
relative to the performance of actions, to allow some level of automation for
them and to apply modifiers to the attempt to complete actions.  Round based
with actions costing certain amounts of time.

For instance picking a lock is much harder while someone is attempting
to beat you to death with a huge club.  In addition picking a lock takes
several minutes of game time, whilst many swings of that club could 
occur during the same period.  It depends on how far you want or
need to go with realism thingy.  My potential players seem to want
complexity in this area with a no-brainer interface (yeah right).

JL
 






More information about the MUD-Dev mailing list