On Thu, Nov 25, 2010 at 10:31:56AM +1000, Jude wrote:
> On Thu, Nov 25, 2010 at 4:04 AM, Tom Lippincott
> > I was wondering if anyone is actively working on making the scripting
> > interface more comprehensive. I've had some luck using SWIG to
> > auto-generate a Python API, and since its also capable of generating
>
> That sounds interesting. I'm not sure what the side-effects of
> requiring Python would be, and the majority of our external scripts
> are written in Lua.
I strongly object to adding a yet another obscure scripting language to our
already extremely messy code.
We already have:
* C++
* lua
* perl
* make
* ruby
* LaTex
* lex
* yacc
* shell
You need to know all of them if you want to have a chance at understanding
the code that touches appropriate parts.
If we disregard the build system, substantial parts of Crawl proper are
written in just two: C++ and lua. That's already one too much.
Note that introducing a language needed at runtime would also decrease
portability, especially for cell phones.
> > Lua, it might be a good way to get access to more internals (and produce
> > better documentation as a side-effect), but I don't want to duplicate
>
> I'm honestly not experienced enough to comment on how well SWIG works
> for generating Lua code. The issue that I can foresee with automatic
> generation basically revolve around the fact that we have two Lua
> "virtual machines" (I forget the proper term here), one for
> user-accessible Lua (macros, etc), which has to be locked down tight
> in order to avoid leaking information, and the dungeon-accessible Lua.
Could you mention which of these parts do you want to extend?
If it's about Crawl's internals (dungeon building, scripts attached to
monsters and/or vaults), I'd say it's a straight no-no -- both for live
Python and for generated code.
For client scripting, though, the matter is different. I'd still object to
having python added to Crawl proper, however it may be possible to make it
easier to run client scripts in other language -- emphasis on "language_s_"
rather than "language". Ie, allowing binding to functions exported by Crawl
instead of using a language-specific interface. I have never used SWIG, but
at a glance, it seems to be able to generate just that -- so it might work.
However, there's a problem: we often pass complex structures rather than
just simple values (ints, strings, ...), and I doubt if SWIG can handle this
well.
Or, for a much bigger project, you could look into the nettiles approach,
which strives to completely split the client interface away from the game
logic itself. This would allow easily adding new interfaces, in any
language you wish.
The difference is: client-side scripting means the game calling a function
in your program when the user presses a key/etc. Client-server means that
drawing the display, etc, is your responsibility -- but this is what you
would want for writing a bot, etc.
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Crawl-ref-discuss mailing list
Crawl-ref-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/crawl-ref-discuss
