Welcome to wesnoth.
I am not much of a python person, so I will let those who are more
closely involved with the python bindings answer those questions. I
have, however, been working on a new C++ AI that will add a lot of
flexibility via WML, and I have been thinking about some of the issues
you have raised involving running the AI from the command line and
training it, so I will try and answer those as best I can..
> * I have to figure out some practical stuff and I'm hoping you guys can
> help me shed some light on them.
we will certainly try...
> I read a little bit about restricting python. I do like
> reviewing/renaming solutions but personally I don't like technical
> restrictions. Python being powerful/versatile makes it a nice language
> for doing research with (you can hook into all kinds of existing stuff,
> you can quickly prototype something). IMHO you probably can't restrict
> any c++ AI so IMHO considering restricting python AI's but not c++ AI's
> seems inconsistent. Also it's not like there are lots of python AI's
> available for wesnoth so the reviewing/renaming solution probably
> doesn't add much to the workload of the volunteers who do this.
The difference between the C++ AI and the python AI is that the C++ is
essentially restricted at compile time. If the program is well
behaved when it is distributed, there is no particular problem. Since
the python AI is interpreted, however, it is conceivable that someone
could execute malicious code unwittingly. Ok, so the individual would
have had to have downloaded the campaign/whatever that had the
malicious python in it, but what it comes down to is that the user
made content server is not policed the way that the C++ code is.
Anyone can upload content to the campaign server and malicious code
might reside there for quite some time before anyone noticed it,
especially if it was careful to hide its tracks. That said, I don't
really know much about the plans for restricting python.
> * I think it's possible for games to be played within a few minutes. I
> did some testing with default AI's which confirms this (starting from
> command line games take roughly 10-80 seconds). My research AI will
> probably be a bit more time consuming than this default AI but I think
> I'm safe here.
This certainly should be possible.
> * As I understand it each turn the AI is re-initialized. Assuming
> set_variable() and get_variable() will only work for variables and not
> for (more complex) objects,dictionaries,lists,lists of lists (matrices)
> this will mean I have to pickle my objects and matrices. Assuming that
> importing cPickle is allowed this will probably mean an overhead in the
> order of seconds per game. (IMHO it would be nicer if you force python
> AI's to implement a save and load function but that approach might have
> the drawback of a slightly steeper learning curve)
One thing that I implemented in the AI for the C++ is a memory that is
saved from turn to turn. Basically any WML construct can be saved for
use in future turns. The memory is split by team so that each AI can
remember different things. I don't know if the python has any
bindings to use this yet, but I think that it would be good if they
did.
> So here's a list of practical stuff that's not yet clear to me :
>
> * if python will be restricted somehow in the future will I be able to
> turn this of by compiling wesnoth with --unrestricted-python ?
That seems like a reasonable request, but it will depend on how
difficult it is to code the python restrictions.
> * Do you think I should run the 1.3 development branch of wesnoth or
> the 1.2 stable branch of wesnoth ? Why ?
Well, it will depend on exactly what you want to do. There are
definitely several nice features that have been added since 1.2, but
on the other hand, several things are in a pretty major state of flux
right now in 1.3. Looking through the change log since 1.2 for
python related things results in this list:
[code]
* increased required version of python from >=2.3 to >=2.4
* fixed detection of installed python versions to work on systems that do
not have python installed at /usr/ (like MacOSX using fink)
* Python AI
* Added various input validations
* Set Python errors upon error
* added support for optipng optimization in the compilation process
[/code]
Personally, if I were you, I would use the latest development version
at the time you actually start doing serious coding. It will probably
be easier to get devs to make any changes that are needed by you on
the development branch then on the stable branch. But then again, I'm
a bleeding edge type of guy.
> * Is there some way for the python AI to know when the game is finished
> ? It's really important to have something like this because without this
> it makes it really hard to make your AI actually learn.
> I would like to know at which place I (the current python AI) is
> finished and I would need to know how much players were in the game
> (finishing 2nd out of 2 players is bad whereas finishing 2nd out of 8
> players is quite good). Most learning probably happens after a game is
> finished.
I don't believe that this is possible the way you have described it.
What can be done with very little modification, however, is to make
sure that the final state is saved at the end of the game and then
whatever script you are using to run wesnoth from the command line
could analyze the save game to determine how to modify the AI
parameters.
> * To be specific : I would like to have the following "finishing stuff"
> : knowing whether or not the game is finished, knowing which place I
> finished at (knowing the place of all players would be nice), knowing
> whether the game is started from command line(all time available) or gui
> (less time available either enforced or just make sure not to use too
> much time),being able to do some computation when the game is finished
Again, I think the simplest way to do this for your research is to
have a script running wesnoth in command line mode and analyzing the
save game outside of wesnoth itself.
> * Consider the following 2-player example if I would use some basic
> reinforcement learning technique (such as q-learning) I can give a
> positive reward to all my actions when I'm finished at first place and a
> negative reward for all my actions for finishing 2nd place. Giving out
> this reward probably isn't computationally heavy but it needs to happen
> after the game is finished.
see above.
> * Consider another (2 player) example. My python AI plays against the
> default AI but after the game is finished I apply some Machine
> Learning/Statistical technique to find interesting places on the map.
> This can actually be computationally heavy if needed because ideally it
> only needs to be done once for each map and it can be done offline by
> me. The stuff you learn here can be used "online" in the map specific
> part of my AI.
still consistant with doing the "learning" portion outside of wesnoth proper.
> * When running wesnoth from GUI python AI's should make sure not to use
> (too much) noticeable time.
Yes, but I wouldn't worry about this too much. If you are planning on
running a lot of iterations in order for the AI to learn, you are
going to want it to be pretty fast to begin with.
> * When running wesnoth from command line the allowed time for
> computation after having finished a game isn't important because human
> players don't see this. Only some AI developers would use it.
Again, if you do this from an external script, this is not a problem.
> * If this "finishing information" doesn't exist can this be included in
> the next development version of Wesnoth ?
I think it would be quite possible to add in an end of game '-save
filename' argument for command line use. I have pondered adding it
myself previously but have put it off until my own AI actually needs
it. If it turns out that this is something that you need, I could
push it up on my priority list. I don't really know about adding in
an end of game python AI analysis call.
Good luck.
John (aka Darth Fool).
--
-------------------------------------------------------------------
"In theory, theory and practice are the same,
but in practice they're different."
-------------------------------------------------------------------
John W. C. McNabb
-------------------------------------------------------------------
_______________________________________________
Wesnoth-dev mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-dev
