I prefer using my own parser for the flexibility, and I much prefer columns and spreadsheet-style to yaml. I like my data as space-conservative as possible, while still retaining readability. I totally cannot quickly parse yaml (visually), and it's also much easier to quickly compare values between multiple objects in an .xt file, which is important for design consistency (especially since I have a horrible memory and can't well remember all the different data values). I'm especially thinking about the items/entities files here, and the particle data, where easy of comparison is very important. Special abilities suffer less from that need.
As a standard tab-delimited file, you can also easily drop the data into any decent spreadsheet program for analysis. (Right now you'll notice there are a few columns I sometimes overextend, but that's for temporary data since the game
is still in development
)
The "scrolling off to who knows where" issue is mostly resolved by opening multiple parallel instances of the same file, and synchronizing the scrolling if necessary (horizontal). There's an explanation of how to do that in the modding guide (and that's also why I include my version of notepad++ in the modpack). It's not really any different than converting the data to yaml, where there are so many values you end up scrolling up/down forever to get where you want to go.
Scrolling is also less of an issue with a large monitor combined with a small font size, but unfortunately not everyone has that luxury. One day there may be a data editor tool which has built-in support for the expected/valid values.
All that said, the data
will still undergo some fairly large formatting changes in the future. One thing to figure out for the final system is how to improve "merging" compatibility like what you can easily do with yaml using multiple different datasets. Right now data development is locked in the demo stage--I haven't even started doing *any* official game data, so everything will eventually be wiped and started anew. At this point we can see what works and what doesn't, and I won't be making any significant data format changes until about 0.25, so all the mods and scenarios stay compatible for a good while.
Thinking more on the current format, I like the idea of data alignment being meaningful in two directions, which makes it much more understandable for me (my source looks the same way--more vertical alignment than you generally see, and,
if necessary/efficient for better understanding, lines up to 200-300 chars long for repetitive chart-style code). File size isn't too big of an issue, but the need to retype column headers is both annoying and fills the files with clutter.
Okay, that was a long reply...
Author
Topic: X@COM - Where ASCII and X-COM Collide! (Read 122883 times)