Experiments with maps...

These two maps, Waterpoint on the left and JHM on the right were produced by the client when it was sent a bunch of data taken from Amit's mapping objects. Amit's code produces a list of room coordinates and exits that can be used to draw a map. The code searches for exits in the 8 cardinal directions (n,ne,e,se,s,sw,w,nw) to determine the initial room coordinates and then applys a bit of physics to ensure that the rooms don't get too close together.

The red room represents the player's position at the time the map was generated, but in addition the client is able to update the position as the player moves from room to room. You can click on any of the blue rooms to cause the message 'walk to #oid' to be sent to the mud. Moving the cursor over a room display's the room's name in the title box under the map.

Ideas...

• is it possible to make the geometry cleaner? if 3 rooms are joined north/south of each other then shouldn't the lines appear to be straight instead of bent in the middle?
• it's possible to use the map to display other information too, like the location of parties. perhaps you could make @who indicate the location of who you're looking for on the map.
• Amit's map generating code doesn't take account of directions like up or down, but the walking code does. this means that if you walk from A to B and your path takes you up or down then your red location marker will momentarily disappear from the map.
• what difference would a Z component (altitude) make to the map? could it be represented in VRML?
• how does this compare with existing drawn versions of the map? which is the correct view of waterpoint, does it matter, if so then how could the maps be made more alike?
• what about scrolling the map if it's very big, or features lots of rooms.

Experimental Rose Widget

This screenshot shows the client with an embedded rose widget. The widget is based on the Rosette Feature Object with adjacent room names appearing in clickable buttons. Click on a button and the client will send a command to invoke the exit (eg. 'north'). The rose widget is defined in a plugin script, a Tcl program that the client reads when it starts up.

The plugin's code cooperates with a Feature Object on the server which updates the buttons each time you enter a new room. The same code updates the current position indicator on the map.

Plugins and Feature Objects

The Rose Widget consists of a plugin and a feature object. Copy the plugin script to ~/.tkMOO-lite/plugins/ and start the client. Connect to Waterpoint and select the Preferences->Preferences Editor menu option to start the preferences editor. Select the Special Forces category and toggle the 'Display rosette' option. The client is now ready to receive information from the feature object.

• rose.tcl

• you need to toggle the 'XMCP/1.1 enabled' option in the preferences editor
• connection script:
  • connect %u %p
  • @xmcp_challenge
• XMCP/1.1 connection script:
  • @xrose

The command @xmap will start the map using whatever information is currently stored in Amit's mapping stuff. To use the map, stand in an interesting place and 'poke map', the results can then be displayed again using @xmap.

However, to use the map you'll need the map plugin which you should install in the same way as you did for the rose:

• map.tcl

That's it. All these details, especially the plugin stuff are subject to change. Give me a shout if this doesn't work. Oh, this only works as advertised on Waterpoint, and you may experience some non fatal warnings from the client if you're not using an up-to-data version.

Arrgh! it seems that this is *only* going to work on client version 0.2.60 and newer (.60 hasn't been released yet, but you could try the .60-dev version if you're feeling brave). Alternatively take your 0.2.59 version, rip out xmcp11.authenticated and put this in its place:

proc xmcp11.authenticated { {flag verbose} } {
    global xmcp11_authentication_key
    if { [request.get current _authentication-key] == $xmcp11_authentication_key
 } {
        return 1
    }
    # should really be up to applications to care about notification
    # but this is simpler for now...
    if { $flag == "verbose" } {
        xmcp11.no_auth_dialog [request.get current _type] [request.get current _
authentication-key]
    }
    return 0
}   

Map Improvements, Terrain

This is a version of the map that contains small images representing types of terrain. Presently the terrain type and density is defined per room in a private table, but eventually this information might be derived from the site's environment/zone information. Zone information might also be a useful cue to Amit's mapping code, ensuring that rooms that are intentionally close (in the same zone) are less likely to be dispersed by the mapping code's physics.

Letting the Client do the work

These two maps were created in a slightly different way. The MOO provided data indicating how the rooms in the map are interconnected, and the client decided how the room coordinates should be calculated. The first map shows the rooms placed on a simple grid, some rooms overlap.

Red lines display the direction and magnitude of forces experienced by each room. Rooms repel each other, all rooms act upon all other rooms, not just adjacent rooms. Paths act to attract adjacent rooms. The same basic idea used by Amit's in-db code. The second map shows the results of applying these forces. The result has been scaled down to fit on a 200x200 canvas, in real life the map's surface area has increased.

Where are the people?

This map shows the distribution of connected users at waterpoint. Each person is represented by a small black dot located 'near' to the square that represents their location. The second image indicates how long the user has been inactive, by setting the colour intensity of the dot. This works in a way similar to the Experimental @whoWidget.