// iteration tracker
Robots World
Project Checklist
Click any item to mark it as done. Progress is saved in your browser.
0
Completed
0
Total Items
0%
Progress
Design & Documentation
Graded DeliverableFailing to produce design documentation will weigh negatively in project assessment and grading.
- Class diagram containing the most important classesGraded
- Domain diagram characterising domain classes and how they work togetherGraded
- Component diagram for the
clientGraded - Component diagram for the portion of the server that reads and executes commandsGraded
- All diagrams saved to GitLab Wiki
- Key architectural decisions recorded in GitLab Wiki
- Retrospective notes recorded after each iteration
World Specification
- World is a grid — size is NOT hard-coded, read from a configuration file on startup
- World coordinate system: centre is always at
(0,0) - North edge = maximum y, South edge = minimum y, East edge = maximum x, West edge = minimum x
- Standard compass directions: N, S, E, W
- Obstacles are rectangular, positioned by top-left and bottom-right coordinates
- Obstacles cannot overlap each other (but can be adjacent)
- World always has at least one obstacle
- Obstacle types: mountains, lakes, and bottomless pits
- Robots cannot move through mountains or lakes — must go around
- Robot that moves into a bottomless pit is removed from the world permanently
- Robots cannot see through mountains
- Robots CAN see over lakes and bottomless pits (limited only by visibility range)
- Visibility range is configurable (in steps) — controls how far a robot can see in each direction
- Robot field of view is straight lines only — N, S, E, W — no diagonals
- If an obstacle is larger than the visible range, the robot cannot see its full extent
World Console Commands
quit— disconnects all robots and ends the worldrobots— lists all robots in the world including each robot's name and full statedump— displays a representation of the world showing robots, obstacles, and all world contents
Server Configuration File
- World width (in steps)
- World height (in steps)
- Visibility range (in steps)
- Shield repair time (in seconds)
- Weapon reload time (in seconds)
- Maximum shield strength (in hits)
- Obstacle definitions (positions and types) read from config
- Server port read from config or command line (not hard-coded)
Robot Management
- Multiple client connections handled concurrently (each on its own thread)
- Robot randomly positioned in an open space on launch
- Duplicate robot names rejected — error response returned
- World full (no free position) — error response returned
- Robot removed from world when killed (status DEAD)
- Robot removed from world when it falls into a bottomless pit
- Robot deregistered from world when client disconnects
- Robot maximum shield strength capped at world's configured maximum even if robot type exceeds it
- Robot always faces NORTH when launched
- Robot starts with maximum shield strength for its type
- Robot starts with maximum number of shots for its type
- Robot starts in NORMAL operational status
Command: Launch
- Request accepts: robot type name (kind)
- Success response data includes:
position,visibility,reloadtime,repairtime,shieldsmax - Success response state includes full robot state (position, direction NORTH, shields, shots, status NORMAL)
- Error response:
"Too many of you in this world"when name already taken - Error response:
"No more space in this world"when no free position
Commands: Forward / Back / Turn
forward <steps>— moves robot in the direction it is facingback <steps>— moves robot in the opposite direction to facingturn left/turn right— turns robot and updates direction- Movement blocked by mountains, lakes, other robots, and world edges
- Moving into a bottomless pit removes robot from world
- Success response:
message: "Done"+ updated state with new position - Obstructed response:
message: "Obstructed"+ position set to last valid step reached - Turn success response:
message: "Done"+ updated direction in state - Robot cannot move while status is REPAIR or RELOAD
Command: Look
- Looks in all four directions: N, S, E, W
- Returns objects as absolute compass directions (not relative to robot facing)
- Respects world visibility range — cannot see beyond configured steps
- Cannot see through mountains (vision blocked)
- CAN see over lakes and bottomless pits
- Response includes array of objects, each with:
direction,type,distance - Object types supported:
OBSTACLE,ROBOT,EDGE
Command: Fire
- Fires in the direction the robot is currently facing
- Shot travels the robot type's configured distance (in steps)
- Can hit a robot it cannot see (shooting into fog)
- Shooting an obstacle has no effect on the obstacle
- Shot count decremented after each fire
- Cannot fire with 0 shots remaining
- Hit response includes:
message: "Hit",distance,robotname, targetstate, attacker shots remaining - Miss response includes:
message: "Miss", attacker shots remaining - Hit target's shields decremented correctly
- Target killed when hit with 0 shields remaining — removed from world
Command: Reload
- Reloads to maximum number of shots — or not at all (no partial reload)
- Takes world-configured number of seconds regardless of current shot count
- Robot cannot move during reload
- Cannot reload beyond maximum shots for robot type
- Status set to
RELOADduring reload, returns toNORMALafter - Success response:
message: "Done"+ state with statusRELOAD
Command: Repair
- Repairs shields to maximum strength — or not at all (no partial repair)
- Takes world-configured number of seconds regardless of current shield level
- Robot cannot move during repair
- Cannot repair beyond robot type's maximum shield strength
- Status set to
REPAIRduring repair, returns toNORMALafter - Success response:
message: "Done"+ state with statusREPAIR
Command: State
- Returns current robot state:
position,direction,shields,shots,status - No data payload — state only in response
Client Requirements
- Server IP address and port taken from command line arguments — NOT hard-coded
- Connects to server and launches a robot before accepting user commands
launch <make> <name>command supportedforward <steps>command supportedback <steps>command supportedturn left/turn rightcommand supportedlookcommand supportedfirecommand supportedreloadcommand supportedrepaircommand supportedstatecommand supportedorientationcommand — shows which direction the robot is currently facing- Client displays server responses meaningfully to the user
- Client distinguishes between a Response and a Notification on incoming messages
- Client displays push notifications to user (shot, killed, disconnected)
- More than one robot can be launched into the world concurrently
Robot Types (Makes)
- At least one robot type (make) implemented with a name
- Each type has a configured shield strength
- Each type has a configured shot distance
- Each type has a configured number of shots
- Shield strength capped at world maximum if robot type exceeds it
- Shield of 0 means no shield — first hit kills the robot
Protocol — Message Structure
- Request JSON fields:
robot,command,arguments— all mandatory - Command must be lowercase
- Arguments array is empty
[]when command takes no arguments - Response JSON fields:
result,data(mandatory),state(only when result is OK) - State fields:
position[x,y],direction,shields,shots,status - Direction values:
NORTH,SOUTH,EAST,WEST - Status values:
RELOAD,REPAIR,NORMAL,DEAD - Error response for unparseable arguments:
"Could not parse arguments" - Error response for unsupported command:
"Unsupported command" - Client validates input before sending — nothing invalid sent over network
- Server validates independently of client
Code Quality
- Every class and public method has meaningful JavadocGraded
- Consistent indentation throughout the codebase (2 spaces, 4 spaces, or tabs — pick one)
- Java naming conventions: CamelCase classes, camelCase methods and variables
- Single responsibility principle applied to classes and methods
- Comprehensive unit tests for the serverRequired
- Comprehensive unit tests for the clientRequired
- Code must run from shell (not IDE or Maven) for final demoRequired
- Input handling and user-facing output is clear and well-formattedGraded
Team Collaboration
- GitLab Issues board regularly updated with tasksGraded
- All code merged to main via GitLab Pull Requests (not direct pushes)
- All team members have write access to the repository
.lms/exercises.tomlupdated with correctactivity_idand all team member emailsRequired- Iteration 1 showcase completed and demo feedback addressed
- Iteration 2 showcase completed and demo feedback addressed
- Iteration 3 showcase completed and demo feedback addressed
- Final demo poster prepared
- Every team member can explain their own code during demo