Re: [Adonthell-devel] More v0.4 design issues

[Kai Sterker]

On Mon, 10 Dec 2001 11:35:00 +0100 (CET) Kai Sterker wrote

> As for the naming, I guess you wouldn't have to name them at all. The
> designer would work at a single world map and would hardly notice that
> stuff is split up by the editor.

[...]

> Of course there had to be a way to put the work of different designers 
> together. Writing a tool to do that shouldn't be a huge problem though.
> I would imagine something like this
> 
>     mapmerge <newmap.file> <size> <map1> <pos1> <map2> <pos2> ...
>     (e.g. mapmerge complete.map 40 40 a.map 0 0 b.map 20 0)
> 
> Then you could load the new map in the mapeditor and make sure that they
> fit well together (or fill in the space between them).
> 
> With such a tool, you could possibly even merge two or more worldmaps 
> that all use global coordinates. You simply had to offset them with
> their new positon during the merge process.

Perhaps this requires a more detailed explanation:

map: a map similar to those we have now. Except that the submap that
    contains the world surface has a fixed, quadratic size. 
    Synonym: area.

location: a place on the world, like a town, a forest, etc. Consists of
    several maps/areas.


Without going to much into implementation details, I imagine the following
scenario. Say you want to create the Waste's Edge location, James. So you'd
fire up mapedit, which basically gives you an (practically) unlimited
canvas where you'd place all the objects (and characters and items).

Basically you could grow the map in all four directions. When saving, a
new directory is created (wastesedge.map/) and inside are the maps the
Waste's Edge location is composed of:

    area0_0, area0_1, area 1_0, ...

Each of those area files is a complete map as we use right now, and all
the objects on it would use global coordinates. E.g. area0_0 would range
from (0,0)-(63,63), area_0_1 from (0,64)-(63,127), ... .

When loading wastesedge.map into the editor again, it would either
translate all coordinates, so that you can add more terrain on either
side, or it could handle negative coordinates and translate stuff when
saving.


Now imagine somebody else had done the Cirdanth location. It would sit
in the cirdanth.map directory and the area files would also use (global) 
coordinates starting from (0,0).

Say the wastesedge map consists of 4x4 such areas, and Cirdanth of 17x12.
If you wanted to put them together you'd do

    mapmerge mainland.map 40 20 cirdanth.map 0 8 wastesedge.map 36 8

That'd result in a new directory, with the area files of cirdanth and
wastesedge and a couple of empty areas. All the coordinates of cirdanth
would have been translated by (128, 512) and those of wastesedge by 
(2240, 512). Of course the area files are renamed accordingly as well.
(wastesedge area0_0 would now be area36_8 and so on ...)

Now you could load the mainland map into mapedit and add objects to the
empty space. Or you could merge in forest.map for example. (That is,
mapmerge should support both merging of several locations into a new 
loacation and adding of locations to an existing one.) 

To resolve overlapping maps (area), we could define that the last 
location merged/added overwrites areas that are already there. (Perhaps
with the exception that empty areas won't override nonempty areas.

For example if you had two locations

    #### .... ....      ++++ ++++
    #### .... ....      ++++ ++++
    #### .... ....      ++++ ++++
    .... .... ....      #### ++++
    .... .... ....      #### ++++
    .... .... ....      #### ++++


then 'mapmerge loc3 2 5 loc1 0 0 loc2 2 0' would result in

    #### .... ++++ ++++ ####
    #### .... ++++ ++++ ####
    #### .... ++++ ++++ ####
    .... .... .... ++++ ####
    .... .... .... ++++ ####
    .... .... .... ++++ ####


Kai