(Forgive the long preface)
I’ve been re-evaluating my project scope on whether the planned end-goal could do reasonably mediocre on that steam rather than itch.io.
I have planned custom-level support from the very beginning, and until now this would have been accomplished via exporting egg files from blender. Using my exporter, the process for creating collisionShapes requires creating the geometry that gets exported to the egg file, and then manually adding a custom-property (One that isn’t currently case-cleaned in the release-build!) for each and every collider. And even then there’s a chance of a large disparity being created between blender and panda3d due to how p3d loads colliders from egg files, thus requiring anyone who’s making a custom level to gain a bit of a technical understanding of how egg files work. That feels like a bit of a larger ask of someone on steam than someone on itch, who might already be a developer who could enjoy learning some of the technical aspects of p3d.
Creating a level editor could help with this as it could have a 1:1 representation (and/or even share code with) my game, as well as being much more ergonomic.
However, I feel exporting to bam-files from the editor would be unwise, as it could mean that upgrading the version of panda3d my game is built with could invalidate custom levels. Furthermore, I’m considering eventually improving on my game’s code to add small flourishes like using bullet to run physics on various props and ragdolls, while retaining usage of panda3d’s builtin collisions so as to not change my existing code, etc. For that purpose all colliders would need a duplicate for the other system, which ends up becoming redundant if they’re saved as separate entities in the bam file. (bad for downloading between players.)
(Once again, sorry for the long preface.)
This brings me to my point: I’m going to eventually develop this system/file format anyway, but I thought I’d ask people here on the forms if they’d ever use it to decide if I do that sooner or later.
The file type itself would start with a header that would define how long the ids for different “entries” are in that particular file, then provide a dictionary correlating entry names with their corresponding id’s in the file. (I want to do this so that level files can even be dragged between games that have different entity types; entities can be skipped if not recognized.)
After that, the rest of the file would consist of entries made out of the id, followed by how many bits following that contain the entity’s “children” entities + any parameters saved to the entity.
The creation and loading of these files would be done by c++ class(es) that can be handed python functions to manage different entity types to call when saving/loading. If there is no python function for a particular entity, just skip it. These python functions would probably be registered like so:
level_file_mgr.register_entity(entType = someClass, finder= finderFunc, constructor = constructFunc,
parentTypes = ("someOtherClass",), superClass = "finalOtherClass"
paramsToSave = ("spinDirection", "spinSpeed"))
In the above:
- entType is the class instance (in python) of the entity
- finder is a function that gets handed any class found whos type name matches one given to parentTypes. This function then checks to see if any class of our type can be retrieved from the parent, and if so returns True, and the instance it found. Else, it returns False, Node. (I.E. if it’s given a nodepath, it can check for a class stored via a python tag)
- constructor is a function that gets called and passed various named arguments, including a dictionary matching all the variables in paramsToSave, and the class’ parent if available. This function then assembles the class in full, and returns it.
- superClass is the name of an already-registered entity that can have all of it’s qualities appended to the ones in this function call, wherever possible.
I’m thinking of making my level editor open source, and including this system along with a python wrapper class that would pre-register most things any panda3d programmer would want (I.E. basic geometry support, occluders, external file references, colliders.) Essentially, create a file format that nixes all animation support and such for what’s more relevant for loading maps (I.E. custom game logic.)
Sorry for that large text blob, I might have gone into more detail than I needed to. Anyway, what do you think? Could this system be useful for any of your projects, past/present/future? Do you think you might use it if/when I make it?
Just to be clear, I’m not advocating to make this a must-have p3d tool, just an option for programmers to have.