Hacker News Reader

Comment by gallerdude | Hacker News Reader

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.

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

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

http://iwataasks.nintendo.com/interviews/#/wiiu/splatoon/0/0

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.

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

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

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.

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. ;)

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?

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.

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.

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.

Reply on news.ycombinator.com