[MUD-Dev] 2d mapping in SQL

Matt Chatterley zen31329 at zen.co.uk
Fri Apr 2 20:20:49 CEST 2004


Byron Ellacott wrote (31 March 2004 23:56):
> On Tue, 2004-03-16 at 00:30, Matt Chatterley wrote:

>>   What about making this a proper model? How might I aim to
>>   create 'clusters' of planets (e.g. solar systems)?

> If you're concerned with realism, you might want to note that the
> distance from a star to its planets is vanishingly small compared
> to the distance between stars.  All the games I've played have
> either hid the detail of planets from the overview map (you reach
> the star, then zoom in to see its planets) or have ignored the
> distinction between planet and star.

[ snip ]

Yeah. This is a conclusion which I reached myself. I'm only really
interested in the distances between 'clusters', as this is the
distance which freight will have to traverse (and so forth) - any
distances encountered within clusters can a) be modeled separately,
as you say, and b) are relatively insignificant (as you also
observe).

The whole concept of 'clusters' is definitely the way I am going to
go.

> But realism isn't particularly important in games, so there's no
> reason not to ignore scale :) Why not place a sun and its planets,
> and declare that system finished.  When you need more planets,
> that means you need more solar systems.  A new player joins, the
> number of current planets is less than the new minimum number of
> planets, and so you find a place for a new solar system and give
> it a random assortment of planets.  If this satisfies the new
> minimum, you're done, otherwise, you'll need to place more.  This
> way, you may have an excess of a few planets, but you'll never
> mess with existing solar systems.

Yep, yep, yep. One whole cluster will be placed a time - this
incidentally simplifies things for the user too. When plotting a
path, they can pick the cluster which a freighter will be traveling
to, and then from a small list, select the planet within that
cluster which is the 'final destination', rather than having any
sort of complicated search method to locate the planet you wish to
travel to. Since I am not aiming for realism, I don't need to worry
about some things, such as scale, so much. I'm far more concerned
with keeping the user interface as simple as possible.

> For choosing the location of a star system, you could specify a
> minimum and maximum distance star systems will be from each other,
> then establish the regions on your map that could contain a
> potential new star system.  Establish that as a bounding
> rectangle, then pick random coordinates in there until the
> selected point falls within the region.

> For each system, construct two polygon approximating circles, one
> with a radius of max_distance, one with a radius of min_distance.
> Union all the large polygons, and all the small polygons.  Find a
> bounding box for the large union, and select a random point within
> that box that is contained by the large union but not contained by
> the small union.

Thanks - that makes a lot of sense (or it did after I sketched it
out, anyway). That pretty much puts the problem to bed (at least for
the prototype).

[ snip rest ]

Although, there are other details to consider, such as number of
planets in a cluster, and so forth, it is actually sufficient at the
moment for me to simply work on placing clusters (especially since a
cluster population routine is the next logical step after the
cluster is positioned within the 'main map').

The next immediate mapping challenge is the placing of players
amidst the clusters, but this is no harder, and pretty much covered
by the above theory - minimum and maximum distances governing the
relative positions of 'outposts'.

Of course, after that, comes the issue of 'map revelation'. Should
all players have access to the entire map, or should it be
discovered over time?  Each outpost might be able to scan a given
distance around itself and then further map 'discoveries' could be
made by scouting missions (perhaps with specialized craft), and by
trading - either buying map information, or part-exchanging for
goods (or indeed map data in return).

Would this need to be maintained, to keep uptodate with new outposts
and constructions (think 'fog-of-war' as in most RTS games). I fear
that full-on FOW may add a little too much complexity, but then, the
exploration aspect of this type of game appeals to lots of folks,
including me. Toughie. I certainly don't like the idea of revealing
the whole thing immediately - if nothing else, it could cause
information overload.

Ah well. The puzzles are what makes this fun!

Cheers,

Matt
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list