PodballModules

Podball Control Modules - Introduction

The whole thing about Podball is that it is designed to run user provided code for getting the actions of the different pods on the field.

As explained in [PodballGame], the Podball game engine calls code from so called control modules every ENGINE_CTRL_STEP ticks.

The first thing to note and remember is that a control module provides the intelligence for the whole team. (This is different from the 2001 version of Podball, where there was a control function for each pod plus a coach function for team intelligence).

Things to remember:

• A control module provides the artificial intelligence for a whole team.
• There is exactly one instance of a control module per team.

Control modules get all imaginable information about the game state as an input. Especially, control modules get the GAMESETTINGS information, which contains all dimension- and physical constants used by the game engine. Then, for every time step they get the WORLDSTRUCT information which contains all dynamic information like positions, velocities (of all pods and the ball) and information about the state of the game.

For details, see the WORLDSTRUCT struct defined in podball.h
and the GAMEINFO struct defined in podtypes.h

Side note: Don't be scared about the amount of values present in GAMEINFO. Most of the physical constants won't change over time. You may well decide to code a module for the given set of default constants and ignore the values in GAMEINFO entirely. That is, your module doesn't necessarily be able to adapt to different physical constants. Get it running adequately for the default set of constants and it will be fine.

In return, the module has to provide the actions for each pod of the team.

There are only two possible actions:

• Move or
• Shoot (the ball)

Both actions require a vector argument to indicate the direction and amount of acceleration or shooting, respectively.

The convention used is to return a vector with a length between zero and one, to indicate the amount.

• In case of acceleration, a length of one corresponds to the maximum amount of acceleration force, i.e. ACCEL_FORCE as defined in game.info.
• In case of shooting, a length of one corresponds to the maximum amount of shooting force, i.e. SHOOT_FORCE as defined in game.info.

Of course, whenever a module returns a vector with length greater than one, its length is normalized to one.

There are some conventions that are important to know:

• The data of the own team is always given in team[0], that of the opposing team in team[1], regardless of the actual side the team is playing.
• Also, all coordinates of all objects in the WORLDSTRUCT are always presented as if the own team is playing from left to right (in the direction towards increasing x-coordinates), regardless of the actual side the team is playing. This feature is called team- and coordinate-remapping of the engine and is to simplify things for module developers.

Podball modules can be developed for different environments and languages. (Currently, only Windows DLLs are supported but this is hopefully going to change soon).

See the details for the Windows native DLL interface in [PodballModDll].

The technical details of how the interface is presented to the client code in the different environments may vary and are presented on their respective pages. But the overall picture and available data will always be the same.