Duke Nukem 3D
Duke Nukem 3D (often just duke 3D) is a legendary first man shooter video
[1]game released in January 1996 (as [2]shareware), one of the best known
such games and possibly the second greatest 90s FPS right after [3]Doom.
It was made by 3D realms, a company competing with Id software (creators
of Doom), in engine made by [4]Ken Silverman -- the game was developed by
around 10 people and was in the making since 1994. Duke 3D is a big sequel
to two previous games which were just 2D platformers (and a prequel to the
infamously unsuccessful Duke Nukem Forever); when this 3rd installment
came out, it became a hit. It is remembered not only for being very
technologically advanced, further pushing advanced fully textured 3D
graphics that Doom introduced, but also for its great gameplay, iconic
music and above all for its humor and excellent parody of the prototypical
80s overtestosteroned [5]alpha male hero, the protagonist Duke himself --
it showed a serious game didn't have to take itself too seriously and
became loved exactly for things like weird alien enemies or correct
portrayal of [6]women as mere sexual objects which nowadays makes
[7]feminists screech in furious rage of thousand suns. Only idiots
criticised it. Duke was later ported to other platforms (there was even a
quite impressive 3D port for [8]GBA) and received a lot of additional
"content".
Of course, Duke is sadly [9]proprietary, as most gaymes, though the source
code was later released as [10]FOSS under [11]GPL (excluding the game data
and proprietary engine, which is only [12]source available). A
self-proclaimed [13]FOSS engine for Duke with GPU accelerated graphics
exists: [14]EDuke32 -- the repository is kind of a mess though and it's
hard to tell if it is legally legit as there are parts of the engine's
proprietary code (which may be actually excluded from the compiled
binary), so... not sure.
Duke was very much influenced by a very cool anticapitalist movie called
They Live, up to the point of completely copy pasting some of the most
memorable lines.
Code
The codebase (including Build engine) is roughly 100000 [15]LOC of [16]C,
with some parts in [17]assembly. [18]Programming style looks like a
disaster, formatting of the code isn't nicest (at least in the version
reviewed here, got somewhere from the net), tabs are mixed with spaces,
there are large parts of code commented out, inserting spaces and newlines
is inconsistent, looks like a work in progress temporary code. There is A
GREAT DEAL of [19]magic constants and spaghetti code (for example just
randomly found: if inside while inside if inside if inside if inside else
if inside switch inside while -- doing it may be OK sometimes, but here
it's all over the place constantly). Yes, there are even [20]gotos. { I
think John Carmack also said the code looked like complete garbage.
~drummyfish }
The original system requirements were roughly following: 66 MHz [21]CPU,
16 MB [22]RAM and 30 MB storage space.
Duke ran on [23]Build engine, a legendary [24]software rendering
[25]primitive 3D engine that had limitations similar to those of [26]Doom
engine, i.e. the camera could not genuinely rotate up or down (though it
could fake this with kind of a "tilting") and things like rooms above
other rooms in a level were allowed only in limited ways ([27]hacks such
as extra rendering passes or invisible teleports were used to allow this).
The engine was not unsimilar to that of Doom, enemies and other objects
were represented with 2D [28]sprites and levels were based on the concept
of sectors (a level was really made as a 2D map in which walls were
assigned different heights and textures), however it had new features --
most notably [29]dynamic environment, meaning that levels could change on
the fly without the need for [30]precomputation, allowing e.g.
destructible environments. How the fuck did they achieve this? Instead of
[31]BSP rendering (used by Doom) Build engine used [32]portal rendering:
basically (put in a quite simplified way) there was just a set of sectors,
some of which shared walls ("portals") -- rendering would first draw the
sector the player stood in (from the inside of course) and whenever it
encountered a portal wall (i.e. a wall that sees into another sector), it
would simply [33]recursively render that too in the same way -- turns out
this was just fine. Other extra features of the engine included tilted
floors and ceilings, fake looking up/down, 3rd man view etc. The Build
engine was also used in many other games (most notably [34]Shadow Warrior
and [35]Blood) and later incorporated even more advanced stuff, such as
[36]voxel models, though these weren't yet present in Duke. Just like
Doom, Build engine only used [37]fixed point, no [38]float! { Hmm,
actually maybe there was a small exception, see the link below.
~drummyfish }
The game uses 256 colors and [39]palettes.
[40]Pseudorandom number generation is done with linear congruential
generator (function krand), using multiplier 27584621 and adding 1,
returning highest 16 bits of the result.
{ Here are some details on the engine internals from a guy who specializes
on this stuff:
https://fabiensanglard.net/duke3d/build_engine_internals.php. ~drummyfish
}
See Also
* [41]Doom
* [42]Anarch
* [43]Jedi engine
* [44]Dick Suckem
* [45]They Live
* [46]Dink Smallwood
Links:
1. game.md
2. shareware.md
3. doom.md
4. key_silverman.md
5. chad.md
6. woman.md
7. feminism.md
8. gba.md
9. proprietary.md
10. foss.md
11. gpl.md
12. source_available.md
13. foss.md
14. eduke32.md
15. loc.md
16. c.md
17. assembly.md
18. programming_style.md
19. magic_constant.md
20. goto.md
21. cpu.md
22. ram.md
23. build.md
24. sw_rendering.md
25. pseudo_3d.md
26. doom.md
27. hacking.md
28. sprite.md
29. dynamic.md
30. precomputation.md
31. bsp.md
32. portal_rendering.md
33. recursion.md
34. shadow_warrior.md
35. blood.md
36. voxel.md
37. fixed_point.md
38. float.md
39. palette.md
40. pseudorandomness.md
41. doom.md
42. anarch.md
43. jedi_engine.md
44. dick_suckem.md
45. they_live.md
46. dink_smallwood.md