UBotScript?

[sfx1999]

I vote no because it is quite a bit slower, and you need speed in these type of bots. I mean, how much CPU power does a server loaded with bots need? Now multiply that by 15.

[Killaruna]

OK, a lot of things going on here...

Originally Posted by Pierre-Marie Baty

The motile part must take from the script, for date t, HOW for it to move, HOW for it to point its gun and HOW for it to act upon entities and equipment (attack/use/whatever).

If I understand you correctly, that's what my goals.xml file does. Plus it incorporates the evaluators for these actions (in form of a scoring system). Good or not good (XML syntax left aside)?

Originally Posted by botman

Start with a simple small design and implement it (in working code, not on paper) to prove that it works.

Yep, that's what I meant. Botman, did you have a look at my code? Note that I'm not advocating a fully scripted bot here. The design that I posted (in working code) uses XML-data/script/whatever to determine the bot's actions based on its perception. That's not complicated at all, not too slow and not hard to change even for non-programmers (if you modify the syntax from XML to something less cryptic).

[Pierre-Marie Baty]

Hmm no.
Your goals.xml rather looks like what I call the "Think" function of a bot.

I see things like this:
For each frame, for each bot, the whole thinking cycle is a three-step phase:
------------------------
Step 1: sense everything that's sensable during this very frame. Store in an array or in a linked list or whatever, ALL that the bot sees, ALL that the bot hears, and ALL that the bot touches, with ALL the detailed information about these perceptions. Don't think, don't act, SENSE. Only sense.

Step 2: think, relatively to 1°) the bot's plan (goal, task, agenda, team intentions) and 2°) these perceptions we sensed during step 1, in order to determine what the bot should DO during this frame. Eventually modify the goal, or the task, and DECIDE where to aim, how to move (this includes pathfinding) and what keys to press. BUT DON'T DO IT. Don't sense, don't act, just THINK.

Step 3: Action. Press the keys, move the crosshair, issue the chat commands, browse whatever menu, call the function to put the character in movement, use stuff, fire weapons, whatever. Don't sense, don't think, just ACT.
----------------------

What I see scriptable is step 2, whereas step 1 and 3 would be pure C code. Step 1's role is to provide information (goal/task and current perceptions) to the "think" script, and step 3's is to take commands FROM the same script. In this sense, we have the top AI completely scriptable (and there's not much to do there, since you know like me that more than 50% of the AI code goes with the sensing/navigation part.)

But botman is right, if we don't trust people's hacking abilities and if we don't believe they may be able to write the bot AI themselves for their MOD, then better make the whole stuff in efficient C code.

[Killaruna]

Nice description PM, these steps are well-defined and I agree to this separation. But: My goals file is exactly your step 2! What makes you think it's an entire Think function? ???
The perception is implemented completely in C-code (a part of that is still missing in PIA, though), as is the action... (called Behaviour in PIA, but still). Look at the latest Think function, I added comments for the steps:

 
void PIA_Bot::think() 
{ 
  // step 1: sense
 myPerception->scanEnvironment( game()->world() );
  // step 2: decide what to do, this is based on the goals.xml file
 myGoalFinder->analyze( myPerception );
  // step 3: get C modules for the implementation of the goal and execute
 PIA_Behaviour *behaviour = myGoalFinder->getBehaviour();
 PIA_Perceipt *trigger = myGoalFinder->getTrigger();
 if (behaviour) behaviour->execute( this, trigger );
};

I mean, that code is the definition of your 3 steps, man... I think I have to add the missing classes and a bit of documentation to the framework to make things clearer. Actually, the basic "action execution" part is missing as well, that might make you think the XML does this - but it does not, trust me

[Pierre-Marie Baty]

it already happened once, it happened twice, and it's happening yet once again: we're talking about exactly the same thing but I'm too dumb to understand what you say
I believe what got me into the wall is that I couldn't find the "action" part, even a basic one, coded anywhere... well I suppose that just fits right, then

Okay. I like what you did and the way you did it. It's just that this XML is argh, well, crap, I've said it already and you must be tired to hear it. Anyway!

Nice. Very nice. Now: if we ever go this way, we oughta make a CLEAR structure - and let me stress out again CLEAR - of this scripted "step 2". Because the key of it, is what results of two analysis the bot runs in parallel: the analysis of the current "task" or "goal" and the analysis of the current perceptions in regard to it.

I've taken a deeper look in this (although short) goals.xml file and all I can see so far is that it fits lovely for a deathmatch environment. Now the question is: how and how easily will you introduce team play, team tactics and team goal completion in the middle of this stuff ?

I might have something to propose, but later, as I'm still working on it with RACC. Anyway, I'd still like to hear anybody who has the slightest beginning of a solution here.

[Killaruna]

The example goals I wrote fit so lovely for a deathmatch environment because that's what I wrote them for I've never programmed any team-oriented goals and have no clear ideas of what you CS-programmers make your bots do and how you do that... So just a first brainstorming on that topic:
- You said two kinds of analysis in parallel, one of the perceptions, the other of the team goals. Sound logical to me. Maybe we could divide these two "scripts" in two different files? Makes things more interchangable, I imagine you could use a great part of deathmatch logic for certain team games as well.
- The team goals file should have limits of the # of bots executing each goal at one. You only need one bot to plant the bomb, but maybe two to cover him, the rest sniping or patrolling, no idea... Anyway, when checking team goals bots can query how many team members are already working on that specific goal and decide in favour or against it.
- If someone could describe his bot's logic for teamplay, I might come up with more ideas on how to formalize that.
I think the syntax is the least problematic step here, that's pretty much interchangable. And I agree to kicking XML for some simpler code

[Pierre-Marie Baty]

It's a bit more complicated than that in fact.
In team play, the individual is nothing, the team is all.
Hence it's just not one bot going to plant a bomb and two or three patrolling around, it's squads advancing to their objective altogether by leapfrogging, everybody being assigned a role: officer in charge, pointman, pointman backup, assault man, grenader, squad backup. Communication is the key. Every team member exchanges with all the other his observations and his intentions.

To make the comparison easy, it's as if the whole squad was just ONE bot, sort of a big spider, and each of the bots were the spider's legs.

Have you read William's articles about team tactics and manoeuvers in the Game AI programming wisdom book ?

[botman]

Team AI can be handled in several different ways.

You can have a team/squad leader and they make all the decisions about what to do and order other guys to do them. When the leader gets killed someone else is promoted to the leader. Half-Life single player AI works this way and real-life military organizations works this way. The problem with this method is that you have to send messages back and forth between the leader and the members of the team/squad. The message passing can become complicated if you have to acknowledge an order before it's carried out or you have to recover if an order isn't acknowledged (that member is busy with something else right now and can't respond or responds negatively). This is probably not the best model for AI (although it does allow you to simulate real world situations, like where orders get lost due to communication problems, loss of sight/hearing, etc.)

Another model for squad AI is to create a "hive-mind" concept (like the Borg in Star Trek), where there is one common mind floating around in space that knows what everone is doing and decides which team members do what. The mind doesn't actually exist as a player in the game. This is more like the general sitting on the top of a hill at a battle and watching everyone down below and giving orders. The general can see everything that's going on, but the general doesn't actually engage in any fighting or physically attempt to complete a mission.

Another way to handle squad AI is to have no leader, and let everyone make their own decisions based on what other people around them are doing. This is more like the "group mob" kind of situation. There's no one person in charge, but when somebody decides to start doing something, somebody else will say "Hey, I'll do that along with you". Other people soon join in and before you know it, there are many people "working" on the same activity (good or bad). This model more easily allows for "rogue" members to go off and do their own thing while the rest of the group is doing something else.

I would vote for doing something similar to the 2nd method above "the hive-mind", since that is probably a little easier to implement (no message passing required) and makes the individual behavior more predictable (you don't have to worry about everyone deciding to go off and do their own thing).

It really all depends on HOW MUCH you want individuals to work as a team. For a more team play oriented tactical game (like Day of Defeat), you want LOTS of team cohesion so that EVERYONE is part of the team. For games like Counter-Strike, team work is important in some aspects (like planting/defusing the bomb), and less important in other aspects (like rescuing hostages). And, of course, deathmatch games require absolutely NO team work at all (unless it's team deathmatch like capture the flag).

botman

[@$3.1415rin]

the hive stuff is nice, I made something similar lately in joebot xp ( http://www.lampel.net/johannes/joebo...XPDoc-beta.pdf ) and it 's working pretty fine ...

but I guess pierre wont agree on that point

[Pierre-Marie Baty]

You guess right.

I'm a firm believer in the first method botman talked about.