Langband - a lispier Angband

Front page |  Screenshots |  Download |  FAQ |  Docs |  SF Project page |  Links | 

Frequently Asked Questions

  1. What is Langband?
    Langband is a rewrite of the traditional/vanilla version of Angband. It is based on version 2.9.3, but has parts found in version 3.0, e.g bigscreen. Langband is written in Common Lisp, which will allow me to combine the dynamic nature of easy scripting with good compiler technology providing an environment that allows a very high level of customisation and the necessary speed. It is a toy project which I work on when I find time, and the development-pace reflects this. However, even if it is a toy-project, I try to write quality-code and have a good design. This also ensures that it will take more time than the usual Angband-variant.
  2. Where can I download it?
    It isn't finished yet and won't be finished for some time as it will need go to through several stages, as all newly written programs must. I hope to have a minimal playable version ready in the 3rd quarter of 2002. You can check it out from CVS or download pre-alpha versions on Sourceforge though. There are also some experimental debian-packages if you use debian, and if you have Debian these are the simplest to get started with.
  3. Does it run on [insert OS]?
    The main development-platform is my x86 Debian-system, using CMU Common Lisp. The status of various ports is as follows (things are still in development so the overall "product" is fairly incomplete):
    ImplementationArchitectureStatus
    CMUCL 3.xDebian x86Well-tested
    ACL 6.0 (Prof)Debian x86Tested bi-weekly
    CLISP 2.26Debian x86Tested monthly. not optimised
    LispWorks 4.1.20Debian x86Recent/immature port. not optimised
    LispWorks 4.1.20Win98Recent/immature port. not optimised
    SBCL 0.7.3Debian x86Recent/immature port. not optimised
    Corman Lisp 1.5bWin98Incomplete port. not finished
    The status for the various UI-interfaces are as follows:
    • X11 is the most mature and the one used for development.
    • GCU is tested basically only for releases.
    • Gtk+ is non-prioritised at the moment, but is usually tested at releases.
    • Win is a very immature port with many errors.
  4. I found a bug, what do I do?
    Please check if the bug has been reported first in the Sourceforge bug-tracking. If it is not reported, please try to describe what caused the crash, include any messages printed before the crash, and if you were dumped into the lisp-debugger please include a backtrace. This is accomplished in CMUCL with the command 'backtrace' and in ACL with the command ':zo'. These commands work in the debugger.
  5. How can I see if a bug is fixed?
    A reported bug will be marked as FIXED when it is fixed and the updated code has been put in the CVS-tree. The priority of a FIXED bug is set to the minimum. It will be marked as CLOSED when a new release have been made where the bug is fixed. If you reported the bug, you will be mailed whenever there is an update on the bug.
    BTW: If you have extra information on a non-fixed bug, please add it.
  6. My save-game from last version does not work in the newest version, why?
    As long as the game is not really playable the save/load code is not enhanced for backward-compatibility and is all-in-all one of the more fragile parts of Langband. But please report bugs and they will be fixed.
  7. The game is sluggish once in awhile, why?
    I have noticed this earlier though not frequently anymore. It might be the garbage-collector interfering. This will be adressed gradually and memory-allocation will be reduced when it is a problem. But during early development this isn't crucial.
    Note: This is still visible in the slower CLISP and in the win32-port if the lispworks-code isn't compiled. Gradual optimisation of the code will probably "remove" this "problem".
  8. The game holds for a few seconds when I change levels, why?
    There are two replies, choose the one that you feel comfortable with.
    • To prevent stair-scumming (a common exploit) a delay has been added to the use of stairs. This has been designed into the game.
    • To prevent the garbage-collector interfering with the game during normal game-play, full garbage-collects are run before and after level­generation. This slows down change between levels. This is very noticable in ACL.
  9. How do I get things working with CLISP?
    It's a bit tricky still but can be done. Assuming csh/tcsh you can do:
    		    $ make
    		    $ clisp -q -ansi
    		    > (load "game")  ;; this stops at foreign loading, use ^D to quit
    		    $ setenv LD_LIBRARY_PATH `pwd`/linking
    		    $ make clisp-link
    		    $ linked/lisp.run -B /usr/lib/clisp -M linked/lispinit.mem -q -ansi
    		    > (load "game") ;; this should work now
    		  
    This will be improved later, but it's an important step ahead. You might need to edit the paths in Makefile and linking/Makefile. For other shells use the equivalent command of setenv which sets and environment value.
  10. How do I get things working with LispWorks Windows?
    Currently it's not 100% streamlined, but if you have it installed in c:/cygwin/home/default/langband/ you might edit zterm/Makefile and set ENVIRONMENTS to WIN and compile zterm with 'make', and then do:
    		    > (setq *default-pathname-defaults* #p"c:/cygwin/home/default/langband/")
    		    > (load "game")
    		    > (lb::a)
    		  
  11. How is the code structured?
    Currently the code is changed frequently and this answer may not be up-to-date. Please look at the Technical description for an hopefully updated description.
  12. You seem to favour classes with datamembers over bitfields, why?
    I tend to favour using clear and readable classes over bitfields for one reason: it's easier to understand, use and easier to extend. However, I know that it is sometimes beneficial to use bitfields but I'll try to hide that behind declarative structures, ie make it an implementation-detail. Resistance and immunity to elements are examples of bitfields that are generated from a specification.
  13. The code in CVS crashes/does not work, why?
    The code in CVS is development code, and might not even compile, and much less work. Please use releases if you want things to "work". The CVS-version is bleeding edge though and may have bug-fixes and features missing in releases. CVS is also where exciting things happen and where you can track day-to-day development.
  14. Regular Angband has several windows, where are the other windows in Langband?
    Several windows can be quite useful but they introduce some extra complexity which isn't essential this early in development. So until the game reaches a stage where more windows is needed it will remain a single-window game.
  15. When I quit the game, my whole lisp is terminated, why?
    Some parts of the UI-code is still structured as if it was still an app with main() that is started and then quitted when one is done playing. This is extremely annoying if you use a slow loader like CMUCL or a big graphical IDE like LispWorks. I hope to eventually make things more intelligent, but this will take time. [Note: This should be fixed in current CVS for X11 and curses, tested with CMUCL, Lispworks and ACL.]
  16. How do I get sounds working?
    1. uncomment the using-sound line in game.lisp
    2. set SOUND_USE in zterm/Makefile to YES
    3. recompile all C-code and lisp-code
    4. get example sounds from the langband project page dowload area
    5. install wanted sounds in lib/sound and configure in lib/file/sound.lisp
    6. start zterm/sound_daemon in the background
    7. start the game
    8. play the game and if possible, hit something
    9. quit game and exit the sound_daemon
  17. How can I get big graphic tiles?

    Set the angband font environment variable, e.g with the tcsh-command:
    setenv ANGBAND_X11_FONT_0 "-*-fixed-medium-r-normal--32-*-*-*-*-*-iso8859-1"

  18. The C-code seems to be filled with gcc-isms and C++-style comments, why?

    I don't think there should be many gcc-isms anymore, but please report those you find. C++-style comments have inserted because they don't break /*... */ comments. When things stabilise, they will be turned into regular C-comments.

  19. I am a lisper, but I find parts of the code a bit odd, why is it the way it is?

    The code is in development and changes relatively often and the interface for the engine that should be extensible and alterable by variants and user-code needs to gradually be worked out. This must be done gradually as I need to experiment with what is interesting to extend/alter, and what can be extended/altered and still get reasonable performance and decent-looking code.

    Some of the interface will be functions which variants may call, and sometimes with function-arguments as plug-ins. Other parts will be generic functions which are designed to be tailoured by a variant. Other parts are extensible classes which variants are allowed to extend. As this interface gets clearer it will be exported from the :org.langband.engine package and variants will reside in their own packages. But we're not there yet, so vanilla currently lives in the same package.


Last updated May 2002
by Stig E Sandø.
See also:
SourceForge project page
SourceForge Logo