DESIGN: Coordinate systems, etc (Was Character Death Real)
Nathan F. Yospe
david...@pobox.com wrote:
:In article <EE3Ap...@sunsrvr6.cci.com>,
:Shawn Halpenny <mala...@iname.com> wrote:
<lots of stuff about Dartmud snipped - sounds interesting... read the orig>
:>This is where I'm going with it, anyway :)
:Sounds interesting; you may want to pop over to Dartmud anyway, to
:see how they've dealt with it.
:(dartmud.com 2525)
:(sneaky subliminal(not) advertising: DartMud is LP based, has been around
:for about 4-5 years now, fully skill-based, with skills for fighting,
:magic, thieving, farming, cooking, refining, juggling and many many
:more. Hex-mapped wilderness areas, limb-based combat, many races,
:large world with well-coded areas and lots to do. Come along and play
:sometime :)
Sounds interesting. Much better than the usual. I noticed the hex-based
wilderness thing... out of curiosity, how is that displayed? Can't be a
nsew thing (thank goodness), so I'm assuming "ahead", "to the right",
"to the left", and "turn right", "turn left"... I did this with an early
version of my GURU project, though it used a hex-tile graphical display
instead of text. It has since, like the rest of my mud projects, left
fixed directions behind, but the concept remains viable, relative to the
cardinal (nsew) system.
The skill based system is another plus. Have you implemented a system
for gain and decay? Sympathetic improvement in related skills? Skill
atrophication and relearning of atrophied skills at an accelerated
rate? Attribute and/or natural talent influences on skills? Tell us
more!
Limb based combat. Hmm. Is it _true_ limb based? Do limbs take damage
and penalties for that damage? Inbuilt reflexes in limbs? Are limbs a
simple list of numbers on the character, or are they effective objects
in their own right, possibly with reflexes and skills built in? What
happens when a limb is severed? For that matter, can a limb be replaced
with something artificial or enchanted? There are definite advantages
to making bodies from composed elements, and making damage apply to all
objects (all physical objects, at least)...
What of the races? Are they humanoid? Are there non humanoid races to
play? Avians, aquatics, amphibians, hive minds? Could a race be made
to simulate an amorphous blob, or even a cloud of sapient gas? *grin*
Don't take this wrong, I'm just playing devils advocate...
Well coded areas is a good thing. Are they dynamic? Persistant? Puzzles?
Action/combat themed? What's special about them?
Even if it isn't all of the above, what you've described is better
than most of the stuff out there... but don't let that stop you from
going further!
--
Nathan F. Yospe | There is nothing wrong with being a sociopath. Its
yo...@hawaii.edu | getting caught thats a problem. Be a mad scientist
UH Manoa Physics | Write poetry. Be an artist. Plot world domination.
Biomedical Phys. | Panthers make great pets. Muhahahahahahahahahaha!!
Dan Shiovitz
In article <yospe-ya02408000...@News.hawaii.edu>,
Nathan F. Yospe <yo...@hawaii.remove.this.edu> wrote:
[..]
>What of the races? Are they humanoid? Are there non humanoid races to
>play? Avians, aquatics, amphibians, hive minds? Could a race be made
>to simulate an amorphous blob, or even a cloud of sapient gas? *grin*
>Don't take this wrong, I'm just playing devils advocate...
I'm a little skeptical that anyone could make a world where some
characters are blobs or sapient gasses. There's a point at which the
problem is not that it's impossible to code something, it's just too
much work to create a world that accomodates that thing. Here, for
instance, I can't imagine that you could make a world where people can
have forms that slip through cracks. This means every single object
will have to know if it's airtight or not, and it should be possible,
for instance, for this cloud of gas to fly inside a piece of swiss
cheese. And what does it see in there? Someone's going to have to
write the description of "inside a piece of swiss cheese." Until
automatic text generation gets a heck of a lot better than it is, the
burden of creation lies solely on the shoulders of humans.
(And yeah, I guess you could do a half-assed implementation of a gas
race, and, say, just not allow them to pick up or wear anything, and
let them fly through doors, and call that good enough. But IMO, it's
usually better not to do it than do it badly.)
[..]
>Nathan F. Yospe | There is nothing wrong with being a sociopath. Its
>yo...@hawaii.edu | getting caught thats a problem. Be a mad scientist
--
Dan Shiovitz :: scy...@u.washington.edu :: sh...@cs.washington.edu
..................................................................
"Alas, I do not rule the world and that, I am afraid, is the story
of my life: always a godmother, never a God." -- Fran Lebowitz
...http://weber.u.washington.edu/~scythe/home.html................
Nathan F. Yospe
scy...@u.washington.edu (Dan Shiovitz) wrote:
:In article <yospe-ya02408000...@News.hawaii.edu>,
:Nathan F. Yospe <yo...@hawaii.remove.this.edu> wrote:
:[..]
:>What of the races? Are they humanoid? Are there non humanoid races to
:>play? Avians, aquatics, amphibians, hive minds? Could a race be made
:>to simulate an amorphous blob, or even a cloud of sapient gas? *grin*
:>Don't take this wrong, I'm just playing devils advocate...
:I'm a little skeptical that anyone could make a world where some
:characters are blobs or sapient gasses. There's a point at which the
:problem is not that it's impossible to code something, it's just too
:much work to create a world that accomodates that thing. Here, for
:instance, I can't imagine that you could make a world where people can
:have forms that slip through cracks. This means every single object
:will have to know if it's airtight or not, and it should be possible,
:for instance, for this cloud of gas to fly inside a piece of swiss
:cheese.
OK, I'll admit the cloud was a bit much, if nothing else, because
I can't think how it would remain together. I do have diffusion and
airtightness integral to the world in my own system, though... its
a major thing when many areas are spaceborne... and hive minds with
thousands of components and amorphous blobs are both available as
racial selections, though I have a lot of kinks left to work out...
:And what does it see in there? Someone's going to have to
:write the description of "inside a piece of swiss cheese." Until
:automatic text generation gets a heck of a lot better than it is, the
:burden of creation lies solely on the shoulders of humans.
I do more auto text generation than human designed text at this point.
Admittedly, the really spectacular scenes are all human designed, but
the generic scenes (inside swiss cheese, for example) use generated
text.
:(And yeah, I guess you could do a half-assed implementation of a gas
:race, and, say, just not allow them to pick up or wear anything, and
:let them fly through doors, and call that good enough. But IMO, it's
:usually better not to do it than do it badly.)
I agree absolutely with the last bit.
--
Nathan F. Yospe | There is nothing wrong with being a sociopath. Its
yo...@hawaii.edu | getting caught thats a problem. Be a mad scientist
Chris Lawrence (Contra)
Dan Shiovitz (scy...@u.washington.edu) wrote:
: I'm a little skeptical that anyone could make a world where some
: characters are blobs or sapient gasses.
I currently have a number of body types:
Various forms of humanoids.
Swarm intelligences (typically insect swarms)
Variations on things that look a lot like a seal crossed with a
brontosaurus crossed with Elmo (ie streamlined, aquatic, long neck,
wiggly arms, ambidextrous).
Ameoboid blobs (various levels of flexure).
Various forms of
Various forms of sessile inteliigences (rocks, silicon, trees, etc).
Various forms of fungoid/plants (mobile trees essentially).
I don't have a gaseous form, mostly as I don't (currently) have any environs
which would support it (dissolution in the wind ain't fun -- talk about
having your mind drift).
: There's a point at which the
: problem is not that it's impossible to code something, it's just too
: much work to create a world that accomodates that thing.
Good modular design helps .
: Here, for
: instance, I can't imagine that you could make a world where people can
: have forms that slip through cracks.
Well, I made (or am making) a couple changes:
No room concept at all.
Nested coordinate system.
The result is that if the object has a hole in it, and the hole is big
enough for the body (or a body part) to fit thru, it can. Of course putting
the hole there in the first place is a design question (I have a lot of
doors with locks whose key-holes lead nowhere).
: This means every single object
: will have to know if it's airtight or not, and it should be possible,
: for instance, for this cloud of gas to fly inside a piece of swiss
: cheese. And what does it see in there?
Err, cheese? </facetious>
--
J C Lawrence Internet: co...@ibm.net
---------------(*) Internet: claw...@cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...
Dan Shiovitz
In article <5snipk$ah4$3...@ocean.cup.hp.com>,
Chris Lawrence (Contra) <claw...@cup.hp.com> wrote:
>Dan Shiovitz (scy...@u.washington.edu) wrote:
>
>: I'm a little skeptical that anyone could make a world where some
>: characters are blobs or sapient gasses.
>: There's a point at which the
>: problem is not that it's impossible to code something, it's just too
>: much work to create a world that accomodates that thing.
>
>Good modular design helps .
I suppose, for the coding. I'm still just unconvinced that people
have the time to make a world that uses this. Could you possibly post
an example of the description in your game language for, say, an
enclosed room with a door?
I'm coming from a primarily diku background here, and I can't imagine
the work involved in designing a large world where you have to go
through for each exit and decide if it's airtight, watertight, locked,
if so, what kind of lock it has, what material the door's made out of,
what material the handle's made out of, how large the doorway is and
what shape it is, etc. It just seems like too much work, even using
templates ("ok, this door is a standard door #307, and this is a
standard door #408").
[..]
>--
>J C Lawrence Internet: co...@ibm.net
>---------------(*) Internet: claw...@cup.hp.com
Dan Shiovitz
In article <871465200.5112.2...@news.demon.co.uk>,[..]
>: I'm coming from a primarily diku background here, and I can't imagine
>: the work involved in designing a large world where you have to go
>: through for each exit and decide if it's airtight, watertight, locked,
>: if so, what kind of lock it has, what material the door's made out of,
>: what material the handle's made out of, how large the doorway is and
>: what shape it is, etc. It just seems like too much work, even using
>: templates ("ok, this door is a standard door #307, and this is a
>: standard door #408").
>
>here. So, you have to create a template in the beginning, but once you've
>got one, you don't need to redo the work. Hell, you could even have some
>kind of inheritance and define subtypes.
It's not that templates are too much work, really, it's that designing
a very complex area is too much work, and templates don't lower the
load enough. As another example, if I wanted to model this room I'm in
with 95% accuracy, say, I'd have to create at least a thousand items;
even if none of those items were original and all were instances of
predefined templates, it's still too much work. And that's just one
room. It's simply not possible to have people build areas at that
level of detail for muds.
The obvious response to that is "Well, duh. Don't model everything in
the room .. Who cares about the nails that hold the shelves to the
walls?" And that's right, of course. But IMO a similar argument gets
applied to some features that I've seen people discuss elsewhere; who
cares about wave motions of sand dunes, if as a builder I've got to
decide on wind speed and what kind of sand it is and what the moisture
content of the air is and so on (sorry Nathan ;P)
On the other hand, it's possible to do the equivalent of artificial
text generation for building areas, and have the game essentially
build its own areas (probably with some prompting, like "have the evil
duke design a castle in this swamp"). That lets you make areas as
complex as you want, because there's no real need for humans to make
all the decisions about every door. But if you're going to have
human-written areas, there is going to be some upper limit on the
number of features you can use.
>Maddy
>Email : gath...@zippy.spods.dcs.kcl.ac.uk
Nathan F. Yospe
scy...@u.washington.edu (Dan Shiovitz) wrote:
:I suppose, for the coding. I'm still just unconvinced that people
:have the time to make a world that uses this. Could you possibly post
:an example of the description in your game language for, say, an
:enclosed room with a door?
:I'm coming from a primarily diku background here, and I can't imagine
:the work involved in designing a large world where you have to go
:through for each exit and decide if it's airtight, watertight, locked,
:if so, what kind of lock it has, what material the door's made out of,
:what material the handle's made out of, how large the doorway is and
:what shape it is, etc. It just seems like too much work, even using
:templates ("ok, this door is a standard door #307, and this is a
:standard door #408").
See my recent post to the "Interested in implementing the scan" thread,
describing a scene using Physmud++, and the equivalent in Rom. Below, I
will paste the room source.
lifetrees{
ObjectPrototypes{
Rooms{
> telestation{
Dimension(500, 500, 500)
Wall{
Dimension(500, 500, 6);
Material(aluminum);
Position(250, 0, 250);
}
Wall{
Dimension(500, 500, 6);
Material(aluminum);
Position(0, 250, 250);
}
Wall{
Dimension(500, 500, 6);
Material(aluminum);
Position(-250, 0, 250);
}
Wall{
Dimension(500, 500, 6);
Material(aluminum);
Position(0, -250, 250);
Door{
Dimension(250, 100, 6);
Material(steel);
Lock{
Type(retina);
Security(5);
Access(touchpad);
Strength(10);
}
}
}
global.items.controlcomp{
Position(0, 249, 100);
}
} // immediate result - a barren room with a computer/WC generator
}
SubstanceTemplate
Maddy
Dan Shiovitz (scy...@u.washington.edu) wrote:
: In article <5snipk$ah4$3...@ocean.cup.hp.com>,
: Chris Lawrence (Contra) <claw...@cup.hp.com> wrote:
: >Dan Shiovitz (scy...@u.washington.edu) wrote:
: >: I'm a little skeptical that anyone could make a world where some
: >: characters are blobs or sapient gasses.
: [..]
: >: There's a point at which the
: >: problem is not that it's impossible to code something, it's just too
: >: much work to create a world that accomodates that thing.
: >
: >Good modular design helps .
: I suppose, for the coding. I'm still just unconvinced that people
: have the time to make a world that uses this. Could you possibly post
: an example of the description in your game language for, say, an
: enclosed room with a door?
: I'm coming from a primarily diku background here, and I can't imagine
: the work involved in designing a large world where you have to go
: through for each exit and decide if it's airtight, watertight, locked,
: if so, what kind of lock it has, what material the door's made out of,
: what material the handle's made out of, how large the doorway is and
: what shape it is, etc. It just seems like too much work, even using
: templates ("ok, this door is a standard door #307, and this is a
: standard door #408").
Templates are too much work? All you do is say - put this type of door
here. So, you have to create a template in the beginning, but once you've
got one, you don't need to redo the work. Hell, you could even have some
kind of inheritance and define subtypes.
Maddy
--
The Gathering ------------------------------------------------------------
Telnet: tg.spods.dcs.kcl.ac.uk 5000
URL : http://tg.spods.dcs.kcl.ac.uk/
Email : gath...@zippy.spods.dcs.kcl.ac.uk
--------------------------------------------------------------------------
Nathan F. Yospe
scy...@u.washington.edu (Dan Shiovitz) wrote:
:It's not that templates are too much work, really, it's that designing
:a very complex area is too much work, and templates don't lower the
:load enough. As another example, if I wanted to model this room I'm in
:with 95% accuracy, say, I'd have to create at least a thousand items;
:even if none of those items were original and all were instances of
:predefined templates, it's still too much work. And that's just one
:room. It's simply not possible to have people build areas at that
:level of detail for muds.
This is not precisely true... it _is_ more difficult to put together
such an area, but that does not mean that it is going to require the
degree of detail you imply. The secret is in the degree of automation.
Its like this: You create a desk prototype. You set its structure,
make certain details variable, then set up potential variables for
contents and such. This is your generic desk object, and simplifies
the situation considerably. Make an office desk, etc. Do I do this?
Not often. But you see, the thing is, I set it up as possible. Its
not a matter of detailing a real room perfectly, its a matter of
designing a plausible room. So the desk template handles everything
associated with it, and then the builder decides to adjust it... the
template can be rerolled, or maybe just a computer added... There is
another aspect to this... the desk _has_ no contents until someone
takes a close look, just a content generating condition, and a list
of special cases. This goes on a lot. There is no way I could handle
the complexity of Sing2 without this sort of thing...
:The obvious response to that is "Well, duh. Don't model everything in
:the room .. Who cares about the nails that hold the shelves to the
:walls?" And that's right, of course. But IMO a similar argument gets
:applied to some features that I've seen people discuss elsewhere; who
:cares about wave motions of sand dunes, if as a builder I've got to
:decide on wind speed and what kind of sand it is and what the moisture
:content of the air is and so on (sorry Nathan ;P)
Not at all. I understand exactly what you are saying. But its not
really as bad as all that. There is a default sand... if you want
something more, it can be modified. This is all online, so its not
like that file (see the posts on this and the "interested in" thread)
is actually edited by hand. The initial area is a flat expanse of
scrub grass, earth grav and air, no moon, etc. Nodes can be created
and templates exist for many variants, to the point that, with one
set of templates, a merc area or circle world could be read in, and
would exist as a series of inaccurately described steel boxes, six
meter cubes, sitting on a plain of scrub, or hanging over, or under,
or connected by tunnels if there is an overlap of rooms... and then
edited to fit its description. Or not. Of course, I would never let
such an area be part of the real game world, but I _do_ support it.
Likewise with the dunes. There are about seven types of sand (not
counting gravels) in my library, and the default one does not make
good dunes... nor is the default weather right, or the moisture of
the air... but there is an entire desert you can inherit as a place
to start. This is how I handle things. You tweak it online, until it
fits your vision.
:On the other hand, it's possible to do the equivalent of artificial
:text generation for building areas, and have the game essentially
:build its own areas (probably with some prompting, like "have the evil
:duke design a castle in this swamp"). That lets you make areas as
:complex as you want, because there's no real need for humans to make
:all the decisions about every door. But if you're going to have
:human-written areas, there is going to be some upper limit on the
:number of features you can use.
No limit. Mix and match to the ability, ambition, and desire of each
builder... have a system that allows humans to write whatever they
want, or as much as you can handle... make it possible, but don't
make it required. Default as much as possible. My creation engine,
my character "subconcious" system, my input parser, all make extreme
assumptions. A lot of people are going to hate that... but I think of
it like this: an autopilot that lets you adjust its behavior, nudge
it... but that takes as much of the tedium as possible out of your
hands. My system is mostly autogenerated, assembled by builders as
much as written... but builders can do all three... assemble, write,
and program. The level of effort is proportional to the level of
unusualness of the area. Anything done before can be used and modified,
and vast parts of any world are automated background. Slums, Jungles,
Deserts, Forests, Swamps, Suburbs, Asteroid fields... all are free
for copy and customization for a new circumstance. Take that alien
desert, and make it fit _your_ world. Change the plants, the type
of sand, and the air... and suddenly, it looks like an entirely
different world. It generates itself...
Chris Lawrence (Contra)
Dan Shiovitz (scy...@u.washington.edu) wrote:
: In article <5snipk$ah4$3...@ocean.cup.hp.com>,
: Chris Lawrence (Contra) <claw...@cup.hp.com> wrote:
: >Dan Shiovitz (scy...@u.washington.edu) wrote:
: >
: >: I'm a little skeptical that anyone could make a world where some
: >: characters are blobs or sapient gasses.
: [..]
: >: There's a point at which the
: >: problem is not that it's impossible to code something, it's just too
: >: much work to create a world that accomodates that thing.
: >
: >Good modular design helps .
: I suppose, for the coding. I'm still just unconvinced that people
: have the time to make a world that uses this. Could you possibly post
: an example of the description in your game language for, say, an
: enclosed room with a door?
I actually don't have that simple an expression. My current form involves
generation of large matricies defining basic geometric shapes which are then
aggregated (additively and subtractively) in a defined sequence to create
a shape.
For a room, the sequence would be something as follows:
Define cuboid of X, Y, Z dimensions. This gives you the exterior
surface of the room/hut.
Subtract from it cuboid of x, y, and z dimensions. The creates the
interior surface.
Subtract again a new cuboid of A, B, C dimensions. This creates the door
in one wall.
Define a cuboid of a, b, c dimensions. This is the door.
and so on with the process for defining the lock and handle etc.
Oh yeah, and each of the above has a coordinate location relative to a
defined origin, as well as defined orientation as relative to that origin
and a second defined point.
In the case of a room within a larger building, the shared walls with other
rooms define its dimensions. Typically those walls would be just thin sheets
of material which are then covered with some pattern/texture.
As far as gaps are concerned, they are implicit in the dimensions above.
Properly done I guess I should have wooden doors not be airtight etc, but I
don't bother with that level of detail.
--
J C Lawrence Internet: co...@ibm.net
---------------(*) Internet: claw...@cup.hp.com