The level editor used by the game's designers was included on the game CD, along with some documentation. The editor has several problematic bugs but is still serviceable. The most significant fault is its inability to save a newly-created level: the editor will fail when you attempt to. This limitation can be worked around by taking an existing level, deleting all but one sector, saving this "stub" level and building onto a copy of it when you make a new level.
The game itself features a unique editing mode, invoked with the "-edit" command-line option followed by the level to be modified. In this mode, the user can modify the floor and ceiling heights and slopes of sectors, change textures and adjust their alignment and scaling, and adjust the light levels of surfaces. Being able to make these modifications in a 3-D environment significantly eases the task of fine-tuning the visual appearance of levels.
The DLLs[edit]
There's a goodly number of standardized interactive functions built into the game itself that apply to all levels, such as doors and lifts. But much of the higher-level functionality (i.e. the "really good stuff") is encoded into DLLs, one per level, and isn't documented in any manner. Examples include, but are not limited to, switches visibly turning on and off, changing floor/ceiling heights and slopes by custom amounts and speeds, changing textures on surfaces (other than destroyable surfaces), most in-game messages, enemy navigation waypoints, changing light values, spawning items, and just about any kind of scripting. From an end-user level-editing perspective, this puts a substantial limitation on customized interactivity. Despite this limitation, one can still build architecture, and make simple missions.
Disassembling these DLLs with the old DOS DEBUG or a comparable utility won't show any sensible program code anywhere (the CLC instruction is extremely frequent, for example) suggesting they're interpreted data and not executable code. Examining them with a "hex editor" or utility that shows their contents as rows and columns of ASCII characters further suggests this. Presumably the game is using DLLs as containers for convenience. It's unlikely the functionality encoded is as involved as that of contemporary games such as Hexen's Action Code Script or Quake's QuakeC. One could probably figure out how they work without too much trouble, but the investment in time and effort may not be worth it, considering how relatively unknown this game is.