13 May, 2010, Chris Bailey wrote in the 1st comment:
Votes: 0
So it seems that using the observable module in Ruby might offer some benefits in streamlining my design. I am, however, having a difficult time deciding what needs to subscribe to what. I've been trying to look at the functionality that I want to figure this out, so let's use an example.

A few facts:

A sword is on the ground at a specific location.
The weather at this location is variable.
People come and go freely from this location.
The sword is intelligent and aware of its surroundings.
The people are aware of items in their location.

What I think:

A location must subscribe to all items it contains, so that it is aware of changes that could have an effect on it.

An item must subscribe to the location it is at so that it will be notified of things like the weather (maybe it needs to rust?), and also because the item might be intelligent and notice people entering, etc..

A pc/npc must subscribe to the location it is in for the same reason an item must.

It seems that the best course of action would be to make all objects subscribe to any object they knowingly contain, and have all objects subscribe to their container. Would this approach have a large amount of overhead in a populated gameworld? It seems a bit extreme to have so many two way communication channels….lots of listening and notification. Anyone have a better idea? =(

EDIT: Fixed some stupid punctuation.
13 May, 2010, Idealiad wrote in the 2nd comment:
Votes: 0
Yeah, this sounds a little overboard. Using that module, can each object subscribe to an event type instead? Then objects send events to a central publisher, which distributes it to the observers.
13 May, 2010, Chris Bailey wrote in the 3rd comment:
Votes: 0
See that makes a lot more sense, it didn't feel right the other way. Thanks Idealiad, I'll toy around with that a bit.
13 May, 2010, Runter wrote in the 4th comment:
Votes: 0
You should have the minimum amount of communication that allows magic to happen. That magic being your need for integrating your system so that each part is aware of the whole. If that need is low you may not need the observer pattern at all.
13 May, 2010, David Haley wrote in the 5th comment:
Votes: 0
Event types on their own don't fully solve the problem, they just move it. If an object cares about the "person entered" event, it subscribes to the central publisher on that type. Now every time somebody enters a room, the event is generated and the object receives it, just to find that the person is way over somewhere else. You need some kind of scope here. You could have a central publisher per room, per cluster of rooms, per area, per whatever other unit makes sense; just remember that things get interesting if you need to cross scopes. (Perhaps an object here cares about people entering over there (it's a radar!).)

Another very simple optimization is to only subscribe to event types that you actually care about. If you have no handler, don't even bother subscribing.
14 May, 2010, Idealiad wrote in the 6th comment:
Votes: 0
David Haley said:
Another very simple optimization is to only subscribe to event types that you actually care about. If you have no handler, don't even bother subscribing.


Could you explain this more, I'm curious about when an object would subscribe to an event type it didn't care about?

While I agree that scope can be important I would want to make sure that the code isn't designed with a built-in handicap with respect to event subscription. I wonder how scope could be made a parameter of subscription, such that it would be flexible based on the observer's needs?
14 May, 2010, Chris Bailey wrote in the 7th comment:
Votes: 0
Idealiad said:
David Haley said:
Another very simple optimization is to only subscribe to event types that you actually care about. If you have no handler, don't even bother subscribing.


Could you explain this more, I'm curious about when an object would subscribe to an event type it didn't care about?

While I agree that scope can be important I would want to make sure that the code isn't designed with a built-in handicap with respect to event subscription. I wonder how scope could be made a parameter of subscription, such that it would be flexible based on the observer's needs?


I'm also a bit curious about subscribing to something you don't care about, not sure what you mean?

Adding in some level of scope parameter seems like a great idea, I can see how it could vary greatly with different functionality. If I'm understanding correctly, you might be aware of certain events only at your current location…but an ability broadening your senses could allow you to be aware of events at various nearby locations. Or perhaps long term scrying on a locale, and being aware of what goes on as it happens. Am I understanding your meaning correctly here?
14 May, 2010, David Haley wrote in the 8th comment:
Votes: 0
Well, a naive implementation, or one that is not sensitive to performance (that is actually quite reasonable for small worlds) will have mobs subscribe to all mob-related events; objects subscribe to all object-related events; and so forth. Before you laugh and say this is silly and nobody would ever actually do this, this is basically what SMAUG does with its mudprog triggers. In other words, it doesn't bother to keep explicit lists of who is interested in what; it just broadcasts the event type to all people in the relevant scope (e.g., all mobs in the room receive the "somebody entered" message).

Of course, SMAUG doesn't have a whole system set up to keep track of subscriptions. If you're going to go to the trouble of tracking subscriptions explicitly, you've already gone a step further than the most basic event model, in that you don't subscribe if you don't care about events. From there, it is relatively straightforward to add subscriptions only to certain types. And finally, it is also straightforward to subscribe to only those types you actually handle (as opposed to those types being potentially relevant to you).

It's worth noting that a lot of this only matters if you have a lot of event passing going around. IIRC, CoffeeMUD is extremely heavy in its message passing and still performs suitably for most people's purposes.

Idealiad said:
While I agree that scope can be important I would want to make sure that the code isn't designed with a built-in handicap with respect to event subscription. I wonder how scope could be made a parameter of subscription, such that it would be flexible based on the observer's needs?

Just as in programming, you can have nested scopes. You can subscribe to a local scope (a room), its container scope (an area), the container's container (the world), the world's container (the whole game). Or whatever – the point being that events can be propagated up this scope list as appropriate. You would choose the scope hierarchy to optimize the common case, and things that need weird subscriptions (like events from multiple areas) just subscribe higher up in the hierarchy. In other words, the scope isn't at all a handicap, it's an optimization. Because, if you have set things up correctly, relatively few people listen to higher levels of the hierarchy, it's safe to push events up the scope chain because it's very cheap to pass them through the small amount of listeners.

Chris, yes, that sounds about right: if you only care about things in your locale, you subscribe only to that locale's scope. If you care about things in multiple locales, you can subscribe to all those locales.
11 Jun, 2010, ProjectMoon wrote in the 9th comment:
Votes: 0
This thread was actually helpful for my own project. After several iterations of event handling ideas, I think this pattern might be the best way to go. Currently I have it set up so that objects can only subscribe to events about themselves, but after considering the radar example, I may set it up so that objects can subscribe to events of other objects as well.
11 Jun, 2010, Noplex wrote in the 10th comment:
Votes: 0
Have you picked up the Gang of Four Design Patterns book? It goes through a very good implementation of this (and many other) common patterns.
11 Jun, 2010, Chris Bailey wrote in the 11th comment:
Votes: 0
I think I might pick that book up. I have a general understanding of several different patterns but I hadn't really tried to implement them.
11 Jun, 2010, Runter wrote in the 12th comment:
Votes: 0
I own the book. There's plenty of interesting patterns (or slightly differing patterns) that aren't covered there. In the last few years there's been an explosion of free resources on the net covering programming patterns. In my own experience I've found the best way to really understand these patterns and their best applications is to really use them for something rather than just read about them.

Incidental, here's a good little read for someone starting off that doesn't quite know what all is a well documented pattern.
http://en.wikipedia.org/wiki/Design_patt...
11 Jun, 2010, Tyche wrote in the 13th comment:
Votes: 0
Chris Bailey said:
I think I might pick that book up. I have a general understanding of several different patterns but I hadn't really tried to implement them.


The original WikiWiki has a great deal of information on patterns.
12 Jun, 2010, Chris Bailey wrote in the 14th comment:
Votes: 0
Thanks Tyche! I've been looking through that link and I'm finding a lot of useful information. =)
25 Jun, 2010, Noplex wrote in the 15th comment:
Votes: 0
Runter said:
I own the book. There's plenty of interesting patterns (or slightly differing patterns) that aren't covered there. In the last few years there's been an explosion of free resources on the net covering programming patterns. In my own experience I've found the best way to really understand these patterns and their best applications is to really use them for something rather than just read about them.

There are very few books that I suggest career software engineers own, that is one of them, while I agree you can scour the Internet for free resources this book lays out some concrete design patterns that you'll see the most often. The book is quite dated for software engineering texts so I would not expect it to have the latest greatest software patterns in there, but for the most part most patterns derive from these base ones (or specific purpose patterns, and these are the general case). The exception is the concurrency patterns. The last time I glanced at the book it had none. From what I hear they are planning another edition soon which will include concurrency.

Nevertheless, I would suggest grabbing a copy of the PDF (http://www.mcdonaldland.info/2007/11/28/...) which is quite great as a quick reference. The Wikipedia matrix is also good. But I think implementing patterns is the best way to learn, so fire up Emacs and start coding some examples. From my experience patterns that you'll see the most in real life are Singleton, Observer (used to implement MVC), Iterator, Builder/Factory and Visitor.

Also, if you're a C++ programmer the Scott Meyers books are essential reads.

As for event handling I have been fond of double dispatch lately, especially with C++. There's a good read with some examples on Wikipedia. Good luck, unfortunately I do not have enough time to study software patterns as they are probably the only thing that would draw me into a doctoral program. They're really brilliant.
0.0/15