Castle Dracwulf/LADS FAQ

Q. What is Castle Dracwulf?
A. A text adventure (or interactive fiction) written in LADS and supplied with
an interpreter which allows it to be played on MS-DOS systems. It is, as the 
name would suggest a game set in a "vampire castle" scenario, although it is 
ultimately a treasure hunt type of game. It is set in 1897 and the protagonist 
is the dashing anti-hero Bonwick, a gentleman thief. Bonwick is on a mission
to retrieve items for a shadowy group known as "The Clients", and you have 
been contracted through a nameless intermediary to carry out this job.

Q. I am stuck in Castle Dracwulf, are there any hints?
A. No hints as such, although examining the DRACWULF.ADV source file will 
ultimately reveal the solution to any puzzle. Also, there should be a full 
walkthrough available on YouTube.

Q. What is LADS?
A. Short for "Levy's Adventure Development System", it's an IF development 
system originally developed Peter F. Levy for the TRS-80 and ported to the 
IBM PC (as we knew it back then - i.e. MS-DOS) by Jim R. Cummins. The version 
(v2.1) hosted on the IF-archive dates from 1st March 1983. It's a full-blown
IF development system comprising of game database compiler and game 
interpreter. It is implemented entirely in BASIC. The interpreter at least 
is 100% compatible with GW-BASIC, QUICKBASIC 4.5 and with some minor 
modifications, the BASIC compilers of that era.

Q. Why in 2020 would you write a game in LADS, rather than Inform, TADS etc..?
A. Just for fun really. I was going through some of the more obscure IF 
authoring systems on the IF archive and came across the rather sparse LADS 
folder. Although I am aware that some previous games were written in LADS, it 
seems they were ported to other more well-used systems and I have yet to find 
a full-sized downloadable LADS game, native to the system. I had however found 
three small LADS demo games and looking at the source code, it seemed like a 
fun system to program in. It looks quite logical and I like the format of the 
LADS bytecode. Also, I was quite impressed that such an advanced system had 
been implemented in BASIC. Finally it was something of a distraction from the
COVID-19 pandemic.

Q. Why in 2020 would you make a game that only runs in MS-DOS?
A. Well there is an argument which says in 2020 in practical terms it's not 
all that different from running a game in say the Z-machine or the TADS 
runtime engine. For example to run a Z-machine game, you download and run 
a Z-machine interpreter (or VM) regardless of whether you are using Windows, 
Linux or MacOS etc.. It's pretty similar nowadays with DOS programs, if 
you are running Windows or Linux, you can download DOSBox. On Android you can
install a freely available port of DOSBox (I use aFreeBox). I have tested the
ladsrun.exe interpreter in DOSBox, aFreeBox and also FreeDOS in a VM. So there
are at least as many ways to run DOS programs in the modern era as there are to 
run more modern IF games. Having said that, I completely understand why people 
would port older games to newer IF systems in order to increase accessibility.

Q. Why I am getting "This app can't run on this PC" when double-clicking 
LADSRUN.EXE?
A. It's an MS-DOS program dating originally from 1983 and not a modern Windows 
program. It can only be run in a true 16-bit DOS-compatible environment. So 
please download DOSBox or any DOS-compatible environment (e.g. FreeDOS) in a VM 
to run it in.

Q. Why did you rename the lads interpreter DRIVER.EXE to LADSRUN.EXE?
A. Nowadays, the IF author/IF player is very likely to have multiple IF systems
installed on the PATH. Names like DRIVER.EXE and COMPILER.EXE are fine in the 
era of floppy disks, where you have inserted a disk labelled with "LADS 
interpreter" etc.. But I have renamed them to LADSRUN.EXE and LADSCOMP.EXE and 
installed them on my PATH on my HDD so it is immediately obvious that they are 
part of the LADS IF system, and not some other IF system.

Q. Can I recompile the Castle Dracwulf source myself?
A. Yes, you can download COMPILER.EXE from the ladsexe.zip package on the 
if-archive. You can then run COMPILER.EXE from a working directory containing 
the DRACWULF.ADV source file. Enter dracwulf when prompted for the database 
name. Assuming you are using the C: drive in the DOS environment, then enter c
at the "on which drive?" prompt and again at the "compilation drive?" prompt. 
You can type "n" at the "Hard copy... ?" prompt. It doesn't matter if the LADS 
source file is in a subdirectory, the compilation will still work fine and 
produce the output files in the same place. Alternatively, if you already have
GW-BASIC installed, you can download ADVCOMP.BAS from the lads.zip package on 
if-archive, and run that in GW-BASIC. One thing to be careful of if editing 
LADS source files is that whitespace is significant. For example you must have
exactly one blank line between sections. This is something us users of more 
modern free-form development systems are not generally accustomed to.

Q. Were there any issues encountered in writing a game in LADS?
A. Yes, although the LADS compiler seems a really solid bit of code, there are
a number of bugs in the interpreter as hosted on the if-archive. I first fixed
a couple of the more critical bugs, which allowed me to play two of the 
LADS demo games (DEMO and CASTLE SLAB). Around this time, I also stumbled 
across Bob Newell's LADS port of the IF-system test game "Cloak of Darkness".
Bob had supplied a compiled version of the LADS interpreter which he had 
bugfixed himself. As I developed Castle Dracwulf, I started using more and 
more features of the LADS system and it soon became apparent to me that there 
were yet more bugs which only would only crop up in the features used by the 
Castle Dracwulf game. Therefore I decided to fix most of these remaining bugs 
and like Bob, I would also bundle a bugfixed compiler with this game 
containing all of the additional, new bugfixes as well. I would say almost 
close to half of the time of developing Castle Dracwulf was spent tracking 
down, fixing and testing remaining issues in the LADS interpreter. Once they 
were fixed though, the system became really easy to develop in as originally 
intended. Also, I decided I would also release the bugfixed BASIC source
(LADSRUN.BAS) just in case anyone else wanted to fix further bugs in future.
Fortunately, I did not need to fix anything in the LADS compiler, so the 
version hosted on IF-archive can be used to compile this game with no 
modifications. 
There is some irony here in that there is a comment in the compiler source
"WARNING FROM MIKE......THIS PROGRAM SEEMS TO BE FAIRLY BUGGY", but no such 
warning in the interpreter source, yet I have found the actual situation to 
be the other way round with the compiler being largely bug free.

Q. What bugs are fixed in this release of the LADS interpreter?
A. Too numerous to list, but many of them are mentioned in "nuts and bolts" 
detail in the accompanying DEV-BLOG.TXT. The most important ones are 
the so called "cursed files" bug which immediately crashes any LADS game 
having more than one implicit action at game start. An other one is the 
"VERB ANY" linked object bug which would cause any verbs using linked 
objects to crash the interpreter if no noun is supplied. Also several of
the LADS action tokens did not work, as they would cause an action 
sequence to prematurely terminate. Also, the SAVE/RESTORE feature needed
fixing as did the DROP token. There was also a bug preventing correct parsing
of commands using a second noun (known as an OBJECT in LADS terminology). 
There were also some text formatting problems in need of fixing. There was 
also a problem preventing use of more than ten bitflags in a game, and quite 
a bit more besides. I suspect much of the above might explain why there are 
generally no full-sized LADS game available for download. Simple demo games 
would not neccessarily encounter many of these issues. Fixing the above has 
resulted in a much more usable IF development system, in which more substantial
games can be implemented. I have labelled the current bugfixed interpreter 
release as "Patchlevel 022" on the start screen so it can be distinguished 
from earlier versions.

Q. Do any bugs remain in the "Patchlevel 022" release of LADSRUN.EXE?
A. Yes quite a few, although nothing that completely prevents a full-sized 
adventure game from being implemented. From a player's point of view the main
ones are that if an invalid adventure game name is entered at the initial 
prompt, the interpreter will crash. It just has to be restarted again and the
correct adventure name entered to start the game. Perhaps more seriously, if
an invalid filename or path is specified during a save or restore of the game, 
it will also crash the interpreter. These issues are due to use of the 
ON ERROR GOTO construct diverting control of the program to a generic error 
printing routine. It's just a case of being careful when saving and loading 
games. Loading games, not a big problem, just restart the interpreter if it 
has crashed due to an invalid filename entered, and reload again.
Saving, generally issues can be avoided if just simple filenames are used,
rather than full paths. In that case, generally it should always work, even 
if the user has entered a typo in the filename.
From the developer's perspective the main remaining bug is the "zero literal 
argument" bug. This was also mentioned by Bob Newell in the "Cloak of Darkness"
source file. In short, no LADS action sequences can use a literal "0" value in
any parameter. The problem stems from the fact that it would be encoded as 
binary 0 (or CHR$(0) in BASIC terms) in the compiled adventure file. Problem 
is CHR$(0) also specifies end of string, or rather end of action sequence.
Therefore the action sequence will immediately terminate at the point the zero
parameter is encountered and the interpreter will relay a generic "That's not 
possible.." reply to the player. A possible fix for this doesn't look too 
trivial, but I have learned it is so easy to workaround. Instead of comparing
a counter to zero, instead you can keep one counter in the game always set to 
zero (as they all initialise to zero), and compare other counters to that 
counter, by using the CEQC token, instead of CEQN. Likewise to move objects to
room zero, or check for the presence of an item in room zero, you can use 
tokens which implicitly refer to room zero, or you can even use another room 
to move objects out of play (Castle Dracwulf uses room 254 for this purpose).
The other significant remaining developer bug is the "Room 26" bug. Any 
reference to room 26 will be encoded as CHR$(26), which is also the "end of 
stream character". So any room having an explicit connection to room 26 will
cause the interpreter to crash at game start. Also any items starting in room 
26 will also cause a crash. Any game having 26 or more rooms, must have a room 
26 present, as all rooms have to be listed in numeric sequence in the LADS 
source file. So the easiest workaround is to reserve room 26 as an unused dummy
room.
There may well be further, as yet undiscovered bugs, as the Castle Dracwulf 
game does not use all known LADS features. I have only fixed bugs I happened 
to encounter whilst developing this game.

Q. I have fixed some further bugs in the LADS interpreter. How can I recompile 
the interpreter?
A. Although it's perfectly fine to run the LADS interpreter itself in 
interpreted BASIC (it works out of the box in the GW-BASIC and QUICKBASIC 4.5 
environments), it is more convenient for the LADS game player to use an 
executable copy of the LADS interpreter. To compile it, you can use either 
bascom.exe or bc.exe and there may be others. I happened to use bascom.exe 
The LADS interpreter can then be compiled with 
BASCOM.EXE LADSRUN,, /E /O
and linked with 
LINK LADSRUN,,,,
This will then produce a LADSRUN.EXE
Note the original interpreter versions on the if-archive will produce a number 
of compilation errors. The fixed version in this release should produce zero 
errors and warnings when compiled.
Of course even though a compiled version of the LADS interpreter is faster and
more convenient for the game player, I would always retain the ability to run 
it in interpreted BASIC while developing LADS games for the simple reason you 
can break into the running program. In the GW-BASIC environment for example you 
can then list variables and troubleshoot any interpreter issues much more 
easily than with the compiled version.

Q. Why is the verb "take" not understood, or generally verb "xyz" not 
recognised in Castle Dracwulf?
A. LADS provides built-in handing of the directional verbs n,s,e,w,u,d plus
i (inventory) and l (look). Also "get" and "drop" are automatically handled
internally by the interpreter. "take" is not by default recognised, although
if you examine the source code for the demo game "Cloak of Darkness" (CoD) by 
Bob Newell, you will see that "take" can be implemented with some effort. In a 
full sized game with a large number of objects however the implementation of 
the "take" verb could in theory get quite complicated, so in a nutshell it's 
far simpler to leave it out. Also anything where the default "get" behaviour 
is overridden by the game author would have to also be duplicated for "take", 
as is the case in CoD, and in that example, it's quite a bit of code just for 
a single object. As for other verbs which are common synonyms, again in LADS,
you would need to duplicate each action line for each synonymous verb and also
because of the way the "verb-noun matrix" (the NDX() array) uses up memory,
there is potentially a lot of extra memory needed for each extra verb, if 
there are a lot of nouns in the game, The amount of memory needed is a 
function of the product of the number of nouns and number of verbs. Therefore,
in LADS it's often preferable for the game author to omit synonymous verbs,
which in other IF systems might well be added.
Also note, user-defined single-character verbs (e.g. "z" for "wait") can't be
used in LADS by default, as the interpreter is hard-coded to reject them with
the in-game messgae "Huh?". The compiler however does seem to compile them OK.
This doesn't seem too difficult to fix in theory, but I decided not to change 
the behaviour of the LADS interpreter. In other words, it appears to be an 
intended feature, rather than a bug.

Q. Why in the Castle Dracwulf source are there newlines at the end of every 
room description and message, but not the object descriptions?
A. This does at first glance appear to be a bit inconsistent. It is because
in LADS, if a message or room description is printed, then the interpreter does
not automatically print a newline character. However, it does for long object
descriptions. Therefore if you add newlines to the end of each object 
description in the source, then you will get a blank line between each object 
described within a particular room. The same also holds for the short object 
descriptions (in the player's inventory) too.

Q. Where can I get more info about developing LADS games?
A. There is a very useful DOC file supplied with the lads.zip and ladsexe.zip 
downloads on the IF-archive. This gives a thorough description of the LADS 
system including the LADS source syntax and lists all available tokens. 
Although, some of the information in there does not quite match the current 
LADS interpreter version. For example it is stated there is a limit of 99 verbs
and 99 nouns, yet the Castle Dracwulf game has well over 100 nouns. Also it 
says a room name can be up to 50 characters long, although I have found in the 
MS-DOS version the practical limit is 26 characters, due to limited space in 
the status bar at bottom of screen. Also a small number of the token names are 
incorrect, as described in more detail in DEV-BLOG.TXT. Also, there's no 
explanation for the newer syntax of requiring a comma and number after each 
verb (all set to 0 in the Castle Dracwulf game). Admittedly I still don't yet 
know what is the purpose of that, but in in the case of Castle Dracwulf, it 
wasn't needed. I was hoping it was a mechanism to allow for synonymous verbs,
but if it is, I couldn't seem to get it working as expected - would need 
further investigation. Also the documentation mentions that a complied LADS
game consists of three files, the DAT, REF and NDX files. However, in the 
MS-DOS port of the LADS system, there are only two files as the NDX file 
(index file) does not exist. From what I can gather, the NDX file appears to 
have been replaced with the NDX() array, internal to the LADS interpreter.
