This tutorial was originaly created for NMP engine (a 90s PAWS style engine for DOS),and published in a spanish fanzine, split in chapters. That’s why this tutorial is also split in chapters. Please take in mind the tutorial was not completed back in the day, but it’s still really good for beginners.
Chapter 1 — The Tower
We will create a simple game whose target is escaping from a tower were you have been confined.
The tutorial is made so you use DAAD Ready, a set of tools made to make your life easier when using DAAD. DAD Ready is only available for Windows, so in case you use some other DOS maybe you need Wine. Alternatively, you can use DRC compiler standalone, but that will require much more manual work.
How to begin
Let’s start by making a simple map:
Note: Lines with arrows mean up/down. The connection with an X does not exist when the game starts.
If you use DRC standalone start by making a copy of BLANK_ES.DSF, and call it TEST.DSF, if you use DAAD Ready just double click any of the BAT files (i.e. ZXTAPE.BAT) and choose english. That will also create a TEST.DSF file in the same folder.
You will need a text editor to modify TEST.DSF file, choose the one you prefer.
Creating locations
First thing we will be doing is creating the location descriptions. As you see all locations in the map have a name — which we will use to refer to them formally -, but also a number, which is internally used by DAAD. In order to easy reference them later (without having to reference them by number), we will also create some labels, so for instance we can refer to barracks location both as “2” and as “lBarracks”.
Please first look for /LTX section in your DSF file, and replace its whole contents with this:
/0 "The Tower#nAn Escape Quest"/1 "You are beside the front door. You can see the guard’s table and a fireplace."/2 "Many wanna — be-beds fill this room."/3 "Wind whistles in the spiral staircase. An old armor seems to guard the steps."/4 "A silent room, whose only light comes from the moon light coming through a very small window. Plenty of straw on the floor. You can see an skeleton tied with shackles to the wall."/5 "Mind your step in this old staircase. Halfway up a torch hanging on the wall brings some light to this area."/6 "A big bed almost fills this room. Bars in the window won’t let you go out that way."
Please notice #n is a carriage return, DAAD supports a few special characters like that, but that one is the most common one.
Now we will add, just before the /CTL section, definitions to identify the locations by label:
#define lIntro 0
#define lHall 1
#define lBarracks 2
#define lStairs 3
#define lCell 4
#define lStairs2 5
#define lBedroom 6Once we add these defines, we can either reference the cell location as 4 or as lCell.
Now let’s look for the /CON section (connections) and add this just below that /CON line, so player can move from one location to another:
/0
/1
EAST lBarracks
/2
WEST lHall
EAST lStairs
/3
UP lStairs2
WEST lBarracks
/4
EAST lStairs2
/5
DOWN lStairs
UP lBedroom
/6
DOWN lStairs2What does all that mean? Ok, first location, location 0, it’s used just as an introduction to game. That’s why it appears in the list but has no connections.
The other entries, define a direction and destination per connection. For instance from location 2, if you go east, you get to stairs, and if you go west you get to hall.
The connection from the stairs to the cell does not exist when we start the game, so we don’t define it.
Now we can test the game, which can be done by double clicking any of the BAT files in the DAAD Ready folder (i.e. ZXPLUS3.BAT). That will compile your game, and if successful, run it in an emulator. Please read the notes on screen to know how to start the game once the emulator loads (on some targets is automatic).
Testing…
Once the game is running you would see a message
The Tower
An Escape Quest
and when you press a key you will be at location 1, the hall.
The secret passage
Maybe I should be talking about objects now, but then you would see no puzzles in this chapter, so we are going to make entering the cell possible for the player. To enter the cell the player should pull the torch in the stair. Pushing the torch would close the secret passage.
Ok, look for /PRO 5 in TEST.DSF, and just below that line type this
#define fPassageOpen 100> PULL TORCH
AT lStairs2
ZERO fPassageOpen
SET fPassageOpen
MESSAGE “You pull the torch, revealing a secret passage going west.”
DONE> PULL TORCH
AT lStairs2
MESSAGE “Can't pull anymore.”
DONE
Ok, what are we doing here?
“#define fPassageOpen 100” allows us to reference flag 100 as fPassageOpen. A flag is a placed where we can put a number in. Think about flags as a box where you can put a piece of paper with a number written on it, but only one piece of paper. You can change the piece of paper, but can’t have two or more papers in, so the box will always have a “value” in.
DAAD has 256 flags (boxes), numbered 0 to 255, and the value stored in may also be a value between 0 and 255.
For our current task we would use flag 100, name it fPassageOpen,and so we can control if passage is open or not, we will consider if flag value is 0, the passage is closed, and if flag value is not zero the passage is open. When the game starts, all the flags have 0 as value so when starting the game the passage would be closed.
The process 5 is called “the response table”. You add entries there for each command the player can type, and you decide what happens when the player types that command.
Entries are organized so they are executed in order, and all of them are considered unless a DONE/NOTDONE action is executed (see below)
If you check the first entry you see the the player has to type “PULL TORCH” to get to that entry:
> PULL TORCH
AT lStairs2
ZERO fPassageOpen
SET fPassageOpen
MESSAGE “You push the torch, revealing a secret passage going west.”
DONEThen you find the condacts (conditions and actions). The condacts are DAAD code, some of them are conditions and some of them are actions.
Actions are directly executed (they do something), but conditions are evaluated and the entry stops running when some condition fails.
For instance, in the code above the first condact is
AT lStairs2
That one is a condition, only true if the player is at location lStairs2, otherwise, the entry will fail from that point and all the other condacts in that entry will be ignored (all those after AT, that is, ZERO, SET, MESSAGE and DONE). We add that condition cause if the player is not at the proper location, he can’t pull the torch.
Then we check if the passage is open. If the passage is open (flag fPassageOpen value is not zero) we cannot open it again. So we check flag value is zero, and otherwise, the entry stops running again (SET, MESSAGE and DONE are ignored).
ZERO fPassageOpenOk, if we continue in the same entry after that ZERO condact, the passage was closed, we are at the proper location, and the player type “PULL TORCH”, so we will really pull the torch. We do that by first setting the flag value to a value different from zero, which is done via SET condact, which sets the value to 255.
SET fPassageOpenThen the MESSAGE condact is used, which will type the text in between quotes following so the player can see it. And finally we run DONE. DONE is a condact that tells DAAD “don’t consider more entries”, so basically the rest of process 5 will be ignored and the game will ask the player for another order.
Hey! But there is another entry!
> PULL TORCH
AT lStairs2
MESSAGE “Can't pull anymore.”
DONEWell, if the previous entry failed cause either the AT or the ZERO condition failed, then another entry would be considered, as it also starts by “PULL TORCH”. In that case, if the user is at lStairs2 but the passage is already open, then DAAD will just write the message “Can’t pull anymore.” and mark as DONE, so no more entries are considered. This entry is a fail-control entry, not absolutely needed for the game, but would make your game look better.
But what happens if the first entry fails cause the player is not at the right location? Then the second one will fail too, cause the AT condition won’t be successful, and DAAD will try to find more entries for “PULL TORCH” after the second one, what will get then to the end of process 5 without replying anything cause there are no more entries. In that case, DAAD will show the message “You can’t do that.”, what is actually true as you cannot pull a torch in a location where there isn’t any torch.
Clossing the passage
Ok, now let’s add a way to close the passage, I hope after reading the code above this one is easy to understand:
> PUSH TORCH
AT lStairs2
NOTZERO fPassageOpen
CLEAR fPassageOpen
MESSAGE “You push the torch, the passage closes.”
DONE> PUSH TORCH
AT lStairs2
WRITELN “I can't push the torch.”
DONE
Also , it would be good that, if the player moves to a different location and then comes back to location lStairs2, he can see the passage open. For that we will be using process 3. Please add this code just below /PRO 3 section:
> _ _
AT lStairs2
NOTZERO fPassageOpen
MESSAGE "You see a passage leading west into the darkness."Process 3 is a process which is run just after the location text is shown, and is often used to add information about the location when there has been changes, as it is the case.
Unlike response table (process 5), you won’t define the entries here setting a verb+name pair, cause you wan’t this entries to be executed no matter what the player typed in last order. In fact, when you enter lStairs2 and this text should be shown, the player would have typed either DOWN or UP, depending on where he is coming from. Or maybe he typed LOOK, what would describe the location again. Anyway, the way to make the player command irrelvant is those two undescore characters you see above. Underscore means “it doesn’t matter”, so two underscore chars mean “it doesn’t matter the verb and it doesn’t matter the name”.
Ok so every time the location lStairs2 is described, process 3 is run, and then, no matter which is the last player order, that entry will be considered. If AT lStairs2 is succesful (we are at the proper place) and the passage is open (NOTZERO fPassageOpen) then the message will be shown to the player.
Finally, we have to take in mind that setting the flag value won’t create a new connections. In fact, it’s impossible for DAAD to create new connections, but we can simulate one. To do so, just add this to process 5:
> W _
AT lStairs2
NOTZERO fPassageOpen
GOTO lCell
RESTARTThat entry will , if the player types W (WEST) and he is at the stairs location, while the passage is open, move the player to location lCell (GOTO condact does that) and then describe the new location (in the end RESTART will do that).
You can get from the cell to the stairs without problem, cause we did define the connection from cell to stairs in the CON section. This is a DAAD feature, that allows you to make connections which only work in one way. It’s very useful for mazes, or just when find a hole in the ground, where you can go down but if you go down, you can’t go up again.
Now you can try the game and move all around the tower, open the passage, enter the cell, and close the passage.
Oh! I forgot something: DAAD does not understand many words by default, and neither verbs as PULL or PUSH, nor nouns as TORCH are recognized.
To make DAAD understand that we have to add them to the /VOC section. Please add this just below /VOC line:
PULL 200 verb
PUSH 201 verb
TORCH 200 nounThat let’s DAAD know PULL is a verb, and it’s code will be 200, PUSH is a verb and it’s code will be 201, and torch is a verb and its code is 200. Words with same type (noun/verb/adjective/etc.) and same code are considered synonyms. In this case there are no synonyms as although TORCH and PULL have same code, they don’t share type.
If we would add this then DAAD would understan PUSH FLAMBEAU, PULL FLAMBEAU, and make the same actions than if you type PUSH/PULL TORCH.
FLAMBEAU 200 nounPlease notice DAAD only considers first 5 characters so two words whose first two characters are the same can’t be added to DAAD.
Well, that’s all for this chapter, happy adventuring!
