6 ms·
Even as a programmer, I appreciate having the vision of the game first and figuring out how to program it second.
by gallerdude 10y ago
Even as a programmer, I appreciate having the vision of the game first and figuring out how to program it second.
- jfroma 10y agoAgree! I think in this case these drawing have a lot of implementation details. It is actually the pattern table, the palette etc.
- deleted 10y ago[deleted]
- deleted 10y ago[deleted]
- bluedino 10y agoAre there larger scans of those sheets anywhere? Possibly a blank?
- plasticbugs 10y agoBG Planning Sheet linked from Nintendo Europe: https://cdn02.nintendo-europe.com/media/downloads/games_8/wiiu_supermariomaker_1/Super_Mario_Bros_sheets.pdf https://cdn02.nintendo-europe.com/media/downloads/games_8/wi...
- ldjb 10y agoFor 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.
- stevehb 10y agoI 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.
- deepsun 10y agoBut 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.
- thesimpsons1022 10y agobut 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.
- setr 10y agoNo 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
- Volt 10y agoMake 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 http://iwataasks.nintendo.com/interviews/#/wiiu/splatoon/0/0
- 10y ago
- Waterluvian 10y ago"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!
- deleted 10y ago[deleted]
- deleted 10y ago[deleted]
- deleted 10y ago[deleted]
- raldi 10y agoIt'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.
- lostgame 10y agoIf 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. ;)
- duiker101 10y agoPlenty 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.
- brenschluss 10y ago
- georgeecollins 10y agoI 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.