4 replies to this topic

[Tispe]

Hi

I have written small game in Directx with animated meshes, sound, GUI and takes in user input via windows messages.

I have determined that my code is kinda chaotic. I am passing down pointers to new object instances, copy them and store them locally, all just to avoid global variables. A lot of "tweaks" just to satisfy all those "don't do that" threads around here.

Now, I want to rewrite the code and my idea is to have a Super Game Class. Such that I can do the following

int WINAPI WinMain(HINSTANCE hInstance,
				   HINSTANCE hPrevInstance,
				   LPSTR lpCmdLine,
				   int nCmdShow)
{
//Some Window code
MySuperClass MyGame;
MyGame.init();
My.Game.run();
MyGame.cleanup();
return 0;
}

//The WindowProc function goes here

The idea is that LPDIRECT3DDEVICE9 device and others can be member variables of MyGame. Then inside MyGame I can pass down "this" and get all the variables I need down to the functions that need them.

Is this a bad or a good idea?

Also, when I pass down "this" to the render classes at init, I make a copy such that all the sub classes can reference the Super Parent with all its children and member variables.

[Seabolt]

So it depends on what you want to do. If you're looking to make a game that may go onto other platforms, the "SuperGameClass" idea isn't very good since your entire platform is now coupled to your game code.

Also when passing in your game class to everything, it becomes easier to access things, yes, but now any change to the SuperGameClass will now affect every piece of code below it.

As a general rule of thumb, try to abide by the Single Responsibility Principle, which means that your object should only do one thing, and one thing only, and use a collection of those objects to build your game.

[Tispe]

So you are advocating what I have done so far, code with a lot of passing things around, copy pointers here and there (making dependencies i.e Addref()) with the resulting code being chaotic?

What is the next best thing?

[Seabolt]

So I'd argue that by removing coupling you reduce dependencies. But the approach of using the "SuperGameClass" method is very similar to a design pattern known as the "Singleton" pattern. This code will allow all global states to be easily queried at almost any point in the code, but it does introduce a lot of coupling and in larger projects will create a terrifying amount of spaghetti code.

Though I suppose that's something you have to experiment with and see how it goes for yourself

[Jason Z]

If you consider what your SuperGameClass would do, it is essentially just a container for everything else that will be used in the whole game. Now consider the portions of the SuperGameClass that only correspond to the rendering aspect of the game. Split those parts off into a SuperRendererClass. Then repeat with the other sub-systems in the game. From your description, you could probably use a renderer, an input manager, a sound manager, etc...

In general, you should follow the advice that Seabolt gave - try to make your classes have a responsibility, and then think about what other objects need to use it and how it will be used. This is what shapes your class hierarchies and the interactions between all of the various objects in your application.