Castle Dracwulf - LADS development history (contains spoilers)

27th May 2020 - Decided to start creation of Castle Dracwulf game using 
recently modified LADSRUN.EXE interpreter. This interpreter version already has 
the "cursed files" and "header formatting" bug fixes.
Having successfully played three small demo games using this fixed interpreter, 
I wonder if it is possible to create a slightly larger game using the LADS 
system under MS-DOS? Being a retro computing enthusiast, I find I quite like 
this IF system. Lucky if I get one spare hour a day to work on this game, but 
here goes!

28th May 2020 - Started with a small template DRACWULF.ADV LADS source file, 
just enough to get an empty game to start up in the interpreter. I found this 
was crashing the interpreter right away with the dreaded "Auto Action number 
mismatch" error. I had fixed one cause of this error for some of the demo games 
in the "LADS demo" YouTube video I previously uploaded, so was surprised to see 
this come back.

29th May 2020 - Found the problem was caused by having any argument set to zero 
within the action sequences (e.g RAND 0). Seems this causes reading of the 
action sequences to be terminated as any numeric zeros are encoded as CHR$(0) 
in the game DAT file. This is "end of string" in many computer languages. I 
realise none of the three demo games which work OK have any arguments set to 
zero in the action sequences. I also realise this would not be needed in 
practice and therefore the problem is easy to avoid in future.

3rd June 2020 - Completed creation of an initial map of the game world using 
Trizbort IF mapper software, prior to adding the rooms to the LADS DRACWULF.ADV 
source file.

4th June 2020 - Discovered the unexpected "Room 26" bug. Any game having a room 
26 with incoming links will crash the interpreter at the very start of play. 
This is because any links from other rooms into room 26 will be compiled into 
the game DAT file as a CHR$(26) character, which is the "End of stream" 
character. This causes the interpreter to prematurely terminate reading the 
room data, messing up any subsequent data. Quick workaround is to create a 
dummy room 26 with no incoming links and not actually used during game play.
The room cannot be omitted since this would cause an out of sequence error 
during game compilation. I renumbered the original room 26 to room 41. 
This bug is also present in Bob Newell's fixed LADS interpreter, DRIVER.EXE.

4th June 2020 - Found another bug in LADSRUN.EXE where once the game had 34 
rooms or more, the scoreline and moves counter would become corrupted, causing 
screen corruption on every turn. I found the interpreted LADSRUN.BAS did not 
show the problem, only the compiled BASIC EXE version did. Managed to locate a 
copy of the IBM BASCOM BASIC compiler PDF manual online, and started reading 
it. This allowed me to learn about the cryptic two-letter compiler error codes.

5th June 2020 - Traced the "34 rooms" problem to BASIC compile-time errors 
essentially causing some arrays to be DIMed to only the default 10 elements, 
causing other variables to be overwritten. This required re-organising and 
changing several DIM statements in the original LADSRUN.BAS and recompiling the 
interpreter. This fixed the problem in LADSRUN.EXE which was not present in Bob 
Newell's DRIVER.EXE. Uploaded the fixed LADSRUN.EXE to Google Drive and updated 
link on existing YouTube "LADS Demo" video. Finally have a working 40-room LADS 
game where I can walk around and check all rooms, but no puzzles or objects 
coded yet.

6th June 2020 - Added first few objects to game. Tested picking up and dropping 
with GET and DROP working fine. Set weight of each object at 16% max load so up 
to six objects can be carried by player.

7th June 2020
Started coding some explicit actions using LADS tokens. Stumbled across a new 
bug where using the "L2R0" token (move linked item to room 0) causes the action 
sequence to terminate so that any subsequent actions on the same line are 
ignored. Solved the problem by changing the BASIC line "13540 GOTO 26000" in 
LADSRUN.BAS to "13540 GOTO 10010" and recompiling the interpreter. 
The original GOTO statement was pointing to the routine which sets the truth 
flag depending on the result of a conditional test. It was in this case setting 
the flag to false, causing the rest of the action line to be ignored. That code 
is only valid for test tokens, not action tokens. Confirmed the "L2R0 bug" is 
present in Bob Newell's DRIVER.EXE from 2003. This means the Castle Dracwulf 
game will now only run correctly on the updated, bundled LADSRUN.EXE 
interpreter. Not a problem, at this point I decided it is better to fix any 
more discovered bugs in the interpreter than retain compatibility with previous 
interpreter releases.

Found another problem where L2RX (move linked object to room X) and L2OX (move 
linked object to object X) tokens are not recognised by the LADS compiler. L2RX 
and L2OX are both listed in the LADS.DOC documentation and in comments in the 
LADSRUN.BAS interpreter BASIC listing. However, in the compiler BASIC 
listing they are known as L2RY and L2OY respectively, (move linked object to 
room Y) and (move linked object to object Y). Not actually a bug, more of an 
inconsistency. Just need to know to use L2RY and L2OY where applicable.

Did some tests using LADS counters. They appear to initialise to zero at game 
start, which I was depending on. Incrementing a counter and testing it against 
a number also appears to be working fine - I saw a note somewhere else
(perhaps Cloak of Darkness source) mentioning the possibility of bugs in the 
counter implementation, but so far working OK here.
[EDIT 10th August 2020: I revisited the Cloak of Darkness source and Bob Newell
correctly pointed out that counters don't work well with negative numbers, or
comparison with zero (the test can fail totally). This is a consequence of the 
"zero literal argument" bug.]

Added the end game condition, which appears to work fine (and depends on 
correct counter behaviour). I now have a skeleton version of the game which can 
actually be completed, but so far only by collecting two items and depositing 
them in the correct location. No obstacles added yet. Will need to fill in more 
of the game next, but the basics are now working and can't yet see any 
remaining technical showstoppers to getting this game completed in LADS.

8th June 2020 - As I add more objects scattered around the game map, I realise 
that debugging commands are needed to speed up game testing. Added temporary
debugging commands DEBUG_GET and DEBUG_GO to get named object (from anywhere)
and go to a room occupied by named object respectively. I find LADS does not 
have an action token to "move player to linked object" But I realise this 
function can be simulated as follows:-
DEBUG_GO ANY L<>X 8 P2OX 8 L<>X 8 .
This swaps the linked object with object 8 (which happens to be an unused test
object in this game, although pretty much any object will do). Then it moves
the player to the location of object 8, and then swaps object 8 back with the
original linked object. This has the effect of moving the player to where the
linked object is.
The two debug commands will be disabled in the public release of the game.
[EDIT 7th August 2020: By the end of game development, this had increased to
seven debug commands, as the complexity of the game increased.]

As a result of using the debug commands in-game, I find a generic bug which
can crash the interpreter, potentially when using any verb without a noun,
if that verb's action sequence has any reference to linked objects. For
example, if I type DEBUG_GO in-game with no noun, I get ***ERROR 5, which is to 
be expected, since I have not referred to a valid object. But this makes me 
realise other verbs using the ANY noun construct which will remain in the final 
game might have the same problem. I confirm the same problem with the PLACE 
verb I have added to this game.
Problem was solved by removing any tokens which reference "linked objects" from
all action lines using the ANY construct. This makes some in-game responses
potentially less-specific, but that's better than crashing the game.

9th June 2020 - Renamed debug verbs to D-GET and D-GO to speed up typing, 
particularly when playtesting in DOSBox on Android devices. Investigated 
"Error 5" bug further. This occurs when any user-defined verb is used without a
noun if the verb's ANY action sequence contains any reference to "linked"
objects. Linked objects can be used as a "catch all", as opposed to specific
objects, so would be potentially useful, particularly in the ANY noun case.
The demo game "Slab Castle" also shows the "Error 5" bug when "look" is typed.
I trace the problem to OB$(0) being set to the empty string, as object 0 does
not exist, rather it is used internally when no object is specified or matched 
in the dictionary. One workaround is adding BASIC line 229 OB$(0)=CHR$(0),
which means object 0 now exists in room 0 (not in play). This will prevent 
error five, however it can lead to misleading responses when no noun is 
specified by the player. So I decided not to implement this fix. 
[EDIT 7th August 2020: I did ultimately implement the fix as in practice it
does work really well and was very simple. Also, I initially misunderstood 
the OBJ= token to refer to the noun (second word of input). I later found in
fact it refers to the OBJECT which in this LADS context means the third word
of player input (not counting any pronouns, which are automatically eliminated 
by the parser), however confusion arose because the implementation of OBJ= was 
found to be broken due to a single-character typo in the BASIC listing.]
An alternative workaround might have been to use the "OBJ=" token in ANY 
sequences in order to eliminate cases where no valid object is specified
(I do find that in fact you can use the argument zero i.e. "OBJ= 0" in the 
explicit action sequences and the game will start OK, unlike with the implicit 
action sequences). However, I found the "OBJ=" token does not work as intended,
it appears to drop out to the default "That isn't possible under the 
circumstances." message rather than printing the message specified on the 
action line. I troubleshooted this a bit further but decided in the end the 
simplest solution in this case was not to modify the interpreter further, 
rather workaround the problem by ensuring any verb ANY action sequences do not
contain any references to linked objects. So, I have again come to the same 
conclusion as yesterday - it means some in-game responses are a bit more 
generic than I would ideally like, but it's better than crashing the 
interpreter. It also means that all user-defined verbs must be play tested with
no noun specified to make sure none have them have slipped through the net and 
that the interpreter can't be crashed that way. But that's quite quick to do. I 
decided therefore after two days not to spend any further time on 
investigating this issue as it has been holding up further progress on the 
actual game development. I decided simply to avoid it instead.
[EDIT 8th August 2020: looking back, I can see I was eager to get on with 
further developing the game rather than troubleshooting interpreter issues, 
however it was a mistake to leave that "VERB ANY" bug in, as it does cause many 
problems. Thankfully I had it all sorted out two days later, along with the 
"OBJ=" bug and only then could I get back on track with implementing the game 
itself.]

10th June 2020 - No, it's no good, I have changed my mind again. Despite the 
realisation that an essentially working game can be made by working around the
remaining bugs in the interpreter, I would much rather get to the bottom of 
them if possible and fix them if I can. It seems more worthwhile to improve 
the interpreter in case any further games are made using the LADS system in 
future. To do this, I will temporarily freeze development on the Castle 
Dracwulf game and create a simple test game having two rooms, two objects and
two test verbs. I will fork the existing ladsrun.bas into a new test version 
and see if I can fix the remaining issues in the test game. If I mess anything
up then it won't affect the current interpreter or game versions. These bugs 
seem a lot more involved than the previous ones, and I don't think there will 
be any quick fixes. So may take a while before I return to coding the original 
game, but I feel this is ultimately the best solution.
 
Started by re-visiting the "OBJ=" token not working as expected. Added some 
debugging statements to the test copy of the interpreter. Firstly it is 
apparent per the documentation that the "OBJECT" being referred to is "the 
third operative word of a player input", not the second word as I mistakenly 
thought.
This is because the variable "NO" used in the OBJ= test routine is only ever 
set when the player types a third word.
This does not include pronouns etc.. so in the phrase "hit brick with hammer",
the OBJ= keyword should be checking against the object "hammer", not "brick".
Even so, it is not implemented correctly - firstly I find the object number
for the third word (variable "NO") is not initialised or altered on each turn 
unless a third word is typed by the player. Meaning, this wrongly remains set 
to the previous third word typed even if subsequent commands only have two 
words.
For example, if the player types "hit brick with hammer" and then later in 
the game simply types "hit brick", then (for the purposes of the OBJ= test), 
the second occasion will be like they actually typed "hit brick with hammer"
even though they did not use the word "hammer" on that occasion, because 
variable NO will still be set to the object number of hammer as it was typed
on a previous turn. 
Second problem is that the OBJ= test is in fact testing against the second 
word, not the third word. So in the phrase "hit brick with hammer", OBJ= is
returning a false result if we are checking for "hammer" or "true" if we 
are checking for "brick". Yet the test is only valid if a third word was typed.
 I can completely understand the confusion as use of the word "object" is 
ambiguous and can refer specifically to the third word as intended here, 
or can in fact refer to the object referenced by a noun in a two-word command. 
In fact both uses are mentioned in the original LADS documentation.
Now having some understanding of the problems with the OBJ= token, I will 
attempt to fix them on next occasion.

11th June 2020 - Have now fixed the "OBJ=" token for all non-zero arguments.
Added line 4095 NO=0 which correctly resets the number of the "object" on each
turn (the object being the second noun if present). Also corrected line 4380 
in LADSRUN.BAS from 
4380 IF O>0 THEN NO=ASC(MID$(NL$,N,1))-32
to
4380 IF O>0 THEN NO=ASC(MID$(NL$,O,1))-32 
As N is the index to the first noun and O is the index to the second noun. This
explains the previous bugged behaviour of the wrong noun being checked. So now 
any game requiring something like "hit brick with hammer" will work correctly.
The case of "OBJ= 0" is still not working. In summary if any 0 parameter is 
used in the implicit action section, then the game will crash at start. If any
0 parameter is used in the explicit action section, then the game starts fine.
However, any action line containing a 0 parameter will terminate at the 0 with
the in-game response "That isn't possible under the circumstances.". Still not
ideal, but tolerable for the time-being. As it happens, I do not intend to use 
any second nouns in the "Castle Dracwulf" game [EDIT 7th August 2020: I did go 
on to use second nouns in several places in the game. Since I fixed the OBJ= 
token, I later thought I might as well go ahead and use it], so next thing to 
look at is the more serious "Error 5" interpreter crashing on using the "linked 
object" tests on action lines using the ANY keyword. To troubleshoot this, I 
can use the existing "Castle Slab" mini-demo game released by Jesse McGrew in 
1995. It contains the following line, showing the problem:-
LOOK ANY AVLL MSGX 6 RPTN MSGX 7 ELSE MSGX 8 .
The great thing about this is that it shows exactly what the intended behaviour
should be in terms of the possible responses to the player typing "LOOK" along
with particular nouns. So the goal is to fix the interpreter such that the 
intended responses are shown instead of "Error 5". Once this is done, it should
then be good enough for the "Castle Dracwulf" game also. I have also searched
for any original TRS-80 versions of the LADS interpreter which may not have had
the same bugs as the MS-DOS version, in order to get some pointers into fixing 
the issue, however a brief search has drawn a blank - can't find it in the 
TRS-80 TOSEC archive either. So again will try to fix this one by reverse-
engineering the MS-DOS GWBASIC listing further. I will first focus on the AVLL
token (is linked object available?) as per the Castle Slab game.

I find the aforementioned fix of adding line 229 OB$(0)=CHR$(0) in LADSRUN.BAS
is the quickest fix. It appears to eliminate the error 5 interpreter crashes 
for all linked object tests. The only disadvantage of it is that when the
player types a verb with no noun, the response can be slightly misleading
(i.e as if a noun was typed). The only way around that would be to check for
absence of noun. But since the interpreter sets NL=0 for both cases of 
unrecognised noun and no noun present, there's no easy way to distinguish the
two cases without seriously changing the interpreter logic for all linked 
object tests. 
It no doubt can be done, but I think it might require extending the LADS
specification, for example allowing an action line in the form VERB NONE, which 
would only execute in the case of no noun being typed. This would require 
modifying and recompiling the LADS compiler, something I have managed to avoid
so far. Also, it would mean modifying existing games, which is not something I
think should be done. So I will leave as-is for now. It's enough to fix the 
error 5 crashes which is now done. The "Castle Slab" game now gives the 
correct responses in the fixed interpreter for the LOOK verb, rather than 
crashing - this will do.
[EDIT 7th August 2020: I realised eventually this was the best possible 
solution. Later on, I made an informal commitment not to extend the LADS 
specification in any way from that originally intended. I'm glad I stuck with 
this 100% throughout. It means even the completely finished Castle Dracwulf 
game can still be compiled with the vanilla, unmodified LADS compiler hosted on 
the if-archive site, with no problems. I hereon restricted any modifications of
the LADS interpreter to merely fixing bugs rather than adding any 
functionality.]

I now have multiple fixed versions of the LADS interpreter on different devices
and on cloud storage. To avoid confusion, I now add a short message on the 
LADS interpreter start screen showing the "patchlevel" and release date, so I
know I am working on the latest one. So far I have fixed six bugs in the 
interpreter, so this one becomes "patchlevel 006".

There may well be more interpreter bug fixes in future, but I can now continue 
back with the Castle Dracwulf game development at next opportunity.

12th June 2020 - Good progress, implemented the golden gun which can be loaded 
and unloaded with the silver bullet. The werewolf can now be shot and the 
bullet retrieved from the corpse. Closed off access to the clearing until the
werewolf is shot. Did not hit any interpreter crashes during playtesting, 
thanks to recent bug fixes. Looks like I may be able to complete the 
implementation of the entire game using this current interpreter version, 
although I remain open to the possibility of further bug fixes if needed later.
[EDIT 7th August 2020: I did not know it at this point, but I was to find 
a total of around 22 bugs or so in the interpreter, which had to be fixed as I 
began to use more LADS features, plus a small number of bugs which remained 
unfixed.]

Started to refactor some of the in-game messages to reduce total number of
messages and save space. Instead of having "load what?", "place what?" etc..,
replaced them with a single message formed by using RPTV token to repeat verb,
followed by single message " what?". Found out the RPTV token had same bug as
previously-fixed L2R0, token. Needed to change line 15330 from GOTO 26000 to 
GOTO 10010 to avoid truth flag getting corrupted. Also found same problem with
four other action tokens, WAIT, ECHO, RPTN & RPTO. Fixed those the same way.
Recompiled interpreter, now on patchlevel 011 after fixing those five further
bugs.

13th June 2020 - I've now got the point where one main puzzle is fuly coded 
with no major problems, and all rooms are present, so can now proceed with
designing and filling-in the rest of the game.
So no actual coding today, but designed about half of the remaining in-game 
puzzles/obstacles and labelled them on the Trizbort map. Decided player can 
become both a werewolf and vampire (but not at the same time). This will be 
needed to obtain particular items. In previous adventure games I have made
(e.g. Elfbayne) I have often used the technique of adding room connections
during play to open up new areas to the player. This does not immediately seem
possible in the LADS system as the room connections appear to be static data. 
So I am working round that limitation by using "portals" e.g. a window or a gap
which only appears when the player has taken the needed actions. They can then
"enter" the portal to get to the new area. Similar behaviour can be seen in 
all of the demo LADS games where it is always actions other than N,S,E,W which
are used to move the player into a newly accessible room.

14th June 2020 - More puzzles added and more of the map filled in with objects.
Still about another six rooms to fill in. Also I realise it is useful to 
simplify coding of some puzzles if I use a distinct room for "spent" objects,
rather than room 0. In LADS, room 0 stores any object not in play. In this game
I will designate room 0 specifically for objects not YET in play, and room 254
will be for any objects which have been used up and taken out of the game. This
will prevent any objects being found twice and should also reduce the potential
number of bitflags needed. Also worked out the full mechanisms whereby the 
player can become a werewolf and a vampire and also how to cure themselves.

16th June 2020 - Completed the puzzles and objects for about 95% of the game.
Left a little bit remaining for later corrections, modifications or additions
if needed. Started coding the first few puzzles and objects. All working fine
so far. Although did hit the "zero value parameter" bug when using "CEQN 2 0".
This bug prevents anything after the "0" in the action line from executing.
Doesn't look like a quick interpreter fix, so for the moment worked around it 
by designating counter number 3 as always set to zero and then "CEQN 2 0" can 
be replaced with "CEQC 2 3" which will then do the same thing and avoid the 
bug. It's working fine like that for now. Found another issue when multiple
objects occupy the same room, there is a blank line output between each object.
Fixed it for now by removing the slash character (encoded as line feed in game
DAT file) from the end of all objects' long descriptions - seems to work fine 
like this. Confirmed this problem also present in other LADS games e.g. 
"Cloak of Darkness".
[EDIT 7th August 2020: Should clarify, I had merely designed 95% of the game 
puzzles at this point and had only started implementing them. Also the game 
would later become around 50% larger, meaning this was more like 65% of the
game puzzles designed at this stage. Also that "0" parameter bug would remain
unfixed, as I found the interpreter would have to read the action sequences in
a completely different way to distinguish between a "0" parameter and a "0" end
of sequence marker. In other words, the more I looked into it, the more the fix
seemed non-trivial. In the end it did not matter at all, as anything can still 
be coded in practice while still avoiding "0" parameters in the action 
sequences.]
  
17th June 2020 - Went back to fix two other known bugs in the interpreter. 
First one is object long descriptions wrapping around the screen after 64 
characters instead of 80 characters. This was caused by the descriptions being
read into a fixed-length 32-byte buffer before being printed to the screen. In
GWBASIC, if the string to be printed is longer than the space remaining on the
current line, then a newline is printed first, rather than wrapping it around
the edge of the screen. So there was just enough room for two 32-byte strings
to be printed before a newline was printed. This can easily be fixed in 
80-column mode by splitting the string in two and printing each 16-byte half 
of the string separately. However the LADS interpreter does have the ability to 
also run in 40-column mode on very old hardware. So to fix the problem for both 
modes, the string needs to be split into four 8-byte strings and printed 
separately. This is done by amending the following BASIC line in LADSRUN.BAS:-
1160 FOR Q=1 TO 25 STEP 8:PRINT MID$(AI$,Q,8);:NEXT Q:NEXT J:PRINT
Second problem was when the player attempts to drop an unknown object (or just
uses the "drop" command without a noun), there is no output returned. This
was fixed as follows:-
25040 IF NL=0 THEN PRINT "Drop what?": GOTO 1000
Recompiled the interpreter after applying both of the above fixes and now on
patchlevel 013. Also re-tested the latest interpreter version with the "Cloak
of Darkness" mini-game as that one overrides the drop command. Confirmed all
still working fine.

18th June 2020 - Had a more in-depth look at the "zero value parameter" bug.
Found two places where the interpreter is truncating action sequences on
finding a CHR$(0) character. One on reading the sequence from the REF file
at game initialisation and again with a LEFT$() statement in the main game 
loop to chop anything after the first CHR$(0) character. It is apparent that
CHR$(0) is used as the "end of action sequence" marker. To fix this bug would
require some significant additional logic. It would need to parse the action
sequences to distinguish the cases where CHR$(0) is being used as a token
parameter and where it is truly the end of sequence i.e. at a point where no
parameter is expected. I concluded this would be a disproportionately complex 
fix compared to the much simpler method of working around the problem. I can't
think of a case that can't be worked around by carefully modifying the LADS
source file of a game. I do wonder though if this bug was present in the 
original TRS-80 version of the interpreter. Since using "OBJ= 0" is 
specifically mentioned in the LADS documentation file. In any case, I decide
for now not to spend any more time on this issue.

19th June 2020 - I realise I can simplify the LADS code of the Dracwulf game,
by effectively eliminating counters 2 and 3 and instead testing for the 
presence of objects in room 0 (using the implicit NR0X token). This reduces
the size and complexity of the game a bit. It's apparent that I am still 
learning the best way to code LADS action sequences.
Coded the ability for the player to transform into a werewolf. Initially, I
want the player to drop all carried objects when they transform. This can be
done in LADS using the DROP token (not to be confused with the DROP player 
command). Although I found that using the DROP token causes the interpreter to 
crash. Will investigate this next. No problem though if it can't be easily 
fixed, it's not essential.

Found the problem, it was an easy fix. In LADSRUN.BAS, needed to change
13720 FOR Z=1 TO NOB
to
13720 FOR Z=1 TO NOB-1
This is because the "NOB" variable is actually set to one more than the number 
of objects in the game.
Recompiled the interpreter with the fix, now on patchlevel 014.

Added the Count and his ability to repel the unprotected player.

20th June 2020 - Had another idea about fixing the "zero value parameter" bug,
or rather decided it should better be called the "zero literal operand" bug. I
noticed in the binary REF file, all action sequences are 32-bytes in length and
padded at the end with spaces. I could therefore change the LADS interpreter to
read in the entire 32-bytes in one go (instead of one byte at at time) and then
using some sort of "reverse INSTR" function, chop the action string at the 
rightmost CHR$(0) character. This would then preserve the entire action string
even if it contained zero-literal operands. However the idea fell apart when in
my test ADV file, LADSTEST.ADV I created an action string deliberately longer
than 32 bytes. This then compiled to a padded 64-byte long binary string in the
REF file. Therefore still no 100% guaranteed way to distinguish between a zero-
literal operand and the terminating zero using this method. Not a big problem.

21st June 2020 - added "save" and "restore" functions to DRACWULF.ADV using
SAVE and LOAD tokens respectively. Save and load operations do themselves run
without triggering an error and I can see the SAV file on disk. However, once
a saved game is restored, it then crashes the interpreter as soon as the player
makes the next move. I will now use LADSTEST.ADV to troubleshoot this further
to see if it can easily be fixed. If not, then I will omit the load/save 
functions from the game. Found the first problem, exactly the same as the 
"DROP" issue above, FOR I=1 TO NOB needed changing to FOR I=1 TO NOB-1 in both
the LOAD and SAVE routines. This stops the game from crashing after restoring.
Also noticed the "Save file" and "Load file" filename INPUT prompts have no 
padding so that saving a file "test" appears on the screen as "Save filetest"
for example. I initially add a ":" character, but then realise a single blank
space is more true to the original LADS style, so go with this - seems fine.
Recompiled the LADSRUN.EXE interpreter, now on patchlevel 016.

Found another problem - when a save file is restored, some of the in-game 
objects are found to have moved into different rooms. Will look at this next.
Turns out the array elements for the in game bit-flags, counters and object 
locations are off by one when read back in again. Examining the SAVE/LOAD
routines shows this is not actually a bug in LADSRUN.BAS itself, it all looks
correct. The data being written to and then read back in from the SAV file
look symmetrical. It looks more like an issue with GW-BASIC itself, that when
an array of numbers is read back in after a string (RE$ in this case), an extra
zero value is read from somewhere (maybe the CR LF after the string is causing
 it). Furthermore the intepreted BAS file appears to be out by two array 
elements, whereas the compiled version is only out by one. Will need to tweak
the format of the game save file somehow to avoid this issue. To investigate 
this will create a small test GWBASIC file I/O program to write and then read
some variables to/from a test file and see if I can find a format which works
reliably both in interpreted and compiled BASIC modes.
[EDIT 8th August 2020: In fact I found there was a problem in GW-BASIC but also
 in LADSRUN.BAS, meaning the SAVE/LOAD routines were not quite symmetrical. I 
just didn't spot it right away.]

22nd June 2020 -  the test load/save BASIC program revealed that if you write 
a string of 255 characters in length then the bug occurs where subsequent 
numerical array values in the file will be read back in "off by one". Solution
was to change line 
670 RE$=STRING$(255,"N") 
to 
670 RE$=STRING$(254,"N")
As RE$ is used to store whether a room has been visited before, it only needs 
to be 254 characters long, not 255. This is because room 255 is the player's
inventory. The player can never walk into their own inventory (if this is
done via a debugging command, then the interpreter crashes anyway as room
255 is never set up as an actual room). This fixes the first load/save bug.
The second bug, I happened to miss the first time around. It was in fact an
error in the save routine, fixed by changing line
15770 FOR 0=1 TO NOB-1:WRITE #3,ASC(OB$(I)):NEXT
to
15770 FOR I=1 TO NOB-1:WRITE #3,ASC(OB$(I)):NEXT
It has to start at element 1, same as the load routine. There is no object 0.
This fixed the second bug. I then confirmed saving and restoring now working
fine in the Castle Dracwulf game, both in interpreted and compiled BASIC modes.
Recompiled the fixed interpreter, now on patchlevel 017.
[EDIT 8th August 2020: I later realised RE$ probably only needs to be NROOMS 
characters long, where NROOMS is the number of rooms in the game, but did not 
get around to changing it, as the above works fine. It would have needed 
further testing to ensure it did not break anything else.]

Returned to adding game objects and coding logic. Added the chemistry lab 
objects, so an antidote can be created. Added the trap and rule that only the
player as a vampire is quick enough to pass through it intact. This required
adding some further implicit actions. On attempting to playtest the above
additions, I found that no implicit actions are working at all now. Either I
messed something up in the DRACWULF.ADV source file, or I have hit a new bug 
caused by having 6 implicit actions. Will need to investigate this further 
before proceeding. All explicit actions are still working fine however.

Found the problem where the implicit actions stopped working. Running 
LADSRUN.BAS in interpreted BASIC mode, rather than compiled revealed the 
issue. It was a problem I necessarily introduced by changing the DIM NDX(...)
statement to DIM NDX(1024) to allow the program to correctly compile to an EXE.
[EDIT 8th August 2020: This was the start of a wild goose chase and a 
distraction from coding the game. It was caused by the fact the documentation I 
had for the BASIC compiler did not match the compiler I was using, although I 
did not know it at the time. The documentation stated that DIM statements 
could only be used with constant parameters i.e. the size of the array had to 
be fixed at compile time. This led to a big headache, as the game grew, so did
the needed size of the array. It was all eventually sorted when I realised that
the compiler version I was using worked fine with calculated array sizes and
had no problem dynamically allocating an array at runtime. Just wish I had 
found that out much earlier, it would have saved a lot of time.]
It's not possible to use on-the-fly calculations to set maximum array sizes
during runtime in a compiled version of a BASIC program. So you must choose
at compile time what is the likely maximum needed array size and fix it then.
The NDX() array contains indexes to strings in the adventure game data file.
Each index value is multiplied by 8 to get the offset within the file. I had
set DIM NDX(1024), which would allow indexing up to 8K of game data, but the 
Dracwulf game is now approx 11K at this point, hence the array was not big 
enough and data was being overwritten. Also, each element in this NDX() array
is two bytes, so if it is too big, then it eats too much memory. The GWBASIC
environment uses a single 16-bit addressable memory segment, which is 64K of
space. 60K of this is available for the user BASIC program and variables.
When the LADS interpreter loads a very small game (e.g. DEMO.ADV or smaller),
the FRE(0) function shows there is no more than ~32K left for a larger game.
So the maximum size of adventure data you would ever want to index is 32K,
meaning the largest useful NDX() array would be about 4096 bytes. However,
even that is too big because the NDX(4096) array would itself take up 8K of 
RAM, leaving only approx 24K left for the adventure game data. Turns out then,
the best size of the NDX() array in the GWBASIC 16-bit environment is something
like 3328 bytes (3.25*1024). Such a NDX(3328) array will take up 6.5K of memory
and will be capable of addressing a game of up to 26K in size. 26K game data 
plus 6.5K index data is 32.5K so likely there will be no memory left at around
the same time the NDX() array is filled up. It's not an exact science but this
is near enough correct. There may be a case for changing this value by up to a
few hundred bytes either way, but it's not far wrong now. Recompiled the 
interpreter with this re-sized NDX() array and the implicit actions have now
started working correctly again. Such a minor change, so still on patchlevel 
017. I will now have to keep half an eye on memory usage in the game as I am 
already approaching the halfway point and there's still quite a bit more to 
add. If the LADS system was converted to QBASIC, then I have read possibly up 
to 160K of RAM could be available. This would be useful for a much larger game, 
but I don't fancy taking this on right now. I have done all work in GWBASIC, so 
will stick with this for the Dracwulf game, which should fit in the effective 
~26K game size limit.
[EDIT 8th August 2020: My misunderstandings in the above paragraph were 
profound at this stage. It wasn't until late July that I had a far better 
understanding of how the LADS system works. I was wrong on two main counts 
here. First was that FRE(0) would return the amount of free space available to 
a GW-BASIC program. I was familiar with FRE(0) in Commodore BASIC, from my 
VIC-20 days. However, I did not realise in GW-BASIC, FRE(0) merely returns the
size of the largest contiguous available block within a highly-fragmented 
string space. In fact the GW-BASIC function call I really should have used was 
FRE(""). This forces a "garbage collection" or defragmentation on the string 
space and then returns the largest available block, which then is a more 
accurate value of total free memory remaining. This made me later realise there 
was in fact far more free memory available than originally thought. 
Second thing I was wrong about here was how the NDX() array works. I knew 
the needed size of the array grew as the game grew, but I did not understand 
exactly how they were related. I had to completely change my thinking on this.
The LADS system does not hold the entire game in RAM at one time, so you can 
add lots of text to a LADS game, and then find that surprisingly, there is 
hardly any change in the amount of available RAM. Turns out the needed size 
of the NDX() array increases linearly with the sum of the number of objects,
rooms, messages and actions in the game, plus the product of the number of 
nouns and the number of verbs. It is this product of the number of nouns and 
verbs which accounts for the ballooning in size of the NDX() array as the 
game grows. This is because the game uses a lookup table of nouns and verbs 
to execute the corresponding action. It's very fast, but also quite wasteful 
of memory. The resultant NDX() array is very sparse, containing mostly zeros.] 

Once the above problem in the interpreter was fixed, found an error in the 
logic for the trap room. Fixed this in DRACWULF.ADV by splitting an implicit
action out into multiple actions.

24th June 2020 - Had an idea for some time to add a few more rooms to the game.
Added them to the trizbort map. Now up from 40 rooms to 58 rooms (although 8
of the new rooms form part of a maze). Once mapped, added them to the 
DRACWULF.ADV source file. Should just about have enough memory remaining to fit
everything in. It is room, object descriptions and messages that take up the
most memory. The game logic takes up comparatively little space, thanks to it
being compiled to LADS bytecode.

25th June 2020 - Worked out exact maze routes and updated the connections in
DRACWULF.ADV. Added mechanism to reveal trapdoor and enter maze. Tested maze 
routes in-game and noted them down for future use while playtesting.

Implemented the drawing room and library and associated objects. Worked out
you can have multiple objects in a LADS game effectively with the same short
names e.g. you can have Door1 and Door2 in the LADS source file, but let the
player refer to either of them using the noun DOOR, depending on which room 
they are in. This applies only to objects that can't be picked up by the 
player. If the objects can be picked up, then the internal names Door1 and 
Door2 would appear in the inventory. If they can't be picked up, then the
internal short names are never actually seen during gameplay. This is really
useful as I plan on having a few doors in the game, and I want the player to
be able to refer any of them simply as DOOR rather than having to use
different synonyms for DOOR in each room. The trick is not to link the noun
DOOR to any specific door object and then avoid using any references to the 
"linked item" in the explicit action section. All movable objects however will
be uniquely named, for simplicity.
[EDIT 8th August 2020: This trick was crucial to having multiple immovable 
items of the same type in a LADS game. By the end, I would have six doors in 
the game, which the player could individually refer to with the word "door".]

Also decided to make use of the now fixed "OBJ=" LADS token by coding the 
"look behind painting" command, where "behind" is used in place of the noun,
and then "painting" becomes the third word, or "object". Seems to work fine,
can also use this technique later for "look under bed".

26th June 2020 - Coded objects in dining room and kitchen. Unlike "look behind 
painting", "stand on table" does not need to use a third "OBJECT" word with 
"OBJ=" because simple pronouns like "on" are automatically eliminated by the 
LADS parser. 

Was a little shocked to discover only 4K of free memory now remaining. Clearly 
won't fit the rest of the game in remaining space at this rate. 
Next will need to start optimising the game for memory by chopping messages and 
descriptions back a bit and possibly eliminating some of the lesser-needed 
responses. Generally will need to do much more with far fewer words. It's going
to be a challenge to squeeze the entire game into the 16-bit memory map (64K) 
of GW-BASIC, where the game itself can occupy no more than approx 26K, or 
seemingly a bit less than that in practice. 
[EDIT 8th August 2020: Again, thankfully this was just a misunderstanding about 
the amount of free memory reported by FRE(0), it was just fragmented. Also, 
again, adding more text would not have used more memory up, I am not realising 
here that the LADS system does not load the entire game into RAM all at once, 
it uses random access to the files on disk during play and reads messages 
on-the-fly.] 

Found out, I just needed to call the function FRE() with a dummy string 
argument, i.e. FRE("") instead of FRE(0) in order to force a "garbage 
collection" in GW-BASIC, which compacts the string space. On doing this, I was
happy to find that there was in fact 28K remaining. The 4K figure was just the
largest contiguous block of free space, not the total amount. This is great as
there should easily be enough memory remaining to finish the entire game 
without worrying about eliminating anything to save space. It does mean my
previous calculations about the size of the NDX() array were completely wrong,
so I should be able to increase the size of that array as and when needed.
The size of NDX() needed for any particular game can be calculated with
PRINT amax.act.inc+1 after loading a game into the interpreter, as per the
original interpreter code. I just need to manually set this when using the
GW-BASIC compiler because of the limitation that it can't use calculated
array sizes on the fly.
[EDIT 8th August 2020: Again, I eventually found out the compiler I was using,
despite what it says in the manual I happened to download can in fact use 
calculated array sizes, which solved all of these issues.]

Also installed QUICKBASIC 4.5 and was pleasantly surprised to see that the LADS
interpreter also runs and compiles fine with zero modifications in this 
environment, plus there is 33K of space free. So still seemingly using a single
16-bit addressable segment (total 64K), but that is 5K more free than GW-BASIC.
However I am sticking with GW-BASIC for the time being as I have become used
to its simpler environment. Plus I'm not too keen on the blue QUICKBASIC IDE 
screen momentarily flashing up before the LADS interpreter starts when run in
interpreted mode (don't think it's an issue in compiled mode), but it's good
to have the option of switching over to QUICKBASIC if it is needed.
[EDIT 8th August 2020: It remains true that there is a bit more free memory 
available in the QUICKBASIC environment, however, I preferred to stick with 
GW-BASIC throughout as the simplistic black and white text-only environment 
with no windowing seems a better fit with the LADS system, and personally I 
find it quicker and easier to use.]

27th June 2020 - Coded dungeon loose brick, key, unlockable pantry door, pantry
items, music box in study, museum cabinet and access to museum storeroom and
death mask. 27K remaining.

28th June 2020 - Coded master bedroom, closet, locked gate into courtyard and 
associated objects. Limit of NDX() indexing array was exceeded again, increased
size of NDX() to 5120 elements. So array itself now occupies 10K of RAM, but it
can now index a game of up to 40K in size. 23K of memory now remaining in the 
GW-BASIC environment.
[EDIT 8th August 2020: Still had not realised I could use dynamically-allocated 
arrays at this point. With hindsight, it was a case of DRTFM (don't read the 
f****** manual). Or at least DRTWM (don't read the wrong manual).]

Coded guest bedroom and becoming a vampire. Coded effect of garlic on player
when in vampire state. Coded crucifix in spare room and effect on player as
vampire. Still 23K remaining.

29th June 2020 - Coded spare room ladder, loft, window2 and statuette atop 
turret. Coded climb and jump commands. Corrected a logical inconsistency
where the player as werewolf could not fit down small stairwell, but could
fit in small loft. Changed small stairwell to silver-plated staircase after
finding one of these actually does exist in Scotland. The silver repels the
player if werewolf. Renamed first window in game to "window1" and added 
"Examine window" response for both windows. Surprised to still see 23K 
of space remaining, even after increasing game size by over 2K. Not sure why
that isn't going down like it was previously, must be something to do with 
the way GW-BASIC handles string space. But it's good that remaining memory no
longer seems an issue.
[EDIT 8th August 2020: No it's not a GW-BASIC issue. Again, this is completely 
explained by the fact that the LADS system does not read the entire game into 
RAM all at the same time. You can add as much in-game text as you want, but it 
is only the addition of new verbs and nouns which will make the game really eat 
a significant further amount of memory.]

2nd July 2020 - Coded drawer, crawl space and black pearls. Also coded skeleton 
and emerald skull.

3rd July 2020 - Coded grass on the cliff edge, hiding the silver bullet. Coded
the three gargoyles, the diamond and the harp. Coded the workshop door, which 
can be lockpicked. Noticed a bug in the door code where when picked, the door 
remains locked. Double-checked the LADS game logic and it does appear to be 
correct. Suspected this might be a new bug discovered in the interpreter so
added some lines in my test adventure LADSTEST.ADV to set, clear and show
bitflags 10 and 11. Confirmed this is a new bug discovered in interpreter.
Bitflag 10 is working fine, but bitflag 11 still shows as cleared, even when
 set. So will now investigate this new "bitflag 11" bug in the LADSRUN.BAS
interpreter source.

Found the problem, needed to change line 12030 from
12030 T=((BF(FB) AND MASK(X))>0)
to
12030 T=((BF(FB) AND MASK(X MOD 8))>0)
This is because the MASK() array is only defined for subscripts up to 10.
Furthermore, the BF() bitflag array only stores eight bits per element, as 
shown by line 12020 FB=FIX(X/8)
So changing X to X MOD 8 has fixed it.
This particular code tests the bitflag value. I also had to make the same 
changes in lines 14440 and 14450 which set and clear the bitflags respectively.
Recompiled the interpreter, now on patchlevel 019. Confirmed the workshop door
in the dracwulf game is now fixed and working as intended.

4th July 2020 - No coding as such, but had to get the final 5% of the game 
designed to completely finish off the game solution and tie up all loose ends.
Added three more locations to Trizbort map, for a total of 60 and that I think
now is final. Designed new mechanisms for player as vampire, "transform bat"
and "transform elemental". Added idea of summoning a wolf. Changed what was 
going to be an easter egg, into an actual useful game room (room 26). Added
several extra objects to game map to make game completion possible. All that 
remains now is to code the remaining aspects of the game, but it's not an
insignificant amount of ideas that have been added today. It will take quite
a bit longer now to get the game finished than originally envisaged, as it 
became bigger than I initially realised it would. But at least now it 
incorporates all ideas I wanted to add in this genre of game.
[EDIT 8th August 2020: Found in the end I could not use room 26 as I had hoped,
not only does the "room 26 bug" prevent any direct links to room 26, it also 
for all practical purposes prevents items from being initially located in room 
26. Also realised at this stage the game had grown much bigger than originally 
intended and would take quite a bit longer (another month in fact) to complete 
development.]

5th July 2020 - Oops, I realise there was no coffin in the game. Crypt hastily
added and two other rooms besides. Now on 63 rooms and I think that really is
it. Original plan was around 40 rooms, so starting to get a bit of location 
creep. Also worked out remaining puzzles and fleshed out the mysterious room 
26. I can really say the game is almost completely designed barring any last-
minute fixes or modifications. Just need to implement the numerous recent 
additions.
[EDIT 8th August 2020: Designed, yes. Implemented and playtested, no. This 
would in the end take another month.]

6th July 2020 - Added all remaining rooms into game source. Coded vase in 
museum cabinet and unfoldable note. Coded Funkenstein's monster and lever2.
Also noticed that the NDX() array is very sparsely populated in the higher
elements, consisting mainly of zeros. This does seem like an inefficient
use of memory, and I wonder if that can somehow be recoded to reduce array 
size. Not an immediate problem though, as still 23K remaining even though 
the game continues to grow in size.
[EDIT 8th August 2020: This is where I got the first inkling about what was
going on with that NDX() array. Have to admit I was surprised to see such a 
large array so sparsely populated with data, with roughly approaching 99% 
of elements just containing zero. It all made sense later on however. This
was the verb/noun combination indexing into the action sequence table. Of 
course the vast majority of verb/noun combinations are simply undefined in
most games.]

7th July 2020 - Coded sack and coins. Coded first part of web and trapped 
prisoner and vampire ability to feed. Exceeded NDX() array bounds again and
increased size to 8192 elements. Array now takes 16K, with approx 16.5K
remaining. But should be able to index a game up to 64K in size. I don't
fully understand the memory map of the GW-BASIC environment, but perhaps it
is using more than a single 64K memory segment, as I seem to have more space
available than originally thought, which is good.
[EDIT 8th August 2020: Again, the answer lies more with the fact the entire 
LADS game is not read into memory all in one go.]

8th July 2020 - Coded prisoner release from web. Coded Borog and killing of
player and/or Borog in lair. Coded coffin and pinhole mechanism. Coded mummy 
and daddy rooms. Added accompanying treasures to above rooms.
 
9th July 2020 - Implemented "Transform bat" to cross chasm and reach dark 
ledge. Coded bridge, rope and ability to push manhole cover open from inside.

11th July 2020 - Implemented "Transform Elemental" to reach the snowy
mountain peak. Coded pendant hidden in snow. Implemented "summon wolf" and
"dismiss wolf". Re-visited the LADS.DOC documentation and was reminded that
the entire adventure is not kept in RAM all at once - "In order to allow 
this system to interpret very large databases, the driver does not maintain an 
entire adventure in memory." This now explains why the amount of remaining
memory is not going down as the adventure size increases. So really the only
theoretical limit is disk space rather than memory. Although limits on the 
number of messages, objects and actions are likely to be reached well before 
this (practically infinite nowadays) limit of disk space applies. However,
I also notice in the MS-DOS version of the interpreter, the NDX() array does
use more memory as the maximum index size is increased. This array appears to
have been implemented instead as a file on disk in the TRS-80 version where it
is mentioned as "name/NDX, the index to the reference file." Still it seems the
maximum size of NDX() is still greater than practically needed for most 
adventures, even in the GW-BASIC environment.
[EDIT 8th August 2020: Finally, I was getting a better understanding of LADS 
game memory usage at this point. It meant I did not need to worry about 
remaining free RAM quite so much from this point on. I did not need to be 
overly concerned about the length of in-game messages and descriptions etc.. ]

12th July 2020 - Had a bit of a revelation about arrays as used in the LADSRUN
interpreter. Had an initial plan to migrate to the QuickBasic compiler as I 
found it does support dynamic arrays. However this was not needed in the end.
First step was to replicate the problem with calculated array sizes in the 
GWBASIC compiler. As stated on page 88 of the basic compiler manual: "The 
value of the subscripts in a DIM statement must be integer constants; they may 
not be variables,". So I created a test BAS file with variable subscripts in 
a DIM statement, and found to my surprise it compiled and worked correctly 
with no compiler error. The array was found to be DIMension correctly, even
when using random numbers to set the array size. I can only put this down to
the possibility that I am using a newer version of the compiler than the one
I have the manual for. The manual is however correct in all other ways, e.g. 
available command line parameters and error codes. So, I immediately went
back in to LADSRUN.BAS and moved all of the DEFFN statements and other lines
using array elements from the 200-299 range of lines to the 300-399 range.
This was so I could move all DIM statements back up to line 320, as they now
use the on-the-fly calculated array sizes as per the original interpreter code.
However, when compiling, anything using the arrays must be moved to a place
after the DIM statements, or the array will be implicitly defined to have a
size of 10, and then cause compiler errors when the DIM statement is 
encountered (duplicate definition). Again to my surprise, this all worked 
perfectly, and immediately freed up another 3K of RAM in the running program,
now the arrays are not any bigger than they need to be. But the best thing is
now, the program is scalable as originally intended to fit the biggest 
possible adventure into available RAM. And I don't have to worry about manually
setting the size of the ever-growing NDX() array any more, which was becoming
a bit of a distraction. Recompiled LADSRUN.EXE now on patchlevel 020, and still
using GWBASIC.
[EDIT 8th August 2020: This really was a "Eureka" moment. It solved almost all 
previous issues concerning the size of the NDX() array (there was still one bug
remaining, to be discovered a bit later). I knew from this point on, I could 
stick with the preferred GW-BASIC environment. The previous problems were all 
caused by having a compiler manual which did not match the actual compiler 
version I was using. I was so relieved this was finally fixed and no longer a
major distraction to developing LADS games and playing them on a compiled-BASIC 
interpreter.]

18th July 2020 - Have now been invited back into work as we ease out of the
pandemic, so that free hour I had to develop this game when working from home
now replaced with commuting. So down to just a couple of hours or so at the 
weekends now. Or maybe if I can steal an hour or two down the week! 
Fortunately, the game is now almost completely implemented and 
should be able to enter the alpha testing phase in the not too distant future.
Coded putting the pendant on the wolf, and "dismiss wolf" now moves the pendant
to outside the castle, if wolf was wearing it. Room 253 becomes "wolf 
inventory", just for the purposes of the pendant. Coded flags so that the trap
only goes off if player moves from trap room to dungeon, not by player simply
being in dungeon. Coded flag to indicate which direction player attempted to
enter the silver staircase from because player as werewolf can now approach
from both directions. In which case they have to be moved back to the direction
they came from. Implemented ability for player as werewolf to jump from "north
of chasm" onto dark ledge. Implemented slamming shut of cell door and ability
of player as werewolf to bend bars open.

19th July 2020 - Coded the "xyzzy" command, which transports player to special
location in future. Originally tried to use the normally unusable room 26 for
this. Had to abandon that idea when I found out it was impossible to add 
objects to the room, without crashing the interpreter. New room 64 created
instead. Hit another bug with the NDX() array subscript being "out of range"
again. Confirmed this bug in original, unmodified interpreter and also in
the "Cloak of Darkness" DRIVER.EXE. It is triggered when the last verb and last
noun in the lists are used together. In dracwulf.adv, this command happened to
be "lock chest". In Cloak of Darkness it is "quit message", a command that
would never be used in practice, but nevertheless does crash the interpreter.
Found this was because the "action" part of the NDX() array stores a "matrix"
of all possible verb/noun combinations, pointing to their respective actions.
Memory usage for the action matrix is therefore a function of product of
NNOUNS and NVERBS. The interpreter uses the variable AMAX, encoded in the 
compiled adventure file to calculate the NDX() array size, however this number
is slightly too low. This could in fact be a bug in the compiler, which I aim
to keep completely unmodified. The problem was easily fixed in the interpreter
by changing DIM NDX(AMAX+ACT.INC+1) to DIM NDX(NNOUNS*NVERBS+ACT.INC).
Recompiled the interpreter, now on patchlevel 021. Also now I know why most of
the NDX() array is very sparsely populated, and mainly contains zeros. It is 
because in practice, most verb/noun combinations do not have a specific action
defined.
[EDIT 9th August 2020: Finally I understood why the NDX() array is very 
sparsely populated and also how it grows as a product of the number of nouns 
and verbs in the game. Because I had a large number of nouns already in the 
game, I worked out that at this late stage, every new verb I would add, would
eat something in the region of 0.25K of RAM. Also, this was the first and only
time I would find a possible bug in the LADS compiler - that the size of the
NDX array needed, which is embedded in the compiled game file was apparently
being slightly underestimated. As it was easily fixed in the interpreter by 
calculating it at game initialisation time, there was no need to investigate 
this issue any further. Any game which has QUIT as the final verb in its verb
list would probably never show up this bug in practice, as the player would 
never normally enter a command of the form "QUIT NOUN", and even if they did,
the game would still quit as intended, it wouldn't really matter much that an 
error code was printed on the screen at that point. However, fixing this bug 
means that games having a usable in-game verb (requiring the form verb noun) as 
last in the verb list will not crash the interpreter.]

21st July 2020 - Added the gold disc and added the remaining "place" actions 
for the remainder of the valuables. Counted up all valuable items in game, for
the purposes of the "game won" condition and was surprised to find there are 
now 23 of them. the game has expanded a bit more than I originally intended.
Tested "winning" the game using purely debugging commands to get and put all
valuable items in to the holy circle. All worked OK.

22nd July 2020 - Added a 24th and final valuable item to bring the total up to 
a more round number - the ruby ring. Implemented the "place" action for it and 
adjusted the "game won" condition accordingly. Edited the intro blurb to more
accurately reflect the game as it is now. I am now at the stage where I am not 
intending to add any more items or rooms, unless needed to solve any issues
during playtesting. The game is effectively completely implemented in its most 
raw form. 18K remaining. Now I enter the "alpha testing" phase. First task is 
to prove the game can actually be completed without using any debugging 
commands. It has become that complex with the various player states and 
restrictions on accessing various locations, I am not completely sure it can 
be completed as is. Will start work on a possible play-through solution.
[EDIT 9th August 2020: Usually a game designer will probably be aware if their 
game can be completed or not, based on the intended solution. However, the 
thing about Castle Dracwulf complicating matters is the ability of the player 
to change form and working out if all puzzles could be completed in a valid 
order. This was a bit of a head-scratcher. Turns out the only way to be sure 
was to play through the entire game at this stage without using nay debugging 
commands.]

Found first bug preventing game completion. The "Emerald" has a name conflict
with the "Emerald skull". The design of this game has spanned so many weeks,
during the later stages I had forgotten about items added in the early stages.
Fixed by renaming "Emerald skull" to "Crystal skull" and keeping the emerald 
as-is. It's no problem in LADS having name conflicts with immovable objects in
different locations (there are six doors in Castle Dracwulf), but it can't 
really be done with objects that can be carried by the player. Replayed the 
game from start, up to getting the Emerald. All OK now, saved the game.

23rd July 2020 - Continued playing through game from yesterday's save. Found a
few minor issues in need of correction, noted for now. Attempted to play game in
the following order:- human -> vampire -> human -> werewolf -> human. However,
 I found I did not have some useful items at the right time. Realised pretty 
soon a more likely way to complete the game is human -> werewolf -> human -> 
vampire -> human -> werewolf -> human. This means the player must become a 
werewolf twice, but there is only one werewolf cure in the game, meaning player 
would be stuck as werewolf on the second occasion, unable to complete the game. 
This proved the game is not quite completable in its current form. Found a 
quick solution would be to allow the "blue biscuit", which is currently just a 
red herring to also cure the player of lycanthropy. With that minor change, the 
game should be completable. Although still not entirely sure until I play 
through it again.

Fixed seven of the minor issues in game and started to replay again from 
beginning. Saved just after pushed manhole cover open (as vampire).

24th July 2020 - Continued playing from yesterday's save. Got to the point of 
needing to change back from vampire to human and realised I hadn't yet
implemented "drink antidote", so game still not completable. Fixed this and
recompiled. Started a new playthrough. This time managed to complete the game
after about an hour and a half. First time I have proved the essentially 
complete game is winnable without using any debug commands whatsoever. Now have
the walkthrough noted down. It may not be the quickest way of winning the game, 
but it works. Also noted a few more minor issues that need fixing. At least the
save/restore commands appear to be working fine as have used them quite a bit
now during playtesting.

25th July 2020 - Fixed cell door logic. It didn't make sense that player could
go south through a locked cell door. Instead made it so door opens again if
player enters skeleton room (and door not already open). Added hint that player
may be able to find another way up to loft as werewolf. Fixed crown long 
description. Added message "you feel your load has lightened" to let player
know when they have dropped items. e.g. by being a werewolf or as a vampire by 
transforming into a bat or elemental dust.
Investigated extra blank line being printed after manhole description in 
"Undergrowth" location. Could not find any superfluous carriage returns in the
game source, so it remains a mystery why this happens with that one object. Not 
a big problem.
Added responses for "Smash window" and "Smash gargoyles".
[EDIT 9th August 2020: Admittedly I still never did get to the bottom of why 
a blank extra line is printed after the manhole description - it remains in the
game to this day, although I can hardly say it's causing a major problem.]

26th July 2020 - Revisited cell door code. Changed message "A cell door slams 
shut behind you." to "The cell door slams shut.". That original message only 
made sense when the player had come from the Skeleton Room (room 19), so I had 
to have another bitflag (bitflag 19) to check entering from that room and not
from the maze below. Also worked out the door could get in an inconsistent 
state, if the player walked the long way round to the other side of door (via 
the manhole). 
Completely solved all issues when the above message was changed, then I could
eliminate bitflag 19 altogether, and just have a single bitfag 18 which is
set if the cell door is open. The cell door now simply opens if not already 
open and the player enters room 19 and it shuts if the player enters the cell
(room 42) from any direction and it wasn't already closed. Of course whether
the cell door is open or not has no effect on the player's escape from the
cell, that's done by bending the bars (as werewolf) in the cell door.

Checked all rooms (1-64) to ensure all exits are correct and no shortcuts
still present. At early stages of game development before puzzles implemented
needed to be able to walk freely round all rooms on map. Removed these 
temporary room connections as puzzles/obstacles were implemented. Confirmed
all temporary connections now removed in this version.

Revisited all rooms and attempted to "get" all items that should be immovable 
just to confirm they can't be picked up. That was fine, but I noticed in nine
cases, the response was misleading. or too general e.g. "get skeleton" after
skeleton was smashed up would produce "what skeleton?" because the original
unshmashed skeleton object was no longer there. Will add action lines to fix
all of these cases.

Fixed "Get skeleton" although noticed when using RPTN to repeat a noun as in
"What skeleton?", there is a space being outputted between the noun and
the question mark, so we get "What skeleton ?" which looks slightly 
different than the built-in response. Not a major issue, but will see if it
is worth fixing this in the interpreter. The problem is leading and trailing 
spaces appeared to be getting ignored in the custom messages, therefore I may
need to leave this as it is. An alternative might be simply change to a general
message without repeating the inputted noun e.g. "You can't do that" - might be 
a much simpler solution.

Changed as above, "get skeleton" always returns "You can't do that", whether in 
skeleton room or not. This is an acceptable result and the coding is so much 
simpler. Also don't have to worry about superfluous whitespace when echoing any 
inputted noun. Will fix this for the other affected objects in the same way.

Fixed responses for "get" command on remaining fixed objects where the default 
response seemed inappropriate, or there were multiple items with the same name
and one of them was linked in which case the default response would be for 
example "What lever?" even if you standing in front of a lever and trying to
get it. In those cases changed response to "You can't do that", regardless of
player location. In other cases, created object-specific responses, for example
with brick, bunsen burner, hay and snow.

Fixed responses for special case of "examine vase" as vase can be seen when 
still inside cabinet, although not technically available to player at that 
point.

Now entered the stage of embellishing the game responses a bit more. None of 
this will change the game logic or solution, but just adds some more specific
responses to things a player might likely try. Changed the default "examine"
descriptions for all valuable items and added some unique ones for specific 
items. Added some responses for the player trying to wear various items.

Decided to aim for a tentative release date for the game of 1st September 2020.
Any earlier than that, then great. I have really enjoyed designing and coding
this game so far, and fixing bugs in the LADS interpreter. The game though has
become about twice as big as I originally intended, and so far taken about 
twice as long to get to this stage of a fully completable game than initially
estimated. So, I am eager to get it all wrapped up in the not-too-distant
future and move on to other things. On the other hand, I very much want to 
resist the temptation to rush the game out, therefore I have set a date a 
little over a month away to aim for finishing this project, let's see how 
things work out.

27th July 2020 - Implemented eating and drinking of all remaining possible
consumables. Implemented ability for player to shoot self. Implemented 
knocking on doors with appropriate response depending on whether door is
open or not. Added to description of music box - this is actually based on
the rotating box shown in the intro of the former British television 
programme for schools "Picture Box".

1st August 2020 - Added more responses for player attempting to kill various
NPCs and objects. Added more non-functional verbs with stock responses:- hit, 
kick, punch, attack, break, give, say, tell, talk. Added save/restore 
confirmation messages. Added danger warning sign in Funkensten's lab. Changed
"place dodo" message to something a bit more light-hearted. Changed "examine 
circle" message to make it more "in game" style, rather than breaking the 
fourth wall. Added "D-LOOT" debugging verb which makes it such that only one
more item of loot is needed to win the game, for speedy endgame message 
testing. Added appropriate "knock on door" responses for doors which can
never be closed. Fixed inconsistent idea of prowling wolf revealing hidden gap
on being shot - just changed the message such that gap is now accessible, 
rather than being revealed. Approx 14.8K remaining, now I know adding verbs and
nouns is the one thing which eats substantial further memory in the LADS 
system. 100% sure now will not run out of memory by a wide margin as almost 
completed the alpha development phase. Just a small handful of more things to 
do before entering beta testing stage in near future.

2nd August 2020 - Added bite, walk, run, fly non-functional verbs. Added 
bracelet engraving. Added eyes in Funkenstein's lab. Added more substantial 
"game won" message. Added simple "help" command. Ran the whole source file
through the Word spellchecker. Found and corrected seven spelling mistakes.
This now completes the "alpha testing" phase of the game. It is now completed
to the extent that there's nothing more intentionally to add apart from where
it might fix any remaining problems or inconsistencies. Next session, I will
enter the "beta testing" phase, where I will try all manner of commands to 
break the game or crash the interpreter, during a second full walk through -
again just to make sure any changes in the alpha stage have not affected 
completion of the game. 

On further playtesting, added missing descriptions for main castle door and 
moon. "examine moon" required adding a rather long action sequence checking if 
the player is in a number of outdoor locations and returning a sensible 
response accordingly, also a different response for the location ~100 years in 
the future (beck Studios). This also led to changing "North of Chasm", to 
"North of Underground Chasm", likewise for two other underground locations just 
to make it clear they are underground (and not in the open where the moon could 
be seen). This led in turn to the discovery of another minor bug in the 
interpreter, room descriptions of 26 characters were getting truncated to 25 
characters in the output text. The original LADS.DOC specifies a maximum of 50 
characters for the "short room name", however, I can see in the MS-DOS port 
that anything over 26 characters would not fit on the status line (it gets 
overwritten by the "Exits" field), therefore I just increased the maximum 
length from 25 to 26 characters in the interpreter source. Recompiled the 
interpreter - problem fixed and now on patchlevel 022.

4th August 2020 - Still finding a need to embellish the game a bit more to 
allow for obvious things the player might try (but have no part in completing 
the game). Added "get moon", "lever manhole", "examine castle", some of
those have to be context-sensitive i.e. depend on location or game state.
Fixed "examine window" to conditionally state when window is open. Added 
"examine staircase" for both the silver staircase and the grand staircase.

5th August 2020 - Added conditional "it is open" to coffin description, when 
open. Added conditional responses to "examine mummy" for second, bigger mummy 
depending on whether the shield has been removed from underneath or not. Added
sword synonym for shortsword - had to duplicate just two action lines to 
accommodate this. Further testing of games saves. I had a feeling there might 
have been something wrong with the turn count on saving/restoring, but there 
isn't - it seems to be working fine after all. Also, I used about seven saves 
to play through the game to completion last time - clearly this is working 
fine now. Added "examine prisoner" and "search prisoner". Added "examine 
borog", "search borog" and "cut borog". Added "kill wolf". Altered description
for cape to avoid overuse of word "dapper". Added "get drawer" to override 
built-in response, which appeared misleading in this particular case. Slight 
alteration to description of castle dracwulf to avoid contradiction with 
painting. Added "search painting". Added "mix any", "heat any", "heat potions",
"heat antidote".

Systematically went through all of the current 306 actions and typed them all
in while at starting location. This to ensure none of them do things they 
shouldn't when in the wrong room, as it is so easy to accidentally omit a 
conditional test - no problems found. Change game release date in header
from June (as originally intended) to August 2020. I now consider the game 
sufficiently beta tested and more or less completed. Will do one more full
walkthrough next, before finalising the game, i.e. removing the debugging 
commands and tidying up the source file comment section - this will be for
next session.

6th August 2020 - Despite the above, can't quite get the game completely 
finalised just yet. Every time I am away from the computer, I think of other 
things that need fixing. Concatenated "Examine Borog" and "Search Borog" 
messages, now all of it is printed simply when player does "examine borog".
 Changed "search borog" to "You decide against it" - more realistic. Added
"examine bed" (both beds). Added name for female wolf "Vega". This required
a bit of additional logic in "examine wolf" and also three more action lines.
Ran all of the additional stuff from the last couple of days through the Word
spellchecker again. Found a couple of minor grammatical errors - fixed. Added
short message when player quits game. Added more info and tidied up remarks 
section at bottom of game source file. Do think that is enough changes now. 
Will change freeze this version as possible release candidate. Dated v1.0 of 
game to 6th August 2020. Disabled debugging commands. Backed up this version.
12.5K remaining. Ready now for penultimate play through prior to actual 
recording. Need to check no new bugs introduced and this version stil 
completable. Also think I can optimise the walkthrough a little bit here and 
there. 

Walkthrough completed and found just one problem - the message when items are
placed in the circle was a bit messed up after a previous spelling correction
had resulted in one line becoming longer than 80 characters. Fixed this and
restarted the game, played through again to completion. No remaining problems.
This can now become the version of the game to be released as v1.0.
[EDIT 9th August 2020: I was very fortunate in the first week of August that 
due to various circumstances I managed to grab a few more hours of free time 
than originally envisaged. This meant I could condense what I thought would 
have taken me two or three weeks or so down to just about five days. I was now
about two weeks ahead of intended schedule on releasing the game. I realise the 
game is not perfect in a number of areas - some due to restrictions of the LADS
system, some due to the fact that there's always more you can add, and 
eventually you make a decision, you know what - it's good enough. There's 
always the theoretical option of releasing a v1.1 of the game in future 
(although no plans at the moment.) Perhaps after a long break from developing 
a particular game, there might be a fresh perspective on any possible issues.] 

7th August 2020 - Renamed the original game dev folder from "dracwulf" to 
"drac-dev" and archived it in the cloud. This folder contains multiple versions 
of the game at various stages of development, not intended for public release. 
Created new "dracwulf" folder containing only files intended for public 
release.

Copied final version of Castle Dracwulf compiled game and LADSRUN.EXE 
interpreter into new folder. Added "extras" subfolder, containing this blog, 
LADS source code of the game and modified BASIC source code of the bugfixed 
interpreter. 

Started adding retrospective annotations to this game dev blog to correct 
previous entries where I did not at the time have a complete understanding 
of how the LADS system works. I did not modify any previous blog entries - 
just added the recent explanatory notes.
 
8th August 2020 - Continued reading through this dev blog and added further 
retrospective notes. This happened to take quite a bit longer than I thought
it would.

9th August 2020 - Final session of reading this dev blog and adding notes. 
Also, this is getting a bit recursive now, but writing up to this very entry.
I am hoping though that some of the info in this file could be potentially 
useful in the event that someone in future decides to develop a LADS game, as 
many of the potential pitfalls have now been solved. Wrote the README.TXT for 
the game release zipfile.
Started writing the accompanying FAQ, DRAC-FAQ.TXT.

10th August 2020 - Finished writing DRAC-FAQ.TXT and minor additions to this 
file. Ran this file through Word spellchecker, found about eighty typos and 
spelling mistakes, all corrected. [EDIT 12th August 2020: Not quite finished 
the documentation just yet as I later thought of a few more things to add.]

11th August 2020 - Recorded a full walkthrough of the game for YouTube, took 
a little under an hour. Made further amendments to DRAC-FAQ.TXT.

12th August 2020 - Finally finished DRAC-FAQ.TXT and spell-checked it, finding 
about 14 errors. That is everything in the DRACWULF.ZIP downloadable file now
completed. All that remains is for me to upload the walkthrough to YouTube and
DRACWULF.ZIP to Google Drive, which I will do at next opportunity. Thus ends 
this project!
