FreeOrion

As the AI is becoming more complex, we should give some thought to the layout and interaction of the individual AI modules. Below is the layout which I would suggest. Color-coded status of coding.

FreeOrionAI
- initialisation of AI
- holds AIstate class
- save/loads AIstate
- calls individual AI modules every turn

AIstate
- manages missions: hold [fleetID / (systemID or planetID or fleetID)] pairs
- manages shipRoles: associates design IDs with ship roles
- manages fleetRoles: associates fleet IDs with fleet roles
- stores colonisable planets
- stores empire priorities

The AIstate provides an interface by which the individual AI modules can share information.

- missions: the idea behind missions is that the AI will need to keep track of its fleets and their orders, so that it will not interrupt their orders and so that it can check if a fleet has fulfilled its orders.
The AI recognises different missionTypes that decide which information is actually stored within the mission. The key to access a mission is always a fleetID, the returned value depends on the missionType (exploration: systemID, colonisation: planetID, fleetMerging: fleetID).

- shipRoles: associate a ship design ID with the purpose for which it has been designed. Will enable the AI to create specific fleets. Will be assigned at start of a game as well as when a new ship is designed.

- fleetRoles: associate a fleet ID with the purpose for which it has been formed (which is a missionType). Helps the AI to specifically pick fleets for a certain mission. Will be assigned at start of a game as well as when a new fleet is formed.

FleetUtils
provides helper functions for fleet operations
- splitting fleets
- checking if a fleet has a ship with a certain role
- getting a ship of a certain role from a fleet (for colonisation)
- getting the fleets of an empire
- getting all fleets with a certain role
- extracting fleets without mission
- assessing the role of a ship (later identifying by parts)
- assessing the role of a fleet (currently by most prominent ship type; fleets with colony ships should always be colony fleets)

PrioritiesAI / DemandAI [The Silent One]
- calculates priorities of an empire
- should calculate priorities, eg. Food, Minerals, Production, Research, Money, Exploration, Colonyships, Military, Defense, Shipyards;
- different categories of priorities (resources, production, research)?

ExplorationAI
ColonisationAI
ResearchAI [m_k]
ProductionAI [The Silent One] (~50%)
ResourceManagementAI
WarfareAI
DiplomacyAI
DesignAI
AIEnumerators (currently in AIgamestate module)
- will hold AI enumerators

So far this looks fine to me. Considering your question marks:

The Silent One wrote:
- stores production queue?
- stores research queue? (also available from foAIInterface)

I think it is better not to store them but instead get them from the interface whenever they are needed (which should only be the case in the corresponding modules anyway), because there is a high possibility that some of the changes made to them through the interface are missed in this stored representation, which will likely lead to incomprehensible errors, while on the other hand I see no benefits from storing them.

The Silent One wrote:
- different categories of priorities (resources, production, research)?

Could be useful but in my opinion this is something which should be done at a later stage. Identifying the actual properties which are of use in most modules (except maybe in the resourceManagementAI where it is obvious) will need some amount of playtesting anyway, so the best way would be to use the same priorities everywhere but to make switching easy, so we should already store the priorities for each AI in a different dictionary and try to hardcode the least amount possible in each module so that we can exchange them easily.

Other things on my mind:
-there should be a section in the gamestateAI where each AI can store any information it needs in later turns, this would make saving easier than including a load/save function in every AI.

-We should probably agree on the order in which the AIs are called. Some are mostly independent, like diplomacy and design, or passive like gamestate or fleet, but for example all AIs which use fleets and missions will be possibly influencing each other.

"GamestateAI" seems il-conceived. What I think you want is an interface that wraps the game state accessing functions provided by foAIInterface. This isn't an "AI", as there's no decision making. But more so, why do you need a wrapper for the gamestate? There's already an interface to it exposed to Python by foAIInterface.

You also shouldn't mix the AI state with the game state. If you want a central storage class or module to keep track of issued orders and AI plans and data, that's not game state; it's AI state. The game state is the empires, ships, planets, systems, techs, etc.

Regarding individual AI modules storing information, you don't need to do anything fancy (like providing a saving and loading interface for them to use). If you've got all your AI modules stored within a container, you can just pickile the whole container as your state string. If you want to separate temporary state information from state information you want to store and retrive when saving / loading, make a separate state information container and pickle that.

You should keep track of ship designs by unique id, not name.

As noted, storing production or research queues is unnecessary when it's available from the gamestate accessors in foAIInterface. You might need to keep track of information about the universe, such as contents of systems, because this information might be unavailable on later turns even if it is known now, once we have a proper visibility system implemented. But you should probably always check for updates from the gamestate accessors.

m_k wrote:there should be a section in the gamestateAI where each AI can store any information it needs in later turns, this would make saving easier than including a load/save function in every AI

Feel free to add any fields you need to the AIstate.

m_k wrote:We should probably agree on the order in which the AIs are called. Some are mostly independent, like diplomacy and design, or passive like gamestate or fleet, but for example all AIs which use fleets and missions will be possibly influencing each other.

I agree that we need to keep an eye on this matter... however, as I conceive the fleet management now, there will be no difference in which order the individual modules will be called. There will be an AI that creates new fleets and assigns them their role, and the individual fleet management AIs like exploration, colonisation, warfare will only pick the fleets they've been assigned (by their role).

Geoff the Medio wrote:If you want a central storage class or module to keep track of issued orders and AI plans and data, that's not game state; it's AI state.

This is what it is supposed to be. We'll call it AIstate then.

Geoff the Medio wrote:Regarding individual AI modules storing information, you don't need to do anything fancy (like providing a saving and loading interface for them to use). If you've got all your AI modules stored within a container, you can just pickile the whole container as your state string. If you want to separate temporary state information from state information you want to store and retrive when saving / loading, make a separate state information container and pickle that.

All the information that should be saved is stored within the AIstate class, so only this class needs to be pickled.

Geoff the Medio wrote:You should keep track of ship designs by unique id, not name.

Ok.

Geoff the Medio wrote:As noted, storing production or research queues is unnecessary when it's available from the gamestate accessors in foAIInterface.

I've removed it. It was more a reminder to myself there may be some information about the queues that we may want to store, but right now, I don't see what it would be.


Also, the term FleetAI is misleading, since it's more helper functions than an actual AI. Maybe it should just be called FleetUtils.