Class-hierarchy beneath class: ACTIVATABLE
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
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 2001]
Langband statistics [root, simple grep, CVS 7th december 2001]
Langband statistics [root, simple grep, CVS 17th february 2002]
Langband statistics [root, simple grep, CVS 5th january 2003]
|
Langband styleCurrently very little is documented or in place, some coding guidelines exist however to make the code easier to understand:
|
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
|
save/load issuesTo ensure that save/load works as it should, all ids for objects should be strings. The ids should be all lowercase-characters (a-z) or hyphen. An id should also be unique for the object it identifies. An object with id uses the id-slot in the object. Typically a lisp-program would use symbols for this, but it gives some case-issues and package-issues, and strings are more portable without imposing too big performance-hit. For some code it is useful to be identified by a symbol, e.g classes, races, ... . This symbol should be put in the symbol-slot of these objects. |
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. You should be aware that some of the terminology has also been changed, e.g where angband talks about level for objects and monsters, Langband talks about depth, reserving level for a 'power-level' use, not dungeon-level it is found. 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-/ |
Class-hierarchy beneath class: ACTIVATABLE
|