Hacker News new | past | comments | ask | show | jobs | submit login
Nintendo releases original Zelda design docs (nintendo.co.uk)
336 points by jlturner on Dec 28, 2016 | hide | past | web | favorite | 45 comments

Don't be deceived: the reason why these plans look nice is because of the team structure of the Zelda project. The design team spent a lot of time drawing up polished graphics and layouts and then "threw it over the fence" for implementation, in waterfall fashion. This is still a common practice within Japanese teams, as evidenced by, for example, Mighty No. 9's documentary, where you can witness an entire level constructed in Microsoft Excel. [0] The separation of roles is not a definite downside if the game design is already well-understood, and American teams have flirted with big up-front design on occasion, but tend to lean towards making sure everyone stays hands-on and can test and iterate independently.

One of the stories about Zelda that appears in interviews is that the second quest is the result of a miscommunication about how much space was available: They could have had a single quest that was twice as big.

The main direct advantage of drawing everything out is that you can quickly explore different types of setups(relative scales, positioning, iconography, etc.) and do a few passes of testing on it before committing it to code, for the same reasons that one might do wireframing and mockups for application UI.

[0] https://youtu.be/Ri4bV3Z186Q?t=249

you don't have bootstrap for game development... you better make sure the levels you spend time developing are well designed.

How can you be sure they're well designed until you've tried playing them?

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.

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.

No man's sky would have been a bad game by either development practice; it's failure primarily stems from a misunderstanding of game design

The game was fundamentally shallow

While I agree on that I think the point of the parent was that No Man's Sky would never have been created if it was designer first.

well a lot of people may realize they don't really have a design, but will think that they can build one up as they work

Nintendo is an iterative developer. They prototype everything and they don't start on any final art or narrative development until the gameplay fundamentals are solid.

For example the Iwata Asks interview with the Splatoon team mentions that the early prototypes for the title were just experiments where boxes were running around in a box world shooting colours at one another. Once that was fun and the controls felt good they figured out everything else about what the game was going to be.

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.

Make no mistake though—Nintendo doesn't use that process exclusively. They also experiment, prototype, and refine.


"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!

Go to a good art museum and see the "studies" associated with many pieces of art. Before the final product, the artist has a bunch of experiments with techniques, framing, and the like.

One of the things we often lack in software is a good medium for exploring mechanics. Getting something to the point where we can conduct an "Is this fun?" test or more generically "Does this serve the purpose" without a massive development undertaking.

Yup, there's a very common game design technique called "White Boxing" where you design your levels out in white boxes until they're fun and then art comes in afterwards and makes it look realistic.

> One of the things we often lack in software is a good medium for exploring mechanics. > Getting something to the point where we can conduct an "Is this fun?" test or more generically "Does this serve the purpose"

A medium? Would you care to expand on this point? While I agree that more work could be done on speeding up the tools used, the process / concept / activity itself already exists, so I am not sure what you mean by medium.

PROTOTYPING is a fundamental part of the software engineering process (and other engineering disciplines), but I see it get missed A LOT in software development, for a variety of reasons. https://en.wikipedia.org/wiki/Software_prototyping

As vvanders has already said, "White Boxing" is a common technique for video game development.

It's not a great analogy, because surgery is not a inherently creative process the way game development is.

Plenty of games are created by jumping right in and starting to code, and then seeing where that takes you. For example, the throwaway game that inspired Portal.

Of course, eventually you do have to take periodic breaks to review things and plan the next phase.

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.

& the patient pays for that kind of service! He has a meeting to get to this afternoon

on the one hand, I refuse to believe this is true.

on the other hand, I've been subject to one surgery and been third-party to multiple others, and can't see how this isn't true.

That's... scary.

pretty sure you just described exploratory surgery.

Plenty great games came from exploring a a game mechanic more than from a level design. There are really a lot of games where the look of something can really mean nothing at all.

In today's industry an overlook like this might be useful in level design but I can't really see it having a big impact on the actual development of the gameplay as long as you know what actions the player can perform you don't need to know where they are going to be placed or what they will look like.

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?"

"A day of coding saves an hour of planning" is one of the first mantras to stick with me (I find it holds true for me)

Edit: I was also hoping there would be an album or collection of the Zelda assets - is it just the embedded ones on the page they released?

If this was the case we also wouldn't have these things called 'test units' which ensure the code does, uh, what it was planned to do. ;)

Agree! I think in this case these drawing have a lot of implementation details. It is actually the pattern table, the palette etc.

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.

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.

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.

Do also check out, if you haven't already, this Iwata Asks interview from 2009, which contains further insight into the development of the original Zelda, and more design documents:


(Be sure to click the Next button at the bottom of that page for the second part.)

Very disappointing. Uploading a few sketches to a blog is hardly what I'd call "releasing original design doc". Where's the rest of it? What about the story? Boss mechanics? Weapons? Enemies? Dungeons?

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.

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.

It seems kind of obvious that Nintendo would have Official Game Asset Graph Paper, but it's pretty cool to actually see it.

Can we have the url point to https://www.nintendo.co.uk/News/2016/December/Take-a-look-be... (the original) instead? I didn't see gamasutra adding anything worthwhile

By manually changing it you've overridden the dupe post check. I posted this Nintendo article 5 days ago. https://news.ycombinator.com/item?id=13240858 https://www.nintendo.co.uk/News/2016/December/Take-a-look-be...

It can be seen in the search: https://hn.algolia.com/?query=https:%2F%2Fwww.nintendo.co.uk...

By HN's standards it doesn't count as a dupe, because the previous submission didn't get attention. See the bit about reposts in the FAQ: https://news.ycombinator.com/newsfaq.html.

In other words, even if the nintendo.co.uk URL had been the submitted one, HN's software would have happily let it through. This is by design. It gives good stories multiple cracks at the bat, in the hope of compensating for the randomness of the lottery on /newest.

We do have a few tricks to try to reward the original submission of a good story, and eventually we intend to work on more sophisticated dupe detection that will reward the original submitter more. In the meantime, there's still a fair bit of randomness. But if an account submits lots of good stories, it evens out.

Thanks for the clarification.

Previously when I had dupe posted something it seemed to be counted as an up vote for the original post or I got an error that it had already been posted without a redirect.

A suggestion: Reposts count as up votes for original submission AND it puts another submission into the newest queue. Maybe with a REPOST tag and a counter for times REPOSTED.

Additional visibility could help post get more up votes and make it to front page.

Current system doesn't reward poster for being first, as you said, it is up to the lottery of /newest.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact