[Ohrrpgce] New map format

[Jay Tennant]

-------- Original Message --------
> From: Ralph Versteegen <teeemcee at gmail.com>
> Sent: Saturday, December 12, 2009 4:19 AM
> To: ohrrpgce at lists.motherhamster.org
> Subject: [Ohrrpgce] New map format
> 
> Whoops, I forgot to start this discussion as I said I would.
> 
> 
> (Prelim: I think changing the map lump naming scheme, if at all
> desirable (I don't see the point) is a separate issue and can be done
> just as easily independently; more interesting would be to lump up all
> the lumps for each map into a single lump named something like map#.lmp)
> 
> Map lumps survey/proposal:
> 
> .N## - NPC definitions. This lump is currently fine as it is, no
> changes required.
> 
> .T##, .E##, ,P## - tilemaps, foemap, passmap. Suggestion: replace; see below
> .MAP - General map data. Suggestion: replace; see below
> .MN - Map names. Suggestion: replace; see below
> 
> .M## - a new main map data lump:
> 
> I like that idea that each map could be stored in a self contained
> lump or set of lumps, so I'd like to replace the .MAP general map data
> lump with a lump per map. More importantly, a fixed length .MAP
> doesn't allow a flexible number of map layers and per-layer settings.
> Also, it should be combined with .MN mapnames. I think RELOAD is the
> right tool for the replacement.

I think this is a great idea, storing maps as single .map files instead of many lumps in the general lump namespace. However, I don't think the data should be stored in sub-lumps. I also think the suggestion for RELOAD should be restructured. Continued below.

> I suggested a little while ago that the tilemap data for each layer
> could be stored in a binary blob inside the RELOAD document. I am now
> starting to think that this would be more of a nuisance, and the tile
> data for each layer would be better off in its own lump.

I've never understood the reason lumps are used for parts of data. Perhaps it's the perspective. To me, a map should be a self-contained, self describing entity. Lumps for smaller data parts could be re-described as xml tags as RELOAD was presenting, not as a separate micro-file.

I think the map document should describe the present attributes of the map. For instance, a newly created map file could look as:

<map name="" creationDate="" uid="" tileset="" widthX="" widthY="" ...etc.>    <!--all general data stored here-->
   <door dateModified="" ...etc.>    <!--describes the "door lump"-->
      <entry locationX="" locationY="" action="" layer=""...etc. />    <!--a single door-->
      <entry locationX="" locationY="" action="" layer=""...etc. />    <!--another door-->
      ...etc...
   </door>
   <npc dateModified="" ...etc.>    <!--describes the "npc lump"-->
      <entry walkaboutSet="" ...etc. />   <!--a single npc-->
      ...etc...
   </npc>
   <tile dateModified="" ...etc.>   <!--describes the tilemap/passmap/foemap 'nodes' as you suggested later.-->
      <nodes format="">   <!--format describes a template as to how the binary data block should be interpreted-->
          ...binary data...   <!--I can't remember how to declare binary character data in xml right now...-->
      </nodes>
   </tile>
</map>

I haven't studied how ohr deals with layers (like crossing over a bridge, then crossing under it), but if there is support (or intended future support), it may be beneficial to consider organizing by layer instead of by topic. From my perspective, I'd prefer not--instead, list the 'layer' the object belonged to as an attribute.

I included "creationDate" and "uid" as attributes to the 'map' tag in the interest of making these formats merge-able. When a new map is created, it could be given the creation date, as well as a unique id (uid). Probably don't need both attributes. If the uid is long enough (say 8 bytes), what's the likelihood of generating identical map uid's?

Each 'lump' description has a "dateModified" attribute so that the lumps can be merged based on edit date. I'd prefer if this attribute would be on each entry, though.

The 'nodes' element of the 'tile' tag first references a template format to understand the binary data. This allows us to update the format without breaking compat, the same thing you mention later. The binary data could reside within the xml within the nodes element. I remember vaguely something about <![CHDATA declaration to declare character data.

The binary data could be the combined 'node' structure you discuss later, describing the foemap, passmap, tilemap, etc.

> Tilemaps, the passmap, the foemap, and in future, user-defined
> datamaps are all basically the same, so I propose storing them all in
> the same way. Each could be described by a 'tilemap' node in .M##. A
> 'maplayer' node would contain a 'tilemap', along with various things
> like the tileset and transparency. A 'tilemap' could have the
> following attributes:
> -width, height
> -format: a string indicating the binary encoding. The specifics aren't
> important, but for example there'd be one (maybe "1Blegacy") for 1
> byte/tile with 160 tiles + 2 animation patterns, and one ("4Bint") for
> 4 bytes/tile, for signed 32 bit integers for data.
> -file: the name of the lump containing the tile data.
> 
> Then the tilemap lumps themselves would be headerless binary blobs. We
> could lump them up into a new lump to keep things clean, eg
> "map#.lmp". However, I don't like the fact that they wouldn't be self
> describing.

I also prefer that the "lumps" describe themselves.

> Alternatively, we could move some of that stuff into a header on each
> tilemap lump. I expect the header would be variable length and need a
> version id. But now we have just what RELOAD is meant to supersede.
> 
> Anyway, the .M## RELOAD tree would look something like this:
> 
> <map>
>   <name="...">
>   ... existing .MAP map not otherwise mentioned
>   <autorun=#>
>     <argument=#>
>   <layers>
>     <maplayer>
>       <tilemap>
>         ...
>       <tileset>
>       ...etc
>     <maplayer>
>       ...
>     <npclayer>
>     <herolayer>
>     <maplayer>
>       ...
> 
> 
> .D## - Door links. A mess, but there's no need to change it in the
> near future. It should contain only actual existing doors instead of a
> fixed number of 200. In future might like to add a script to trigger
> on use. Maybe a candidate for RELOAD.
> 
> .L## - NPC locations. Needs to be changed to complete the removal of
> the 300 NPC limit. Better think ahead and make coordinates in pixels.
> .DOX - Door locations. All maps are in the same lump. Could also be
> split out to one lump per map, but no pressing need. Also want to
> switch to pixel positions eventually... actually, I don't see why
> doors should be exactly 20x20 pixels in size. And other data might be
> desired in future, like walk off direction.

I don't think the npc's should be described by pixel location. What if we update the pixel format, or eventually support scalable sprites/tiles? Perhaps it's better to refer to them as tile location + center offset. The offset could be a value from -1.0 to 1.0 for each x and y. -1.0 on the x would be at the maximum left side of the tile. 1.0 on the x would be the maximum right. -1.0 on y is maximum bottom, 1.0 being maximum top. 0 would be center.

> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org 




_______________________________________________________
Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting
              http://www.doteasy.com