Time for yet another update here :-)
The progress of the last two weeks is quite encouraging. We've decided to give the extend approach for scripting a try in a separate branch but it looks like that this branch will replace our current trunk version quite fast. The work on it isn't finished yet but it seems that the performance drawback of the extend approach should be bearable; some initial tests (although with work in progress code and just on tested a Linux system) did show almost no performance drawbacks at all.
For anyone who's interested to know more about it and is not afraid of playing around with some work in progress code, check out our extend branch in SVN:
branches/active/extend
One major advantage of the extend approach in combination with <a href="http://www.swig.org/">SWIG</a> is that you'll be able to get FIFE running with bindings for your favourite scripting language quite easily. We do currently play around with Python support and that works quite well. Additionally we'll maintain support for Lua bindings as Lua was our language of choice before we decided to try something different than embedding the scripting language into FIFE. It shouldn't be too hard to create Ruby or OCaml bindings for FIFE either and if we find somebody who maintains these bindings, they'll find their way into our Subversion repository so you won't even need to invest time to generate the bindings yourself (although SWIG makes it rather easy in most cases).
Here is a nice screenshot from one of our recent test sessions. It shows the FIFE console that now can execute Python code e.g. for ingame manipulations or debugging your FIFE-based game:
Besides the work on the extend branch we're currently trying to fill our wiki with use cases for some possible FIFE-based games. That's because we intend to tackle the design of our scripting API after the work on the extend branch has finished. There is already a pretty small API in place but as it was written as proof of concept and for doing initial scripting tests it is neither consistent nor feature-complete. So we're trying to collect some real game examples first, analyze them concerning their requirements for a scripting API and plan to come up with a consistent design for our API after that.
If you consider to use FIFE for an own game in the future feel free to lend us a hand by contributing to the use cases. And don't be afraid: there are already a bunch of examples listed there that should make it easy for you to get started. If you would like to contribute but don't understand the concept of the use cases or got other related questions feel free to ask them here or at the talk page of our use case wiki article:
Use cases for the FIFE scripting API
And last but not least we're still searching for interested programmers who would like to collect some experience working on a rather large scale group project :-) And we're usually kind guys and don't bite so if you want to find out more about us before you sign a lifetime contract with us feel free to visit our irc channel :-)
#fife @ quakenet