mvBarracuda
Augur
- Joined
- Jun 7, 2006
- Messages
- 478
I would like to explain the whole idea in more detail but unfortunately I'm dead tired so here is the short version:
We were recently brainstorming about the scripting API changes for the upcoming FIFE 2007.2 release. We did realize that the whole scripting API concept will heavily depend on if we stick to the current "embed Lua as scripting language"-approach or if we switch to an "extend a scripting language (e.g. python) with C++ engine code"-approach.
While we're sure that changing to an extend approach would give developers who would like to use FIFE for their games new possibilities, going down this route will also mean to throw away quite some code that is already in place. Even more important we would need to redesign certain parts of FIFE after the release of the 2007.2 milestone so we could wrap it up nicely into python.
If anybody is interested in the whole approach, there is proof of concept code in one of our SVN branches:
http://mirror1.cvsdude.com/trac/fife/en ... wig/engine
To wrap up this example code into python, see the commit message posted here:
http://mirror1.cvsdude.com/trac/fife/en ... geset/1185
We would like to hear feedback from the python gurus who browse the codex if the whole approach appears to be worth a try as long term solution. For the not so tech-savvy guys and girls: this would mean you could develope your FIFE-based game in python.
Feedback please. And let me know if you need more information about the whole concept, I don't write code for FIFE but I hope I understood the whole concept well enough to further explain it here if questions arise.
We were recently brainstorming about the scripting API changes for the upcoming FIFE 2007.2 release. We did realize that the whole scripting API concept will heavily depend on if we stick to the current "embed Lua as scripting language"-approach or if we switch to an "extend a scripting language (e.g. python) with C++ engine code"-approach.
While we're sure that changing to an extend approach would give developers who would like to use FIFE for their games new possibilities, going down this route will also mean to throw away quite some code that is already in place. Even more important we would need to redesign certain parts of FIFE after the release of the 2007.2 milestone so we could wrap it up nicely into python.
If anybody is interested in the whole approach, there is proof of concept code in one of our SVN branches:
http://mirror1.cvsdude.com/trac/fife/en ... wig/engine
To wrap up this example code into python, see the commit message posted here:
http://mirror1.cvsdude.com/trac/fife/en ... geset/1185
We would like to hear feedback from the python gurus who browse the codex if the whole approach appears to be worth a try as long term solution. For the not so tech-savvy guys and girls: this would mean you could develope your FIFE-based game in python.
Feedback please. And let me know if you need more information about the whole concept, I don't write code for FIFE but I hope I understood the whole concept well enough to further explain it here if questions arise.