Yes.

quote:Original post by tHiSiSbOb
How else can I tie everything together in my program if not with one class?

whit name spaces. but you probably ment class solution.



[edited by - Craazer on April 3, 2004 3:19:51 PM]

quote:Original post by Magmai Kai Holmlor
Refer to the meditator pattern.

Hmmm, I thought that was the pattern that never actually did anything... (compare the sleep-pattern)

quote:Original post by Cibressus
thats the first time i''ve heard a master processing system called a god class, but sure why the heck not, we need more terms like that. just imagine in 20 years.

Programer: So i tooketh the arcane IPC of sorlan a wrapethed it about the sinfull API of quarlacran. then, from the higest heavens arived the GOD class which unfied all classes under one proud bane and beat back memory leaks into the lowest pits of the garbage bin.

LOL, really funny

I would say tha rather than having a GOD class I like to have a Systems class in my engine. In this System class I can then Add loaded modules and sort them accorting to cathegorys. Like:

Renderer - GLRenderer, D3DRenderer
Sound - DXSound, SomeOtherSound
etc...

And also have an ActiveSystems map where you for each cathegory have an active System eg:

Renderer - D3DRenderer
Sound - SomeOtherSound

Then this class could export a function like:

Module GetModule(const char* sModuleID, void** &pInterface);

to every module while the module is loaded. Now every module has access to other modules...

The best way of loading cathegorys and modules would be to have a script file like core.cfg and read from that file and load all the cathegorys and modules. This way you can later in the developement add a new system cathegory like:

Script - CLikeScriptSystem, HaskelLikeScriptSystem
SceneManager - OutDoorSceeneManager, InDoorSceeneManager

This is done easily by loading another .cfg file...
And now each System can use the new loaded module you
newly created.

I think it''s better to have a structure like this rather than having a GOD class or having namespaces.

The only negative I can find with this is that everything is built on Interfaces and sometimes it can be hard to build all the Systems with a common interface for each cathegory. Though if you manage to do this you will have a very flexible engine where you can add new Systems by simply creating DLL''s and later on activate the system from a .cfg file. The only thing I you will need to actually recompile for is if you change something structurally or want to add another platform... then you will need to add ModuleLoading functions etc...

I usually use a system like this:

class CGame{public:	Run(); private:	Init();	MainLoop();	Shutdown(); 	CGraphics m_graphics;	CSound m_sound;	CNetwork m_network;...	// Game vars}; CGame::Run(){	Init(); 	while(gameIsRunning) // GetMessage/PeekMessage	{		MainLoop();	} 	Shutdown();}CGame::MainLoop(){	switch(gameState)	{		...		case SOME_STATE:		{			m_network.ReceiveDataFromClients();			GetInput();			ProcessInput();			m_graphics.DrawSomeStuff();			m_sound.PlaySomeSounds();			m_network.SendDataToClients(); 			break;		}	}}

So in a way, my CGame class is basically a God class, except it does more than just combine all of the other classes and interacts with them - it does plenty of its own work, i.e. non-engine specific game stuff.