Narbacular Drop Technical Design Document [pdf] | Hacker News Reader

Narbacular Drop Technical Design Document [pdf]

nuclearmonkeysoftware.com

48 pointsRolpa16 comments

Open articleView on HN

Coding guidelines

- Precompute whenever even remotely possible.

- Measures must be taken to prevent copy paste errors.

- The STL is evil (most of the time).

- Unnecessarily virtual functions should be rewritten to remove virtual requirements.

- Sloppy code must be marked for recoding later.

- Unreadable code earns you a free punch in the face.

- Measures must be taken to prevent copy paste errors.

"Checkouts can be performed at will (network permitting), but all code checked into the primary code branch MUST compile. Anyone caught checking-in uncompilable code will be tarred and feathered."

For those that aren't aware, the dev team for this was later hired by Valve and created Portal.

Portal is a slightly dumbed down version of Narbacular Drop (ND), with lots and lots of polish. In ND, it was possible to create portals through portals, which drastically increased the complexity of certain solutions.

It also made some puzzles much simpler. Have to navigate around 20 half-walls zigzagging over a pool of lava? That was a breeze. In Portal you only get line-of-sight, meaning you had to create a pair of portals, step through, repeat. The same puzzle would have been much more challenging in Portal.

"RECODE", ha, cute.

Short and to the point, it's a good doc but not very interesting. Just glad they didn't pad it with tons of code (last I remember Digipen TDD's are required as part of the curriculum and students are known for doing this).

Haven't thought about this game in years, though. What a nice throwback. I thought Portal was great, very polished with great sense of humor but ND was in my opinion a much more fun and interesting game experience (the puzzles really gave you that fantastic "aha!" moment).

Nice piece of history, and hilariously/sweetly innocent/naive in its specificity and certainty, like only newbies' first "design document" could be.

I have issues with this 'longform word doc' format of design documentation in general. It's tedious, no-one bothers to do more than skim read it, it conveys method but not intentions, etc.

I assume this was a class assignment or project, wasn't it? The format was probably dictated by DigiPen instructors.

Yeah. I'm not sure if Digipen still teaches it but I know others do, unfortunately.

For those who haven't played it, the original game is here:

http://www.nuclearmonkeysoftware.com/narbaculardrop.html

Too bad there's nothing about handling recursion of the portal rendering.

This is actually in the developer commentary for the game, I seem to remember.

Page 19 seems to address this a bit.

Very cool. Are there similar documents available for any other games that we would be familiar with?

I imagine it could be a pretty interesting exercise to read over a handful of these from different teams.

https://www.reddit.com/r/TheMakingOfGames/ collects a lot of this kind of material. Use the search function for "doc", "document" and "documents" to find a bunch of them.

Reply on news.ycombinator.com