Duke Nukem 3D Code Review
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."
duke nuken
Cone get sone!
My sausage tree didn't grow, does that make me a bad mommy?
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).
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.
What political party do you join when you don't like Bible-thumpers *or* hippies?
For shane.
Give me Classic Slashdot or give me death!
I'm more interested in a Duke Nukem Forever code review. Imagine how horrible it must be.
The difference is most CS prof's don't program for the real world and would get a F if they tried.
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.
When I first created my account on /. I remember getting excited about the sequel that was going to be released soon.
Fuck Ajit Pai
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.
Piece of cake!
That's a lie!
Which is not what 99% of code does.
I was speaking generally, and generally globals are a bad idea.
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".
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.
Why would anyone engrave "Elbereth"?
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 higher bit-depth textures, featured a basic physics engine for weapon effects, featured alt-fire modes for weapons, and more advanced networking. And it came out in 1994; Duke arrived in 1996. Ultimately, they're both innovative engines, but I'd give the nod to Marathon as being the best of the time.