Mechanized Assault & eXploration Reloaded

Subject: Ai implementation

---

Hi Everybody,

Since MAXr has no AI, and I enjoy playing offline, I started hacking around this topic. The current status is:
- AI connects to the new game, and acts as a regular remote player.
- AI cannot handle right reconnects, game saves, etc (tried to implement it, but doesn't work right: need to store the "socket number" between crashes/disconnects)
- AI has a landing party (generously composed of constructors, tanks, pioneers, scanners and surveyors). However, no limitations of start-up capital is being taken into consideration. It seems the server allows me to get along with my choices without checking.
- AI doesn't move, but reacts to aggression.
- AI has an obsession to end turn.

So far so good, future plans, with regard of features are:
- ability to randomly move units
- resource exploration
- map exploration
- economy intelligence (investment Simplex)
- land randomly, on the buildable ground
- adjust the landing party & upgrades to the game limits

The current code is a golem of existing source taken from client GUI code. When I will have time, I will refactor it into classes. However, since I am a manager and a PhD student, I never have time

The sources are attached. There is a new Visual Studio project (yes, I have license for 2012 Ultimate) that shares the sources of the original MAXR game. There is a new file, containing main function (since VS console project has _tmain, no conflict with the original main occurs). However this conflict needs to be addressed on compiling another platforms. Also, I changed a few original sources: there were some minor errors with MSVC2012 (possible uninitialized variable is escalated to error), and I changed a few class members from private to protected.

The AI runs as a different process. For the moment, the IP address is hard-coded, as well as my name as player.

Maybe there is interest in this direction, I would like to hear other people's idea regarding AI. Feel free to write me in English or German, but I will reply in English, I really lost my skill of writing German.

I like to work on this project to improve my C++11 skill (until now, no C++11 in my code) and to understand VS2012 before using it in production.

Enjoy the winter holidays!
Razvan

Attachments:

Subject: Re: Ai implementation

---

everything has to have a starting point - This is a good one
Good job so far! I hope it will continue at some point

Subject: Re: Ai implementation

---

Hi Razvan,
welcome to the maxr board and thanks for your efforts and sharing the code!
As you might have already suspected, you're not the only one who thinks about AI. But you're one of the few who actually presented some code and didn't just post on the board that he wants to work on the AI (if you search the forum you will find some AI approaches that never really got to something usable).

I myself started some time ago to write an AI that is in general like yours, i.e. it connects like a regular player and behaves like a "bot". You might be interested in this thread, there is some info (and also a practical application to put this "bot" to some use in a scenario game): http://www.maxr.org/...q=scenario
I wrote it in JAVA (because for my job I'm writing C++ and wanted to keep a little up to date to JAVA...) and started with an empty project (but of course knowing some of the code of maxr). But having no time I skipped the project (for now?).

In general there should be some work/plan on how to really make an AI and not just start some more little individual projects that are discarded after some time. This shouldn't mean that your efforts are not appreciated! It's just that for the maxr project we would need something mid/long-term that will scale up and can be maintained and extended.
But I have to say: The maxr team is currently focussing on the multiplayer part and having the full feature set of the original M.A.X. for multiplayer. And unfortunately I also have to say: Currently not much work is put into maxr as none of the developers find the time.

About the options for an AI in general. I see two different approaches:
A) Make a bot that connects like a normal player.
B) Integrate it in the server, so that the AI has easier access to the world model.

I started myself with A, because it's of course a nice project to work on and you're independent. Negative: You have to implement many things twice (as long as the code is not easily reusable from the maxr code base), e.g. parsing the unit description xmls. And second: We have no "formal" specification of the network-protocol and the xml descriptions. These sometimes change and then the bot breaks. If we want to go for A, we would have to make sure that we don't change protocols once they were released.

In my opinion we should aim for B as I think it's more appropriate for a game and very probably easier to implement (this is no academic project where we do "general research" about AI and therefore would like to simulate an independent AI-agent).

Would be interested to hear your thoughts.

Yours,
Paul

P.S.: If you want to share, I would be interested to hear where you make your PhD and with which topic.

---

Subject: Re: Ai implementation

---

First thought (still don't have opened Maxr source code...) :

I prefer solution A. The server should only be concerned by ruling the game without cheaters.
Clients (for AI ou GUI) should share code for all "world model" and network management so i only has to do what it is supposed to do (AI or GUI).

This would also ease the work of different teams. If you mix AI in the server, you are also more subjet to inject new bugs in something that is working now.

By the way, in order to deep in the Maxr code, does someone have a few documents or advices to begin ?

Subject: Re: Ai implementation

---

Hi Everybody,

@fyzzo thanks for cheering me up!

@Toranaga My purpose was to use as much as possible from the existing protocol implementation, for instance, if you miss-implement the message packing or unpacking, the client (and also likely the server) may crash. Most of the game use the B) method, simply because AI is too "dumb" and it needs to cheat in order to make the game challenging. "Connected process" reduces cheating to a point: if the server doesn't check and control the "cheater", AI cheating may happen. For example, my landing party is not constrained to the game specified amount.
What I did is A) but I use the original source code of MAXR, to avoid additional work, this was a good shortcut. Many objects require graphics, so my program also loads all the graphics available.
Planning is difficult since we are a group of volunteer with different goals and variable time availability.
I will check your bot implementation, thanks for sharing!
My PhD topic is data mining (for the moment, I am concerned with big data storage) in a remote program at Transilvania University of Brasov, Romania. Currently, I don't pursue a degree or publications related to gaming AI. However, C++11 may be a part of the research.

@ness the original code is almost all the times self explanatory. Some German skills may help in understanding the comments. I spent 2 evenings and Saturday morning to understand the code and write the bot. There is no formal definition of the protocol, that is not all the time stateless. For example, by not handling the GAME_EV_ATTACKJOB_LOCK_TARGET and GAME_EV_ATTACKJOB_FIRE messages in the right way, the enemy (with regard of the bot) unit becomes locked indefinitely. I don't know the exact mechanism behind, I only used existing classes that handle this messages right. Indeed, sharing the same protocol makes collaboration easier than direct memory access.

Razvan

Subject: Re: Ai implementation

---

@Razvan: Thank you for posting your source code. I compiled and ran it. It works great. It was great fun moving my surveyor over to the AI landing party and seeing them there. Later, I built a scout and moved it over. It was awesome seeing the AI tanks destroy my scout. This is a great start. Thanks a million for posting your source code! As you said, Razvan, I think the next step is the ability to randomly move units. I definitely understand how busy you are. I will do my best to learn and see if I can contribute anything helpful.

@Toranaga: Long term, I think I agree with you that the AI should be included in the server instead of implemented as a BOT. I see your point about writing the same code twice. On the other hand, I think it is easier for us a newcomers to write a bot than it is to try and modify--and probably break the server.

---

Subject: Re: Ai implementation

---

As a note,
I provided a patch for a Passive AI there : http://www.maxr.org/showtopic.php?id=695

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.

Subject: Re: Ai implementation

---

I recently stumbled over LUA again and I remember that we decided to go for LUA for events and scenarios. Why not use LUA? This way you don't have to recompile AI all the time and you can even tweak it on runtime.

---

Subject: Re: Ai implementation

---

Now that you mention it, I remember...

Alzi once wrote a concept for lua integration:

http://www.maxr.org/showtopic.php?id=650&page=1

But I don't understand the concept in deep detail. Does this mean, the script is interpreted by the server, so this would be a variant of method 3) ?