For a good event example checkout the mechazoid folder from casey duncan's public repo:
http://code.google.com/p/caseman/ Always a good place to steal snippits of code ;) The example does network play as well as a bunch of other things. On Mon, Mar 09, 2009 at 10:52:28AM -0700, hotdog003 wrote: > > Hello, pygleteers! I am a newb at pyglet but have been using pygame > for quite some time. Now that I realize pygame can give only 2-3 FPS > and PyOpenGL is lacking when it comes to distribution, I now turn my > sights to this humble framework as the savior of my project. > > Pyglet seems to have some *really* epic ideas. I like what you've done > in every part, but there is one thing that confuses me to no end: The > event system. Perhaps I just don't understand it. Maybe my definition > of a nice event system is different from yours. There must be some > simple, elegant truth that I just don't *get*. Either way, this part > of pyglet drives me bonkers. > > Here's how I've always done it: According to the pygame programming > tutorial ( http://ezide.com/games/writing-games.html ), it's always a > good idea to split your game into separate parts: The "view" that > shows all the bits of the game to the screen (or sends them across the > network or draws the minimap or whatever really), the "model" that > keeps track of where everything is (the map, the objects within, etc), > and the "controller" that sends events down the system to listeners in > the model. For example, a keyboard controller would send a 'KeyPress' > event. When the player object hears that, it would update its position > and send a 'JumpEvent' which is caught by both the networking code and > the player sprite which would change its animation, etc.) It's very > light and very nice. If you can understand it, it fits together well. > > What my code does is have a single EventManager that every object > knows about. When the object wants to be notified of a certain event, > it registers that type of event with the event manager, which will > tell that object whenever an event happens For example, a network > object can do eventmanager.register('JumpEvent', > self.send_player_state) and the event manager would call that > networking object's send_player_state function whenever the player > jumped. > > The idea behind this is you can take away any part you want and the > game would still work properly. With my current code, I can take out > all the views without touching any other code and my game would work > just as well as if I didn't. Or, I can take away the view and the > keyboard controller and I'd be left with a still-working server that > keeps track of what's happening and sends everything in the model to > the clients. Or, I could re-use the model but change the view to GTK > and write a map editor. Easy sneezy. > > The problem is that Pyglet's notion of events really doesn't lend > itself very well to this kind of thinking. From what I understand, > each object (subclass of EventDispatcher) can send events to > listeners, but the listener must know the exact object that will be > sending the event (eg. self.dispatcher.push_handlers(self) ). There's > no easy way to 'multiplex' events (eg. have the player object send a > message to both the network code (self.networking.push_handlers(self)) > and to the player's sprite (self.player_renderer.push_handlers(self))) > without interlocking the player (model), the networking code (could be > considered a view), the minimap (a view), the player's sprite (another > view), and everything else that will need to know about what happens > to the player all into one tangled mess. HEEELLLPPP! > > How do YOU guys do it? None of the examples I've seen use this kind of > design, but surely I must not be the only one who thinks the way I do. > Should I keep my own EventManager code and use pyglet's event handlers > just to catch keypresses? Seems lame to have that much overhead. > Should I change my thinking entirely because it's a dumb idea? Seems > lame too, but I'm pretty new to game design, so I don't know what the > "do"s and the "don't"s are. Is there a way to shoehorn pyglet's event > system into something like this? I sorely hope I misunderstand how > pyglet's events work. > > How *should* it be done? > > > -- Harry Tormey P2P Research http://p2presearch.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 -~----------~----~----~----~------~----~------~--~---
