Scene Stack for my Isometric Action Game

Hello! I'm currently working on an untitled isometric action game in Godot. I think one of the biggest issues I had when coming over to Godot was really wrapping my head around how to structure my scenes. In Godot, EVERYTHING is a scene, meaning it can sometimes be tricky to determine when to make Packed Scenes, Inherited Scenes, or just make Local Scenes when putting everything all together.

At this point, I'm by no means a genius when it comes to project architecture in Godot, but I have a few finished projects under my belt, so I thought I'd share some of my findings and process for my current project. I'm going to show a single scene from my project, then break down where and why I'm using the different scene types. So let's get into it!

Top Level Structure

This is the highest level scene in my project. I've found that the best way to structure an entire game in Godot is to use a single Main scene, and then swap levels in and out as needed as an Instanced Scene. This structure makes it easy to set up singletons like transitions or debug UI.

It's important to note that none of the nodes here are coupled to one another-- That is to say that any one of these nodes could run on its own. This is important to make sure we can smoothly and efficiently test any nodes that would typically be used as a child of Main. If the nodes were completely reliant on one another, we'd have to swap a variable each time we wanted to test one of our scenes, which isn't really ideal. As an example, if I ran "Fury Level" here without being in Main, everything would work as intended, I just wouldn't have access to my Debug UI.

Stage Level Structure

Diving into the actual Stages, we start to see more complex scene structure. This is my template scene that I use when I'm designing new levels. This might look pretty barebones, but that is the idea! I've been trying my best to move away from using inheritance in my scene structures, partly because of some nightmare restructures I had to do when working on Empty Spiral, but also partly because I'm having a lot of fun determining how to set up scalable "components" using composition. If you've never tried structuring your projects using composition, this is a great video by Bitlytic that explains the differences between inheritance and composition, and why you would want to use one over the other.

You might also notice that I have several Lights in my scene. If you're interested in seeing how my lighting works, you can check out this write up that I did explaining how to set it up.

Now, this is an example of one of my levels that use the Level Template filled out with all of the additional scenes that compose the finished level. I've made generous use of the "Editable Children" property of my inherited scenes (shown in yellow) to make sure each level feels unique.

You might notice that a majority of my Inherited scenes don't actually affect the content of a level, just the environment the level is in. This is important!

The main problem with inheritance is that once you define your "is a" relationship, you must check all of the boxes that make that statement true. A car is a vehicle, and so anything a vehicle can do, a car must do. This is the slippery slope of inheritance. While it might be a good way to share methods in the beginning, inheritance in games can often bog down the actual creation of content due to all of the conditions that need to be fulfilled to make a child object function properly. As a result, I've opted to just used my inheritance nodes as a organizational structure for things I know will be in every scene. Essentially turning it into a little kit I can use so I don't have to set up the base.

There are some unique nodes though. For example, I've added some post-processing effects via shaders to this scene as children of the CanvasLayers BG Effects, Water Effects, and Foreground Effects. I don't know if I'm going to want post-processing on every single level, and so those aren't a part of the Level Template scene.

Room Scene Structure

That brings us to the lowest-level scene in my project, the rooms. Similarly to the levels, I'm using a base scene to outline the aspects of the room that I know every room will have. I've split up my rooms like this so that I can design each room from the same level scene, rather than designing each room in a vacuum. In other words, none of the individual rooms are saved in my project. They only exist as a part of their respective Level scene.

Since I'm going for an isometric-style, I have a TileMapLayer for each level of my room's map and an additional TileMapLayer to define borders where I don't want the player to go. From there, I also have included a CollisionPolygon to define the boundaries of the room, and a custom A* Pathfinding setup for letting enemies move around obstacles. (Engine devs, please please please allow support for Isometric tiles in the AStarGrid2D. It would have saved me SEVERAL hours.)

So, all of this comes together in the Level Scene, where I add an instance of the Level Template and deck it out as I see fit. Again, I use "Editable Children" so I can modify the respective TileMapLayers, and then I use composition to add in additional elements I want, like enemy spawners, dialogue triggers, and the like. I troubleshot the Y-Sorting issues for a few hours, and made a few sample rooms to make sure I'd got my inherited templates with an appropriate amount of information, and I was good to go.

Final Thoughts

The end result after all of this is a scene structure that is scalable enough to make lots of levels, while still having enough structure to save time in the areas that slow me down the most. I feel like solo-development is a lot of that-- Finding ways to make your life easier without designing yourself into a corner. I'm pretty happy with how this project is coming along, and this structure of Template Node ~> Inherited Fleshed Out Node is really letting me spend more time designing and less time troubleshooting.