[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [pygame] UI Blues
Yeah I see your problem -
You want to clearly differentiate between 'hardware' events and 'Events' in general.
And the double-queue method IS probably the purest way, but its double-handling.
Hmmm...
Quoting Kris Schnee <kschnee@xxxxxxxxxx>:
> In revisiting my interface code, in light of what I've learned from the
> tactics-game project, I've hit a snag.
>
> Earlier, I'd set up my interface so that hitting a button or something
> would cause the button to call a "Notify" function of the main game
> object, sending it a dictionary describing what happened.
> {"headline":"click","sender":self} That meant having a special event
> queue in the game object, to be added to by Notify and read by a game
> loop. That is:
>
> -In Screen X, there's an interface. The user hits a button.
> -The button calls Notify.
> -The loop for Screen X sees that an "Button B was clicked" message has
> appeared, and reacts to that.
>
> That's the "poorly-formatted random data" situation I was trying to
> avoid, but I don't see how it _can_ be avoided. With the tactics game I
> was getting around it by having ad-hoc variables attached to the
> game-world object, rather than a generic message queue.
>
> Another approach to UI handling I've had suggested is to have a double
> event-handling system. The first part handles raw Pygame events and adds
> to a queue of _gameplay_ events, to which the UI can also add. The
> second part handles the gameplay events, like so:
>
> for event in pygame.event.get():
> if event.type == KEYDOWN and event.key == KEYS_JUMP:
> self.game_events.append("jump")
>
> for event in self.game_events:
> if event == "jump":
> self.player.Jump()
> elif event == "pause_button_clicked":
> self.Pause()
>
> Does this setup make any sense?
>
--------------------------------------------------------------------
Come and visit Web Prophets Website at http://www.webprophets.net.au