Nao_uの日記 このページをアンテナに追加 RSSフィード

2008-06-24

[][]「作った人だけが面白いゲーム」問題 「作った人だけが面白いゲーム」問題 - Nao_uの日記 を含むブックマーク はてなブックマーク - 「作った人だけが面白いゲーム」問題 - Nao_uの日記 「作った人だけが面白いゲーム」問題 - Nao_uの日記 のブックマークコメント

個人で作ったゲームでも商用で作られたゲームであっても、作った人やルールを理解できた人には楽しめるんだけど、そうでない人が遊ぶと「よくわからなくて面白くない」という感想になってしまうゲームは多い。たとえ誰かには「面白い」と感じられるゲームであっても、ルールが複雑になればなるほど、そのルールを理解して楽しめる人は減っていく。



以前に作った「ライフゲームアクション(仮)」も、少なくとも作っている間の自分はきっと面白いものになるはず、と思いながら作ってたはずなんだけど、いま改めて遊びなおしてみるといろいろと問題点が目に付く。


とりあえずライフゲームを知らない人にはよくわからないという根本的な問題はさておいて、画面に色違いのゲージがやたらと多くてわかりにくく、SEやエフェクトなどで何が起こったのかを説明しようとはしているのだけど今ひとつ伝わりづらい感じで、定期的に画面下に出てくる数値などはかなり意味不明。

ライフゲームをアクションゲーム化する際に単純に赤ブロックを破壊するだけではつまらないだろうと考えて、黄色ブロックと赤ブロックの干渉を軸にゲームを組み立てようとした結果、むやみに複雑なルールになってしまったのが失敗の原因か。

それなりにスコアアタックができる形にはしてあるものの、もともとのルールの意図した形で遊んでもらうことは難しそうだし、単純なアクションゲームのはずなのに画面外に表示されるよくわからない数字を見ないと理解できないようなルールはやっぱり間違ってるような気がする。*1



おそらくこのゲームを触った人の大半は、ルールがどうなってるのかを理解する前にやめてしまうんじゃないかと思う。*2

この手の問題を改善していくためには、直接遊んでくれているところを後ろからこっそり眺めつつ、プレイ後にどこの部分をどのように感じたのかを丹念に聞き取って反映していくのが一番いい方法なんだろうと思う。実際、そうすることで得られるものはすごく多いはず。



ゲームを作っているうちに独りよがりになってきて、なにが良くて何が悪いのか、だんだん感覚が麻痺してきてわからなくなってくることは多い。

会社で誰かが買ってきたゲームを遊んでいるときに、なにかゲームとしてマズい要素を見つけたときにはみんなすぐに気づいて「これはひどい」などと批評しあうのに、なぜか自分たちの作ってるゲームになると一転して、その批評眼が全くといっていいほど発揮されずにおかしな仕様のものを何の疑問も持たずに作りつづけてしまうことはよくある。自分が作ってる途中のものを客観的に見るのは本当に難しい。自戒を込めて。




本来はこういうのはある程度形になった段階で何人かの人に遊んでもらいながら、制作時に想定されていなかった問題やわかりにくいところの修正などを繰り返して少しづつ調整していくのがいいやり方なんだろうけど、今回はWeb上に置いたFlashのゲームだったこともあって、このゲームをどのくらいの人が、どんな風に遊んでくれたのかは想像するしかない状態だった。

できることなら裏でこっそりとリプレイを記録する仕組みを仕込んでおいたりして、どんな動きでプレイしたのか、とか、どのくらい遊んだら飽きるのか、とかをじっくり眺めてみていろいろ改善していきたかったところだけど、この時には思いついたネタをとりあえず実装するのに手一杯で、そこまでは手が回っていない。


どんなやり方を取るにせよ、誰もが楽しめるわかりやすくて面白いゲームを作るためにはこのような経験や思考・分析を蓄積していく事が大切なんではないかとは思ってるのだけど、たとえ仕事でゲームを作っていたとしてもそういった機会を作るのはなかなかに手間がかかるし、その結果をどう解釈してどのように反映していくのか、という事を考えていくのもまた難しい問題だったりする。

どうするのがベストなのか、という結論が簡単に出るようなものでもないだろうから、とりあえずは手を動かしながらいろいろ考え続けていくしかない類の話なのかもしれない。

*1:ちなみに自己ベストは確かLV40くらいで約15万点だったような。今遊ぶとボーナス点の点数バランスとかも今ひとつ調整不足かも。

*2:じゃあルールを理解できれば面白いゲームになってるのか?という疑問はひとまず置いといて・・・。ルール以外にも問題点は多いし。遊んでみたくなるようにするための工夫とか?

バグバグ2008/06/25 15:18結構面白いね。こういうシンプルなの好きですわ♪(^-^)
私は基本的に自作のFlyingFlyみたいなストイック&点稼ぎ系が好きなんよね。

Nao_uNao_u2008/06/27 01:08僕もMSX-FANに掲載されていた1画面プログラム部門のゲームなどで遊んでた記憶が原体験にあるせいか、FlyingFlyみたいなシンプルなゲームはけっこう好きです。まだBASICもよくわからないころに、1時間くらいかけてプログラムを入力して30分くらい遊ぶ、みたいな感じで遊んでたような。面倒ではありましたが、あれはあれで楽しかったです。

なめなめ2009/10/24 21:46プレイヤーが段階的にルールを学べるチュートリアル要素と
達成感(爽快感)を得られる仕組みで化けそうですね^^

Nao_uNao_u2009/11/01 21:36遊びながら試行錯誤しているうちに自然にルールが飲み込めてくる、というふうな工夫は必要ですよね。
こういう一発ネタ的なゲームでは特に、何をすべきなのかをはっきりさせることと、その行動が狙い通りに上手くいったときの見返りをわかりやすく設定する、ということに関しては特に注意して考えないといけなそうです。

トラックバック - http://game.g.hatena.ne.jp/Nao_u/20080624

2008-06-23

[][]文字が小さくて読めない問題 文字が小さくて読めない問題 - Nao_uの日記 を含むブックマーク はてなブックマーク - 文字が小さくて読めない問題 - Nao_uの日記 文字が小さくて読めない問題 - Nao_uの日記 のブックマークコメント

lastline 2008/06/22 13:01

文字ちっさいは同感。僕は21型ブラウン管ですが。というか、本編のソリッドアイの情報も全然読み取れません。文字サイズ調整欲しい

ゲーム開発者は30インチ近い高解像度のテレビを机の上に置いて、数十cm~1m前後という家庭ではほとんどありえないくらいの近距離で作業していることも多いためか、特にその辺の感覚が狂いやすい傾向がありそう。


今は過渡期でもあるので、高解像度が出せるゲーム機でもみんながHDのテレビで遊んでいるわけではなく、lastlineさんのようなSDの環境で遊んでいる人のこともある程度は考慮しておかないといけないのが、さらに問題をややこしくしている。

「文字が小さすぎて見えない」とか「せっかくの高解像度なのに大きすぎる文字で表示されてデザイン的に変」などと相反する指摘を受けたり、現実的な話としては全ての文字に大きさ調整を入れることがコスト的・ゲームデザイン的に難しいこともあったりして、それぞれ苦労しているはず。とりあえず現状では、まずは視認性を優先すべきなんじゃないか、とは思うけど。



また、ゲーム内の情報も企画書や広告などと同じで、情報量が多いうえに文字が小さすぎて読みにくいようなものは、全ての情報を網羅して見てみようという気が削がれやすくなるだろうから、注意が必要なのかも。

トラックバック - http://game.g.hatena.ne.jp/Nao_u/20080623

2008-06-22

[][]マヌケの谷 マヌケの谷 - Nao_uの日記 を含むブックマーク はてなブックマーク - マヌケの谷 - Nao_uの日記 マヌケの谷 - Nao_uの日記 のブックマークコメント

E3 06:Sprinter Cell バックステージパス

いい具合のド画面などありつつ、このジャンルのゲームでは、不気味の谷っていうよりは、現実とゲームルールの違いによるマヌケの谷が結構深いよなという気も。まあ気にしないんだけど。

ずいぶん前に見かけて印象に残ってた単語「マヌケの谷」。


リアルさとゲームルールが相反するところに関してはあまり気にしすぎると何も作れなくなってしまうけれど、人間の挙動がからむ部分に関してはこれだけ絵が綺麗になるとさすがに無視しがたい場面も。これも難しい問題。

GTAとかはこのへんもものすごくうまいバランスで処理しているように思う。


トラックバック - http://game.g.hatena.ne.jp/Nao_u/20080622

2007-01-05

[][]スーパーマリオ・コンプレックス スーパーマリオ・コンプレックス  - Nao_uの日記 を含むブックマーク はてなブックマーク - スーパーマリオ・コンプレックス  - Nao_uの日記 スーパーマリオ・コンプレックス  - Nao_uの日記 のブックマークコメント

大昔に自分も同じように考えて、習作としてスーパーマリオの動きの完全再現を目指してGBAの実機で動くプログラムを組んでいたことがある。Javaで書かれたブラウザ上で実行できるエミュレータでそのときに作ったものが動くので、サーバに上げてみた。


f:id:Nao_u:20070106123615j:image


なにかとマズそうなのでキャラは適当なものに差し替えてあるが、一応オリジナルの挙動をコマ送りで解析しながらドット単位でほぼ同じように動くように作ったつもり。(一部完全でない部分も残ってるけど)

自作のステージでスーパーマリオを遊ぶのが子供の頃からの夢だったのだけど、ジャンプの挙動を作ったところまでで満足して、中途半端なまま放置してしまっていた。


スーパーマリオの内部処理はジャンプの挙動に限らず、加速・急制動時の挙動や、ジャンプ中に頭の一部をブロックに引っ掛けたときの補正・キノコを取って大きくなったときに頭がブロックにめり込んでいるときの処理なども面白い。


また、Bボタンで発射するファイアーボールのバウンドの高さが、ノコノコにはほぼ確実に当たるのにクリボーは背の高さの都合でタイミング次第で飛び越えてしまってすり抜けることがあるように調整されていたりするのも興味深い。これだけで、平地をファイアーボールを撃ちながら走り抜ける時にも単調な展開になりにくい。

最近のゲームから見れば少ない要素の組み合わせだけで作られているにもかかわらず、難度をさほど上げないようにしながらも予測を超える多彩な展開が起こりやすいようにいろいろと計算されているのが素晴らしい。


個人的には、普通に遊んでも十分面白いのだけど、何より「最高速でステージを駆け抜けるときに最も気持ちよく感じられるように」デザインされている点が、このゲームが奥が深くて飽きが来にくい一番の理由だと思っている。

k_uk_u2007/01/07 03:16空中でのx軸加速はパックランドやフリッキーに入っていたと記憶しとりますが、こちらについては、プログラミングの過程で自然発生する可能性も結構あるかもしれませんですね。x軸周りの処理を接地状況によって分ける前に遊んでみたら、面白かったのでそのまま採用…とか。

Nao_uNao_u2007/01/07 11:25アーケードには詳しくないのでパックランドは失念していました。ものすごくクセのある操作でしたが、確かに空中制動できていたような。大ジャンプすると制御不能なくらいに加速できていたような印象があります。

フリッキーの方はプレイしたことがなかったので、G-CLUSTER経由で遊んでみました。
http://game.goo.ne.jp/ondemand/mSEG/p1.html
ガンスタースーパーヒーローズのヒヨコ面の元ネタはこれでしたか・・・。同時期のゲームをあまり知らないのでよくわからないですが、もしかしたら主人公が鳥であることは、このゲームに空中での加速を取り入れることになった理由の一つだったりするのかもしれませんね。

プログラミング自体は空中の処理を場合分けしないほうがむしろ簡単なので、確かにx軸加速が自然発生する可能性はかなり高そうです。この時期のファミコン以外のゲームに関してはほとんど知識がないですが、時系列で操作系の発展をまとめてみると面白いかもしれないですね。

naoya2knaoya2k2007/01/08 01:37実はパックランドの後にメトロクロスがあってその後にスーパーマリオがあるのですが、空中で微調整してクリボーを踏むマリオの操作感はむしろメトロクロスの缶踏みに似ているのではないかと思いました。
あと、ジャンプ中でも地上と同じように左右に動けるゲームとしてボンジャックがあります。

Nao_uNao_u2007/01/09 00:39久々にパックランドをプレイしてみたら、左右移動が十字キーでなくABボタンでの操作になっていて戸惑いました。クセのある操作感だった印象があるのはそのせいだったようです。
メトロクロスも同様に、なんだか難しくてうまく遊べなかった印象だけが残っていますが、また機会を見てもう一度プレイしてみたいです。

自分はあの当時にはファミコンしか知らなかったため、メトロクロスもスーパーマリオ以降のゲームだと認識していました。ただ、発売日を見るとかなり近い時期であるため、開発自体はほぼ同時期に行われていたように思われます。もしかしたら、ボンジャックも含めて進化の過程で同時多発的に似たタイプのゲームが作られてきたのかもしれませんね。

トラックバック - http://game.g.hatena.ne.jp/Nao_u/20070105

2006-07-07

[][][]Half-Life2の作られ方 Half-Life2の作られ方 - Nao_uの日記 を含むブックマーク はてなブックマーク - Half-Life2の作られ方 - Nao_uの日記 Half-Life2の作られ方 - Nao_uの日記 のブックマークコメント

初代からのコアなファンには、HL2は案外評判が良くない。

中でもよく言われるのが、ゲーム全体の流れの悪さ。チャプターごとに違うチームが作ったせいか、レベルデザインの品質のバラつきも指摘されている

Half-Life2が前作に比べて面白く感じなかったのは自分だけではなかったようで、ちょっと安心。品質のばらつきもさることながら、寄せ集め的な内容のちぐはぐさも気になるところではあった。また、全体にレベルは高いんだけど、とても大切な「何か」が足りてない、というような感触も。


プロセスは以下のようなものである。まず約15分のゲームプレイ体験を荒く製作する。そしてプレイテストを行う。その結果から来週の優先課題を決める。プレイテストを見ていてつらい気持ちがしなくなる、つまり完成するまで製作とプレイテストを繰り返す。

きっと、『プレイテストを見ていてつらい気持ちがしなくなる = 完成』というような考え方が、Half-life2のまずかった点の一つのではないだろうか。

これはスタートラインというか少なくともそうあるべき、という最低限の基準であって、この条件を満たしたから面白いものになったはずだ、と考えるのは何かが間違っているような気がする。また、匙加減は難しいものの、全ての点において不満点をなくすことが必ずしも全体のクオリティアップにはつながるとは限らない、というような場合もあったりするはず。


目立つ不満点がなくなるところまで作りこめたところで、今あるものには何が足りないのか、そこに何を足せば求めていた面白さが得られるのか、それとも本質的に何かが間違っているのか、などを考え、その解決策を実行に移していくには、また違った思考パターンや能力が必要となる。しかし、たとえその一つ上の基準を満たして何らかの意味で「面白い」ものが完成したとしても、それが「売れる」ものになるためにはさらにまだ何かが足りないということも往々にしてあったりもするし、さらにはもっともっとそれ以前の段階に問題があって・・・、などと考え始めるとどんどん話がそれるので、Half-life2の製作工程から思ったことに話題を絞って続けてみる。



このプロセスを巨大プロジェクトで実行するためにValveでは従業員をCabalというチームに分け、それぞれのチャプターなどを並列して開発作業を行った。

プロトタイピングチームが作ったデザイン原則、ストーリー、設定などのデザイン制約を基に、個々のチャプターのチームが作業を行った。武器、NPCなどチャプターに共通な部分に関してはその専門のCabalが担当した。

こうして全体が遊べるアルファまで開発したところで、全体の質を評価する監視Cabalが作られた。プレイアブルにならないと全体のペース、難易度カーブ、多様性、一貫性を評価することはできない。

だがこのゲームには前作に及ばない点がいくつも存在する。一つはゲーム全体の流れの悪さである。冗長な章がいくつかあり、似たような展開が長々と続くのにはウンザリさせられてしまう。代表的なのがバギーを操る章だろう。延々とバギーを操って川を進みながら障害物を排除していくという展開でありもっと短く削ってもよかったはずだ。その他にも後半、仲間を引き連れて延々と突撃を繰り返す章が冗長と言える。流れの悪さと言えば全体的にチグハグで、章ごとにコンセプトがバラバラなのが変な感じである。バギーをひたすら運転したと思ったら、次にエイリアンを味方につけて延々と突撃させながら進んだり、ゲームの雰囲気の変化が激しい。そのため統一感というものが感じられない。また移動と謎解きが常に一定のテンポで繰り返されるのが気持ち悪い。内容以上に単調に感じる。

個別のチームがバラバラに各パートを作っているのも、ゲームの盛り上がりの緩急や、統一されたつながりの感覚があまりうまくいっていない理由の一つなのかもしれない。たとえあとで全体の流れの管理のためのCabalを作ったとしても、ボトムアップで作られたものを繋ぎ合わせる、というプロセスそのものが本質的にこのような問題を生み出す原因を孕んでいるように思える。

クオリティの高いものをたくさん繋ぎ合わるだけで、自然に良いものができるわけではない。いかに上等な食材を使ったコース料理でも、順序や量も考えずにげっぷが出るまで詰め込まれるような状態では楽しい食事になるはずはないし、いくら個々の料理人の腕が良くても、その中に少なくとも一人はコース全体の流れを意思と意図を持って構築できるような才能を持ったシェフがいなければ、食べてくれる人のために皿の一つ一つの量や順序にまで気を配ったもてなしの心を込めた料理を作ることは難しいだろう。そういった配慮を怠ると、一つ間違えばコース料理ではなく、ただの品のない豪華食材の寄せ集めになってしまう危険もあるかもしれない。


でもまぁ、このようなチームの運営方針なら、上記のような問題を認識したなら次回にはそれを改善するためのより良い制作フローを構築し、完成後にまた同じように発表してみんなで情報を共有しながらさらに効率の良い作り方を求めていこうとするのかも。

開発プロセスなんてものは生モノなのでこれが公開されたことが直接どう役に立っていくのかはわからないけれど、とりえずこのやり方で膨大な期間をかけてもあまり面白いゲームに仕上がらなかったという例が一つあった、ということは記憶に留めておくといいのかもしれない。



最後の別の場所からもうひとつ引用。

しかし,そういった理屈だけから導き出された答えは作り手の自我に欠けており,まるで魂が抜け落ちてしまったような面白味の無い代物になってしまう。創造とは本来,人間の自由意志 [skepdic] によって為されるべきものではないだろうか? 理屈とは創造を補助するための術であって,それ自体が何かを生み出すものとは違うのではなかろうか? 論理的な導出とは,知識と判断力さえあれば誰にでもできる,最も単純な「やりかた」であることを忘れてはならない。ある作品を他の作品とは異なる唯一無二の存在たらしめるのは,作り手の自我の力に他ならないと信じている。

理屈からの演繹だけでは成し得ない境地がある、と。


上記引用とは直接関係ないけど、『アニメがお仕事!』は絵柄があまり好みでなかったので購入対象にしていなかったのだけど、次に見かけたら買ってみることにしてみようと思う。

ひげたまひげたま2006/07/08 23:56分業化しないと規模の大きいものは作れない(かも知れない)、分業化すると統一感があるものを作り出すのは難しくなる(かも知れない)。今の大規模ゲーム開発の問題そのままですね。読んでいて身につまされました。やや辛い気持ちです。分業化してパラレルで出来上がったモノを、最後に一旦壊してシリアルに再構築する時間があればかなり違うのでしょうが、分業自体が元々開発期間を圧縮する手法でもあるので難しいところです。
…と思いつくまま書きましたが、自己紹介を兼ねて自分のblogのリンクおいて置きます。よかったらお暇な時にでもどうぞ。
http://blog.so-net.ne.jp/higetama/

Nao_uNao_u2006/07/11 00:23はじめまして。分業に伴う問題は根が深いですよね。結局作るべき内容やリーダーの資質・求める方向性やチームの構成によって、その場その場でどうすべきかの対処を考えていくしかないでしょうか。作るゲームによっても並列化しやすいモノとそうでないものがあるでしょうし。

トラックバック - http://game.g.hatena.ne.jp/Nao_u/20060707

2006-04-23

[][][]ゲーム制作の才能 ゲーム制作の才能 - Nao_uの日記 を含むブックマーク はてなブックマーク - ゲーム制作の才能 - Nao_uの日記 ゲーム制作の才能 - Nao_uの日記 のブックマークコメント

ゲーム制作のつらいところは(というか全ての仕事はそうですが)仕事を覚えると、それを応用する前に次に覚えなければならない事がすぐにやってくることです。仕方ないんですけどね。でも「もっと才能があったら楽かもなぁ」と思う時もあります。もっと才能があればもっと早くでき上がって、もっと寝れて...もっと酒を飲む時間もあって...あぁ...。

と言う訳で、今回は「ゲームの制作の才能」についてのお話です。

例えば仕事でトラブルが起きた時に(技術面も感覚的な面も)これを続けるか?あきらめるか?一部の仕様変更か?どんな変更か?等の選択をする時も「トラブルのミソ」をこれらのポイントから割り出して解決することになります。

 そしてこのポイントに対して一人ひとりの認識が浅いと制作のテンポは遅くなり、制作に時間がかかってしまう割に成果は出ず、おまけに沢山の落とし穴を自ら生み出すことにつながってしまいます。そして、面白くないまま...

 あ、あともう一つ言いたいのが、せっかく「状況把握の能力」と「先見性」がありながら、それ止まりで終わってしまっているもったいないケースもあったりします。簡単に言うと、せっかく問題に気づいてるのに、その場で解決しないで先送りにしてしまうケース。これは甘く見ない方が良いです。

 例えば「ココのところイマイチなんだけど、どうかなぁ」なんて言う時に「まぁ作りながら何とかしようか...」なんて言いながら進めてしまう時って確かにあるんですが、実際、本当にちゃんと「作りながら何とかなった」ためしなんて、まず無いです。大抵は後々になってから、その小さな後回しが大きな壁となってしまう事がほとんど。「いや、俺はあんまり無いなぁ」と言う人がいたら、それは本当に後回しにしても良いことだけを後回しにしたからか、問題だったことをそのまま忘れてしまっているか、どちらかだと思います。

「問題を先送りにしない」ということに関しては少し前のファミ通の桜井氏のコラムでも同様のことを言っていたような気がする。それだけゲーム制作の意思決定においては重要なことなんだろう。基本的に、あとで困るだけなので問題を先送りにして得になることなどまずありえない、と思っていたほうが良さそうな。




でもこうやって偉そうに言っている俺も、その手の失敗は大きなものから小さなものまで、死ぬほど沢山経験してきました。今思い返しても大反省です。でも俺はこの手の失敗事って忘れません。ほとんど覚えています。

 やっぱり悔しいからでしょうね。

 自分のうかつさや、能力の低い部分をまともに感じる部分ですからね。でもそれ自体が大切な財産です。

でもね、特に若い人に言いたいんですが、若いうちは自分がモノ作りに対して「確信犯」になることを目指して欲しい。

 今回はモノを作るため才能と呼べる検証方法を紹介したんですが、それらを十分に検討したなら、最終的には「俺はこういう意図でやったんだ」と言い切って作って欲しい。

 でないと失敗が「失敗の価値」を持たなくなる。つまり、悪い結果が出ても悔しくない。

 そして良い結果に対しても嬉しさのテンションも低くなります。それはもったいない!

 もちろん失敗をして欲しくはないけど、悪いと悔しい。良かったら思いっきり喜べる。と常に感じられるようでいて欲しいです。これは肝心な所です。

終わってみてから前回の仕事を落ち着いて振り返ってみると、結果としての読み違いや判断ミス、もっと違う手段で解決すべきだった問題など、反省すべき点が山のようにあったことが思い起こされる。

冷静に考えてみれば誰でも簡単に気づくような大きな問題が開発の流れの中では目に付かずに放置されてしまっていたり、もう少し時間があれば解決できたはずなのにその余裕を持つことができなくてそのままになっている類の問題など、遊んでくれた人の感想を見ていて、そういったものを見つけるたびになぜ対処することができなかったのか、ととても申し訳ない気分になってくる。

今回の仕事での反省点を順に挙げて整理し、次回に繰り返すことのないように、それぞれの場面でどうするべきだったのか、次に同じようなことが起こったときにはどう対処すべきか、をしっかりと考えておいて、次に生かせるようにしていきたい。

トラックバック - http://game.g.hatena.ne.jp/Nao_u/20060423

2006-04-17

[][][]ゲームを作る人が意外とゲームで遊んでいない、という現実 ゲームを作る人が意外とゲームで遊んでいない、という現実 - Nao_uの日記 を含むブックマーク はてなブックマーク - ゲームを作る人が意外とゲームで遊んでいない、という現実 - Nao_uの日記 ゲームを作る人が意外とゲームで遊んでいない、という現実 - Nao_uの日記 のブックマークコメント

彼は俺に問うた。

お前、ゲーム1000本クリアしたか、と。



俺は答えた。

おそらく半分もないでしょう、と。



彼は俺に言うた。

お前にゲームを語る資格は無い、と。


まあ、要約するとこんな感じ。ずいぶん乱暴なようだが、1000本ゲームをクリアしていることがゲーム制作の上でものすごく有益だろうということは、同意できる。ゲームを十分に遊んで、プレイの「感覚」を自分の「感覚」にするまでの基準が「クリア」であり、どんなジャンルの人間とも遊んだソフトを共有できる本数の基準が「1000本」と解釈すると、その先輩の主張も荒唐無稽なものとは思えない。




ゲームプログラマにもいろんなタイプの人がいるけれど、「触っていて気持ちいい」動きが作れるようなプログラマの人は、大抵の場合、これまでに膨大な数のゲームを遊んできたうえに、今でも継続してゲームを遊び続けているような人が多い。

プログラマは他のセクションと違って、自分のイメージする動きを直接プログラムとして実現できる。気持ちのいい動きを作るためにはそれを実装するためのプログラム技術だけではなく、作りたい動きそのものをイメージする能力も必要とされる。こういったイメージ能力は、これまでにいろいろなものを見たり触ったりして体に刻み込まれてきた経験から生み出されるものだろうし、おそらく、そのような経験はある閾値を超えるまでは遊んできたゲームの数に比例するのだろう*1


動きに限らず、パラメータや難易度曲線の調整、「気持ち良い」と思えるモーションやタイミングなど、感性に依存するような調整が必要になってくる部分は、その人のこれまでに経験してきたものの中から生み出されてくるものだったりするのだろうし、その中には実際のゲームプレイからしか得られない経験も多くあるに違いない。



「大人になったらゲームは卒業」と言われたりすることもあるけれど、ゲームを作っている人たちの中でもすっかり「卒業」してしまっている人が意外と多いことには驚く。「最近面白いゲームがないから」「仕事が忙しくて」「家庭を持ってから割ける時間がなくなった」など、各人それぞれいろいろな理由はあるだろうけれど、それぞれの立ち位置なりに、自分の飯のタネや業界がどうなっているのかには興味は持ち続けていないとマズいようには思う。また、大きな会社の偉い人になると、もう個々のゲームがどうなっているのかなんてのは見る必要はなかったりするのだろうか。


よくゲーム業界を志す人に対して「ゲーム以外のことをたくさんやっておけ」というアドバイスが為されることが多いけれど、これは特にプログラマやプランナーに関しては、「ゲームをよく知り尽くした上で」と付け加えた方が良いのではないか、と個人的には思っている。社会人になると「ゲームは一日一時間」の意味が子供の頃と逆になってしまっていて、以前いたチームでは「業務時間中でもいいからもっとゲームで遊べ」と推奨されたことさえある。そのくらい、ゲームに触れる時間は短い。義務で遊ぶようなゲームなんて面白くはないだろうけど。


もちろん、みんながみんなマニアである必要はないし、そうなったらそうなったで別の問題が出てくるのでバランスは大切だろうけど、少なくとも自分から見えている範囲では、ゲームをあまり遊ばない人の割合の方がちょっと多すぎるのではないか、と感じている。それこそ新規に提案されたアイデアとまったく同じものが過去にすでに存在してたり、ひどい時には海外ではメジャーなタイトルで普通に実現されてることを当人が「これは新しい!」とか言ってるのに知識不足で気付けないケースとか。


少し前に、スマブラの桜井正博氏がファミ通のコラムで、「年間100本以上の膨大な数のゲームをこなしている」と書いているのをみて驚いたことがあった。仕事内容や人のタイプにもよる違いもあるだろうけど、今のゲームがどうなっているのかを知るためにはそのようなゲームを遊んで体で覚えるのが一番確実で手っ取り早い方法なのだろう。自分も最近はゲームを遊ぶ時間が激減中だったりするので、少しづつでも未開封のゲームの山を崩していかねば・・・。

*1:だからこそ、スーパーマリオタイプのジャンプ挙動をあのタイミングで完成系に持って行った宮本茂氏は偉大だ。

夢幻将和夢幻将和2006/04/18 13:11企画職の方は両極端が多いですね。まったく遊ばない人と遊びまくる人。遊ばない人は、アイデアが知らず知らず被るのがダメだそうです。プログラマでもMMOしか遊ばない人とか居ますし、そもそもゲーム会社にマニアは1割でかまわないなんて話もあるぐらいですから。

Nao_uNao_u2006/04/19 03:54必ずしもマニアである必要はないですね。弊害も多いんで。まぁ、他の作品を見なくても自分のセンスで仕事ができるから大丈夫、という人であればそれはそれでかまわないのではないかと。凡人には真似しがたいですが。
あと、昔見た話で印象的だったのが、宮本茂氏と小島監督の対談で、宮本氏が『新鬼が島』を作っている頃に、パソコンで斬新なアドベンチャーゲームがあるらしい、という形でPC-88版の『スナッチャー』の存在を認識していた、という話を見たことがあります。よもや宮本氏がPC版の当時はマイナーだったゲームを知っているとは思わなかったので、ああいう人でも他の作品を全く参考にしないわけでもないのだな、と。最近はどうなのかはわかりませんが。

Nao_uNao_u2006/04/19 08:20あと、逆にメモリーカードのセーブデータを見ると誰もが知っているような大作タイトルしか入っていない一般的な感性の持ち主や、何年もコントローラーを触っていなくてゲームそのものに慣れていないような初心者の人などはそれはそれでまた貴重ですよね。そんな初心者の人が最初は歩くのさえおぼつかない様子だったのがめきめきと上達してしまっていくのを見てると、貴重な人材がまた一人減った、と残念に思えることさえありますし。

夢幻将和夢幻将和2006/04/19 10:03どっちがいいとか個人的な感性ですし、一概には言えない話ですが、たしかにNaoさんの言葉も頷けます。自分自身マニアですが、ゲーム関連の知識ベースな話は振ってもらえたりするので、マニアでも必要な場所はあるのかな?と思います。先日のネコソギトルネードなんか誰もダウンロードしに行ってないですし。

トラックバック - http://game.g.hatena.ne.jp/Nao_u/20060417

2006-04-13

[][][][]ゲーム作成における理論領域・感覚領域の製作コストと気力 ゲーム作成における理論領域・感覚領域の製作コストと気力 - Nao_uの日記 を含むブックマーク はてなブックマーク - ゲーム作成における理論領域・感覚領域の製作コストと気力 - Nao_uの日記 ゲーム作成における理論領域・感覚領域の製作コストと気力 - Nao_uの日記 のブックマークコメント

プロトタイプを数多く作り、その中で面白そうなのだけを見繕い、厳選されたものだけをちゃんとしたゲームに仕立てていく。こうすればグソゲーを作ることもなく面白いゲームを量産することができる。すばらしい。

みたいな方法論はよく言われているんだけど、これも実際は難しいよね。特に「面白そうなのだけを見繕い」の部分が。プロトタイプとして作ったゲームって、たとえその中に光るフィーチャーが含まれていたとしても、あんまり面白くないことが多いような印象がある。ゲームってのは絵なり音なりで体験をブーストすることで初めて面白くなることが多くて、そのコア部分だけを切り出して遊んでみてもいまいちなことがある。ジオメトリウォーズからパーティクルとBGMとSEを剥いで、敵のバリエーションが3種類くらいで作ったプロトタイプとか、多分あんまり面白くなさそう。

なのでプロトタイプで遊ぶときは、そこにかっこいいエフェクトや音がのっていることを妄想しながら遊ぶという能力が必要とされる。

最近は自宅でプログラムをする際に気力が長続きしないため、土日の2日間で組めるところまで組んだ時点で面倒になってしまって、そのまま作りかけで放置する、ということを繰り返している。

作るものもインターフェースの実験や非ゲームの箱庭的プログラム、技術デモなどに逃げることが多く、もう長い間きちんとゲームとして完成したものを作ったことがない。最後にちゃんと遊べる形までゲームを仕上げたのは、どのくらい前のことになるのだろう・・・。


このところずっとそんな状態が続いているので、もう何年もエフェクトやSEを作りこむようなところまで進んだことがない。「こんなルールのゲームを作ってみたらどうなるだろう?」とごくごく基本的なプロトタイプを作ってみて、それがなんとなく動き始めた時点で見限ってしまうことが多い。

もしかしたら演出やSEを加えることでもうちょっと遊べるものになるのかもしれないけれど、どうせ大したアイデアでもないし、誰に見せるわけでもないから別にこれでいいか、などと考えて手を止めてしまう。よくない傾向だと思う。面白い、面白くないはさておき、ある程度ちゃんとした形にまで組み上げてみないとわからないことも、きっといろいろあるのだろう。そのような経験は何らかの形で自分の中に残るものだろうし。


ゲームの面白さを構成する要素にはいくつかあって、それは現在も多くの人によって考察が重ねられているのだが、自分なりの考えでこれを大雑把に分類すると以下の二つに分けられる。

言葉を換えてまとめると、「ゲームの面白さ」は

・理論領域……面白さが発生する理由をきちんと筋道立てて説明できる、意味付けされた範囲

・感覚領域……明確に意味付けできないが、主に入出力を通じてプレイヤーの意識や感覚に刺激を与える範囲

に大別できるが、両者の境界は曖昧であり、プレイヤーの習熟度等によっても変化する、ということだ。

10年くらい前には「演出部分などをすべて排除した、理論領域のみの状態まで削ってもなお面白いゲームこそが、本質的に『ゲーム性の高い』良いゲームなんだ」などと原理主義的(?)なことを考えていた時期もあったけれど、実際には感覚領域の良し悪し次第でプレイした人が感じるゲームの「面白さ」はずいぶん変わってくるために、そちらの要素も軽視するわけにはいかない。


実際にゲームを作る過程において、理論領域に関わる部分だけであれば比較的低コストで作ってテストしてみることができるけれど、ゲームの感触や気持ちよさに関わる感覚領域の部分まで作りこもうとするとずいぶんと高いコストがかかってくる。

作りかけのゲームにそのような感覚領域に関わる部分を組み込むことで、どのくらい面白く感じられるようになるのか?ということを判断するには、ある程度の経験も必要だろう。エフェクトやSEが乗ったところを妄想するには、ある程度エフェクトなどを作ってみた経験も必要になってくるだろうし。

そういった意味でも、今の自分のような状態で期限を切ってとりあえず「完成」と呼べるところまで作ってみる、という行為には何らかの意義を見出せるかもしれない。ただ、逆に、やればやるほど自分の才能のなさがイヤになる、という暗黒面もあったりもするけど。


だからこそ、フリーのゲームを発表し、作り続けている人たちは本当に凄いと思う。

まぁ、何にしてもとりあえず諦めたらそこで負けなのだろうから、何であれ手を動かし続けるしかないのだろうけど・・・。

トラックバック - http://game.g.hatena.ne.jp/Nao_u/20060413

2006-04-10

[]デザインと分業 デザインと分業 - Nao_uの日記 を含むブックマーク はてなブックマーク - デザインと分業 - Nao_uの日記 デザインと分業 - Nao_uの日記 のブックマークコメント

  • 同一人物がGUIのデザインと実装の両方をやるということのメリット

「同一人物が、GUIの実装をしながらGUIのデザインをする」のと、「GUIのデザインだけに選択と集中する人と実装に選択と集中する人の二人がペアになって仕事をする」のとでは、どちらの方がいいデザインができるかについて、考えてみます。

たしかに、デザインと実装を同一人物がやることのメリットというものがあるようにも見えます。そもそも、あるデザインアイデアを思いついたとき、それが実際に実装できるかどうかは、実際にプログラミングしてみなきゃ分からないこともあるし、また、実際にプログラミングして、動くものを見てみたら、感触がなんか違和感のあるものだったりしてやり直したりと、そういう、試行錯誤やフィードバックループがあるからです。

もっというと、プログラミングしながら、自分が何をデザインしたいのかがしだいに明確になっていくということが、よくあるのです。プログラミングとは、実装というより、アイデアを練る作業でもあったりするからです。

分業すると、この、プログラミングする過程における、試行錯誤、フィードバックループ、アイデア練りが、デザイナーによってなされないために、そういう面からのデザインの深まりが弱いのです。そして、これは、一見、極めて重大なことのようにも見えます。



  • デザインだけに集中することで見えてくるシンプルで美しい世界

しかしながら、デザインだけに選択と集中をすることのメリットというのもあります。それは、実装のごちゃごちゃした問題を意識から追い出し、純粋に、「知覚の設計」を練りに練ることに、集中できるということです。ほんとうにユーザが求めているGUIについて、考えに考え抜き、そもそも論までどんどんさかのぼって、現在の自分たちのGUIについての思い込みや偏見自体にまで気がつき、それを外側から見つめなおし、根本的に新しい概念や発想でとらえ直し、ゴチャゴチャしたものが、ばっさりなくなって、とてもシンプルで美しいデザインでありながら、極めて汎用的かつすばらしく実用的であるという仕様になるまで、徹底的に煮詰めるための時間と思考エネルギーを確保できるのです。GUIの実装に時間と思考エネルギーをとられてしまっていては、けっして到達できない、シンプルで美しい世界にたどりつけることがよくあるのです。それは、気がついてみれば、なんてことはなし、ごく単純なものの見方なのですが、そこにたどりつくには、自分が無意識のうちに思い込んで閉じ込められている思考の檻を、いくつも破って、その外側に出て行かなければならないので、とても時間とエネルギーがかかるものなのです。


  • 地頭の良いデザイナーの技術的知識

地頭の良いデザイナーと、ペアでGUIプログラミングをしてみれば、すぐに分かりますが、地頭の良いデザイナーは、技術についても、すさまじく貪欲で、デザインの肝となるところについては、プログラマーですら把握できていない深いレベルのパフォーマンスについてまで、徹底的に質問責めにします。そのため、最初のうちは、単にそのデザイナーの質問に答えるためだけに、ゲーム機なりPCなりOSなりの制限事項や、APIの調査や、パフォーマンスの調査に明け暮れるのが、GUIプログラマの仕事になります。また、地頭の良いデザイナーは、自分自身でもプラットフォームの技術仕様書を読み、「あれはどういう意味だ?」、「これは何が嬉しいんだ?」、と徹底的に聞いてきます。

でも、ここが肝心なのですが、それらの技術的質問は、すべて、Whatについての質問なのです。何が、どのくらいの工数で、どのくらいのパフォーマンスで実装できるのか、という質問であり、Howの質問などしないのです。Howなどには、興味がないのです。どんなライブラリを使うのか、どんなアルゴリズムを使うのか、どんなクラスデザインにするのかは、まったく興味なしです。彼らが興味があるのは、そのライブラリやアルゴリズムを使うことで、どのくらいGUIレスポンスが速くなるのかとか、そいういう、ライブラリ、アルゴリズム、アーキテクチャの外部仕様だけなんです。

これはゲームのデザインでも同じ、かな?

分業のメリット・デメリットは作るものによって変わってくるところもあるので一概には言えないだろうけど、それでもプログラマはプログラムの行為そのものに意識を取られがちになるのは避けられない。

トラックバック - http://game.g.hatena.ne.jp/Nao_u/20060410

2006-04-05

[][]技術屋とデザイナーの不毛な対立 技術屋とデザイナーの不毛な対立 - Nao_uの日記 を含むブックマーク はてなブックマーク - 技術屋とデザイナーの不毛な対立 - Nao_uの日記 技術屋とデザイナーの不毛な対立 - Nao_uの日記 のブックマークコメント

とても興味深い。現実にありがちな例が列挙されている。どれもが「エンジニアとデザイナーの対立」という枠で捉えられているのがちょっと気にかかるけれど、それだけこういった事態はよく起こり得ることなんだろう。



  • エンジンが入らない自動車
    • こんな最低限の知識すら持ってないデザイナーが設計することもあるんだ・・・。怖い。
  • 薄すぎる薄型テレビ
    • 「デザインの都合でできるだけ薄くしたい」ことと、「それによって下がる性能」のトレードオフの判断は誰が行ったんだろう?どちらかというとその人の責任?
  • おかしなエルゴノミクスデザイン
    • きっと、「現実にそれを作ったらどうなるのか」ということに対する認識力も、デザイナーの能力のひとつなんだろう。
  • 「操作ボタンは全体のデザインを崩す根源」といってボタンのない家電
    • デザインの仕事といっても見てくれだけ決めればいいわけではないはず。本当に優れたデザインであれば、インターフェース面まで含めた「どんな人が、どういった場面で、どのように使うのか」まで考えてあるはずだろう。外見のデザインとインターフェースを考える人が別、ってのは効率が悪いような。


Aさん:エンジニアにとって重要なのは、納期とコストだと思うんです。つまりモノをつくる際、技術側はいかに低コスト、かつ納期を守るためにいちばん早く開発できる方法を考えながら常に作業しています。

 ですから、デザインが凝れば凝るほど時間とコストのかかる設計になり、結果として開発の最短ルートからは遠ざかることに……。そういう意味でいえば、エンジニアにとってデザイナーは、いわば最短ルートをねじ曲げる“邪魔者”なんです(笑)。

たとえエンジニア視点のみで捉えたとしても、大切なのは納期とコストそのものではなく、本当に重要なのは「最終的な製品の質」と「納期・コスト」のトレードオフだろう。ここを履き違えてただ納期内に低コストなものを作ればいい、といいはじめると何かが狂ってくるのではないか。



青木さん:エンジニアの方は常にコスト削減や納期短縮という現実的な制約を考慮する必要がありますから、必然的に「今ある技術・今ある施設や部品でできる生産能力」といった、現実的な思考の中でものごとをジャッジする方が多いと感じます。

 でもそれは時として、モノづくりの可能性を制限してしまうんじゃないかな、と思うんです。「過去の経験から生み出せるデザイン」って結局、どこかで見たことがあるようなデザインなんですよね。それって手堅いかもしれないけど大ヒットは望めないし、大きな利益も生み出せないと思うんです。

デザインに関しては「過去に存在しないこと」が重要なのではなく、「そのデザインによってどんな新しい使い方が生まれるのか」が大切なんだろう。

ウォークマンは「音楽を持ち歩く」事を可能にするためにあのようなコンパクトなデザインである必然性があったし、iPodは見た目のデザインが優れているだけでなく、ソフトウェアも含めたインターフェースのさわり心地や感触、「どういった人たちがどんな場面でどのように使うのか」まで考慮に入れた製品としてのトータルでのデザインが素晴らしかったのがここまで普及した理由だろう。

見た目の綺麗さや美しさだけではなく、「それを使う人がどんな体験をするか」まで考えてこそ、素晴らしいデザインと呼べるものができるのではないか。



自分の専門分野の枠内だけでものを考えるのではなく、デザイナーも技術的な制約について知っておく必要があるし、当然エンジニアもデザインの意義やあり方について理解しておく必要がある。結局、「エンジニアだからまず技術のことを考える」だとか、「デザイナーだから見た目を重視」なんて狭い視野で考えるのではなく、技術屋だろうがデザイナーだろうがまずは製品としてのトータルパッケージとしてどうすればより良くできるのか、という視点でモノを見て、考えていく力が必要なんだろう。その上で、それを実際に形にするときにはそれぞれの特異分野やスキルに応じて「デザイン」と「実装」に仕事を分業する、というだけのことで。

それぞれの専門分野の仕事はその人にしかできなくても、最終的にできあがった製品を使ってくれる人の満足度をより高くするためにはどうあるべきか、ということに関しては専門分野に関わらず誰にだって考えることはできるし、より良いモノを作りたいのなら、そうしていく必要がある。

互いに相手を目の仇にして対立したところで、いいことなんて一つもない。



で、きっと、これはゲーム制作のデザイナー・プランナー・プログラマに対しても、まったく同じ事が言えるのではないか、と思う。

トラックバック - http://game.g.hatena.ne.jp/Nao_u/20060405

2006-04-04

[][][][]大規模な開発現場におけるゲームの作られ方 大規模な開発現場におけるゲームの作られ方 - Nao_uの日記 を含むブックマーク はてなブックマーク - 大規模な開発現場におけるゲームの作られ方 - Nao_uの日記 大規模な開発現場におけるゲームの作られ方 - Nao_uの日記 のブックマークコメント

ちょっと前のファミ通のFF12の開発者インタビューで、アートディレクターの人が「FF12はクリアーしましたか?」という質問に対して「まだ3分の1くらいまでしか・・・」「発売日に購入してゆっくり遊びます」などと答えていたのを見て驚いた。自分の作ったものに関して、開発段階の部分を切り取って見たときの印象と、ある程度流れができて全体の進行の中で見たときの印象とでは違って見えることはけっこう多い。自分の作ったものがゲーム本編の流れの中でどのように登場して、その場面でどういったイメージを与えているのかを把握しないままに完成させてしまって商品として売ることができてしまうものなんだなぁ、というのは新鮮に感じた。


トップの人がこういう作り方をしている状況下で、おそらく100人を超えるであろう大人数のスタッフたちが、自分の作っているものがゲームの中のどんなシチュエーションでどのように使われているのかをどれくらい把握できているのか、ちょっと気になってきた。

作っている過程でそこだけ見ればとてもクオリティが高いけれど、全体の流れからすると浮いて見える、というような部分もあるだろうし、逆に単体で見たときにはこれはちょっと微妙かも?と思っていたような絵や仕様が、通して遊んでみると自分の想像していたのとは違った形で綺麗に収まっていて、驚くこともあったりする。FF12のような通常のプレイでも60時間を越えるような規模の大きいゲームだと、開発中にざっと一通り遊んでみるだけでも大変だったりするのだろうけれど、それでも通してプレイしてみないとわからないことだって、きっといろいろあるはずだろう。


とりあえずこのインタビューを見て思い出した別のインタビュー記事から一つ引用。

宮本茂さんはユーザーの評判が出る前に

反省会を開くとお聞きしましたよ。

さらりと書いてあるけれど、これをちゃんと実行しているのであれば本当にすごいことだし、反省点を見つけ出して次につなぐ、という意味ではものすごく有意義なことなんだろうと思う。




あと、他にも受け答えで気になる点がいくつかあった。こういったインタビューに対して揚げ足を取るようなツッコミを入れるのは野暮なことかもしれないけれど、ファミ通の記事から2つほど引用してみる。

  • ハードの性能は限界まで使い切ったと?

皆葉 今回は開発当初から限界ギリギリまで性能を使いきろうとしました。バトルと移動を同一画面で行うというのは、早い段階で決まっていましたので、その影響でグラフィックに使える性能も少ないとわかっていました。グラフィックの作り方も今までと異なり、表示されたときにベストになるようにしています。

素朴な疑問だけど、それなら今まではどのようなときにベストに見えるように作ってたんだろう?



  • 背景を作る際は、実際にプレイしているユーザーの視点などの感覚は意識されますか?

上国料 もちろん非常に考えます。作っているときに綺麗に見える風景と、実際にプレイ中に見て美しい風景は別ですからね。あと、ゲームをプレイしているときは、背景はさほど注意して見られないというのが、僕らの定説です。しかし、実際に旅行に言った人たちは風景を見ますし、世界遺産に行ったら感動しますよね。これと近い感覚を再現したいと思っていました。

できることならこの段階で「定説」などといって思考停止せずに、「ゲームをプレイしているときは、背景はさほど注意して見られない」理由は何故なのか、ということまで考えてくれるととても助かったのだけど。ここで考えるのをやめてしまったら、本当に「さほど注意して見てもらえない」程度のものになってしまうかもしれないし。

ただ美しい風景を作ってそれで終わり、というわけではなく、その効果が最大限に生かされるような方法を考えていくことも、アートディレクションの大切な仕事であるように思う。とりあえず、問題の一つであるマップ構成に関しては、「レーダーやMap画面を見ればわかるだろう」というのはあくまで補助的な回避策でしかなく、本当に他に方法がなくてどうしようもないときの最後の手段だ、くらいに考えておくべきなんだろう。



FF12のような特殊なプロジェクトは開発の規模も他に類をみないほど大きいものだし、そのために仕事の進め方や考え方が違ってくる部分も大きかったりはするのだろうけど、どんな現場であれ、このようなことについて考えを巡らせることだけは忘れないようにしていきたい、と思う。

トラックバック - http://game.g.hatena.ne.jp/Nao_u/20060404

2006-03-29

[][][]ゲームはなかなか最後まで遊んでもらえないメディア ゲームはなかなか最後まで遊んでもらえないメディア - Nao_uの日記 を含むブックマーク はてなブックマーク - ゲームはなかなか最後まで遊んでもらえないメディア - Nao_uの日記 ゲームはなかなか最後まで遊んでもらえないメディア - Nao_uの日記 のブックマークコメント

もう1つだけ付け加えることがあるとすると、ゲームはなかなか最後まで遊んでもらえないメディアだということです。本や映画に比べて、最後までたどり着くのに時間がかかりますし、インタラクティブな娯楽ゆえに「難易度」や「作業」が発生して、途中であきらめてしまう人、途中で飽きてしまう人が出やすいんですね。

(中略)

ですから、ボクは1時間しか遊んでない人の意見も立派な意見だと受け止めるようにしています。自分の作ったゲームが最後まで遊ばれないという事はありますし、最後まで遊んでいない人の意見を読むこともあります。そういう人の意見は、もしかすると、世間様一般での「批評」の水準には達していないのかもしれませんが、最後まで遊ばなかったという事実がすでに1つの評価になりえる、と考えています。

もう、「激しく同意」以上に付け加えることのないくらいに的確な指摘であるように思う。


娯楽としての価値を考えるなら「その人がどこまで遊んで、どのくらい楽しめたのか」は重要な指標だし、製作者側から見れば実際に遊んでくれた人の意見に限らず、店頭でぱっと見たときの印象や、触れてないばかりか見てすらいない、「今回は~の理由で購入を見送りました」みたいな意見もまた、貴重な情報であるように思う。場合によっては「購入する理由」と同レベル以上に「購入しない理由」も重要だろうから。

また、たくさんの感想たちを純粋に統計データとして捉えるならば、「やりもせずにクソと決め付ける人の割合」とか「信者とアンチの比率」みたいなものでさえ、何らかの考察の対象にすることもできなくはない。そんなデータの取り扱いには十分な注意が必要だろうけど。


あと、以前にもちょっと書いた*1けれど、個人情報つきでネットワークに常時つながった機械が普及して、ゲームのプレイ時間や進行状況をその場でサーバに送信することで「典型的なハマりポイントの検出」とか「最後まで遊んでくれた人の割合」などの正確なデータが得られるようになったなら、ゲームの作り方もまた変わってくるのではないだろうか。個人的には正しいデータが得られて正確に判断・分析できるものであれば、情報は多くあればあるほどありがたい、と思っている。*2

*1:ゲームがどのように遊ばれているのかを知るために:http://game.g.hatena.ne.jp/Nao_u/20060219#p13

*2:「過剰な情報はそれを処理しきれない人間の能力をさらに落とす」みたいな台詞を思い出したりもするけど。出典は何だっけ?

トラックバック - http://game.g.hatena.ne.jp/Nao_u/20060329

2005-11-24

[][]セオリーに則って作っても セオリーに則って作っても - Nao_uの日記 を含むブックマーク はてなブックマーク - セオリーに則って作っても - Nao_uの日記 セオリーに則って作っても - Nao_uの日記 のブックマークコメント

確かにゲームデザインには「セオリー」と云えるモノがあるのですが、とは云え、セオリーをいくらツギハギしても「ゲーム」にはならない。アイデアを篩い分ける「ざる」はどこまでいってもざるであり、誰かが生んだ「種」(あれれ氏の云い方では「卵」)がなければゲームは生まれない。種があってこそ、それをセオリーによって「磨く」コトが出来るワケです。

スペルチェッカーには小説を書くことはできない。綴り間違いや文法の誤りを指摘して文章の完成度を上げることに貢献はできても、それ自体は何か新しいものを生み出すことはできない。もし文法に則って、セオリーに従うだけで良いものができるなら世の中はもっと素晴らしいものであふれているだろう。


また、かならずしもセオリー通りに進めることが良いわけではない。セオリーから外れているものの指摘やそれを一般的によく見られる形にもっていくための提案なら誰にでもできるけれど、意図的に何らかの効果を狙ってセオリーから外している部分や、根本的にセオリーなど気にせずに作られた真に創造的なものに関して、その断片を見ただけでは理解できないこともある。

これまでの経験上、企画草案段階で評価される企画は普通の企画。

けちょんけちょんに言われるようなものの方が新しい。

たくさんの人に驚きを与えられるような大きく育つことのできる「種」を作れる人は多くはない。学習によって誰にでも習得できるセオリーとは違って、そのような種を作る能力は真似しようとしても簡単に身に付けられるものではない。そういうのが一般にいわれる「才能」と呼ばれるものなんだろうか。

時々、自分はただのスペルチェッカーなんじゃないか、と思うこともある。まぁ、今はとりあえず自分にできることをできるようにやっていくしかないわけだけど。

トラックバック - http://game.g.hatena.ne.jp/Nao_u/20051124

2005-11-12

[][][]プログラマにできないこと、プログラマにしかできないこと(その2) プログラマにできないこと、プログラマにしかできないこと(その2) - Nao_uの日記 を含むブックマーク はてなブックマーク - プログラマにできないこと、プログラマにしかできないこと(その2) - Nao_uの日記 プログラマにできないこと、プログラマにしかできないこと(その2) - Nao_uの日記 のブックマークコメント

とかいろいろ考えても、のら個人ゲーム製作をやっている我々には選択の余地がなく、プログラマ兼ゲームデザイナ兼グラフィッカ兼コンポーザー兼いろいろ、いろいろだ。どうせ古いゲームの焼き直しみたいなものを作ってばっかりですよーだ!

(略)

そもそも自分でゲームを作るような、強度のゲーマー脳の人間に、今までのゲームの枠にとらわれないゲームを作れ!って言うことに無理がある。ゲーマー脳は、きっちりとしたゴールのある古典的なゲームに楽しみを感じるよう長い年月をかけて熟成されたものだから、前の論文でいうボーダーラインケースのものをそもそも楽しめないんじゃないかと思う。で、自分が楽しめないものは作れない。いや作れるかもしれんが、趣味でそれをやるのは苦痛だよね。

まあでも無理をしてまで、いままでのゲームとは全然違うゲームを作ってやるぜ!とか気張る必要は特にはないんじゃないかなあとも思うわけで。そもそも、市場から昨今消え去っている昔かたぎのゲームがたくさんあるわけで、それを個人ゲーム製作者がほそぼそと復興させつつ、じりじりと前進させるという姿は決して悪くない、というかそれが私にとっての理想だ。

これからの商業作品には古典的なゲームよりもボーダーラインケース的な内容が求められる傾向が強くなるのだろう。

だからこそ、個人製作では作りたいものを作りたいように作ればいい。ベーマガやMSX-FAN、PC-98のフリーソフト群を見て育った人間としては、個人製作ゲームには市販の商業ゲームにはない魅力を感じる。商業レベルでは「商品」としての価値を持たせるために一定量の規模や物量が必須となるけれど、個人製作ではそういったしがらみとは無縁の状態でゲームが作れる。時には『洞窟物語』とか『雪道』みたいな特異で他では味わえない魅力を持ったゲームに出会えることもある。

もし仮に市販のゲームがボーダーラインケースに偏っていくのだとしたら、それで空いたスキマはフリーのゲームが補完することができるかもしれない。STG・パズル・格闘などの古典的なジャンルのゲームであれば、すでに個人製作でも十分に面白いものが作られている。市場とか採算とか期限とかを気にしなくていい分、商業的に作るよりも有利かもしれない。


基本的に他のどんな能力があったとしてもプログラミングができなければゲームを作ることはできない。自分一人でゲームを作ることができるのはプログラマだけだし、自分で実際に動くものを作りながら考えることのできるプログラマにしか思いつくことのできないゲームデザインだってあるに違いない。作る人の能力や資質によってできあがるものも変わってくるだろうから、良くも悪くもそれが多様性を生み出す源泉になるはずだ。

ああ、こういうことをぐだぐだ言う前に自分も何か作れよ、とか突っ込まれそうな気がしてきた。そういえばもう何年も仕事以外でちゃんとしたゲームを完成させたことがないなぁ・・・。

トラックバック - http://game.g.hatena.ne.jp/Nao_u/20051112

2005-11-11

[][][]プログラマにできないこと、プログラマにしかできないこと(その1) プログラマにできないこと、プログラマにしかできないこと(その1) - Nao_uの日記 を含むブックマーク はてなブックマーク - プログラマにできないこと、プログラマにしかできないこと(その1) - Nao_uの日記 プログラマにできないこと、プログラマにしかできないこと(その1) - Nao_uの日記 のブックマークコメント

要するにプログラマにゲームデザインをやらしておくと、連中が好きな昔のゲームを再生産するばっかりで、Doom4みたいなゲームはできるけど、Nintendogsは生まれないよね、ということらしい。

まあ主張している内容は分からんでもないが、これはプログラマだからどうこうというより、プログラマが主に属するコンピュータギークコミュニティの好みが偏っているのが問題だね、っていう内容に思える。コメントでも、次のアーティクル(http://lostgarden.com/2005/11/five-step-program-to-move-beyond-game.html)でも、anti-programmerの意図があるわけではないと言っているし。

個人的には、プログラマであること自体は、ゲームデザインに悪影響を及ぼすことはないと思う。

プログラマはこれから作ろうとしているものがどのような実行結果になるのかをまず頭の中で組み立てて動かしてみて、それをプログラムという行為によってコンピュータの中に再現するというのが仕事であるために、他の職種に比べると企画・仕様の段階からどのような出来上がりになるのかを正しく見積ることができる。

その能力ゆえに、ゲームのルール設定やパラメータ調整などを行えば的確で効率よく作業を進めることができる反面、確実性を重視しすぎて柔軟な発想に乏しくなる事はあるように思う。


この話を見て、学生の頃に研修に行った会社で聞いた話を思い出した。

プランナーやディレクターは無茶を言うのが仕事だ。

だから、プログラマに企画をやらせてはいけない。なぜなら、どんなに気をつけていてもプログラマの本能のために最後の最後で必ず守りに入ってしまうからだ。

ゲームはプログラマからみて少々無茶なくらいの仕様でないと面白いものにならない、と。なんとなく納得できるようなそうでないような話だけど、特にディレクターには理不尽ではない説得力のある「無茶」をいう能力が求められるのだろう。


プログラマの本能故にアイデア出しの段階から「どう実装するか」などと考えてしまうのも事実で、しがらみにとらわれずに自由に発想すべき場面であるにもかかわらずアルゴリズム的に可能かどうかとか、メモリや処理量は現実的なのか、などとその時点で考えるべきでないところまで無意識に考えてしまうし、「これは無茶だ」と思った時点で安全に実装できそうな仕様にしようと考えてしまうこともある。

こうした思考法が発想の枠組みを狭め、その結果ボーダーラインケースに位置するような新しい発想が出にくくなってしまうこともあるのではないかな、とは思う。



ムラシュウに感想を聞くと「面白いんじゃないですか?」と目を輝かせる。

これまでの経験上、企画草案段階で評価される企画は普通の企画。

けちょんけちょんに言われるようなものの方が新しい。

「メタル」も「ボクタイ」も身内にまずぼろくそに言われた。

この企画、ダメなのかもしれない。

・・・発想の根幹が違う。こういった新しいものを作れる人とそうでない人の違いはどこにあるんだろうか?