DDF stands for Doom Definition File, and is EDGE's answer to DehackEd
(a utility that allowed you to alter the gameplay of doom and doom2)
However, DDF is much easier to learn than dehacked, and allows you to
do a number of unique things were simply not possible with dehacked.
Indeed, DDF has more in common with say, the .CON files that enabled
users to modify the gameplay of Duke Nukem 3D. Unlike dehacked, which
could be complex and not particularly intuitive, DDF uses fairly
simple, easily understood commands (although it might seem
intimidating at first)
Anyway, we should have a quick look at the general format of a DDF
file. Some of what follows may not initially make a lot of sense.
Don't worry, it becomes easier to understand, especially when you
actually see it in action.
This guide to DDF is probably best used in one of two ways. If you
have already used DDF extensively, you can search through it to check
the correct usage of a command, or to review new features. However, if
this is your first introduction to DDF, this guide will probably be
more effective if you read it in conjunction with the relevant DDF
files. That way, you can see how all the various commands are
structured and get a good understanding of how all the different files
work. The other thing you should do is experiment. Make a backup of
the original DDF files and then try changing around different values
and seeing what happens. If something goes terribly wrong, you can
always restore the original DDF files (or see the hints & tips section.) Anyway, let's launch into
things.
A DDF file is a simple text file that describes an object.
Comments: Anything after // are comments. They are
ignored by the parser.
Spaces are ignored. So this means that calling your monster [EVIL
MONSTER] is exactly the same as calling it [EVILMONSTER] since the DDF
parser will ignore the space. The underscore '_' character is
converted to a space. So you'd use EVIL_MONSTER if you wanted the DDF
parser to recognise a monster called EVIL MONSTER.
Upper and lower case is ignored (so writing SHOTGUN is the same as
writing shotgun).
Anything between quotes '"' is parsed as is eg "MAP01: Containment
area" This means that spaces and upper and lower case characters will
be recognised. This is especially important for names of lumps or
textures, since any '_' characters would normally be converted to
spaces and EDGE would complain about a missing lump/texture.
The main structure to define an object is
The name of the object is the name used to refer to it. Names should
be unique, since when there are two entries with the same the later
one will override the earlier one.
In some DDF files the names are ignored.
Param1 and data1 etc are dependent on what type of object you are
trying to define. Put a semicolon after each
define.
Datatypes:
You will probably find that this doesn't make a whole lot of sense.
But as you begin to
play around with DDF files, it will become less abstract, and you
should soon have a handle on things. DDF is actually a very simple
concept. You use a plain text file to name an object (be it a weapon,
monster, sound, animation etc) that you can then use in the game. Then
according to the particular object, you change various values to
determine how your object will work in the game.
back to top
DDF docs written by Andy Baker and Ziggy Gnarly, with updates by Andrew Apted.
© EDGE Team 1998, 1999, 2000.
eg // This is ignored.
[name]
param1=data1;
param2=data2;
param=data1,data2,data3;
is the same as
param=data1;
param=data2;
param=data3;
Site design by Fanatic (with graphics and modifications by Ziggy Gnarly). Problems with the docs, errors and comments should be directed to the EDGE team.