[Langband-devel] Re: Perhaps an easier way?
Status: Alpha
Brought to you by:
stig
From: Stig E. S. <st...@ii...> - 2000-08-23 07:34:15
|
On Tue, 22 Aug 2000, Tom Breton wrote: [I took the liberty of cross-posting to langband-devel] > Hi, I was looking at your Langband project on sourceforge. > It occured to me that it would be easier to add a Lisp > scripting language to Angband. For instance, Guile, a > Scheme interpreter that is built to be an embedded language. > > That would be far, far less work, especially with a tool > like SWIG that can automatically create interface files. > Existing scripted Angbands like PAngband and ZAngband show > how easy it is, and pretty much lay out the interesting > hooks for you. > > It seems like that would let you gradually move whatever > parts you liked into Lisp and have a working version the > whole time. Ben's C source is very clean and I found it > easy to deal with. Is there anything you can't do by just > adding Lisp scripting? I considered to do it the easy way, and I had a look at how things were done with Python. And yes, it seems easier if Lisp scripting is wanted. But, after discussing it with other variant-writers and having a closer look at the actual Angband-source, I came to the point where I decided that to make the variant and engine I wnted I needed to start from scratch in Lisp and iterate [1] within the Lisp implementation. Most of the current langband code now only shows basic classes, reading of *_info.txt files and a simple example to show that the connection to the zterm-code works. It does not show how it will be fundamentally different, yet. Some of the reason I won't go for the gradual adding of scripting capabilities is that it's merely a strap-on for code never designed for scripting languages. The current code is well-written and nicely commented, but written for legacy machines. Several of the choices in the code indicate to me that speed on a 286 has been chosen over a structured/functional approach. I think that a much smaller and leaner engine which is designed to allow scripting and major changes to the game is preferrable. The variant I have planned for, needs major changes to the game in a way that I think won't be as easy with scripting as rebuilding a subset of the usual Vanilla. (Did I answer your question or did I miss it?) [1] new opportunities and better solution will surface, as well as the need to optimise probably will show up. ------------------------------------------------------------------ Stig Erik Sandoe st...@ii... http://www.ii.uib.no/~stig/ |