Subject: Re: Ai implementation

---

Hi Razvan,

I would really love, to see this project continued. You can count on our support Maybe we can team up some people, who are interested in the AI topic (Jarod? ).

I think the question, how the AI integrates with the server, is very important and should be answered well considered. I see three possibilities:

1) Separate process, that connects to the server like normal clients

• Easy implementation
• More difficult user interface integration (but not impossible): The user shouldn't have to handle a separate command line tool to add AI players.
• Cheating: The Ai is restricted to the possibilities a normal player would have. I consider this as a disadvantage, because it makes is harder to
  implement a challenging AI.
• Maintainability: We have to maintain and compile two separate projects. When changing something in the maxr code, we need to compile the AI as well to check the changes. When the AI is integrated in the maxr project, it would be easier to maintain, because is gets compiled at the same time, and thinks like intelllisense can also
• stability: when the AI crashes, it doesn't kill the server. The ai can reconnect to the running server, like normal players, without interrupting the game.

2) Instantiate another client in maxr itself. Communication also via the defined net messages.

• Needs some effort to separate the Client from the GUI and for message dispatching to the correct client

3) Directly within the server main loop. Direct access to the game model.

• easy implementation
• AI could slow down the server main loop too much. That would affect the game speed an all clients.
• No multicore support: All AI players and the Server itself share the same CPU core.

So what's the conclusion from that? I'm not absolutely sure. Every method has it's advantages. In every case we should avoid code duplication (implementing things twice) as much as possible.
In my opinion, we should prefer method 3. Any further opinions?

P. S. : Regarding the GAME_EV_ATTACKJOB_LOCK_TARGET and GAME_EV_ATTACKJOB_FIRE messages: Yes, I'm not very proud of the attackjob implementation. It was a desperate try to hold the clients in sync, without synchronized game speeds on the clients and server. I'll rewrite and simplify this part of the code, after merging my last changes back to trunc. Then the GAME_EV_ATTACKJOB_LOCK_TARGET message will be removed. And also the GAME_EV_ATTACKJOB_FINISHED message. Then indefinitely locked units are not possible any more.