Wednesday, October 9, 2013
Summary
Spent forever going through different ideas for syntax for my generic data format. I think I finally settled on one that'll work for a lot of different purposes! Not only that, but I've written the full string tree parser for it.
I realize now that string tree is actually not a file format, it's an intermediate data format. If I want, I can actually define multiple file formats for different purposes, write a string tree parser for them, then proceed to use all of the operations that I'll define on string trees. Cool! Although, in reality, unification suggests that I should just find a really good syntax / file format and stick to it for all purposes. Well, I think I've got it
Here's an example of defining a three-element list (vector) of 3D points in a few different ways:
Code: Select all
(3, (1, 0, 0), (0, 1, 0), (0, 0, 0))
Code: Select all
Vector (
3
(1, 0, 0)
(0, 1, 0)
(0, 0, 1)
)
Code: Select all
Vector (
size = 3
V3(1, 0, 0)
V3(0, 1, 0)
V3(x = 0, y = 0, z = 1)
)
The neat thing about my format is that it has two optional elements that make it very expressive: a field "name" and "type". Each datum can have a name and type, or one, or neither. A datum without a name will be interpreted as an anonymous field and will be loaded into a type in the order in which it is found (hence, three anonymous fields in a 3D point will specify the x, y, and z components...obviously it would be annoying to write x =, y = , z = all the time). A datum without a type will deduce the type based on the way in which the application is trying to load it. However, it's necessary to write the type when you're creating a derived instance through a base pointer (i.e. I need to specify "Ship" or "Planet" when loading a generic "Object"). It can also just be nice to explicitly write the type for the sake of readability.
I like a lot of things about this format. Simple pieces of data like a 3D point remain very easy and lightweight, for example, (0, 1, 0). But complex structures like an entire technology tree can remain expressive and easy to understand via the use of explicit names and types.
I've already written the basic code for loading arbitrary types from string trees, and it already works for everything except pointers (and derived types) (which are of course the only challenging things
). Awesome! I don't think it's really fully sunken in yet that I've just enabled any type in the entire engine to be loaded through a file
Hope to start using this to build tech trees ASAP!
PS ~ I know it's stupid that you have to explicitly specify the size of a vector/list, but in the future I will write a specialized parser for vectors to prevent that (right now a vector is treated just like every other type, with no exceptions, which is kind of cool when you think about it
)
[
You can visit devtime.ltheory.com for more detailed information on today's work. ]
Anyway, it's done now!
)
Code and data...all the same 
Seriously, it's pretty great. I didn't implement editing yet, but I'll do that soon as well 
The LT Ghost