[CF-Devel] Map world redo.

Mark Wedel mwedel at scruz.net
Mon Jul 16 00:05:33 CDT 2001


 Now that a big piece that makes this possible is now in (map tiling), I thought
I should at least re-iterate the conclusions from previous discussion, as well
as some things to make this more manageable.

 first, I should note I made no attempt at any modification for the current
maps.  One reason for this is that the current world maps did their tiling by
using a 5 space overlap on the next map.  To make the world maps use the new
tiling features would basically mean that this 5 space overlap gets removed,
which unless it is filled with something else, would then result in all the
coordinates on the map being off by 5 spaces, which then means all the exits
leading to the map are off.  In short summary, it means that it would take a lot
of work to make the current maps use tiling as is.


 The first conclusion was that a dual scale system should be used instead of the
tri scale we currently have.  The dual scale would basically be indoor/outdoor. 
The world maps would no longer have the little city symbols, but rather the city
would appear the same scale they currently are, but be on the world map.  The
city would still have the the various shops, and things like towers and caves
would similarly appear in the world maps.  Unified scale has been suggested, and
I think there are a lot of good reasons why doing it is not a good thing.  I
don't really want to discuss this again, so if you missed the discussion first
time around, please re-read the archives.

 The second point which is open up to a little more interpertation/discussion.
is how much larger the scale should be.  Anywhere from 20 to 50 is probably
valid.  I put 20 at the low end simply with the unified scale, you sort of need
this for this to work in at least reasonably OK.  Note that the current maps are
effectively 32x24 (this effective size gotten by removing the 5 space overlap). 
The main continent right now is 3x4, which means the entire thing is roughly
96x96 spaces.  Scaling at 20 would make this 2000x2000 spaces, by 50 would be
5000x5000 spaces.

 Point 3 would be the size of each tile.  Somewhere in the range of 50-100 for
each axis would probably be appropriate.  Note that on my machine, each object
is 428 bytes.  This means that a 100x100 map would roughly take up 5 megabtyes
of ram (I'm make the assumption in this case that most of the outdoor maps only
have 1 thing per space).  

 Point 4 would be naming system (right now it is world_a1, world_a2, world_b1,
etc).  Ideally, this naming system and directory setup should be such that it is
pretty unlimited - at some point, sailing boats accross the ocean to other
continents may happen instead of the instant journey it is now, so something
that will last long enough is probably the ideal thing.  My personal thought
would be to do it as something like sprintf(path, "world/%03d/w_%03d_%03d", x,
x, y), where x is the x position in the world.  This means an entire row would
be stored in one directory.  I note that if you do the math and take the largest
scale (50) with the smallest map size (50), that would result in a 100x100 set
of maps, and you probably don't want that many files in one directory for
reasons of space.

 I would also suggest that scorn starts somewhere in the middle of this set, so
things can work outwards.

 If these values get nailed down, this then means that multiple people can work
on different aspects.  For example, if you know the size of the tiles, and know
the scale, and know that scorn is on map 400x400, you can then figure out that
'ok - navar city should be at map 458,395' for example, so that a person can
work on the navar city area, a person work on the scorn area, a person work on
the brest area, etc.  Of course where the two meet up, some changes may need to
get made, but I think a world redo probably needs to get done by several people
at minimum.  I don't think it will be complicated, it will just be a bunch of
work that just takes time.

    
    


More information about the crossfire mailing list