Forgot your password?
typodupeerror
Programming Games

Duke Nukem 3D Code Review 128

Posted by timothy
from the much-faster-than-the-game-itself dept.
alancronin writes "Similar to Fabien Sanglard's previous code reviews of other games such as the Quake and Doom line of games comes a review of the code base of Duke Nukem 3D (split out over 4 pages). This will be a very good read for anyone interested in understanding the mechanics of a highly addictive game or anyone that wants to learn more about game design."
This discussion has been archived. No new comments can be posted.

Duke Nukem 3D Code Review

Comments Filter:
  • duke nuken (Score:5, Funny)

    by Anonymous Coward on Tuesday February 19, 2013 @12:27PM (#42945557)

    duke nuken

    • by sharkey (16670)
      Pfft. I know a genuine Panaphonics when I see it. And look, there's Magnetbox and Sorny.
    • by Sockatume (732728) on Tuesday February 19, 2013 @12:40PM (#42945691)

      "I'm here to use my bubble-gun and kick some asps. And I'm all out of bubbles."

    • "Dam toes, ale in bass 'tards argon happy forts 'ooting up my right. "

    • by din0 (2608929)

      I'd like the follow up to be Mew Super Nario Bros. for the Wii-V

    • by asylumx (881307)
      I guess that's why they need a code review.
    • by Megane (129182)
      Maybe it was just a case of really bad keming. [xkcd.com]
  • Duke Nuken (Score:5, Funny)

    by digitalmonkey2k1 (521301) * on Tuesday February 19, 2013 @12:35PM (#42945639) Homepage

    Cone get sone!

  • by nedlohs (1335013) on Tuesday February 19, 2013 @12:40PM (#42945699)

    And you can't get it right. Find a job more suited to your lack of ability already (though I admit it's going to be hard to find a job that requires less).

  • by crazyjj (2598719) * on Tuesday February 19, 2013 @12:41PM (#42945707)

    Most methods have "void" parameters and return "void". Everything goes via global variables.
    Methods naming does not use camelCase or NAMESPACE prefix.

    Somewhere, my CS professor just had a simultaneous heart attack/stroke.

    • by Murdoch5 (1563847) on Tuesday February 19, 2013 @12:53PM (#42945847)
      The difference is most CS prof's don't program for the real world and would get a F if they tried.
      • by h4rr4r (612664)

        Here in the real world using global variables gets you fired. Even worse are the PHP dunderheads who think that turning on register globals is a good idea.

        • by Murdoch5 (1563847)
          Okay, sit down, grab a good embedded C board and write me an entire full featured RTOS without using a global, once you can do that you can slander global variables.
          • by h4rr4r (612664) on Tuesday February 19, 2013 @01:53PM (#42946533)

            Which is not what 99% of code does.
            I was speaking generally, and generally globals are a bad idea.

            • Re: (Score:2, Troll)

              by Murdoch5 (1563847)
              Embedded Code out numbers Non Embedded Code on about a 50 000:1 scale. Every single little micro-controller, power IC, control system and numerous other devices, to many to mention, all run Embedded Code. Desktop code really being the exception should follow Embedded Code.

              Desktop code roughly teaches:
              Global's are evil.
              Goto is the most evil and hated statement ever.
              Loops shouldn't run forever.
              Pointers in general are evil.
              Function pointers are to hard to understand because people are morons.

              etc...
              • by h4rr4r (612664)

                Ha, yeah right. We don't even have secure embedded devices. We have plenty of buggy, crashy, insecure ones though.

                I am not sure what metric you are using, but most programmers are not employed writing embedded systems.

                • by Murdoch5 (1563847)
                  I never said most programmers were embedded programmers, I said embedded code out numbers non embedded code. If you take unit insecurity and compare the desktop to the embedded world then you'd easily find the desktop contain FAR more insecurity then the embedded world. Every door lock, finger lock, bio-meteoric lock runs embedded code. Most cars on the road run embedded code, most airplanes run embedded code. Most military drones run embedded code, all phones run embedded code, all desktop computers eve
              • by crazyjj (2598719) *

                I actually miss goto and I'll admit it. It doesn't NECESSARILY produce spaghetti code, people! [ducking for cover]

              • by yincrash (854885)
                I think that would be for most number of devices, not necessarily lines of code written (or even # projects). Most code written today is not for embedded systems.
                • by Murdoch5 (1563847)
                  Even a small update to a micro-controller can cause millions and million of devices to requires updates. Embedded Systems far out number Desktop Systems, even a mobile system is an embedded system. So I would say that most development really is for embedded platforms.
    • by BasilBrush (643681) on Tuesday February 19, 2013 @01:28PM (#42946239)

      The engine was written by an 18 year old. You've got to forgive the lack of college CS education and work experience, and marvel at the talent to actually make the best featured and performing 3D game engine of it's day.

      • by petsounds (593538)

        Well it wasn't true 3D; the Build engine was basically 2.5D -- the levels were still 2D, with an added height component -- using a lot of clever hacks to enable Z-axis levels and targeting. It worked well enough, and was a lot faster than the true-3D Quake on machines of the day. Quake needed a Pentium; if memory serves, Duke could run well on a 486.

        I'd disagree that it was the best-featured engine of the day though. Bungie's Marathon engine was 2.5D with free-look and z-axis targeting, but also allowed for

        • Thanks for the pointer. Back then I was still on PCs, so I wasn't aware of Marathon. I see it's been ported to the iPad, so I'm downloading it for a look.

          I imagine Macs of the day were better featured than the PCs. So that might account for some of it? Perhaps.

          Did Marathon have angled floors? I remember being impressed with that in DN3D, having been used to Doom's limitations.

          • by petsounds (593538)

            The Marathon series has also been open-sourced by Bungie [bungie.org], and builds are available for Mac, Windows, and Linux. Probably a better experience than the iPad version (haven't played it), but YMMV. They're actually pretty good single-player games.

            With regards to your questions, Macs of the day did have an edge on graphics as compared to PCs, so that could account for the higher resolutions and higher bit-depth textures. But most of it is just smart people making cool stuff. As for destructible stuff, you know,

          • by petsounds (593538)

            Bungie has open-sourced the Marathon series [bungie.org], with builds available for Windows, Mac, and Linux, so that may be a better experience than the iPad version.

            You're right -- Macs of the day did have better graphics capabilities than equivalent PCs, so that may account for the higher resolutions and texture bit-depths. But I think most of the innovation just comes from smart people making cool stuff.

            Yes, Marathon did have angled floors. Destructible stuff, I'm not sure -- the last time I played through the series

          • by petsounds (593538)

            Bungie has open-sourced the Marathon series [bungie.org], with builds available for Windows, Mac, and Linux, so that may be a better experience than the iPad version.

            You're right -- Macs of the day did have better graphics capabilities than equivalent PCs, so that may account for the higher resolutions and texture bit-depths. But I think most of the innovation just comes from smart people making cool stuff.

            Yes, Marathon did have angled floors. Destructible stuff, I'm not sure -- the last time I played through the series

        • Oh yeah, destroyable walls, transparent windows and reflecting mirrors were also impressive aspects of DN3D, did Marathon have those?

    • by MrSteveSD (801820) on Tuesday February 19, 2013 @02:09PM (#42946625)
      At my old job I was once writing a while loop and decided to use "i" as the name of a counter variable I was incrementing. After a while I noticed that I had not declared the i and was perplexed as to why there was no compile error. Then to my horror I discovered that someone was using a global variable named "i".
      • by Namarrgon (105036) on Tuesday February 19, 2013 @03:45PM (#42947453) Homepage

        Had a similar problem; couldn't figure out why I kept getting surprising compiler errors in some of my perfectly legal loops. Even more surprisingly, I got similar errors in some basic expressions, despite identical expressions using different variables compiling just fine.

        Surprise was no longer adequate, and I had to resort to astonishment when I found a colleague had #defined the letter "r" to a constant.

    • by MadKeithV (102058)

      Most methods have "void" parameters and return "void". Everything goes via global variables. Methods naming does not use camelCase or NAMESPACE prefix.

      Somewhere, my CS professor just had a simultaneous heart attack/stroke.

      Yeah, C doesn't have methods, it has functions. Argh!

  • Duke Nukem Forever (Score:5, Interesting)

    by KPU (118762) on Tuesday February 19, 2013 @12:43PM (#42945717) Homepage

    I'm more interested in a Duke Nukem Forever code review. Imagine how horrible it must be.

    • by Sockatume (732728) on Tuesday February 19, 2013 @12:46PM (#42945749)

      It'd be interesting to date various components of the code by technological improvements or software development trends.

      "Here we see a portion from the early 2000s, by which point the developers had discovered primitive particle effects. It is built upon the ruins of an older epoch developed in the Quake II engine."

    • by SrLnclt (870345)
      So anyone have an ETA for the Duke Nukem Forever source code?
    • by 91degrees (207121)
      There's probably several working but incomplete versions. Different iterations apparently used 3D Realms home grown "Build" engine, the Quake 2 engine and the Unreal engine, and while I guess the engines may have been designed with some compatibility but it's rarely easy to just switch.
    • Re: (Score:2, Interesting)

      by Anonymous Coward

      What I love about DNF is that you can spot the bits where, over the years, they looked at the hot FPS du jour and thought 'shit we better put that in'. Like the eerily empty Half-Life 2 bits.

    • by locopuyo (1433631)
      It probably wouldn't be quite as bad as you think. They scrapped a lot of the old code when they switched engines. In the end they used a modified version of the Unreal 2 Engine so they were at least building off of something good.
  • by Prokur (2445102)
    Piece of cake!
  • The appeal of DN3D (Score:5, Interesting)

    by RogueyWon (735973) * on Tuesday February 19, 2013 @01:02PM (#42945957) Journal

    DN3D came out when I was in my late teens, about 18 months before I went off to university and got a net connection good enough for online gaming. At the time, it was DN3D, rather than Quake, that was the LAN multiplayer game of choice for my friends and I.

    Partly that was because of the actual gameplay. While Quake was a better twitch-shooter, DN3D had a real, nasty, sneaky dimension to its multiplayer. You could use the pipebombs and holoduke in particular to make traps for opponents that were just like something out of Spy vs Spy. Much more potential for hilarity than a simple rocket to the face.

    But it was also the ease of level creation. Once we were bored of the levels that came with the game, it was trivially easy to fire up the bundled level editor and make new maps. We'd been doing that before with Doom and, if anything, despite having "2.5d" levels (as opposed to Doom's straightforward "2d" levels), DN3D level creation was even easier due to the quality of the tool. By contrast, creating "3d" Quake levels was massively more difficult and time consuming.

    Once I went to University, of course, it became much easier to download new maps from the internet and the superior network infrastructure underpinning Quakeworld, Quake 2 and eventually Half-Life multiplayer moved my gaming in that direction instead.

  • Sequel (Score:5, Funny)

    by Nick (109) on Tuesday February 19, 2013 @01:07PM (#42946007) Homepage Journal
    When I first created my account on /. I remember getting excited about the sequel that was going to be released soon.
  • When I used to look at Doom and Duke3D and try to imagine how the engine worked, portals was the concept I imagined. I was surprised and initially rather confused when I found out that Doom actually worked using Binary Space Partitioning.

    I'm rather pleased to see that I was at least right in my theory with regards to DN33. Possibly I came up with the portals theory after seeing DN3D's windows and mirrors, and then imagined that Doom worked the same way.

    Anyhow, the article was a great read.

    • ... Mind you I'd only ever imagined portals as complete rooms. But in actuality the borders of portals are everywhere the floor or ceiling height changes. So each chair for example consisted of two portals, one for the seat area, and one for the back.

  • Duke Nukem was a great game - many hours played over the phone lines and single player. One fond memory I have is tinkering with the Duke Nukem game settings file. IIRC you change all sorts of things like bullet damage, explosion radius, health, etc.. I once set the radius high enough that you could kill all the enemies in the level with one RPG round aimed at the floor. Then walk around and witness the carnage. ;)
  • by CODiNE (27417)

    I noticed in the article that he was working with a decompiled version of the a.c file.

    a.c: A C reverse-engineered implementation of what used to be highly optimized x86 assembly. It works but is a monstruous pain in the ass to read :( !

    A version of it reimplemented in C was released as detailed here [advsys.net].

    08/20/2003: BUILDC.ZIP: Unobfuscated A.C. (that's a .C source file, not an air conditioner : )

    MUCH easier to read.

    That should help with his project updating the engine as well as anyone else wanting to study th

FORTUNE'S FUN FACTS TO KNOW AND TELL: #44 Zebras are colored with dark stripes on a light background.

Working...