I’m new to panda3d and working through the beginner tutorial from ArsThaumaturgis.
While doing the tutorial I thought about how to structure my project once it gets bigger.
My first idea was to simply build a ‘parallel’, panda3d independent object structure (either game objects with inheritance or some form of simple ecs).
And than simply add one update task that updates my internal game world representation and have some logic that updates panda3d objects (through some form of listener or notifying pattern)
But (aside maybe from keyevents) that would imply having only one single huge panda3d task.
Will this lead to any problems? I’d like to concentrate the calls to panda3d to as few places as possible.
It sounds like you are on the right track with regards to structuring your game logic in general.
There are many ways of structuring your game code - Panda is not particularly demanding. Using the task manager offers a number of features for complicated scheduling, such as coroutines, delays, threading, etc. If your game structure doesn’t require those features, and you’re already managing a list of all the things that need updating, then by all means, feel free have your entire update loop in a single task. If you really wanted to, you could even ditch the task manager altogether and invoke the Panda subsystems that are normally also updated by tasks (rendering, audio, etc.) yourself.
You may eventually find that, as the complexity of your game grows, you need some of the features of the task manager, at which point it might make sense to refactor your code to make more use of it rather than reimplement those features in your own update loop. If you build an ECS, for example, you could let each system be updated at a different rate, or you could spread certain workloads out over multiple threads, or have some update tasks be suspended while they’re awaiting some operation while other tasks continue to run. But you could keep it simple for now and cross that bridge when you get there.
