Using scripting languages for KDE4 main modules
mauricio at tabuleiro.com
Wed Oct 4 15:26:45 BST 2006
Just putting this discussion in the kdegames BoF context, we were mainly
contemplating the possible usage of scripting languages where they make
sense, for configuration, some AI routines, level design and
description, and themes. I believe no one was actually advocating the
possibility of writing full game engines in scripting at this time, even
with stable bindings. The consensus was to do more or less what is
already an established practice in the gaming industry: write your game
engine in C++, and use scripting for level description, AI and others.
KJSEmbed is a good candidate, of course. Except that I have to agree
with a previous poster: I do not know of any game scripted in
games and apps, so if you write a developer-friendly C++ game engine
with a JS scripting interface this could work nicely. There are bad
games written in Flash out there, but there are some masterpieces as
well, better than anything we have on kdegames currently, for example.
Taking the case of games in particular, if you examine the scripting
languages used currently for commercial game development you will find
that the most popular one is Lua, followed distantly by Python. Lua is
used extensively in games like FarCry (scripting all game events and
AI/game logic, both for single and multiplayer game, and for realtime
game editing), World of Warcraft (UI customization), Grim Fandango
(scripting), Psychonauts (whole game scripting and simulation), Baldur's
Reasons for using a scripting language like Lua in games specifically
are well known, as it is ideally fitted for data description and
implementation of finite state machines for AI. The discussion about
performance is not really applicable. Scripting is of course a resource
that has been proved valid in gaming, even on applications where every
performance optimization counts, as in the case of a FPS game like
FarCry. Developers know that 99% of the time is spent in the C++ game
engine anyway, the memory overhead of the Lua interpreter and the script
execution time is insignificant given the advantages offered by the
ability to control the whole game simulation via scripting. Using
scripting in this way is an established practice in the games industry.
Notice that I am not advocating the usage of Lua specifically in
kdegames, as it has some technical disadvantages as well in the specific
context of a project like KDE. And basically because there is not (yet)
a need for it, so I do not want a hammer if there are no nails to hit.
But for longer term planning we discussed in the BoF the possibility of
converting 20 games to maybe 3 or 4 game engines, and driving the
simulation via scripting. It will not happen now for KDE4, but it may
happen in the future, and open the door for more user contribution.
For educational applications Python or Ruby are probably better suited,
I imagine. But for the reasons explained above (and others) I believe
forcing one scripting language standard of course is not going to work.
No one has even talked about Lua in the thread for example, and it is
practically the standard scripting tool used in the gaming industry.
We should however make it clear that scripting should be used where it
makes sense, as in the game engine scenario above, Krita plugins, etc.
Writing a whole game in PyGame just because the developer does not know
C++ does not qualify, imo. Scripting should be a choice that comes
naturally because it is better for the application, not a way of simply
lowering the barrier for code contribution artificially, otherwise we
will probably simply end up with bad scripting code.
More information about the kde-core-devel