Program structure

[pauly]

I've been fooling around with the tutorials for a while now. I've noticed that the structure used in the tutorials really isn't the way you should program at all.
For example there apparently should be a class called game which holds all the data and functions in the game. This class should be objectified and afterwards updated or run if you will like so:

Code: Select all

int main()
{
	CGame game;

	game.run();

	return 0;
}

I actually got it to work

For different parts of a game or program there should be classes like CIntro, CMainMenu, CTheActualGame. These contain functions that handle objects from classes that are needed in these parts of the program.

My questions are:

Is there a better way of structuring all this?

Can the game.run(); be split into more loops or must all updates be done in the run function of CGame.

Is it possible to create multiple eventreceivers for these different parts of the game. So that the eventreceiver is more or less broken up.

[Saturn]

Having a Game class instance as top level object and owner of everything in the second level is obviously a good idea. Letting it hold "all data and functions in the game" is a not so good idea.
The description of your design is way too coarse to give sensible advice.
So if you want specific advice ask specific questions, present specific problems or explain more of your design.
Your question is like showing a silhouette of a car and ask us how to improve its engine and transmission.

CGame::run splitting into more loops? What loops exactly? What for?
Having multiple EventReceivers doesn't have to be a good idea. Usually I prefer to handle input hierarchically. Have one object get input and decide whether to handle it itself or whether to delegate it elsewhere. E.g. have an InputManager that handles all the global stuff itself and delegates everything else to the current game state input handler, which is maybe from a different class in case of being in the main menu or steering a character through a level. When you have multiple independent event receivers, you have to notify them all of this state change, since inside the game menu you only want to let the user choose among the options not accidently moving the character around when switching through the menu items with up/down, just as an example. Having a single central place that decides what to do or where to delegate is easiest to manage.

Nitpick: Prefixing class names with C is soooo 80-ish. You'd be surprised how much better to read class names are without this C and how much more sense an alphabetic index in Doxygen makes...
When you prefix interfaces with I there is no need for the C for classes anyway. What else are they other than classes/structs? You probably know the basic C++ types already, so C prefix doesn't add useful information anyway, it just makes the names awkward to read.

[pauly]

Well for noobs it's not really obvious that

Having a Game class instance as top level object and owner of everything in the second level is obviously a good idea.

Because not all people who start irrlicht have actual programming experience in c++ or any other object oriented programming language. The tutorials themselves are not structured that way and the tutorials are that which most noobs look at first. I know that there probably are loads of tutorials for c++ which explain programming structure but it just might be a good idea to make a tutorial that presents a good way to structure a game. Anyway thanks for the reply, just needed some confirmation that i was on the right track.

CGame::run is for example

Code: Select all

while(device->run())
		{

			driver->beginScene(true, true, SColor(255,0,0,0));

			smgr->drawAll();
			guienv->drawAll();

			driver->endScene();
		}

		device->drop();

I didn't really knew if there can be more of these functions running. I asked my brother and he explained a bit and answered most of my questions.

I 'm planning to write a tutorial explaining programming structure when I got it figured out thoroughly. Would you guy's care to comment when I have got a coarse version of the tutorial?

[Sean H.]

understanding code, and creating a complete game framework are two separate things. the latter takes alot of planning and experience.