A DAAD tutorial for beginners (1)

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

First we need it’s to have an script, something easy to begin working with DAAD. 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 the new DRC compiler, instead of original DAAD one. It will make your life easier.

How to begin

Let’s start by making a simple map:

Image for post
Image for post

Note: Lines with arrows mean up/down. The connection with an X does not exist when the game starts.

Now we have to start by making a copy of BLANK_ES.DSF, and call it THE TOWER.DSF

You will need a text editor to modify THETOWER.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”

Please notice #n is a carriage return, DAAD supports a few special characrters 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 6

Once 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:

EAST lBarracks
WEST lHall
EAST lStairs
UP lStairs2
WEST lBarracks
EAST lStairs2
DOWN lStairs
UP lBedroom
DOWN lStairs2

What 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. Please follow DRC instructions to set it up. When done, run, from command line, and being at the folder where THETOWER.DSF is, the following commands:


if succesful, run:

php drb.php zx en THETOWER.JSON

That will create a DDB file. DDB files store the logic of your game, but has to be put together with interpreter and some other files depending on target machine. Please have a look at this other tutorial to create your testing disk, tap file, etc.

Please notice the commands above are for ZX Spectrum, if you are building for some other machine just replace zx with c64, msx, cpc, etc.


Ok, once we have your disk or tape file, open it in your prefered emulator for the target machine and run it, you would se 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 programming 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 the DSF, and just below that line type this

#define fPassageOpen 100

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), from number 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 — except a few flags which are called system flags but we won’t cover that in this chapter - 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:

AT lStairs2
ZERO fPassageOpen
SET fPassageOpen
MESSAGE “You push the torch, revealing a secret passage going west.”

Then 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 fPassageOpen

Ok, 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 fPassageOpen

Then 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!

AT lStairs2
MESSAGE “Can't pull anymore.”

Well, 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:

AT lStairs2
NOTZERO fPassageOpen
CLEAR fPassageOpen
MESSAGE “You push the torch, the passage closes.”

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

That 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 noun

That 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 noun

Please 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!

Go to next chapter >>

Written by

Developing indie interactive fiction and IF engines since 1984

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store