DED 2.0

From Doomsday Wiki
Jump to: navigation, search
Proposal
Requires:
Roadmap

Background

The DED parser is limited by its hardcoded semantics. The implementation of the parser is cumbersome to maintain, and the hardcoded definition data structures are inflexible.

Definition parser with extensions

This proposal presents a redesign of the definition parser, with these goals:

  • Add support for defining constants and expression evaluation.
  • Allow games to define definition structures for their data (such as Hexen's MAPINFO).
  • Allow different syntaxes for different kinds of source data (DEDs vs. MAPINFO, for instance).
  • Provide the definition data through a good API to interested parties.

Definitions themselves should be enhanced with the following:

  • Scoping mechanism.
  • Inheritance from and patching of other definitions.

For example (using 1.9 syntax):

Material "MYMAT" {
   Thingy = 2
    ....
}

# A derivative definition.
Material "X-MYMAT" Extends "MYMAT" In doom2|map04 {
   Thingy = SOME_CONST + 4;
}

# A patching definition.
Material Mods "MYMAT" In doom2|map04 {
   Thingy = SOME_CONST + 4;
}

The “In” would specify the scope where the definition applies. You might also have:

In doom2 {
  Material "SOMEMATR" {
    # Scoped to doom2
  }
}

This would still allow using “Copy” as before, to duplicate the previous def.

Advantages

  • Parametric definitions controllable from the command line and the frontend.
  • Easy to add new definition structures and members required by features added to the engine.
  • Reduce the effort to maintain the parser.
  • Uniform scoping allows map/episode/etc. specific definitions for all data.

Open questions

  • The definitions should be tied as closely as possible to Doomsday Script. The script language syntax can be extended with some keywords for conveniently creating definitions. Each definition should be an object created by and accessible through scripts. This will allow serializing the definitions over the network and in savegames.
  • Identifier namespaces (e.g., with Materials there are duplicate identifers in TEXTURE1/2, flats, etc.)
  • How to implement the scoping for all definitions? Is there a need to re-evaluate the entire collection of definitions whenever the map changes, for instance? (Is resolving the scoping and inheritance on-the-fly too costly?) Maybe URLs would be useful here.

See also