I’m requesting a sanity check on a code-snippet, if I may:
I’ve implemented a means of optionally loading a level from multiple numbered parts. (Where originally I loaded from a single file.) Simple testing indicates that it works, but I’m concerned that there might be issues that I’m not seeing in my approach to it. So, does anyone see a problem with the following snippet?
Intended result: a level-model, including collision etc., rooted in a NodePath stored in the variable “self.geometry”. This will subsequently be searched for various sub-models–collision geometry, various tags, and so on–which are handled in various ways as part of setting up the level.
self.geometry = loader.loadModel(file, okMissing = True)
if self.geometry is None:
self.geometry = NodePath(PandaNode("partwise geometry root"))
working = True
index = 0
while working:
part = loader.loadModel("{0}_{1}".format(file, index), okMissing = True)
if part is not None:
part.ls()
for child in part.getChildren():
child.reparentTo(self.geometry)
else:
if index != 0:
working = False
index += 1
Note that single-file levels can get rather large, that being one of my motivations for this feature: it allows me to change part of a level without having to export and import the entire thing, a process that in larger and more-complex levels can take a few hours.
Basically: Is the above a bad idea for some reason that I’m not seeing? ^^;
Right now it looks fine to me–but I don’t feel confident that there aren’t issues with things like attempting to load and then checking that the result isn’t “None”, etc., and that there isn’t some huge inefficiency in this method, and that there won’t be problems with the resulting scene-hierarchy–or some other issue that I’m not aware of at all.
But I still have to store the actual geometry (visible and collision) somewhere. And while I do use level-model parts for some game-logic elements, it’s generally in cases in which it would be less troublesome to do so, I think. (Such as having a particular collider be registered as bearing a description that the player can examine.)
Quite a bit is indeed handled as you describe, I believe–but that’s separate from what I’m working on in this feature.
The approach seems fine to me. One thing that comes to mind is you might have to pull any lights out of the parts and add them to self.geometry so they can affect geometry across file boundaries. However, I don’t think EGG supports lights, so this may not be a problem for you.
Lights are handled in a somewhat… idiosyncratic manner in my game. ^^;
In short, there are only two halfway-“normal” lights: the sun, and the player’s lantern; these are constructed in game-logic, not stored in level-files.
However, there are also “blob-lights”, which don’t cast shadows, and which are handled by my custom shaders. These are stored in level-files–but they’re stored as ordinary nodes with some data attached to them via tags, rather than as actual “lights”.
It doesn’t really make sense to store the actual geometry and collision geometry. For example, if you take a barrel, you can create a collision geometry and assign it to all the barrels in the scene. This requires an additional description file. Which you can refer to in the level file. In short, you need a format for all types of objects.
Then how would you handle buildings of various sizes and shapes? Some ruined, some not? At the least the walls and floor of the level would be stored in the level-file, surely?
And as I said, I do have some active objects stored separately from the level-file; but some things are far more easily stored in the level-file.
Plus, it’s easier to see how the level is structured, how the traversal elements fit together, when you can actually see the models of those traversal elements in-place in the modelling program, I feel.
But that still wouldn’t show up in my modelling program.
And as I’ve said, I do have some of that.
Perhaps it would help if I gave concrete examples from my game:
In the second level, the one with the mound in the centre, there’s a tree standing next to two large stone structures. On top of one of those structures is a small wooden box that can be opened, and which contains a wooden key and a note.
The box, the key, and the note (if I’m not much mistaken) are all handled more or less as you describe: they’re separate from the level-model.
The tree and the stone structures, being specific to this level, are part of the level-file, collision included. Aside from simply making sense to me to have such things be part of the level-file, this means that I can see these traversal elements in the editor, meaning that scale and position are easy to keep in sync.
I understand, so you need to divide the object types into categories that are in the game. And develop a different format for each of them. This is like creating a behavior class.
That still doesn’t change the fact that some elements–like those stone structures–seem to me better stored as part of the level-file.
I mean, in the third level, there are quite a few buildings, often at least somewhat different from each other. They don’t have logic associated with them, so there’s no reason to make a class for them, but they do have visual geometry and collision geometry–and it makes no sense to me to store those separately from the level-model.
Also, one thing that might be worth clarifying: when I talk about the “level-file” in this thread, I’m referring to the file for the level-model, not the file that defines the logic of the level. Things like enemy placement, that wooden box that I mentioned above, etc. are all stored in another (non-model) file.
To be clear, it’s less what I do with the model afterwards that I was concerned about, then the potential consequences of loading in chunks this way, in part given that I do things with the model afterwards.
Or, to put it another way, my code–as used in the demos that I’ve put out for A Door to the Mists–previously just had the first line that I gave in the code above, but without “okMissing = True”. I’ve now added the rest, and have been feeling a bit anxious about whether it might mess things up some distance down the line… ^^;
