Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nintendo releases original Zelda design docs

nintendo.co.uk

Post reply on HN
Print view View original

41–50 of 51 posts

Re: Nintendo releases original Zelda design docs

#41

Post by ldjb »

plasticbugs wrote: post #35
bluedino wrote: post #12

Earlier quoted context omitted.

Are there larger scans of those sheets anywhere? Possibly a blank?

BG Planning Sheet linked from Nintendo Europe: https://cdn02.nintendo-europe.com/media/downloads/games_8/wi...

For anyone curious about the few bits of Japanese on those sheets...

On the BG Planning Sheet, 年 月 日 mean Year Month Day -- for indicating the date. 時 分 are Hour Minutes -- for indicating the time. デザイナー means Designer and プログラマー means Programmer.

Oddly, the last page seems to be a mirror image, and it's quite difficult to read the text. However, it appears to be for designing an individual sprite. There is a field labelled キャラクター (Character) along with Date and Memo fields.

Re: Nintendo releases original Zelda design docs

#42

Post by mysterydip »

thesimpsons1022 wrote: post #21
deepsun wrote: post #10

Earlier quoted context omitted.

But don't forget that today it's often faster to program it first without a plan, and rewrite it a few times later; than to draw such nice design plans and iterate on them before writing actual code. Also, in some cases, writing actual code reveals some unforeseen problems in design.

but what makes the game more fun? from what i've seen, most people agree that Nintendo games are some of the most fun consistently and yet they use this process. Meanwhile there have been many disasters like no mans sky that have been built iteratively.

I would say it's a mix of the two. "Find the fun first" is the advice being sent around now in indiedev circles. Prototype your core game loop ("whiteboxing" it as mentioned below) and mess with it until you have something fun and replayable. After you have that, now start into a more designed approach for levels and menus and GUI, etc.

Re: Nintendo releases original Zelda design docs

#43

Post by Johan-bjareholt »

deepsun wrote: post #10
gallerdude wrote: post #4

Even as a programmer, I appreciate having the vision of the game first and figuring out how to program it second.

But don't forget that today it's often faster to program it first without a plan, and rewrite it a few times later; than to draw such nice design plans and iterate on them before writing actual code. Also, in some cases, writing actual code reveals some unforeseen problems in design.

That depends on the tools. Thats generally the case nowadays but that would not be fun when we're talking about writing assembler.

Re: Nintendo releases original Zelda design docs

#45

Post by stevehb »

ldjb wrote: post #41
plasticbugs wrote: post #35

Earlier quoted context omitted.

BG Planning Sheet linked from Nintendo Europe: https://cdn02.nintendo-europe.com/media/downloads/games_8/wi...

For anyone curious about the few bits of Japanese on those sheets... On the BG Planning Sheet, 年 月 日 mean Year Month Day -- for indicating the date. 時 分 are Hour Minutes -- for indicating the time. デザイナー means Designer and プログラマー means Programmer. Oddly, the last page seems to be a mirror image, and it's quite difficult to read the text. However, it appears to be for designing an individual sprite. There is a field l…

I think the last page is for Ditto machines. I remember them being used for schools back in the 80s when all the copies came out in purple ink.

Re: Nintendo releases original Zelda design docs

#46

Post by georgeecollins »

gallerdude wrote: post #4

Even as a programmer, I appreciate having the vision of the game first and figuring out how to program it second.

I understand the sentiment but the best game I ever made was done in exactly the opposite way. So I don't know if it is the best way, unless maybe you are making a sequel.

Chris Taylor used to say the "game is the design document." There is obviously a lot of problems with that approach. But I have also seen terrible results from teams who plan on paper and neglect the reality of the work product.

Re: Nintendo releases original Zelda design docs

#47

Post by georgeecollins »

I once took an English class where we read screenplays that were printed in a book. One of them was of the great movie "Chinatown."

The professor --- who had never worked in film-- said: "See, the screenwriter really comes up with everything. See how he thinks of every scene, every bit of dialog, that the actors and the directors follow."

Later I read a book about the making of Chinatown and learned that the script was some huge thing that Robert Town and Roman Polanski rewrote every day while they were making the movie. The version in the text book was the correct script in the order of the final cut.

Anyone who takes a class in video game design or development should be wary of those who haven't really done it.

Re: Nintendo releases original Zelda design docs

#48

Post by dragonwriter »

georgeecollins wrote: post #47

I once took an English class where we read screenplays that were printed in a book. One of them was of the great movie "Chinatown." The professor --- who had never worked in film-- said: "See, the screenwriter really comes up with everything. See how he thinks of every scene, every bit of dialog, that the actors and the directors follow." Later I read a book about the making of Chinatown and learned that the script w…

The professor may not have worked in film, but probably was still aware of the process (which, at the level of description you provide, is pretty much common to all film.)

The professor remains correct that all those things are the role and responsibility of the screenwriter (and will, in fact, be reflected in an intended-as-final screenplay before the inevitable revisions that occur during shooting and the changes to the final result that occur in editing, etc., that end up getting reflected in a.ouhlished script.)

In an English (even screenwriting) class that isn't a class on filmmaking process, the details that you object to be omitted are generally irrelevant to the focus.

Re: Nintendo releases original Zelda design docs

#49

Post by rokosbasilisk »

mustacheemperor wrote: post #24
Waterluvian wrote: post #11

Earlier quoted context omitted.

"As a surgeon I appreciate planning the operation before cutting the person open." Your comment seems trivially true to me. How can one possibly begin the second without the first? And yet people try it all the time!

As an agile surgeon, I focus on immediate deliverables - we can figure out how to restart the heart once we've iterated breaking the ribcage a few times.

pretty sure you just described exploratory surgery.

Re: Nintendo releases original Zelda design docs

#50

Post by brenschluss »

duiker101 wrote: post #27
brenschluss wrote: post #23

Earlier quoted context omitted.

In Zelda's case, the level design _is_ the game mechanic - where you have to go to get a key, how the game forces you to double back in a dungeon, falling from one floor to the other through a hole, etc.

I disagree, all the things you listed are game mechanics, but they have nothing to do with level design. as a developer I should have all this different mechanics working independently of where they are in the level.

You speak as if "how the level design" comes after "what mechanic the game needs". I think it's simultaneous.

For example: If I say "Oh, it would be really interesting if there's a Dungeon of Reflection in which the entire dungeon is symmetrical, and the monsters always copy the character's movement", then that would require some careful level design, which having worked out, could translate into a mechanic.

Operating in reverse is much more difficult and ends up stuffing mechanics into a sense of play. "It's easy in code to make the character teleport! Now.. what should we do with this?"

Post reply on HN