ゲーム制作にまつわる問題点

島国大和 @shimaguniyamato

ゲーム製作の現場において、誰のいう事を聞くかといえば、金出してる奴のいう事が絶対だ。クライアントとか。だがここで問題があって、金出してる奴は金出してる以上のリターンを求める。全部いう事聞いてたら赤字になる。

島国大和 @shimaguniyamato

自分がディレクションとかその辺に関わる時意識するのは、「OK。クライアントの意図は汲む。けど１００%は無理だ。こういう手段でいい？」というやり方。これが正しいかどうかは解らない。全部にハイハイ言っておいて何もいう事を聞かないとか、全部いう事を聞いて完成度が全部低めとか、色々ある。

島国大和 @shimaguniyamato

ちなみに、俺のやり方は、クライアントに嫌われるので、考え直し中。最近はサイフのヒモに儀ってる人と、指図をする人が別になっていて、ロジックで説明するのが無理になってきた。「兎に角やれ」「コスト的に無理です」「でもやってください」意味わかんねぇ。

島国大和 @shimaguniyamato

その２、自分からチームへの指示に関して。昔は全部紙書けばどうにかなるだろうと思ってた。無理だった。だって、紙読まないんだぜ。かなりの開発者が。

島国大和 @shimaguniyamato

かなりの企画(仕様書書く人)が経験してると思うんだけど、書いた紙は読まれない。もちろんしっかり読む人も居るけど、読まない人はマジ読まない。立派な職場ほど読む人が多く、そうでないほど、読まない人が多いが、一概には言えない。

島国大和 @shimaguniyamato

また、仕様書上ではパーフェクトに思えた仕様でも実装すると、頭を抱える場合がある。プログラマは自分がソースを書くことを考えながら仕様書を読むので、ちゃんと仕様書を読むプログラマはものすごく重宝する。

島国大和 @shimaguniyamato

実際、最近の企画の子って、プログラム的知識が圧倒的に足りないので、（俺の世代でもプログラム組める企画って少なかったけど）今の企画の子に仕様書をゴリゴリきらせるのは、かなり怖い。

島国大和 @shimaguniyamato

ちなみに、オイラも最近のハードウェアではLOD（レベルオブディティール）なんかしない方が描画は早い。ってのを食らって、もうダメだ俺の知識で仕様考えるのやめようと思った。基本的には出来るプログラマに頼らざるを得ない。

島国大和 @shimaguniyamato

そんな状況下（企画やら、ディレクターやらが、ゲームを作るのに詳しくない状況下）で、現場の指揮が出来るかつったら、出来ないだろう。権限移譲をうまくやらなきゃグズグズになる。

島国大和 @shimaguniyamato

でも、逆パターンで、最近のプログラマは、高速化や圧縮の小技を知らない人も多い。そこでは苦労してないから。あと、綺麗なソースを目指すので、面白いゲームを目指すとは別軸だったりする人もいる。

島国大和 @shimaguniyamato

ちなみに最近の絵描きは、プログラム的知識に乏しいので、パレット（クラット）や、ファイル、ディレクトリ、なんやらかんやらの知識をぶっこむのが超大変。３Ｄツールの操作に長けるが絵が下手とか、絵は上手いけど３Ｄ苦手とか、特化してて面倒な人も多い。

島国大和 @shimaguniyamato

何かというと、開発しなきゃいけないものが、驚くほど莫大になってしまって、もはや個人でコントロールできる範疇を気持ちよく超えてしまったわけで。もはやスケジュールと実装内容を見ながら、切り貼りする職人のようになってしまった。＞俺。

あきつらＢ @akitsura_b

私は公務員から転職してきたんですが、書類の読まなさっぷりには度肝を抜かれましたね。QT @shimaguniyamato かなりの企画が経験してると思うんだけど、書いた紙は読まれない。もちろんしっかり読む人も居るけど、読まない人はマジ読まない（以下略）

島国大和 @shimaguniyamato

こういう状況カでの、戦い方は成功例がいくつかあって、まず北米のように、ゲーム開発環境をツール化して、絵描きも企画もそのツールでゲームをつくる。プログラマはツールの開発とデバッグ、アップデートを主な仕事とする。というもの。ＦＰＳがおおきく発展したのはこの辺のおかげ。

島国大和 @shimaguniyamato

ツール化によって、ＦＰＳは大きく発展したけど、どれも似たようなゲームになった。（当たり前）ＦＰＳはルールが良く出来すぎ（クリックすれば画面の中央の敵にダメージ）てるから、そんなに差が出ないのは仕方がないけど。

島国大和 @shimaguniyamato

日本のゲームの特徴として、毎回エンジン新造したり、ルールを根底から創造したりするところがあるので、これはなかなかツール化が大変だ。（時間とハードスペックが解決するとは思うが）

島国大和 @shimaguniyamato

@akitsura_b あれは２重に困ってしまって、「読まれないなら書かなくていいや」になるんですよね。難しいトコロです。紙をちゃんと読まないPGやDESIは、PLANを楽にさせてるんですよね結果的に。

島国大和 @shimaguniyamato

例えばチームリーダーが何故チームリーダーかといえば、チームリーダーの地位があたえられてるからだけど、プログラマが「それは出来ない」つえば出来ない。絵描きがそれは描けないといえば描けない。本当に出来ないか、本当に描けないか、それぐらいは最低限解ってないといけない。

島国大和 @shimaguniyamato

俺自身、素人の頃は一人で１本作るのが普通だったから、トライ＆エラーのトライアルを延々やるのが普通だったので、仕様書一発で無駄作業を減らすのは大事だけど、一定以上は無理じゃないかと懐疑的。チームが全員優秀ならいけると思うんだけど。

@kazuki_kido

そんなの、TRPGじゃ20年前から常識……GMが紙に書いた設定には誰も興味がない。 RT @shimaguniyamato かなりの企画(仕様書書く人)が経験してると思うんだけど、書いた紙は読まれない。もちろんしっかり読む人も居るけど、読まない人はマジ読まない。

島国大和 @shimaguniyamato

なので、ドラッカーだのなんだの、経営書とかあのへん見ると、「今の問題には答えがある、その答えを教えてやる」という内容だったりするけど、実際は答えなんかなくてサジ加減の問題で如何に被害を抑えるかだけの問題の方が多い。最初から撤退戦。

島国大和 @shimaguniyamato

@kazuki_kido アソビなら良いですけどね。プラモ作るのに説明書読まないのは個人の問題ですが、家を建てるのに設計図読まないのは、それヤベーだろ。という。

島国大和 @shimaguniyamato

まぁそういう八方塞のなかで、重要なのは開発環境のツール化だと思ってるんだけど、これは１本作ったぐらいでは蓄積が効かない。にたようなの何本か作ってやっと本番。

@kazuki_kido

@shimaguniyamato プロのライターが雑誌に載せる記事を書くときに、です＾＾；

ゆんゆん探偵 @yunyundetective

@shimaguniyamato 仕様書がほとんど不要なくらいにコアチームが少数精鋭少人数なのが理想的なんすが、なかなかそうもいかず。