But suppose two different controllers are in two different languages or computers or something? We're not sure there are any really compelling scenaria that demand an in-game fix, but it may not be a crazy idea to have a stylized set of naming and language conventions for quagent communication. OK you're up to date: now read on.
(Stolen from George Ferguson): Begin quote.
There's no real difficulty in making processes talk to each other. Using sockets in java is pretty painless as we all know. Cook up a message format and sling strings around. So I'm assuming that the students either haven't thought it through, or have something more organized and predefined in mind. For example, that agents all have names (and maybe "teams") and that messages can get addressed to agents (or teams) and magically arrive there. And maybe that there's some structure imposed on the messages already.
If that's what they want, and they don't want to roll their own, we could provide our TRIPS message-passing infrastructure for them to use. I haven't had a chance to look at BH's agent code, so I can't say how easy or hard it would be to integrate our stuff. My guess is, not too hard. Our stuff spawns a thread to handle messages, and calls callbacks (interface methods) to process them. The messages themselves are based on the KQML standard (very similar to FIPA ACL, mentioned previously). [See links on the quake links page -- CB] If I didn't want to sleep any more than I'm already not sleeping (err...), I would make it "pure" FIPA. Whatever. You could actually send anything as the content of the messages, including simple strings, a just use the TRIPS Facilitator's naming, addressing, broadcasting, etc., services, as well as logging and such not. Still leaves open *what* they'll say to each other, which could be a bug or a feature.
If you want to know more, like you want to look at the TRIPS code, just ask.
Then, if some one or group in the class has a compelling case for such a thing as the above, make a proposal. That is, tell what do you want to achieve, why (what scientifically interesting goal are you pursuing), what are you proposing exactly (underlying system mechanism, formalism, semantics, functionality), why is your proposed method better than competing methods. Proposal doesn't have to be long but it should show an open mind, a thorough look at issues, and strong technical grasp of the mechanisms.
This page is maintained by
Last update: 1.13.04.