UBotScript?
 

Greetings.
I just had an idea, why not create a scripting language in United Bot? We need the bot to be Platform independent also in addition to game independence right? 9_9
So a very versatile scripting language with a very C-like syntax would be the order of the day.
It could be somthing like this:
BEGIN BOT_AI
Check(EnemyInSight)
if TRUE
{
Check(HavePrimGunAmmo)
if TRUE
{
String FiringMode=NonBurst
Check(BotSkill)
if >60
{
FiringMode=Burst
}
Fire(Enemy, FiringMode)
}
else
{
SwitchWeapon(Secondary)
}
}
END BOT_AI

This could increase the number of people able to work on United Bot enourmously and the sourece code would not have to be released. PLus the C++ code that works behind this could be written for multiple platforms and games and thus the scripts would work in all operating systems and maybe multiple games.

Re: UBotScript?
 

In general, Killaruna had this idea, too, and he already did some work on a similar system. he uses XML, which looked pretty nice.

maybe he'll pass by and describe the stuff :)

Re: UBotScript?
 

Indeed, he will :D

I'd like to discuss the entire PIA (Portable Intelligent Agent) framework I have been designing after my experience with Parabot. Anyway, the only thing I need is a place to upload the stuff: It contains the base classes, some example functions for HL and HLDM and a running console application where a bot joins a console world and his perception/goalfinder pipeline gets executed. As @$3.1415rin said, all goals are scripted in XML, although the underlying functionalities are coded in C++. So it's basically a scripting of the higher AI levels... Anyway, if somebody of the admin sends me a PM on how to upload the zip (or if he offers to upload it if I email it to him :P ), you could have a look for yourselves...
EDIT: @$3.1415rin just told me that I could upload the file by myself, which I did - and you can get it here:
http://filebase.bots-united.com/pafi...on=file&id=138
I am just preparing a new thread for discussing the framework in this forum...

Re: UBotScript?
 

Killaruna man! that would be so great to have you contribute to the United Bot =)

Uploading stuff to Bots United is not a problem for members! you can log in to the filebase and upload any file of your choice in one of the filebase's subfolders... everybody can upload, feel free to use it too :)

/me whispers "argh, C++... pipelines... classes... I feel I'm gonna have headaches reading this stuff again" :D

Re: UBotScript?
 

yes, i have read it (the source & xml) but is it me or is it just a pain to read XML?

Re: UBotScript?
 

I believe XML may not be the best language to use if we want to implement the top level AI in a scriptable fashion.

And as for data storage, INI files are better too...

I'd rather see a mix of INI files and a simple scripting language. Perhaps small ? The AMX compilers are open-source I think, no ?

Re: UBotScript?
 

I don;t know about AMX, i know INI files are easy to read and to make an own INI parser is no big deal.

Perhaps a small scripting language is best, but we should either make our own or use some source elsewhere.

Re: UBotScript?
 

That's what I mean, small is the name of the scripting language AMX uses :)
It's a very common scripting language, and relatively simple to master.

Re: UBotScript?
 

http://www.flipcode.com/tutorials/tut_scr01.shtml

Are you sure you want to do this? I mean, you end up having to make your own compiler using Bison and Flex somehow, which can be found at http://gnuwin32.sourceforge.net/ (Windows binaries). The problem is that a scripting engine can be very slow...

Re: UBotScript?
 

I think it'd be a great idea to use small scripting language as the UBotScript..
Since lots of people in the HL community probably know a little bit of small from making AMX and adminmod plugins.
It'd help people get used to and help make lots of plugins for it and therefore making this bot more popular.

Re: UBotScript?
 

I think the scripting will be best if it is limited to the high level AI only, otherwise it may be too slow. This does not mean that full access should not be provided through the scripting, just that a programmer will probably want to limit the use to high level functions only. The low level scripting may be worth while for quick and dirty testing, or for new programmers breaking the ice.

I also think that use of the scripting language should be 100% optional.

Exactly
 

Yes, Exactly, it makes sense to make UBotScript Optional, I think it should not be there just for the sake of including a scripting language, it should have a deeper purpose: to increase the number of people that can contribute to this project, for this we need a scripting language which is popular, the SMALL architecture, as has been suggested, has all of these features but I think it will be more flexible if we use our own custom created .ini files.
UBotScript in my opinion should not be limited to only AI, it should also be extended to navigation, waypoints created ingame can be saved as ini files by UB and then be edited by the users to give very smart navigation indeed.

Re: UBotScript?
 

I see scripting also for simple sollutions, like ie you have the 'commandmenu' for Counter-Strike. Its in fact a little scripting (well, its primitive) to make your own menu. I would like to see such a thing in UB too.

Re: UBotScript?
 

I agree with the scripting language thing, and i also believe the SMALL language, would be the best for this, as already mentioned, its already used all around the half-life community, and a lot of people know how it works.

Re: UBotScript?
 

XML isnt that difficult as well

Re: UBotScript?
 

OK, people, let's get a little bit more specific here... Saying that scripting would be cool, attract more users etc is fine, but doesn't help to design a bot. I noticed that in the other threads as well, there is a lot of very interesting discussion going on, but everything is too abstract, no examples, no design proposals (I mean class-wise)... I don't know if it's just me, but I feel that we could be going on like that for months without any clear decisions and any real progress.

So, back to scripting. Is it slow? Yes, obviously much slower than C-code, but that shouldn't be a problem if you use it for high-level AI only. So don't worry about that. Second: Which language/interpreter? I wrote my own, which took me about one day, maybe two, and I could probably write an interpreter for any regular Chomsky language you could conceive. If there are scripting standards (Small, or whatever the name) and libraries for it, even better. I didn't know any scripting language when I wrote my code and just wanted to give it a try to see how scripting worked with XML, just out of curiousity...
But before discussing about languages, you need to know what exactly you would like to script and what constructs you need for it.
I set up this example goal file in the PIA-code, and although it's XML everybody should be able to understand it (come on, there are comments :D ). I'm still waiting for some specific feed-back on the approach: Would it work for your bot? Does it impose restrictions you cannot tolerate? Is it too complex? Is it the type of "high-level AI" you have in mind or is it completely different? If it is, post some examples of your ideas of alternative scripting languages (it would help immensely if you had an idea of how interpreters work and which constraints you have to take care of here)... Let's get these design discussions a bit more realistic, implementation-wise.

Re: UBotScript?
 

Ok, i like the XML idea, but how far can it go? you can specify weapons and goals etc, but can you specify bot behaviour in it? Would it be possible to make the bots support things like the WarCraft3 mod for CS, just by editing an XML file?

I assume that the dir structure will be something like..
root/ubot.dll
root/mod/*.xml
?

or will the XML somehow be compiled?

Re: UBotScript?
 

Exactly. I was about to hit the fist on the table once again. 8)

I have read yesterday all the articles in the Game AI programming wisdom book and I have made my mind regarding this issue.

Scripting language -> whatever one. Simple. Weak-typed. Case-insensitive. LIMITED.
Runtime machine -> a stack machine. There are good examples of this in the AI prog wisdom book.
Additional libraries -> external DLLs in C/C++ that provide large sets of facilities to be used by the script. This to overcome the limitations of the language.
Intrinsically limited scripting facilities -> why ? because we don't want to provide debug support for evolved third-party code full of bugs.

What to script ? -> the AI character's Think() function. If we stick to the frame scheme:
sense -> think -> act
sensing and action ought to be complete, fully-featured and quick, written in fast C/C++ code. Eventually make "what" to sense requestable by the script in order to lower CPU usage.
Ideally: the whole Think() process ought to be scripted.
Realistically: put AS MANY of the heavy general-purpose funcs (pathfinders, vistable analysis, etc.) in script libraries in C/C++.

What NOT to script: the sensing and action part. The chat engine. The low-level "user interface" that the bot client uses. The sensing part must make available to the bot, at time t, ALL that the bot sees, ALL that the bot hears, ALL that the bot touches. 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).

How to pass information back and forth from the script to the C code is my last question. Any advice ?

Everything else -> INI files.

Does it answer to your question, Killaruna ? :)

Re: UBotScript?
 

*bump*

botman, you have voted "no", you must have good reasons, would you mind telling us your opinion ?

Re: UBotScript?
 

"botman, you have voted "no", you must have good reasons, would you mind telling us your opinion ?"

Sure. Scripting languages are usually created to give non-programmers a way to create code. Scripting languages are usually fairly simple syntax and have fewer command words in the language that need to be learned by the user. Scripting languages usually prevent "dangerous" coding concepts (like pointers, memory allocation/deallocation, array indexes out of bounds, etc.) so that non-programmers creating script code don't shoot themselves in the foot.

I think the main question to ask is "Why do you want to create (or use) a scripting language (who do you expect to use it)?" If you are creating a scripting language to allow non-programmers to modify the bot code, you will find VERY few non-programmers who are able to understand the complexities of the bot's code and be able to modify it to create new behaviour without breaking the existing behaviour.

If the only people you expect to be modifying the bot code are programmers (i.e. understand C/C++ well), then the language should be something that allows them to create behaviour in the most efficient way possible and scripting languages are NOT efficient. They are slow, they are limited and they are difficult to debug.

As for the argument that a scripting language would make the bot platform independent, I'd say that's not true. Compiled script code (byte-code or p-code or whatever you want to call it), still must be interpreted by native code on that operating system. The script code itself may be platform independent, but the native code that understands the compiled script code is not platform independent.

I think all the United Bot discussions so far are starting out WAY to complicated and grandiose. You're trying to make it everything to everybody, instead of focusing on making it as minimal as possible and getting it running first. Once you have a minimal system working properly, then worry about adding on all the bells and whistles and kitchen sinks. Start with a simple small design and implement it (in working code, not on paper) to prove that it works. Then modify that design and implement whatever new feature you want to support.

If you start out today trying to design it so complex that nobody can agree on what it should be, you'll never get anything done.

botman

Re: UBotScript?
 

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.

Re: UBotScript?
 

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

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)?

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).

Re: UBotScript?
 

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.

Re: UBotScript?
 

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:
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 :)

Re: UBotScript?
 

ROFL :D
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 :D

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.

Re: UBotScript?
 

The example goals I wrote fit so lovely for a deathmatch environment because that's what I wrote them for :D 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 :)

Re: UBotScript?
 

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 ?

Re: UBotScript?
 

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

Re: UBotScript?
 

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 :)

Re: UBotScript?
 

You guess right. :P

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

Re: UBotScript?
 

I've got kinda group mobbing squads going on in my bot.. :) although if the leader is human they ccan tell them not to shoot, walk, crouch/prone etc..

Re: UBotScript?
 

lol. I tend to like the second 'hive' method better too. :D

Re: UBotScript?
 

This is going to be a universal bot, yes?
meaning support for every mod, past, present and future?
that means there could be features in future mods that the bots can't handle (using jetpacks is the first example I thought of). So would it not make sense to include support for OPTIONAL act and sense scripts? Include a standard setup that will work for most mods, but allow scripted 'addins' for extra things, like the jetpacks I mentioned, so that they don't have to re-compile the whole bot if something new is added?

Re: UBotScript?
 

that was the point of the UBotScript indeed, although I would have restricted it to the main think() function. But botman's point is that if it is coded neatly enough, it will be just as hard to write any script than to add functionality directly into the source code.

Anyway - I think it is more urgent now to define the game driver API (in another thread). If anybody has time on his hands he can open the discussion and start proposing things :)

Re: UBotScript?
 

agreed. Lets get a concept working first, later on we can think again about scripting or not.