Jump to content
  • Advertisement
Sign in to follow this  
Perma-noob

Unity [java] event listeners, etc.

This topic is 4116 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

hey. I've been working on the program described here: http://www.gamedev.net/community/forums/topic.asp?topic_id=453645 (don't worry about reading it, it's just background info). I've reworked my code to implement event models, but I want to make sure I'm on the right track before I code too much further. I've scanned through alot of java tutorials (including the big one at Sun) and I can't find any mention of events (other than those directly tied to Swing). For example, I'm using custom events like TradeRouteEvent, etc. Now, I have interfaces for each type of listener (which also includes the 'firing mechanism' methods that send the event object to the listener)... each object that fires an event holds an array of listeners (typed as whatever 'listener' the object implements), which it cycles through. an example: (this is not directly pulled from my code, so it may have typos or whatever) <code> void fireEntityCreated() { for(int i = 0; i < noOfListeners; i++) { listenerArray.EntityCreatedListener(new EntityEvent(blah) ) ; } } </code> the problem I see with this approach is first, there will be ALOT of for-loops. (one for every possible type of event) also, there will be a lot of arrays (possibly with over-ridden types, knowing my program hierarchy), which I'm afraid will be very inefficient when taking into account how many events will be 'fired' during gameplay. I'm currently researching other containers (which is slow-going work), but I'm in the dark with regards to events, listeners, observer models, etc. am I on the right track? any tips or insults? lemme know, thanks

Share this post


Link to post
Share on other sites
Advertisement
From my experience, this is pretty much the norm. You might be able to do a Generic-based event delivery system, but that can be kinda difficult to design properly.
I would stick with what you have, as cumbersome as it seems. It's very straightforward and easy to maintain.
Another suggestion (which seems obvious, but is often overlooked) is to do very little in your event listeners as possible. Spawn off the work on another thread or something. You don't want to tie up your event delivery thread, otherwise things might become unresponsive.

Share this post


Link to post
Share on other sites
You're basically on the right track. The for-loops are not a big deal if you consider the alternative - each object looping over every event messsage generated this frame. I would recommend using ArrayList instead of plain old arrays since the number of listeners can be dynamic. You can also create event objects if you need to inform about the source - Java is generally considered to be very good at allocating and deallocating very small short-lived objects, so I would not worry about it until you know it to be a bottleneck.


ArrayList<TradeListener> tradeListeners = new ArrayList<TradeListener>();
...
TradeEvent e = new TradeEvent(this, 50, 100, whatever);
for( TradeListener l : tradeListeners ) {
l.tradeHappened(e);
}







Edit: If the event is not consumable and not modifiable (it should not be modifiable in my opinion), there is no reason to create a separate event for each listener, as you are doing right now.

Edit 2: Also, I do not agree with Antheus' suggestion about cross-manager access in the original thread you are reffing to. In my humble opinion, it's just a disguised global variable but with additional casts. It allows for such awkward situations as, say, your renderer getting a handle on your input system and calling its update loop. So with all that typing, while you do get somewhat loose coupling, you are still allowing access to every system from every other system, which spells disaster as far as trying to understand the architecture or track down bugs is concerned. This is not the case if your design requires you to pass around the various handles. You'd still want to centralize all the systems in the class that executes your game loop, but only pass down the systems that each component needs to do their work.

[Edited by - lightbringer on July 17, 2007 10:06:41 AM]

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!