そのデザイナーさんが
最初にプチゲームをつくった仕組みは、
最終的に商品になったものと比べて
まだ遙かに貧弱な状態だったんですよね。

そうです。

それでもすぐに、いろんなことができたんですか？

はい。やれることは少なかったんです。
でも、逆にできることが少ないからこそ、
パズル的に組み合わせれば「こんなことまでできるんだ」
という発見につながったんですね。

やれることが少なくても
複数の機能を組み合わせて応用すれば
いろんなことができると。
でも、ゲームというのは
多種多様な動きをするものですから、
思いついた機能はどんどん足していきたくなるものですよね。

そこをあえて
本当に必要な機能だけを入れるようにしました。
それで実際にゲームをつくってみると、
いろんなパターンに応用できたんです。

つまりいろんな機能をまず足して、
そこから不要なものを引いたのではなく、
少ない機能でも多彩に楽しめることを確認しながら、
本当に必要な機能だけを足していったんですね。
こういうときは、どんどん機能を足したくなるはずですが、
よく我慢できましたね。

そもそも、いろんな機能のボタンが
たくさん並んでいたら、
どれを選べばいいのか迷ってしまいますよね。

そこでまず、機能選択のボタンを
6個にしようと決めて、それに収まるように
大事な機能を優先して入れるようにしたんです。

たとえば、マリオを
同じ場所でジャンプさせたいときがあるとしますよね。
そんなときは「ピョンピョン」という機能を使うのですが、
そのままだとカエルのように
画面の枠のなかをあちこちピョンピョン跳び回るんですね。
そこで移動のエリアを狭めると、
同じ場所をピョンピョン跳ぶようになると。

移動の幅を狭めることで
垂直にジャンプするようになるんですね。

でも、畠山さんは、
いろんな機能を追加したいと思いませんでしたか？
「6個じゃ足りません」とか言って（笑）。

実はその通りです（笑）。もともと僕は
ゲームづくりの経験が浅いということもありましたし。

あれもこれもできたらいいと
そう思うのが当然ですからね。

そこで阿部さんに
「こんなアクションもできるようにしてほしい」と伝えても、
「それはこれとあれを組み合わせればできちゃうから」
と言われることが多かったんです。
で、終いには必殺ワザのようなセリフを浴びせられて・・・。

必殺ワザ？

「このゲーム、数秒で終わるから」と（笑）。

あははは（笑）。
確かにプチゲームは数秒で終わっちゃいますね。

そんなに凝ったアクションをさせようとしても、
数秒後にはパタンと閉められちゃうゲームなんだからと。

ちょっとズルイけど、妙に説得力がありますね。
シューティングゲームをつくっていて
途中で挫折するような飽きっぽい自分でも、
これならつきあえるかもしれないと思ったんですね。

そうです。
そもそもプチゲームは、
短いゲームだと4秒、長くても8秒なんです。

あっという間ですね。

とは言うものの、
いろんなプチゲームをつくれるようにはしたいと。
そこで、いままでのゲームが実現できるかどうか、
『俺』を使って実験をやってみたんです。

つまり、『さわるメイドインワリオ』の
プチゲームがつくれるかどうか、
『俺』で再現しようと試みたんですね。

そうなんです。
『さわる』の中で、タッチするだけでゲームができる
最初のステージを再現しようとしました。
その実験を通じて再現できたりできなかったりしたんですけど、
再現できなかった場合は
どうしたらできるようになるか
何度も調整を繰り返すようにしました。

最終的にどのくらい再現できたのですか？

ほぼ100パーセントです。

ランダム性があるものについては
ちょっと難しかったりするんですが
ほぼ再現できました。

いろんなことができるようになっただけに
デバッグの作業は大変だったんでしょうね。

そうですね。今回はとくに、
「つくる」部分を先に固めておきたかったということもあって、
わりと早い段階でその部分のデバッグを先行して進めてたんです。
そしたらデバッガーの人たちも
どんどんつくるようになって・・・。

デバッグをしてくれる人たちが
プチゲームをつくる職人になったんですか（笑）。

もちろん、プチゲームをつくることも
デバッグ作業の一貫なんです。
ところが彼ら、仕事の枠を超えて
どんどん高度なワザを駆使するようになっていったんです。

開発者でさえ「負けた」と思うような
すごいモノをつくるようになったんですね（笑）。

プログラマーは1人もいないんですけど。

あるとき、デバッグチームの1人に
「この動きができないのは問題じゃないでしょうか」
と指摘されたことがあったんです。その時は、
「そこは技術的に難しいので、保留にしましょう」
と返答したんですけど、しばらくたってから
「これとこれを組み合わせたらできました」と
戻ってきたこともありまして。

どっちがプログラマーなんだ！？（笑）。

（笑）

だから、今回の『俺』には、
デバッグチームの人たちがつくったプチゲームが
そのまま入っていたりするんです。
スタッフクレジットのなかにも、
デバッガーの方々のそういった人たちの名前が出てます。

「ゲームデザイン兼デバッグ」として（笑）。

それはすごいですねえ（笑）。
こんなこと、前例がないんじゃないですか。

開発者でなくても、ここまでできるんだというのが、
そのときよくわかりましたね。

でも、デバッガーの人たちも、
「開発者の人たちの気持ちがわかりました」と言ってくれたんです。

彼らがつくったプチゲームに対して、
「ここはもっとお客さんのことを考えて
なおしたほうがいいんじゃないでしょうか」と
僕たちが評価してたんです（笑）。

いつもと真逆じゃないですか（笑）。

（笑）

そんな指摘をされたデバッガーの人たちが、
「僕らはいつもそんなことを言ってたんですね」と（笑）。

デバッガーのみなさんが
ゲーム開発者の気持ちがわかるきっかけになって
ゲーム開発者に優しくなれるソフトなのかもしれませんね（笑）。
 
ちなみにデバッグと言えば、任天堂は今回、
杉岡さんにすごく迷惑をかけたんですよね。

今回の商品で初めて使われた
「NANDカード」のことですね（笑）。

「NANDカード」というのは、
NANDメモリという大容量化に適したフラッシュメモリを搭載した
新しいタイプのDSカードです。
通常のDSソフトで使われているDSカードと比較して
大容量のデータを書き換えて保存することができることや、
データの消去や書き換えが高速に行える特徴があります。
 
もしわたしが阿部さんに
「NANDカードを使ったら」とさえ言い出さなければ、
このソフトはもう少し早く出せたはずでした。

岩田さんからアドバイスをいただいたあと、
すぐに社内のハード担当スタッフに相談したんです。
この開発スケジュールで「NANDカード」を使いたいと。
そしたら「やめたほうがいい」と言われたんです。
スケジュール的にちょっと厳しいということで。

それでも採用しようと思ったんですね。

「NANDカード」は、データの書き換え速度が
圧倒的に速かったですから。
もともとは『バンブラDX』で使われたDSカードと
同じものを採用するつもりだったんですけど、
それだとどうしてもセーブするのに時間がかかってしまうんです。
 
『俺』というゲームは、
つくってはセーブし、つくってはセーブしと
つくったデータを頻繁に保存したくなるんですけど、
『バンブラDX』のDSカードだと4〜5秒待たされて、
それがストレスになってしまうんです。
だから、いくら開発が難しくても、
セーブ速度が圧倒的に速い
「NANDカード」を採用すべきだと考えました。

それに、セーブできるプチゲームの本数が
増やせるというメリットもありましたしね。
ちなみに、90種類まで保存ができます。

ええ、そういう相性の良さがわかっていたからこそ、
開発途中でできあがりつつある「NANDカード」を
使ってみてはどうかと提案したわけです。
でも、ゲームソフトで初めて採用したメモリだっただけに
原因不明の問題が発生してしまいました。

開発機材ではまったく問題がなかったのに、製品仕様の段階で
そのメモリを使ったら、突然止まる現象が起きてしまって。

その原因を杉岡さんが解明してくれたんですよね。

結局、杉岡さんには「NANDカード」のハードのデバッグまで
担当してもらうことになってしまいました・・・。
開発機材で再現しない問題を解析するのは
かなり難易度が高いデバッグなので、
もし、杉岡さんが奥深くに立ち入って
原因となっていた部分をピンポイントで見つけてくれなければ
今でも発売のメドが立っていなかったかもしれないです。
ありがとうございました。

いえいえ、今後のことを考えると
「NANDカード」を採用してよかったと思っています。