Skip to main content

Overview

Client messages are JSON objects sent from your application to the MARL WebSocket server to control and interact with the urban mobility simulation. All messages follow a consistent format with type and payload fields.

Message Format

Message Types

request_initial_agents

Initializes the simulation and requests the first batch of agents. This should be the first message sent after connecting. Direction: Client → Server Payload:
Example:
Server Response:
  • Multiple add_agent messages (one per agent)
  • Final initial_population_complete message
Notes:
  • If coordinates are provided, simulation centers around that location with a 2km radius
  • If coordinates are omitted, uses default San Francisco downtown bounds
  • Generates up to 1,000 agents (configurable)
  • Clears any existing agents before generating new ones

request_new_path

Requests a new destination and path for a specific agent. Typically used when an agent reaches its current goal or needs to be redirected. Direction: Client → Server Payload:
Example:
Server Response:
  • new_path message with updated goal and path data
  • No response if agent not found or path generation fails
Behavior:
  • Vehicles: Finds new random goal node on road network, calculates shortest path
  • Pedestrians: Selects new random goal position within bounds
  • Ensures minimum distance from current position
  • Includes elevation data for each waypoint

set_stimulus

Activates, deactivates, or updates a global stimulus event (e.g., emergency, disaster) that affects agent behavior. Direction: Client → Server Payload:
Examples:
Server Response:
  • update_flee_status messages for affected agents (broadcast to all clients)
Behavior:
  • Agents within flee radius start fleeing behavior
  • Agents outside flee radius return to normal behavior
  • Flee radius is configurable (default: ~500 meters)
  • Only one global stimulus can be active at a time

Advanced Usage Patterns

Sequential Agent Population

Dynamic Path Management

Emergency Scenario Management

Multi-Area Simulation

Error Handling

Message Validation

Connection State Management

Best Practices

  1. Initialize First: Always send request_initial_agents as your first message
  2. Validate Coordinates: Ensure latitude/longitude values are within valid ranges
  3. Handle Failures: Not all request_new_path calls will succeed
  4. Manage State: Track active emergencies and agent states locally
  5. Rate Limiting: Don’t spam path requests for the same agent
  6. Graceful Degradation: Queue messages when connection is lost

Next Steps