let it leave me like a long breath

so i was looking up how java handles loading xml files, since i was considering using them for data stuff, and uh the answer seems to be "badly".

so there's this thing called JAXB, the java architecture for xml binding, which is apparently the accepted method, and it just like, automagically dumps out all state in a java object, recursively. what if you don't want your xml files to have a 1:1 correspondence with internal object state? well, then you make an interstitial object that has the correct names and values so that the automagical serialization produces an xml file more to your liking, and then you convert your normal objects into interstitial objects, serialize them, and repeat the process in reverse to deserialize. there are also some custom hooks in the xml parser thing to optionally drop specifically-named fields, or store certain values as attributes instead of sub-elements, but it seems unbelievably crusty.

for a while i was like "this seems incredibly dense and obnoxious to use, which is weird because i remember using a thing with minecraft that was a lot easier", and after a little digging i remembered that that was when i was using the gson lib to serialize/deserialize json, where you just write a decoder func for type T and that means you can then make a Deserializer<T> which has a default function to parse a file into a value of that type.

(it's not that i have anything against automated serializers/deserializers, it's just it seems to encourage thinking of data as an opaque glob, and introduces huge issues if the object ever gains or loses internal properties, since that invalidates all your old data.)

so anyway i'll probably just do all this using json, which is... not ideal (there is no javascript here at all, so, why json) but unless there's a non-awful xml lib i'm just gonna go the path of least resistance here.

yes this is video games

libgdx has... let's say it has a way to procedurally assemble simple models, such as, say, flat quads for use as world geometry. but it's kind of a huge mess. still, it's nice to see that in a certain sense getting 3d rendering with textures working is Just That Simple.

like i kinda wanna put together a demo render that's a semi-outdoor baths setup, with a bunch of water effects and lighting effects and particle fountains (water splashes, fireflies by lanterns, etc) and the like. but at this point i think even drawing a translucent layer would be an achievement.

maybe i should replay breath of fire 4 to get a better feel for what its aesthetic is

also, looking at the gson docs now, and they do actually have a solution for the issue of parametric types not having a class instance. when i did the minecraft stuff i made dummy container types, which i kind of hated, but i guess they provide a TypeToken<T> type, that makes an explicit subclass with a fixed class instance, or, something. so that's neat.

i should probably get around to actually writing the parsing code, since that's kind of an important aspect to get working.