167(1): 名前は開発中のものです。 [sage] 02/09/04 00:43 ID:??? AAS
>>166
　マジレスすると、ライトマップ。呼び方は社によって違うかも知れ
ないけど単に陰影をテクスチャに落としてマルチテクスチャで張るだけ。
特別な事でもなんでもないね。

177(1): 名前は開発中のものです。 [sage] 02/09/04 02:33 ID:??? AAS
頂点カラーでパースが付かないハードでも
マルチテクスチャなら付いたりする不思議。

285(1): 142 [] 02/09/08 22:45 ID:zlWfT7z1(4/6) AAS
敵の動きの仕様が適当なのは、プランナーの能力がないというより
実際に動かしてみなければわからない部分が多すぎるから。
そもそもゲーム開発とはそういう予測が不可能なものであり、
トライ＆エラー（試行錯誤）の回数が多ければ多いほど良いものができるのである。
従来の開発プロセスでは、
実際に動かして、パラメータを調整して、また動かして
というＴ＆Ｅのプロセスの多くはプログラマにしか許されていなかった。
そのため「ゲームのおもしろさはプログラマで決まる」と言われてきたのだろう。

我々が目指すべきなのは、
プランナが指示をだしデザイナがデータを作りプラグラマが試行錯誤する。
ではなく、
プランナ、デザイナ、プログラマがそれぞれに試行錯誤を繰り返すことである。
そしてＴ＆Ｅの間隔を短くし、それを円滑に統合するのが汎用化されたオーサリングツールなのである。

従来の開発プロセスでプログラマに負荷が集中するのは当然で、
またそうした環境に慣れたプログラマがプログラマ至上主義になるのもまた当然である。
しかし大規模化し高度化する昨今のゲーム開発において従来の方法が限界に来ているのもまた事実である。