Show page

Differences

This shows you the differences between two versions of the page.

--- mps:proiect [2024/10/12 12:19]
mihai_lucian.voncila
+++ mps:proiect [2024/11/22 17:27] (current)
giorgiana.vlasceanu [Game Mechanics]
@@ Line 20: / Line 20: @@
     *Tower tile: The player can see in an area of 7x7 around this tile (X-RAY points can still be used)
     *Traps, which can be seen at a max of 2 steps away from them, and are of multiple kind, with a number n assigned to them:
+      *traps are not disabled when activated by walking over them
       *movement decrease: decreases the maximum number of steps you can send to the server in the next turn by n
       *rewind: the players last n moves are undone
@@ Line 25: / Line 26: @@
       *pushback: the player is forced backwards based on the direction of their movement for n steps
     *Portals: They work in pairs and connect one point of the maze to another.
       *Each pair has a specific id to represent a portal
+      *To activate a portal the agent must send a command "P" while on top of one
     *Consumables:
       *X-RAY point increments
@@ Line 34: / Line 36: @@
   *The maze generator must function procedurally, creating mazes with a single entrance and a single exit.
   *The entrance and exit of the maze can be placed anywhere in the maze, not necessarily on the borders.
+  *In order to have intricate possible solutitions the shortest possible walkable path from the entrance to the exit must cover at least 50% of the total area covered by paths and elements placed on path tiles
   *The minimum rectangular path from the entrance to the exit must cover at least 50% of the total rectangular area of the maze.
   *Teams will choose the horizontal and vertical dimensions of each generated maze within specified maximum allowable ranges.
-  *The maze should be able to be generated in one of three ways:
+  *The maze should be able to be generated in one of the following ways:
     *completely random, based on a fixed seed, which may or may not be provided, and a set threshold that represents the maximum of special tiles that can be generated of each type.
     *semi-random, based on a fixed seed and a set number for each special tile that can be generated.
@@ Line 53: / Line 56: @@
   *32 - fog tile
   *224 - tower tile
+  *90 - reserved value for generic trap tiles (this is not used in generation, but will be sent to the agents during solve)
   *96-100 - trap movement tile with n = [1,5]
   *101-105 - trap rewind tile with n = [1,5]
@@ Line 62: / Line 66: @@
 ==== Server ====
-Each request to the server is done by sending a JSON with the following format:
+The client, represented by an agent strategy, and the server will communicate with each other through a series of JSON commands.
+The first time a client connects to a server it gets assigned a UUID, thus the server will distinguish between a new connection and a reconnection attempt based on the UUID.
+The first connection from an agent will always be an empty JSON, whereas every recconection will be a JSON containing the UUID, in the following format:
+  {
+  "UUID": ""
+  }
+<note important>
+In order to simplify the problem, the server can work in a friendly mode where it communicates to an agent its initial coordinates in the maze and the maximum maze size: width, height, alongside the 5x5 tiles it sees initially.
+Thus, the first JSON request back from the server should be in the following format:
+  {
+  "UUID": "",
+  "x [optional]": "",
+  "y [optional]": "",
+  "width [optional]": "",
+  "height [optional]": "",
+  "view": "string of the matrix representation of the visible area around the agent"
+  "moves": "total number of moves/commands available for the agent in the first turn"
+  }
+</note>
+In a normal turn the agent sends a JSON to the server in the following format:
 {input: "string of commands up to length 10"}
-The server will output back a JSON with the following format:
-  "command1": {
+The server will output back a JSON with the following format:
+  {
+  "command_1": {
     "name": "name of command, ex: "N"",
     "successful": "0|1",
@@ Line 72: / Line 99: @@
             ex for 3x3: "[0, 255, 255; 0, 255, 0; 0, 255, 0]"
   },
-  "command2": {
+  "command_2": {
     "name": "",
     "successful": "",
@@ Line 78: / Line 105: @@
   },
   ...
-  "command10": {
+  "command_N": {
     "name":"",
     "successful": "",
     "view": ""
+  },
+  "moves": "total number of available moves for the next turn"
   }
+In the case of a friendly solve, the server will always output the value of a trap if it's inside the agent's visible area. However, in the case of an unfriendly solve, traps are only shown if the agent is 1 tile away from them and their type is hidden using the value of 90.
+Once an agent solves a maze, or the server decides the agent is taking too long so it gets timed out, the server will send a JSON with the following format:
+  {
+  "end": "0|1, based on if the agent solved the maze or not"
+  }
+Following a solve, the server can test the agents on a new maze, for this it sends a request in the following format:
+  {
+  "x [optional]": "",
+  "y [optional]": "",
+  "width [optional]": "",
+  "height [optional]": "",
+  "view": "string of the matrix representation of the visible area around the agent"
+  "moves": "total number of moves/commands available for the agent in the first turn"
+  }
 The server can store generated mazes as images and output them back on request.
+<note important>
+In the case where multiple agents are on the same server, they don't interact with one other, so that each agent has a fair chance at solving the maze. For this reason, every trap triggered by an agent will only affect that specific agent, so the server needs to keep track of which agent triggered which trap.
+</note>
+==== Agents ====
+An agent can work in one of two modes:
+  *real time: it sends the move commands to the server, receives back the success fail results and immediately follows with the next list of commands
+  *await for input: sends the list of commands, receives the results of the execution and awaits for user input before sending the next list of commands (this is done client side, not server side)
+Each agents performance is measured in one of three ways:
+  *Least time taken to solve the maze
+  *Least number of turns taken to solve the maze
+  *Least number of moves taken to solve the maze
+For the real-time mode the agents will have a maximum time allotted before sending each command. If the allotted time expires, the agent is timed out and disqualified, and the maze is considered unsolved. The maximum time can be set before each run, or be preset depending on the maze difficulty.
+<note important>Each AI agents behaviour must be unique, avoid creating different agents that have only a minor part of their strategy modified.</note>
 ==== Viewer ====
@@ Line 97: / Line 159: @@
   *Traps should have their value n on top of them if possible.
   *The walked path should be represented by a solid line, and the planned moves of the agent by a dashed line.
+  *The viewer can put the server into an await for input mode, where it doesn't output back an agents results for a move till a button is pressed in the viewer.
-==== Agents ====
+==== Team collaboration ====
-An agent can work in one of two modes:
+After the initial phase of developing the project:
-  *real time: it sends the move commands to the server, receives back the success fail results and immediately follows with the next list of commands
-  *await for input: sends the list of commands, receives the results of the execution and awaits for user input before sending the next list of commands
-Each agents performance is measured in one of three ways:
-  *Least time taken to solve the maze
-  *Least number of turns taken to solve the maze
-  *Least number of moves taken to solve the maze
-For the real-time mode the agents will have a maximum time allotted before sending each command. If the allotted time expires, the agent is timed out and disqualified, and the maze is considered unsolved. The maximum time can be set before each run, or be preset depending on the maze difficulty.
-<note important>Each AI agents behaviour must be unique, avoid creating different agents that have only a minor part of their strategy modified.</note>
-==== Team collaboration ====
-After the initial phase of development the project
 For a successful collaboration, the teams should consider the following:
-  *collaborations will happens between teams in each lab
+  *collaborations will happen between teams in each lab
   *meetings will happen between 2 members of each team
   *each team can test each other's agents and offer feedback and suggestions
-Alongside the normal team meetings, teams will meet between themselves with a limited number of persons to
-collaboration happens between teams in each lab
-meetings between 2 members of each team (potentially project manager/team lead + one other person)
-each team can test each other’s agents and offer feedback and improvements
 <note warning>Teams still need to develop individual solutions. They are allowed to implement and test the same strategies, but each team needs to implement that strategy in their own code.</note>
@@ Line 187: / Line 233: @@
     - Update the viewer/server so multiple agents can run at once on the same maze.
     - Fix any potential issues in the code.
-</hidden>
+</note>

Resurse

Laboratoare

Proiect

Proiect

mps/proiect.1728724742.txt.gz · Last modified: 2024/10/12 12:19 by mihai_lucian.voncila

Show page Old revisions

Media Manager Back to top