i’ve begun to make a few of the supplementary projects that have broader use-cases public:
vibarena
vibarena is actually published as a crate- https://crates.io/crates/vibarena. I’ve tipped about generational arenas in the thread OP but these are a really great data structure in the realm of game development. The idea behind them is rather than keeping all objects in standard list/vecs and referencing them by index, you return a ‘Key’ that contains both the index in the array but also a “generation” that determines when that element was added to that index. If I delete the element at that index, the arena increases the generation so we know the key that refers to it is out of date. So if you have a key you can always check if the object it points to is valid instead of something that was deleted and reinserted with a replacement. In a game this can be useful if you don’t want all your game objects holding direct references or pointers to each other. vibbit doesn’t have any concepts for game objects but I still use these internally for resources the user loads like textures, these all come with a key for the arena - which will be useful for working with scripting languages since you can just pass those keys (just two numbers) back and forth from one language to another rather than a full size struct
This arena stores all the actual objects totally compact in memory. Some arenas will leave deleted spots “empty” in memory, but this one will stay compact during any insertion/deletions so it can remain super fast if you just want to iterate over everything in the arena. Since its for a game 90% of what you do is go over each element and call update(). I’ve also set up some secondary data structures that allow you to associate more data in a map from key->value, but without having to actually hash anything to access it.
Rust can do some neat things automatically with your types - for the key I’ve specified the generation is a “NonZeroU32” which lets the compiler know this number will always be >= 1. This tells it that there is actually one “free” bit not being used by the struct - so I can wrap a Key with something like Option and it won’t take up any more space in memory than a Key on it’s own. An option in rust is a value that may or may not actually exist - think something like an enemy that is following a target. It may have a state where it forgets that target, or the target is deleted so you might want an Option, and in your code you must check if that option is Some or None before you try to actually access the target inside.
ogmold
I don’t have too much to say about this one other than it’s a loader for tilemap files from the ogmo editor: https://ogmo-editor-3.github.io/
I’ve worked with ldtk before but something tells me i should be sticking to the classics for this, so i wanted to create a simple lib to load files for ogmo. at some point it would probably be my plan to build some custom editor that is more in line with a greater engine, but for getting off the ground ogmo is a good balance.
since this is just an interpretation of a file format its interesting to try and figure out how much you want to be able to abstract over it. i come up with thoughts on useful things i could add to the loader, but the same time knowing anything that uses a project like this will still end up building another abstraction over it anyways, so why inject a middle abstraction here versus just presenting the data as its stored.
rusts more conventional lib for loading files is called serde, but its a pretty massive project and ive opted here to use a miniaturized crate called nanoserde instead, which is the only dependency for this ogmo loader. ogmo files have a few “existential” types, meaning JSON objects where the exact type of the object is defined in a property inside that object, which meant having to write manual parsing for a few of the structs. Otherwise serialization is quite simple in rust, where most basic types have serialization implemented as traits by the library, and if your structs only use those basic types you can derive that behavior automatically.
vibbit now has a few very basic sound functions thanks to https://crates.io/crates/kira - in my heart it was definitely way less satisfying to wrap this library, in comparison to the main work on rendering, so ive adopted a pretty small set of load sound / play sound / play music functions, enough at least to make jam-ish games on while i consider what it might look like to learn the audio stack myself. its getting to the point where i really just want to remove barriers towards whatever it will take to reach ‘playable game’ with, even if that means having to swap out a component later on. i wanna see this stuff running out there in the wild. gamepads and mouse input (which i forgot existed when i was adding keyboard stuff) will hopefully be next