mirror of
https://github.com/brmlab/brmlife.git
synced 2025-08-01 17:33:35 +02:00
118 lines
3.8 KiB
Text
118 lines
3.8 KiB
Text
Artificial Life Platform
|
|
========================
|
|
|
|
Client-server protocol: The time is quantized in ticks.
|
|
In each tick, the server sends sensor input to the agent.
|
|
Until the next tick, the client may supply actions to take
|
|
to the server.
|
|
|
|
Server input follows the format:
|
|
|
|
cmd1 <par1> <par2>...
|
|
cmd2 <par1> <par2>...
|
|
...
|
|
<empty line>
|
|
|
|
I.e. a sequence of lines terminated by an empty line.
|
|
Each line starts with a single word (command name), plus
|
|
some command-specific parameters. Note that newlines are
|
|
CRLF ("\r\n"), not just LF ("\n")!
|
|
|
|
The following inputs (in no particular order) are supported:
|
|
|
|
agent_id <id>
|
|
unique id of agent; may be sent only once at the beginning
|
|
(you can use it to reconnect to the same agent later)
|
|
tick <ticknum>
|
|
BUMP
|
|
if received, the agent's move failed
|
|
(or attack of non-existent agent, etc.)
|
|
BRED <id> <father_info>
|
|
a new agent has been spawned, connect using agent_id <id>;
|
|
<father_info> is arbitrary string passed from the father,
|
|
can be used for genetic recombination
|
|
DEAD
|
|
if received, the agent is dead!
|
|
energy <points>
|
|
number of agent's energy points; disregard
|
|
in case of dead agents
|
|
visual <desc> <desc>...
|
|
<desc> describe tiles, clockwise from top,
|
|
in the immediate vicinity of the agent
|
|
<desc> format is two-character, <type><agent>
|
|
<type>: . for ground
|
|
<agent>: - no agent
|
|
a dead agent
|
|
A alive agent
|
|
x herp
|
|
pheromones (<ph>,<ph>,<ph>,...) (<ph>...)...
|
|
(<ph>,...) describes set of pheromones on a tile,
|
|
in the same order as visual; if agent is on a tile,
|
|
its pheromones are merged with tile pheromones
|
|
<ph> format is <id>:<intensity>
|
|
<id>: pheromone id 0..65535
|
|
<intensity>: floating-point number
|
|
|
|
Client output follows a slightly different format:
|
|
|
|
<tickid> cmd1 <par1> <par2>...
|
|
<tickid> cmd2 <par1> <par2>...
|
|
...
|
|
|
|
Only commands with a matching tickid are processed; in case a command
|
|
is delayed, causing late relaying to the server and processing in the
|
|
future, it is silently dropped and ignored.
|
|
|
|
The following outputs are supported:
|
|
|
|
move_dir <x> <y>
|
|
<x> and <y> are integer offsets relative
|
|
to the current position, may be just {-1,0,1}
|
|
attack_dir <x> <y> <force>
|
|
<x> and <y> are integer offsets relative
|
|
to the current position, may be just {-1,0,1};
|
|
<force> is invested energy, damage is proportional
|
|
breed_dir <x> <y> <info>
|
|
<info> is arbitrary string passed to the "mother"
|
|
(to be passed to the child)
|
|
secrete <phid> <phintensity>
|
|
produce a pheromone; pheromones are initially
|
|
associated with an agent and trailed at tiles
|
|
visited by the agent; pheromones with lower id
|
|
transfer from agent to tile faster
|
|
energy required is proportional to phintensity
|
|
|
|
|
|
When new agent connects, the client first enters the "negotiation"
|
|
phase, specifying its desired attributes, in the same format as in
|
|
normal output (line-based, terminated by empty line), but with
|
|
these commands instead:
|
|
|
|
move <rate>
|
|
<rate> between 0 and 1, describing probability
|
|
of success of move command.
|
|
attack <rate>
|
|
<rate> between 0 and 1.
|
|
defense <rate>
|
|
<rate> between 0 and 1.
|
|
breeding_key1 <value>
|
|
breeding_key2 <value>
|
|
<value> is arbitrary integer number; default is 0;
|
|
breeding succeeds only between individuals with key
|
|
that is near enough (abs(key1-key2) < kappa).
|
|
key1 is used as the initiator's key, key2 as the
|
|
receiver's key. (I.e., use different keys for
|
|
sexually reproducing species.)
|
|
|
|
In general, higher rate means higher energy maintenance of the
|
|
appropriate actuators.
|
|
|
|
Alternately, the client may send a single command in the negotiation
|
|
phase:
|
|
|
|
agent_id <id>
|
|
|
|
If the id corresponds to a disconnected agent, the connection
|
|
is immediately attached to that agent. Combining this with other
|
|
negotiation commands is undefined, except for newborns - in that case,
|
|
negotiation commands must follow after agent_id.
|