AI and SWIG

[mihoshi]

So, question is - do we want a support of writing AI and/or event handlers on external script languages?

If yes, are we ok with just existing python binding, or it's good to add others (or improve binding to Python, at least)?

If yes, then using SWIG may be a good way. I tried binding AI on Lua with it, and it worked (partially) nice.

Good thing - it's really easy. It taked about 3k of hand-written c++ code. And if use Lua, it's +238k of liblua.a library.
Also, SWIG generates script interface that is very close to C++ interface, (and another script interfaces, generated from same swig file). So, AI designer will not have to learn different API in different languages, and will have a next to now limitations compared to if writing ai on C++.

Also, hand-written code for adding new language is not very small - 3k for Lua, and probably not much more for any other language, supported by SWIG (Java, Python, Lisp, Perl, Ruby, Ocaml, Tcl, etc.)

Now about what is bad. First - SWIG generate c++ code from interface definition file. It generates a rather lot of code for ai_interface - about 500k code and about same of stripped object file. That's mostly because SWIg tries to give script as many abilities as possible, but at the same way, as many protection. And if bind several language, that's about same size for each. That can be bad for compilation and linking speed, and exe size. May be that can be countered with exporting this code to dlls.

Second - SWIG somewhat struggles with some C++ advanced funstions. Especially with nested classes and templates. More important, target languages can also lack similar abilities.
That can be dealt with in two ways.

First - fix C++ AI interface with fact that it can be accessed from different languages in mind. That is, extract nested classess, limit using of typedef's and templates.
You can get a more full list here:
http://mapguide.osgeo.org/apicodingguidelines.html

This way, interface will be universal for C++ and scripts. Also, SWIG interface definition will be very simple and short - basically just list of headers to export. When you add new feature for C+++ interface, that will also be accessible to script languages too.

Second way - make some layer add another layer of interface. It's possible, but requires a lot of ugly layer code. And more when interface is extended/added.

There also can be some middle way - simplify c++ interface (that's mostly just "cosmetic" changes in header) and add glue where it's not possible.

If someone interested, I can post a code that I made so far (4k SWIG interface definition and 3k of Lua api). It can do things like reading info, but I stuck at the moment on nested class/template/out argument heavy part of issuing commands to units.

So, is it interesting, or not?

[allefant]

Using SWIG instead of the Python-C-API does sound like a good idea to me - mainly because it would mean the auto-generation of src/ai_python.cpp and therefore one file less to maintain A problem is that existing scripts would stop working, but I think there are few enough that they could all be translated to the new API as initial test case.

As for using Lua instead of Python (or allowing both, or allowing even more languages) - I think it's best to stick to one, for maintenance reasons - each supported language is another compile-time dependency after all, in addition to SWIG itself. It's also nicer for content maintainers if they have to deal with at most one scripting language in addition to WML. And personally, I would prefer to keep Python, because it's the nicer language. Of course, Lua does has the advantage that it supports "safe execution" without needing extra stuff, so that would make it not a bad choice as well.

[mesilliac]

In principal I think having a generic AI interface in C++ which is simply wrapped for scripting languages is a good idea.

The main stylistic thing I'd worry about is that it might not keep the "python" feel of the python API. Sometimes it's painfully obvious that a module is simply wrapping C/C++ to be accessible from python. A recent example I was playing with was pygame (which really should be called "python-SDL-bindings").

Another concern is that last time I tried to use SWiG for something it seemed that the code it output was long-winded and incomprehensible. This was a while ago though.

I think a better idea might be to clean up and properly comment the current python interface. It's not so bad, just a little disorganised.

[mihoshi]

Another concern is that last time I tried to use SWiG for something it seemed that the code it output was long-winded and incomprehensible. This was a while ago though.

I think a better idea might be to clean up and properly comment the current python interface. It's not so bad, just a little disorganised.

Code, generated by SWIG is really big, but I find it comprehensible enough.

And "a little disorganized" is a recurring problem of Wesnoth scripting. If WML was organized, may be we'll write AI on it instead of Python

So, I'll try to make a SWIG interface for Python. And may be also extend Python application for somthing else than AI

[allefant]

And "a little disorganized" is a recurring problem of Wesnoth scripting. If WML was organized, may be we'll write AI on it instead of Python

It's called "Formula AI" - so yes, that soon will work.

So, I'll try to make a SWIG interface for Python. And may be also extend Python application for somthing else than AI

Did you post your Lua patch btw.? I might look at it if it's ready, or in any case, post one for Python when it's at the same stage.

[mihoshi]

Did you post your Lua patch btw.? I might look at it if it's ready, or in any case, post one for Python when it's at the same stage.

No, it's not finished. I haven't enough time lately, I'll continue after 14th april.
Here is about all of it.
O'll post Python one when it is finished, of cause.