Tools Development and a Kinder Loader (Part 2)

Please complete the required fields.




Getting Distracted:

So, one of the great things about working on a game engine is there’s so many parts of it to work on. The same could be said for gamedev in general in terms of being a fusion of many art forms, but when it comes to raw programming, putting together an engine from scratch seems to present a neverending list of things to be worked on, which I’m all for.

That does however come with some unfortunate side effects, namely decision paralysis, as well as (in this case) going down a rabbit hole of interconnected features far away from where I started (wanting to get a test level in), going through tools programming (because making the test level in text files would kinda suck so why not make a level editor) to UI programming (I mean I need UI for a level editor? right) to trying to navigate around how c++ does copying to get the exact result I want, to deciding to redesign how the game loads structs to solve all of my problems. So… in terms of thinking I’ve been productive but in terms of finishing anything I started designing, less so. Still, we’ve gotta be close to the bottom of the rabbit hole now.

If a cow had a stack of compounding problems to work through they would probably be crudely drawn.

You could do worse than Messy Data:

So… suffice to say I’m not super happy with how deserialisation is done in the current revision of Nightjam. As stands current, each object is initialised using set variables stored in specific places in a text file, so it could be name, position, tag, some other variable for one, or name bounds tag position, or so on. Everything has to be formatted specifically into a certain number of lines arranged in a very specific way… which is what computers like and it works well enough, but, well, it also pressures anyone working with the system to be able to do very specific work (also part of why I wanted to make a level editor so as to avoid having to make a level by putting together a perfectly parseable text file), and also it’s kinda just inconsistent across data types as to where similar types of variables were placed, in what order, position, etc, because every object is different.

It’s not very consistent, it’s not very human readable and I kinda just wanna make it better. So, with that in mind I have designed a new, somewhat universal serialisation format which I hope to implement over the various game constructs in the game to make me happy with how all the files work.
Where previously a file might have been formulated Name, position, bounds tag tag tag. things will now be split so that most variable groups are given their own line, and the purpose of that line is indicated by the keyword it starts with. So it’d look more like

NAME name
POSITION x y z
BOUNDS w h
TAG tag
TAG tag
TAG tag

And during deserialisation, each class’s constructor (or rather a function running under it, Unpack(string)) will parse that line by line and change whatever variables it refers to from their default values to what’s specified, based on exactly how it’s implemented that in the class. And, when it comes to serialising or copying an object, each class will have a specific Pack() function that generates a string of all its serialisable variables to either be saved or be used to set up another object. Importantly however when reading it doesn’t matter what order things come in and whether or not everything’s there (it can just default on some values) meaning I can be messy with the stuff I do write manually, still have something load, and be able to debug what didn’t load by what variables don’t match what they are in the file in case anything goes wrong… instead of staring at the file trying to work out why it crashes everything.

It’s quite possible I may just have invented worse JSON, but I consider that to be an important learning experience.

Anyway yeah, progress on Nightjam is going great, nothing to worry about.

 

Press X to…