Langband, though based on Angband and feels pretty alike when playing it, is very different when you look at the code. It is written in a different language, structured differently and assuming any code-resemblance with standard Angband may prove problematic. Writing another "variant" with a drastic difference with the Angband code-base, which many good variants have been based on, might seem like a crazy project. It might very well be a crazy project, but sometimes one has to be crazy to further the development.
On the positive side, Langband possess some qualities over the standard Angband code-base:
Langband advantages
|
But we might want to jump to the technical side of Langband, how things are structured.
Engine <-> Variant <-> Level[Please note that all parts of the code is written in CAPS-LOCK here to be visible in the text. You're very strongly encouraged to write in only small letters any code to avoid breaking compatibility.] A variant is an encapsulation of all the features which make the game fun to play: fun levels, objects, monsters, classes, races, flavouring of objects and fun rooms. All these things can be customised for a variant, and the engine has nothing of this hardcoded. Other parts of the engine may also be customised; equipment handling, shops, etc. The variant object is available to the engine and it's own code
in the global dynamical variable Also available globally is the A variant may also define it's own room-types, which may be vaults, shop-rooms, churches, elven courts, dragon's den, etc. This code has not been fully expanded yet, but it should have the same customisability as a level. A level-type may also define which rooms may be generated for that level. Another useful global dynamical variable is the
|
Variant object
SORT-VALUES #<EQL hash table, 35 entries {486D439D}>
ROOM-BUILDERS #<EQUAL hash table, 2 entries {486D43DD}>
FLOOR-FEATURES #<EQL hash table, 64 entries {486D441D}>
LEVEL-BUILDERS #<EQUAL hash table, 2 entries {486D445D}>
TURN-EVENTS #<EQUAL hash table, 0 entries {486D449D}>
TURN 138
CLASSES #<EQUAL hash table, 6 entries {486D44DD}>
RACES #<EQUAL hash table, 10 entries {486D451D}>
CONFIG-PATH "./variants/vanilla/config"
SYS-FILE "./variants/vanilla/langband-vanilla.system"
NAME "Vanilla"
ID LANGBAND-VANILLA
TWILIGHT-TIME 6000
DAWN-TIME 0
Filter-table:
{:OBJECTS} -> {((LEVEL
. #<Function "DEFMETHOD ACTIVATE-OBJECT :BEFORE (VANILLA-VARIANT)"
{4836FC69}>))}
{:MONSTERS} -> {((TOWN-LEVEL
. #<Function "DEFMETHOD ACTIVATE-OBJECT :BEFORE (VANILLA-VARIANT)"
{4836F959}>)
(RANDOM-LEVEL
. #<Function "DEFMETHOD ACTIVATE-OBJECT :BEFORE (VANILLA-VARIANT)"
{4836FAE1}>))}
|
Langband statistics [CVS 17th july]
|
Langband symbolsThis is an attempt to list certain symbols that one should be careful about manipulating, as they're used by the engine internally.
|
Langband events[Please rewrite] This is an attempt to list known events that are triggered and
the order they're triggered in. Listed as: BirthDungeon object is NIL.
ObjectsPlayer and dungeon arguments are NIL. There might exist valid
values at
|
Compatibility with ordinary Angband code-baseMost of the code is derived from Vanilla Angband 2.9.0 and many of the function names are taken directly from the Vanilla-code but some are changed and more will be changed as things progresses and Langband finds its own system to do things in. You should not expect Angband-ways of doing things to work. Important simple changes is that all Angband underscores are now hyphens, and that the code relies very little on global variables (ie dungeon tables, player object, etc). Other changes may be found in the style guidelines. Some functions which may be important to remember when going from C/Angband to Lisp/Langband:
Angband: Langband:
rand_int random
randint randint
/ int-/
|