Generic Object Description
Robert Baruch
sort of generic object description language so that the effect of
objects on other objects can be calculated in some fashion, instead of
just having tables and tables of interactions? Or so that new objects
can be brought in just by defining their characteristics?
I know, I know, eventually you would have to simulate every bloody
atom in every object to achieve perfect interactions. I thought
you could define classes of objects, and then determine how
classes interacted with eachother, then have subclasses if the
result of class interaction was too vague, and so on.
--Rob
Chris Harwood-Jones
>
> Msg-ID: <1992Apr3.2...@nynexst.com>
> Posted: 3 Apr 92 20:57:28 GMT
>
> Org. : Nynex Science and Technology
I have been dealing with that same problem in designing a computer RPG. Having
just moved from a structured-programming approach to an object approach (and am
redesigning from scratch), my current thoughts are far from sophisticated, but
heres what I have so far:
ROOT CLASS: "Thing"
name
weight monetary value
ability to withstand damage
how carried:
wearable (e.g. a coat),
carryable (e.g. a ball), or
liquid (e.g. a pint of beer)
how many (for object groups; e.g. "20 arrows"
type (is this object a member of a special subclass?)
SUBCLASS #1: "Container"
capacity
percentage of carried items' weight negated
(i.e. Bag of Holding or suspensor field)
does it carry liquids or solids? (i.e. wineskin vs. backpack)
SUBCLASS #2: "Armour"
protection type & value
hit location(s) affected
SUBCLASS #3: "Weapon"
hand-to-hand stats:
technique(s) required, held one- or two-handed
possible attack types
damage
speed
reach
minimum strength
(other stats as required by the combat system)
throwing stats:
(all HTH stats except that "reach" is changed to "range")
accuracy
firing stats:
(include all throwing stats except "minimum strength")
ammunition required
cartridge size (e.g. a pistol can hold 6 bullets)
reload time
SUBCLASS #4: "Spellcasting Item"
spell cast by the item
must be activated?
activation time
activation requirements (e.g. "clerics only")
number of charges
affects others?
range
NOTES:
On Weapons:
A single weapon may have multiple uses; e.g. a spear may be used hand-
to-hand or thrown, and a rifle may have a bayonet on it.
On Spellcasting Items:
Another option is to make all of these attributes part of the root class, and
thus allow any type of item to be able to cast spells.
Hope this is of some use.
--
----------------------------------------------------------------------
/ Chris Harwood-Jones ************ a3...@mindlink.bc.ca /
/ /
/ "It means nothing; and it seems, so far as I can observe, /
/ useless to others." /
/ /
----------------------------------------------------------------------
Craig Thomas Judd
Do you realise that the acronym for this would be GOD?
Which you would probably have to be, considering your first sentence in the
second paragraph...
Could you please define your definition of a GOD? I am a bit hazy about your
definition here.
Yours hazily (purple haze...purple heads?...);
--
\/\"Well, this isn't a COMIC BOOK, you know!" Yoshi, Appleseed Book 2/\/
====\/\ "You REFUSE to drink my wine...?" Kahm, Outlanders /\/====
=====\/\ *** WANT ANY MANGA ARTWORK DONE? Just email me! *** /\/=====
\/\ cj...@esk.compserv.utas.edu.au a.k.a. Kuro to Shiroi /\/
Robert Baruch
>
>I have been dealing with that same problem in designing a computer RPG. Having
>just moved from a structured-programming approach to an object approach (and am
>redesigning from scratch), my current thoughts are far from sophisticated, but
>heres what I have so far:
>
>ROOT CLASS: "Thing"
> name
> weight monetary value
> ability to withstand damage
> how carried:
> wearable (e.g. a coat),
> carryable (e.g. a ball), or
> liquid (e.g. a pint of beer)
> how many (for object groups; e.g. "20 arrows"
> type (is this object a member of a special subclass?)
>
>SUBCLASS #1: "Container"
> capacity
> percentage of carried items' weight negated
> (i.e. Bag of Holding or suspensor field)
> does it carry liquids or solids? (i.e. wineskin vs. backpack)
>
>SUBCLASS #2: "Armour"
> protection type & value
> hit location(s) affected
>
>
>--
>----------------------------------------------------------------------
>/ Chris Harwood-Jones ************ a3...@mindlink.bc.ca /
>/ /
>/ "It means nothing; and it seems, so far as I can observe, /
>/ useless to others." /
>/ /
>----------------------------------------------------------------------
Well, this sort of thing is necessary. I've looked at the object tables of
lots of adventure games, and they are all pretty much of the same type as
your system. What I am looking for is a system which allows a programmer
to add on an object, and define its reactions to a finite number of 'action'
variables, which encompasses pretty much everything you can do with an
object. These action variables could be considered primitives, from which
all other actions (or at least, most of them) can be derived.
For example, take a brick object. A programmer adds this brick object to
the database of objects. Later on some other programmer adds a hammer object
to the database. I want the system so that even if the second programmer does
not know about the brick object, the brick will react correctly when hit by
the hammer -- the brick fragments into two or three smaller brick pieces.
So we could have a primitive 'impact', which would be programmed by the
brick programmer. The brick programmer would say that soft impacts (such as
dropping from a height of a few feet) will not do anything. Medium impacts
(the hammer) will fragment the brick into several brick pieces. Hard impacts
(shooting the brick with a gun) will blow it into smithereens.
So regardless of what object actually performs the impact, you can define what
happends to the brick. Therefore, the hammer programmer would only have to specify
that when you say "Hit X with hammer", the hammer applies a medium_impact to X.
The object X then decides what happens to itself, additionally decided what to
apply to the hammer. For example, if the hammer is a funky magic hammer made of
breakable glass, then yes indeed the hammer will shatter the brick, but the brick will
then apply a medium_impact to the hammer, shattering IT!
Some kind of physical-law engine would probably apply that rule mentioned above
automatically, and so you would in effect get a law that states, "Unless otherwise
specified, if X impacts Y to degree Z, then X will also have an impact of degree Z
applied to it." The Every Action law applied to every object without any work!
--Rob
Robert Baruch
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: <920406135...@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
In-Reply-To: <1992Apr4.0...@cam.compserv.utas.edu.au>
References: <1992Apr3.2...@nynexst.com>
Organization: Nynex Science and Technology
Cc:
In article <1992Apr4.0...@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
Darrell Ulm
>> sort of generic object description language so that the effect of
>> objects on other objects can be calculated in some fashion, instead of
>> just having tables and tables of interactions? Or so that new objects
>> can be brought in just by defining their characteristics?
>
>just moved from a structured-programming approach to an object approach (and am
>redesigning from scratch), my current thoughts are far from sophisticated, but
>heres what I have so far:
I see some problems here, you are too specific for a gaming world. To
simulate reality, think form and function. Function is not armour...too
specific. Think of matierals and and actions that can transform a
material to suit a purpose...
>
>ROOT CLASS: "Thing"
> name
-- let players in the world name it.
> weight monetary value
weight is importatnt...how about matierial...linked list of elements?
> ability to withstand damage
hard one!
> how carried:
based on weight and form...also hard
> wearable (e.g. a coat),
> carryable (e.g. a ball), or
> liquid (e.g. a pint of beer)
solid, liquid, gass is importatnt...
> how many (for object groups; e.g. "20 arrows"
yes, could take and arrow...break it and thus
remove it from general 'arrow' list...then
there are 2 new items each with some characteristics
of the arrow.
> type (is this object a member of a special subclass?)
>
>SUBCLASS #1: "Container"
> capacity
> percentage of carried items' weight negated
> (i.e. Bag of Holding or suspensor field)
> does it carry liquids or solids? (i.e. wineskin vs. backpack)
>
too specific
>SUBCLASS #2: "Armour"
> protection type & value
> hit location(s) affected
>
too specific
>SUBCLASS #3: "Weapon"
> hand-to-hand stats:
> technique(s) required, held one- or two-handed
> possible attack types
> damage
> speed
> reach
> minimum strength
> (other stats as required by the combat system)
> throwing stats:
> (all HTH stats except that "reach" is changed to "range")
> accuracy
> firing stats:
> (include all throwing stats except "minimum strength")
> ammunition required
> cartridge size (e.g. a pistol can hold 6 bullets)
> reload time
>
ditto
>SUBCLASS #4: "Spellcasting Item"
> spell cast by the item
> must be activated?
> activation time
> activation requirements (e.g. "clerics only")
> number of charges
>
> affects others?
> range
>
>NOTES:
do non magical first and you are a genius!
>
>On Weapons:
dulm
Steve Dakin
Regarding Chris Harwood-Jones ideas about a generic object description and
Darrell Ulm's retorts, I'd just like to say that judging by what I read, Chris
would have a chance at actually designing, writing and finishing a game using
his ideas, Darrell would not. It's helpful to occasionally explore the
theoretical world, but if you want to actually complete a project, it's more
critical to keep one foot on the ground.
Happy designing,
Steve
Mike Hackett
YES! This is exactly what I've been thinking about for my gaming
environment software. I haven't actually got around to even properly
designing that area of the program, but I have been forming some ideas in my
head. I first came up with the idea of "intelligent" objects - where each
object is defined by bits of code instead of just statistics to be
interpreted by the controlling program. More recently, as I've become more
acquainted with OOP, I can see that, while my original ideas were pretty
farfetched, such a system can be done using classes and objects. True, you
won't obtain "prefect interactions", but with some good planning I think
many possible actions could be simulated. For example, if your character's
belonging were exposed to a fire, each object could determine for itself
what sort of damage it suffered.
/==========================================================================\
| Mike Hackett | "I don't believe you, you had the whole |
| <hac...@gaul.csd.uwo.ca> | damn thing all wrong; He's not the kind |
| Honors Computer Science III | you have to wind up on Sundays." |
| University of Western Ontario | -Ian Anderson, "Wind Up" - _Aqualung_ |
\==========================================================================/
Darrell Ulm
>
>Regarding Chris Harwood-Jones ideas about a generic object description and
>Darrell Ulm's retorts, I'd just like to say that judging by what I read, Chris
>would have a chance at actually designing, writing and finishing a game using
>his ideas, Darrell would not. It's helpful to occasionally explore the
Oh, really mister smarty pants...want to take me up on this?
Gee whiz, you dont even know me and you jump to such broad concl.
>theoretical world, but if you want to actually complete a project, it's more
>critical to keep one foot on the ground.
Where else would my feet be? I don't see what you are getting at.
Ive looked at various ai methods and think that some of them should
be applied. Application of known methods is no big deal is it?
Anyway, I cant start on this until I finish this compiler optimiser
I am working on.
>
>Happy designing,
OK, ill be happy...Thanks for the vote of confidence...chump
>Steve
Brilliant!
dulm
Chris Harwood-Jones
>
> Msg-ID: <1992Apr8.1...@mcs.kent.edu>
> Posted: Wed, 8 Apr 1992 12:21:18
>
> Org. : Kent State University
Now, gentlemen....
Rather than rag on each other, let's go back to the question. We're looking
for a "generic object description" for use in an adventure game. I proposed
some ideas for data structures which involved a few basic object "types", and
Darrell commented that I was being too specific.
I fully agree with the idea of defining objects by function. However, in an
adventure game, there is a very small set of possible functions that can affect
the game. Characters can be affected by (1) altering their character sheet, or
by (2) altering their capacity to perform various game actions (e.g. "your arms
are paralyzed" means that you can't use the functions 'get', 'drop' or 'put
away').
That is how I came up with my four subclasses: Every adventure game that I
have ever seen has objects function in at least four ways (in addition to just
being bought, sold and carried): as armour, weapons, containers or
spellcasters. Furthermore, these functions make up a relatively large subset
of all possible "interactions" in a computer adventure game.
Of course in reality, any object could have any or all of those functions: a
brick can hold a ping-pong ball, be worn on top of the head to prevent damage,
be used to hit someone and maybe even cast a spell. However, restricting type
crossover saves disk space and doesn't significantly restrict the game. 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!
It seems, and please correct me if I am wrong, that Darrell's approach has
defined the problem too broadly: he asks "how do I build a reality simulator"
as opposed to "how do I build an adventure-genre game?" I would argue,
therefore, that having defined the problem as having infinite bounds, Darrell
has prevented himself from coming up with any solution from the outset - unless
of course he is actually God and is just toying with us through the net. :)
So I would like to see Darrell's comments as to how his approach "cashes out"
in an adventure-game context.
Cheers,
Chris H-J
BILLY JOE BISSETTE
|> So regardless of what object actually performs the impact, you can define what
|> happends to the brick. Therefore, the hammer programmer would only have to specify
|> that when you say "Hit X with hammer", the hammer applies a medium_impact to X.
|> The object X then decides what happens to itself, additionally decided what to
|> apply to the hammer. For example, if the hammer is a funky magic hammer made of
|> breakable glass, then yes indeed the hammer will shatter the brick, but the brick will
|> then apply a medium_impact to the hammer, shattering IT!
|>
|>
You might want to try adding material strength to that. Sounds about like a
system I was working on for a computer rpg. Objects, in particular weapons,
have material strength and suitibility for attacks.
The information was in the form of multipliers. All a person had to do to
include a new weapon was to make it according to a template.
Ex. An epee had a Hack of 0,Thrust of 2, Bash of .something, etc. It also had
a strength lower than a sword but stronger than flesh.
The impact resulted from the force applied, and was not inherent to any object.
Expansions to teh system would have included things like a comprehensive way
to determine damage recieved by the object under various circumstances. A
weapon being used to parry would recieve less damage than a weapon being
attacked(I would probably alter the damage recieved in the parry by the skill
of the parrier)
I thought about applying this system to everything in the game, but I didn't
have the will power.
--
----------bill the clueless, bjbi...@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!!
Seth J. Golub
> 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 ************ a3...@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)
sj...@cec2.wustl.edu
Robert Baruch
>In article <1992Apr7.2...@oceania.com> st...@oceania.com writes:
<frothing at the mouth deleted>
(puzzled) I do not recall any 'retorts' by anyone. I only recall
some ideas and suggestions.
--Rob
Robert Baruch
>In article <1992Apr6.1...@nynexst.com>, bar...@nynexst.com (Robert Baruch) writes:
>|> So regardless of what object actually performs the impact, you can define what
>|> happends to the brick. Therefore, the hammer programmer would only have to specify
>|> that when you say "Hit X with hammer", the hammer applies a medium_impact to X.
>|> The object X then decides what happens to itself, additionally decided what to
>|> apply to the hammer. For example, if the hammer is a funky magic hammer made of
>|> breakable glass, then yes indeed the hammer will shatter the brick, but the brick will
>|> then apply a medium_impact to the hammer, shattering IT!
>|>
>|>
>|> --Rob
>
>You might want to try adding material strength to that. Sounds about like a
>system I was working on for a computer rpg. Objects, in particular weapons,
>have material strength and suitibility for attacks.
>
>The information was in the form of multipliers. All a person had to do to
>include a new weapon was to make it according to a template.
>
>Ex. An epee had a Hack of 0,Thrust of 2, Bash of .something, etc. It also had
>a strength lower than a sword but stronger than flesh.
>
>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!!
>
requiring any new object to have a set of base parameters (ie, hardness,
perhaps temperature, weight, etc). Other parameters could be optional. Also,
in coding, some functions, such as apply_impact, could be defined for the
object, or be left undefined. If undefined, the required parameters themselves
could determine what happens on impact, so that a programmer would not have
to run through the immense volume of possible actions. This could be a kind of
default code that would come into effect if the programmer feels nothing
special should happen for most actions. If you lick a hammer, nothing much
should happen, so that code would be default. And so if you stick a hammer
in flames, and then lick it, even though the code isn't there, the GOD system
could easily determine that you've burnt your tongue.
If you wanted something special to happen when you lick the hammer (GOD knows
why you would want to do THAT) then you would write specific code for that action,
in effect overriding the default code.
--Rob
William Henry Timmins
>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...
How about having types of objects, so that you only vary the
particulars? Like- 'terrestrial animal life form' for people and similar
beings, 'trollish animal life form' for a variety of beings based on,
say, a troll type composition. And so forth. ('masonry' could handle a
lot, and so forth)
-Meow
Robert Baruch
: > Yes, simulations can get very detailed, but the amount of
Well, you're getting a little too specific for types. Maybe just
"life form", and then some parameters which modify the life form
(such as physical characteristics, etc which all add up to 'troll').
I was hoping that instead of types (which we would all have to sit
down and make a great big list of), we could have a list of parameters
the values of which would add up to types. The 'life form' type is a
bit hard to break down into parameters because it's such a huge class
of objects, so we would just have a few, great big classes. Then we
could define lists of parameters which apply to those classes. For
example, the class 'life form' has the parameters strength, speed,
disposition, and so on. The class 'takeable objects' would have
parameters sharpness, hardness, color, temperature, length, texture,
material, etc. We could even put a parameter "force multiplier" which
will indicate whether a really sharp object is either a glove with
spikes on it (force multiplier 1) or a sword (force multiplier 5 or so).
Two-handed swords could have force multipliers of 10 or more.
So the values in the list of parameters would not necessarily immediately
tell you that the object in question is a "weapon" or a "key", but its
name sure will. So when a person comes across the object "two-handed sword",
he'll immediately know it's a weapon. How that weapon acts is up to the
parameters.
Caveat: An object designer has to think about each object carefully. For example,
there is no such thing as a class of "projectile weapons". So an object designer
will have to characterisea "gun" as a thing which causes an object "bullet" to
be thrown at great velocity. The gun object would have to have a built-in
action throw_object, which would be able to manipulate the bullet object (if
you have any!).
But the system should be designed so that aside from describing what the object is,
and what it's primary purpose is (the gun fires bullets), nothing else should
have to be said about it -- default action functions should take care of that. So
if I decide to bop someone over the head with my gun, GOD should know
immediately that the guy keels over, eyes crossed, even though the object
designer did not specify what happens
Problem: Suppose I design a sword object, and then want to hit someone over the
head with the flat of my sword. This should not kill that person. But if I
do not specify what happens, I would just kill the person because the sword is
sharp and force-multiplicative. How can we design a system where I can say
"Hit man on head with flat of sword" and have the right things happen? Does
the object designer need to pull this out as a special case and write a
function for it? Probably, since the "flat" of a sword is different from the
"flat" of a gun, especially since guns have no flat!
--Rob
Paul Lambert
>wt...@andrew.cmu.edu (William Henry Timmins) writes:
>: > 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...
>:
>: How about having types of objects, so that you only vary the
>: particulars? Like- 'terrestrial animal life form' for people and similar
>: beings, 'trollish animal life form' for a variety of beings based on,
>: say, a troll type composition. And so forth. ('masonry' could handle a
>: lot, and so forth)
>:
>: -Meow
>
.
Sounds to me exactly like a SmallTalk model for Objects: define an Object which
has a location, temperature, etc... then define a LifeForm which inherits those
features from Object, but has its own things. You could make a Troll as a type
of LifeForm, then make a Two-HeadedTroll as a type of Troll. Et cetera ad
infinitum. This would give you EXACTLY the type of model you're looking for.
If an Object defines an impacted message, then you can hit someone over the
head with a Troll (assuming you can lift it!) and it'll work. But if Trolls do
something special when you swing them, you can override it.
So what's the problem? You would have to hardcode all of this... find someone
who has written an OOE (Obj-Oriented Environment) and see how they did it (I
couldn't do it if my life depended on it...) to figure it out. Then you'll
just need a decent parser to drop your ideas from text to messages.
--Paul
(ignore this entire message if it makes no sense!)
--
-------------------------------------------------------------------------------
plam...@psuvm.psu.edu, plam...@endor.cs.psu.edu, or just plam...@cs.psu.edu
William Henry Timmins
>"life form", and then some parameters which modify the life form
>(such as physical characteristics, etc which all add up to 'troll').
>
>I was hoping that instead of types (which we would all have to sit
>down and make a great big list of), we could have a list of parameters
You misunderstood. What I meant by 'type' was a generalized
description. Essentially, one would detail an 'average type', which
would be characterstics that would change least and fully describe most
things within a type. This 'average type' could then be tweaked for each
individual example, and allow things of the same type to have certain
similarities.
Types could be expanded as much as you want, I was thinking of it more
as a convenience than as hard-coded.
Example:
Someone defines 'life form' to be able to move under it's own power,
require fuel, and has some decision making capability, as well as
composition. The fuel type will be based on WHAT kind of life form (eats
animals, plants, energy, etc), though the amount of fuel used will vary
highly.
Sorry for the confusion...
>Problem: Suppose I design a sword object, and then want to hit someone
over the
>head with the flat of my sword. This should not kill that person. But if I
>do not specify what happens, I would just kill the person because the sword is
>sharp and force-multiplicative. How can we design a system where I can say
>"Hit man on head with flat of sword" and have the right things happen? Does
>the object designer need to pull this out as a special case and write a
>function for it? Probably, since the "flat" of a sword is different from the
>"flat" of a gun, especially since guns have no flat!
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
Brian D. Leet
>>Problem: Suppose I design a sword object, and then want to hit someone
>over the
>>head with the flat of my sword. This should not kill that person. But if I
>>do not specify what happens, I would just kill the person because the sword is
>>sharp and force-multiplicative. How can we design a system where I can say
>>"Hit man on head with flat of sword" and have the right things happen? Does
>>the object designer need to pull this out as a special case and write a
>>function for it? Probably, since the "flat" of a sword is different from the
>>"flat" of a gun, especially since guns have no flat!
>
>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
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.
Keep in mind these are special situations. Any computer run/simulated
environment needs to deal with only basic variables and conditions with any
special situations and options hard-coded into the location that will allow
them to work. 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). The key
is actually to make the "basic" objects as simple and open as possible in
order to allow the most flexibility in hard-coding special options into them.
If you want an example of how the environments I have worked on run I would
be glad to post some (when I have a chance.)
Brian (@TMI, @Underdark)
Thomas Aaron Insel
> Someone defines 'life form' to be able to move under it's own power,
> require fuel, and has some decision making capability, as well as
> composition. The fuel type will be based on WHAT kind of life form (eats
> animals, plants, energy, etc), though the amount of fuel used will vary
> highly.
Neat. And then, we can have whole virtual ecologies, where various `life
forms' move around and eat each other. This should really contribute to
the effect that you're interacting with a real world, not just a fake world
presented for your personal gaming use.
--
Thomas Aaron Insel (tin...@uiuc.edu)
I speak for myself, and not for the State or University of Illinois.
"We must not confuse dissent with disloyalty." -- Edward R. Murrow
Billy Joe Bissette
In article <gdukx9q00...@andrew.cmu.edu> wt...@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, bjbi...@eos.ncsu.edu
David Howell
Ironic, really, using Object Oriented Programming to describe
objects. :)
OK: Object-->Thing
It's got a weight, a shape (probably length, width, heigth), a name,
an appearance (either verbal or graphic file or both, I suppose).
Now. Plant: Thing, and add rate of growth, needed phenomena for
growth (object sunlight, object water, etc.),
Daffodil: Plant, (set appropriate parameters), add appearance of
flowering part, timetable of flowering, etc.
Carnivorous Daffodil: inherit Daffodil, but change response to
presence of certain objects. Default response is to ignore. If
Object-->Animal is within range (dependent on size, one supposes), then
use function attack.
A Specific Carnivorous Daffodil would be scaled from the general
(80% of size, 110% of normal aggression vis a vis presence of
animal, color 10% darker than default, etc.)
A good start would be to take a specific object (George's Sword), and
describe it in detail. Then, figure out what's specific to that sword
(location of manufacture? The nick in the blade?), what's a property of
class "Long Sword" (shape, width), property of "Sword" (made of steel,
has pommel), property of "Edged Weapons" (affect of edge on Things,
<effect>, existance of point), what's a property of "Weapons" (various
actions regarding impact, I guess), and so forth. There should
also be objects like "Steel", so the sword can inherit certain fields
from that, and should probably be able to inherit surfaces. If
steel has a range of surface reflectivity, then setting it to
`polished' might cause it to inherit the "Medium Mirror" surface.
You can't really use it for shaving, but it can do a credible job of
reflecting light. It _just_might_ work for looking at a Medusa, for
example.
The first couple of objects are a bear, especially when you start
trying to deal with responses to stimuli. Below certain temperatures,
"Steel"'s response to impact should change: it gets brittle. Around
room temperatures, it would inherit "Thing"'s properties: ignore
temperature. Above a certain point, it needs to inherit properties
from "Lava" with suitable modifications.
Once "Steel" is set, though, doing "Iron", "Titanium", "ChromeMoly Steel'<
or "Adamantine" would probably be a matter of inheriting "Steel" and making
just a couple of changes. The more objects, the easier the process gets.
Yes? No?
Dave Howell
how...@blegga.cac.washington.edu
<danger-->header address is in error>