• Advertisement
Sign in to follow this  

Game Design OOP

This topic is 4179 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Advertisement
Hidden
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

Share this post


Link to post
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-

Share this post


Link to post
Share on other sites
Hidden
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?

Share this post


Link to post
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-

Share this post


Link to post
Share on other sites
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-

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Hidden
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!

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites
Hidden
Ok, lets say I do something like this:

SystemClass: Initialisation, Config, MainLoop

Then

WorldManager

Renderable Objects Abstract Objects Both inherit from WorldManager

Why would I need to rewrite it?
I would then inherit classes from renderable objects for the map (Terrain), the buildings
In the abstract objects I would go for a list of the buildings and their stats that would inherit from a virtual tile map.

Would that work properly?

I don't get why I would need to rewrite.

Share this post


Link to post
Why don't you just try with a RAD editor?
Make your demo with a Game tool like these: Blender3D, Virtools, DarkBasic, Macromedia Director etc.

May you will develop your Game demo around two weeks. Don't waste time thinking about elevated programming topics and OOP. Some people have done a solution ready to use for you. Reinventing the Wheel?

Share this post


Link to post
Share on other sites
Hidden
Maybe because I like programming, know how to programm (well maybe not much OOP but procedural yes), and I want to change from doing all procedural programs.
I did some OOP before but wasn't game stuff.
And I am quite interested in the all architecture of this stuff.
Plus I don't see the fun in using tools that don't give you enough liberty.
(And I am a programmer not an artist, so the demo would be more on the programming side than the artistic one)

Share this post


Link to post
Hidden
Ok, before going further I'd like to show you what I did for the moment:
I went back on my old programming books and reread most of the stuff on OOP.

Free Image Hosting at www.ImageShack.us

I wrote the code for this and it all works.
Now I'd like to know if you think this is a good way of structuring it?

Now I intend to inherit from CWorldManager a CTileMap and a CTerrain (that is dependant on CTileMap (which will create a virtual tilemap, CTerrain being the actual physical object).

Thanks for your help!

Share this post


Link to post
hmm why do you put CSystem in CWorldmanager? Id suggest make CSystem a static class (after all your only gonna have 1 main loop). CSystem would have all kinds of static functionality, a time function, a sleep function and so on.

Don't try to inherit too much, its a mistake many ppl make when starting OOP. Here are some old but still interesting aricles Object Mentor, take a look at the "Patterns" and "Object Oriented Design" sections.

Share this post


Link to post
Share on other sites
Hidden
Well I don't inherit CWorldManager, it's a dependency.
Anyway, if I don't do it that way, when I want to get the pointer to the device,driver,scene manager, should I go on creating a pointer to CSystem?

Share this post


Link to post
Sign in to follow this  

  • Advertisement