Quagent Ideas

This page is to hold onto ideas that otherwise might get lost as email is deleted and discussion groups closed. This page is itself an idea that might well not work out, but here goes anyway.

UGs and Research

Meta-idea. Undergraduates get involved with research using this Quake engine. Requirements would be the usual for any research job in the way of scholarship, curiosity, ingenuity, perserverance, and talent, plus superior programming skill and programming discipline (including documentation and willingness to acquire and use simple s/w engineering practices).

Specific research project

Design and implement an interface (or an environment for creating and experimenting with interfaces) for commanding a team or teams of intelligent agents. What would graphics look like, would there be a NL interface, what command structures are appropriate, etc.

Quagent Communications

The issue is how quagents communicate. Our current line is that certainly bots don't. The quagent "controller code" can, just with sockets say, or shared files, global variables, whatever. (See the Quagent Overview page).

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.

End quote.

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.

242 Home Page

This page is maintained by

Last update: 1.13.04.