Atomic Space News #5: Building a better builder

Last month I said I’d be working towards having multiple levels. That’s led me down a bit of a rabbit hole. To have multiple levels I need a better level file format. That format is going to need to contain various kinds of objects, whereas the existing format only knows how to handle one type of thing. That leads to the fact that the level editor itself needs to be more flexible, and while I’m at it there’s real star system arrangements that the editor can’t support that I want it to. Also it’d make setting up systems based on real data much easier if I could enter in values like distance or mass in various units instead of a single option, so if I’m hacking on the editor I might as well try to do that at the same time.

Some might call this scope creep, and they might be right, but this is all stuff I need to do eventually and they go well together.

Working back up from the bottom of the rabbit hole to the top, the new editor has option selections for each appropriate line to let you choose what unit you want to view/edit them in.

The option list is flexible, I could add or remove some without much effort(though it’d cause some layout headaches, those are solvable). A few familiar units like miles or tonnes might be useful to put in.

I streamlined text entry while I was at it. In the old system you’d put in values, then have to hit a button before they were pushed into the actual data and you could see the results. Now they update as you type. There are surprisingly many moving parts involved in that! The old system does have some small benefits in being able to back out of bad ideas without commiting them, but I’ve some ideas on how I could potentially implement undo, and I think the faster feedback will be a worthwhile trade-off.

The other big change from the existing system editor interface is less visible, which is that the values to edit are not hard coded into the GUI, instead the object being edited tells the GUI manager what values it has to be edited and what kind of values they are, meaning that as I add new object types they can slot in there with minimal extra work and hopefully no special cases. This is a big win for me that’ll hopefully save some time going forward, and bits of it my be re-usable elsewhere.

Back up the rabbit hole another step is saving. Up until now all my saving and loading has been through creating or parsing comma separated value files, essentially a spreadsheet of values with a line for each object and an expected format. Strictly speaking I could extend this to plenty of new objects, but doing so is labor intensive and failure prone, and the resulting files are somewhat opaque when I’d like them to be at least theoretically hand editable. That brings me to serialization, which is pretty much the automated process for doing just that. C#, which is the language all this is being done in, has some standard serialization features. This is a thing I’d tried to make use of long ago, but I was too novice at certain aspects of programming to make it work. This time around it went relatively smoothly, I did have to more or less turn a portion of my data structure inside out to make it work, but that only took about an hour and seems like it’ll have some good side effects down the road. I can now save and load the editor files to an XML format with minimal amounts of special work to prepare for saving or cleanup after loading. Similar to the GUI stuff this happens without me needing to specifically write (much) code to handle new objects types, which will save time in the future. XML is less than ideal for my goals of human readability/editing, so I may look into alternate options, but it does do the job.

I’m still a few steps away from having a full featured level editor. Most pressingly the new logic can not yet convert from the simplified orbital representation in the editor to the actual raw positions and velocities needed for the levels. That shouldn’t be too hard to cannibalize from the old logic, but it hasn’t been done yet. Editing mission objectives promises to be a bit tricky, and definitely needed. Editing mission meta-data(name, description, and so forth) is similarly needed but probably easier. Also on the immediate to do list is support for binary stars or planets, which now that I’ve done everything else I’ve talked about here should be pretty simple. There are a few other loose ends in the editor GUI, and if I’m really smart I’ll build an automated way to convert the old CSV levels I’ve made to the new format.

That’s all for this month! Plenty of words this time, next time I’ll strive to have more pretty pictures too.

Leave a Reply