MegaGlest Forum
MegaGlest => Feature requests => Topic started by: Baŝto on 19 March 2014, 19:54:48
-
This is a suggestion how an xml format for maps could look like.
No additional features (for now), just the same as .mgm files.
XML is a human readable format, this is not really important for maps, but you could easier write third party tools for maps.
E.g. you can create a website for storing maps and show a preview and player limit.
<?xml version="1.0" standalone="yes" ?>
<map version="1.0" maxfactions="8" width="2" height="2" altitudefactor="1" waterlevel="4" clifflevel="4" cameraheight="42">
<head>
<title>a map</title>
<author>somebody</author>
<decscription>just a simple map for demonstration</description>
</head>
<row><cell altitude="10" surface="1" resource="1"><cell altitude="10" surface="3" object="3"></row>
<row><cell altitude="10" surface="4"><cell altitude="3" surface="5"></row>
</map>
Width and height also could be skipped.
Not defined parameters are set to 0.
This version is also possible:
<row><cell altitude="10" surface="gras" resource="gold"><cell altitude="10" surface="road" object="stone"></row>
But would be kind of ugly for mods with other resources like Annex .
-
I like the format, this will add more flexibility when the Lua scripting is integrated in the future,
You could make gold change places in maps or making labyrinth from set of arrays and much more.
-
Hmm, an XML format does have some advantages over the GBM/MGM format, particularly in extensibility.
I'd rather we use numbers than names, as the actual objects, resources, and surfaces are tileset and techtree dependent.
However, XMLs are huge because they add a lot of fluff. How we either:
- Use JSON -- it's also a human readable format with tools in pretty much every language, but it's much more compact (XML is super verbose) and the use of JSON arrays is ideal for handling a matrix of data, which is what the map format really is. I'm not really sure about C++ libraries, but in my experience in using the GSON Java library, it's far easier to read and write than XML.
- or standardize some compression wrapper. That is, set some type of compression format that can be used to compress the map. For example, we already support 7z in MG, so we could put the map in a 7z archive (with the map file having the same name as the archive). The map is tiny and only has to be unpacked once, so this should be a mostly negligible overhead. Should result in smaller sizes than the current binary format. This could be combined with using JSON (and would get better file size reduction, anyway).
Sample of how this could look in the JSON format:
{
"headerInfo": "someInfo",
"moreInfo": "foo",
"aBoolean": true,
"aNumber": 12,
[
[
{
"altitude": 10,
"surface": 1,
"resource": 1
},
{
"altitude": 0,
"surface": 4
}
],
[
{
"altitude": 10,
"surface": 1,
"resource": 1
},
{
"altitude": 0,
"surface": 4
}
]
]
}
As we can see, we have a top level object (the map), some data for that (header stuff like authors, etc), and then an array of rows, which are arrays of cells. Whitespace is optional and included only for readability.
I like the format, this will add more flexibility when the Lua scripting is integrated in the future,
You could make gold change places in maps or making labyrinth from set of arrays and much more.
This isn't true. Adding an XML (or whatever) version will not change the game. After all, the GBM/MGM format currently represents this same information (just in a format that is difficult to read -- but not that difficult for computers -- and human readability doesn't mean much given that you'll use a map editor for any serious map creation). I'm not sure what limitations are currently preventing lua from changing the map in-game (although it's a long time feature request), but it's not the map format.
The only advantages I can think of is that textual formats like this handle unnecessary data well (which is good for adding new features -- avoids breaking older versions) and possibly making parsers easier (but well documented binary formats aren't that much harder to make). I'm not sure about XML, since it doesn't correlate well with objects, but the JSON format can sometimes be converted directly to objects, which makes it far, far easier to read files in. In fact, creating a reader for the above JSON format is so easy it's laughable (create an object template, let JSON do the hard work, and then iterate through your newly populated arrays).
-
I agree, XML might have to much overhead for a map-format
Suggestion for complete map format in JSON:
{ "formatVersion":1.0,
"title":"a map",
"author":"somebody",
"description":"just a simple map for demonstration",
"maxFactions":2,
"altitudeFactor":1,
"waterLevel":4,
"cliffLevel":4,
"cameraHeight":42,
"altitudeMap":[
[10,10],
[10, 3]
],
"surfaceMap":[
[ 1, 3],
[ 4, 5]
],
"objectMap":[
[ 0, 3],
[ 0, 0]
],
"resourceMap":[
[ 1, 0],
[ 0, 0]
],
"playerPositions":[
[0,0],
[1,1]
]
}
I’ve chosen XML, because it’s easier to embed Lua there … but this will break syntax highlighting and lead to very blown maps.
Lua code could be attached like this:
"lua":{
"global":["scripts/global.lua"],
"startup":["scripts/startup.lua","scripts/locicallySeperatedStartup.lua"]
}
Or just:
"lua":{
"global":["global"],
"startup":["startup","locicallySeperatedStartup"]
}
All files should be located in scripts/ and have the suffix .lua … this would be a more secure way.
"/" shouldn’t be allowed than and symlinks not being followed.
Even so it should have no use, because the scripts can’t read the content of the opened files and megaglest might crash.
We could try http://jsoncpp.sourceforge.net/
-
I already had some code that exported maps to xml. I made this when I worked on jglest, to be able to read the maps in java.
https://forum.megaglest.org/index.php?topic=4831.msg36592#msg36592
( yes, its just a hack )
BUT: A xml format will be a lot bigger than the binary format, so at least a zipped xml should be used in the end.
-
https://forum.megaglest.org/index.php?topic=4831.msg36592#msg36592
Wow, that thread opens a cringe-worth look into the past...