Skip to main content

Overview

Server messages are JSON objects sent from the MARL WebSocket server to your client application. These messages provide real-time updates about agents, simulation state changes, and system events. All messages follow a consistent format with type and payload fields.

Message Format

Message Types

add_agent

Sent individually for each agent when the client requests initial agents or when new agents are dynamically added to the simulation. Direction: Server → Client (to requesting client) Payload:
Example Handler:
Notes:
  • path_coords is null for pedestrians (they don’t follow road networks)
  • Elevation data is included for realistic 3D positioning
  • velocity can be used to calculate agent orientation
  • attributes field reserved for future customization

initial_population_complete

Sent after all initial agents have been generated and sent via individual add_agent messages. Direction: Server → Client (to requesting client) Payload:
Example Handler:
Use Cases:
  • Hide loading indicators
  • Enable user interface controls
  • Begin simulation updates
  • Initialize performance monitoring

new_path

Sent in response to a successful request_new_path message from the client. Direction: Server → Client (to requesting client) Payload:
Example Handler:
Notes:
  • Only sent if path generation succeeds
  • path_coords may be null for pedestrians
  • Includes current fleeing status (may have changed due to stimulus)
  • Path includes elevation data for each waypoint

update_flee_status

Broadcast to all connected clients when one or more agents’ fleeing status changes due to a stimulus event. Direction: Server → All Clients (broadcast) Payload:
Example Handler:
Behavior Changes:
  • Fleeing Agents: Move faster, may ignore normal pathfinding
  • Normal Agents: Resume regular behavior patterns
  • Visual Indicators: Color changes, animations, effects

ping

Sent periodically by the server to maintain WebSocket connection and detect unresponsive clients. Direction: Server → Client Payload: null or empty object
Example Handler:
Notes:
  • Sent every 30 seconds by default
  • Used for connection keep-alive
  • No response required from client
  • Can be used to detect connection issues

error

Sent when the server encounters an error processing a client request. Direction: Server → Client (to requesting client) Payload:
Example Handler:
Common Error Scenarios:
  • Invalid coordinates in request_initial_agents
  • Agent not found in request_new_path
  • Simulation initialization failures
  • Network or processing errors

Advanced Message Handling

Message Router

Agent State Management

Performance Monitoring

Error Recovery Patterns

Graceful Degradation

Best Practices

  1. Handle All Message Types: Implement handlers for all message types you might receive
  2. Validate Message Structure: Check for required fields before processing
  3. Error Recovery: Implement graceful degradation for connection issues
  4. Performance Monitoring: Track message frequency and processing time
  5. State Synchronization: Keep local state in sync with server updates
  6. Memory Management: Clean up agent references when no longer needed

Next Steps