Best approach for separate modes/scenes

[joshbenner]

Experienced programmer, but new to Python, Panda, and game programming. Looking for sanity check/input:

My game has several modes (think mini games, or different modes like strategic vs. tactical modes). Each mode has different key binds, graphical elements, and largely different code controlling what's going on. The player will switch between these modes during normal course of play.

I feel compelled to somehow encapsulate their functionalities into separate objects, probably of some shared parent class. My first instinct is to create a child class of PandaNode that handles applying keybinds, transitioning between modes, etc. Then, each mode would be another child class of the main "mode" class, and when a mode switch happens, I simply detach (maybe lose references) to the previous "mode" node, and instantiate and attach the new mode.

Does this sound reasonable/sane? Is there a better/alternate approach?

Thanks!

[cemper]

I'm not really an experienced software designer, but my first instinct would be to have some kind of state machine which handles various "MiniGame" objects that could essentially do what they want as long as some clean_up() method gets called every time you leave a MiniGame and some setup() method gets called when you enter it. This way you only have to make sure that base and taskmgr are exposed to the MiniGames to make programming them feel like programming an independent game. Of course, you will need some way of sharing state between them, and the practicability of this approach may depend on how much state you want to share.

Subclassing PandaNode doesn't appear like a good idea to me. When you think about subclassing a new class B from a class A, you should always ask yourself whether in the real world you would say that B is an A. Is a minigame a scene graph node? Obviously not. Therefore subclassing most likely is a bad idea.

[Hollower]

You'll want to take a look at the FSM class, documented in the manual starting here and the API here. I also found looking directly at the source code to be helpful in fully understanding how it works. Also check out the API for DirectObject which FSM inherits from.

[kurohyou]

There are numerous posts on the forums as to why subclassing PandaNode (or any node which could be inserted into the scene graph and retrieved later for that matter) is not a good idea. See http://thetechartist.com/?p=325 for my attempt at a thorough explanation.

If you want a good base class which supports key binding and events then DirectObject is probably the way to go as the others have suggested.

[heek_]

I really don't have the time to read that text now, but I guess there's some misconcept going on.
The numerous posts I saw suggest subclassing a NodePath is a bad thing, but I guess subclassing a PandaNode is the way to go.

The problem (one of?) with the NodePath is that you must create a circular reference to retrieve the info you want later. And that cause objects not being destroyed ...

But I'm not saying you should subclass in this case. And I'd say the same as cemper, it doesn't sound right.