Just to chime in, auto generation of lua bindings is a good idea from my point of view as long as it's easy to maintain. But, I'd like to note a heretofore unmentioned issue with adding python as a scripting language and that is, to encourage community contribution we need to reduce the requirements to do so. If people who might not be programmers have to learn another syntax this might discourage some people who just want to generate a small but of content because they enjoy the game.
Also, Crawl is much, much more complex structurally than NetHack. I have the dependence graphs to prove this. Are you talking about a specific module of crawl, maybe? - Chris Galardi Aka Ixtli On 2010/11/25, at 13:18, Tom Lippincott <thomas.lippinc...@cl.cam.ac.uk> wrote: > 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 ------------------------------------------------------------------------------ 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
