My Class Hierarchy

Mobiles will be the base class here, it handles all coordinates for moving objects... Here is how it works... This is just the Mobiles class hierarchy.

For a 3d Space based FlightSim/RTS, capable of cockpit view, and third person POV, build space stations around your planet to defend it. Exploit a planets minerals and explore and conquer the Solar System!


Mobiles -> Planets, Ships, PlayerMobile, Asteroids, Comets
Planets -> Ice, Moon, Lava, Green, Aquatic, Desert
Ships -> StarFighter, StarDefender, BattleCruiser, TradeShip, Worker
Asteroids -> Mineral 1, Mineral 2, Mineral 3, Mineral 4, Mineral 5, etc


That is what I have for the mobiles class, Everything that inherits mobiles will send coordinates to mobiles, mobiles will handle coordinates and then send it to the OpenGL Rendering Pipeline for the rendering process.... Few questions:

What do I connect mobiles to? A global GameEngine class, that ALL classes inherit?

PlayerMobile class will ultimately use many other systems, such as a HUD class system, menu systems, etc, how and which classes do i connect it do?

I think you have a good layout. It shows you can organize to a relatively high degree, which will make your life easier.

For complex systems I have devised a manner which I religiously follow whenever I develop an application. In general, I use a client-parent based manager system. What does this mean? It means that *all*of the really important functionality is implemented in manager classes. As of right now, my manager classes look like this:

-A renderer class manager ... the clients are stored in containers which are various types of primitives to render using the fixed function OpenGL pipeline (tris/quads, textured tris/quads, vertex lit tris/quads, alpha blended tris/quads, spheres domes etc etc)....all rendering is a manifestation of adding a client to the renderer. All objects are allowed to add themselves to a renderer by calling their 'Draw' hooks, which paints the object by adding the required primitives to the renderer, and then at the end of the frame the actual rendering functions are called (and all similar types are drawn at the same time).

-A renderer2 class manager, same as above, but fits OpenGL 2.0 specification (almost no fixed-point OpenGL...all shaders, but a somewhat similar layout)

-A texture/material class manager, which loads textures and hands out texture IDs...the existance of a texture is a client of the texture class manager

-A 'movement' manager, which is really a rigid body physics manager...anything that wants to move adds itself as a rigid body to the physics manager, which goes through the various process of collision detection and response following newtonian laws of physics

-A GameExport manager, which in the days of Quake is really just supposed to be that which puts the game engine API into a dll, but in this case it is what ties all of the engine components together. It contains hooks (function pointers) which delegate what functions to call based on what Game you are playing (but, it is specifically built to work with my engine).

There is no one way to tie everything together. A sane approach would be to just make everything derive from a 'GameObject' class...the 'GameEngine' could be a manager in itself, and its clients are 'GameObjects.' Anything that is an entity in the game is a GameObject. It makes sense, the overhead is pretty negligible, for the alternatives in professional titles typically implement this in pretty sophisticated ways, which often even includes writing a virtual machine, writing a game API which must be exported/imported by the engine and tying everything together is only done through 'virtual function calls' and jumping from one virtual instruction to another...this manner is more effective for C however...the former approach is adequate in an object oriented environment.

Quote:

---

Originally Posted by BobMcGee123

I think you have a good layout. It shows you can organize to a relatively high degree, which will make your life easier.

---

It is a newfound skill, I just relearned how to write OOP over the last couple weeks

Quote:

---

Originally Posted by BobMcGee123

For complex systems I have devised a manner which I religiously follow whenever I develop an application. In general, I use a client-parent based manager system. What does this mean? It means that *all*of the really important functionality is implemented in manager classes. As of right now, my manager classes look like this:

---

So I use super classes such as Movement (physics), Renderer (artistry), Textures(for textures!)... And make all the mobiles use those classes to help define themselves and what they do, and all the classes of mobiles will do is Send information to these classes.

Quote:

---

Originally Posted by BobMcGee123

-A renderer class manager ... the clients are stored in containers which are various types of primitives to render using the fixed function OpenGL pipeline (tris/quads, textured tris/quads, vertex lit tris/quads, alpha blended tris/quads, spheres domes etc etc)....all rendering is a manifestation of adding a client to the renderer. All objects are allowed to add themselves to a renderer by calling their 'Draw' hooks, which paints the object by adding the required primitives to the renderer, and then at the end of the frame the actual rendering functions are called (and all similar types are drawn at the same time).

---

So clients, such as Mobile->Ships->Starfighter, sends information (probably a 3ds model) to a renderer class manager..[/quote]

Quote:

---

Originally Posted by BobMcGee123

-A renderer2 class manager, same as above, but fits OpenGL 2.0 specification (almost no fixed-point OpenGL...all shaders, but a somewhat similar layout).

---

UHG, i'm not going to try pixel shaders on my first big game

Quote:

---

Originally Posted by BobMcGee123

-A texture/material class manager, which loads textures and hands out texture IDs...the existance of a texture is a client of the texture class manager

---

Loads textures and then clients apply them, and then send them to renderer

Quote:

---

Originally Posted by BobMcGee123

-A 'movement' manager, which is really a rigid body physics manager...anything that wants to move adds itself as a rigid body to the physics manager, which goes through the various process of collision detection and response following newtonian laws of physics

---

Yay, collision detection... gotta learn the various algorithms n stuff..

Quote:

---

Originally Posted by BobMcGee123

-A GameExport manager, which in the days of Quake is really just supposed to be that which puts the game engine API into a dll, but in this case it is what ties all of the engine components together. It contains hooks (function pointers) which delegate what functions to call based on what Game you are playing (but, it is specifically built to work with my engine).

---

This is for when I actually decide to encapsulate my engine, right?


For an Idea of how I want the game to look and feel, Google Eve Online, and Homeworld

I realize I'm not eloquent, and if you've just recently learned how to use OOP then I applaud your learning curve. I'll try to clarify what I was saying in each instance.

Quote:

---

So I use super classes such as Movement (physics), Renderer (artistry), Textures(for textures!)... And make all the mobiles use those classes to help define themselves and what they do, and all the classes of mobiles will do is Send information to these classes.

---

Yes, this is exactly how it works. You keep the really vital stuff that will be reused often, such as the equations of physics for motion, and the rendering functionality, in the really important 'manager classes' and exactly as you mentioned, all the client classes (classes of mobiles) just send information to the 'manager' classes.

Quote:

---

So clients, such as Mobile->Ships->Starfighter, sends information (probably a 3ds model) to a renderer class manager..

---

[/quote]
Yeppers. In my applications I use .ms3d, and it just says to the renderer 'add a milkshape3d model to the renderer' and it denotes its position, and orientation.

Quote:

---

UHG, i'm not going to try pixel shaders on my first big game

---

Yeah, I really wouldn't worry about it bro.

Quote:

---

Loads textures and then clients apply them, and then send them to renderer

---

The texture manager and renderer are, at least in my implementation, separate entities. However, the renderer and texture manager often communicate (the texture manager is in charge of holding all of the unique texture Identifications...it stores the actual OpenGL texture, but does not duplicate the same texture more than once, and if the texture cannot be found it returns an error texture. Each renderable object that needs a texture asks the texture manager to load the texture...the texture manager loads the texture if it doesn't already have it, otherwise it just returns the index of the texture that already exists. When a texture needs to be bound, the renderer asks the texture manager to do it).

I don't know how much sense I am making so I'll post my texture manager


edit:

Quote:

---

For an Idea of how I want the game to look and feel, Google Eve Online, and Homeworld

---

Yes, I am familiar with homeworld. You may ultimately find that the way I've detailed things doesn't work with how you think, which is okay. If you'd like to look for a more 'official' manner of laying things out in a game, the construct for that is typically called a 'scene graph.' Look for an API called OpenSceneGraph, and just search for the term on gamedev.net (perhaps even wikipedia).

So the classes of mobiles( the clients ) holds information on which textures will be used for the model, the clients send this information to the render class, the render class requests the ID from the texturemanager class, render throws it all together, and then, straight to DrawGLScene it goes...

Cool...

BTW I'm in love with your Texture Manager! Can I use it :D

Quote:

---

So the classes of mobiles( the clients ) holds information on which textures will be used for the model

---

Yep

Quote:

---

the clients send this information to the render class, the render class requests the ID from the texturemanager class, render throws it all together, and then, straight to DrawGLScene it goes...

---

Exactly. Again however, I must stress this is just how I do it. Granted, I think it's a pretty intuitive/useful way to go, but you might want to look around at other sources. The renderer for Quake3 was recently released, you may want to download that.

I coded that stuff 'on my own' but I could not do so without viewing many other sources...I couldn't find the layout of various files so I had to essentially learn the file formats by reading other peoples source code...I don't ever copy code, but that is still more-or-less regurgitated from other sources.

I don't mind if you use it, I still occasionally find bugs with it to be honest...this was one of my own projects so I never format my code for production specifications (no pre/post comments and I leave all my data public) subsequently I can't imagine any of that is coherent but I don't care if you use it.

EDIT:
something else I must add...in the 'createtexture' function it checks every single time to see whether or not there are any textures present...if no textures are present, it loads the first texture which is always the error texture. The reason being is that if you try loading a texture before you let OpenGL initiate itself then you cannot even get the error texture to load...subsequently, I didn't put the error texture loading in the TextureManager constructor.

EDIT1: I've been pretty bored lately, I like your project and you seem to learn pretty quickly. If you want somebody to collaborate with or even help do some of the coding I might be interested in participating.

Theres my current project, its quite far from done, incredibly messy, but it shows that i do know syntax :d