Map Engine Development
Recent Posts
-
@ff03k64 - good consideration whether we would have to update maps to have this descriptor file. For maps in the triplea-maps repositories, we could certainly add it. I suspect the engine could fall back to current behavior if the file is missing. Older game engines would still be able to work by defaulting to current behavior as well.
The game notes being in their own file would be optional. If there is no reference to the game notes in the map.yml file then the engine would check the game XMLs for the game notes.
It's still a work in progress for what the map.yml would look like exactly, the latest example is this:
mapName: previewImage: games: - name: path: notes:I'm currently thinking the map description would go into a 'mapDescription.html' file. For context, the map description is what you see when downloading a map, currently today it lives in the triplea_maps.yaml file.
-
@ff03k64 , this list is the 'why' (admittedly it is terse):
@LaFayette said in Proposing maps.yml index file to be added to each map:
Map Uploadsmap uploads
removes n-layer dependency on map name
faster map parsing
allows for thumbnail images to be bundled with the map
would obsolete the "*.properties" file that gets created on client file systems.I'm working on a project where maps can be uploaded from the game itself. This means there will be no interaction by map makers with github repositories. A person opens up the map maker tools: selects a new "upload map" option, selects their map folder or zip, enters their lobby login username and password, and then clicks "upload", and they are done!
This process raises a few problems to solve. Notably when you enter a map into 'triplea_maps.yaml' one is adding the metadata that is intended to be replaced by a 'map.yml' file. For example, when uploading, we need a way to know the name of the map. We could have an upload form to enter this in, but if we do that then you have to enter the same name, each time, and take care to avoid typo's. To some extent it's easier if this information just lives with the map.
To be explicit, map uploads would not only remove all of the map repositories by hosting maps in database instead, it would also remove any need to interact with the 'triplea_maps.yaml' file as well.
removes n-layer dependency on map nameThis is a very brittle aspect for how maps are loaded and is a weak design. TripleA has a lot of reliance on "magic" naming, which is known to be generally brittle (easily broken). A recent map upload had this exact problem and we had to debug. Specifically you need to ensure that a map repository is named such that the zip file that comes from it will match the name of the 'map name' attribute in each XML.
There is just no real need for this if we can explicitly determine the name of a map from a configuration file that lives with the map. This removes the need to have a zip file be named in a special way, no need to have a repository with a special name, and no need at all to have a 'mapName' property in the XML. Instead the map name is defined once and would be in the maps.yml.
faster map parsingCurrently map parsing has to scan an entire zip to find all XML files. If instead we can read the 'map.yml' file and then know which files to read from within the zip, map loading should then become more efficient. In part too with explicit paths XML files can be placed in arbitrary locations within the zip file as convenient.
allows for thumbnail images to be bundled with the mapThe triplea_maps.yaml defines where thumbnails are to be loaded. This is another step to upload thumbnails somewhere, generally it's easier if the thumbnail can simply be placed within the map zip. When reading a 'map.yml', the zip file to read is the same one containing the 'map.yml', so we can then define a relative path.
Generally though, allowing the thumbnail to live in the zip file keeps the zip much more cohesive and complete, reducing the additional configurations and other files that need to be set up and then referenced in 'triplea_maps.yaml'.
would obsolete the "*.properties" file that gets created on client file systems.This is primarily a simplification for development and how the engine would work. We are combining here the '.properties' file with a file that lives inside of the zip natively.