Hi, I'm basically re-implementing an old (and unfinished) Quake BSP renderer that I implemented in C++ a while ago. This implementation didn't use objects or inheritance and I have since discovered the joys of Object Oriented Programming and would like to re-write and extend my engine using this methodology. My problem is deciding on a object structure for the engine. I have already decided how to structure various sub-sections of the project it's just the task of tying it all together which is confusing me. I have defined the following classes: CConsole CCamera CInputSys CEntity <---- CPlayer Now here is what I'd like to achieve: Do you remember the Quake Console ? Well if you don't I'll refresh your memory. The Quake Console could be used to change various critical values within the game like the player's field of view and so on. Now this I have already implemented but what I'm interested in is the way that Quake controled motion. One could type "+back" and the player would start moving backwards. Type in "-back" and In my first implementation I bound the keys to their console commands and then upon being pressed they simply found their binding and executed it within the console. This would as previously described, flick a corresponding boolean and then whichever value the kepress is related to would be incremented during the animation (pre-rendering) loop. Obviously upon a keyup event (or whatever it's called depending on API - I haven't decided yet SDL/WIN32/DXInput) the boolean would be flicked off again. My problem is making an OOP system using the classes defined above. I'm not sure where this functionality should be placed. And hang on, there's more... There must also be some kind of abstraction between the viewpoint and the camera. I'd like the player to be able to see through the "eyes" of all "entities" within the system and to be able to switch the viewpoint between them. This again raises the question of where the motion code should go - in the CEntity, CConsole or CInputSys ? Maybe some form of abstraction class needs to be defined. I turned this over and over in my head and haven't been able to think of an OOP approach that makes sense both in terms of OOP and in terms of the engine itself. But then again I'm fairly new to OOP. If you could provide a breif outline (in terms of objects and the way they work together-not code don't worry about code i can do that) of how you think such a system should be structured I would be very gratefull. Thanks in advance Tony. tony@transCendenZ.co.uk Edited by - TonyFish on January 23, 2002 9:13:17 AM

What do you want your key bindings do ?
When you look "through" the eyes of someone else, do you want to have some control of this new viewpoint (eg look up or down) or do you still want to move your player (even though you won''t see where he''ll move) ?

Yeah that wasn''t the best choice of words.
Basically I''d like to be able to switch between players/avatars/whatever (all derived from CEntity). How the actual switching occurs doesn''t matter. It''s how the whole structure should fit together which is bugging me.

I think you need a class which manages the "actions".

An "action" represents anything you can do from an input : move the player, shoot, switch the cameras, show/hide the console, quit the game, etc.

The "action manager", let''s call it CActionManager, is responsible for looking at what input gives, and he decides what action has to be performed.

This CActionManager "uses" (OOP term) the input (CInputSys) and the controllable objects (mainly cameras and players). The CActionManager is aware of what the user controls : he know if you''re in the body of a character, if you look through the eyes of someone/something else, if the game is paused, etc.

When this manager receives an event from an input, he checks the state of the game :
- if it''s paused, you can do nothing but remove the pause,
- if you''re looking through someone''s eyes, you can''t move the body, but perhaps you can look up/down,
- if you''re controlling your player (eg you look into _your_ eyes), you can run/jump/shoot/whatever,
- in any case, you can quit the game,
- ...

For example, if the key "up" is pressed AND you''re controlling your character AND the game is not paused, then CActionManager has to call CPlayer''s moveForward() method.

What do you think of it ?

Hey,

Yup I''d thought about an interlocking "Manager" system as well. Would you mind giving a simple explanation of the "uses" concept ? I''m not familiar with it. I''d look online myself but I''m on a *very* slow machine at the moment and only with one window open the hard disk sounds more like a violent Aphex Twin track then any hardware I know of ! (VMem thrashing I''ll be bound)

Thanks

When a class C1 "uses" another class C2, it means that C1 knows the existence C2 and can act on it (and sometimes "interact" with it).
One way of implementing it is giving your class C1 a reference (a pointer, in C++) to your instance of C2.

class C2{public: C2() {} void print_hello() { printf("hello world\n"); }};class C1{private: C2 *object_in_use;public: C1(C2 *object_to_use) { object_in_use = object_to_use; } void use_method_from_client_object() { if (object_in_use!=NULL) object_in_use->print_hello(); }};int main(){ C2 my_C2; C1 my_C1(&my_C2); my_C1.use_method_from_client_object(); return 0;}

In that sample source, C1 uses an instance of C2 to do something (display some text in this case).

In your program, C1 could be CActionManager, and C2 could be used objects like CPlayer or CInputSys. But you need to use more than one object. Just do something like :

class CActionManager{private: CInputSys *keyboard_input; CPlayer *current_player;public: CActionManager(CInputSys *input, CPlayer *player) { keyboard_input = input; current_player = player; }...};