MUD-Dev
mailing list archive
[ Other Periods
| Other mailing lists
| Search
]
Date:
[ Previous
| Next
]
Thread:
[ Previous
| Next
]
Index:
[ Author
| Date
| Thread
]
Re: [MUD-Dev] 3D engines for MUDs
- To: mud-dev#null,net
- Subject: Re: [MUD-Dev] 3D engines for MUDs
- From: cg#ami-cg,GraySage.Edmonton.AB.CA (Chris Gray)
- Date: Mon, 23 Mar 98 13:52:19 MST
- >Received: by ami-cg.GraySage.Edmonton.AB.CA (V1.17-beta/Amiga) id <8w4u#ami-cg,GraySage.Edmonton.AB.CA>; Mon, 23 Mar 98 13:52:19 MST
[Niklas Elmqvist:]
[snippage]
:Anyway, using this scheme, we get a nifty way of viewing and designing
:the macro-geography of our world (by first generating the world
:map and then possibly tweaking it a little with some kind of editor), as
:well as blending together the boundaries of adjacent submaps.
You're on track with me here. However, as I previously mentioned (which
was the trigger for my current sidetrack into bytecode), you don't need
to actually store any height maps anywhere. If you are carefull with how
you do your pseudo-random numbers, basing them only on a single fixed
seed and the co-ordinates, you can, at will, generate reproducible heights
for any part of your map. This is the full map of your world (about
16 million squared in my case, at least tentatively).
The key question I'll be looking at soon (hah!) is how to effectively
store the exceptions. A builder asks for an image of the height-map for
the area he is messing with, and decides to fiddle it a bit, by raising
or lowering some key points. You need to store those changes in such a
way that you don't need tons of storage, but also so that retrieval based
on the co-ordinates is fast. One possibility I've been thinking about is
to artificially introduce actual stored maps for levels in the hierarchy
where changes have been made. I want those small enough to not be too
large, yet large enough to make them worthwhile, storage-wise. I've
tentatively chosen 16 x 16. So, if a huge part of the world gets modified
by a builder, then perhaps the top 16 x 16 map actually exists, and contains
the generated height values as well as the explicitly modified ones. Each
element of the array can also contain a different seed to use for the
detail beneath it, thus allowing a builder to experiment to find a "good"
seed for that sub-area, without changing the global seed used for the rest.
--
Chris Gray cg#ami-cg,GraySage.Edmonton.AB.CA
- Thread context:
- 3D engines for MUDs, (continued)
- 3D engines for MUDs,
Niklas Elmqvist d97elm#dtek,chalmers.se, Mon 23 Mar 1998, 19:17 GMT
- Re: [MUD-Dev] 3D engines for MUDs,
J C Lawrence claw#under,engr.sgi.com, Mon 23 Mar 1998, 20:52 GMT
- Re: [MUD-Dev] 3D engines for MUDs,
Chris Gray cg#ami-cg,GraySage.Edmonton.AB.CA, Mon 23 Mar 1998, 23:21 GMT
- Re: [MUD-Dev] (fwd) Functional Security,
Chris Gray cg#ami-cg,GraySage.Edmonton.AB.CA, Fri 20 Mar 1998, 16:47 GMT
- Re: [MUD-Dev] (fwd) Functional Security,
Felix A. Croes felix#xs1,simplex.nl, Fri 20 Mar 1998, 16:40 GMT
- (fwd) Functional Security,
J C Lawrence claw#under,engr.sgi.com, Fri 20 Mar 1998, 00:04 GMT
[ Other Periods
| Other mailing lists
| Search
]