syoyoさんとのメール2

前回から半月ぐらい立ちました。俺がのろまですいませんが、第二弾です。
俺がのろのろやってるうちに、syoyo大先生はポータルの記事書いちゃいましたね。

■syoyo

> あと、アメコミ調の伸びですが、ウチの社内だと...

なるほど、デキるヤツらはちょっと違うというわけですね。
でもアメコミ調でもアニメータががんばれば対応できるようなのですね。

> > o マップをグリッドに切る
> > o LOD を用意して距離で切り替え
> >   (Continuous LOD とか今の PS2 レベルで処理できるの?)
> > o グリッドの先読み
> 
> はい。広大なマップを小さなメモリで表現する方法は、
> これしか聞いたことがありません。
> 
> (以下、脱線)
> 
> まあ、正確には、
> 
> > ギョーカイのデファクトスタンダード
> 
> は、「そんな仕様はあきらめる」です。
> マップの途中で他のゲームのようにやや間を開けて
> 読み込んでやるようにしたら、ワンダは、
> あと1年早くできたのでは!?と思ってしまいます。
> ゲーム屋としては、どちらの方がよりよい判断かは、
> 難しいですが...。

まあワンダは結構マップ移動でも狭い壁と壁の間を通る部分もあるので、
たしかに画面切り替えでもよかったのかもしれませんね。

> 
> 加えて言うと、
> 
> > o マップをグリッドに切る
> 
> 仮に、これはやったとしても、
> 
> > o LOD を用意して距離で切り替え
> 
> これを用意する前にマスターを迎えてしまいます。
> PS2だと満足のいくLODデータは手で作るしかないようです。
> どうせ、ワンダも荒く自動で生成した後は、延々と人が直したと思いますよ。

LOD はやはりそうですか。ところで、ワンダは、かなり遠くのジオメトリは、
視野の変化が小さいので、
imposter rendering みたいに、画像にしちゃって貼り付けているみたいな
感じがするのですが、そうでなくてきっちり描画しているんですかね、、、
DOF エフェクトでどうなのかよくわからないのですが...
もし描画していたとして、
そんなに PS2 でポリゴンパフォーマンスって出るもんなのでしょうか?

ところで、ワンダではモーションブラーもやっていますが、
あれってradial blur みたいに前のフレームをブレンドして、
って感じでやっていますよね。ここでは PS2 の帯域が功を奏している?

> 
> > o グリッドの先読み
> 
> これはPS2だと非常に難しいと思います。
> ワンダは偉大です。
> 仮にワンダが名馬アグロではなく、
> 超高速旅客機に乗ってマップを移動すると、
> マップの読み込みが間に合いません。
> おわかりかと思いますが、
> グリッドの先読みは、
> 
> ・メモリ容量(PS2の場合、絶望的)
> ・DISC速度(PS2の場合、絶望的)
> ・ゲーム中のカメラの最大速度(ゲーム性に依存)
> ・グリッド分割後の容量(ゲーム性とその案件の画像品質に依存)
> 
> に依存します。
> これは、ゲーム性にも影響を与える重要な問題です。

でも、PS1 というもっと絶望的な環境でも、
キングスフィールドのようにすでに
先読みによるシームレスなマップ移動があったので
(fps は絶望的でしたが...)
技術はすでに確立していたのではと思います。

平原で、遠くのジオメトリまで描画している点は、
ワンダはよくやっていると思います。

これはデザイナーが苦労したのか、プログラマーががんばったのか、
どっちなのでしょうかね。

> 特にマップの場合は、コリジョンも問題となるため、
> 普通のモデルと比べて1.2〜1.5倍程度の容量が必要です。

そうそう、コリジョンについても聞きたいです。
3D ゲームだと、どのように衝突判定をしているのでしょう?

普通に最終的にはポリゴンとの交差判定になると思うのですが、
そのポリゴンの絞込みには BSP とか作っているんですか?
それともやっぱり単純にグリッドに切っているんでしょうか?

1.2-1.5 倍というのは、コリジョン用の簡略版ジオメトリも
作っているということでしょうか?

■&o

いや〜長々とお返事書いてしまいました。恐縮です。

> そうでなくてきっちり描画しているんですかね、、、

正確なところは不明です。
でも、さすがに最大遠景はテクスチャーでごまかしている気がしますが...。
ちなみに、GT4は空の手前にある遠くの山を書き割りではなく、
ローポリで扱っていましたよ。
ワンダの場合は...不明です。

#【syoyo氏追記】
#これは以下の方法っぽい気がしてきた。
#1. 遠くのジオメトリは低い解像度で一度 offscreen に描画
#   (depth 書き込みつき。ちょっと暗く描画することで切り替り部分を fog みたくする)
#2. offsceen buffer をテクスチャとして、
#   矩形ポリゴンを描画(引き伸ばす)。depth 書き込み off
#3. 近いジオメトリを depth test & write 有効で書く。
#   (ちょうど切り替わり部分をごまかすために
#    近いジオメトリも fog を掛ける)
#
#ってやっているかな。これって PS2 の機能でできるよね。
#
#【&o追記】
#作るのは大変そうですが、可能だと思います。

> PS2 でポリゴンパフォーマンスって出るもんなのでしょうか?

出ないです。
おかげで、ワンダは、至る所で処理落ちしまくり(^^;)
近景だけでも、すでに結構ハイポリらしいですよ。
#僕には判別できません。デザイナーが言ってました。

> ここでは PS2 の帯域が功を奏している?

PS2 の限界に挑戦してますね。
詳しい手法はわかりませんが、フィルに任せてテクスチャーを何枚も重ねるだけ
で、トーンマップを実現しているあたり、さすが日本、ひいてはPS2における
HDRの先駆者ですね。

> キングスフィールドのようにすでに
> 先読みによるシームレスなマップ移動があったので
> (fps は絶望的でしたが...)
> 技術はすでに確立していたのではと思います。

あ、失礼。そいつのことは忘れてました。

#【syoyo氏追記】
#あと、マリオやゼルダとかもそうですね。

> 先読みによるシームレスなマップ移動

に限るのであれば、レースゲームは、かなり早い段階からマップのシームレス読
み込みを実現していましたね。
そういう意味だと特に新しいモノでもない!?
ただ、依然としてみんなが毛嫌いする分野ではあると思います。

> これはデザイナーが苦労したのか、プログラマーががんばったのか、
> どっちなのでしょうかね。

両方だと思います。
もう読まれたかも知れませんが、啓治郎さんの

http://www.radiumsoftware.com/?10310400

みたいに、誰もがワンダの謎にぶち当たっているようです。

> そうそう、コリジョンについても聞きたいです。
> 3D ゲームだと、どのように衝突判定をしているのでしょう?

適当ですよ〜。マップは大体コリジョンメッシュか、ハイトマップですね。
やたらと多いのはレイや線分を使った処理ですね。
如何にそれっぽくごまかすかで、各社しのぎを削っています。

> 普通に最終的にはポリゴンとの交差判定になると思うのですが、
> そのポリゴンの絞込みには BSP とか作っているんですか?
> それともやっぱり単純にグリッドに切っているんでしょうか?

よく海外製のエンジンがBSPを実装しますけど、
実際に便利に使っているという話は聞きません。
RenderWareがその例としてあがるのですが、
今は無きぶんか社チームは、それを嫌ってFPSですでに確立されていた
ポータルをダブルスティールで採用し、4年ほど前のCEDECで発表したりも
しています。
まだまだ人の手の必要な分野です。それは次世代も変わりません。
グリッドや、ポータルは、人間が調整しやすいという特徴があります。
少なくとも日本人には人気のようです。

#【syoyo氏追記】
#いやー、やっぱポータルでしょ。グリッド? ポータル(PVS)以外ありえない。
#っていうかポータル解説せんかオラオラ〜
#いやー、よくよくポータルについて調べてみましたが、やっぱポータルでしょ。
#はあぁ? グリッド? ポータル(PVS)以外ありえない(小西真奈美風に)。


> コリジョン用の簡略版ジオメトリも
> 作っているということでしょうか?

そうです。手作りが基本です。
絵素材としてのポリゴンの場合、
シャドーマップ、PRT等メッシュの分割数が高い方が有利な技術を導入する際、
ユーザーが実際にふれる場所、歩く場所を丁寧に分割します。
その際、さらに光源の位置などが想定できる場合は、当然、それに合わせた形で
メッシュを分割します。良くできたモデル、特にマップは、ポリゴンの割り方だ
けで、すでに芸術品です(同様の話でテクスチャーの密度配分という問題もあり
ますが、話が長くなるので止めておきます)。
逆に、コリジョンのようにあまり細かく割れていると処理速度や、精度上の問題
から不利になる場合があります。この場合は、ばっさり切ります。このコリジョ
ンメッシュにはいろんな情報を入れるのが最近の主流です。僕が知る限りベイグ
ラントストーリーあたりからプレイヤーに対するアンビエント色を埋め込む技術
が導入されていった模様です。
ワンダにもそういった技術が見受けられますね。おそらく、コリジョンメッシュ
とプレイヤーの位置から当たり判定を取り、ゲーム用の情報が詰まったマテリア
ル(?)を取得します。そのマテリアルには、

・プレイヤー用アンビエント(後述)
・移動できるか否か
・移動速度
・歩いたときに起きる砂埃のパーティクルID
・足音SEのID

等が想像できます。プレイヤー用アンビエントというのは、たぶん、オフライン
レンダラーの人には怒られてしまうかも知れないのですが、その色をプレイヤー
の最終シェーディング値に掛けるためのものです!何となくアンビエントと呼ぶ
人をちらほら見かけます。本来の意味とは違う気がしますが...。
ライトが固定されている環境なら、足場から、プレイヤーが光源から大体どのく
らい遮蔽されているかわかるので、暗いところは思い切ってプレイヤー全身を暗
くしてしまうわけです。逆に明るいところは、1.0に近い値を掛けます。さら
に、PS2だとアルファチャンネルに2が入れられます。これを使って、現実に
はあり得ない異常に明るい場所も作れますね。ひょっとすると、それと Bloom
/Glare を組み合わせて、ワンダはあの神々しい空間を実現している、のかもし
れません。


■syoyo

> > そうでなくてきっちり描画しているんですかね、、、
> 
> 正確なところは不明です。
> でも、さすがに最大遠景はテクスチャーでごまかしている気がしますが...。
> ちなみに、GT4は空の手前、遠くの山を書き割りではなく、
> ローポリで扱っていましたよ。
> ワンダの場合は...不明です。

これは背景をポリゴンで描画、っていう感じですよね。

> 
> > PS2 でポリゴンパフォーマンスって出るもんなのでしょうか?
> 
> 出ないです。
> おかげで、ワンダは、至る所で処理落ちしまくり(^^;)
> 近景だけでも、すでに結構ハイポリらしいですよ。
> #僕には判別できません。デザイナーが言ってました。

ですよね。テクスチャも使いまわしで、
がんばってディテールを出しているんでしょうねぇ。
 
> > ここでは PS2 の帯域が功を奏している?
> 
> PS2 の限界に挑戦してますね。
> 詳しい手法はわかりませんが、フィルに任せてテクスチャーを何枚も重ねるだけ
> で、トーンマップを実現しているあたり、さすが日本、ひいてはPS2における
> HDRの先駆者ですね。

ワンダの HDR ですが、よく見ていると、画面全体のブラーだけでなく、
それっぽいαテクスチャのジオメトリ(レンズフレアみたいな感じ)
も輝度の高い部分に描画しているっぽいですね。


> > キングスフィールドのようにすでに
> > 先読みによるシームレスなマップ移動があったので
> > (fps は絶望的でしたが...)
> > 技術はすでに確立していたのではと思います。
> 
> あ、失礼。そいつのことは忘れてました。
> 
> > 先読みによるシームレスなマップ移動
> 
> に限るのであれば、レースゲームは、かなり早い段階からマップのシームレス読
> み込みを実現していましたね。
> そういう意味だと特に新しいモノでもない!?
> ただ、依然としてみんなが毛嫌いする分野ではあると思います。
> 
> > これはデザイナーが苦労したのか、プログラマーががんばったのか、
> > どっちなのでしょうかね。
> 
> 両方だと思います。
> もう読まれたかも知れませんが、啓治郎さんの
> 
> http://www.radiumsoftware.com/?10310400
> 
> みたいに、誰もがワンダの謎にぶち当たっているようです。

これは OBB ツリーでやっていたりはしないんでしょうか?
PS2 の処理性能では無理?

> 
> > そうそう、コリジョンについても聞きたいです。
> > 3D ゲームだと、どのように衝突判定をしているのでしょう?
> 
> 適当ですよ〜。マップは大体コリジョンメッシュか、ハイトマップですね。
> やたらと多いのはレイや線分を使った処理ですね。
> 如何にそれっぽくごまかすかで、各社しのぎを削っています。
> 
> > 普通に最終的にはポリゴンとの交差判定になると思うのですが、
> > そのポリゴンの絞込みには BSP とか作っているんですか?
> > それともやっぱり単純にグリッドに切っているんでしょうか?
> 
> よく海外製のエンジンがBSPを実装しますけど、
> 実際に便利に使っているという話は聞きません。
> RenderWareがその例としてあがるのですが、
> 今は無きぶんか社チームは、それを嫌ってFPSですでに確立されていた
> ポータルをダブルスティールで採用し、4年ほど前のCEDECで発表したりも
> しています。
> まだまだ人の手の必要な分野です。それは次世代も変わりません。
> グリッドや、ポータルは、人間が調整しやすいという特徴があります。
> 少なくとも日本人には人気のようです。

なるほど、やっぱり最終的には手作業が多いんですね。

> 
> > コリジョン用の簡略版ジオメトリも
> > 作っているということでしょうか?
> 
> そうです。手作りが基本です。
> 絵素材としてのポリゴンの場合、
> シャドーマップ、PRT等メッシュの分割数が高い方が有利な技術を導入する際、
> ユーザーが実際にふれる場所、歩く場所を丁寧に分割します。
> その際、さらに光源の位置などが想定できる場合は、当然、それに合わせた形で
> メッシュを分割します。良くできたモデル、特にマップは、ポリゴンの割り方だ
> けで、すでに芸術品です(同様の話でテクスチャーの密度配分という問題もあり
> ますが、話が長くなるので止めておきます)。
> 逆に、コリジョンのようにあまり細かく割れていると処理速度や、精度上の問題
> から不利になる場合があります。この場合は、ばっさり切ります。このコリジョ
> ンメッシュにはいろんな情報を入れるのが最近の主流です。僕が知る限りベイグ
> ラントストーリーあたりからプレイヤーに対するアンビエント色を埋め込む技術
> が導入されていった模様です。
> ワンダにもそういった技術が見受けられますね。おそらく、コリジョンメッシュ
> とプレイヤーの位置から当たり判定を取り、ゲーム用の情報が詰まったマテリア
> ル(?)を取得します。そのマテリアルには、
> 
> ・プレイヤー用アンビエント(後述)
> ・移動できるか否か
> ・移動速度
> ・歩いたときに起きる砂埃のパーティクルID
> ・足音SEのID
> 
> 等が想像できます。プレイヤー用アンビエントというのは、たぶん、オフライン
> レンダラーの人には怒られてしまうかも知れないのですが、その色をプレイヤー
> の最終シェーディング値に掛けるためのものです!何となくアンビエントと呼ぶ
> 人をちらほら見かけます。本来の意味とは違う気がしますが...。
> ライトが固定されている環境なら、足場から、プレイヤーが光源から大体どのく
> らい遮蔽されているかわかるので、暗いところは思い切ってプレイヤー全身を暗
> くしてしまうわけです。逆に明るいところは、1.0に近い値を掛けます。さら
> に、PS2だとアルファチャンネルに2が入れられます。これを使って、現実に
> はあり得ない異常に明るい場所も作れますね。ひょっとすると、それと Bloom
> /Glare を組み合わせて、ワンダはあの神々しい空間を実現している、のかもし
> れません。

アンビエントは、あれですね、暗いところに移動するとキャラクタも
暗くなるってやつですね。レースゲームでも橋の下とかくぐるときに
そうなりますが、これもそのアンビエントを使っているんですね。

■&o

> これは背景をポリゴンで描画、っていう感じですよね。

御意。

> ワンダの HDR ですが、よく見ていると、画面全体のブラーだけでなく、
> それっぽいαテクスチャのジオメトリ(レンズフレアみたいな感じ)
> も輝度の高い部分に描画しているっぽいですね。

僕もそう思いました。
正確なことはわかりませんが、
輝度の高い部分に何か特殊なこと(PS2の場合、上からアルファで重ねる以外
有り得ませんが)をしていと思います。
ここがワンダ HDR の肝だと思いますが、
ここらへんの解析が、僕の中だとできていません。

> これは OBB ツリーでやっていたりはしないんでしょうか?
> PS2 の処理性能では無理?

まずは啓治郎さんのブログから引用。

> プレイヤーの動きの細やかさに脱帽。これだけ自由に変形するコリジョンに対
> して,どのようなプログラムを用意すれば破綻無く対応することができるのか,
> 想像もつかない。

啓治郎さんのブログは、
数値的安定性について述べているように読めます。
OBBツリーはコリジョン処理に高速さを与えてくれるとは思いますが、
数値的安定性については何も手助けはしてくれない気がするのですが、
間違ってます?

ほんでもって、OBB ツリーですが、PS2でも可能だと思いますよ。
結局実装の手間が追いつかないんだと思います。
ただ、ワンダにおける巨像のように動的に変形するコリジョンに対しては、ツリー
を再構成する手間が少々面倒です。メモリに対して、動的に確保・解放を繰り返
す必要がありますので、8時間ぐらい戦闘しっぱなしだとえらいことになりそう
な予感!!!

> なるほど、やっぱり最終的には手作業が多いんですね。

その流れをいい加減変えないと次世代は生き残れないのでは〜?
果たしてどこまで自動化が図られるのでしょうね?

> アンビエントは、あれですね、暗いところに移動するとキャラクタも
> 暗くなるってやつですね。レースゲームでも橋の下とかくぐるときに
> そうなりますが、これもそのアンビエントを使っているんですね。

御意。

syoyoさんとのメール1

syoyo大先生からメールが届きました。ゲーム業界の常識?みたいなものを返信してみました。間違った返事をしているかも知れないんですが、こういった情報ってWeb上に無いと思うので、載せたいと思います。
とりあえず、4通ぐらいを「大人の事情を考慮」して載せます。
(syoyoさんの了承は得ました。)

※以後PS2の話ばかりをしますが、僕はPS2でのプログラマー経験は少ない(1週間のみ)ため伝聞情報です。間違っている可能性が多分にあります。ご容赦ください。

    • -

■syoyo 大先生からのありがたいメール

いまさらですが、SBR 幹事ありがとうございました。
良い感じのお店でしたので、これからもちょくちょく利用させていただこうかと思います。
 ところで、ポリゴンモデルのキャラクタアニメーションの手法でいいのってありますか?
ふつーにボーン(パーツごとに行列)変換が主流なのでしょうか?
ただふつーのボーンだと、よくあるように、ひじとかの変形がおかしくなりますよね。
(それとも頂点ウェイトをつければだいたい解決するのでしょうか)
なるべく 3ds max とかでアニメーション付けできて、collada で出力できて、頂点シェーダで計算できるようなのを希望しています。
それかなんかキャラクタアニメーション手法でこれは読んどけみたいな書籍とかあったらそっちがんばって読むんで、あればぜひ教えてください。


■不肖 &o の全力回答

> ふつーにボーン(パーツごとに行列)変換が主流なのでしょうか?

はい。
みんな、結局は、それで、ウェイトをがんばってつけて、
カメラでおかしいところがばれないように試行錯誤するのが、
「デファクトスタンダード」です。

一応、
回転しかないのであれば、ご存じかと思いますが、
クォータニオンボーンが知られています。

Game Programming Gems 4の5.12 Hardware Skinning with Quaternions
が、参考文献となります。

http://cyberloonies.com/gameprogramminggems.html

■syoyo 大先生からのありがたいメール

なるほど、やはりそうなのですか...

ただ、キングダムハーツとかのアメコミ調のモーションだと、
スキニングというか、ひじひざなどはうまく引きのばしとか
やっているっぽい気がするんですが、そう見えるだけで
そんなことはないのかな?

そうそう、ワンダちょっとやりました。

空間とかの出来がよいですね。
安藤さんもオンラインゲーで広大なマップ処理とかやっていると
思いますが、ああいうのって

o マップをグリッドに切る
o LOD を用意して距離で切り替え
  (Continuous LOD とか今の PS2 レベルで処理できるの?)
o グリッドの先読み

で処理するのがギョーカイのデファクトスタンダード
なのでしょうか?それともほかの手法が使われていたりしますか?


■不肖 &o の全力回答

(ここから僕の暴走が始まったというか、めちゃくちゃ長い返事を書くようになってしまいました。)

> ただ、キングダムハーツとかのアメコミ調のモーションだと、
> スキニングというか、ひじひざなどはうまく引きのばしとか
> やっているっぽい気がするんですが、そう見えるだけで
> そんなことはないのかな?

(諸事情により、ここにあった段落を削除)

アメコミ調の伸びですが、ウチの社内だと、
クォータニオンスキンに拡縮に対応させるための機能拡張を行えば、
モーションを作る人の創意工夫で何とかなっていますよ。

> そうそう、ワンダちょっとやりました。

僕は今日クリアーしました。

> o マップをグリッドに切る
> o LOD を用意して距離で切り替え
>   (Continuous LOD とか今の PS2 レベルで処理できるの?)
> o グリッドの先読み

はい。広大なマップを小さなメモリで表現する方法は、
これしか聞いたことがありません。

(以下、脱線)

まあ、正確には、

> ギョーカイのデファクトスタンダード

は、「そんな仕様はあきらめる」です。
マップの途中で他のゲームのようにやや間を開けて
読み込んでやるようにしたら、ワンダは、
あと1年早くできたのでは!?と思ってしまいます。
ゲーム屋としては、どちらの方がよりよい判断かは、
難しいですが...。

加えて言うと、

> o マップをグリッドに切る

仮に、これはやったとしても、

> o LOD を用意して距離で切り替え

これを用意する前にマスターを迎えてしまいます。
PS2だと満足のいくLODデータは手で作るしかないようです。
どうせ、ワンダも荒く自動で生成した後は、延々と人が直したと思いますよ。

> o グリッドの先読み

これはPS2だと非常に難しいと思います。
ワンダは偉大です。
仮にワンダが名馬アグロではなく、
超高速旅客機に乗ってマップを移動すると、
マップの読み込みが間に合いません。
おわかりかと思いますが、
グリッドの先読みは、

・メモリ容量(PS2の場合、絶望的)
・DISC速度(PS2の場合、絶望的)
・ゲーム中のカメラの最大速度(ゲーム性に依存)
・グリッド分割後の容量(ゲーム性とその案件の画像品質に依存)

に依存します。
これは、ゲーム性にも影響を与える重要な問題です。
特にマップの場合は、コリジョンも問題となるため、
普通のモデルと比べて1.2〜1.5倍程度の容量が必要です。
やはり、

・ゲーム性
 ・カメラ移動速度
 ・必要なコリジョン精度
・モデル制作のコスト
・マップの画質
・ツールチェーンを含むシステム構築にかかるコスト
・場合によってはランタイムプログラム自体のサイズ

の総合的なバランスから、ゲームに特化した形で、
実装されています。
どろくさ〜い世界です。

長々と失礼しました。

(続きは次回の更新で)

戦神

http://www.genki.co.jp/games/ikusagami/

ゲームショウで会社のみんなを総動員して体験版を確保しまくりました。
かねてから業界関係者の間では話題となっており、僕も情報収集に余念がありませんでしたが、「60000どころか10000もでない」と思っていました。
行っておくけど、これ最高。みんな買うべし!本当に65000体でてる。いや、稲葉物置みたいに数えた訳じゃないけど、あれは...。無双系ゲームが乱立する昨今、ぬきんでた一作。あの割り切り方、最高です。ステージはすり鉢状でぺんぺん草一本生えていません。ただただ敵がいるだけです。たとえると、こんな感じ↓

http://images.google.com/imgres?imgurl=http://www.ne.jp/asahi/toshiya/cult/naushika.jpg&imgrefurl=http://www.ne.jp/asahi/toshiya/cult/lego36.htm&h=480&w=640&sz=23&tbnid=Erx5sjDKYsYJ:&tbnh=101&tbnw=135&hl=ja&start=2&prev=/images%3Fq%3D%25E9%25A2%25A8%25E3%2581%25AE%25E8%25B0%25B7%25E3%2581%25AE%25E3%2583%258A%25E3%2582%25A6%25E3%2582%25B7%25E3%2582%25AB%2B%25E9%2587%2591%25E8%2589%25B2%26svnum%3D50%26hl%3Dja%26lr%3Dlang_ja

オウムが金色の絨毯を作ったように、敵が白い絨毯を作っています。
もう、シリーズ化して欲しいね。敵は1ステージあたり1種類だけでいいです。マップは1つしかなくて、ボスもいりません。それでも、1万円までなら「僕は」買います。

...さて、ゲームプログラマーとしての一言ですが、「とにかく敵を出す!」という筋がチーム全体に行き渡っていた、さらに言えば会社全体に行き渡っていたからこそ、このようなおもいきったモノになったのだと思います。何か言うとその逆の意見が社内、社外から吹き出すという場面がゲーム開発現場ではよく見受けられますが、ここまでの割り切りをしてよいのだ、できるのだという「戦神という名の証明」は、なぜだか僕を勇気づけてくれました。
それに、これは任天堂のRevolutionの話にも共通するのですが、「敷居が低い」、「キーワードがわかりやすい」というのはゲーム人口拡大へ向けての基本事項だと思います。また、数が出るだけで大喜びすると思われるマニア層にも訴える力があると僕は感じました。

http://www.irwebcasting.com/050916/02/eec05e89e7/index.html

ゲームに詳しくない友達を呼んで、ちょっと暇だから「ゲームやるか〜」と誘ったときに、いちいち操作方法を説明するのは面倒です。たぶん1分以内で説明できないと、場がしらけますよね。これなら「■連射して!」で、終わり。後は順次「R1押して」とか、「L1がカメラ」とか、「三角を押すと〜」みたいなことを小出しに行っていけば、かなり盛り上がれると思います。
こういった特徴はDSにも共通しますね。おそらくRevolutionでもそれを目指すのでしょう。楽しみです。あれれ、いつの間にかRevolutionの話をしてる...。

#だって、このゲーム片手でゲームリモコンで遊んだら、最高ですよ。絶対。

COLLADAできた

COLLADA&Cg

う〜、いっぱいライブラリ使ってるので、コンパイル準備に時間がかかった。疲れたけど、何とかビルド成功。なんか、モデルが出たよ。

なんか、以下のように、XMLの中にCgコードが入ってた。

   <code semantic="VERTEX_PROGRAM" profile="CgVP20 CgVP30" lang="Cg">
struct VertexInputs
{
 float4 Position	: POSITION;
 float3 Normal		: NORMAL;
 float2 Texcoords0	: TEXCOORD0;
};


struct InterpolatedValues
{
 float2	TextureCoords0		: TEXCOORD0;
 float3 Position		: TEXCOORD2;
 float3	Normal			: TEXCOORD3;

 float3 PointToLight0		: TEXCOORD4;
};



float4 VertexToFragment(in VertexInputs IN,
            out InterpolatedValues OUT,
            uniform float3 LightPosition0,
            uniform float4x4 ModelViewProjMatrix) : POSITION
{
 float3 LPosition = IN.Position.xyz;

 OUT.TextureCoords0 = IN.Texcoords0;
 OUT.Position = IN.Position;
 OUT.Normal = IN.Normal;

 OUT.PointToLight0 = normalize(LightPosition0 - LPosition);

 return mul(ModelViewProjMatrix, IN.Position);
}

  </code>