Talk:Map Format

From FIFE development wiki
Jump to: navigation, search

Additions to map format

The current rewrite of the pathfinder (cell_pathfinder branch) introduces data which has to be stored in the map file as well as new loading orders. Map files can't just be parsed in a linear way. This is due to the fact that some part of the data definitions relies on FIFE data (which differs greatly from the current data loading process, as there only new FIFE data has to be created)

On a side note: FIFE is getting more features here, which mostly are about to work on exisiting data and connect them. This is a somewhat new approach like we already faced it with atlas format - in the past we just kept adding new data to FIFE, now we also re-use the old ones. (can't stress that difference enough =) )

Processing instructions

Updates for the processing instructions (PI):

<?fife type="map" ?>

  • create xml tree object
    • create map
  • parse import statements (objects)
    • process import statements
  • parse tree for layer statements
    • create layer
    • add layers to map
    • create instances
    • add instances to map
  • parse tree for camera statements
    • create cameras
    • add cameras to map
  • parse tree for light statements
    • create lightnodes
    • add lightnodes to renderer
  • parse tree for cellcache statements (either via import or within the file)

<?fife type="cellcache" ?>

  • create cellcaches
    • create cells
    • finalize cellcache (e.g. create transitions)

Instance data

  1. bool; visitor (flag if the instance can remove fog of war)
  2. int; visitor_radius (range the fog of war is removed; only evaluated if visitor = True)
  3. int; cellstack position (cells use this value to sort out blocking attribute; inherited from object or defined by the user)
  4. string; cost_id (id of cost which this instance adds to the cell it is currently; inherited from object or defined by the user)
  5. float; cost (value of the cost which this instance adds to the cell it is currently on; inherited from object or defined by the user)


<!-- within layer section -->
	<!-- (in addition to all other attributes of <i> tags( -->
	<i visitor="" visitor_radius="" cellstack_position="" cost_id="" cost="" />
	<!-- .... -->


Layer data

  1. string; layer_type (either 'walkable', 'interact' or none; a layer of type 'walkable' triggers the creation of a CellCache; layers of type 'interact' have no own CellCache, instead their data is merged with the CellCache of their corresponding 'walkable' layer; optional attribute)
  2. string; layer_type_id (links a layer of type 'interact' to the layer of type 'walkable' by the given id)


<!-- within map section -->
<layer layer_type="" layer_type_id="">
	<i />
	<!-- .... -->


CellCache data

  1. float; default_cost
  2. float; default_speed
  3. string; id


  1. cell custom costs (id, value); set by the client / FIFedit
  2. transition data (connecting two cells like a portal)
  3. cell states (for field of view implementation)

Detalis: #1 involves an unknown amount of data (depends solely on the client), I'd suggest a separate section within the cell structure (separate cost entries)

<?fife type="map">
		<!-- ... -->	
		<cellcache default_cost="" default_speed="" id="layerid">
			<cell mc_x="0" mc_y="0" state="0" blocker_type="3" >
				<transition x="0" y="0" layer_id="userid" immediate="True" />
				<cost id="userid_1" value="1.0" />
				<cost id="userid_2" value="1.0" />
				<cost id="userid_3" value="1.0" />
				<cost id="userid_4" value="1.0" />


CellCache definitions separated from mapfile:


<?fife type="map">
		<!-- ... -->	
	<import source="mapfile_cellchache.xml" />


<?fife type="cellcache">
	<cellcache default_cost="" default_speed="" id="layerid">
		<cell mc_x="0" mc_y="0" state="0" blocker_type="3" >
			<transition x="0" y="0" layer_id="userid" immediate="True" />
			<cost id="userid_1" value="1.0" />
			<cost id="userid_2" value="1.0" />
			<cost id="userid_3" value="1.0" />
			<cost id="userid_4" value="1.0" />

--chewie 16:06, 9 April 2012 (CEST)

Object representation ideas

Important ideas from an irc discussion:

  • Ismarc: I didn't even think about the offsets for grids or anything
  • phoku: hm.. well, i think this field idea could be kept in mind, but could go in the next iteration
  • phoku: objects are (small) lua tables with a visual associated...
  • phoku: in the map file they sit at object grid locations and have pre-formatted script entries and parameters for those
  • phoku: or they are full blown scripts, but that should be seldomly needed
  • phoku: the ingame map mostly keeps track of the visuals(display) and the objects loacation. it will have some hooks to call objects
  • phoku: invisible objects are used for extra storage or other script hooks
  • phoku: later numerical data might be added to the grid, but it's not important now
  • phoku: hmm... map files consist of header: grid geometries used, pointer to data repository, version info
  • phoku: the tiles for floor and roof
  • phoku: and the objects as described above
  • phoku: hm. well mostly of pointers to objects as described above ...and a position.
  • phoku: ... is that it?
  • Ismarc: the tile for floor and roof and the objects need to specify which grid geometry they are positioned using
  • phoku: woah, okay that is most flexible ... let that be if left out they use the default value
  • Ismarc: yup
  • Ismarc: that puts a lot of power in the modders hands for how the world looks
  • phoku: this contains parts of the map view/model design, too
  • phoku: yes ... indeed
  • phoku: okay. now we ...only... need a detailed design doc made from this
  • Ismarc: now, do we want to allow them to specify how each position in the geometry is numbered, or just use a base system in the engine?
  • Ismarc: like, they say A100, A101, A200. That is then derived as x direction counts up with single digits, y counts up with hundreds, all of which is prefaced by the letter A
  • barra: the map geometry should define the counting, should't it?
  • phoku: i think we should specify that
  • barra: if they want to change it, they could change it in the c++ code; a normal modder wouldn't need that
  • Ismarc: true, it'd just be a matter of designing it large enough so they never feel limited on size of the map

External resources

comments on the map format

  • map-param id (the integer value)

I no longer think having such a field is a good idea; as long as maps are hand-written there is a high probability of authors just ignoring it. In any case the value needs to be unique (or it wouldn't make any sense at all) and this assumption might be true for independent level-makers A and B, but if person C installs levels made by A and B the ids can easily clash... not good. Simply using the map filename as identifier seems better (not by much though).

  • <param type="text" name="NAME">My first map</param>

Why this way instead of <metadata name="..."/>; I guess your way is ~type-safe~, but I have my doubts about validating

<param type="int" name="foo">1</><param type="Point" name="bar">...</>

with a DTD, maybe with a schema?

  • Finally: do we really want xml for storage?

Why? What do we gain compared to writing the map definition in Lua as well?

Skybound 04:13, 24 February 2007 (CET)

  • You're right, I'll remove the ID.
  • Well, I don't see much value in validating? Thing is this is much easier too code... hm. I'm not sure though.
  • I personally think we should stop the endless discussions, and just use what's working, and provide some stability in that.

--phoku 15:51, 24 February 2007 (CET)

Image data

The noise*.xml maps use it; not that I care about those maps and I admit creating image-based maps isn't exactly convenient at this time, but storing the <gid/> tags for any non-trivial map is an inefficient use of storage. Assuming a single tag is 15 Bytes a FO-sized map is:

100*100*15 ~ 146 KB

noise1.png is 6.3 KB

Now, if someone were to write a zip-backend for the VFS...

I do count on that. Though that 146 kb probably don't matter that much. The parsing time could be another issue. But the nice thing with XML is that you can add the stuff without breaking existing maps. Btw. any hopes I could convince you to write a SQLite archetype? :-) phoku

I just created a ticket for the VFS ZIP support. Thomas_34 from the irc channel mentioned that he wants to give it a shot:

--barra 11:27, 1 March 2007 (CET)

Possible notes and grouping support

There are two rather important ideas mentioned the outdated Map editor article that would be a great addition to FIFE IMHO. The first one the the Notes Support that was planned for the editor. I guess this could be done by using the Metadata part of the map format, however I would like to see that every map object itself could contain this metadata, otherwhise you couldn't attach notes. Or we could introduce a specific <note>Your note here</note> tag. I'm not sure if you should be able to attach notes to special tiles on the map but I guess it couldn't hurt; but notes support for objects and especially NPCs would be a really great addition. You should be able to add a number of notes even to a single object to support team work while working on maps.

The second feature I would like to see supported with the map format is what the author of the map editor article called Layers support. I think that having a way to mark objects to represent that they belong together somehow offers some nice possibilities e.g. the engine could turn off the roof layer if you enter a house with your alter ego. To make this possible the engine would need to know that the roof tiles belong together. So maybe introduce a group="xyz" attribute for tiles and objects so you can set the group they belong to? I'm not really happy with the word "group" either, but I hope you get the idea. Another important advantage would be that you could move grouped objects together with the planned map editor. So if you think that the building you just created should be a bit to the south, simply select the group "house_27" and drag it a bit over the map to the place where he thinks it would fit better.

Feedback please :-)

--barra 09:52, 1 March 2007 (CET)

I am pretty sure both can be done already, for two reasons.

The notes section can be implemented with metadata as you have realized already. Especially the editor could claim the metadata names "_note" and display it as a note on Map, Elevation, Layer and any Objects. I think these are all relevant parts. Hm. Maybe some stuff in the archetypes needs this, too?

Grouping should be done with layers itself. But you are right there is a deficiency that a layer currently can not be offset to another layer in terms of grid cells. Though this can also be implemented in the map editor with metadata (_reflayer and _gridoffset) and the map editor can then have "merge down" feature like known from image editors (gimp).

So for now, I'll vote against adding this as separate tags and sections. These can be implemneted already seen from a map editor point of view.

Also the XML map loader ignores unknown tags, so you also can add them in the map files, if one wishes to do so.

Also please note, that the metadata section should be used for these "work in progress", "obscure" and/or "might change later" features, so that they don't litter the map format =)

--phoku 14:48, 1 March 2007 (CET)