Should we support YAML for Maps?
-
i will say that yaml does look a bit easier to learn and more sensible in general i understand the hesitation about indents (which i personally like actually) but doesn't the shorthand version somewhat resolve that issue?
-
Thanks for the feedback all. I think time to put this one to bed. Having both YAML and XML in the mix is really disruptive, the answer to mixing the two from me is "no". If we have a choice to migrate all XML to YAML, the answer from me is then "probably not".
Reasoning:
- there is a lot of expertise around XML built up, this would be lost going to YAML
- a cleaner syntax is nice, but not compelling
- all of the tooling around XML would be lost, the list of attributes, etc, all of the existing examples, would all have to be redone
- XML vs YAML is not hurting us so much where migrating is going to solve a lot of problems. We have limited resources and need to get LOTS of other things done. Unless we're solving a big problem, it's not worth it.
- Similar to saving effort, we might as well save the development effort of switching code
- The chance for indentation errors is high, I just foresee dos line endings and/or tabs giving someone a really bad day. While nasty XML is unpleasing to the eye and lengthy, at least it's easier to diagnose a problem there (and most tools will tell you where and which tags are unmatched or badly structured)
- Having two different formats would be no end to headaches, both in terms of which options they support, hurting people, coding, everything.
-
@LaFayette said in Should we support YAML for Maps?:
In essence, XML was an early standardized format that grew out of HTML that was meant for structuring data for one computer to send data to another. It was never really intended for humans to interact with it and write it by hand (the idea was there would be GUIs to help you do that).
Most likely this has always been the case for TripleA too. Ideally, you would have a map creator covering everything, and you would use that for creating and modifying the XML, never actually opening it with a text editor or anything. I believe this was the plan, except that it never happened (there have been several aborted attempts over the years).
-
Not to bring up a topic that was essentially decided, but I would love to throw my vote behind sticking with XML.
I love XML. For one reason and one reason alone- XSD (namely, well supported schema). We would lose that with YAML. I see YAML as short term gains but long term losses. For example, I've written a tool that takes an Excel sheet with units, their attachments, territories, starting placements and bi-bidirectionally "syncs" it with the game file using JAXB and Apache POI. This is the general direction I would love to help go- using powerful map-making UIs (and how much more power can you get with Excel/LibreOffice/standard spreadsheet UIs?) built on top of the most powerful/structured data interchange format. XSD supports inheritance, inclusion, polymorphism, unions, enums, etc. etc. and can be edited by a human in a pinch, but I'm envisioning a future world where map tools edit and the game engine parses and humans touch the game files less and less.
-
Agree on having humans touch the XML less and less. My long term vision is to have all the map making tools be built into the actual game, just like 'edit' mode, there would be a 'map making' mode that would enable additional options. Such an example would be an attachment editor to configure the attachments, a UI to adjust unit stats, etc..
FWIW, YAML does have a XSD like schema validation, more like DTD I suppose. We run that check against changes to the map.yaml file, adding unrecognized YAML attributes would fail that check and the build. This largely catches typo's or missing attributes.
-
I love building UIs and I love data interchange and would love to help with such a UI
once I get some free time which might not be for awhile...
