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? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
