Changes between Version 2 and Version 3 of ProtocolZero


Ignore:
Timestamp:
May 31, 2011 7:55:02 AM (13 years ago)
Author:
jherwitz
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ProtocolZero

    v2 v3  
    1 This page will require cleanup, and is currently a dumpsite for connecting to Quagents3 at the lowest level of control.
    2 
    3 This is simply a proposal at this point. Please share your thoughts.
     1This page defines the currently implemented Quagents3 protocol.
    42
    53ProtocolZero is the command protocol used for directly talking to Quagents. (The naming convention adopted here is that ProtocolOne is the protocol (or API) between the thing that sits on top of Quake and deals with socket I/O and whatever more abstract structure exists above that; ProtocolTwo would be two levels removed.) In particular, ProtocolZero is for the agent-based communication, not for the experimental control.
     
    86ProtocolZero commands are sent as plaintext over a TCP/IP socket to Quake on port 6000. Currently, any new connections to this port result in the creation of a new bot. Each command should be terminated with a newline character.
    97
    10 Quagents model their behaviour in the form of a double-ended queue (note: some nastiness here since there's no dynamic memory allocation - but it seems possible to 'fake it' pretty well with two arrays). Commands can be pushed onto either the front ("now" commands) or the end ("then" commands). Some commands may generate automatic subcommands that are pushed onto the front of the queue - for example, "get railgun" might insert a bunch of moves first.
     8Quagents model their behavior in the form of a double-ended queue (note: some nastiness here since there's no dynamic memory allocation - but it seems possible to 'fake it' pretty well with two arrays). Commands can be pushed onto either the front ("now" commands) or the end ("then" commands). Some commands may generate automatic subcommands that are pushed onto the front of the queue - for example, "get railgun" might insert a bunch of moves first.
    119
    1210Additionally, all commands are optionally suffixable with an IDSTRING. If an IDSTRING is specified, when the task is complete, the agent should report "COMPLETED IDSTRING" or something like that (this is so simple to implement that it might be better left to a higher level: just insert an 'echo COMPLETED IDSTRING' task that is just behind the task itself). This may seem redundant given that the "then" commands already allow explicit task scheduling, but I can imagine it being nice to know precisely when given actions complete, without having to remember what order you issued commands in.
     
    1412It might be nice to allow all commands to be suffixed with a MAX_DURATION as well? The idea there is that you get a unified framework for specifying how long to do something before quitting.
    1513
     14A future goal is to implement an "overseer" structure which collects and returns macroscopic game data, such as all Quagents' position and group-based metrics (TBD). The idea is that there are two types of connection permissions - overseer and Quagent. This is defined during initial connection, either with a character permission system or the utilization of a different port number.
     15
    1616== Specification ==
    17 At this point let's just list stuff we want it to be able to do with wild abandon, and then have our starstruck dreams shattered by their impossibility. All the below commands should be prefixable with "now" or "then" to determine where they go on the queue. All commands should start with a letter, not a number or other character. Commands should not have spaces other than to separate parameters. Obviously some of these need renaming.
     17The front-end API is currently implemented in Java. The following functions are defined in the API, and their implementation is in progress.
     18
     19All the below commands should be prefixable with "now" or "then" to determine where they go on the queue. This will be implemented with an additional parameter for all function calls. All commands should start with a letter, not a number or other character. Commands should not have spaces other than to separate parameters.
     20
    1821
    1922'''INITIAL COMMANDS'''