UBotScript?

[botmeister]

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.

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.

[stefanhendriks]

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.

[FrostyCoolSlug]

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.

[@$3.1415rin]

XML isnt that difficult as well

[Killaruna]

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

[FrostyCoolSlug]

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?

[Pierre-Marie Baty]

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.

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

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 ?

[Pierre-Marie Baty]

*bump*

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

[botman]

"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