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