HTML5 desktop notifications on active network games?

[Omega]

Nowadays, at least with Firefox and Chromium/Chrome, there's another option (which others may adopt, yet): The HTML5 desktop notifications standard makes it technically feasible to have the play.mg website (i.e. the masterserver code) notify when a server becomes available (someone would yet need to implement this - patches welcome!), so it would only take a running web browser to know when new servers are available. However, this doesn't allow you to connect to a server on the click of a button, yet. This would take a bit more (mostly) platform specific client code. I actually started writing some quick and dirty server side code for this (which is already live), but the client side handlers are missing as of yet. Once done, such code could be added to the MegaGlest installers, though, so it would become universal.

I'm happy to discuss this in more detail if anyone is interested in spending time on this.

I might be interested in taking a look at this. Feel free to go on in more depth, including what the notification should say and how (when) it should be fired.

[tomreyn]

If any server is newly listed and matches all of the following criteria or changes state and thus matches all of the following criteria (i.e. state tracking is necessary, ideally on the client only), a notification should be triggered:

• # network players (connectedClients) must be greater than 0
• status is "waiting for players" (0). in the future, when (re)joining running games becomes possible, the following is also a match: status is "in progress" (2) && connectedClients < activeSlots
• if set, version filter must match requested version

The notification should say something like:

PRODUCT_NAME server "$serverTitle" ($status) has {$activeSlots - $connectedClients} free slots available. Click to join now.

Clicking it should point to the current URL with the following parameters appended (with the $parameters replaced by the servers details):

Code: [Select]

mgg_host=$ip&mgg_port=$externalServerPort... resulting in a URL such as:

Code: [Select]

http://play.mg/?version=v3.8.0-beta1&mgg_host=124.109.2.127&mgg_port=61357Care should be taken to ensure that there will be only a single mgg_host and single mgg_port parameter in the final URL.

So a user clicking on the displayed notification would then trigger the systems' default web browser to download of a plain text file of MIME type application/x-megaglest-gameserver and UTF-8 character set, which contains the servers IP address and external server port separated by a colon. (This part is already implemented.)

The web browser will need to know how to handle this file, passing it to some script which will read the downloaded file and run MegaGlest with the --connect option, passing the contents of said file as a value to this option. (This part is platform specific, not implemented, yet. On Linux / systems conforming with the freedesktop.org standards, it should probably interface with xdg-open and xdg-mime. Generally the goal should be to add instructions to the MegaGlest (un-/re-)installers to also install this platform specific code.)

[Omega]

Okay, here's what I'm thinking. I would use ajax to query the table data. Probably return an XML that can be easily parsed. The data would then be stored in an array (in client side JavaScript), keyed with the host IP and port number (which should be all we need to uniquely identify each game). The array would contain data like the version, techtree, etc.

Every time we run the ajax request (I'm thinking something like 30 seconds by default, but it could be configurable without much more work), the array will be compared. We'll issue an HTML 5 desktop alert to the user if either an existing game is changed (that is, a row with the same IP and port number have different data) or if a new IP and port number have been added.

Finally, once the old and new tables are compared, the new table replaces the old one. Rinse and repeat.

On a side note, the URL that is created contains the version number, but as far as I can tell, the version number is never used (the downloaded file only contains an IP and port address).

[tomreyn]

Okay, here's what I'm thinking. I would use ajax to query the table data. Probably return an XML that can be easily parsed. The data would then be stored in an array (in client side JavaScript), keyed with the host IP and port number (which should be all we need to uniquely identify each game). The array would contain data like the version, techtree, etc.

If you'd like to update the server list using AJAX, it might be easier to use the JSON interface there (which already exists, and can be adjusted as needed). There's also a CSV interface. But if XML seems easier (I would be surprised), surely that will work, too.

Every time we run the ajax request (I'm thinking something like 30 seconds by default, but it could be configurable without much more work), the array will be compared. We'll issue an HTML 5 desktop alert to the user if either an existing game is changed (that is, a row with the same IP and port number have different data) or if a new IP and port number have been added.

This would trigger a new notification whenever the server admin switches to a new map, tileset, or techtree (and an update on that is sent to the masterserver), so this may be a bit much. If you think that this should trigger a notification, I think it should be an option which defaults to off.

Finally, once the old and new tables are compared, the new table replaces the old one. Rinse and repeat.

On a side note, the URL that is created contains the version number, but as far as I can tell, the version number is never used (the downloaded file only contains an IP and port address).

I assume you're referring to the URL which is requested when a user is trying to connect to a server? That's probably correct, what there is so far is just an example implementation which can be improved upon. It may make sense to pass along the servers' version number to the client side application which will handle the downloaded file, so that it may display a warning if there is a version mismatch before it runs MegaGlest (but then MegaGlest would also display a warning if there is a version mismatch, so I guess this wouldn't be a huge improvement).

This said, I'd like to continue to have a server list which provides the current functionality (server list, version filtering, regular updates within configurable intervals by means of page reloads, connecting to a server by clicking no it on the list) without a requirement for javascript support. This can be at the same or a different location (URL), I don't care much about this. I guess it can make sense to make the ajaxified presentation the new default. Aside of that, you're welcome to rewrite the code and change the looks as much as you like, as long as it doesn't break the game and other clients like MGTray and MGViewer (I think they use the CSV interface only).

[Omega]

This would trigger a new notification whenever the server admin switches to a new map, tileset, or techtree (and an update on that is sent to the masterserver), so this may be a bit much. If you think that this should trigger a notification, I think it should be an option which defaults to off.

Hmm, perhaps I'll just limit it to new servers appearing. In retrospective, changes seem too often and not useful for players.

This said, I'd like to continue to have a server list which provides the current functionality (server list, version filtering, regular updates within configurable intervals by means of page reloads, connecting to a server by clicking no it on the list) without a requirement for javascript support. This can be at the same or a different location (URL), I don't care much about this. I guess it can make sense to make the ajaxified presentation the new default. Aside of that, you're welcome to rewrite the code and change the looks as much as you like, as long as it doesn't break the game and other clients like MGTray and MGViewer (I think they use the CSV interface only).

This shouldn't break anything. The server side modification is in a new file, which generates an XML based on the current database (and is based on how the table is created). The client side code will probably import a JavaScript file on the index.php file, which should be ignored entirely if JS is disabled.

[Omega]

Okay, I *think* it is all working as expected, although I tested on a local host, which may or may not impact the results, so we really need to test on the live site.

Here's the only changes made to existing files:

Code: (File showServers.php) [Select]

60a61,62
> echo ' <script src="scripts/json2.js"></script>' . PHP_EOL;
> echo ' <script src="scripts/desktopNotifications.js"></script>' . PHP_EOL;
As you can probably tell, it simply has the showServers file, which generates the table, load two JavaScript files. The first is a minified version of this, which allows for safe parsing of the JSON that the server creates.

The second file is here. It does all the work, downloading the JSON data, converting it into useable objects, and comparing it to last time it downloaded. If there was any changes, it throws a desktop notification.

On a side note, desktop notifications, at least for Chrome, stop appearing after so many have been generated (to prevent spam, presumably). This may impact the usability of them.

A collection of all needed files is here, which includes the image used in the notifications. The refresh time is currently hard coded at the top of desktopNotifications.js, and at 2000ms, it's too short for production use, but useful for testing. The final version should increase this to something like 10000 or 15000 ms or allow it to be specified (defaulting to one of those values). Before I add such a functionality, I need to be sure the feature works as intended.

[tomreyn]

Omega has since made a lot of progress on this feature. In the future this should allow anyone to be notified on their desktop when games are available and connect to a server just by a click on a notification or entry in the play.mg server list.

This already works for me locally now and here's how it looks (currently, looks and text are subject to change):

1. A future version of the http://play.mg website will have this new option (the checkbox will be disabled by default):



2. Once the box is ticked, you will get a browser prompt similar to this:



This is Chromium on Linux, the Firefox one actually looks a bit better.
Once this is live, the hostname will be different, namely play.mg, and if you only choose to always allow "play.mg" to notify then you'll only get this prompt once.

3. Once notifications are active, you will get to see Desktop notifications as soon as a new server which has spare slots becomes available:



The play.mg website which displays in the background here doesn't need to be in front for this to work. It has to be loaded on your web browser, but it doesn't need to be the active tab, and you can be working with something completely different (like checking your e-mails, editing some text or images etc.). Depending on your configuration you may even be able to close the web browser window and they will still work. So this is really a Desktop notification, not just a simple Javascript pop-up.

4. Now when you click on this notification, your web browser will download a very small text file which contains only the IP address and game port of the server which you are trying to connect to.

This is a plain text file with a single line, e.g.:

Code: [Select]

123.123.123.123:61357
This is how far things will go in the first stage. For now, your web browser does not know how to handle this downloaded file and will ask you what to do about it, or just download it.

In a second stage, your web browser and the operating system will know how to handle this file, passing it to a script (which someone will yet have to provide), which then automatically spawns MegaGlest and makes it connect there.

Altogether this means it will be possible to get notified when a server is available and someone is connected to it (and there are free slots), and by a click on the notification you'll connect to this server.

Does this sound good? It already works here :-) (but just for testing, and Linux-only).

[Omega]

Does this sound good? It already works here :-) (but just for testing, and Linux-only).

Should be possible to get it working in windows with very minor changes. First of all, we'd need a program to make some slight changes to the registry. It would have to add some information about the .mgg file, namely what opens it and how it should be opened. In HKEY_CLASSES_ROOT, we'd have to create a .mgg key. The default value of this key will be an identifier, say, megaglest_multiplayer_file. We could also add a key named Content Type inside this, which describes the MIME type, which should be application/x-megaglest-gameserver.

Now we need a new key (also under HKEY_CLASSES_ROOT), which has the name of the identifier (the purpose of this is to allow multiple programs to be able to open a single file type, but only one can be the default). So this means we have a key named megaglest_multiplayer_file (or whatever we named that identifier). The default key for this is the description (what Windows explorer will display about the file). To tell Windows how to open the file, we need a folder here named shell. Inside this should be another folder, say, Open. The default key of the shell folder should be the name of whatever folder is the default for opening this file (namely Open). It's like this so that file types can have multiple shell commands associated with them.

Anyway, inside this Open folder, the default shell should be the shell command to launch the program. That's the only problem I see. How do I tell MegaGlest to use this file? I'm not sure if there's already a shell command for opening it? If not, I don't believe the terrible Windows command line would be able to parse the file's CONTENTS, since Windows lacks a "backticks" feature. So in other words, we need a command like megaglest --open-multiplayer-file myFile.mgg (I didn't see anything like it in megaglest --help).

That means the changes should look something like:

Code: [Select]

REGEDIT4

; Tells windows that the .mgg extension is tied to the specified identifier.
; The "Content Type" key holds the MIME type
[HKEY_CLASSES_ROOT\.mgg]
@="megaglest_multiplayer_file"
"Content Type"="application/x-megaglest-gameserver"

; Default key of the identifier holds the description (for Windows Explorer)
[HKEY_CLASSES_ROOT\megaglest_multiplayer_file]
@="MegaGlest multiplayer file"

; Default key of the shell folder tells which folder to use for the default
; command
[HKEY_CLASSES_ROOT\megaglest_multiplayer_file\shell]
@="Open"

; The subfolder containing the command
[HKEY_CLASSES_ROOT\megaglest_multiplayer_file\shell\Open]

; Actual command is located in the "command" folder. Note that the command
; must work from anywhere, so we need the full path unless MegaGlest's
; executable is added to the system PATH. Thus, this should be generated
; by the installer program.
[HKEY_CLASSES_ROOT\megaglest_multiplayer_file\shell\Open\command]
@="C:\Program Files (x86)\MegaGlest\megaglest --load-multiplayer-file=%s"

Note that the path for the command must be absolute, so these changes are best applied by the installer. As mentioned, Windows would need a command to load that file directly (%s in the last line will be turned into the file name).

[tomreyn]

I guess this may work for Windows (untested):

Code: [Select]

@echo off

if [%1] == [] goto usage

rem FIXME: The installation path actually needs to be read from the registry
rem Alternatively make sure this file is located nex tot megaglest.exe and don't "cd"

cd %ProgramFiles%\MegaGlest
set /p hostport=< %1
megaglest.exe --connect=%hostport%
goto eof

:usage
echo Usage: %%0 <filename>
pause
goto eof

:eof
OS X would yet need to be done.

[tomreyn]

Roughly this might work generically for Linux (untested, some assumptions are made, needs to be improved):

Code: [Select]

#!/bin/bash
# Installs / uninstalls MegaGlest gameserver MIME-type handler
#
TMPFILE=`mktemp -t megaglest-gameserver-XXXXXXXX`
cat << EOF > $TMPFILE
           <?xml version="1.0"?>
           <mime-info xmlns='http://www.freedesktop.org/standards/shared-mime-info'>
             <mime-type type="application/x-megaglest-gameserver">
               <comment>MegaGlest gameserver location file</comment>
               <glob pattern="*.mgg"/>
             </mime-type>
           </mime-info>
EOF

if [[ $1 = 'install' ]]
then
  xdg-mime install --novendor $TMPFILE
  xdg-mime default MegaGlest.desktop x-megaglest-gameserver
  xdg-icon-resource install --context mimetypes --size 64 ~/megaglest/megaglest.xpm application-x-megaglest-gameserver
elif [[ $1 = 'uninstall' ]]
then
  xdg-icon-resource uninstall --context mimetypes --size 64 application-x-megaglest-gameserver
  xdg-mime uninstall --novendor $TMPFILE
else
  echo "Usage: `basename $0` <install|uninstall>" >&2
  exit 1
fi

rm $TMPFILE

Code: [Select]

#!/bin/bash
# MegaGlest gameserver location file handler
# Runs MegaGlest
#
if [[ "$1" = '' ]]
then
  echo "Usage: `basename $0` <filename>" >&2
  exit 1
fi

head -n1 $1 | xargs -I '{}' ~/megaglest/start_megaglest --connect='{}'

[Omega]

Yeah, I think it'd be a lot cleaner if the binary would have native support for this file. Can we make a feature request?

[tomreyn]

This can be a good approach, too, maybe better.

[jammyjamjamman]

Yeah, I think it'd be a lot cleaner if the binary would have native support for this file. Can we make a feature request?

If you were to do this I would also recommend making sure you had the right game loading for the right server (eg. if the server rev=x, start megaglest rev=x. If the server rev=y start megaglest rev=y. if there is no megaglest rev=y report error).

[nig]

love it!
is it possible to show the message a liitle longer? its hard to click the "join" link in that short time. A silly notify sound would be nice too.

Today I saw the "history" on http://play.mg the first time. nice idea too. Would be more useful if there were the starting time of each game visible. So you can have a guess when a game might finish and players become free again.

Greetz
nig

[tomreyn]

love it!
is it possible to show the message a liitle longer? its hard to click the "join" link in that short time. A silly notify sound would be nice too.

The message vanishing on its own is a quirk specific to the Firefox implementation (the standard does not mention this behavior and it does not happen with Chromium/Chrome). There's a bug report on Mozilla's bugzilla on it but I can't find it now.

Today I saw the "history" on http://play.mg the first time. nice idea too. Would be more useful if there were the starting time of each game visible. So you can have a guess when a game might finish and players become free again.

I agree we should record (this may already be happening since Softcoders' latest improvements) and expose this information, too.

[nig]

thanks for the game-time.
its available after a game has finished. It would be more useful to see the starting time during a game is running to have a guess, if it would finish soon.
seem to be nice, to see players names during the game to decide if it is worth waiting...

Gaming seems to be right social...

Maybe we need a battlecenter with all these infos and more like used factions, current number of units etc...