[MUD-Dev] Re: Reputations, More Mazes
Eli Stevens {KiZurich}
c718157 at showme.missouri.edu
Sun Jan 17 03:21:11 CET 1999
J. C. Lawrence:
>??? You questioned the signal to noise ratio of the list, or of your
>ability to contribute to the list? Ouch.
Sorry, I was unclear. In the past, I have not posted trivial ideas that
have been sparked by the list because I did not think that they would
significantly add to the conversation. I am slowly getting a better
idea of where the line between brainstorming and spam is drawn here. :)
The S:N of Mud-Dev is great. Lurking here gives me a lot to ponder,
some of the views I agree with, some I do not, but they all make me=20
think.
Actually, I think I may have come across wrong a few times in my post,
(I will try and refrain from posting late at night in the future :) so
bear with me while I clarify (and apologize if I offended).
Me:
>> ...for a sophomore in college with a scant four years (mostly self
>> taught) of programming experience. =20
No judgement was intended on the value of self teaching here, I was=20
just giving a bit of my background. :)
Me:
>> Quzah's thread on the "maze of the mind" system got me thinking on a
>> better way to model vast, twisting, untamed wilderness without
>> having to store thousands of rarely visited rooms (much less code
>> them).
"Better" refered to manually coding large mazes, not Quzah's method
of maze generation.
---
>In principle this is good stuff (and well workable). The problem is
>translating it to a workable, interesting and believable environment
>within the game world. Nobody here has yet done that, tho we have all
>nodded out heads wisely and said, "Yes, that's a good system that
>would work well in principle." Implementation is a whole other bitch:
>
> Okay, you have a random value. Exactly how do you translate that
>into a generated room which is fairly consistent with the rooms
>surrounding it (encluding those NE/NW/SE/SW), or is at least
>believable without being a very simple variation of combinations of a
>few components in a room:
>
> Tree? Yes/No
> Rock? Yes/No
> Pond? Yes/No
> etc.
>
> Simple random combinations of the above makes for a mighty boring
>area.
Even with a decent paragraph splicer and fancy ways of saying the same
thing, I am afraid you are right.
Perhaps if the group carries three or four (or 17, whatever) bytes of=20
data along with the seed, and used them as restrictions to the possible=20
outcomes it might work better?
/*---*/
char *ground_desc[] =3D {
"craggy and mountainous",
"rough and broken",
"gently hilled",
"mostly flat"};
char *tree_desc[] =3D {
"blue spruce"
"pine and oak"
"oak and silver maple"
"maple and birch"};
char *underbrush_desc[] =3D {
"carpets of needles"
"leaves and thick ivy"
"shrubs and berry bushes"
"thick brambles"
byte ground_val =3D 2;
byte tree_val =3D 2;
byte underbrush_val =3D 0;
print( "Around you tower " + tree_desc[tree_val + rand(2)] +=20
" trees, dappling the sun on the " +
underbrush_desc[underbrush_val + rand(2)] +
" that cover the " + ground_desc[ground_val + rand(2)] +
" ground." );
/*---*/
A run of this might result in:
Around you tower oak and silver maple trees, dappling the sun on the
leaves and thick ivy that cover the gently hilled ground.
As long as the _val s stay the same, the land described will stay very
similar. The values only change when the players move in a direction
specified to increase a value.
Ex: Use the above simple example, but replace the arrays with sparsly
populated arrays of size 256 (sparse to allow easy additions and to=20
allow some items to happen more often), the rand(2) with rand(17) and
limit the byte _val to 256 - 17. Now, when the players step n, ne, or
nw, add one to the tree_val. Going s, sw or se subtracts one, and so
on for all the _val s (possibly with different directions). Then add
more templates, make each paragraph a template, etc. Of course, there
will always be some funky rooms, but... over all I think it would
work, provided enough word choices were given. =20
I suppose the best way to find out would be to code it. Ick. :)
Silence is random
Eli - c718157 at showme.missouri.edu
More information about the mud-dev-archive
mailing list