This semester's project is a variant of the game of HUNT. The game consists of a maze (constructed from square blocks), with a number of players, each trying to shoot down the other players. Motion is in either the vertical or horizontal directions. We will add a few enhancements to make intelligent planning in the game a bit more challenging, adding features from the DOOM family of games.
The game is a discrete-time game, each move is by exactly one unit, and the action of shooting is instantaneous. In addition, a player has an INVENTORY and may select and use an item from the inventory (items are automatically picked up when a player moves into a square where they are located).
Each player has a HEALTH attribute and an ARMOR attribute, both initially 100. A player hit by a shot is injured by deducting some HEALTH points, depending on ARMOR and on attributes of the weapon used. Probability of a shot hitting depends inversely on distance, and on possible player enhancements. Players operate in an initially unknown environment, and start at a random location in the maze.
A list of items found at some locations in the maze are:
(* Design now final - no changes permitted (modulo serious bugs) *)
Note that these state elements can also be maintained by the agent, but some are initially UNKNOWN to the agent. Health and armor state are sent from server to agent every turn.
Before each move, the server notifies all agents of part of the
agent state, as well as part of the state of the environment, as follows:
A note on designing your agent: although state information is maintained by the simulator, much of that is NOT transmitted to the agent, which should attempt to keep track of them by counting, learning, etc.
The server waits until the current turn message is received from all agents. The actions are then performed "in parallel". All shoot actions occur before all object activation actions, which occur before all move actions. Trap activation actions occur last (when an agent steps onto a trap).
Conflicting actions are still possible - two agents attempt to move into the
same locations. In this case BOTH motions fail, and the agents are notified.
Other items agreed by committee:
The simulation functions and parameters have been finalized as:
Each part will be a complete program that communicates with the others via an agreed-upon interface, in order to create a complete running system. Tasks to be implemented by each part are as follows.
Responsible for coordinating all game actions, simulating the game environment, keeping score, and graphical display of the environment. The server, after reading a configuration file, loads a maze file (specified by the configuration), and waits for contact by all agent programs. The server sends all clients an initialization message, including an agent ID (see below), and then repeatedly waits for actions from all agents, updates the environment and scores, displays changes, and sends updates to all agents. A dead agent is revived at a random location in the map.
In order to achieve a clean interface, communication protocols and data formats appear below.
We will be using reliable socket-streams. Server will wait for a number of clients specified by a command-line parameter. Once the requisite number of clients have connected, the simulator in the server is started and the game begins. A game turn consists of (sepatrate) messages originated by the simulator and sent by the server to all clients. The agent in each client recieves these messages, processes the information and sends back a turn command. After the server collects a message from each client, the simulator processes the messages and a new turn begins. For example code containing basic ASCII client-server communication, see ~shimony/public/client_server_example.
The server is started up first, and creates a PF_INET, SOCK_STREAM type socket. After binding the socket name, it "listen"s for client connects, and accepts as many clients as specified in a command-line parameter. Note that a DUPLICATE socket is created on accept, and the duplicate is used henceforth to communicate with the client (one duplicate created for each client).
Client creats a socket and connects to server socket, and henceforth uses the socket for bidirectional communication.
All communications are in printable ASCII messages.
Every information item is on a null-terminated string, with the last
line (string) of the message consisting of the 2-character
string "#E" (also terminated
by null). Internal fields in messages terminated by space, where necessary,
or non-terminated if length of field is pre-determined. To be on the safe
side, we adopt the following two conventions:
#I agent-id
Agent sends a single item of information - its turn, in the format:
#T turn-specifier optional-item-specifier
The turn specifier is a single character, one of the following:
The optional-item-specifier is a specifier used for the U action, a single character denoting the item to be used.
The simulator must provide an agent with results of actions, what the agent senses, information on its state, and state of the game. The following sequence of message lines will be used. Semicolon always starts a COMMENT field to be ignored by the recepient.
; Start with a line signifying perception - starting with forward direction
#F 1 x ; Enemy number 1 in front, then space, then wall (x)
#L ; Single character specifying environment one space to left
#Rx ; What's on the agent's right (a wall - x)
#l ; What's on the agent forward left (dx = 1, dy = 1)
#r ; What's on the agent forward right (dx = 1, dy = -1)
#H integer ; Health of agent (an actual number instead of "integer"
#A integer ; Armor of agent
#f x ; Action x failed
#T x ; Agent just stepped on trap of type x (one of C T)
#C ; Agent is confused
#K x y ; Agent x killed agent y
#P x ; Picked up item x
#U x ; Just used item x
#e n h a dir ; Status of enemy in front, if any. n is enemy id, h=health,
; a=armor, dir=which way the enemy faces: T=towards agent
; L=facing left (from agent's perspective), R=right, A=away.
#o dx dy n ; Radar on - list element - enemy n at rel. location dx dy
#o dx dy n ; Additional enemies, if any
#M x y ; Optional - when map on, x y are dimensions of map
#a x y ; In map - location of agent
#m xxx xxx ; actual lines of map, as many as necessary
#m x x a x ; actual lines of map, as many as necessary
#E ; Last line of message
Note change: radar info now begins with o instead of r due to conflict wirh r used as forward-right information about environment.
In the message, visible, gathered, or used items are reported according to the
following format:
Back to BGU CS HomePage