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.
eg // This is ignored.

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.
param=data1,data2,data3;
is the same as
param=data1;
param=data2;
param=data3;

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, Andy Brewood and Luke Brennan.
Problems with the docs, errors and comments should be directed to the EDGE team.

© EDGE Team 1998 - 2023.