2009/12/13 Jay Tennant <[email protected]>:
>
>
> -------- Original Message --------
>> From: Ralph Versteegen <[email protected]>
>> Sent: Saturday, December 12, 2009 4:19 AM
>> To: [email protected]
>> 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.
A set of sublumps lumped together isn't really any less self-contained
or self-describing than a single RELOAD or XML document: you could
translation between these easily.
My rationale behind having things in separate lumps in my proposal is:
-it's far less work. Some of the existing file formats can be kept.
But I guess there's some benefit to throwing out currently adequate
file formats and switching to RELOAD, if anyone else wants that
-extracting most data, such as to do a binary diff and three-way merge
is trivial. I guess this isn't a very good reason
-Mike insisted storing huge globs of binary data in a RELOAD document
missed the point. I have no idea what he meant.
> 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'm not completely sure what you mean, but nothing is layered except
for tilemaps, plus the setting specifying between which two layersl
NPCs and heroes are drawn.
In future, it might be nice to place objects on maps with z
coordinates. I conclude that we don't have to consider it, because it
will be described in some radically new way.
> 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?
Interesting idea. But what do you do when a map is copied?
> 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.
I guess we'd need something like that to enable merging (or just 3 way
merging). But wouldn't you need a uid on each entry?
> 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.
I'm confused as to why you're mentioning xml. Aren't you using xml to
describe a RELOAD document?
> 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.
Well, the whole point of using a format like RELOAD is that such
things can be easily changed in the future: we could start storing x
and y as floating point values later, or we could replace them with
some alternative.
However, you've just made me realise an important point. The battle
formation file format is totally screwed up because it stores the top
left pixel position of formation slots instead of their standing
points. Unfortunately... different enemies have different sizes, so if
a different sized enemy is spawned in the slot, it'll be standing in
the wrong spot. And it's impossible to know what size enemy the slot
was for if it's empty! It's a back compat nightmare: only the original
author knows where spawned enemies during battle are meant to stand;
the game data doesn't say.
So, we guess we should store the position of the bottom center of each
NPC (as a reference point, they could possible extend below that). I
proposed pixels instead of tiles because of the "Plan for
non-tile-based walking".
*
I had rather been hoping to hear from the rest of you, and be able to
start on this sometime soon. Although currently I'm resuming on the
interpreter.
_______________________________________________
Ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
