Being inspired by Marko Rodriguez's papers about grammar-based random walkers in semantic networks (http://www.soe.ucsc.edu/~okram/papers/random-grammar.pdf, and some less math-heavy ones at http://www.soe.ucsc.edu/~okram/Research.html), I thought the idea could be extended into kind of a "real time" control system.

The example can be thought of as depicting some operation taking place in some geographical area. There are field units, which are doing whatever necessary for the operation. The details of what they are doing are not simulated here. What is important for the current example is that they occasionally need help in the form of various services: technical service (if something brokes down), supply service, medical service, etc. The services are provided by service units, who go and provide their service to field units when necessary. The decisions about where service units should go are made using random walkers.

For a start, here is an extremely simplified example.

To see the  network, press F2.

 Links between field units and service units are "distance" links. Their weight is inversely proportional to the distance between field unit and service unit. Links between field units and the service type, and between service type and service unit, are "service of that type" links. Currently their weight is constant, but later can vary: the first ones depending on the field units' need for a given service (though the need can also be expressed through the number of generated walkers), and the second ones depending on how good the service unit is at providing that type of service.

When a field unit needs service, it (in current prototype) generates at each timestep:

• one walker that randomly (probabilities depending on link weights) chooses one "distance" link going to a service unit,
• one walker that goes out on the "service of that type" link. Currently nothing to choose from, as only one type of service is available. However, when that walker reaches service type bar, it currently can choose between two outgoing links, as there are two providers of that service type.
  

Walkers carry the information about who generated them.

Service units keep in memory last 30 or so incoming walkers, and at each timestep move towards the field unit whose walkers are most abundant in this set of incoming walkers (not a particularly ingenious strategy, but good enough for the first prototype). Service is "provided" instantly when service unit reaches a field unit.

Program usage 

Mostly it is just about sitting and watching. 

If things move too fast, press Z to slow down, X to speed up again.

To see the links between units, press F2.

To move boxes that have numbers on it, press the corresponding number on the keyboard (no need to hold it down) and then move mouse (no need to use mouse buttons). The number for the service type bar is 0.

To make mouse pointer visible and to release it from being "aggressively" grabbed by the program, press F1 (useful when you want to use mouse to move the application window or do something outside the program). However, using it for moving the boxes in the program is easier in mouse grab mode.

To exit, press Esc.

Download 

The program code is not very well designed, not easily extendable or anything, just a dirty hack.

Source in Python (tested in Python 2.4 in Win XP and MacOSX. Has several dependencies: pygame, PyOpenGL, ...): gramnet_simple_src.zip

Executable for Windows: gramnet_simple_winexe.zip

Application for Mac: gramnet_mac.zip.

What next?

More service types. Service units that are able to provide various services, and have different expertise for different services. The "need for service" a continuous value, not boolean. Better strategies for service units to decide whom to service. And many other enhancements are possible.

Questions

Is this idea a novel approach, or just some other method in disguise? Is it useful? Is it in some situations and in some way better than other approaches? What could be the applications?