Artificial Life Platform; enables you to write competiting AIs
Find a file
2011-12-08 00:11:33 +01:00
client Example client: Secrete a pheromone 2011-12-07 23:54:17 +01:00
.gitignore gitignore: rawio_{cfg,map} 2011-12-03 14:57:10 +01:00
agent.cc Make herbs smell 2011-12-07 23:55:37 +01:00
agent.h Make herbs smell 2011-12-07 23:55:37 +01:00
connection.cc Pheromones: Merge tile and agent info in pheromones output 2011-12-08 00:10:09 +01:00
connection.h Connection: Add negotiation phase 2011-11-27 05:06:46 +01:00
main.cc ./brmlife -t: Missing break 2011-12-03 18:57:53 +01:00
main.h Evolve herbs dynamically based on energy 2011-11-27 07:33:48 +01:00
Makefile Introduce pheromones 2011-12-07 23:54:03 +01:00
map.cc Introduce pheromones 2011-12-07 23:54:03 +01:00
map.h Introduce pheromones 2011-12-07 23:54:03 +01:00
pheromone.cc Introduce pheromones 2011-12-07 23:54:03 +01:00
pheromone.h Introduce pheromones 2011-12-07 23:54:03 +01:00
rawio.h Added server pre-gui interface 2011-11-28 21:08:48 +01:00
README Pheromones: Merge tile and agent info in pheromones output 2011-12-08 00:10:09 +01:00
viewer.nlogo Patches, patches, patches... 2011-12-03 20:13:08 +01:00
world.h Make herbs smell 2011-12-07 23:55:37 +01:00

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:

	tick <ticknum>
	BUMP
		if received, the agent's move failed
		(or attack of non-existent agent, etc.)
	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}
	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


After connecting, the client specifies 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.

In general, higher rate means higher energy maintenance of the
appropriate actuators.