㈱ソニー・コンピュータエンタテインメント久夛良木健氏と五十嵐和久氏による対話

2D, 3D, 動画をすべて統合

五十嵐（以下,I）ハードウェア構成でまず気になるのはGTE、 GPUといったグラフィックス周りですけれども、どういったデザインになっているんでしょうか。 

久夛良木（以下、K）われわれのPS-Xは、完全にゲーム機として作ったんですが、今までの2次元的な表現だけじゃなくて3次元的な表現も同時にできます。ゲーム機であるためには2次元と3次元がリアルタイムで合成できるぐらいのスピードが必要ですから、それに適したアーキテクチャになっています。 

　今までにも、3次元グラフィックスの表示できるアーケード用のゲーム基板というのはあったのですが、それは場合によっては3次元に特化した回路、もしくは2次元に特化した回路になっていて、2つを合成するのが非常にやりにくいハードウェア構成だったようです。PS-Xでは2次元の機能と3次元の機能を統一したアーキテクチャで、同じハードの上で混在して実現できるというのが最大の特長です。

　あるキャラクタが3次元で描かれていて、ところがゲーム上のマップなどは2次元であるとか、もしくはその逆ですね、3次元のワールドがあってキャラが2次元であるとか、そういった混在使用がPS-Xでは自由にできるんです。 

I）それは、2次元的なスプライトが3次元のレンダリング（光源計算）された背景の上に乗ることもできる････ 

K）そうです。キャラクタが2次元か3次元というのはアーティストの人たちがどういう表現をしたいかということですから、特定のキャラクタ、あるいはすべてのキャラクタが2次元である必要はない。たとえば手だけ3次元で描いてもいい。そういうことが自在に混在できるんです。

　PS-Xは3次元に特化したハードであるというふうに思われがちなんですが、今までのアーキテクチャを持ったワークステーションやパソコンで3次元を実現しようとすると大変な計算力が必要なので、やっと3次元を実現しているというのが現実で、その中でさらに2次元を使うというのはもっと大変なことだったんです。 

I）そうですね。 

K）いわゆるマルチメディア・パソコンで使える動画というのは、ウィンドウを空けて表示するスタイルが多い。ところがゲームにおいては、そういうタイプのゲームも確かにあるんですが、実際、キャラクタの形に切り抜いた動画が欲しいとかいう必要もあります。

　動画のデコード・エンジンというのを１つCPUのリソースとして本来持っていればいいんですが、MPEG1とか、そういった動画形式専用のデコードLSIがすでに存在していて、それをアド・オンの形でPCとかゲーム機に付けるわけです。すると動画をどう合成するかというと、動画とそれ以外、でき上がった画像同士を合成する、そこでの優先順位というのは、後ろに張るか前に張るかウィンドウを空けるかになります。ゲーム機というのはそうじゃなくて、あくまでも圧縮した画像を解凍して自由に使えるというのが本来必要なのです。

　ところが現状では、そういったLSIはなかなかないわけです。ソフトウェアでのデコードはできるんですが、それではリアルタイム性が損なわれます。ですからPS-Xでは3次元も2次元もハードウェアで統一して扱えるように拡張しているわけです。今までは3次元のチップと2次元のチップがあって、それが最後に合成されていた、これだと、空間表現とかキャラクタとかの使い回しの自由度が減るので、PS-Xでは動画も2次元も3次元も統一のアーキテクチャで成り立っていて、すべてCPUがいじれるという形になってます。 

PS-Xの設計思想

I）すべてをプロセッサを使ってソフトウェア的に処理するという形ならそういう形式も可能ですが、実際にはアド・オンのハードウェア、グラフィック・パイプラインというようなものを使ってらっしゃると思うんですけれども、それをどうやって汎用的になさっているわけですか。 

K）まず、ワークステーションでJPEGを解くこともできれば、スプライトも時間をかけて描くこともできる、3次元のレンダリングもすることができる。ただ、むちゃくちゃに時間がかかったりするわけですね。ところがゲーム機であるためには少なくとも1/30秒で、理想を言えば1/60秒でいろんな処理を全部完結したいという要求がある、それを全部やらせようとすると、当然ソフトウェアだけでは、今あるCPUのどれを持ってきても困難ですね、PentiumやR4000でもだめ。 

I）そうですね。 

K）そうすると分散することになりますね。グラフィックスの処理というのはものすごくたくさんの計算能力が要る。特に2次元の計算を3次元まで拡張するともっと要る。それを今までのワークステーションですとパイプラインで実現していたんですよね。どうしてかというと、どんなグラフィックス・ワークステーションでも、使えるプロセッサというのは市販のものがほとんどです。

　すると限定した計算力のものを並べることになる。処理は並列にも行なうわけですが、どうしても計算能力を上げるため直列になる部分も出てくる。そこでパイプライン構成になり、レーテンシ（遅延）が増えるわけですが、それでも今までのワークステーションですとそれで十分よかったわけです。どうしてかといいますと、たとえばテレビ番組制作のために1画面1/30秒でアニメーションをするような用途のためにグラフィックス・ワークステーション存在していたんですが、なにもアニメーションを作るのにリアル・レスポンスである必要はないわけですから、パイプラインの段数をいくら増やしても構わなかったんです。 

I）パイプラインの各段ごとの処理時間は短いですから、パイプラインを使うことによるレーテンシというのは実際には問題にならないのではないですか? 

K）ものすごく問題になりますね。 

I）なりますか。 

K）ゲームにおいては、これはもう本質的な問題です。たとえばバーチャルリアリティでヘッドマウント・ディスプレイをかぶって何かやりますね、あれでめまいがする最大の理由というのは、横を向いたときに絵がついてくるスピードなんですよね。 

I）それは処理能力そのものの、つまりボトルネックに起因するものではなくて、パイプラインによるレーテンシの結果そういうことになる部分が大きいと。 

K）そうです。どうしてかというと、最近のグラフィックス・ワークステーションは数段のパイプラインになってます。1段の処理を60Hzでやるとしますと、各段あたり16.6msですね、すると6段で0.1秒遅れます。人間がそういった遅れを感じ始めるのは0.1秒,見る人が見るともっと分かる。また感じなくなったときに何が起こるかというと、感覚的なめまいになるんです。この遅れというのはなるべく短いほうがいい。 

I）はい。 

K）それから、今回バーチャルリアリティをやるわけじゃなくてゲームをやるわけです。従来の家庭用ゲーム機はフレーム・バッファを持たない構造なので、ライン・バッファで1Hブランク（水平帰還期間）中にキャラクタをスプライト・データで送るということをします。そのため1走査線に並ぶスプライト数には制限があったんですが、最大のメリットは描き替えるときに、アセンブラでたたいて、それが絵になるまでの時間遅れがなかった。皆無ですよね。 

I）レーテンシ発生がない。 

K）ですからボタンを押してからキャラクタが動くリアクションがすごく速いので快適だったわけです。ところが業務用のゲーム機ですと1走査線にキャラクタが8個なんて制限では困りますから、フレーム・バッファ方式になっているわけですね、そうなったときにダブル・バッファでそれを描くときには、最短でも･･･ 

I）最短でも1フレームずれると。 

K）1フレーム遅れる。だけど実際にはコントローラのデータを読んで、ゲームの計算をして描き込んで表示するわけですから、業務用のゲーム機は今2フレーム遅れてるんです。 

I）フレーム単位で描く限り、それよりは速くなりませんね。 

K）ですから今のワークステーション方式を使うと何が問題かというと、遅れがありすぎて、あれで格闘ゲームとかレーシングゲームをやると、たとえばハンドルを切ると、実際に曲がるのに0.1秒位かかる。それからポリゴンを使った格闘もので技を使いますが、たとえばストⅡであるとか、あの辺のリアクション性とは違うある重さを伴って技が出る。それだけ遅れているわけです。 

I）はい。 

K）あれは、ゲーム機においては本来あってはいけない遅れなんですよね、それを短くするためにはパイプラインの段数を減らさなくちゃいけないんです、パイプラインとパイプラインの各段では通常Vブランク（垂直帰線期間）周期、つまり16.6msで処理します。そうしないと画像処理ですから次の段に送れません。それを大体10段弱ぐらいでやっているとすると、約百数十ms遅れてしまう。ですからパイプライン・アーキテクチャを使う限りは、ワークステーションを持ってこようと業務用ゲーム機を持ってこようと、リアクション性でゲームボーイに負けるんです。 

I）そういう意味では負けますね。 

K）ところがゲームというのは、このリアルタイムのリアクションが非常に大事です。横で観客の立場で見ているとゲームになっているんですが、プレイしてみるとフラストする。1/60秒の世界というのはゲーム機の命です、世の中にテレビというのが各家庭にインフラとしてあるからテレビゲームが成り立つんです。

　テレビというのは、NTSCでは1/60秒で絵が描き替わるんです。では何で1/60秒でテレビジョンのシステムを作ったかというと、それが一番みんな動画と錯覚するからです。映画が24コマなんですが、パンするとパタパタパタっとした感じがする、その60分の1秒の絵のアップデイトというのが、人間が動画として感じる1つの基準なんです。もう1つはさっき言ったようにリアル・レスポンス性… 

I）レーテンシ、フレームレートの両方が重要になる。 

K）両方がゲームにとっては重要なんです。もう1つの重要な点は、ゲーム機というのは絵と音を「再生する」機械ではないということなんです、コンピュータで絵と音を「合成する」機械です。ですからそれが成り立たないと、ゲーム機としては失格です。 

VブランクとVブランクの間の世界

I）PS-Xの場合はどうやってレーテンシの削減をされたわけですか? 

K）業務用のゲーム機と同じように最大で2フィールド遅れ、だから1フレ遅れのレーテンシ、1/30秒で全部やり切るという基本アーキテクチャになっているんです。そうするためにはまずパイプライン、VブランクとVブランクの間を越えるパイプラインを極力廃止してます。 

I）パイプラインではなく、並列処理で行なうということですね。 

K）そうです、可能な限り並列でやります。もちろん、VブランクとVブランクの間では流れていきますが、中でやっていることは並列です。たとえばGTEで計算した結果をグラフィックスに送るということは1つの画面を作るためにやらなくちゃいけない処理ですが、それはVとVの間でやってしまうわけです。 

I）処理のどこが直列になって、どこが並列になっているのですか。まず最初にGTEは直列ですよね、頭に入りますよね。一番最後のスキャン・ライン（走査線）を描く部分というのは並列になりますよね。 

K）そういう意味からすると、GTEは座標変換だとかレンダリングだとかいった処理を行なうのですが、この中は全部並列です。

I）並列的に座標変換演算を行なうということですか。 

K）もちろん、ジオメトリー・エンジンとかGTEとか言っているのは、論理的にいったプロセッサをそう呼んでいるわけで、実際には中身はもっとたくさんのプロセッサの集合なわけです。 

I）各段階で並列処理を行なって、それを一括して次のステージに渡してということで、結局3段ぐらいになるわけですね。 

K）ステージという意味では本当にないんです、そのステージというのをどういうふうに言うかなんですが、たとえばプログラムするとするでしょう･･･ 

I）普通のアルゴリズムでは、まず座標変換した結果をZ方向にソートして画面に描き込まないと、隠面消去できないですよね。 

K）そこを論理的なステージと見ると、そこが1ステージになる。ただ、それはVブランクとVブランクの中に入り込んでいる世界なんだけども。処理の組み合わせはソフトウェア・ドリブンなので、GTEでソートした結果を描画しながら、またGTEでソートして描くという、そういった入れ子構造になるようなものもできるんですよ。 

I）なるほど、たとえばこの絵なんか前景,中景,後景ですか? 

K）いや、そうじゃなくてそういうふうにバックグラウンド的に割らないで、ただ単に一連のZで描かれています。 

I）たとえば、この後ろのツリーの絵を描いている間に、この3次元の絵の座標変換計算を行なって、これの描き込みを行なっている間に･･･ 

K）そういうふうにやろうと思ったらできます。 

GTEこそPS-Xの肝だ

I）GTEのほうは大体ごく普通の機構だと思っていてよろしいんですか。 

K）PS-XはすべてがカスタムLSIで構成されています。ではなぜワークステーションでできないことがゲーム機でできるかというと、それはすごく簡単なことで、精度を落としちゃえばいいんですね、CADとかワークステーションですと、すごく精度が必要です。ところがゲームの場合はどんなに高解像度だといってもテレビの解像度ってたかが知れてますから、いろんな部分で精度を落とすということをやっています。

　市販のプロセッサを使えば、当然16bitとか32bitとか固定の演算しかやらないわけですよね。ところがわれわれは中で13bitをやることもできれば7bitをやることもできるし、35bitをやることもできるしというふうに最適化するので、そこで初めて可能になるんですね。 

I）ビット長はデータ長ということだけで考えれば、一番簡単に可能な並列化要因になるんじゃないんですか? つまり石の数だけを増やすことによって、演算でも･･･ 

K）でも無駄なことが起きますよね。たとえば32bitのDSPを使って、音の演算をすると、でも結果としてみんな16bitで十分と。そうすると残りのビットというのは、ある意味では非常にもったいない演算をしているということになるわけです。フルカスタムのLSIで成り立っているということがまず第1点、次にビット長が各段ですべて最適化されている。それは人間の感覚で全部シミュレーションしてあるんです。サウンド方面ですと、ヒアリングのシミュレーションをする。画像ですとビューイングのシミュレーションをする。それでエンターテイメントでは十分であるというふうに考えます。 

I）GTEというのは何bitのものが何個ぐらい並列化しているわけですか。 

K）GTEでは、全部インテジャー（整数）で計算します。どうしてかというとフローティング（浮動小数点）演算の必要がないんです。でも32bitのインテジャーでも、全部のワールドを表現するのには足りないという場合もあります。ですから個別の要素を何ビット以内で計算して、ワールドとしては合計こうだとかという、そこも最適化している。ただし何クロックもかけてフローティングの演算をしてもしょうがないので、1クロックで動作するようにして、それを集めることによって相当の計算数を得ています。

　一般にはインテジャーなりフローティングのDSPを皆さん使って、座標変換の演算をやっていると思います。PS-XのGTEは3次元の透視変換をするだけじゃなくて、ほかのいろんな変換もします。、光源の計算もする、いろいろな変換をここでやります。 

GTEからGPUへ

I）GTEについて、全体の規模を教えてもらえますか? 

K）ちょっと計算が難しいんです。ただ、そこで演算できるスピードは、150万ポリゴン/secの座標変換演算ができる。これは全部独立三角形での性能です。 

I）ということは毎秒450万頂点について、座標変換演算ができるということ。 

K）そうです。描画と別ですから、なぜ独立三角形というと、ゲームですから全部ポリゴンが独立でないと後で厄介だからです。その450万頂点というのはフラット・シェーディングの場合、つまりX、Y、Z、それから1カラーの場合ですね。 

I）それはGPUなどのボトルネックが絡んでくる話ですよね。 

K）そうですね。 

I）その座標変換した後に、今言われたシェーディングを行なわなきゃいけないと思うんですけど。 

K）レンダリング部分ですね、それ以降は全部GPUというプロセッサになります。 

I）シェーディングとラスタライズも両方とも･･･ 

K）シェーディングですね、それからテクスチャ・マッピング、ラスター、それはGPUの機能です。 

I）Zバッファというようなものは持たないわけですか。 

K）Zバッファは持ちません。コストの点で持てないと言ったほうが正しい。だからZソートでやります。ソートそのものについてはハードでサポートします。 

I）このソートされた結果というのは･･･ 

K）まずメインメモリ上に持ってきます。 

I）メインメモリ上に1画面分全部入る。 

K）普通入れるでしょう。 

I）メインメモリ上でソートされてインデックスがついてというようなデータ形式になる。 

K）そう、タグがついてとか、そういった形で絵を送り出すわけです。 

I）それはどのくらいのサイズになるんですか。 

K）これは何十Kbytesかもしれないし、こういうのをダブルバッファで持たなくちゃいけないとすると、それだけで数百Kbytesを超える場合もありますね。 

I）かなり大きいですね。中間結果を保持するようなことを考えてられるわけですか、たとえば座標変換演算をした結果だけを保持して、レンダリングだけ変えていくラジオシティのような方法ですね。 

K）ソフトウェア的にはできます。GTEで計算した結果データを、データとしてCPUから送り出すということをすると、もっと別なこともできます。 

I）それはGTEで計算したほうが速いですか。 

K）GTEで計算したほうが速い、今回ラジオシティはGPUでできないわけですけども。CPUとそういった持てるプロセッサを組み合わせることで可能なわけです。この辺がPS-Xのおもしろいところで、GTE, GPUなどのハードウェアリソースはすべてソフトウェア・ドリブンですから、いろんな使い方ができるわけです。Zソートした結果は1本のデータ列になるんですが、そこを何階層も階層化できる。 

I）それがGPUに入ると。基本のシェーディングとしてはフラット・シェーディングですか? 

K）基本というとフラット、グーロー、テクスチャと、グーロー＋テクスチャですね。 

I）テクスチャについては特定の場所に入っているわけですか。 

K）テクスチャは基本的にVRAM上に置きます、VRAM上にどんなデータが入るかというと、まずダブルバッファのためのフレーム・バッファがありますね、それ以外にCLUT（Color Look Up Table: パレット）、それからテクスチャのソースイメージがそこに入る。テクスチャもスプライトのパターンもソースとしては同じですね。 

I）テクスチャとスプライトは同一の機構で実現されているわけですね。 

K）そうです。まったく等価に扱えます。基本的にはそれがVRAM上に配置されます。 

I）それはRGBAですね、アルファもあるんですよね。 

K）アルファもあります。ただワークステーションみたいな精度は要らないので、最小限度となっています。ただ、そのアルファというのも階層化して重ねることはどんどんできますから、もっとやわらかな表現はいくらでもできるようになってます。 

I）そうするとメインメモリからGPUに転送するのはDMA的に行なわれる。 

K）DMAで行なう。GTEが描いたものをCPUが介在してGPUに送り出したら遅くなってどうしようもない。1回ワーッと計算したら、あとはもうハードウェアが画像データを送り出すことができる。 

I）GPU自体はフレーム・イメージをどういう格好で持っているわけでしょうか。フレーム・バッファに描き込んで、そのフレーム・バッファを表示するという、割とコンベンショナルなやり方ですね。 

K）そうです、そのフレームの裏面のフレームに描くときには、当然先ほどいったCLUTであるとか、テクスチャであるとか、いろんなデータを合わせてきて一気に描くわけです。 

MPEGの使い方を間違うな

I）動画展開についてMDECというような言い方がされていますけども、MPEG, JPEGなどの形式のデータもGTEとGPUを使って表示するということですね。 

K）コンセプト的には違います。つまり本来なぜJPEG, MPEGを持ってきたかというと、なにもムービーを出したいから持ってきたわけではありません。データがもったいないから圧縮して持とうということです。ゲーム機というのはパソコンと違って、コストの問題でメインメモリは可能な限り小さくしたいんです、できたらゼロにしたい、カートリッジの中に入れたいぐらいなんだけど、そうもいかないので最低限持つわけです。

　そこにもしベースバンドに近い形で画像のデータを持っていると、2つ問題が起こる。まず、メモリが足りないから増やせという話になるんですよね、次に同じデータを転送するのに帯域幅の制限で遅くなる。それを避けたいわけです。ですから圧縮して持っていて、使うときだけ解凍すればいい。 

I）使うときに絵をVRAM上に転送して、たとえばVRAM上に置いて、マッピングするなり何なり素材として使うということですか。 

K）そうですね、それができるのが大原則であって、つまり四角い絵を解凍するんじゃなくて、とにかく圧縮したパターンを･･･ 

I）圧縮したパターンを動画としてどこかにマッピングする。たとえば画面の一部に映画が映っているとかも可能であると。 

K）やり方はまったく自由ですが、パターンをベースバンドで持っていると高くつく。VRAM上には当然持ってなくてはいけないけど、ソースとしてメモリ上に持っているのはバカげているので、メインメモリ上には圧縮した状態で持とうということです。もしくはCD-ROMからメインメモリに持って来て、そこからVRAMに必要に応じて展開しながら転送して表示する。 

　メインメモリからVRAMに送り出すときに、CPUによる処理のステージを1回はさむわけです。MDECを通しなさいとか指定すると、VRAMに送られているときには解凍されている。

　今度はそこでの問題なんですが、ワークステーションでもVRAMの上で持っているテクスチャは快適にマッピングできるんだけども、メインメモリからVRAMに持ってくるにはけっこうセットアップがかかる場合がある。どうしてかというと、バスがそれだけ速いものがたくさん積まれてないから。今回はMDECにしろ、それからグラフィックスにしろ全部メインメモリに直接つながっているんです、そのメインメモリの転送レートが132Mbytes/secある。 

I）これはどうやって稼がれているんですか？　メインメモリで132Mbytes/secということは、SRAMを使うか、何か特殊なDRAMを使わないといけませんよね。 

K）ですね、これはノーコメント（笑）。要するに帯域幅を稼ぐというのは当然みんな考えつくことなんだけど、それがなかなか実現できないんです。帯域幅を稼ぐには方法はいろいろあって、たとえばバスの幅を広げる。64bitにする。128bitにする、これも1つの方法。ところがPS-Xのメインバスは32bitですから32bitで132Mbytes/secを実現するためには、これは1クロックでアクセスするしかないわけですね、しかし1クロックでやるためには普通高速のSRAMを並べるしかない。でもさすがにSRAMを並べて5万円とはいきませんから、SRAMじゃない、だけど、その後はちょっとノーコメント（笑）。 

I）バースト時132Mbytes/sec, メインメモリに対してとれるということですか。 

K）とれます。それはVRAMに対してもとれる。 

CD-ROMの使い方を間違うな

I）メモリとしては、これ以外に何か持つんでしょうか。たとえばCD-ROMのキャッシュだとかオーディオのバッファだとか。 

K）まず僕らはCD-ROMというのを、大容量で画像とか音声のデータがたくさん入るからといって、そういう用途だけでは使わないでくださいというスタンスなんです。どうしてかというと、ただでさえ遅いのに、子供たちは待ってくれない。マスクROMでゲームした世代にはそんなものは待てない。基本的には最初の立ち上げ画面で1回読んできたら終わりというのが一番よろしい使い方だと考えてます。

　よくパソコンのCD-ROMドライブにバッファ容量何Kってありますよね、バッファがあればいいように見えますが、バッファを満たすだけの時間を待たなきゃいけないという二律背反がありますから、われわれとしては、ここはもうなるべく素直にスパッと誤り訂正が解ければいいというだけのものが付いてます。

　CD-ROMはサブ・バスについているんですが、CPUはいろんなジョブをしながら。バックグラウンドのワン・タスクで、CD-ROMからデータを読めます。今までのゲーム機は、もうデータを読んできたら、そのDMAでバスが全部埋まってしまうという状況ですが、PS-Xでは本当にごく一部ですね。 

I）そういう使い方をすると2Mbytesしかメモリがないのに、一体どこにこんなたくさんのデータを置くの、あるいはコードを置くの、あるいは座標変換の中間結果を置くのという話が出てくると思うんですが。 

K）基本的にシンセサイズするから可能なんです。つまりパソコンというのはそこまでできないから、どうしてもデータを置いておく大量のメモリが必要になるわけですね。あえて置いておくならばコア・プログラム、それから圧縮されたデータ。 

I）と、中間結果ぐらいしか置けないわけですね。 

K）つまりシンセサイザと考えたときに、MIDIのシンセサイザを考えると分かりやすいですが･･･ 

I）音楽をシンセサイズする元データは非常に小さいですね。 

K）びっくりするほど小さい。

リッジレーサーが落ちない

I）ナムコさんが参入されるとなると、やっぱり「リッジレーサー」はPS-Xで動くんですかとかという単刀直入な話が出ちゃいますね。 

K）技術的に見てPS-Xで実装可能かといったら、ほとんど品質が落ちないで可能ですね。 

I）ほとんど落ちないで可能ですか。 

K）ほとんど落ちないと思います。2次元に関しても、よくPS-Xは2次元は何のかんのとうわさも流れているけど、2次元ゲームに関しても業務用からの移植が期待されます。 

I）細かい話ですが、入力装置なんですが。フライト・シミュレータなどの場合、アナログ・ジョイスティックのほうがいいんじゃないかみたいなことをよく感じるんですけれども、その辺って早い時期に何か出てくるんですか? たとえばハンドルとか。 

K）まず、アナログを制御するときにアナログ・コントローラが要るかというと、必ずしもそうじゃないんです、サイバースレッドだったら2つ欲しいとか。ストⅡだったらこれが欲しいとか、みんな1個1個違いますよね、だから3次元だからアナログという単純なものじゃなくて、ではラジコンみたいなコントローラがいいのかといったら、それじゃストⅡなんてできないでしょうという話になる。いずれにしてもコントローラというのは脱着可能ですから。 

I）その辺は公開していくという。 

K）アスキーさんのグループ会社さんでもおやりになるでしょう（笑）。ただ、1億人が慣れ親しんだコントローラをゼロで否定することはできません。とは言っても、今までのゲーム機ようなコントローラを付けるんだと能がないので、多少違うことをやりたいと思ってます。それはデザインも含めて出てきたときに楽しんでいだたきたいですね。 

I）何か3次元的な動きを拾うための工夫というのはされていると思っていていいんですか? 

K）いきなり3次元のボリュームが付いているかというわけではなくて、3次元ゲームは3次元ゲームに即したコントローラがひょっとしたらあるかもしれません。 

I）なるほど、今日はありがとうございました。

ASCII 1994.6