In the year 2121, everybody is wondering what has happened during the previous 33 years. While the landscape has drastically changed, the citizens of Mars have adapted and specialised their ATPs, e.g. to be more efficient at scouting the environment or clearing debris. Suddenly, an official regulation agent of the New Official Regulation and Monitoring Syndicate (N.O.R.M.S.) arrives. The agent claims to have been instituted to oversee and regulate the reconstruction of Mars infrastructure to keep everyone safe.
The scenario consists of two teams of agents moving on a grid. The goal is to explore the world and acquire blocks to assemble them into complex patterns.
Agents can adopt roles that are each better suited for specific tasks. The main goal of the agents is to acquire and attach blocks to each of their four sides, moving and rotating them into specific positions, connecting them together with other agents to create more complex structures, and finally to deliver these structures to specific locations.
Tournament points are distributed according to the score of a team at the end of the simulation. Winning a simulation awards 3 points, while a draw results in 1 point for each team.
The environment is a rectangular grid. The dimensions are not known to the agents. Agents only perceive positions relative to their own. The x-axis goes from left to right (or eastwards) and the y-axis from top to bottom (southwards).
The grid loops horizontally and vertically, i.e. if an agent moves off the right "edge" of the map, it will appear on the left side.
Each cell of the grid contains up to one thing that may collide with other things, i.e. agents, blocks and obstacles. Only in the beginning of the simulation, an agent shares the same cell with one agent of the other team/s (to ensure fairness). Once one of the agents has moved away, they cannot overlap again later.
Each agent controls one entity in the simulation (s.t. we can use both terms interchangeably). Agents do not know their absolute positioning in the environment. They only know their current role, their energy level and whether they are currently deactivated. In addition, they perceive all "things" within their vision radius.
Each agent starts with the same energy level and automatically recharges a fixed amount per step (usually 1 energy point). There are various ways for an agent to lose energy (e.g. being hit by clear actions/events, violating norms, using the clear action, ...). Once the energy reaches 0, the agent gets deactivated for a fixed number of steps.
If an agent becomes deactivated, it loses all of its attachments and remains inactive for a fixed configurable number of steps. For as long as the agent is deactivated, all its actions will result in failed_status. The energy value remains 0 during the deactivation period, after which the agent gains a certain (preconfigured) energy level.
Agents perceive everything in a specific radius r around them. In other words, a cell can be seen by an agent, if its distance (Manhattan distance, taxicab metric, ...) to the agent is at most r. The following illustrates a few different values for r. (X and * can be perceived, X is the agent's position).
r=3 r=4 r=5
* * *
*** *** ***
***** ***** *****
***X*** ******* *******
***** ****X**** *********
*** ******* *****X*****
* ***** *********
*** *******
* *****
***
*
There are number of things that can inhabit a cell of the grid:
- Entities: Each agent controls an entity on the grid. Entities can move around and (with one of the correct roles) attach themselves to other things.
- Blocks: The building blocks of the scenario. Each block has a specific type. Agents can pick up blocks and stick multiple blocks together. Blocks have to be arranged into specific patterns to get score points.
- Obstacles: Obstacles block the passage of agents. They can be attached and moved away or removed by clear actions. In contrast to blocks, they cannot be connected to other obstacles (or even blocks).
- Dispenser: Each dispenser can be used to retrieve a specific kind of block.
- Marker: A marker marks a cell. Markers do not block other things. For now, markers are used to signal incoming clear events.
A zone has a center and a radius. There are two types of zones in the game.
- Goal zones: Agents have to be on a goal cell in order to be allowed to submit a task.
- A goal zone moves to another location after a certain number of tasks has been submitted inside.
- Role zones: Agents have to be on a role cell in order to use the adopt/adapt action.
- Role zones stay the same for the whole simulation.
The environment randomly generates events.
When a clear event happens, a certain area is marked. The timing and size of an event is random. Each event can be perceived (i.e. its clear markers) for a few steps before it actually occurs. Once it resolves, the marked area is cleared:
- The energy of affected agents is reduced to 0 and therefore, they get deactivated.
- All obstacles and blocks affected vanish.
- New obstacles are created randomly around the center of the event (and not necessarily in the previously marked area).
Config: match.events.*:
chance- the chance for a clear event to start in any step (in %)radius- the bounds for the event sizewarning- the number of steps the area is marked before the event resolvescreate- the bounds for how many obstacles are created (additional to the number of objects destroyed by the event)perimeter- an additional radius where new obstacles may be created (added to the event's radius)
Norms introduce dynamically small changes in the rules of the game. When a norm is in place, an agent must decide whether to follow or violate it. In the latter case, the violator is punished with a decrease in its energy level. Before policing a norm, the game's officer announces it to all agents. After a small number of steps, the norm becomes active. We call an approved norm a norm that is either announced or active. Each norm regulates on a specific subject, that is, a characteristic of the scenario. Moreover, a norm regulates on what either an agent (individual level) or a team (team level) can do. For instance, at the team level, a norm might state that at most 2 agents may adopt a given role.
Config: match.regulation.*
Regarding the general regulation:
simultaneous- how many norms are allowed to be in the state approved at the same stepchance- the chance for a norm to be created (in %)subjects- the subjects a norm may regulate
Regarding each specific subject:
name- It must be one of the following options:- Carry: the agents are prohibited to carry a certain number of attachable things;
- Adopt: the teams are prohibited to have more than a specified number of agents adopting a particular role.
announcement- the number of steps of the announcement periodduration- the number of steps the norm stays active after the announcement period is overpunishment- the number of energy points an agent loses in case it violates a normweight- an integer value that dictates the probability of selecting the subject. For instance, if subject SubjectA has weight of 15 and subject SubjectB has weight of 15, then each subject has probability of 50% of being selected.optional- subject dependent information to help specifing on what a norm should regulate.
Establishes an upper bound on the number of attachable things that an agent can carry. An attachable thing is either an entity, a block, or an obstacle.
Additional Configuration
quantity- the lower and upper bound on the number of things an agent may carry
Algorithmic View:
- Select a random upper bound given the bounds specified in the config file;
- Apply that bound to all attachable things;
- E.g., the bound is set to 2, and an agent is carrying one block of each of the following types
b0,b1, andb2. Therefore, punishment is applicable to that agent.
- E.g., the bound is set to 2, and an agent is carrying one block of each of the following types
- Punish every agent that does not follow the norm.
Requeriment Percept:
For the 16th MAPC, the carry subject (see the step percept description) has a single requirement and its correspondind percept is in the form of
"requirements": [{ "type": "block", "name": "any", "quantity": 1 }]
- Property
typeis set toblock. - Property
nameis always set toany. That means, anything attached to an agent counts towards the maximum number of attachable things it may carry. - Property
quantityis an integer value between the configured range.
Establishes an upper bound per team on the number of agents that can play a chosen role.
Additional Configuration
playing- the percentage of agents that can play a given role
Algorithmic View:
- If the percentage is set to
0%, then no agent can play that role - Count the number of agents adopting each role and set the probability of choosing a role to be prohibited accordingly.
- Count the number of agents in each team that is adopting the selected role; select the greatest number.
- Set the number of agents allowed to play the selected role (per team) according to a percentage defined in the configuration file.
- E.g., the role
explorerhas been selected, and20agents are playing this role currently (5agents in Team A and15agents in Team B). The percentage has been set to50%, then the norm will allow8agents per team to play the role ofexplorer.
- E.g., the role
- Punish all agents in a team that are not following the Norm.
- E.g., Team B has
9agents playing the role ofexplorer; thus the9agents will be punished
- E.g., Team B has
Requeriment Percept:
For the 16th MAPC, the adopt subject (see the step percept description) has a single requirement and its correspondind percept is in the form of
"requirements": [{ "type": "role", "name": "default", "quantity": 5 }]
- Property
typeis set torole. - Property
nameis one of the available roles. - Property
quantityis an integer representing the maximum number of agents that can adopt that role in a team.
Tasks have to be completed to get score/simulation points. They appear randomly during the course of the simulation.
- name: an identifier for the task
- deadline: the last step in which the task can be submitted
- reward: the number of points that can be earned by completing the task
- requirements: each requirement describes a block that has to be attached to the agent
- x/y: the coordinates of the block (the agent being (0,0))
- type: the required type of the block
Tasks have to be submitted in goal zones. Each task can be submitted multiple times for as long as it is active. A task is replaced by a new one when
- it has been submitted a certain number of times (unknown to the agents; submissions of all teams are counted), or
- its deadline is reached before that.
In each step, an agent may execute exactly one action. The actions are gathered and executed in random order.
All actions have the same probability to just fail randomly.
Each action has a number of parameters. The exact number depends on the type of action. Also, the position of each parameter determines its meaning. Parameters are always string values.
The agent won't do anything this turn. Always successful (except for random fail).
Moves the agent in the specified directions. If the agent is currently allowed to move more than one cell, multiple directions can be given.
| No | Parameter | Meaning |
|---|---|---|
| 0-* | direction | One of {n,s,e,w}, representing the direction the agent wants to move in. |
| Failure Code | Reason |
|---|---|
| failed_parameter | No parameters given or at least one parameter is not a valid direction. |
| failed_path | The first move was blocked. |
| partial_success | At least the first step worked but one of the later moves was blocked. |
Attaches a thing (friendly entity, block or obstacle) to the agent. The agent has to be directly beside the thing.
| No | Parameter | Meaning |
|---|---|---|
| 0 | direction | One of {n,s,e,w}, representing the direction to the thing the agent wants to attach. |
| Failure Code | Reason |
|---|---|
| failed_parameter | Parameter is not a direction. |
| failed_target | There is nothing to attach in the given direction. |
| failed_blocked | The thing is already attached to an opponent agent. |
| failed | The agent already has too many things attached. |
Detaches a thing from the agent. Only the connection between the agent and the thing is released.
| No | Parameter | Meaning |
|---|---|---|
| 0 | direction | One of {n,s,e,w}, representing the direction to the thing the agent wants to detach from. |
| Failure Code | Reason |
|---|---|
| failed_parameter | Parameter is not a direction. |
| failed_target | There was no attachment to detach in the given direction. |
| failed | There was a thing but not attached to the agent. |
Rotates the agent (and all attached things) 90 degrees in the given direction. For each attached thing, its final position after the rotation has to be free.
| No | Parameter | Meaning |
|---|---|---|
| 0 | direction | One of {cw, ccw}, representing the rotation direction (clockwise or counterclockwise). |
| Failure Code | Reason |
|---|---|
| failed_parameter | Parameter is not a (rotation) direction. |
| failed | One of the things attached to the agent cannot rotate to its target position OR the agent is currently attached to another agent. |
Two agents can use this action to connect blocks attached to them. They have to specify their partner and the block they want to connect. Both blocks are connected (i.e. attached to each other) if they are next to each other and the connection would not violate any other conditions.
agent1 is on (3,3) and agent2 is on (3,7). agent1 has a block attached on (3,4) and one attached to that block on (3,5). agent2 has a block attached on (3,6). Both agents want to connect their attached blocks, namely those on (3,5) (of agent1) and (3,6) (attached to agent2).
Then, agent1 has to perform connect(agent2,0,2), while agent2 has to perform connect(agent1,0,-1) in the same step. If both actions succeed, the blocks will be connected and still attached to both agents.
| No | Parameter | Meaning |
|---|---|---|
| 0 | agent | The agent to cooperate with. |
| 1/2 | x/y | The local coordinates of the block to connect. |
| Failure Code | Reason |
|---|---|
| failed_parameter | First parameter is not an agent of the same team OR x and y cannot be parsed to valid integers. |
| failed_partner | The partner's action is not connect OR failed randomly OR has wrong parameters. |
| failed_target | At least one of the specified blocks is not at the given position or not attached to the agent or already attached to the other agent. |
| failed | The given positions are too far apart OR one agent is already attached to the other (or through other blocks), or connecting both blocks would violate the size limit for connected structures. |
Disconnects two attachments (probably blocks) of the agent.
| No | Parameter | Meaning |
|---|---|---|
| 0/1 | attachment1 | The x/y coordinates of the first attachment. |
| 2/3 | attachment2 | The x/y coordinates of the second attachment. |
| Failure Code | Reason |
|---|---|
| failed_parameter | No valid integer coordinates given. |
| failed_target | Target locations aren't attachments of the agent or not attached to each other directly. |
Requests a new block from a dispenser. The agent has to be in a cell adjacent to the dispenser and specify the direction to it.
E.g. if an agent is on (3,3) and a dispenser is on (3,4), the agent can use request(s) to make a block appear on (3,4).
| No | Parameter | Meaning |
|---|---|---|
| 0 | direction | One of {n,s,e,w}, representing the direction to the position of the dispenser to use. |
| Failure Code | Reason |
|---|---|
| failed_parameter | Parameter is not a direction. |
| failed_target | No dispenser was found in the specific position. |
| failed_blocked | The dispenser's position is currently blocked by another agent or thing. |
Submit the pattern of things that are attached to the agent to complete a task.
| No | Parameter | Meaning |
|---|---|---|
| 0 | task | The name of an active task. |
| Failure Code | Reason |
|---|---|
| failed_target | No active task could be associated with first parameter. |
| failed | One or more of the requested blocks are missing OR the agent is not on a goal terrain. |
Clears a target cell if the agent has sufficient energy.
- The area is cleared of blocks and obstacles.
- The action consumes a fixed amount of energy.
- Targeted entities may get damaged.
- If the role's maximum clear distance is 1 or less, other entities cannot be damaged.
- The damage depends on the distance between both entities.
- Damage results in loss of energy.
The clear action's success rate depends on an agent's role. I.e. there may be an additional probability to receive
the failed_random result.
| No | Parameter | Meaning |
|---|---|---|
| 0/1 | target | The x/y coordinates of the target position. |
| Failure Code | Reason |
|---|---|
| failed_parameter | No valid integer coordinates given. |
| failed_target | Target location is not within the agent's vision radius or outside the grid. |
| failed_resources | The agent's energy is too low. |
| failed_location | The agent is targeting a cell out of reach. |
| failed_random | The action failed due to random failure or the additional probability to fail. |
Config: match.clearSteps- number of action required for a successful clearConfig: match.clearEnergyCost- energy cost for a clear action (subtracted when the clear actually resolves)
Adopts a role if the agent is in a role zone. If adopt is a keyword in your agent platform, you can use adapt instead.
| No | Parameter | Meaning |
|---|---|---|
| 0 | role | The name of the role to adopt. |
| Failure Code | Reason |
|---|---|
| failed_parameter | No parameter or parameter is not a valid role name. |
| failed_location | Agent is not in a role zone. |
Localises or gathers information about a target. Moving targets are harder to survey.
| No | Parameter | Meaning |
|---|---|---|
| 0 | target | The target type. One of "dispenser", "goal", "role" |
In this case, the agent will receive a percept with the distance to the nearest dispenser, goal zone or role zone before the next step.
| Failure Code | Reason |
|---|---|
| failed_parameter | No target parameter or target is not valid. |
| failed_target | No instance of the target found. |
The action can also be used with position parameters:
| No | Parameter | |
|---|---|---|
| 0/1 | target | The x/y coordinates of the target. |
In this case, the agent will receive information about the agent (name, role and energy) at the given location.
| Failure Code | Reason |
|---|---|
| failed_parameter | Parameters are not coordinates or too many parameters given. |
| failed_location | The location is outside the agent's vision. |
| failed_target | There is no entity at the given location. It might have moved away before. |
All actions can also have the following failure codes:
| Failure Code | Reason |
|---|---|
| failed_random | The action failed randomly. |
| failed_status | The agent is deactivated. |
| failed_role | The agent's current role does not permit the action. |
| unknown_action | The action is not part of the game. |
Percepts are sent by the server as JSON files and contain information about the current simulation. Initital percepts (sent via SIM-START messages) contain static information while other percepts (sent via REQUEST-ACTION messages) contain information about the current simulation state.
The complete JSON format is discussed in protocol.md.
This percept contains information that does not change during the whole simulation. As mentioned in the protocol description, everything is contained in a simulation element.
Complete Example (with bogus values):
{
"type": "sim-start",
"content": {
"time": 1556638383203,
"percept": {
"name": "agentA1",
"team": "A",
"teamSize": 15,
"steps": 700,
"roles": [
{
"name": "SampleRole",
"vision": 5,
"actions": ["move", "attach"],
"speed": [2,1,0],
"clear": {
"chance": 0.5,
"maxDistance": 1
}
},
{"..." : "..."}
]
}
}
}- name: the agent's name
- team: the name of the agent's team
- teamSize: number of agents in the agent's team in the current round
- steps: the sim's total number of steps
- roles: all roles in the simulation
- name: name of the role
- vision: vision range
- actions: actions available to the role
- speed: the different speeds the agent can move at with things attached
- e.g. for [2,1,0], the agent can move 2 cells with no things attached, 1 cell with one thing attached and 0 cells (i.e. not at all) with two or more things attached.
- clear: properties of the clear action
- chance: the probability of the action to succeed (between 0 and 1)
- maxDistance: the maximum range of the action (if 1, entities cannot be damaged)
This percept contains information about the simulation state at the beginning of each step.
Agents perceive the state of a cell depending on their vision. E.g. if they have a vision of 5, they can sense all cells that are up to 5 steps away.
Example (complete request-action message):
{
"type": "request-action",
"content": {
"id": 1,
"time": 1556636930397,
"deadline": 1556636934400,
"step" : 1,
"percept": {
"score": 0,
"lastAction": "move",
"lastActionResult": "success",
"lastActionParams": ["n"],
"energy": 277,
"deactivated": false,
"role": "SampleRole",
"things": [
{
"x": 0,
"y": 0,
"details": "",
"type": "entity"
},
{
"x": 0,
"y": -5,
"details": "",
"type": "obstacle"
},
{
"x": 2,
"y": -1,
"details": "b1",
"type": "block"
},
{
"x": 2,
"y": -1,
"type": "marker",
"details" : "clear"
}
],
"goalZones": [[1,1],[1,2],[4,0]],
"roleZones": [[0,4]],
"events": [
],
"tasks": [
{
"name": "task2",
"deadline": 188,
"reward" : 44,
"requirements": [
{
"x": 1,
"y": 1,
"details": "",
"type": "b0"
},
{
"x": 0,
"y": 1,
"details": "",
"type": "b1"
},
{
"x": 0,
"y": 2,
"details": "",
"type": "b1"
}
]
}
],
"norms": [
{
"name": "n1",
"start": 1,
"until" : 100,
"level" : "individual",
"requirements": [
{
"type": "block",
"name": "any",
"quantity": 1
}
],
"punishment" : 15
}
],
"violations": ["n1"],
"attached": [[2,-1]]
}
}
}(Note: as this is a JSONObject, the order of keys is not guaranteed.)
- score: the current team score
- lastAction: the last action submitted by the agent
- lastActionResult: the result of that action
- lastActionParams: the parameters of that action
- energy: the agent's current energy level
- deactivated: whether the agent is deactivated
- things: things in the simulation visible to the agent
- x/y: position of the thing relative to the agent
- type: the type of the thing (entity, block, dispenser, marker,...)
- details: details about the thing
- for blocks and dispensers: the block type
- for entities: the team
- for obstacles: empty
- for markers: the type of marker (i.e. clear)
- clear: the cell is about to be cleared
- ci: "clear_immediate" - a clear event will clear the cell in 2 steps or less
- cp: "clear_perimeter" - the cell is in the perimeter of a clear event (i.e. new obstacles may be generated there as part of the event)
- goalZones: an array of positions, each of which is part of a goal zone
- roleZones: an array of positions, each of which is part of a role zone
- events: an array of incidents during the previous step; each event has a type and additional info. (These events do not include the map events, like e.g. clear events.)
- type: one of ["surveyed", "hit"]
- if surveyed:
- target: one of ["goal", "role", "agent", "dispenser"]
- if role, goal, or dispenser:
- distance: distance to the nearest instance of the surveyed type
- if agent:
- name: name of the agent
- role: current role of the agent
- energy: current energy of the agent
- if role, goal, or dispenser:
- target: one of ["goal", "role", "agent", "dispenser"]
- if hit:
- origin: the position where the damage came from (might be off if the agent moved during the previous step)
- if surveyed:
- type: one of ["surveyed", "hit"]
- tasks: a task that is currently active
- name: the task's identifier
- start: the first step during which the task can be completed
- reward: the score points rewarded for completing the job
- requirements: the relative positions in which blocks have to be attached to the agent (the agent being (0,0))
- x/y: the relative position of the required block
- type: the type of the required block
- details: currently not used
- norms: a norm that is currently approved
- name: the norm's identifier
- start: the step in which a norm becomes active
- until: the step in which a norm becomes inactive
- level: one of ["individual", "team"]
- requirements: what the norm regulates (see each norm subject)
- type: one of ["block", "role"]
- name: one of ["any", ASingleRole], where
ASingleRoleis one of the available roles, e.g., the role constructor - quantity: an integer representing the maximum number that can be carried/adopted
- violations: a list of norms an agent is violating at the current step
- attached: an array of positions - each position represents a thing that is (directly or indirectly) attached to an entity
Each simulation configuration is one object in the match array.
Example:
{
"id": "2022-SampleSimulation",
"steps": 800,
"randomSeed": 17,
"randomFail": 1,
"entities" : [
{"standard": 15}
],
"clusterBounds" : [1,3],
"roles" : [
{
"name": "worker",
"vision": 5,
"actions": ["skip", "move", "rotate", "adopt", "request", "attach", "detach", "connect", "disconnect", "submit"],
"speed": [1, 1, 0]
},
{
"..." : "..."
}
],
"clearEnergyCost" : 2,
"deactivatedDuration" : 10,
"maxEnergy" : 100,
"refreshEnergy" : 50,
"stepRecharge" : 1,
"clearDamage" : [32, 16, 8, 4, 2, 1],
"attachLimit" : 10,
"grid" : {
"height" : 50,
"width" : 50,
"file" : "conf/maps/test40x40.bmp",
"instructions": [
["cave", 0.45, 10, 5, 4],
["line-border", 1],
["ragged-border", 3]
],
"goals": {
"number" : 3,
"size" : [1,3],
"moveProbability": 0.1
},
"roleZones" : {
"number" : 5,
"size" : [3, 5]
}
},
"blockTypes" : [3, 3],
"dispensers" : [5, 10],
"tasks" : {
"size" : [1, 4],
"concurrent" : 2,
"iterations" : [5, 10],
"maxDuration" : [100, 200]
},
"events" : {
"chance" : 15,
"radius" : [3, 5],
"warning" : 5,
"create" : [-3, 1],
"perimeter" : 2
},
"regulation" : {
"simultaneous" : 1,
"chance": 15,
"subjects" : [
{
"name" : "Carry",
"announcement" : [10, 20],
"duration" : [100, 200],
"punishment": [10, 20],
"weight": 15,
"optional": {
"quantity": [1,1]
}
},
{
"...": "..."
}
]
},
"setup" : "conf/setup/test.txt"
}For each simulation, the following parameters may be specified:
- id: a name for the simulation; e.g. used in replays together with the starting time
- steps: the number of steps the simulation will take
- randomSeed: the random seed that is used for map generation and action execution
- randomFail: the probability for any action to fail (in %)
- entities: the number of entities (i.e. agents) per type
- clusterBounds: min./max. number of agents starting near each other
- roles: (see below the list for more information)
- name: .
- vision: max. distance the agent can perceive at
- actions: all actions the role is allowed to use
- speed: the different speeds the agent can move at with things attached
- e.g. for [2,1,0], the agent can move 2 cells with no things attached, 1 cell with one thing attached and 0 cells (i.e. not at all) with two or more things attached.
- clear: properties of the clear action
- chance: the probability of the action to succeed (between 0 and 1)
- maxDistance: the maximum range of the action (if 1, entities cannot be damaged)
- clearEnergyCost: how much an effective clear action costs
- deactivatedDuration: for how many steps an agent remains disabled
- maxEnergy: an agent's initial and maximum energy level
- refreshEnergy: how much energy an agent is restored with after a deactivation period
- stepRecharge: how much energy each agent recharges per step
- clearDamage : similar to speed, the value at index i determines the damage a target at distance i receives (e.g. the value at index 0 would be self-inflicted damage, the value at index 1 dealt to a target directly adjacent to the agent etc.). If a distance longer than the list is required, the last value of the list is used. E.g. the list [7] would imply any target receives 7 damage regardless of distance.
- attachLimit: the maximum number of things that can be attached to each other
- blockTypes: upper and lower bounds for the number of block types
- dispensers: upper and lower bounds for the number of dispensers per block type
- grid:
- height/width: dimensions of the environment
- file: a bitmap file describing the map layout (see examples for more information)
- instructions: an arbitrary number of map generation steps
- cave: generates a cave like structure using a cellular automaton
- 1st parameter: chance for a cell to start as an obstacle
- 2nd parameter: number of iterations
- 3rd parameter: min. number of obstacle neighbours for an empty cell to become an obstacle
- 4th parameter: min. number of obstacle neighbours for an obstacle to remain an obstacle
- line-border: creates a straight line of obstacles around the map
- 1st parameter: width of the line
- ragged-border: creates an irregular border around the map
- 1st parameter: initial (and average) width of the border
- cave: generates a cave like structure using a cellular automaton
- goals:
- number: number of goal areas
- size: bounds for goal area radius
- moveProbability: probability (0-1) for a goal zone to move after a task has been submitted inside
- roleZones:
- number: how many role zones to place
- size: bounds for how big each role zone can be
- tasks:
- size: bounds for the size of a tasks (i.e. number of blocks)
- maxDuration: bounds for a task's (maximum) duration (i.e. number of steps)
- concurrent: how many tasks should exist at any given time
- iterations: bounds for often a task can be submitted before it is replaced
- regulation: see Norms
- events:
- chance: chance to generate an event in any step (0-100)
- radius: bounds for the event radius
- warning: number of steps the event area is marked before the event occurs
- create: bounds for how many additional obstacles an event can create (besides those that were removed)
- perimeter: an additional radius where new obstacles may be created (added to the event's radius)
- setup: a file describing additional steps to be performed before the simulation starts
- might be useful for testing & debugging
- see examples for more information
Currently, there is only one standard agent role.
Roles: Only the first role has to be configured with all values. This role will be the default role. If some value for another role is not set, the value/s of the default role will be used. Each role also gets all actions of the default role.
Currently, no special scenario commands are available. You may use a simulation setup file instead.