Arranging the game code

General Discussion
1

Hi!..

After doing some test in main() I decided to move code to OOP…

How do you do to arrange your code?.. i.e , do you inherits from something to create your scenes?.. my first approach is that each scene is a different class, it has composition, but my scene does inherits nothing, is just a simple c++ class that contains NodePaths, Textures, Sounds and everything else that the scene has… then on constructor i setup the creation of nodepaths, position adjustements, then it calls to another function start() which call the framework’s main_loop(), then kept some shared function on a singleton.

Maybe there is a better way to organize all of this?..
Please enlighten this user.

Thanks

2

Hi! Since there is not a “right way”, you should find the way that better models your specific case. Looking at what you wrote, I would ask myself if creating multiple scene classes is really what I need. I would prefer a single Scene class, and every scene will be an instance of it. As instance, the arguments of the constructor may be the nodes, the positions, … Then the constructor processes these lists and creates your scene - so, you can create a lot of different scenes with a single class.

Generally, you need new classes (or subclasses) when you have new behaviors: if what changes is the value of data then this is an hint that you need new objects (correspondingly, when you have new behaviors - i.e. methods - you may need new classes or subclasses).

Please note that you should (generally) avoid creating a lot of scene’s subclasses for each new behavior. Typically, you should locate the “area” of the changing behavior and model exactly that (and this will naturally happen if you follow the single-responsibility principle). As instance, if it is in the creation code, then a creational design pattern would handle this. If your “flexibility” is located in the scene’s logic or in the scene’s states, then a Strategy pattern or a State pattern would be a better choice (of course, there are a lot of other patterns that you may consider). So, you typically won’t have a lot of different scene classes, but you will have several classes/subclasses which model the flexibility/complexity of your specific scenario (e.g. creation/logic/state/… classes).

2 Likes
3

I agree with the above, I believe!

As the poster above says, I don’t think that there is one “right” way of doing this; different approaches may work for different people, and different projects.

As to what I myself do (and noting that I’m speaking of Python development, not C++):

I generally seem to have a “framework” class that controls everything–that handles events, that manages which scene is currently active, and so on.

I then have a “world” class (which I imagine would be similar to your “scene” class); depending on the specifics of the game, there might be sub-classes to this that handle various specific sets of functionality. The “world” class is often responsible for managing the various objects of the game–enemies, NPCs, the player, weaponsfire, etc.

And finally, I generally have a “GameObject” class, which is the super-class to most, perhaps all, in-game objects: the player, NPCs, enemies, and so on.

As to NodePaths and the like, I tend to include them into my classes. For example, a “world” class might store the root-NodePath for the level geometry. Similarly, a “GameObject” class might store a “handle” NodePath by which the object is located, rotated, scaled, etc., as well as a “model” or “actor” NodePath/Actor, and perhaps collision NodePaths. Sounds would likewise be stored in their relevant objects–footstep-sounds in a “GameObject” class, for example.

If you want a basic example of this, albeit in Python, my “beginner’s tutorial” follows the above pattern, I believe; perhaps it’s worth taking a look at the reference code for the tutorial and seeing how things are laid out there.

(The reference code is linked in the “Start here” page, I believe.)

1 Like