AI

[WhiteMage]

i like AI coding. can we do it in a way that supports multiple AI codes and then picks one of the available for each AI player by difficulty level, player choice, random, whatever? the biggest downfall of all AIs is usually predictability. having multiple AIs would counter that a bit.

Absolutely. I have been preaching about this for years and is done that way in C-Evo. You are welcome to read my earlier posts to lower duplications.

[WhiteMage]

Ill make an assembly that has teh AI interface in it.

As a rule of thumb, remember that AI and human client are the same from the viewpoint of the server. The server pushes standard data to both as needed. At this time, I do not see any instance when differentiation is needed between AI and client from the viewpoint of server. Some humans want to see all updates immediately. Morningkill wants to make it available to AIs between their turns and thinks that it is easy to do for reMOM. Sounds good. So let AI programmers decide whether to use that data or not, but push it to the AIs. This makes uniform server programming easier.

void InitAi(AIContext) //the context contains all information the AI will need
// to know about the game beforehand (ruleset, whatever else is needed) as well as
//necessary gamestate objects to query gamestate and produce network events

Yes. Again, this should be identical to what the client computers (for human players) receive. The clients will be limited to use the data through the predified set of UI functions. All statistics are locally generated whether AI or client. No query to server to ask for info. They only push game state and keep communication open.

List<NetworkEvent> DoTurnOverland(Wizard aiPlayer) //do part of an overland turn. This will be called repeatedly while the ai is the turn master

I don’t fully understand. Please explain.

List<NetworkEvent> DoTurnCombat(Wizard aiPlayer) //do part of the combat turm. This will be called repeatedly while the ai is the combatturnmaster

I guess you mean that this will be called after every combat event. Even several times during the AI’s single battle turn. AI assesses current state and sends move request to server. Server makes the move, subject to all conditions including randomness. Sends back the new game state to the level 2 AI, which assesses new current state, etc. Level 3 AI is not part of this: it only receives game states before and after a battle. Not during the battle.
Can you support separate level 2 (battle) and level 3 (overland) AIs? I guess if you don’t want to keep track of that on the server side then level 3 AI can simpy forward it to level 2 AI. Which way is better for server and logging/debugging?

NetworkEvent RespndToDiplomacy(DiplomacyOption )//this shuold be a simple yes/no answer for player initiated diplomacy options

Again, no difference planned between AI and human. So you agree to my earlier proposed once per turn diplomacy, which would only allow diplomatic actions during players’ turns (AI and human) and not between? Some problems otherwise.

One issue I see is to have the AI be aware of inbetween turn happenings. For example: player attacks AI city, but loses. The AI will none the wiser, as by querying the gamestate this is not deducible.

With AI and clients receiving all updates even between turns, this problem disappears. It will be up to the programmers (and players) how use this data.

The problem is, that different AIs may require different notifications: maybe someone want an AI that detects troops coming near its cities, not just attacking ones.

No. Everyone gets it. Then can choose to ignore it. Uniform plan for data sharing.

It is hard to formalize all possible queries, so maybe AI needs to get notification of all events, and then needs to figure out whats happening by himself.

Exactly, but not those which would count as “cheat”, such as random seed or event on other side of map it does not know yet. Server maintains knowledge on Fog of War, etc. and applies filter to all players and sends data only as justified.

We still need a comprehensive list of things the AI may be interested in. Network events only may not be enough.

Get comprehensive list of what humans want. Then provide that to AI too. I can start to write a list and change it later as needed. It should be relatively easy to decide on each issue, but thinking of all issues will take time. 

[letsdance]

the list of what human wants, if incomplete, can be easily completed by playing the game.

[Shendemiar]

I totally agree with everything Whitemage says (so far) on AI or otherwise (you seem to have this all figured out really well, haven't you?)

Cheers for me, I never worked with any Visual Studio before but I got the project running now.

[Anthony]

the list of what human wants, if incomplete, can be easily completed by playing the game.

Actually, it can't, because what humans want is significantly influenced by what the AI can be expected to do. You'd have to run on multiplayer to really get a sense.

[Shendemiar]

In C-Evo the AI just gets access to the current turns game state with FOW mask, and 32 bits per city/unit to store information for the next turn. I think this might be insufficient.

1) The AI/client should be provided with the possibility to keep a record of all data received throughout the game. AI keeps it for analysis and client for fancy graphs, expansion playbacks etc.

2) I think the AI (and thus also the client) should also be allowed to keep the battle data so that it is not lost after the battle. I think level 2 and level 3 AIs should be able have unrestricted interaction.

3) To top it off, AIs should be able to save data on 'game to game' basis so they could learn in the long term also, not just inside one game.

Not all points 1-3 needs to be utilized in all AIs, but the option should be there.

Note: Enemy power, army strength and research are public knowledge and not masked by FOW in MoM.

[WhiteMage]

In C-Evo the AI just gets access to the current turns game state with FOW mask, and 32 bits per city/unit to store information for the next turn. I think this might be insufficient.

Agree. You looked into the C-Evo source code already? Excellent. Lots of goodies there for the expert Delphi programmer.

The AI/client should be provided with the possibility to keep a record of all data received throughout the game. AI keeps it for analysis and client for fancy graphs, expansion playbacks etc.

Yes, but that is AI and client programming. In C-Evo, the “book” contains the detailed history of the game. It can be played back and show player views or supervisor view. In reMOM, server should keep step-by-step recording of ALL games: multiplayer games, AI only games, and single player games. Yes, it would benefit the AI to keep its own book as well, but this is up to AI programmers if they want to program, maintain and use that for decision making and learning. For clients, we build it up gradually. Maybe once the server logging is done and well tested, the code can be ported to the AIs and the client code in a simplified way. Then build proper processing functions on the top of that. These processing functions could be additional examples for the level 1 AI I described earlier.

I think the AI (and thus also the client) should also be allowed to keep the battle data so that it is not lost after the battle.

Of course. Battles are to be logged too in detail. On the server’s step-by-step recording, I envision a single comprehensive log file per game, which records everything including (server) time stamps.

I think level 2 and level 3 AIs should be able have unrestricted interaction.

Definitely, but I think that they will not communicate much for practical reasons. There will be populations of both levels of AIs and they “marry” at the beginning of a game, and “divorce” at the end of the game. They do not marry or divorce in mid-game. The level 3 AI is better off not knowing about the details of exactly how the battle went down and vice versa. However, they can prepare and send reports to one another. Level 2 AI is to know the nuts and bolts of playing battles and can have its own metacognition module or learn from experience should the programmer decide to do so. So roughly speaking: Level 1 AI: user support; Level 2 AI: battle tactics. Level 3 AI: overland strategy. There will likely be more, as we get deeper into coding.

To top it off, AIs should be able to save data on 'game to game' basis so they could learn in the long term also, not just inside one game.

Surely, but up to the programmers if that is the approach they take. In addition, both the human and the AI community will have access to all server logs (the entire library of all past games), which is even more valuable to support learning.

Not all points 1-3 needs to be utilized in all AIs, but the option should be there.

Exactly.

Enemy power, army strength and research are public knowledge and not masked by FOW in MoM.

I know. That should go away. I hate this all-seeing orb function in all Civilization type games. I think that player should need a spell, a spy, or diplomacy for that, but that would count as modding, so VM may disagree for current cloning goal.

[VM]

I feel we talk beside each other. The current design of the AI ism that it will run in the server process, but communicate with it trough NteworkEvents (just like the player who sits at the server). In this respect, the server game knows, that when its the AIs turn, it can talk to the AI and request thenext move from it. The AI will then calculate whatever, and make a decision, put an appropriately parametrized NE into the queue, which gets propagated to each client. The clients take the NE and process it, making the necessary changes on their locally stored gamestate. The clients dont have to know who is AI and who is not: for them, the AI is just like another player.

The alternative is to write an AI client, that can join a game just like any client: in this case, the server needs absolutely no knowledge about the AI player. You seem to prefer this one, but then you have to duplicate a lot of code, that is still in development. (Gamestate information tracking, NE processing)

Im reluctant to write a whole second client. But the 2 options are not necessarily exclusive: the connecting protocol is open, you can already go ahead and make an AI client if you want to.

[WhiteMage]

I feel we talk beside each other.

Should not be the case. I was discussing long term plan. I would like to know if there is a problem with it or if you have a better proposal.

The current design of the AI ism that it will run in the server process, but communicate with it trough NteworkEvents (just like the player who sits at the server).

Yes. I understand that current design does not even have full client/server implementation, just wanted to ask not to dig this design in too deep and make future upgrade easy. Besides, I need to know if this design impacts AI development. I don’t see that it would, but maybe you do.

In this respect, the server game knows, that when its the AIs turn, it can talk to the AI and request thenext move from it. The AI will then calculate whatever, and make a decision, put an appropriately parametrized NE into the queue, which gets propagated to each client.

This seems roughly OK for my long-term proposed plan too. I suppose you apply FOW, etc. filters as needed only on the client side. That is OK for now, but can’t stay long term.

The clients take the NE and process it, making the necessary changes on their locally stored gamestate.

Yes.

The clients dont have to know who is AI and who is not: for them, the AI is just like another player.

This appears to be true for both current plan and long term plan. For long term, this will be also true for server game processing.

The alternative is to write an AI client, that can join a game just like any client: in this case, the server needs absolutely no knowledge about the AI player. You seem to prefer this one, but then you have to duplicate a lot of code, that is still in development. (Gamestate information tracking, NE processing)

Yes, I strongly prefer this. Without this, the AI capability will be severely limited. AI would think longer and the quality of decisions would be poorer if bound by server, not to mention accusations of cheats, difficulty of upgrades, etc. Cloud based AI is ultimate goal. See StarBase Orion for example. Their AI is also lame, but the design is good. Certainly I am not suggesting duplicating code that is in development.

Im reluctant to write a whole second client.

I understand if you do not want to spend time on this now. No problem. Maybe later, maybe someone else.

But the 2 options are not necessarily exclusive: the connecting protocol is open, you can already go ahead and make an AI client if you want to.

I do not wish to write AI for a game where even the rules are not known. We need some kind of stability and rule freeze. Again, see C-Evo. 80% of AI programmers developed working AIs for the game under development. All of those AIs went out of synch and almost all AI programmers disappeared without coding proper patch. New AI programmers start from scratch. However, I think that next step for reMOM AI would be to fix the battle and create a basic AI sample code with AI toolkit, and nice debug environment. Thinking of eventual cloud AI, C# is not the only way, but whatever makes it easy to start it up.

[VM]

Well, we do need a aingle player AI, and Id prefer not to have to set it up as a multiplayer...

I suppose I could create a sort of "plug", where you could put the AI into a dll, and in single player, the AI would be called from the server, and in multiplayer, it could be plugged in to a client to handle that one fully?