Diary: Notifications

Introduce your project and write about your work.

Moderator: PPS-Leaders

Post Reply
User avatar
Mozork
Mogthorgar, the mighty
Posts: 134
Joined: Wed Sep 24, 2008 3:27 pm

Diary: Notifications

Post by Mozork » Wed May 11, 2011 9:05 am

I've been working for quite some while now on notifications and lately have begun to convert some of the overlays that display useful information to the new notification framework.
In the process of doing that I started to reconsider the viability of one design decision in particular I made along the way. When talking to Felix about it, he suggested I should post my problem here, to get a more varied response and, hopefully, some helpful suggestions or comments.

But first, let's talk about why we notifications in the first place and how they're implemented so far.

The basic goal behind the notifications module is to provide an easy to use, coherent framework to both send and display notifications, notifications being short messages informing the user about something you think he should know.

The reasons why I felt the need for such a system are manifold, mainly I didn't want to deal with overlays every time I wanted to display some informative text. I also wanted to give the UI designer more control about what is displayed how, when and where, and ultimately prevent a chaotic situation, where, in order to display some text I would have to know about any overlay that currently exists, just to be sure it doesn't interfere with what I want to do.

As for the implementation, I decided to separate the displaying of the notifications from the process of sending and storing them.
Sending a notification can be done trough a static function of the NotificationListener. The notification is then registered with every NotificationListener and the NotificationListener also takes care of all the network stuff, e.g. if the server wants to send a notification to just one client.
Then there is the pivotal entity in the whole notification framework, the NotificationManager. It is in fact the only NotificationListener (so far) and it's responsibilities are the storage of the notifications (ordered by their time of arrival) and their redistribution to the entities that display them. Later this could also be used to display some kind of notification history.
The entities that display the notifications are called NotificationQueues and they have all the notifications they currently display (or plan to display in the future but haven't gotten around to displaying them), they have parameters such as the maximum number of notifications they display at a given time or how long a notification is displayed at the most. They also talk to CEGUI to do the actual displaying. (The framework could be extended without much effort to have a special type of NotificationQueue that displays its notifications using overlays instead of CEGUI, but I think CEGUI is much more suited to do this.)
In CEGUI the notifications (or rather the NotificationQueues, that then display the notifications) are displayed in a sheet called NotificationLayer, that can be shown or hidden to show or hide all notifications.

There is some more fancy stuff, such as commands that affect the NotificationQueue in ways other than displaying notifications (e.g. clearing them), or NotificationDispatchers, that allow to display (customized) notifications as a result of something happening in a level (e.g. a Trigger triggering) and also some stuff in the works, e.g. different types of notifications (info, important, ...) that the NotificationQueue can decide to display differently.

Now to the problem: So far whenever a notification is sent, a sender (which is just an arbitrary string, that should identify the part of orxonox the notification is coming from, e.g. if a notification comes from the questsystem the sender could be set to "questsystem") has to be specified and each NotificationQueue has a list of senders it accepts notifications from (or displays notifications of).
This may be counter-intuitive at first glance, because you may think of a NotificationQueue as a kind of Blackboard that you decide to put your notification on and where it is then displayed.
But that's currently not how it works. A proper analogy would be to think of a NotificationQueue as a mask that only lets you see notifications from parts of orxonox you defined.
There are various advantages to this strategy. First and foremost if we decide to change our NotificationQueues, e.g. we started with two, one displaying all quest-related notifications and another displaying all gametype-related notifications, but now we want to just have one queue displaying notifications for both of them, we run into problems, if we have the Blackboard approach. We would need to go through each instance we send a notification and change where we send it to. This gets very tedious very quickly (and you'll need to recompile a lot of code).
With the current approach we only need to change the senders that are accepted by the NotificationQueue, which in the future might bold down to just changing some parameters in an XML file.
Additionally the NotificationQueue could actually indicate where the notification came from, helping the user to more easily determine its relevance.

The question is, whether it would be more usable, and thus justify the loss in adaptability, if we would do the Blackboard approach.

Also I'm curious what other questions, comments and suggestions you have regarding the notifications.

User avatar
beni
Baron Vladimir Harkonnen
Posts: 949
Joined: Tue Oct 03, 2006 9:15 am
Location: Zurich
Contact:

Re: Diary: Notifications

Post by beni » Wed May 11, 2011 1:45 pm

I clearly prefer the sender-receiver solution. Even though there is more complexity, there is also more flexibility. Since the notifications seem to be a part of the game that may be affected a lot by modules that we maybe haven't even started to think about, flexibility is key IMHO.

In the end the complexity is not that much worse: In the blackboard approach I still need to know where I could write the stuff and what the name of the overlay/CEGUI element is. I would then need a pointer to that "receiver" and call it with my message. It would give me more control, but it also brings the issue of a lack of flexibility.

In the sender-receiver approach people don't need to care too much about displaying, if they want to send something. They can just add a category ("questsystem") and stop thinking about it. Somebody else will decide what to do with questsystem notifications and how to display them. He can also change the whole concept of the HUD and still doesn't have to look into the source code. And even if it's me who has to do both, matching strings is much easier than searching for the right pointers. Especially when I have to change it once in a while.

I think this all clearly speaks for the more complex sender-receiver approach.
"I'm Commander Shepard and this is my favorite forum on the internet."

User avatar
x3n
Baron Vladimir Harkonnen
Posts: 810
Joined: Mon Oct 30, 2006 5:40 pm
Contact:

Re: Diary: Notifications

Post by x3n » Sat May 14, 2011 11:43 am

Thanks for giving some insights into the notification system, so far I never found time and motivation to dig through it myself ;) As you may remember, I already considered merging the notification- and the event-system. After reading your post however I think that it's probably better to keep the notification-system separate - for text messages, with all the specific information like the "importance" of a message or the queueing of the output. Maybe in future we can still put the notification-system on top of the event-system, but that's not important right now.

So back to topic, let me try to understand the problem/question right:
You basically have senders which just spit out notifications. On the other hand, you have receivers which display notifications. And if I got this right, your question is whether the sender should define its notification targets (blackboard approach) or the receiver defines its notification sources (mask approach).

However I'm a bit confused by Beni's post which talks about a sender-receiver solution which, in my opinion, is neither blackboard nor mask, but rather a 1:1 connection, at least according to the term "sender-receiver". But it's probably just a misunderstanding.

Anyway, I see yet another solution which expands the data model a bit: instead of looking at a sender-receiver problem, we could also look at it as a sender-message-receiver problem. In this case you could disconnect senders and receivers. senders would just spit out notifications of certain types (e.g. quest notification, kill notification, gametype notification, etc) independent of the receivers. receivers would choose to display notifications of certain types, independent of the senders.

Basically this approach is similar to your "mask" approach, except that it uses a string to define the message instead of defining the sender. So in fact this solution is just another name for the same approach. However we see now that the sender is not of importance anymore. It boils down to a message-receiver problem. And now, at least in my opinion, it's clear that the message should not choose it's receivers, but rather the receivers choose the messages they're interested in.

So to come to a conclusion, I'm in clear favor of the "mask" approach, i.e. basically the HUD element decides which messages to display. The system shouldn't have to know which HUD elements exist in order to display a message. Or, in other words, the notification-system is good as it is now (assuming it uses the mask approach).
Fabian 'x3n' Landau, Orxonox developer

User avatar
Mozork
Mogthorgar, the mighty
Posts: 134
Joined: Wed Sep 24, 2008 3:27 pm

Re: Diary: Notifications

Post by Mozork » Sat May 14, 2011 12:42 pm

I like the idea to use the string to identify the message instead of the sender, it explains more clearly how I intend it to be used. So I'll adjust that in the code and documentation (which isn't up to date anyhow...).

I think putting the notification system on top of the event system would be prudent and easily accomplished.

User avatar
beni
Baron Vladimir Harkonnen
Posts: 949
Joined: Tue Oct 03, 2006 9:15 am
Location: Zurich
Contact:

Re: Diary: Notifications

Post by beni » Sat May 14, 2011 4:00 pm

Oh it seems I misunderstood something and thus used unclear wording of my proposal.

I agree completely with x3n's approach. In fact I believe I was advocating exactly this. The mask approach is the one to go, but the receiver shouldn't choose the sender, but the message (type).
"I'm Commander Shepard and this is my favorite forum on the internet."

Post Reply

Who is online

Users browsing this forum: No registered users and 12 guests