AI interface in Python?

[hughperkins]

Hi, it's been a while

For those who are new here, I built an AI in C# a few years ago, for TASpring. http://springrts.com/wiki/AI:CSAI

I'm feeling the 'itch' to have an AI I can play with again. I learned a number of lessons last time.

AIs are basically not used unless they can be delivered as part of the binary releases. Anything too far from being non-standard renders this difficult to impossible. Anything which requires compilers other than C++ on the build box renders this difficult to impossible.

I'm thinking of building a new interface that will allow AIs to be written in Python.

Python is fairly widely distributed. For example, it is part of the Ubuntu default build, at least from Hardy onwards, which is a good year or so.

This contrasts with C#.Net, which doesn't even run on linux, and mono, which is potentially patent-encumbered, and Java which doesn't come by default, at least not the jdk, and the jdk is fairly heavy to install.

I'm thinking of possibly rewriting my generators that were in C# before in C++, and using xml as an intermediate parsing language, ie parse the Spring globalai header files et al into xml, and then use those xml files as the basis for generation of appropriate c++ <-> python interfaces.

In the past it was really hard to specify the AI to use from the Lobby interface, when one had multiiple C# AIs, since they all went through the same intermediate dll. I think maybe I'll have some way of creating tiny wrapper AI dlls that handle loading the appropriate python script somehow, maybe based on their name , on an xml file, something like that.

Python is quite cool as far as release distributions go, since the python scripts can be released with the distribution without being compiled, since they are interpreted later, so there is no need for some kind of python compiler on the build box. This contrasts with both Java and mono, for which this would be potentially a blocking point for their being included in the releases.

Python is not as fast as java or c#, but it's not too bad. It has the advantage of being fairly concise, fairly easy to write, fairly widely known and available, and not patent encumbered. It's fairly lightweight, compared with installing the jdk or mono-devel.

So, this is just a statement of my potential interest in this. This post is to obtain feedback on:
- ideas and concepts expressed above
- possible tweaks to implementation / execution, compared to ideas expressed above
- how does this idea fit into a world where lua AIs are possible? Are there Lua AIs now? Will there be in the near future (1-3 months, let's say) ?
- what about the java / oo AI interface? What is the situation with that? Is it operational or near operational (>= 99% operational let's say, since 90% operatoinal is in practice about 40% operational most likely otherwise someone would already have done that last 10% right? )
- other thoughts / concepts / ideas?

Remember that it's easier to influence the direction of such an interface before I've written a single line of code, than once I'm half way through, or once I've started to think through implementation in detail.

Hugh

[SpliFF]

I see two issues with this:

* Python is pretty 'heavy', both in terms of install size and processing overhead. That isn't to say efficient code can't be written using list comprehension, lambdas, maps, etc but that tends to cancel out pythons main advantage - clean code and legibility.

* Python updates regularly and breaks the ABI. You would probably find you need to have a separate module for 2.4, 2.5, 2.6, 3.0 and 3.1 as all of these versions are currently in use and most distributions will only have 1 of these.

Python's greatest strength is its access to comprehensive libraries for web, email, system operations, etc. The AI doesn't need these.

Lua is far more practical and not a lot harder to learn, and I say that as somebody fluent in both languages. Anyone interested in game development could do worse than learn Lua. It seems fairly certain that LuaAI and C++ will become the primary AI languages for Spring and Java/.Net extensions are really only of value to people porting existing code.

If I were going to do this I'd definitely approach it through an automated wrapper like SwiG. Anything less than near-total automation will make maintaining this interface a chore since you would need to rebuild your modules everytime python or Spring changes.

[imbaczek]

java ai interface + jython should work, if that suits you.

[Agon]

Welcome back hughperkins,

Lua AIs are possible.
AIs have config files, now. So no problem with different languages interfaces. They work also in SpringLobby.

Python is nice for doing small things fast.
But Spring requires much CPU resources so you only have a small amount left for AIs (its similar in other games), then deciding to use one of the slowest languages (VMs) limits the possibilities of writing CPU intense algorithms.

As for Java, I think the Java interface is near to 'stable' and hoijui is supporting the AI and especially the Java interface.
Also the Java OO wrappers seems to be good helpers.

As for C++. Well its basically the best choose for an AI thinking of speed.

Last C#. I worked on an Mono interface. It was nearly finished to a beta stage where first simple none OO commands could be run. Basically the callbacks from C# did not work.
Hello engine was possible .
Mono is installed standard on openSUSE and I think on Ubuntu, too.
Since some C# applications are available for Gnome.
The .Net world has IronPython btw. but it is slower as the C (?) implementation in some ways. Or take a look at Boo which is similar to Python. A Mono interface based on the newest changes should be doable in 100 hours depends on C and Marshalling knowledge. It tooks me some months (including learning to manage C and Marshalling).

[Kloot]

There have been Lua AI's for quite some time, which have more info more easily available to them than traditional AI's bound to an external interface. Python AI scripts would be as limited as native AI libs, so I wouldn't say you'd get much return of investment out of it.

[hoijui]

reading your post, it seems to me you dont know much of the current workings of the AI interface. the GlobalAI files eg, are nothing you have to deal with when creating an AI language interface.

the best you could do, in my eyese, is what imbaczek suggested.

if you really want to do a separate phyton interface...
have a look at the code under rts/ExternalAI/, but really important is only the one under rts/ExternalAI/Interface/ for you. Then of course the Java Interface code is something you should have a look at (AI/Interfaces/Java/).
also have a look at the Wiki:
http://springrts.com/wiki/AI:Development:System
http://springrts.com/wiki/AI:Development:Interface

I can tell you, and Agon will confirm it , that it is not much fun writing an AI interface. of course you can do a lot of automation, but .. there is lots of stuff you have to hand tweack afterwards. of course it can be automated as well, but often it is code you have to write to change a single line in the automated code.

also...
the build system for the java interface works like this (and hte phyton one would have to be setup the same way):
you can manually disable all Java AI stuff, or if the JDK is not found, there is a warning message on cmake configure, and no Java AI stuff is configured/compiled then (neither interface nor AIs).

also, it is not really so important how much non-default stuff you have to install on the build system, as this is usually just hte buildbot, the package maintainers, hte interface maintainer and maybe a few AI devs. it is more important what additional packages the users had to install. mainly interesting on linux, as on windows, we have the library packages, though big things like the JDK are of course not included there.

in addition to jython, there are many other languages running on the JVM. i personally tried JRuby, Groovy and Bean Shell Scripts, which all work fine as an AI.

there are quite some Java AI projects in the makings, and quite a lot of bugs have been fixed already.
i can not really say how operational it is, as i have never personally seen a Java AI playing a game. but i have at least 4 guys that report to me from time to time, report bugs, and tlel me the state of their projects.

[echoone]

Did anything move forward with the Python AI effort?

I'm curious why SWIG wrappers were not created to allow for Lua, Java, and Python bindings. I read in one thread there were issues attempting to use Lua with SWIG but those were dated back to 2007. And, based on those comments, suspect the issues stemmed more from SWIG's poor documentation rather than a technical issue.

Also, since Boost is already being used, would Boost Python be considered?

As for those looking to discount Python because of "slowness" issues, I'm actually not worried about that. For one, Python (stackless) is commonly used for AIs, including in some MMORPGs. Python was also used for a while in Wesnoth. Support for Python was eventually redacted because of political/security concerns (their AI distribution methods, etc) - not performance or technical concerns. And I know this because I was one of the developers. Not to mention, the bag of tricks available to Python to address performance issues is actually deep and wide. Simply put, performance is not a concern - until proven otherwise - and then you reach into your bag.

I posted and decided I wasn't done here. As for ABI concerns, just pick a version which is supported. For now, 2.6.x is likely what we want. ABI concerns no longer an issue. And if someone wants to support another version, they can compile it themselves. Projects like Blender tend to support 2.5 and 2.6 - but IMHO, just supporting 2.6 for now is enough. Bluntly, 3.0 should not be supported and a stable 3.1 is still pretty far off - last I read. Besides, supporting 3.0 and 3.1 likely means significant AI changes; to which some automated script updates are possible.

And so - what became of this?

[hughperkins]

Personally I started using hoijui's Java interface instead, since it is also platform-independent.

As imbaczek says, Jython should probably work fairly easily using the already-existing Java interface?

If you want to write a native interface in Python, I would be happy to use such an interface to play with.

I'm not actually planning to write a native Python interface myself though. I feel the Java interface is pretty good, and very well maintained. The only bit that is a bit 'iffy' I feel with the Java interface is JNA speed, which is pretty far from fast I feel, but it's not I feel an insurmountable issue, and I think hoijui has been looking into doing some optimizations to make it faster (they may already have been done in fact, I'm not sure?).

Looking at your post, do you know that Stackless Python is single-threaded? Yes, you read that right. Ok, so Stackless Python uses 'green' threads to pretend to run lots of threads all at once. For many definition of the word 'thread' stackless Python really is multi-threaded, however for one crucial one: can the 'threads' run on multiple processors at the same time, it generally is not I think, because there is a Global Interpreter Lock that means that Python processes are by and large single threaded.

I haven't looked into stackless in very much depth, so feel free to correct me. I'd be very happy to be wrong.

In the meantime, I did a project the other day to write a truly multithreaded Python, using Erlang-type semantics, and full os processes as each thread:

http://manageddreams.com/python-threadingx

[hoijui]

as hugh explained, it is already possible to do Java and Phyton (with jython) AIs, and Lua AIs are supported since before Java ones even. The Lua interface is very different though, form the one of the other languages.
As for the speed in the Java interface, yes, i am workign on that, but my general motivation to do anything is so low these days, that i hardly get further with it. Also, it is jsut AWK scripting left, which is very ugly even for me, who wrote the scripts .

[echoone]

Personally I started using hoijui's Java interface instead, since it is also platform-independent.

Looking at your post, do you know that Stackless Python is single-threaded? Yes, you read that right. Ok, so Stackless Python uses 'green' threads to pretend to run lots of threads all at once. For many definition of the word 'thread' stackless Python really is multi-threaded, however for one crucial one: can the 'threads' run on multiple processors at the same time, it generally is not I think, because there is a Global Interpreter Lock that means that Python processes are by and large single threaded.

Stackless is technically a different beast - but yes, I know. I've very well versed in threading on Python, as well as the associated issues. I've ported Python to other platforms, which does include the low level threading module, on which Python depends.

I haven't looked into stackless in very much depth, so feel free to correct me. I'd be very happy to be wrong.

I'm actually not interested in supporting stackless - and technically stackless uses co-routines so as to avoid context switching overhead - but I digress. My point is Python is very capable in its own right and dismissal of Python based on simple hand waving is seemingly inappropriate given Python is well proven for AI use. This is true for both stackless and CPython. And especially true given traditional relative performance of Lua to CPython.

In the meantime, I did a project the other day to write a truly multithreaded Python, using Erlang-type semantics, and full os processes as each thread:

It likely uses the multiprocessing module. While Python does have the GIL, but it is very much a misnomer to state python is strictly single threaded. In fact, its technically incorrect and extremely misleading given the context here. I do not believe this is the place to debate Python's threading semantics. Regardless, multiprocessing and multithreading, the later of the two with some caveats, are both available to coders and both can provide for concurrency.

I will say, a typical AI (at least in Wesnoth; I've not reviewed the interfaces here) spends a considerable amount of time within the engine itself in an effort to either obtain state or to update state. Every call into the engine from the AI means multiple threads of execution are possible. This traditionally means at least two concurrent threads are possible. And, depending on the AI implementation, higher levels of concurrency are obtainable. Using a Wesnoth AI as a reference, I was able to increase AI performance roughly 20% with an extremely modest amount of AI code changes and relatively minor tweaks to the python bindings; neither of which were written with concurrency in mind. This strongly suggested far high levels of concurrency are available even with Python's threading module. Simply put, AI use with Python, from a concurrency perspective, is ripe for opportunities. And that's not even mentioning the multiprocessing module. With good use of the multiprocessing module, its likely each Python AI can run in its own process; providing for high scalability.

Don't let popular threading and concurrency Python myths confuse you about what's possible.

[hughperkins]

It likely uses the multiprocessing module.

Oh, good info! In fact it doesn't use this, but it probably should. Interesting module!

[echoone]

as hugh explained, it is already possible to do Java and Phyton (with jython) AIs, and Lua AIs are supported since before Java ones even. The Lua interface is very different though, form the one of the other languages.
As for the speed in the Java interface, yes, i am workign on that, but my general motivation to do anything is so low these days, that i hardly get further with it. Also, it is jsut AWK scripting left, which is very ugly even for me, who wrote the scripts .

Jython has library limitations, compatibility issues, functional semantic differences, and is drastically lagging behind in development parity. Its likely to be many years before Python 3.x is supported by Jython, let alone Python 2.6. It also typically experiences its own class of bugs and issues. Its only significant attraction is that it can be JITed - and in this case, an available interface. Jython has little to no interest for me. Frankly, Java holds little to no interest to me despite that fact I spend considerable time coding in it.

So I think its safe to say no SWIG interface for any language bindings currently exists? What about Boost.Python around the C++ bindings? Would such an effort (Python bindings that is) be accepted into mainline? Which is not to say I'm stepping up to the plate. Right now, I'm just exploring.

I'll also add, I have experience using both SWIG (C/C++ -> Python) and Boost.Python. The only reason we used SWIG is because our C++ compiler was choking all over modern C++ code/templates.

[echoone]

It likely uses the multiprocessing module.

Oh, good info! In fact it doesn't use this, but it probably should. Interesting module!

Ya, very neat. This is off topic but I can't resist. And if you don't know, do checkout Python's "with" keyword. Concurrent locking with "with" is extremely savvy - in line with using scoped locks in C++.

Code: Select all

# Locking is auto-magically handled
# True for threading or multiprocessing
myLock = multiprocessing.Lock()
.
.
.
with myLock:
  accessProtectedResource()

[hoijui]

in spring, there is only one thread that will call to AIs, you also have to call back to the engine wiht the same thread.

about your question if phyton bindings would be accepted.. that is not really a question, such bindings would have to be implemented as a plugin anyway, so even if it would not be accepted (which it surely would be, if it is usable/kind of stable), it could still be easily supplied as a separate package.
you should probably look at the code how the AI interface works, or have a look here:
http://springrts.com/wiki/AI:Development:System

[hoijui]

about SWIG:
i did use it in the past, here and in other projects, but back when i started here, it was too ugly, as the interface was in C++, and there were a lot of special cases.
now, the interface is C and relatively simple, so SWIG could be used. it is still not used, but AWK instead, because: The part of the interface wrapping that could be done with SWIG is a really simple part, easily done, small, simple and fast running wrapper generation code, plus the generated code is more tidy/optimized. For the much more complex other part, we would need an other tool anyway (AWK is about the most simple tool that can do it). This is the heavy work; much more complex code, more bugs, more problems, more adjustments over time, ...

there is an interface refactor on the way. it will mainly change the Java AI Interface, but also the C interface will change a bit, though not the gerneal design (mainly: functions renamed, parameter addded/removed, .. such stuff).
if you have questions about the AI interface, and i am online, it is probably best to ask me, as i am the one most into it.

[echoone]

in spring, there is only one thread that will call to AIs, you also have to call back to the engine wiht the same thread.

That's pretty much what I expected. That's the same for Wesnoth. Because of the potential lack of thread safety in any number of other functions, its simply not safe to make any other assumption.

about your question if phyton bindings would be accepted.. that is not really a question, such bindings would have to be implemented as a plugin anyway, so even if it would not be accepted (which it surely would be, if it is usable/kind of stable), it could still be easily supplied as a separate package.
you should probably look at the code how the AI interface works, or have a look here:
http://springrts.com/wiki/AI:Development:System

Thanks. Glad to hear.

I've been checking it out. I've been reviewing the Java Interface, specifically the bridge code. It appears there are many parallels in the Java setup as to what would be required for a Python setup.

Also, please allow me to be sure I understand how this all works. The interface proper is compiled as a shared lib (dll) which is dynamically loaded by the engine. The engine does so by means of locating libAIInterface.so in the .../AI/Interfaces sub dirs. Or does it use a resource file to tell it about the interface? Or am I over thinking this?

From here Skirmish AIs, in this case it would be a python script name, are handed to the Interface to load with a team number, or some such thing, where the Interface proper can finish setting up the environment and/or context for the given script to run.

Somewhere I saw a thread which detailed all the structures, constants, etc., which needed to be exposed, but I'm having trouble locating it again.

Am I on the right page here?

[echoone]

about SWIG:
i did use it in the past, here and in other projects, but back when i started here, it was too ugly, as the interface was in C++, and there were a lot of special cases.
now, the interface is C and relatively simple, so SWIG could be used. it is still not used, but AWK instead, because: The part of the interface wrapping that could be done with SWIG is a really simple part, easily done, small, simple and fast running wrapper generation code, plus the generated code is more tidy/optimized. For the much more complex other part, we would need an other tool anyway (AWK is about the most simple tool that can do it). This is the heavy work; much more complex code, more bugs, more problems, more adjustments over time, ...

No problem. Don't take my comment negatively. I couldn't find any .i files so I thought I'd ask. I just thought if a swig definition was in use, and I found plenty of posts talking about it, it would serve as a spring board for Python.

there is an interface refactor on the way. it will mainly change the Java AI Interface, but also the C interface will change a bit, though not the gerneal design (mainly: functions renamed, parameter addded/removed, .. such stuff).
if you have questions about the AI interface, and i am online, it is probably best to ask me, as i am the one most into it.

What implications does this have for would-be new Interfaces? From what I can see, it appears there are only a small handful of functions exposed in the bindings. Is there something else I need to look at?

As a side note, why is a void pointer being tossed around for the interface? I'm curious and not trying to step on anyone's toes here. By using a void pointer, type safety is lost, etc., etc., ... not to mention frequently incurs binding headaches and/or runtime overhead. Why not use a union, class, or some such concept to pass that stuff around?

[hoijui]

The interface proper is compiled as a shared lib (dll) which is dynamically loaded by the engine. The engine does so by means of locating libAIInterface.so in the .../AI/Interfaces sub dirs.

yes

there is an interface refactor on the way...

What implications does this have for would-be new Interfaces? From what I can see, it appears there are only a small handful of functions exposed in the bindings. Is there something else I need to look at?

The C interface will change a bit, this means, stuff under rts/ExternalAI/Interface, namely AISCommands.h, AISEvents.h and SAIInterfaceCallback.h. as youll see, all these contain some kind of listed up stuff (list of command, list of events, list of callback functions). the general format of these files will remain the same, but some list members get altered, added or removed.
the only thing that will change, is the meta comment format.
for a direct comparison, you can have a look at the pureint branch on the main spring repo on github (it is not usable yet, but this part is mostly done).

As a side note, why is a void pointer being tossed around for the interface? I'm curious and not trying to step on anyone's toes here. By using a void pointer, type safety is lost, etc., etc., ... not to mention frequently incurs binding headaches and/or runtime overhead. Why not use a union, class, or some such concept to pass that stuff around?

i guess you are talking about this:

Code: Select all

int (CALLING_CONV *handleEvent)(int teamId, int topic, const void* data);

right?
the void pointer can contain one of the structs in AISEvents.h. i wouldn't know how to pass them through a generic function without a void*. Keep in mind that this is C, not C++, so there are no classes, and there is no inheritance.

feel free to ask more.

[hughperkins]

I feel it would be really awesome if there was a Python AI interface! Can't wait to see what happens in this thread.

[echoone]

The C interface will change a bit, this means, stuff under rts/ExternalAI/Interface, namely AISCommands.h, AISEvents.h and SAIInterfaceCallback.h. as youll see, all these contain some kind of listed up stuff (list of command, list of events, list of callback functions). the general format of these files will remain the same, but some list members get altered, added or removed.
the only thing that will change, is the meta comment format.
for a direct comparison, you can have a look at the pureint branch on the main spring repo on github (it is not usable yet, but this part is mostly done).

By C interface, I guess you mean the interface to which all AI Interfaces must use? And/or skirmish interfaces?

I'll have to take that in to better understand the implications and the relative amount of work if I were to start this rolling.

i guess you are talking about this:

Code: Select all

int (CALLING_CONV *handleEvent)(int teamId, int topic, const void* data);

right?
the void pointer can contain one of the structs in AISEvents.h. i wouldn't know how to pass them through a generic function without a void*. Keep in mind that this is C, not C++, so there are no classes, and there is no inheritance.

feel free to ask more.

I guess I would be expecting something like this:

Code: Select all

  /**
   * Union of all event structures to maintain type safety.
   */
  union AIEvent {
    int team ;

    // Always carry the topic with the event, which must be of
    // type EventTopic.
    int topic ;

    // And so long as this structure is not being serialized
    // we can use the actual type which is even more type-safe
    // and future proof.
    // EventTopic topic ;

    struct SInitEvent init ;
    struct SReleaseEvent release ;
    struct SUpdateEvent update ;
    struct SMessageEvent message ;
    struct SUnitCreatedEvent unitCreated ;
    struct SUnitFinishedEvent unitFinished ;
    struct SUnitIdleEvent unitIdle ;
    struct SUnitMoveFailedEvent unitMoveFailed ;
    struct SUnitDamagedEvent unitDamaged ;
    struct SUnitDestroyedEvent unitDestroyed ;
    struct SUnitGivenEvent unitGiven ;
    struct SUnitCapturedEvent unitCaptured ;
    struct SEnemyEnterLOSEvent enemyEnterLOS ;
    struct SEnemyLeaveLOSEvent enemyLeaveLOS ;
    struct SEnemyEnterRadarEvent enemyEnterRadar ;
    struct SEnemyLeaveRadarEvent enemyLeaveRadar ;
    struct SEnemyDamagedEvent enemyDamage;
    struct SEnemyDestroyedEvent enemyDestroyed ;
    struct SWeaponFiredEvent weaponFired ;
    struct SPlayerCommandEvent playerCommand ;
    struct SCommandFinishedEvent commandFinished ;
    struct SSeismicPingEvent seismicPing ;
    struct SLoadEvent load ;
    struct SSaveEvent save ;
  } ; // Union AIEVENT

Which now provides for the possibility of:

Code: Select all

int (CALLING_CONV *handleEvent)( union AIEvent *data );

And since we don't have classes, and if we want to be really clever, we can create a union factory function of something like:

Code: Select all

union AIEvent *createEventUnion( int team, EventTopic topic ) ;

Which behind the scenes [c/m]allocs the union but also sets the team and topic. That pretty much eliminates human error (whereby errors, if any, are always localized to the event construction/initialization, making them very easy to find) and saves the manual initialization step which would otherwise follow. Plus this implementation allows for type safety without recasts, which is then extends all the way to AI Interfaces and their associated bindings; limited by the binding language, as in no void pointer. An example use would be:

Code: Select all

union AIEvent *aiEvent = createEventUnion( team, EVENT_UNIT_CAPTURED ) ;
.
.
.
handleEvent( aiEvent ) ;

And yes, that really all did jump out at me as soon as I saw the use of "void *" for an overloaded reference to a well defined set of structures. And of course, the union can always be typedef'd to make reference of the union more natural.

Void pointers always means one or more recastings later, which is one more chances for human error. Me being very human means I've been bitten many times over the years by void pointers. As such I try to avoid them wherever possible.