Game Design OOP
I'm bumping this up cos I need some help!
I've made some progress, I looked through some articles and I thought about doing it this way:
Make a GameManager class where I would Initialize and do the configuration of the game, but also the render.
Then I would create two classes than Inherit, one for renderable objects and one for non renderable.
Should I then go straight to map/buildings etc...in inherited classes? Or another step is needed?
Any better ideas?
Thanks
I've made some progress, I looked through some articles and I thought about doing it this way:
Make a GameManager class where I would Initialize and do the configuration of the game, but also the render.
Then I would create two classes than Inherit, one for renderable objects and one for non renderable.
Should I then go straight to map/buildings etc...in inherited classes? Or another step is needed?
Any better ideas?
Thanks
I know this is hard to see if you're just beginning with OOP, but for a usable design (and not just grouping some stuff into classes) you'd have many more classes.
1) There's a simple rule that says: Deriving A from B effectively means "every A is a B". So is a 'Building' a 'GameManager'? Nope :)
2) Try breaking it down to a much finer level. Make each class responsible only for one thing. Don't be scared of using classes excessively.
For example, write a 'WorldManager' which manages the game world, create an 'Actor' class from which you derive a 'MedikitActor', 'MinigunActor', 'PlayerActor'. The 'WorldManager' has a list or later a quadtree or more advanced structure for storing the actors. Continue like this until you've got all your game objects in place.
Instead of one GUI class which handles anything from drawing controls, gathering user input, managing windows and so on will likewise not yield any advantages from using classes. Split it up to 'WindowManager', 'Window', 'Widget', 'ButtonWidget', 'ButtonPainter' and more.
Here's a chart of my framework in an early to give you an idea how it could be done:
https://devel.nuclex.org/engine/browser/nuclex/trunk/Docs/Architecture/Nuclex.png?format=raw
(the GUI system I was referring to is in the lower right)
-Markus-
1) There's a simple rule that says: Deriving A from B effectively means "every A is a B". So is a 'Building' a 'GameManager'? Nope :)
2) Try breaking it down to a much finer level. Make each class responsible only for one thing. Don't be scared of using classes excessively.
For example, write a 'WorldManager' which manages the game world, create an 'Actor' class from which you derive a 'MedikitActor', 'MinigunActor', 'PlayerActor'. The 'WorldManager' has a list or later a quadtree or more advanced structure for storing the actors. Continue like this until you've got all your game objects in place.
Instead of one GUI class which handles anything from drawing controls, gathering user input, managing windows and so on will likewise not yield any advantages from using classes. Split it up to 'WindowManager', 'Window', 'Widget', 'ButtonWidget', 'ButtonPainter' and more.
Here's a chart of my framework in an early to give you an idea how it could be done:
https://devel.nuclex.org/engine/browser/nuclex/trunk/Docs/Architecture/Nuclex.png?format=raw
(the GUI system I was referring to is in the lower right)
-Markus-
Ok, so I split it up a lot more!
But where do I do all my initialization, config and stuff? Should I create a class for that but not inherit anything from that?
But where do I do all my initialization, config and stuff? Should I create a class for that but not inherit anything from that?
Everything where it belongs. Do simple things in the constructors of your classes and distribute complicated stuff (loading your meshes, setting up your rendering system, etc.) over several methods that perform logical steps.
Let's assume you decided to create a 'System' class that manages the 'AudioSystem', 'RenderingSystem' and 'WorldManager' classes, it could happen like this (just an example from the top of my head):
- main() creates an instance of the System class
- The System class' constructor prepares the 'AudioSystem', 'RenderingSystem' and 'WorldManager' subsystem classes.
- main() calls System.Startup() or something similar
- The System class creates the game's main window and calls the Startup() methods on the 'AudioSystem', 'RenderingSystem' and 'WorldManager' that it manages
- main() calls System.Run()
- System::Run() contains the main loop and is responsible for giving the audio, rendering and world management classes an oppotunity to update themselfes each frame.
But this varies greatly from game to game. You might even want to place some initialization stuff into a background thread and keep the main loop / message pump running all the time so the application stays responsive while it is loading.
-Markus-
Let's assume you decided to create a 'System' class that manages the 'AudioSystem', 'RenderingSystem' and 'WorldManager' classes, it could happen like this (just an example from the top of my head):
- main() creates an instance of the System class
- The System class' constructor prepares the 'AudioSystem', 'RenderingSystem' and 'WorldManager' subsystem classes.
- main() calls System.Startup() or something similar
- The System class creates the game's main window and calls the Startup() methods on the 'AudioSystem', 'RenderingSystem' and 'WorldManager' that it manages
- main() calls System.Run()
- System::Run() contains the main loop and is responsible for giving the audio, rendering and world management classes an oppotunity to update themselfes each frame.
But this varies greatly from game to game. You might even want to place some initialization stuff into a background thread and keep the main loop / message pump running all the time so the application stays responsive while it is loading.
-Markus-
One more thing: Don't just blindly use my design ;)
If you're not comfortable with classes yet, it's rather easy to mess up (eg. loosing track of who owns what or not knowing how reach class B from within class A).
-Markus-
If you're not comfortable with classes yet, it's rather easy to mess up (eg. loosing track of who owns what or not knowing how reach class B from within class A).
-Markus-
There are more issues respect to a citybuilder game engine. It's not enough to define your game objects based on the 3D engine (Irrlitch). You'd need to define more abstract objects (like players, vehicles, houses, builds, furniture etc) and they must be Persistent (Able to be stored in a file). That can be well done if you make your game able to manage the whole state of the world based on Database Entities. You can embed a Database System with SQLite.
If you can manage your citybuilder with databases, your gamers will be able to extend it adding more complex entities without programming.
If you can manage your citybuilder with databases, your gamers will be able to extend it adding more complex entities without programming.
Also keep in mind that just because the language is OO, it doesn't mean that every function has to be part of an object.
I know it sounds silly to be reminding people, but I've caught myself a couple of times implementing something as a class when it was better to have them as a bunch of global functions.
I know it sounds silly to be reminding people, but I've caught myself a couple of times implementing something as a class when it was better to have them as a bunch of global functions.
Ok, so lets say I do it this way:
I create a system class where I do initialization, configuration and render every frame
I create a second class (WorldManager) from which I go for 2 different classes: renderable objects and abstract objects.
Is that a good start?
leoptimus: I'll think about it, but in the current state of things it might seem a little bit overkill as its just a very simple demo I want to make!
I create a system class where I do initialization, configuration and render every frame
I create a second class (WorldManager) from which I go for 2 different classes: renderable objects and abstract objects.
Is that a good start?
leoptimus: I'll think about it, but in the current state of things it might seem a little bit overkill as its just a very simple demo I want to make!
Quote:Original post by crackingod
Ok, so lets say I do it this way:
I create a system class where I do initialization, configuration and render every frame
I create a second class (WorldManager) from which I go for 2 different classes: renderable objects and abstract objects.
Is that a good start?
leoptimus: I'll think about it, but in the current state of things it might seem a little bit overkill as its just a very simple demo I want to make!
It's going to be a simple demo? Then yeah, you can do it like that, and you can store all the renderable things in a linked list. But, when you want to go for something more complicated, you'll most likely have to re-write most of it.
When you do re-write, you'll want to look at scene graphs, then all renderable things will inherit from a basic scene graph node class, and so on.
But, if you're okay with doing an almost complete re-write (which you'd probably have to do later on, even if you were writing a complete engine), then yeah, write it so it works. Then re-write with a better design. And again. But after that, you'll probably move on.
Sorry if I rambled on a bit.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement