wiki:ProtocolZero

Version 1 (modified by jpawlick, 13 years ago) (diff)

--

This page will require cleanup, and is currently a dumpsite for connecting to Quagents3 at the lowest level of control.

This is simply a proposal at this point. Please share your thoughts.

ProtocolZero 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.

Overview

ProtocolZero 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.

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.

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.

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.

Specification

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.

  • Basic robot-like functions for users who want low-level fine control. (Implement first)
    • walkby [DISTANCE] - the bot moves forward until it reaches the distance or strikes an obstacle, in which case it reports so.
    • walkto [LOCATION] - the bot rotates and moves in a straight line to a given coordinates (or to directly above/below them, if not on the same Z-plane).
    • turn [ANGLE] - rotates the bot clockwise by the specified angle
    • echo [STRING] - reports a string back over the socket to the user
    • look - sends an image over the socket back to the user representing what the agent can see.
    • listen [TIME] - sends sounds back to the user for the specified time. This seems like it might be Hard.
    • exactlywhereareyou? - returns the bot's coordinates.
  • More complex robot-like functions. (Implement next)
    • follow [ENTITY] [DIST] - Bot moves toward/away from entity until it is at the given distance, if possible, and attempts to maintain that.
    • track [ENTITY] - Bot rotates to face entity.
  • Invokable Quake Behaviors (Implement last)
    • getto [OBJECT] - finds the location of such an object and then does the below.
    • getto [LOCATION] - pathfinds its way to the location. It would be nice if along the way it used Quake's goal system. That would give us free puzzle-solving/button-pushing/surfacing-for-air.
    • whereareyou? - returns what the bot usually says if you ask it that in a team game ("I'm by the rail gun in the blue base." sort of things).
    • followsmart [ENTITY] - smartly follows the given character using Quake's follow chat command.
    • playQuake - activates Deathmatch AI?
  • Behavior management system / agent management (Also implement first?)
    • forgetalltasks - clears the command queue
    • pause [TIME] - if TIME=0, wait forever, else wait TIME milliseconds. (As with all commands, can be interrupted with "now pop".)
    • pop - deletes the current command. If this is the only command, does nothing. (Note: weird to think about: "then pop, then walkby" - pop will clear the walkby even though it was issued before it.)
    • peek - echoes a description of the current command.
    • peeknext - echos a description of the next command to evaluate

Implementation

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.