HDTenEightyP/NetNews huggingface dataset:
From: sjg1@cec1.wustl.edu (Seth J. Golub)
Subject: Re: Generic Object Description
Summary: Sounds like a good LPmud
Keywords: lpmud god mud 
Organization: Washington University, St. Louis Mo.
Date: Thu, 9 Apr 1992 21:28:39 GMT

In article <11317@mindlink.bc.ca> a3619@mindlink.bc.ca (Chris Harwood-Jones) writes:
>.[...]  It also makes it much easier on the user creating his or her
> own objects:  can you imagine requiring a game user to enter ALL of
> those stats just to create a  bloody brick?  No-one would ever play
> the thing! 
>
>----------------------------------------------------------------------
>/ Chris Harwood-Jones        ************       a3619@mindlink.bc.ca /
>----------------------------------------------------------------------

This is a problem.  I'm working on a system that hopefully will do
some of these things when we're done.  Obviously it won't be a
complete reality simulator.  But it may have enough object interaction
to get by for an adventure game.  
  To anyone who's tried making a realistic game, this all sounds
pretty familiar.  It's also very difficult.  On our system, for
example, (an LPmud) we'll have an event handler.  When someone thwacks
one object with another, whether it be a sword and an orc, a brick and
a hammer, or a nose on the doorjamb, both objects will get a message
saying that something has happened.  That something is in this case a
collision.  They'll know what they are collidiing with and how hard.
The tough part is knowing what to do with this information.  
In your example, the brick would shatter into smaller pieces when hit
with enough force.  This means that we need a "shattered piece of
brick" object all ready to go.  It would probably be a generic
"brick-like-thing" on which we set the size and description in the
inherited instances.  
  This is a lot of work just to make a brick.  While someone as anal
as myself about simulating reality on these games might not blanch at
entering all that information just to make a brick, it's not something
I'd expect all of our builders to do.  Also, this is only enough to
cover things hitting eachother.  We haven't dealt with acid, fire,
water, juggling, holding various objects in one hand, and oodles of
things I'd rather not think about.
  Yes, simulations can get very detailed, but the amount of
information for each object grows as your world becomes more precise.
I'd hate to have to enter the chemical composition of a cave troll
just to have something interesting in the cave...


Seth Golub @ CS @ Washington University
Zamboni @ End Of The Line   (mud.stanford.edu 2010)
sjg1@cec2.wustl.edu
From: esper@cs35b.cs.umn.edu (Dave Sherohman)
Newsgroups: rec.games.design
Subject: Re: Skills/Attributes-General query
Date: 12 Apr 92 16:21:19 GMT
Article-I.D.: news2.1992Apr12.162119.14959
Organization: none

In article <1992Apr07.230021.7561@ecst.csuchico.edu> tdunn@ecst.csuchico.edu (Tim Dunn) writes:
>William Henry Timmins writes:
>>How about a system wherein stat and skill level are multiplied?
>>
>>This would reflect the cross effect of stats and skill... If both were
>>1-10, you would get a simple percentile system.
>
>One major complaint I have with systems such as Vampire and Cyberpunk 2020
>is their method of adding the stat and skill.  This puts them on equal

I think you misunderstood the original idea - it looks to me like WHT isn't
suggesting chance = skill + stat, but rather chance = skill * stat.  Though
it does make skill and stat values equally important in a purely mathematical
sense, it avoids the problems of a rookie with high aptitude (stat 10 * skill
1 = 10%) being better than an average person with a lot of experience (stat 5
* skill 5 = 25%).  It also addresses the matters of people with better stats
having a higher final potential and learning faster.  While the /3-*3 system
also has these advantages, this has the added plus of not requiring any
multiplying by nonintegers (unless you decide to get into a fight with a cat
whose STR is 0.15 or so...).

esper@ima.umn.edu
Newsgroups: rec.games.design
From: bjbisset@eos.ncsu.edu (Billy Joe Bissette)
Subject: Re: A new trend in roleplaying?
Organization: North Carolina State University
Date: Tue, 7 Apr 1992 16:36:40 GMT

In article <1992Apr7.013723.14841@oz.plymouth.edu>, sos@oz.plymouth.edu (Steffan O'Sullivan) writes:
|> urban@stout.atd.ucar.edu (Art Urban (PROFS)) writes:
|> >
|> >Yes! Add on products just like this are of great interest to me, but yours
|> >is of greater interest due to the inclusion of system specific information.
|> >I'm a GURPS player by choice, and would *love* to see new skills, job tables,
|> >etc.
|> 
[deletions]
|> 
|> I would think it would be far better to put *no* game-specific material
|> in the book.  Keep it systemless, like the Catalyst series, and it will
|> be worth more, since you won't be paying for all those pages of AD&D, RQ,
|> SR, RM, FH, etc., stats that you wouldn't need - and those fans wouldn't
|> need the GURPS material, either.
|> -- 
|>   - Steffan O'Sullivan		         sos@oz.plymouth.edu

I agree.  If it appears that someone/thing needs stats, just describe it.
People, I hope, can use the descriptions to convert it to the system of their
choice.  Its all relative.
-- 
----------bill the clueless, bjbisset@eos.ncsu.edu
Go, Go, Gadget Clue.  No, Gadget Clue, not Gadget Hammer!  Help Brain!
What do you mean, "The Swedish Chef got him."  Stop Gadget Hammer!
No, not Gadget Flame! Stop!  Stop!!
Newsgroups: rec.games.design
Date: Wed,  8 Apr 1992 14:25:54 -0400 
From: William Henry Timmins <wt0b+@andrew.cmu.edu>
Subject: Re: Skills/Attributes-General query

>My own conclusions on this were that attributes are aspects of character that
>are essentially fixed.  They can be modified if the character really
works hard
>at it, but things like strength, dexterity, intelligence and so on are
>basically genetic.

	Hmm. My approach is to give someone a basic list of attributes, and
then a list of modified attributes based on background.

	For example, under conditions humans were evolved for, average
strength, endurance, and size were equivalent to our average athletes.
Because of our current backgrounds, we are all fairly weaker than what
we could be.

	Strength can be modified fairly easily, but there is a basic ease of a
person to raise it. Ie- a given person has a strength 'capacity' which
is only reached through constant exercise. Most of us are much lower
than our capacity.
	Note that a given person's capacity is lowered by not getting
sufficient exercise before/during puberty.

	Mental stats are highly affected by the environment we grow in.

	I would take the approach of starting with 'basic body', the genetic
capacities of a human (which should be on the high side). Then backround
should lower theses capacities, with recent activities setting the
current level.

Affected by background:
Strength- work and effort, plus development of skeletal and muscular systems
Constitution- similar to strength
Health- the correct diet has a profound, basic effect on health
Curiousity/cunning- training and encouragement are vital here
Dexterity- usage and need for dexterity and agility, less affected than
the others
Senses- training to use effectively is necessary

comments?

-Me
From: Darrin_Hyrup@sorinc.UUCP (Darrin Hyrup)
Newsgroups: rec.games.design
Subject: Re: Dice.game
Date: 7 Apr 92 08:18:40 GMT
Article-I.D.: sorinc.Darrin_Hyrup.0029
Organization: Shades of Reality BBS

In a message dated Sun  5 Apr 92 06:33, Wigdahl@dragon.unl.edu wrote:

>[dice game mechanics deleted.]

>**********************************************************************
>*RINCEWIND THE WIZARD AT YOUR SERVICE.*tkelly@unix2.tcd.ie           *
>*Life has all the thrills of a melon. *                              *
>**********************************************************************

 WW> Pretty unoriginal -- seems highly derivative of Shadowrun combat
 WW> mechanics. :-)

Ugh!  For shame!

-- Via DLG Pro v0.991

==========================================================================
= Darrin Hyrup, System Operator           a68k.denver.co.us!sorinc!magik =
=-------------------------= FidoNet 1:349/7.0 =--------------------------=
= GEnie Mail:   //  -=- The Shades of Reality BBS -=-    //  Compu$erve: =
=   SHADES    \X/   (503) 772-0569 [9600/V.32b/V.42b]  \X/   71441,1006  =
==========================================================================
From: torbenm@diku.dk (Torben AEgidius Mogensen)
Newsgroups: rec.games.design
Subject: Re: Skills/Attributes-General query
Date: 9 Apr 92 10:08:45 GMT
Organization: Department of Computer Science, U of Copenhagen

thornt_g@cs.uwa.oz.au (Sebastian Nobwit DeLaBler) writes:

>I have a general question concerning skills and
>attributes in an rpg. Don't tell me I'm putting
>the cart before the horse, it's a general question
>so I'm not expecting an exact solution.

>What kind of rules do you use for interrelated skills
>and attributes?

>Eg. Most games have some kind of agility/dexterity 
>attribute. How does this affect skills that involve
>agility/dexterity? These are some of the approaches
>I have found.

>8) Skills have a base rating equal to a stat and build
>   from there. Eg. StarWars.

>10) Stats determine the maximum rating for skills.
>   Eg. ??

>11) Stats determine the cost of increase for skills.
>    Like, say, a high dex means that dex related skills
>    are cheaper or faster to increase. Eg. ??

All these three approaches are used in Harn Master. Your calculate a
base rating by averaging 3 attributes (which may be duplicated, like
STR/STR/DEX) and adding sun-sign modifiers. Your skill starts at some
multiple of the base (e.g. 3*base) and to increase your skill you have
to roll over your current skill on a D100+base. Thus your max skill is
100+base and you advance faster if you have a higher base.

	Torben Mogensen (torbenm@diku.dk)
 
Newsgroups: rec.games.design
From: mavra@cpac.washington.edu (Peter D. Adkison)
Subject: Re: A new trend in roleplaying?
Organization: Wizards of the Coast, Inc.
	<1992Apr6.204543.9468@ncar.ucar.edu>
	<1992Apr7.013723.14841@oz.plymouth.edu>
	<MAVRA.92Apr7081408@bailey.cpac.washington.edu>
	<1992Apr7.181006.21819@cco.caltech.edu>
Date: Sat, 11 Apr 1992 10:12:32 GMT

In article <1992Apr7.181006.21819@cco.caltech.edu> laurence@cco.caltech.edu (Dustin Lee Laurence) writes:

>   One thing I may not like about TPO is that it sounds like it presents
>   a single model for gods, etc.  How "gods" work is very, very campaign
>   dependent, just as it is story dependent in fantasy fiction.  I may
>   have the wrong impression of how TPO handles this, but what I would
>   like for such a book would be an in depth look at many, many different
>   ways of handling this.

Here's what it does:

* Outlines a set of assumptions that are the "default mode" for the
book in its entirety.

* Throughout the book there are variations to some of the rules.

* In one of the appendices major variations are discussed.

This allowed us to get pretty specific along one line of thinking,
while exposing the reader to various alternatives.

				--Mavra!
				  Peter D. Adkison
				  Wizards of the Coast, Inc.
				  mavra@blegga.cac.washington.edu

The above internet address should be used for e-mail if it is
different from the e-mail address in the header.
Newsgroups: rec.games.design
From: cleggp@aix.rpi.edu (Paul Jason Clegg)
Subject: Re: CRAN FANTASY FRPG
Organization: Rensselaer Polytechnic Institute, Troy NY
Date: Tue, 14 Apr 1992 16:33:43 GMT

Is it me or does this Cran Fantasy RPG seem like a hashing of GURPS and
Hero System?

...Paul

|FQT 1.10| This door is baroque; please call Bach later

Newsgroups: rec.games.design
From: cat@wixer.cactus.org (Dr. Cat)
Subject: Hello from Dragon's Eye
Organization: Real/Time Communications
Date: Sun, 12 Apr 92 01:33:29 CDT

Just thought I'd let everyone know I'm here.  I've been a professional
game designer for ten years, five of them spent at Origin Systems (I
was the head writer on Ultima VI).  I've just recently founded my own
company, Dragon's Eye Productions.

                                        Dr. Cat
Newsgroups: rec.games.design
From: baruch@nynexst.com (Robert Baruch)
Subject: Re: Generic Object Description
Organization: Nynex Science and Technology
Date: Mon, 6 Apr 92 13:58:20 GMT

Hallo, I see everyone has had problems reaching cjudd@esk.  Odd.

Well, here's my reply to him:

----- Transcript of session follows -----
>>> RCPT To:<cjudd@esk>
<<< 554 <cjudd@esk>... Never heard of esk in domain nynexst . com
554 <cjudd@esk>... Service unavailable

----- Unsent message follows -----
Return-Path: <mailer.nynexst.com>
Received: from poseidon.com (poseidon-gw) by mailer.nynexst.com (3.2/SMI-DDN)
id AA19510; Mon, 6 Apr 92 09:50:41 EDT
Received: from isl_img.nynexst.com by poseidon.com (4.0/SMI-4.0)
id AA05658; Mon, 6 Apr 92 09:50:11 EDT
Date: Mon, 6 Apr 92 09:50:11 EDT
From: baruch@poseidon (Robert Baruch)
Message-Id: <9204061350.AA05658@poseidon.com>
Received: by isl_img.nynexst.com (4.1/SMI-4.1)
id AA01671; Mon, 6 Apr 92 09:53:04 EDT
To: cjudd@esk
Subject: Re: Generic Object Description
Newsgroups: rec.games.design
Organization: Nynex Science and Technology
Cc: 

In article <1992Apr4.073254.2911@cam.compserv.utas.edu.au> you write:
>Do you realise that the acronym for this would be GOD?

Yeah, I saw that as I was typing it, but I decided to let others draw the
conclusion.  Congratulation on seeing it!

>
>Which you would probably have to be, considering your first sentence in the
>second paragraph...
>

For sure!


>Could you please define your definition of a GOD? I am a bit hazy about your
>definition here.

Basically, programmers get to add on objects as they like.  For example, one programmer
could add in (OK, let me think of a *different* example than the one I've constantly been
(over)using) a flammable substance such as oil.  A different programmer, later on, could
add in a gun.  Now, we know (from watching the Boob Tube) that when a gun is fired at the
floor, the bullet usually sparks.  So the GOD system would automatically know that if you
fire a gun at a shallow pool of oil, the oil will get set aflame by the sparks.

To do this, the GOD system would have to deduce that the bullet fired from the gun impacts
against the ground, and that certain types of ground will spark.  That is to say, the 
bullet, being metal, will react with the ground (being, say, concrete) in the way we all know
it does.  That sort of reaction would have to be hard coded, but the gun programmer would
simply specify that the gun fires bullets ("throws" them far and fast), and that his particular
bullets are made of metal.  The oil programmer would have to specify that it is highly
flammable.

Therefore, faced with the situation "Fire gun at oil", GOD would determine that:
(1) the bullet careens off the floor
(2) in doing so, sparks
(3) sparks ignite the oil (WHOOSH!)
(4) player's eyebrows are burnt off [or some equivalent, perhaps unhumorous thing].

You would have to sit down and think about all the 'primitive' actions and reactions, and then
you could let the programmers loose.

--Rob
Newsgroups: rec.games.design
From: bjbisset@eos.ncsu.edu (BILLY JOE BISSETTE)
Subject: Re: A new trend in roleplaying?
Organization: North Carolina State University
Date: Mon, 6 Apr 1992 21:13:45 GMT

In article <MAVRA.92Apr3063837@bailey.cpac.washington.edu>, mavra@cpac.washington.edu (Peter D. Adkison) writes:
|> This message discusses what could become a new trend in the gaming
|> 
Doesn't seem so new to me . . .

|> Now that TPO is at the printers, we have started working on our next
|> capsystem, "The Military Order," and have started thinking about
|> future capsystems like "The Economic Order," "The Criminal Order," and
|> "The Governmental Order."  The real challenge is going to be keeping
|> all the acronyms unique.  B-)
|> 
Just make 26 of the things.  Although I doubt The Zygote Order will be a big
seller.

|> * Does this sound like an interesting approach?
|> 
Yeah, its interesting.  You're the first person/group I know of to go that deep
(256 pages?) into a single subject.  But some subjects need that much
to complete the job. 

|> * Do you think that going into great depth on one topic is good, or a
|> time-wasting overkill?
|> 
Someone will say its overkill, some may say its not enough.  Personally, I
think that if you're going to get something pre-fabricated, you should get the
most possible, For Your Money.  I noticed that your post didn't mention cost.
Remember, anything will sell at the right cost.  But TPO sounds like it will
be Expensive.  I wouldn't really want TPO myself, but I'm sure that there are
people who do.  Besides, you'll probably later come up with an idea that I will
like.

|> * Do you have any ideas for interesting capsystem products?
|>
Stay away from magic!
 
What I'm looking for are some precise weapon descriptions(stats not necessary
if comparisons are given) and effects, something dealing with castles would be
nice(I couldn't design a castle to save a kingdom), etc.  It probably won't
fit into your system of products, but a book/supplement on fortresses would be
great.  It could cover design, construction, cost, etc, of a fortress/castle/
base of any time period.  The basics of the reasons for a castle would have to
be given, along with what it is supposed to accomplish.  Examples of real and
imaginary fortresses could be given, along with the guidelines in mind when
they were created.  Heck, does anyone know if such a product exists?  I could
sure use it.

|> I'm looking forward to hearing from as many of you as possible.
|> 
|> 				--Mavra!
|> 				  Peter D. Adkison
|> 				  Wizards of the Coast, Inc.
|> 				  mavra@blegga.cac.washington.edu
|> 
|> The above internet address should be used for e-mail if it is
|> different from the e-mail address in the header.

-- 
----------bill the clueless, bjbisset@eos.ncsu.edu
Go, Go, Gadget Clue.  No, Gadget Clue, not Gadget Hammer!  Help Brain!
What do you mean, "The Swedish Chef got him."  Stop Gadget Hammer!
No, not Gadget Flame! Stop!  Stop!!
From: bjbisset@eos.ncsu.edu (Billy Joe Bissette)
Newsgroups: rec.games.design
Subject: Re: Generic Object Description
Date: 15 Apr 92 01:01:54 GMT
Organization: North Carolina State University

In article <1992Apr14.182251.3182@acsu.buffalo.edu>, leet@acsu.buffalo.edu (Brian D. Leet) writes:
In article <gdukx9q00aw9A1y1YY@andrew.cmu.edu> wt0b+@andrew.cmu.edu (William Henry Timmins) writes:
>>
>>Use a different action... for example, 'hit <target> with <object>' just
>>smacks a target with a flat or blunt part of your object. 'cut' can be
>>used if you have a sharp edge, and 'stab' if you have a point.
>>
>>-Me
>
>What about strike, skewer, slash, bash, pierce, etc...?  At some point you 
>need to draw a limit here.  Based on my experience in OOE (LPmud, basic mudlib

You wouldn't need that many.  First of all, their are only so many ways for
something to damage something(No flames, I know what you're trying to say).
I think William is saying the same thing as I have earlier.  This part of the
GOD discussion is about assigning damage, not parsing words.  From your verbs
listed above, probably slash, bash, and pierce,(You need to add something like
entangle) would be used.  Strike is too generic, as specific forms of attacks
are needed here(for various types of damages and effects).  Skewer maybe
would be covered under pierce.  

>design) I would say you are trying to do just a bit too much.  The best way 
>to go about it would be to set up the sentence/command parser to be flexible.
>Then if you hard-code into the sword that you can use a command like:
>Hit troll with flat of sword
>A special routine/function in the sword may be called.  If you try:
>Hit troll with flat of axe
>and axes do not have this special "variation" coded into them the parser may
>ask a question like: "Do you wish to hack the troll with your axe?" since it
>notices the word axe in the command used with other terms it does not 
>recognize.

You do have some good points which can be applied to a parser for a
computerized version of GOD(I must admit, I feel uncomfortable with that name).
Someone entering strike as a command could do damage with the aspect that does
the most damage.(PS  Axes have flats, and with the right amount of force, I'm
sure they would be rather effective).  Words not supported in the parser could
be returned in a prompt for another verb. 

>   I have no clue how many verbs there are in the English language
>but i doubt you could code them all (nor would you have reason to)

Too many.  Trust me.  I sat down and wrote every verb I could think of one day.
I probably missed some, and I wrote some wierd ones(spit as an attack?  The
person[or creature] could have something in its mouth).  And no, I won't post
the list.  I have better things to do with my life than to wear out my fingers
on something that wouldn't be used.  If someone would want it, start the list
yourself and post it with a request for additional ones.

-- 
----------bill the combustible, bjbisset@eos.ncsu.edu
From: db@dcs.ed.ac.uk (Dave Berry)
Newsgroups: rec.games.design
Subject: Re: PBeM: creating/joining governments?
Date: 8 Apr 92 14:17:24 GMT
Reply-To: db@dcs.ed.ac.uk (Dave Berry)
Organization: Laboratory for the Foundations of Computer Science, Edinburgh U

In article <1992Apr8.010621.12442@usenet.ins.cwru.edu> mxb8@po.CWRU.Edu (Matthew Bakaitis) writes:
>	Actually, I would assume that similar is used in other games also.

Yes - Britannia and Empires of the Middle Ages come to mind.

I think that either such agreements should be of limited duration or the
game should provide some way of breaking them at a possible cost to the
player who breaks them.  For example, if you breeak a binding agreement
in EMA, players can vote to excommunicate you.  Not nice - but if the
other players need your help to bring down the leader and your binding
agreement is in the way, ou could be safe.

Dave.
--
 Dave Berry, LFCS, Edinburgh Uni.      db%dcs.ed.ac.uk@nsfnet-relay.ac.uk

Authority is arbitrary.          Nobody is normal.         Assume nothing.
Newsgroups: rec.games.design