GOBS are quite similar in principle to DOOM WAD files, but at a higher level.
In fact, WADS directly contain the information or resources, but GOBS also contain complex files, themselves still containing multiple resources.
dark -umygob.gob is nearly equivalent to doom -file mywad.wad
You cannot however load multiple gobs in DF as you can load multiple wads in DOOM.
Here is the correspondence between DARK FORCES and DOOM level components:
DF FILE | USE | DOOM EQUIVALENT |
name.LEV | geometry (static) | SECTORS, LINEDEFS/SIDEDEFS, VERTEXES |
name.INF | workings (dynamic) | none, except the TAG concept |
name.GOL | goals | none |
name.O | objects | THINGS |
name.PAL | palette | PLAYPAL 0 (not the 'hit' palettes) |
name.CMP | palette mappings | COLORMAP |
The GOB structure is quite similar to that of a WAD file, the small difference is that in wads the MASTERN field is at the beginning of the file, between WAD_MAGIC and MASTERX.
Of course, the WAD_MAGIC is 'PWAD' or 'IWAD', not 'GOB' followed by 0x0A.
This distinction between master (IWAD) and patches (PWAD) doesn't exist in DF.
Layers are a whole new concept for DOOM levels designers.
It is possible in DF to have many sectors one above the others.
This is completely impossible in DOOM.
The DF sectors are self-contained, by opposition to DOOM vertex and linedef sharing.
In Doom, the equivalent to an Adjoin/Mirror is the sharing of two vertices and a linedef between two sectors.
Contrary to a DF Wall, the linedef doesn't contain texturing information, this one being coded at the sidedef level.
There is no node building (BSP) to do on these levels.
There certainly are checks at level loading time, but a few tests on complicated sectors seem to show 'errors' in texturing or HOM problems.
In fact, it seems that big non-convex sectors are problematic.
This is exactly the same as DOOM texturing, just note that there are two different walls, not one linedef with two sidedefs.