When reporting on this translation you must mention that it was translated by Soma for Source Gaming. Please include a link to either our Twitter account, or to this article WITHIN the actual article. For additional information, please read this post. This translation is for fan use only, and may not accurately reflect the opinions of Masahiro Sakurai.
This column was originally published on April 21st, 2016 in Weekly Famitsu (Japan time).
Let’s Try to Make it First and See What Happens? Volume 504
Today, I’d like to offer this piece of advice: “directors, or game designers, should have a picture of the finished product in their head before they start work on a project plan.”
The president of Nintendo, Satoru Iwata, passed away on July 11th of last year. But until the end of June, we were still exchanging emails. This ended up being my last email from him, but I’ve decided to show you all an excerpt from this email.
“Sakurai-san, your ability to make the final image of what you want in your head ‘move’ is a very special thing you have. Actually, in this respect, you’re a rarity among even the entire games industry.”
Mr. Iwata very rarely offered compliments or flattery. However, he excelled at conveying the true essence of something to other people in a simple, comprehensible way. Getting back to the main topic now, when you are making a game, having a strong grasp of what you want your finished product to look like is not easy. Mr. Iwata has worked hundreds, or maybe even thousands of game developers, so this is a statement that’s backed by his instincts, cultivated over his long work in the games industry.
However, I think that it’s obvious, even normal, that the person behind the project plan would put a lot of thought into it from the beginning. Otherwise, you end up having to put in a lot of trial and error, and you put a larger burden on your development team. Costs pile up, completion seems to grow ever farther, and nothing good comes of it. For my projects, the project plan is usually very close to the final product, that fact can be seen in some of the information I’ve revealed in my columns or books. That doesn’t mean that I don’t change things during development, or that things go without a hitch, but most of the gameplay does not largely differ from what I had decided on in the beginning.
As a developer, there are times when I see design documents for games that just didn’t come together and were never released, but I think this may happen because developers think, “let’s try to make it first and see what happens,” and end up over-rationalizing their work using this train of thought. You made something, but it’s not as fun as you thought it would be. You change the rules, change the control scheme, or start tweaking the challenge of the gameplay. I don’t know if you end up wandering off course first, or if you start over-tweaking first, but I don’t think that excessive trial and error is healthy. If you have a lot of time, than really working hard and getting into the fixing process is fine, but most of the time that’s not going to be the case.
One of the things Mr. Iwata used to say was, “programmers don’t say ‘I can’t do that.’” But I think if you take this too strongly to heart, that’s not good. There are some things that you actually can’t do, and on the design side, the designer should be able to predict things like that as well. If there’s something that can’t be done, both the programmer and the designer should continue to come up with alternate solutions.
However, if the programmers take the previous stance, then I think “game designers don’t say “let’s think about it after we make it’” is also true. Doing things like fine game balancing may only be possible after you’ve made some amount of work on a playable product, but if you try to add things after the general overarching game design has been decided, you’ll just end up with an uneven product.
Of course, you could say much the same about graphic design, or coding a program, or even any other sort of creative endeavor. This isn’t just limited to games– if your job is to come up with a plan or blueprint, think about your goals and move towards them swiftly!
There are exceptions. Even if a director is being vague and ambiguous, there are ways to use your team’s chemistry and potential to their best. There might be teams that work well with a build-and-crash type of workflow. There are no right answers. Teams can work as they see fit.
Remember, you’re working with computers, which are highly logical. Stay flexible and adapt to the situation! But don’t lose sight of your original path! How’s that for advice?
Make sure to follow us on Twitter for more news and translations, straight from the source!
We are also going to E3 this year– but we need your help to get there! Check out our GoFundMe for more information.
Latest posts by Soma (see all)
- Japanese Players’ Impressions of the Switch - January 18, 2017
- Melee Development Timeline (in-progress) - September 16, 2016
- Smash 64 Developer Interview with Sakurai (HAL website) - September 13, 2016