Artificial Life Platform; enables you to write competiting AIs
C++ Perl C
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.


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

	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.