On 11/25/2010 05:57 PM, Paul Du Bois 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 >>>> 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. Just a quick compliment: the crawl code is *much* cleaner than e.g. nethack. > 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. Yes, I meant to suggest a way of improving the current Lua code automatically. That's not to say I don't have my personal dream of a python interface (introspection is...much easier in python), but I don't propose rocking the boat *that* much. > 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. In the Python case I was getting an API to the game itself, i.e. from a python shell I import a "crawl" module, create an instance of a game (so the window pops up), and I could play normally, or call an arbitrary function in the shared library/examine the game state/etc in the shell. In other words, this was a coarse and intrusive approach to writing a bot.
I think SWIG could also be used to generate the "l_*.cc" files, or "fill them in" automatically (see below for the issue of controlling what gets exposed). > 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. When building a Python API, I had to be selective about which structures were exposed: some header files caused errors that would have taken a longer effort to track down and fix. For the most part, you can simply take a header file and declare which structures you want the API to expose (and you get an arbitrary level of control beyond this), so its easy to distinguish between, say, user-accessible info and internals. Frankly, I was surprised by how well it worked when just playing around with it, and so a more careful effort should be even more successful. > 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 ------------------------------------------------------------------------------ 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
