Changes between Version 13 and Version 14 of ProtocolZero


Ignore:
Timestamp:
Jun 3, 2011 12:56:13 PM (13 years ago)
Author:
jpawlick
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ProtocolZero

    v13 v14  
    44
    55== Overview ==
    6 ProtocolZero commands are sent as plaintext over a TCP/IP socket to Quake on port 6000. We have designed a simple grammar based on RISC ISA to streamline the parsing process, named wiki:QuagentISA. Currently, any new connections to this port result in the creation of a new bot. Each command should be terminated with a newline character.
     6ProtocolZero 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. Command format is of the form :A BB IDNUM PARAM_1 PARAM_2 PARAM_3 PARAM_4... \n
     7 * where A is either a 't' or 'n' character, for 'then' or 'now', specifying scheduling (see below).
     8 * where BB is the opcode of the instruction (always 2 characters).
     9 * where IDNUM is a sequence of numeric characters representing an unsigned 32-bit integer. This code will be returned on completion, for the client's convenience. We imagine that users will typically make this a sequence number, but we do not require or enforce uniqueness.
     10 * where P1... are parameters for the instruction, and may be any length. They are delimited by spaces, and therefore cannot contain spaces (even if explicitly quoted or escaped). Parameters should be printed in ASCII, so 253 is '2','5','3', not '\253'. Floats are interpreted by the atof() function.
     11 * and \n is a newline. A carriage-return will work just as well.
    712
    8 Quagents 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.
     13Examples (each of these entries ought to be terminated by a newline):
     14 * t ju 653 0 1
     15  * This command means: "after you do everything I've told you to do, jump. This is command id=0, and you should jump in direction 0 degrees at speed 1".
     16  * The server will respond after some time "cp ju 653 done".
     17 * n po 0
     18  * This command means: "immediately pop what you're doing, this is command id=0".
     19  * The server will respond (almost instantly in this case) "cp po 0 done" then some other message about the previous command (say, "cp ju 653 popped").
     20 * t mf 350 180 0.4
     21  * This command means: "after you do everything I've told you to do, walk forever, this is command id=350, direction=180 degrees, speed=0.4".
     22  * The server might eventually respond "cp mf 350 blocked".
    923
    10 Additionally, 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.
    11 
    12 It 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.
     24Quagents model their behavior in the form of a double-ended queue that has a maximum capacity of 128 commands. Commands can be pushed onto either the front ("now" commands) or the end ("then" commands).
    1325
    1426A future goal is to implement a GOD (Global Overview Descriptor) 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 - GOD and Quagent. This is defined during initial connection, either with a character permission system or the utilization of a different port number.
    1527
    16 == Specification ==
    17 The front-end API is currently implemented in Java. The following functions are defined in the API, and their implementation is in progress.
     28== Brief Specification ==
    1829
    19 All 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.
     30'''INITIAL COMMANDS'''
     31* ''r'' - "ready", spawns the bot.
    2032
     33
     34'''LIVE COMMANDS'''
     35* Movement:
     36 * ''[[mf]]'' - "Move Forever". Takes three arguments:
     37  * int obstacles
     38  * float direction
     39  * float speed
     40 * ''[[ju]]'' - "JUmp once". Takes two arguments:
     41  * float direction
     42  * float speed
     43 * ''[[ro]]'' - "ROtate". Takes two arguments:
     44  * float yaw
     45  * float pitch
     46* Command Queue Management
     47 * ''[[po]]'' - "POp". Takes no arguments.
     48 * ''[[pa]]'' - "PAuse". Takes no arguments.
     49 * ''[[fa]]'' - "Forget All tasks". Takes no arguments.
     50
     51'''GOD'''
     52
     53== Not Yet Implemented Commands ==
    2154
    2255'''INITIAL COMMANDS'''
     
    77110* We also want GOD functions that can change the world state. These are TBD.
    78111
    79 == Implementation ==
    80 Each of these behaviours will be modelled as an ai_node function. Parameters will be saved in the bot state struct, which gets passed to these functions.
    81112
    82113== WalterAPI ==