AegisBot (Aegis for short) was the default AI for 0 A.D up to alpha-16. It has been replaced by the PetraBot which is derived from Aegis for alpha-17. The latest version of the code can be found here for reference.
It was mostly written by wraitii, and replaced qBot and JuBot. It originated as a merging between qBot and Marilyn (experimental bot by wraitii).
Over time, as new features were added, it superseded qBot until the other AIs were replaced.
Though Aegis is still undergoing several changes, the general intent of the files should remain somewhat constant. Here are some basic informations that could help newcomers. They are up-to-date as of January 16th 2014.
Some quick high-level remarks:
Aegis uses two main managers: a Headquarters and a Queue manager. The headquarter deals with high level strategy, or macro-ing. The Queue manager allocates resources to what Aegis wants to build or train. The Headquarters (HQ) overlook bases, which are defined by an anchor building (such as a CC) and a territory. Each base has functions and units attached to it, and handle base functions (building new dropsite in the base territory, constructing to better suit its functions…). The HQ also hold a defense manager which deals with all defense, taking units from bases and targeting enemy armies. There is also a WIP Naval Manager to handle transport and amphibious attacks.
This file initializes the bot, inheriting from BaseAI as defined in the common-api. The initialization is done in two main phases: the constructor Init, and the initialization using the gamestate in CustomInit().
This file also handles the bot updates, calling the Update functions of the main components. Finally, it handles picking the AI high-level personality (as of the writing of this page, this is still a very experimental feature and subject to change).
This file handles attacks. Aegis attack plans are very flexible, and can be used to do many different things. There is a possibility that this file will be split in several (similarly to how queueplans are now handled) sometimes in the future.
Aegis plans have a target player and a goal (usually a building). It creates two queues (one for soldiers and one for champions), and tries to train units to meet the requirements defined in its buildOrders. Those buildOrders are extremely flexible, which is the strength of these attack plans: you can use them to create cavalry archer raids, champion infantry sieges, mixed armies, and really anything.
These plans handle the training, the preparation, the pathing, and the actual attack. Note that this too is subject to change or to splitting, there may be helper files in the future.
Furthermore, this is an area where Aegis needs a lot of work (for example, having a specific entity as a goal is a little dumb, it would be better if its goal was defined as "raze buildings" or "kill villagers").
This file handles bases. It contains anything related to them. In particular it holds the functions that keep track of the base's resources levels, and that check if we need to expand the base (or tell the HQ to build new ones). It also handles workers assigned to that base (for gathering, hunting and constructing/repairing). It should grow slightly over time as I switch functions from the HQ to this file.
Defence.js and defence-helper.js
Those two files are the core of the defense. Defence-helper.js is a wrapper around an enemy army for convenience purposes. Defence.js checks for dangerous enemy units, and assigns them into armies. It will then try to sensibly affect some of the workforce to defend its hometown. This function also needs substantial work.
This file defines the HQ. The HQ handles high-level strategy, expansion, high-level build order decision, plans attacks and a few other things (bartering…). It currently also plots buildings and things like that, though those functions should for the most part be relegated to bases in the future.
naval-manager.js and plan-transport.js
Those files are related to WIP works about naval support. The naval manager function is explained in its header. plan-transport is a convenience wrapper to make transporting units over water easier.
This files handles allocating resources to plans, and handles planning the needs of the AI (this part in particular needs a bit of work). It's somewhat complicated, but it basically tries to assign resources to queues equitably depending on their priority and available resources.
Those four files (one generic, three specializations) are wrappers around plans. Plans are basically stuffs that the AI wants to build or train. These should be expanded further to be more resilient (building plans should make sure we scout LOS, things like that) and to give more feedback to the AI (i can't train this unit: I don't have a barracks -> AI builds a barracks).
This handles the logic of workers, as the name implies. It can be thought of as a super-level of unitAI. Its most important function is getting the best resource to gather for workers. This should be expanded to handle hunting better.