Frequently Asked Questions
- 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.
- 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.
- 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):
Implementation | Architecture | Status |
CMUCL 3.x | Debian x86 | Well-tested |
ACL 6.0 (Prof) | Debian x86 | Tested bi-weekly |
CLISP 2.26 | Debian x86 | Tested monthly. not optimised |
LispWorks 4.1.20 | Debian x86 | Recent/immature port. not optimised |
LispWorks 4.1.20 | Win98 | Recent/immature port. not optimised |
SBCL 0.7.3 | Debian x86 | Recent/immature port. not optimised |
Corman Lisp 1.5b | Win98 | Incomplete 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.
- 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.
- 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.
- 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.
- 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".
- 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 levelgeneration. This slows down change
between levels. This is very noticable in ACL.
- 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.
- 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)
- 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.
- 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.
- 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.
- 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.
- 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.]
- How do I get sounds working?
- uncomment the using-sound line in game.lisp
- set SOUND_USE in zterm/Makefile to YES
- recompile all C-code and lisp-code
- get example sounds from the langband
project page dowload area
- install wanted sounds in lib/sound and configure in
lib/file/sound.lisp
- start zterm/sound_daemon in the background
- start the game
- play the game and if possible, hit something
- quit game and exit the sound_daemon
- 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"
- 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.
- 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.
|