>> 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 >> > Lua [API] ...
Jude and Adam wrote: >> I'm not sure what the side-effects of requiring Python would be, > I strongly object to adding a yet another obscure scripting language to our > already extremely messy code. Adam and Jude, I think you misunderstood Tom. His point (paraphrased) was "SWIG+Python has worked for me, so perhaps SWIG+Lua would work for Crawl". Not apropos of Tom's question, of all the "scripting languages" embedded in games these days, Lua and Python are the most-used and hardly deserve the epithet "obscure". I put "scripting" in scare quotes because the high-level language is sometimes used much more heavily than the low-level one. Adam: > 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. A 2-language implementation is quite standard practice in games. That architectural decision doesn't cause messy code any more than the decision to use C++ -- which is to say, like C++ it certainly adds much _potential_ for trouble. In fact, these days I might even claim that the vast majority of games use two implementation languages; and the majority of those that don't have jettisoned the lower-level language (cf Flash, Unity, UDK, GameMaker, pygame). But on-topic: in my experience (5 big games) it's important that the embedded language have a clearly-defined architectural role. It is horrible to have code paths wander back and forth between languages based on the taste of the particular author. It's also important that the API exposed to the embedded language not try to subvert that role. A thoughtfully-crafted scripting API is a good way to keep the boundary between languages clean: this is an argument against willy-nilly SWIGging up a new Lua interface that exposes all internals. SWIG might be able to clean up existing interfaces nicely though. Adam misunderstood and reacted against adding Python to the stack of tools; but his root argument is still valid (if a bit overstated; everything on the tool list is reasonable for a project of this scope save the duplication of shell, ruby, and perl). SWIG itself is complex, and would add swig interface files and a new code-generation build step to the mix. So that's a point against. Jude: >> we have two Lua >> "virtual machines" (I forget the proper term here ["instances"?]), 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. It is pretty easy to expose API to different VM instances selectively. Unless you share the code that creates and sets up the instances, the right thing will happen by default. Adam: > 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. SWIG is very, very mature and has handled much hairier projects than Crawl (example: wxWidgets). It handles complex structures as well (and as poorly) as one has a right to expect; there's a limit to how nice things can get if you pass or return structures by value to a reference-based garbage-collected language. p ------------------------------------------------------------------------------ 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
