On Mon, Mar 9, 2009 at 1:52 PM, hotdog003 <[email protected]> wrote: > > How *should* it be done? >
You have the general idea, but pyglet's paradigm works at least as well. By using a centralised event dispatcher (as you are currently), you typically seek to reduce coupling between systems (i.e. the receiver doesn't have to know who sent the event), but this rare accomplishes what one assumes it will. Lets take the example of a controller, which receives keyboard input: as far as the controller knows, the input is just input - it could be direct keyboard input, recorded input from a file, or some sort of AI. However, something has to connect the controller to the correct events at run time, and this is where you seem to be having issues. In your system, each object connects itself to the event dispatcher, specifying which event it wants to receive. Now this is actually a bad thing, because our controller just specified exactly which source of events it is using. If we instead connect events directly, we are free to connect the correct object (be it keyboard, recorded or AI). The big question remaining is who is in charge of connecting everybody up to each other, and the answer depends heavily on how your game is structured. In my case, the game initialisation code connects up the major sub-systems, and the level loading code connects up the interaction events for each level and character. -- Tristam MacDonald http://swiftcoder.wordpress.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en -~----------~----~----~----~------~----~------~--~---
