若手ソシャゲプランナーがゲーム業界で何とかやっていた話

 こんにちは、涜(とく)です。 今回はレベルデザインの話を書いてみます。もちろん一般的な話はしません。 どういう感じで作るといいんだろう？って迷いやすいところでもあるので、理想形を自分で定義するためにも、感覚ではなく多少は論理的に考えてみたいと思います。 ここで語ることはあくまで基礎的であり、応用や具体的な制作については各々調整するのが前提です。 決まった答えがあるものではありませんし、モノが出来上がって評価されるまで良し悪しが分かるものでもありません。 ふ～んって感じで見ていただければと思います。 レベルデザインとは 調べれば色々なところで色々と書かれているので、私なりにふわっと書きます。 レベルデザインとは、平たく言えばステージ構成です。 「レベル」というのは、いわゆる「面」のことです。この面をゲーム全体でいくつ置くか、それぞれどんなテーマにするか、各面ごとの中身をどう作るかを決めていく作業です。 理想モデルとは これは私が勝手に出した言葉ですが、今回の話題としてはどういうレベルデザインが理想的であり、これを外れるとプレイヤーとして面白くないよねっていうところをなんとなく詰めてみることを主旨にしたいと思います。 具体的にどういう風に理想モデルを表現するかというと、ゲームの面白さの数値化というかグラフ化を行います。 何をグラフにするかというと、「ゲーム進行に伴ってプレイヤーが身に着ける、攻略に使う要素がどのように成長するか」というものと、「レベルデザイナーが用意するステージでどのような攻略を要求するか」というものを数値化し、それらの差を取ってプレイヤーの難しさの体感をグラフで表現してみよう、といった感じです。 要するに、プレイヤースキルとステージ難易度の差を取ったら、どう難しいと感じるか大体分かるんじゃね？ということです。 ゲームの面白さに影響する要素 まずはこれが分からないと決めようが無いので、要素を抽出します。 と言っても、私がこれらを抽出するのは専門学校で教えてもらった知識の受け売りなので、私の手柄でもなんでもありません。 要素は以下の3つです。 運 技量 知識(智略) ゲームの面白さは、これらをプレイヤーが如何様に用いるか、またステージ側がこれらをどれだけ要求するかで決まります。 面白いという主観は、難しさがちょうどいいだけでは成り立ちません。易し...

こんにちは、涜(とく)です。 たまには真面目に専門分野の話をしてみます。 わたくし実はインゲームと呼ばれるゲームの遊びの部分を担当しています。 ゲーム開発上の企画職の作業としては花形であり、担当していてやりがいを感じる分野ではあるのですが、ゲームの出来と直結している以上プレッシャーのかかりやすいところでもあります。 私の関わっているようなソシャゲだと、作業のほとんどはキャラクター性能かステージの設計になると思います。基本的な遊びのシステムは開発初期に作りきってしまうので、開発期間中でも運営中でも多くの時間を性能の設計とデータ作成、バランス調整に費やします。 出来が酷いと炎上しますし、あまり無難すぎると喜ばれないし、出来が良くても悪くても売上低下の温床になる場合もあります。（まぁ燃えるほど有名ではないですが） 上記の通り売り切りでも難しいですがソシャゲだと別の難しさも伴う箇所だと思っています。 そんな担当を今まで何とかやってきた知見をここに共有できれば幸いです。 キャラクター性能を作る上で意識していること まずは、あくまでゲームとして気にしていることについてです。 ゲームのシステムを活かす設計になっているかどうか それぞれの性能のユニークさ システムが耐えうる限界を超えていないか ①ゲームのシステムを活かす設計になっているかどうか これは当然できていないとマズいのですが、運営が長く続いたり、ユーザーが何らかシステム上の抜け穴を見つけたものに対して対処するような、応用的な対応が要る局面が訪れると見落とすことがあります。 また、ユーザーがゲームを初めて最初に触れるようなキャラクターの場合、これを強く意識して設計しなければなりません。 例えば、RPGならよくある、物理・魔法のような攻撃属性のあるシステムを、それらが如何にして戦闘上で影響をもたらすのかを、できるだけ説明なしで理解させる必要があります。 基本的にただ戦いを表現するのであれば、物理・魔法のように分けることなくただのダメージにしてしまえばよいです。しかし、わざわざ分けているならばこれらの価値の違いを示す必要があります。 あくまで私の持つ一番強いイメージですが、攻撃属性の違いというのは希少性の違いになることが多いと考えます。これはユーザーが所持する手持ちでの属性の偏りだったり、敵の持つ耐性の偏りだったりします。 もち...

こんにちは、涜(とく)です。 闇深そうな話題に足を突っ込んでいきます。 ここら辺むやみに突っつくのが危険なのは百も承知ですので、私なりにできるだけ予防線を張ってから話始めようと思います。 私が仕事で関わっているものも"その気"があるので、情報漏えいにならない範囲で内情も話せればなと思います。 そんなわけで早速予防線。 「量産ゲー」とは？ これを定義しないことには、いろいろな捉えられ方をされて困ることが予想されるので、私の考えの範囲ではありますが書いていきます。 数値や仕様などにコピーと判断される可能性の高い要素を有し、「オマージュ元の作品との差異が少ない」と揶揄される場合が多いと主観的に感じるもの。 「部分的にでもオマージュ元の作品より優位性がある」と判断されない場合が多い、あるいは優位性と呼べる部分を加味しても「オマージュ元の作品と比較して総合的な魅力に欠ける」と判断される場合が多いと主観的に感じるもの。 以上、2点を満たすものを本記事内で「量産ゲー」と定義します。また、これに該当するか否かは 個人の主観によって決定される と考えていますので、あくまでこれは「今その人にとって、量産ゲーだと感じられるもの」という前提をご承知おきください。 「量産ゲー」誕生の背景 どこか見覚えのあるゲームが開発される背景は、既存のゲームに寄せて作ることによるメリットを最大化しようとすることで起こると考えています。 そもそもなぜ既存のゲームに寄せるのかというと、開発者にとってもプレイヤーにとっても既存のシステムでないとすんなり理解しづらく、売れるかどうかの博打度合が高くなってしまうからです。企業は営利団体であることが前提ですので、たとえユーザーを喜ばせることが目標であったとしてもボランティアではいられません。コストを抑えて利益を出そうとするのは当然のことです。 次に、既存のゲームに寄せて作るメリットは下記のようなものです。 既存ゲームという具体的なイメージがあるため、ステークホルダーと成果物の共通認識を持ちやすい。 仕様作成コストを低く抑えられる。 ゲームデザイン、レベルデザインコストを抑えられる。 運営をある程度トレースできる。 既存ゲームというベースがあることである程度の失敗のしにくさが認められ、信用の高い安心感を得られる。 ※もちろん各ゲームによってこれらをど...

こんにちは、涜(とく)です。 今回の件はざっくりいうと、会社が利益を出すのに四苦八苦しているという話です。 それでは早速本題にいきます。 利益の出し方 これはもちろん私のいるゲーム会社に限らず、どこでだってさほど変わりません。 自分たちに掛かるコスト、これを上回る売上を営業で賄うことができればそれでOKです。 ただし、そのコストと売上の差分である利益があまりにも小さすぎれば困るはずです。 新しいことができないとか、よりよい環境が作れないとか。 ひどいと給与が払えないとか。 そんな状態にならないためにも企業は日頃から色々考えて利益の最大化を目指しています。 利益を増やすなら…… さて、どうしたらよいでしょう。 「"いいもの"を作ったらユーザーは付いてきて来てくれる」 当時ビジネス思考アピをした就活生の私に、熱い言葉をかけてくれた面接官がいました。 正直、この思考のほうが、本来の私の価値観に近いものでした。 就活で箸にも棒にも掛からず、ビジネスアピをしろ！という学校からのアドバイスを鵜呑みにして思考停止になった私は、この時目が覚めたような気分になりました。 まぁ、その会社落ちたわけですが。 とにかく、これは一つの答えだと思います。 今回の表題に従って表現するならば、これは「こだわり」にあたります。 利益の増やし方としては、売上を伸ばすことになります。 もう一方の「効率化」は、これとは逆にコストの低下によって増益を目論みます。 両方やればいいんじゃね？と考えると思います。 そう、どちらもやればもっと利益が出せるはずです。 やってみてよいのではないでしょうか？次の２点に目を瞑れれば。 ①「こだわり」がコストを食らう これは宿命です。 ある程度余裕と自信があれば、「こだわり」も「効率化」も両方やればよいでしょう。 しかし、それが無ければ「効率化」だけ進めるのが無難です。 「こだわり」というのは青天井です。正解も終わりもありません。そのため、時間とコストが許す限りやるという風にほぼなります。 やり始めたら歯止めが利かないものなので、節度を保つかやり抜くかは前もって決めておくと良いでしょう。 また、「効率化」も実際のところ着手してすぐはある程度コストを食います。 しかし、それは効率化が成されたあとの期間を考えれば費用対効果はよいはずです。 ゲームのサ終は早くて...

こんにちは、涜(とく)です。 今まで紹介してきたゲームプランナーの仕事から内容を適当にピックアップして、それぞれについてできるだけ細かく話してみようと思います。 今回はゲーム企画をいかにして作るかという話になります。 会社ではどんな感じで作るのかと、就活で必要な企画書との違いについてそれぞれ触れてみようかと思います。 プランナーの就活では「企画書」の提出がほぼ必須ですので、気になる方は見てもらえると良いかなと思います。 ただ私自身は企画の魅せ方にあまり自信が持てないので、完成する企画に至るまでの思考についてを参考にしていただければ幸いです。 実務における企画書 企画書とは、ゲーム制作を始める上で必要になる資料です。 社内や協業先向けに、制作するゲームの 概要 ・ マーケットでの売り ・ マネタイズ と それを実現させる要素 などを伝えるために作成されます。 企画書を作成すること自体、基本的な業務のうちに入らないことが多いと思います。このあたりは会社さんによってまちまちかとは思いますが、ほとんどの作業はすでに始まっているプロジェクトのものなため、普段触れることはないでしょう。 企画書を作成するパターンは大きく2通りあると思っています。 1つは 「自社企画」 、もう一つは 「営業」 です。 あくまで私の知りうる範囲なので、例の1つ程度で認識してもらえると助かります。やり方なんてコロコロ変わるでしょうし。 自社企画 当然パブリッシャーでのパターンです。 ※パブリッシャーについては コチラ 会社の状況を見て新規プロジェクトを始めようとなったとき、社員に案を募ったり、溜めておいた案を引っ張ってきたり、協力会社さんの得意なものをベースに考えたりした上で企画を作るイメージです。 そう、イメージなんです。 同業の知り合いにこういう話を聞いても分からんといった感じでしたし、まぁ普通に平社員やってれば聞かないような話です。 当然このあたりは会社さんによって全然違うと思うので、一概にこうとは言えないです。 申し訳ない！ 営業 このパターンは先ほどとは対称的に、デベロッパーがやるパターンです。 今まで絡みがあったパブリッシャーなどから打診があったり、こちらから営業をかけることで企画の話をもらい、それに応える形で企画を作成してプロジェクトを立ち上げる感じです。 ウチはデベロッパーなのでこちら...

こんにちは、涜(とく)です。 今回もプランナーの仕事について作業別に話していこうと思います。 というわけで後編です。前編はこちら→ プランナーの作業とは？前編 プランナーの作業(残り) まず作業の一覧を振り返ってみましょう。 資料作成 データ作成 データ分析 マネジメント QA フィードバック ミーティング 前回2つしか紹介してないので、残り全部ですね。 ここからはより "やってみないとわからない" タイプだと思いますが、できる限りイメージしやすくなるように書いていこうと思います。 データ分析 かつてはソシャゲや対戦ゲーならではという感じだったかもしれませんが、今どきどこのタイトルでもやっていそうな分野です。 というのも、最近はソーシャルゲームに限らずコンシューマーなどでも販売後に運営を続け、追加コンテンツのリリースやバグ修正などのアップデートがされます。 この追加コンテンツというのが、プレイヤーの皆さんの動向を探って打ち出された施策だったりするという感じです。 データ分析は何のために？ データ分析を行う動機は、ゲームごとやその時の状況によって様々でしょう。 "売り上げを上げたい"、"バランスを改善したい"、"延命させたい"、"アクティブユーザーを増やしたい"など色々です。 これらを抽象的に括ると、"そのゲームの期待に満たない部分を改善するため"というところでしょうか。 もちろん現状で十分優秀ということもあるでしょうが、その場合はより上を目指すよう期待されるはずなので、相対的には常に期待には満たないのだと考えておきましょう。 この改善をもたらす施策を練るための事前調査や、その結果を評価するために我々はデータ分析をしています。 データ分析でやること 取れる手法こそ会社さんやチームごとで様々ですが、基本は一緒なはずです。 調査に必要なデータを用意する。 目的に応じてデータを加工する。 加工データから傾向を把握し、調査元の状況について仮説を立てる。 データの加工というのは、例えば2つ以上のデータを使ってグラフを作ったり、何か式を通して必要な値を導出したりというものです。 別に データを改ざんするわけではないです。 最終的には立てた仮設をもとにこれからの施...

こんにちは、涜(とく)です。 今回はプランナーの仕事を作業別に話していこうと思います。 ただし、紹介内容が多くなりそうなので、前後編に分けようと思います。 プランナーの作業 作業というと前回紹介した"仕事"と意味が被って聞こえるかもしれませんが、 前回紹介した仕事はカテゴライズした"目的そのもの"であり、今回紹介する作業はそれらを実現させるために具体的にやることという感じです。 もちろん、以前の仕事の分類はそれぞれに「この作業はあって、あの作業はない」みたいなものを含みますが、便宜上まとめて紹介します。 というわけで、こちらが作業です。 資料作成 データ作成 データ分析 マネジメント QA フィードバック ミーティング ※外部対応系や雑務の作業は普遍的な説明が難しく、それ専門という感じなので省きます。 それでは中身を見ていきましょう。 資料作成 資料というのは、ほぼ仕様のことです。 一生普通の企画にとどまる方は、一生仕様を書くことでしょう。 企画書は基本書きません。 というのも、新規案件の立ち上げ時にディレクターポジションにあたる人が作成して終わりという感じだったりして、何かにつけて必要なものではないからです。 まぁ、社内コンペがあったり、小さいゲームをたくさん作っているところは別だと思いますが。 ですので、軽く 仕様書の解説 と、 仕様書の内容 についてまとめてみます。 仕様書とは 仕様書というのは、"見たら完成形が想像できる資料"と私は解釈しています。 ゲームはプログラムやグラフィックなどの要素の組み合わせで構成されています。 ですので、機能を作るのに必要なパーツを揃えるためには、それらを作る各職種のメンバーや管理者に対してそれがどういったものかをできるだけしっかり伝える必要があります。 その伝達に必要な情報を書面化したのが、"仕様書"という感じです。 仕様書の内容 あくまで今まで私が見てきたものや書いてきたものベースですが、とりあえず書いていきます。 まず当然のことですが、仕様書は見た人に理解してもらうために作るので、内容を把握しやすく書く必要があります。 ですので、情報の出し順は「抽象→具体」を意識するとよいでしょう。 これをもとに、仕様の要素を並べてみます。 概要（どういったも...