Ai

[The Jo]

I try to improve the AI in Orxonox - one critical part of the project concerning the user experience. At the moment nothing seriously has been implemented by me so far. Until now I've been testing the existing framework and have tried to come up with some ideas and concepts.

Any kind of suggestion is welcome - the more detailed the better.

[beni]

愛

[greenman]

are you trying to improve the whole ai or implement a specialized ai for a specific gametype (like last man standing / TeamBaseMatch) ?

[The Jo]

I'm trying to improve the whole ai. Specialized ai is only the second goal.
-------------UPDATE-----------------
My thought so far:
- The bot's level should be configurable. (Maybe there are 3 different levels. Dependent on the bot's level, some parameters are adjusted.)

- A bot should be able to use all kind of weapons available.

- More functions that allow the bot to do more things and especially more complex things. For example: protect(woldentity* target).

- A detection mechanism for critical events. If a bot receives damage, it should react somehow.

- A planing system. A bot should have a plan what to do and call the related functions accordingly.

- A function(-pointer) stack, in oder to manage the functions. Example: A bot`s goal is to protect a transporter. By default the bot should patrol in the area near the transporter. if the transporter or the bot is attacked, a counterattack function should be put on the stack, which will make the bot to interrupt his default-action and react.

- In the end there should be separate classes for different kind of bots, which are adjusted to certain gametypes, levels, ....

[beni]

You may also want to look into a simple state machine where you can have different states inside the bot ('idle', 'under attack', 'fleeing' etc.) and alter the behavior accordingly.

Also have some priorities for instance may a bot abandon the target he has to protect when he is under heavy attack and takes a lot of damage etc.

[greenman]

I would propose to use a fuzzy-logic-like function instead of a dicrete state machine for the bot state. with fuzzy-logic-like i mean that the bot should have multiple states at once (with the states having priorities) resulting in actions somehow mixed from the different states (e.g. superposition or whatever)

that way it might be possible to fullfill "follow the transporter" and "defend" at the same time

[beni]

I like the fuzzy logic approach. A strict state machine is clearly not the way to go.

I want to add, that we may need routes defined by waypoints to make sophisticated movements with the AI.
Flee: Where to and which way?
Attack: Where exactly?
Ambush: From which direction?

Waypoints introduce a way for the AI to get around in the world.

[The Jo]

My current approach: I try to model a "thinking process". Practically there will be only two additional classes, since there is only a little difference between detecting and analysing. A second class should carry out the decision process. In order to have different kind of bots, one has to created alternative decision classes/ make decisions configurable.

1. Detect events: Try to find out when something critical happend.
Example: health lost, waypoint reached, targed died, ...

2. Analyse those events: Further data gathering after an event was detected in order to be able to react accordingly.
Example: health lost -> was it an attack? -> where is the attacker? , ...

3. Make a decision: The decision-part is the most important part, since it defines the bot's behaviour.
Example: attack the attacker / already fighting back->forget the event / ...

(4. Execute the decision)

While I've already started to implement the detection/analysation part, I'm still not sure how the second part could be carried out exactly. Furthermore a lot of questions arised. A list of questions is coming soon.

[greenman]

sounds good
have you already an idea on how to implement following of two/multiple goals / targets? (e.g. stay in formation and attack enemies)

[The Jo]

I've got only roughly an idea how to implement following multiple targets. First of all there has to be a check whether those targets match or are a contradiction. If they "match" the time is splittet into intervals where the bot switches between these targets. (1 second: shoot at attacker (1st target); 0.5 seconds: follow your group (2nd target) , 1 second: shoot (1st target), ...)
//Is this what you mean with following multiple targets?

[greenman]

hm... i think we mean the same by saying follow multiple targets, but i don't know if it's good to split up time... one can also follow a transporter and shoot at an enemy within the same tick (not just 0.5s later)

maybe a grouping of actions is neccessary (attack, evasion, movement, ...). after grouping you could check which actions can be done simultaneously (e.g. attack and evasion or attack and movement). for actions that cannot be done at the same time (like evasion and movement) you would need some priorities ...

i don't know if this approach is better than splitting up time, but it's a bit more "parallel" ^^

[x3n]

Well I think the question is: do you want to implement a full-fledged AI which works in all situations, multiplayer & singleplayer, combines different tasks, moves in formations, etc. Or do you just want to make some improvements on the current AI for the upcoming release?

While I'd certainly welcome a professional AI, I think we should currently go for the latter and make some simple but effective changes. We can then build upon the experience from this implementation to create the final AI.

Furthermore, Jo, you're definitely a talented, creative, and very motivated programmer, but the AI is a topic which exhausts the skills of the whole team of orxonox core developers, so I doubt that you succeed in the first attempt to build an AI which satisfies all our current and future needs (no offense ). That's why I recommend to make some simple improvements for the upcoming release and collect ideas and experience for the final implementation.


By the way, have a look at the pong gametype (located in the pong module). It has a separate AI which is not built upon the regular AI. When I implemented this, I realized that it's not enough to make a new controller for the pong AI, but also a new bot class which uses this controller. This showed me the need for an improved modularity of the AI system, because the controller should be easily exchangable without implementing a new bot class for each gametype.

That's an example for an experience that was made during some simple "experimenting" with AI that will be considered in the final implementation. And I expect that we'll gain more experience of this kind during your improvements on the AI.

[The Jo]

Ok. Got it! I'll concentrate on small/ quickly implemented improvements for the release.

[The Jo]

I recently added a way how to influence a bot's strength. But currently I'm not able to integrate it in the game - the effect seems to be hard coded so far.

1st attempt: XMLPortParam(ArtificialController, "level", setBotLevel, getBotLevel, xmlelement, mode).defaultValues(1.0f);
-> I didn't define the setBotLevel function as an inline function. Is that a problem?
I added the following xml code:
<SpawnPoint team=0 position="-200,0,0" lookat="0,0,0" spawnclass=SpaceShip pawndesign=spaceshipassff level="1.0f" /> There is no xml parsing error but also no measurable effect, if one modifies the level value.

2nd attempt: SetConsoleCommand("ArtificialController", "botlevel", &ArtificialController::setBotLevel);
the command "botlevel 10.0f" doesn't work.
My next attempt: "addbots 10 botlevel 10.0f" didn't result in an error message, but the measured effect isn't what I had intended.
--> As soon as I'm done with testing, I'll post the results here.

[x3n]

hey jo,

yeah I noticed your attempts in the commit emails, nice

1st attempt: XMLPortParam(ArtificialController, "level", setBotLevel, getBotLevel, xmlelement, mode).defaultValues(1.0f);
-> I didn't define the setBotLevel function as an inline function. Is that a problem?

No problem, inline is not required.

I added the following xml code:
<SpawnPoint team=0 position="-200,0,0" lookat="0,0,0" spawnclass=SpaceShip pawndesign=spaceshipassff level="1.0f" /> There is no xml parsing error but also no measurable effect, if one modifies the level value.

If you add XMLPortParam in ArtificialController, you have to define level="1.0f" in the controller (note: the controller is not visible in the xml file for ordinary bots). If you want it in the SpawnPoint, you have to move XMLPortParam into SpawnPoint.cc

But I don't think SpawnPoint is the right location for that. The idea with a console command is probably better.

2nd attempt: SetConsoleCommand("ArtificialController", "botlevel", &ArtificialController::setBotLevel);
the command "botlevel 10.0f" doesn't work.
My next attempt: "addbots 10 botlevel 10.0f" didn't result in an error message, but the measured effect isn't what I had intended.
--> As soon as I'm done with testing, I'll post the results here.

Two problems here:
1. ArtificialController::setBotLevel is a member function, not a static function. Member functions need an object (the "this" pointer). You call them object->memberFunction(value) in C++, in the console command you have to define an object otherwise. However this is not required, because the second problem is:
2. With this console command, you can only change the level of one bot, not all existing bots.

To solve these problems, you have to implement a new function. for example something like this:

Code: Select all

static void setAllBotLevel(float level);

The implementation looks something like this:

Code: Select all

void ArtificialController::setAllBotLevel
{
    for (ObjectList<ArtificialController>::iterator it = ObjectList<ArtificialController>::begin(); it != ObjectList<ArtificialController>::end(); ++it)
        it->setBotLevel(level);
}

What does this code? it iterates through all existing instances of ArtificialController and sets the bot level.

edit: more information about the object list here: http://www.orxonox.net/doxygen/_object_ ... torExample


By the way, on a side note: I'd prefer a bot level from 0.0 to 1.0. This makes certain things easier, for example you don't have to define the highest level (at the moment it's 10, but why?), because the maximum is simply 100% ( = 1.0). Also you can use it as a base for probability, for example a bot hits the player with probability "botlevel" (set botlevel to 0.5 and it hits every 2nd shot, simple as that). It's just a little more intuitive in my opinion.