Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (757)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (844)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  how to represent event data in event-driven communication?  (Read 1531 times)
0 Members and 1 Guest are viewing this topic.
Offline tacticalPotato37

Senior Newbie

« Posted 2012-07-26 22:42:41 »

I'm trying to create a central event dispatching system using kind of an Observer pattern for my small RPG project, and I need advice on how best to represent event data.

I'll have an EventManager that registers listener classes for different event types defined in a static enum such as Event_Input_KeyPressed or Event_Game_ActorMoved. It will store events in a queue and dispatch them to the corresponding listeners, which will each have a method handleEvent(Event e) or something.

Each event will be an object of type Event, which holds data such as its event type.

My question is, since the nature of the event data differs considerably between event types, how should this data be represented? I'm not yet sure exactly what types of events I will want to create in the future, so I want this to be as flexible as possible. For example, an event could trigger other events if certain conditions are true (ie. when the player pressed the action key, a door opens if the player is in a certain location and has a key). Is XML or scripts a good choice? Another way I can think of is to create a custom class for every general event, like ActorEvent or MenuEvent, but that seems really inefficient and inflexible. Also, since some objects such as Character only need to know very specific events like when the "w" key is pressed, I figure they don't need to be notified when other keys like "h" are pressed. Is it viable to create event types that specific or is there a better way? ie. Event_Input_KeyPressed_W

Thanks  Smiley
Offline UprightPath
« Reply #1 - Posted 2012-07-26 22:50:47 »

Not sure I can give you some far reaching advise about this, however I can at least give two cents worth.

Separate your UI from your Logic. Your game's logic should not have any idea what a 'W' key is. Some other mechanism should be in charge of accepting your keyboard/mouse/orangutan-plug-and-play-event and then generating an event based off of that, which it puts on the logic event queue. The primary reason for this... Well, not everyone (Here especially) uses a qwerty keyboard so what seem like perfectly good ideas on that keyboard arrangement are utter rubbish to them (Like using Z, X, C for three button controls. Makes sense on a Qwerty, but...). This also means that you can cut down on the events that your system needs to know how to process (If you have three different ways to move your character-- WASD, Arrows, Num-Pad-- your logic shouldn't know that and they should all be treated as the same by your game.)

Beyond that: Build with extension in mind, but don't let making it extensible prevent you from getting it done. Figure out your base events and attempt to get a system that works off those, then try to get one that'll respond to others.

Offline actual

JGO Coder

Medals: 25

« Reply #2 - Posted 2012-07-26 23:26:24 »

I use the one class per message approach and I have not found it to be a problem. Each class is small, only containing data specific to that packet. You have access to the source code and re-compiling isn't a big deal, usually when you are adding new messages, you are doing other things anyhow.

While you could have a EventKeyWPressedMessage, it would be better to have a layer in between your input and the game entities reacting. So you have some input manager that listens for key presses. If the user presses "w", it fires off a MoveLeftMessage or MoveMessage with direction as a parameter.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline tacticalPotato37

Senior Newbie

« Reply #3 - Posted 2012-07-27 01:18:02 »

Thanks for the input guys.
I think I'll just go with one class per event first until any problems come up. The only concerns I have with this are clutter and that there isn't really any way to give events certain conditions or other effects, but I guess that stuff can easily be dealt with wherever the events are created and received.

You're right about separating UI from logic, that's actually why I'm making an event management system, so thanks for saving me from being stupid haha.
Pages: [1]
  ignore  |  Print  

EgonOlsen (45 views)
2018-06-10 19:43:48

EgonOlsen (25 views)
2018-06-10 19:43:44

EgonOlsen (47 views)
2018-06-10 19:43:20

DesertCoockie (202 views)
2018-05-13 18:23:11

nelsongames (127 views)
2018-04-24 18:15:36

nelsongames (126 views)
2018-04-24 18:14:32

ivj94 (867 views)
2018-03-24 14:47:39

ivj94 (128 views)
2018-03-24 14:46:31

ivj94 (771 views)
2018-03-24 14:43:53

Solater (143 views)
2018-03-17 05:04:08
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!