Server

Below is a list of improvements as they come to mind without any ordering for importance or priority.
These improvements would facilitate the design of the AI. All the suggestion pertain to an AI under development.

For most of the items below I have programmed a workaround already. If implemented, they would simply make life easier for new programmers joining the community.

If you want to add to this list, just mail me your proposal.

Nomenclature

Tournament mode

Interface

Testing

To assure the quality of a released version, some means of automated testing is absolutely required. Testing by running the tournament mode is just not good enough as the only scenario variation tested is the tile distribution within a fixed size map.

I envision a feature whereby cEvo would take its input (players, landmass, etc.) from a list. This list could then be filled for each test run as the designer sees fit.
Together with the above mentioned start/stop facility a small test programm is easily written that should solve the test problem.

Information Transfer

There is quite a bit of information that is available within the server but is not available to the AI today. Instead, the AI has to do quite a bit of programming and spend a lot of compute time to generate this information.

1. Changes in ro.Map.
Every step a unit does may entail changes in ro.Map. The server knows about these changes but keeps that information to itself. The AI on the other hand therefore has
to keep an old Map, compare against the current Map to filter out the changes, then update the old Map.

That may be acceptable in the early game, but once Shinkansen comes into play with potentially hundreds of steps per unit per turn, that simply takes too long. I believe the easiest would be to make the previous state of changed tiles available, with ro.Map showing their current state anyway. That info could even be part of the response to a move unit command.

2. Work done
Every time a settler does some work on a tile, the server keeps an account of the work done. Again, this information should be made available to the AI. Only with this information it is possible to determine whether it makes sense to send additional settlers to a tile to speed up the work there.

Also, if the AI has to keep track of the work accounts, it usually has to do so for a number of turns, thereby unnecessarily filling up space in the Datablock or in the serial data store.

3. Return flags
The flag eEnemySpotted is misleading. Assume an formerly empty enemy city. Later observe again and now it contains a unit. The flag does not go up.
Actually, this flag should be split into two flags: eEnemyUnitSpotted and eEnemyCitySpotted.

Additional flags would be helpful: eEnemyCityDestroyed, eEnemyCityCaptured, eUnitMoved

From a logical point of view, there should be one separate flag for a killed unit : eUnitDied. Then there would be not need for combined flags as eBloody or eJobDone_Died.

The only answer to that problem is to do away with all combined flags.

Killed Units / Destroyed Cities

Flags/ Enumeration

Any enumeration list of less than 32 items should be made flag style.

Example:

Instead of

gAnarchy= 0,
gDespotism= 1,
gMonarchy= 2,
gRepublic= 3,

make it

gAnarchy= 1,
gDespotism= 2,
gMonarchy= 4,
gRepublic= 8,

such that the statement
if ((gGovernment == gDespotism) || (gGovernment == gMonarchy))
simply becomes
if (gGovernment & (gDespotism | gMonarchy))

The programmer could then use the stile that suits him best.

ro-Map tiles

Instead of the three flags fOwned, fUnit, fCity four flags would be easier to use: fMyCity, fMyUnit, fEnemyUnit, fEnemyCity, as the AI has to make them anyway from the three flags given.

If there is a city on a tile, the flags fRoad, fCanal should be on as well as fRR as soon as adRailroad has been researched .
Also, if there is fRR, fRoad should be on as well.

In general, if a state is true, then it is good programming practice that the corresponding flag is true also.

I do understand that the graphics live off these flags also, but that is no good reason to force AI programmers to use statements like ro.Map[n] & (fRoad | fCity) all over the place when a simple ro.Map[n] & fRoad would do.

loading unit onto ships/aircraft ( item has been fixed in 1.03 ??!!)

fairness human player vs. AI

1. Non-random maps should not be blackened, as the human player can know the content of the map, while the Ai can not.

2. The human player know his opponents, while the AI does not. This knowledge gives quite an advantage to the human player as he can direct his play accordingly.

Assume a game with CIV-S and Capital as opponents. Knowing this, a good strategy would be to search for Capital to get advances while avoiding CIV-S territory. Without theis knowledge, one has to contact every enemy with the risk of being killed.

use of -1 as indicator for an invalid index

Although this may be standard practice, it is very dangerous at least in languages that do not check for invalid indices,
as the inadvertened use of this index can destroy memory locations.

A better way is to expand the indexed list by 1 and use that index as the indicator for an invalid index. That way, a write operation with that index cannot cause memory destruction. Proper initialisation of this memory location will lead to defined behavior in the case of error.

Proposals for Improvement of the Server-AI Interface