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.
The game was fundamentally shallow
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.
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!
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.
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.
As vvanders has already said, "White Boxing" is a common technique for video game development.
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.
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.
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.
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?"
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?
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.
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.
(Be sure to click the Next button at the bottom of that page for the second part.)
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 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 can be seen in the search: https://hn.algolia.com/?query=https:%2F%2Fwww.nintendo.co.uk...
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.