This semester's project is the game of PANGO. The game consists of a variable maze (constructed from square blocks), with a player (possibly more than one), and several monsters. Motion is in either the vertical or horizontal directions, for both monsters and players. In addition, a player can execute a "kick" action. This action causes a free maze block to move in the direction of the kick until it hits something. A monster hit by a block dies. A block that cannot move at all breaks and disappears. Optionally, kicking a wall "stuns" all monsters standing next to that wall (a stunned monster is killed when a player reaches its location). A player that is hit by a monster dies.
Other items in the game are "diamonds", which are indestructable blocks that have to be placed adjacent to each other on a single row or column in order to collect a bonus. Optionally, the maze may contain several treasures to be collected by the agent (graphically depicted as various fruits).
In the discrete-time version, each move is by exactly one unit, and the motion of a kicked block is instantaneous. Items are assumed to hit each other if execution of either motion results in a collision assuming the other object is stationary.
Each part will be a complete program that communicated 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 agen programs. It then sends them the maze specification. Then, the server repeatedly waits for actions from all agent, updates the environment and scores, displays changes, and sends updates to all agents.
Interaction with the server is the same as for player agents.
Again, computation of action is the main issue - this agent should
target survival, as well as killing player agents (perhaps using
monster collaboration). Some AI techniques to be employed are:
In order to achieve a clean interface, communication protocols and data formats are described below. The standard has now been frozen. The only changes permissible are additional of specially designated OPTIONAL items. Programs not supporting the optional items must IGNORE them.
All programs, upon startup, read a configuration file (specified by a command-line parameter), providing the server port number, and a maze file. Monster and player programs (collectively called "clients" henceforth) then connect to that port via a stream-type socket. Once connected, they send a message containing ID and other information to the server. The server accepts connections from all clients, and begins the run by sending data in standard format, detailing the status of the game (see data formats) to all clients. Repeatedly, clients compute and generate the moves and send them to the server/simulator, and the simulator computes the next state and sends data to the clients. For simplicity, there are only two data formats: server to client, and client to server, with unnecessary items omitted. For example code containing basic ASCII client-server communication, see ~shimony/public/client_server_example.
The state of an agent include its location (X, Y), direction (one of Up, Down, Left, Right), and status (normal, dead, stunned, restart, restart_game, pending). Actions include motion (U, D, L, R, None), kicking (U, D, L, R, None), and direction changes (U, D, L, R). Agents programs that do not need to use some of the actions (e.g. kicking for monsters) are free to ignore them.
Status is as follows: restart - re-birth of agent, pending - agent not yet active, restart_game - restart all of the game from the initial position (all agents). The latter is tacitly agreed upon not to be employed except by ONE of the participating agents.
Back to BGU Math & CS HomePage