Game Layout

Quote:

Just a general question really, I am considering building an engine to later create a game.

Oh?

Quote:

My question is within a game which uses an event handler, what sort of events are usually sent.

That depends. This kind of question is indicative of the problems described in the article I linked above -- you have developed an attachment to the idea of having an 'event' system, because you think it will be useful to your engine. However, you lack the requisite experience making games and understanding the various options in which a game can employ some kind of a event system, and as such you've no real idea how to implement it into an engine.

Events of some fashion can be used to route low-level functionality, such as input and rendering messages ("player pressed X"), or the can be used to route mid-level functionality, such as messages and information between game components ("I have set my position to X,Y,Z"), or they can be used to route high-level functionality, such as pure game logic and state data ("bad guy entered my view volume").

So what do you want to use events for? And what kind of events do you want to use? I generally use the OS messages directly for input, capturing them in my Windows message handler (whatever the equivalent is in whatever language I'm using), and using them to modify state in my input dispatcher -- such as modifying my understanding of what keys are currently down. I also fire off callbacks into the game code to notify the game that keys were pressed. These can be viewed as "events," but typically aren't because they are extremely specific and rigid.

However, I use a more generalized event dispatch system to allow my mid-level game components to communicate notifications. Your post seems mostly concerned with handling input, though, so I'll go into more detail there. What I have is essentially:

struct InputDispatcher {  typedef void (*KeyEventCallback)(Key key);    void RegisterKeyDownHandler( KeyEventCallback callback ) {    keyDownCallbacks.push_back( callback );  }  void RaiseKeyDown( Key key ) {    for( std::size_t callback = 0; callback < keyDownCallbacks.size(); ++callback) {      keyDownCallbacks[callback]( key );    }  }private:  std::vector< KeyEventCallback > keyDownCallbacks;};

This is, of course, simplified (and translated from C# to the roughly-equivalent C++). But this illustrates the key concepts. There is a callback function list, one for each type of 'event' I can raise. Here I show only key-down callbacks, but there of course are callbacks for key-up and such as well.

The game code has an instance of the InputDispatcher which is created for it by the basic initialization process (which is also responsible for setting up the window and message pump, et cetera -- this is necessary because the message pump function, the WndProc, will be interacting directly with the input dispatcher. When a Windows message comes in telling me a key was pressed, I figure out which key it was and I call inputDispatcher->RaiseKeyDown( theKey ), which then loops through its callbacks and fires them to tell the game that a key was pressed. I could also modify the current state (which keys are up/down) inside RaiseKeyDown and RaiseKeyUp as well.

This is an extremely simple system, but can be made to work with windows messages and DirectInput equivalently, and there is really little need for anything more complex as far as input goes.

Quote:

I am just curious because the passing input via an event handler seems to be the easiest way to do it but when you have a lot of classes within the event dispatcher requiring knowledge of input at that time it seems like a burden on the processor.

You shouldn't be handling input directly in a lot of different classes, you should try and minimize that dependency. You should capture input from the OS in one spot, translate that to game-specific information -- for example, space means "jump" -- and then tell whatever other system is appropriate that the player has jumped -- not that a key was pressed. For example, if your game is purely physics-driven, you wouldn't want the physics engine handling the 'space' key. Instead, you'd want the central game loop to gather input, check for the space key, and if so, tell the physics engine to apply an appropriate impulse to the player's rigid body.

The top-level 'game' object, or game loop, is the most game-specific bit of code you will write, and it is thus suitable for all these sorts of inter-subsystem translations to occur there.