I’m new to gaming, not programming, and after reading and playing with some sample code in the past few days, I’m very excited to write a new game with panda3D!
I went over and played with the examples, @wolf’s collection, and other resources I could find.
The biggest thing I’m missing is a guideline for the structure (architecture) of the program and the code.
All of the examples I saw are a single long python file, which is wonderful to go over when learning a concept, but not a scalable way to write code.
I’m assuming that the main “world” class will take care of the heavy lifting: initialization, timing, events, and general orchestration, etc., but I’m not sure about the other classes.
For example, I would like to have a separate class for separate “game objects”. What’s a common way to do it? Keep them as Panda3D aware objects, and let them import panda3D packages? I rather have these classes decoupled from panda3D code, and maybe use some proxies to connect them to the world. Somehow I have a feeling that it should be a common practice, but maybe it’s just something that’s already been tested but discarded.
In short, the question is: While Panda3D is the engine of the whole game, is there a good guideline on how to create a good clean architecture that decouples the game logic from it?
I would love to hear your thoughts or look at (preferably recent) code samples that do it.
I think that this is something on which different developers will have different preferences: some might want a high degree of decoupling; some (like me) might not be too bothered; and others may lie in-between.
For a simple example of how I tend to do things, you could take a look at my “beginner’s tutorial”, here:
The short version, however, is that I tend to create a “GameObject” class that handles logic (which in turn is controlled by a Panda task), as well as containing Panda-related elements related to the object (like a model, or a velocity). This class is then often sub-classed to create specific functionalities.
There are a lot of ways one could choose to build up their games, Panda3D itself won’t limit your choice. As you know my code collection, you may also be interested in my books that go more in depth with creating a game from scratch and all the bits and bobs around it. https://github.com/fireclawthefox/panda3d-tutorial/blob/master/Panda3D%20Tutorial.pdf
Regarding the structuring itself, it heavily depends on how granular you want to make things and that can vary from application to application. I myself try to make the structure fit the needs of the project. If it’s a simple game that won’t be extended in the future, everything can be packed more dense to keep development time down. If you plan on something larger, you can go and separate things out like having classes for the game objects, GUI layout, logic bricks, etc.
There also have been made efforts to support an ECS type development for Panda3d which may fits with what you had in mind: https://github.com/TheCheapestPixels/wecs
Hi! After considering the previous suggestions, if you want to decouple game’s logic and low-level code, you may want to consider the dependency inversion principle.
Thanks for all your replies! @flavio - that was my line of thinking. I was wondering if there is some “standard” way to do it…
@Thaumaturge - I absolutely agree. For each his own… I assume that most people here are developing “indie” style, so that’s even more true than usual. My background is with bigger teams, so my default thinking is skewed towards breaking the code to components early. It can definitely be an overkill for a small project. And thanks for making that guide!
@wolf - again, I entirely agree. The ECS might be the closest to what I’m looking for. I’ve just started to read about it, and it looks promising.
For future readers of this thread (even if only me), here are few things I’m looking at: