DOCSEARCHbyAlgolia
Submit Docs

Cross Language Soccer Framework

website·Indexed 30 days ago

https://clsframework.github.io

An RPC framework designed for the RoboCup Soccer Simulation 2D, supporting gRPC and Thrift to enable the development of Playmaker servers in multiple languages. The framework provides protobuf definitions (Version 1.9), base code samples for Go and Python, and integration with the Soccer Simulation Proxy.

Tokens
31.8K
Snippets
119
Records
187
Agent score
74%

What's inside CLSFramework

  1. Overview of the Soccer Simulation Proxy workflow

    The Soccer Simulation Proxy allows developers to create soccer simulation teams in any language supported by gRPC or Thrift (e.g., Python, C#, Java, Go, Node.js) instead of being limited to C++. It acts as a bridge between the game server (rcssserver) and the team's AI logic (Playmaker-Server).

  2. Overview of SoccerSimulationProxy for RoboCup 2D

    SoccerSimulationProxy enables the development of RoboCup Soccer Simulation 2D agents in any language supported by gRPC (e.g., Python, C#, Node.js, Go, Java). It removes the requirement to program exclusively in C++ by leveraging Helios-Base features. The architecture requires three components to run a game: 1. rcssserver (hosts the game), 2. SoccerSimulationProxy (connects to the server and forwards data), and 3. A gRPC server (e.g., Playmaker-Server) that implements the logic and sends actions back to the proxy.

  3. Overview of the Cross Language Soccer Framework (CLSFramework)

    The CLSFramework enhances flexibility and interoperability for RoboCup Soccer Simulation 2D (SS2D) by allowing agents to be developed in different programming languages. It consists of two primary components:

    1. Soccer Simulation Proxy: An extended version of the Helios base. It handles communication with the RoboCup Soccer Simulation Server and SoccerWindow2, denoises observations, creates models, and forwards this information to a PlayMaker Server. It also receives high-level/low-level actions from the PlayMaker Server to execute in the simulation.
    2. PlayMaker Server: A decision-making server that receives processed information from the proxy and selects the appropriate actions to send back. Because it communicates via gRPC, it can be implemented in any language supported by gRPC (e.g., C#, Python, JavaScript).

  4. Overview of the Cross Language Soccer Framework (CLSFramework)

    The Cross Language Soccer Framework (CLSFramework) enhances the flexibility of RoboCup Soccer Simulation 2D (SS2D) by decoupling the simulation interface from the decision-making logic. It uses a proxy-server architecture to allow teams to implement their strategy in any language supported by gRPC, avoiding the need to rewrite complex base code (like Helios) for every target language.

    Architecture Flow:

    1. Soccer Simulation Proxy: An extended version of the Helios base code. It handles the low-level communication with the RoboCup Soccer Simulation Server, denoises data, and creates world models.
    2. gRPC Communication: The Proxy serializes game state data (WorldModel, Server/Player Parameters) into gRPC messages and sends them to the PlayMaker Server.
    3. PlayMaker Server: Receives the game state, makes strategic decisions, and sends high-level actions back to the Proxy via gRPC.
    4. Execution: The Proxy deserializes these actions back into Helios base actions and executes them in the simulation.

  5. Overview of RoboCup 2D Simulated Soccer League

    The RoboCup 2D Simulated Soccer League is the oldest of the RoboCup Soccer Simulation Leagues, featuring computer-simulated soccer matches as its primary competition event.

  6. Overview of Cross Language Soccer Framework (CLSFramework)

    The Cross Language Soccer Framework (CLSFramework) enables the development of RoboCup Soccer Simulation 2D (SS2D) agents in various programming languages. It achieves this by introducing a 'Soccer Simulation Proxy' (an extended version of the Helios base) that acts as an intermediary. The Proxy handles communication with the RoboCup Soccer Simulation Server and SoccerWindow2, while delegating high-level decision-making to a 'PlayMaker Server'. This allows developers to use languages with strong AI/ML libraries (like Python) without needing to implement the complex C++ base code required for direct simulation interaction.

  7. Overview of the Playmaker server architecture

    The Playmaker server is used to receive the state of the RCSSServer from an agent and respond with an action. It works in conjunction with the SoccerSimulationProxy (Proxy base), which acts as an intermediate connection. In each game cycle, the Proxy base receives observations from the RCSSServer and sends them to the Playmaker server as a WorldModel (defined via protobuf). The Playmaker server then sends the resulting action back to the Proxy base, which forwards it to the RCSSServer.

  8. Overview of the Cross Language Soccer Framework (CLSF)

    The Cross Language Soccer Framework (CLSF) enhances the flexibility and interoperability of RoboCup Soccer Simulation 2D (SS2D). It decouples the simulation interface from the decision-making logic by using a proxy-server architecture. The Soccer Simulation Proxy (an extended Helios base) sends game state information to a PlayMaker Server, which then returns high-level actions to be executed in the simulation. This allows developers to implement the decision-making logic in any language supported by the chosen RPC framework (e.g., C#, Python, JavaScript).

  9. PY2D Architecture Overview

    PY2D solves the performance limitations of Python in the RoboCup 2D simulation by splitting the system into two segments: a C++ proxy for high-performance data processing (creating the World Model/state) and a Python server for high-level planning. The proxy communicates the state to the Python server using gRPC.

  11. Choose a sample Playmaker server for RoboCup Soccer 2D

    Playmaker servers act as the decision-making entities that control agents within the RoboCup Soccer 2D simulation environment. Depending on your preferred language and communication protocol, you can use the following official sample implementations:

  12. Understand Low-Level vs High-Level Agent Actions

    Agent actions are divided into two categories:

    1. Low-Level Actions: Direct commands received by the RCSSServer. These are basic movements and interactions (e.g., Dash, Turn) that require the developer to perform precise calculations to achieve a goal.
    2. High-Level Actions: Abstractions developed in helios-base and supported by the Proxy base. These allow developers to focus on strategy by providing complex behaviors (e.g., Body_GoToPoint) that automatically calculate and execute the necessary low-level actions.