Thank you so much for the insight.
Question: how do you generate collision data for the level? Is this part of your export script?
Development Log 3 - Levels and Enviroment Creation
Welcome to another devlog and this time going of my exploration of environment creation for the game with Godot and Blender.
With Office Point Rescue (currently on 40% sale here) I used modular pieces imported into Godot to create the levels. This was excellent for creating lots of levels. With time and care, repetition could be avoided. It did come with challenges though and certain drawbacks/limitations I don’t want for Heir of Eminence 2
Level creation is such an intergral part of game development but so many factors go into it. When it came to the core mechanical creation of levels though, this method of modular meshes in the engine editor was not always ideal.
Modular meshes made for Office Point Rescue
Positives of creating in Engine:
No switching of context between other applications, everything is simply in the editor.
Can create composite scenes from from the modular pieces (rooms etc.)
Rapid iteration due to moving things about then diving straight into the game without context switching
If you don’t have a piece then you need to create it and import it. This can disrupt iteration and just generally be a pain
All your modular pieces can only make compositions of what you designed it for. You have to have either a lot of forsight, planning or experience to just make a set and have it work for 90% of you levels/environments
Changes or errors can be laboureous. Having specialised pieces or geometry are a bit more expensive in terms of time.
All the individual pieces need be combined into a single mesh for performance. This can be done at runtime or saved as resources, but eitherway extra pipeline work/coding.
Part of the issue with importing meshes is the 3d workflow from 3d editor of choice to Godot. I got around this by creating one-click export scripts from Blender and likewise for import. I had to create a pipeline of importing the meshes into the desired scenes and formats as well as attaching materials and collision. Once done, it worked perfectly but creating a new piece or shape of module would still be an unwanted effort when making levels.
With Heir of Eminence 2 I have chosen to go with greyboxing the levels, testing and then upon having the desired gameplay polishing it up and exporting the entire thing to Godot.
Area 1 blockout
The reasons for doing this was the areas in Heir of Eminence 2 will be explored and traversed repeatedly. There will be a lot use of the geometry rather than in OPR (Office Point Rescue) where if you blast through a level, it’s done and you won’t see it again until the next playthrough.
This means the investment in the environment’s detail and form is much more worthwhile.
The other reason, is in Godot 3.2 (or maybe was introduced in 3.3) had an incredible update to the light mapper. It works absolutely perfectly with individual modular pieces but having fewer, larger meshes makes using the light mapper much easier.
Heir of Eminence 2 is all about atmosphere as well as growing your character and smashing monsters. It needs to have shadows and global illumination , that and it just looks great.
With this workflow, I greybox/draft the area. Iterate on the layout optimising the desired gameplay and then work on texturing, architecture and environmental details. This is then imported into Godot and baked.
Area 1 textured. Modular pieces are still used, but only in the 3d modelling program (Blender)
It’s a tried and true method but everyone works differently and different projects/games have different requirements. I’m loving it so far as I can iterate almost as fast as with my previous method due to creating a one-click pipeline for exporting/importing levels.
So far the results have been excellent. The look is just as wanted and the light baking looks really nice. The performance (currently) massively surpasses OPR so all wins.
Area 1 in game with baked lightmaps.
Of course, as development continues things will change and I’m sure problems here or there will crop up but I will of deal with that if/when I get to it.
Thank you for checking out another development log. Things are going a little bit slowly at the moment, but progress is going well. The next log will hopefully be focused on more of the gameplay, but until then.
Log in with itch.io to leave a comment.
Thank you so much for the insight.
When I was doing levels modularly, it was part of the script. Premade collision scenes were made in Godot, and then attached based upon a suffix of the imported mesh name.
This time around, it's using a static trimesh that is generated in Godot (initiated by the import script). It isn't particularly performant but currently it has no significant impact upon this game's performance. If that changes I'll consider another solution.
That's really cool so far. Do you add the lights than manually in Godot or can you use them from blender?
Thank you. I'm currently placing them manually. Once I've finished this first area I'll have a better idea of extra things I need to put into my import and lights will be one. The torch models themselves are just part of the level, so with the next iteration of import code I'll (hopefully) add automatic placing of the torch flames and light entities.