What's a clean way of separating the game into "scenes&

I’m just getting started with Panda3D and I’ve noticed that 99% of the code I’ve stumbled upon seems to be centered around a monolithic class derived from ShowBase and it seems like there can be only one of these around without running into problems.

Cocos2D has the nice concept of scenes with a diagram to illustrate what sort of functionality I’m looking for. As far as I can tell Panda3D does not come with anything like this built in, so I’m going to have to roll my own, which means that sooner or later I will run into problems of some sort and it makes more sense to learn from the experiences of others than to make too many of my own mistakes.

So how have you managed different scenes in the past? What sort of classes did you use? What did you inherit them from? How did you trigger and handle transitions between the scenes? And what are the “best practices” here?

That looks a lot like something a finite state machine could do, which is something that Panda provides. You can, if you want, separate these stages into classes, such as Menu() and Highscores() that you can create in your enterXX methods of your FSM.

The usual Panda example code looks something like:

[code]

class App(ShowBase):
def init(self):
# set everything up

a = App()
a.run()



...so it seems a bit, um, non-obvious how one would go about doing this. Do I create new classes that inherit from ShowBase? (e.g. MainMenu, Game, CutScene.) How would I go about swapping out the current ShowBase subclass instance? etc.

One approach might be to keep one ShowBase subclass around and fire off events to different other classes, whatever the current one might be. I guess I'm gonna go down that road.

Usually you have exactly one ShowBase instance that is instantiated very early.
From your ShowBase subclass you could e.g. instantiate CoreFSM which is a subclass of FSM. Inside the FSM you could have your states like “menu”, “highscores”, “level1”. How you divide your game depends on the type and your preference. I used to have three states: menu, loading screen and scenario (3d game world), where each was loaded by another proxy class.
If you look at the FSM class, you’ll notice that you can request any state, which in turn calls enterState or something like that. There you can instantiate your class that handles main menu or anything else. On a state switch you can then clean up that class and start another one.

If you need code samples, let me know.

If you have any code samples lying around, especially about how to reset the scenegraph before going to another scene, I would very much appreciate it :slight_smile:

Your code samples are top notch. Your multiprocess wxpython+panda example is the foundation of my map editor. Many thanks! :slight_smile:

github.com/nemesis13/Azure–Inf … re/core.py <- My old Core FSM
In the doc directory you’ll also find some old diagrams regarding that.

The Core basically passes a scenario name or instance to the ScenarioProxy class, which then loads up the requested scenario and offers it common operations through a list of managers.

For cleaning up I used to make all assets self-contained classes, which have the ability to fully clean up themselves. On scenario switch the asset manager would ask all assets to destroy themselves. I have no idea, though, if that would work for bigger and more complex scenes. I should probably replace the whole scene graph - which, by the way is easier than one might think.

I should also mention that although that concept worked for me more or less, I abandoned the project in favor of a more unity3d-like workflow, which I’ll try to implement in a visual editor (basically unity with panda3d backend).

Thanks for the code sample! I went through it to try and come up with insightful questions, but I can’t think of any. It’s actually rather clear.

Personally I try to avoid magic global variables as much as possible, so instead of using ‘base’, I just pass around the ShowBase instance everywhere or make it accessible through a singleton.

Is there some particular reason you’re sticking with Panda3D and implementing a Unity3D-like workflow instead of just going with Unity3D?

Another solution to have clean global variables is making base a module-wide variable or a static class member.

Panda3d is the best open source engine around and the fact that you can use it with Python makes it even more attractive. Sadly, there’s neither a real workflow model nor a full-featured visual editor around. Unity has both, but it’s closed source, hardly extendible and many features are for paying customers only. Also with Unity you still can’t develop using Linux (although you can develop for Linux as a target platform since version 4).
I think that an OSS Unity clone could actually become attractive in the industry, since so you’re independent and can extend and customize it at your own.
I don’t really think I ever get that far, but it’s fun working towards something :slight_smile: