Latest Posts

Topic: News about AI

Tibor

Topic Opener
Joined: 2009-03-23, 23:24
Posts: 1377
Ranking
One Elder of Players
Location: Slovakia
Posted at: 2016-10-21, 20:05

GunChleoc wrote:

The max players branch is finished now. All one needs to do is to edit graphics/playercolor.h to increase the max amount of players and add player colors.

We still have a UI issue with starting games, but since those screens need redesigning anyway, I'm not going to touch them right now.

What is upper limit now? 16 players? There is though small problem here - if I merge your branch into mine, will I be able to easily "unmerge" it. Of course I can still do it manually... But first we need at least few 16-players maps...


Top Quote
Tibor

Topic Opener
Joined: 2009-03-23, 23:24
Posts: 1377
Ranking
One Elder of Players
Location: Slovakia
Posted at: 2016-10-21, 20:13

king_of_nowhere wrote:

one thing to take into account is that different maps call for different strategies, so the parameter optimization should be done on different maps. maybe an average of what worked best in different maps could be taken.

As I said, I test four maps in pararel, and I am trying to have them different, results are four distinct DNA's in the source file and new players are generated with random crossbreeding of two parents.

Of course AI is not that intelligent to choose a strategy for a map... It would need to be completely different AI - based on neural networks f.e.....


Top Quote
GunChleoc
Avatar
Joined: 2013-10-07, 15:56
Posts: 3324
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2016-10-22, 09:57

The max_players branch won't break older savegames or maps, so merging it shouldn't be a problem. We should do a code review on it first though, so I have created a merge request.

Regarding reading / writing values into files, I think that's still a good idea, because time is a factor, and compiling takes time.

The functions are located in profile/profile.h. For usage examples, I recommend looking at map_io/map_elemental_packet.cc. It goes something like this:

#include "profile/profile.h"

// Reading
Profile prof("file_path");
Section& s = prof.get_safe_section("foo");

int value1 = s.get_int("value1"));
std::string name = s.get_string("value2"));

// Writing
Profile prof;
Section& section = prof.create_section("foo");

section.set_int("value1", 42);
section.set_string("value2", "bar");

prof.write("file_path");

The generated profile file will look like this:

[foo]
value1="42"
value2="bar"

Busy indexing nil values

Top Quote
Tibor

Topic Opener
Joined: 2009-03-23, 23:24
Posts: 1377
Ranking
One Elder of Players
Location: Slovakia
Posted at: 2016-10-22, 19:36

> *GunChleoc wrote:*
>
> The max_players branch won't break older savegames or maps, so merging it shouldn't be a problem. We should do a code review on it first though, so I have created a (https://code.launchpad.net/~widelands-dev/widelands/max_players/+merge/309083).
>
> Regarding reading / writing values into files, I think that's still a good idea, because time is a factor, and compiling takes time.
>
> The functions are located in `profile/profile.h`. For usage examples, I recommend looking at `map_io/map_elemental_packet.cc`. It goes something like this:
>
> ~~~~
> #include "profile/profile.h"
>
> // Reading
> Profile prof("file_path");
> Section& s = prof.get_safe_section("foo");
>
> int value1 = s.get_int("value1"));
> std::string name = s.get_string("value2"));
>
> // Writing
> Profile prof;
> Section& section = prof.create_section("foo");
>
> section.set_int("value1", 42);
> section.set_string("value2", "bar");
>
> prof.write("file_path");
> ~~~~
>
> The generated profile file will look like this:
>
> ~~~~
>
> value1="42"
> value2="bar"
> ~~~~

That profile stuff looks good, I think I will use it, but after the MAX_PLAYER branch is merged. BTW I was thinking about two new folders

data/ai
./widelands/ai

What do you think...


Top Quote
GunChleoc
Avatar
Joined: 2013-10-07, 15:56
Posts: 3324
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2016-10-22, 21:04

Yes - looks good.

Any read/write files should be in the profile format, and read-only configuration in lua. You can give me a shot if you need help with reading Lua files.

Regarding the different win conditions, there could be different AIs trained for each one and then loaded according to win condition.

Edited: 2016-10-22, 21:20

Busy indexing nil values

Top Quote
Tibor

Topic Opener
Joined: 2009-03-23, 23:24
Posts: 1377
Ranking
One Elder of Players
Location: Slovakia
Posted at: 2016-10-22, 23:22

GunChleoc wrote:

Yes - looks good.

Any read/write files should be in the profile format, and read-only configuration in lua. You can give me a shot if you need help with reading Lua files.

My idea: standard format for such file with AI "DNA" - default values in ..data/ai/, but user could use own DNA if he locate these files in .widelands/ai/

As by now - 4 separete AIs DNA are used, new AI is created by mixing 2 AI and some mutation is added. So there should be files like ai_1.dna to ai_4.dna used as a source for initialization.

Also, when game is initialized, AI of each player is bit different (I mentioned it above) and this should be dumped to some file with the very same format as above files ai_*.dna. Similarly like when new replays are created for each game. But this would be for each ai.

And training look like - the person takes one generated dna file of AI player it likes and copy it to .widelands/ai/ai_*dna. Next time when game starts this file is used instead of default one in data dir. And again and again...

Regarding the different win conditions, there could be different AIs trained for each one and then loaded according to win condition.

Now only part of logic will be controlled by those DNA, and I can say this would not work very much. F.e control of rangers - starting and stopping them is done by old code that is not aware of any wood mode (I dont know what exactly the english term is.). Training is very lengthy and repeat it for each mode - impossible. Well, we are not google.... (or IBM)

EDIT: But yes, I tend to gradually shift decision making from my code to new code (AI), every time it means "detraining" of AI and as theory says, it increases "searching space", and this basically means more combinations to try out (=more time for training).

Edited: 2016-10-22, 23:37

Top Quote
DragonAtma
Avatar
Joined: 2014-09-14, 01:54
Posts: 351
Ranking
Tribe Member
Posted at: 2016-10-23, 03:39

Unless I'm misunderstanding something, it should be easy to make AIs for the multiple gametypes:

(1) Do the current testing, with the game only in Endless; the last survivor is the winner.
(2) Do the current testing, with the game only in Wood Gnome Mode; the winner is, well, the winner.
...
(8-ish) Add a simple "if Endless, use AI 1, if Wood Gnome use AI 2, (etc.)".

Edited: 2016-10-23, 03:40

Top Quote
Tibor

Topic Opener
Joined: 2009-03-23, 23:24
Posts: 1377
Ranking
One Elder of Players
Location: Slovakia
Posted at: 2016-10-23, 18:54

DragonAtma wrote:

Unless I'm misunderstanding something, it should be easy to make AIs for the multiple gametypes:

(1) Do the current testing, with the game only in Endless; the last survivor is the winner. (2) Do the current testing, with the game only in Wood Gnome Mode; the winner is, well, the winner. ... (8-ish) Add a simple "if Endless, use AI 1, if Wood Gnome use AI 2, (etc.)".

Generally yes, but:

  1. Relevant logic has to be moved to new AI (this is not the case yet for everything)
  2. Training is time demanding. I will be happy if I manage to prepare single "generic" AI that could be usable for the "production" version. Also, not only training, but a lot of manual changes to code takes a lot of time.
Edited: 2016-10-23, 18:56

Top Quote
Tibor

Topic Opener
Joined: 2009-03-23, 23:24
Posts: 1377
Ranking
One Elder of Players
Location: Slovakia
Posted at: 2016-10-23, 20:46

Hi,
my first testing of 16-players map:





map: 128x128 so each player has space 32x32. Probably the map could be rather bit bigger, now it is quite a massacre

The map is absolutely periodic, so is completely fair.


Top Quote
Tibor

Topic Opener
Joined: 2009-03-23, 23:24
Posts: 1377
Ranking
One Elder of Players
Location: Slovakia
Posted at: 2016-12-20, 22:05

Hi,

After some struggling with possibly new AI I decided that it is stabilized enough for other to look at it and test it. I dont say it is in good shape, but it absorbed some training and some aspects of AI are now fully self-developed, e.g. positioning of new and dismantlement of military sites, some attacking logic, part of productionsites management is also self-developed.

If you are able to compile and are interesting to try bit different AI, here is the branch

bzr branch lp:~widelands-dev/widelands/ai-post-b19-2

As a small curiosity here is genealogy of 4 virtual AI players, that are included in the code and are evolving/propagating during training. No big deal to see, but it hink it is very similar to evolution in nature.

Here is the tree:



Top Quote