Regardless of the programming language you adopt, your bot must implement the following methods.

All methods receive 2 parameters, and the goalkeeper method receives an extra param.

The first parameter is the OrderSet. That is the object where your bot should set the orders it wants to send to the server in the current turn.

The second parameter is the GameSnapshot. That brings the current game state and its elements. Players positions, speed, direction, ball position, score, etc...

The goalkeeper receives a third param that indicates the goalkeeper state (holding the ball, defending, disputing, or supporting).

• Python
• JavaScript
• Go

class Bot:
    

    #on_disputing is called when no one has the ball possession
    def on_disputing(self, order_set: lugo.OrderSet, snapshot: lugo.GameSnapshot) -> lugo.OrderSet:
        pass

    #on_defending is called when an opponent player has the ball possession
    def on_defending(self, order_set: lugo.OrderSet, snapshot: lugo.GameSnapshot) -> lugo.OrderSet:
        pass

    #on_holding is called when this bot has the ball possession
    def on_holding(self, order_set: lugo.OrderSet, snapshot: lugo.GameSnapshot) -> lugo.OrderSet:
        pass

    #on_supporting is called when a teammate player has the ball possession
    def on_supporting(self, order_set: lugo.OrderSet, snapshot: lugo.GameSnapshot) -> lugo.OrderSet:
        pass

    #This method is called on every turn, and the player state is passed at the last parameter.
    def as_goalkeeper(self, order_set: lugo.OrderSet, snapshot: lugo.GameSnapshot, state: PLAYER_STATE) -> lugo.OrderSet:
        pass

export interface Bot {
{

    /**
    * OnDisputing is called when no one has the ball possession
    */
    onDisputing: (orderSet: OrderSet, snapshot: GameSnapshot) => OrderSet | null

    /**
    * OnDefending is called when an opponent player has the ball possession
    */
    onDefending: (orderSet: OrderSet, snapshot: GameSnapshot) => OrderSet | null

    /**
    * OnHolding is called when this bot has the ball possession
    */
    onHolding: (orderSet: OrderSet, snapshot: GameSnapshot) => OrderSet | null


    /**
    * OnSupporting is called when a teammate player has the ball possession
    */
    onSupporting: (orderSet: OrderSet, snapshot: GameSnapshot) => OrderSet | null

    /**
    * AsGoalkeeper is only called when this bot is the goalkeeper (number 1). This method is called on every turn,
    * and the player state is passed at the last parameter.
    */
    asGoalkeeper: (orderSet: OrderSet, snapshot: GameSnapshot, state: PLAYER_STATE) => OrderSet | null


}

type Bot interface {
    
    // OnDisputing is called when no one has the ball possession
    OnDisputing(ctx context.Context, sender TurnOrdersSender, snapshot *proto.GameSnap

shot) error

    // OnDefending is called when an opponent player has the ball possession
    OnDefending(ctx context.Context, sender TurnOrdersSender, snapshot *proto.GameSnap

shot) error

    // OnHolding is called when this bot has the ball possession
    OnHolding(ctx context.Context, sender TurnOrdersSender, snapshot *proto.GameSnap
        
shot) error

    // OnSupporting is called when a teammate player has the ball possession
    OnSupporting(ctx context.Context, sender TurnOrdersSender, snapshot *proto.GameSnap

shot) error
    // AsGoalkeeper is only called when this bot is the goalkeeper (number 1). This method is called on every turn,
    // and the player state is passed at the last parameter.
    AsGoalkeeper(ctx context.Context, sender TurnOrdersSender, snapshot *proto.GameSnap
        
shot, state PlayerState) error

}

See below and example of the stringified version of a GameSnapshot object.

However, all bot's methods will receive the GameSnapshot as an object based on the programing language you are using.

We strongly do not convert it to JSON since the object is a representation of a gRPC response.

Regardless the programing language you are using, though, there will be a GameSnapshot reader class that implements most part of the common operations you will need (e.g. fetch your team mates, fetch a specific player, etc)

Note that the vectors are normalized and multiplied by 100 (see documentation for further details)

{
    "state": "LISTENING",
    "turn": 47,
    "home_team": {
        "players": [
            {
                "number": 1,
                "position": {
                    "x": 9048,
                    "y": 3245
                },
                velocity": {
                    "direction": {
                        "x": -99.95606441193794,
                        "y": -2.963981659273956
                    },
                    "speed": 100
                },
                "init_position": {
                    "x": 7000,
                    "y": 1875
                }
            },
            {
                "number": 2
                ...
            },
            {
                "number": 3
                ...
            }
        ],
        "name": "Team A",
        "side": "AWAY"
    },
    "away_team": {
        "players": [
             ...
        ],
        "name": "VS Code",
        "side": "AWAY"
    },
    "ball": {
        "position": {
            "x": 9740,
            "y": 5223
        },
        "velocity": {
            "direction": {
                "x": -99.79061148317571,
                "y": -6.467910003539166
            },
            "speed": 100
        },
        "holder": {
            "number": 8,
            "position": {
                "x": 9940,
                "y": 5236
            },
            "velocity": {
                "direction": {
                    "x": -99.79061148317571,
                    "y": -6.467910003539166
                },
                "speed": 100
            },
            "init_position": {
                "x": 7000,
                "y": 4375
            }
        }
    },
    "shot_clock": {
        "remaining_turns": 300
    }
}

You do not need to study the documentation. All client implementations bring the specs in it.

As an example, in the Python client, the IDE will list all game specs from the lugo4py packages:

It only depends on your creativity!

Differently of the ACM International Collegiate Programming Contest questions, in a game like Lugo, there is no expected output, but expected outcome.

That means you may decide to get an outcome (e.g. pass the ball to the safest team mate) that requires knowledge on a particular algorithm, while another programmer may want to get an different outcome (e.g. pass the ball to the most advanced team mate). And the new outcome may require a totally different algorithm.

Therefore, if you are a good ICPC programmer, you will definitly have some good results to find the outcome you want. But if you are not getting good results on ICPC competitions, you still have good chances to find in Lugo a nice place to shine.

It's an Artificial Intelligence game that won't require AI expertise. If you are not familiar with AI, don't worry.

Lugo will be a great place to practice your techniques if you have experience in AI, machine learning or reinforcement learning experience.

But if you have no experience yet, Lugo is a great way to start from scratch on the AI field.

As a matter of fact, the best bots in the raking so far (2023) were developed by junior developers that have no experience with AI algorithms yet.

It has already started!

You may submit your bot whenever you want. Then, you can subscribe your bot to the tournaments and wait for the official games to happen.

Lugo is not a game like racing, mining, searching, etc. Where there is a performance/efficiency/metric to be overcome. No, it's all about strategy

There will always be a way to defeat a bot, but not to defeat all bots. If you don't agree with this statement, prove me wrong. :-)

However, we may reach a point where bots become very mature and the most common strategies are well known. Whenever this happens, matches can end in a draw very often, if not constantly. Then, as most real sports do, we will change the rules to make it more competitive.