mirror of
https://github.com/brmlab/brmlife.git
synced 2025-08-02 18:03:37 +02:00
23f2fce7ff
One party initiates the breeding; the other party exerts most of the energy if its breeding key matches. It is that party's responsibility to set up the newborn agent's connection (but the father can pass it an arbitrary message). Newborn is spawned immediately but can be renegotiated on first connect.
103 lines
3.3 KiB
Text
103 lines
3.3 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.
|
|
|
|
Both server input and client output follow the same 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
|
|
|
|
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>
|
|
<x> and <y> are integer offsets relative
|
|
to the current position; may be just {-1,0,1}
|
|
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_key <value>
|
|
<value> is arbitrary integer number; default is 0;
|
|
breeding succeeds only between individuals with key
|
|
that is near enough (abs(key1-key2) < kappa).
|
|
|
|
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.
|