Bot language | June 9, 1997 | $1.50 Sundays |
[ May 11, 1997, mikeBot press ] Amid speculation amongst big-name players in the client-side bot arena that mikeBot couldn't talk, a top-secret and still-in-development document outlining a beta version of both a human-bot "say" language spec and a socket-based inter-bot spec was given annonymously to one of our reporters. |
It is reproduced below, verbatim, for your reading pleasure. A note accompanying the document indicated feedback is wanted by Project leader Mike.
|
This is still very much under development |
why? |
An interbot communication protocol would be useful in many ways. The "say" interface will allow humans to communicate with the bots easily, and advanced socket commands would allow bots to team up, especially during CTF, for example. Also, a standard is needed so bots from different authors can understand each other. Note that QuakeBot C/S also has a proposed (partial) standard.
feedback |
I would appreciate any thoughts you have, pro or con, regarding both the socket and "say" mikeBot Language Specs.
the say interface |
These simple commands, sent through the say command, will allow both human players and bots to ask simple questions of other bots.First, though, player numbers will need to be determined by the name of the player, so some parsing rules for player names need to be established:
I.e. you could (and probably should ;) ) use C-code like this:
- Convert all characters to "real" ASCII (0..127) (i.e. strip the top bit off)
- All non-printable characters are converted to underscores ('_'). (all characters < 32, including linefeed)
void parseName( char * n ) { for( int i=0; n[i]; i++ ) { n[i] &= 0x7F; if( n[i] < 32 ) n[i] = '_'; } }
In the following table, <name>:text means the bot should say the player it is responding to, followed immediatly by a `:', followed by the responce string. Note also that "command" is the string that should be sent exactly as-is through a say message, with no extra characters before or after it.Commands with white backgrounds remain un-implemented
Also, you have the option of supporting only some of the commands. However, if you support one compliance-level, you must support all commands in that level. Compliance level is indicated by the colour in the last column.
command meaning responce(s) C-L mbl-author Who made any bots here? The bot should say who its author is, along with some sort of contact info. (web page, email etc.) 1 mbl-bot Which bot is this? The bot should respond with <name>: mbl-bot-<bot name> where bot name is the actual name if the bot (i.e. mikeBot, JavaBot, etc.) 1 mbl-hate How much do any bots here hate me? <name>:<hate level> : this is more mikeBot-specific, but this would notify the asking player of how likely it is they are targeted compared to all other players (if they are all visible, obviously). Preferably as a percentage. 1 mbl-help What were those commands...? The bot should print out a list of all supported mbl- commands and their meaning 1 mbl-compliance How much of MBL do you comply with? The bot should respond with <name>: mbl-compliance-level-X where X is 1, 2 or 3 depending on how much of MBL the bot supports. 1 mbl-socket Do bots here support mbl socket interface? <name>:yes-mbl-socket implies the bot does support the socket communications described below. It would be nice to print the number of connected communications on the bot socket interface as well. <name>:no-mbl-socket means the bot doesn't support inter-bot socket communication. 1 mbl-cooperate Any bots here want to cooperate with me? <name>:yes-mbl-cooperate : implies the bot is now on the asker's team, and should switch colours to their's and no longer target them, unless, say, they shoot the bot.
<name>:no-mbl-cooperate : implies the bot doesn't want (can't) cooperate with the requesting player.2 mbl-maximal-hate Bring it on, bots! <name>:yes-mbl-maximal-hate : implies the bot has increased the requesting player's hate above all other players (thus being targeted above others). 2 mbl-target Who are you targeting? The bot should pring out the name of his target, parsed as per above 2 mbl-observers Any observers connected? The bot should print out all connected observers or observers not supported if there is no observer mode. 2 mbl-wingman-on Be my wingman, bot. Only if the bot is cooperating (mbl-cooperate) and the teammate is visible. The bot will then follow the player 128.0 units behind and aquire other targets in the normal manner...If the bot does not want to/ can't go into wingman-mode, it should respond <name>:no-mbl-wingman. The bot should respond <name>:yes-mbl-wingman if it is now in wingman mode. 3 mbl-wingman-off Stop being my wingman, bot. If the bot is in wingman-mode, it goes out of wingman-mode. The bot should respond <name>:yes-mbl-wingman-off if it is now not in wingman-mode. It should respond <name>:no-mbl-windman-off if there was an error (i.e. the bot wasn't in wingman-mode) 3
Feedback is definetly needed...
the socket interface |
I have reconsidered and decided a client-server architecture for the bot socket interface is desireable. Therefore, bots should attempt to connect to each other on port 26000 with the same control packets as normal quake, but using the string "QUAKEBOT-MBL" instead of "QUAKE", similar to QuakeBot C/S's proposal. Then, after connected, the following packets are legal, and should be sent reliably, using the same (reliable) packets as quake.Note that if a bot-talk server accepts the connection, it implies level-2 cooperation. A rejection implies no cooperation (level-1) and no responce implies non-bot cooperation. (i.e. the player is probably human or doesn't support mbl-socket)
CO-OP level meaning level-0 Unresponsive bot or human. level-1 Non-cooperating bot. level-2 Minimum cooperation. You are still allowed to target the bot you are talking to. level-3 Deathmatch cooperation. You must not target the bot you have agreed to cooperate with. level-4 CTF cooperation. Only allowed if you are on the same team as the other bot. Note the co-op levels in the last column. Also note that all number are in little-endian order (Motrolla) which is not Intel order. Also realize that by int I mean a 4-byte signed integer; short is a 2 byte signed integer. floats are 4-bytes as well and use IEEE floating-point syntax. A byte is an 8-bit signed number, while a char is a 7-bit ASCII value. Also note that playernumbers are not entity references; entity numbers are 1 greater than playernumbers (i.e. player number 0 is actually entity 1 since the world itself is always entity 0).
Also, note that if your bot agrees to a certain co-op level, it must send the messages in that co-op level if they occur. Also, a higher co-op level implies all messages in all lower co-op levels must also be sent. (i.e. bots communicating at level-3 also send level-2 messages)
Note, too that if there is a cleint-server relationship there should not also be a server-client one (if that makes sence) i.e. if bot A connects to bot B, bot B should not connect to bot A.
opcode data meaning co-op level 0x00 none. Disconnect. Tells the server or client to disconnect. Implies cooperation-time is over. Any level ![]()
0x01 struct { byte playerNumber; }Quad: playerNumber is the guessed person who has the quad (0 <= playerNumber < maxPlayers). If it is negative, then the bot is unsure who has it, but someone just picked it up. This can, of course, be used to say "I just got the Quad" level-2 0x02 struct { byte playerNumber; }Pentagram: same as above, but for the POP. level-2 0x03 struct { byte playerNumber; }Biosuit level-2 0x04 struct { byte playerNumber; }Ring of Shadows level-2 0x05 none. Level-3 request. Requests level-3 cooperation. The server (or client) responds with a 0x81 responce for accept or nothing for reject (so don't keep asking...). level-2 0x06 none. Level-4 request. Requests level-4 cooperation. The server (or client) responds with a 0xC1 responce for accept or nothing for reject (only ask once). level-2 ![]()
0x81 none. Level-3 accept. Bump cooperation level to level-3 level-3 0x83 struct { byte playerNumber; }Target on. Tells the recipient that the bot just started targeting playerNumber. level-3 0x84 none. Target off. Informs the recipient the bot is no longer targeting anyone. Should only be sent once, when a target is killed or goes out of sight. level-3 0x85 struct { unsigned short amount; byte playerNumber; }Damage. Informs recipient that playerNumber did amount units of damage to the bot. level-3 ![]()
0xC1 none.Level-4 accept. Bump co-op level to level-4 level-4 0xC2 struct { byte playerNumber; }Flag. Informs recipient that playerNumber is a flag-carrier; it would be nice to guard him, now... level-4 0xC3 none.Base guard needed. Informs recipient to guard base. (The recipient is under no obligation to comply) level-4 0xC4 none.Offence needed. Informs recipient to attack enemy base. (The recipient is again under no obligation to comply) level-4
Fully-autonomous![]() client-side quake bot |
Best experienced with![]() Click here to start. |
Proud member of![]() The Bot Author's Guild |