会社初！コンシューマーでのオリジナルゲーム開発チームに迫る！ Vol.1
目次
- はじめに
- どういったゲームを開発しているのか
- コンシューマーでオリジナルを創り始めたきっかけ
- 受託開発との違い
- 制作体制や期間
- 今回の開発にあたって工夫したこと
- スマートフォンゲームを創る時と比べて、苦労した点
- おわりに
はじめに
今回は、弊社初となるコンシューマーでのオリジナルタイトル開発チームに直撃インタビューしてまいりました。 インタビューにお答えいただくのは、プロジェクトリーダーのIさんとプランナーのT2さんです。
受託開発との違いや、技術的な工夫などご紹介しておりますので是非ご覧ください！
どういったゲームを開発しているのか
──早速ですが、どういったゲームを開発されているのでしょうか？
I：アクションパズルゲームですね。
T2：もともとパズルの方が強かったのですが、テーマチェンジにともなってアクション性が強くなりました。
──やり込み要素などはありますか？
I：繰り返し遊んで、より高いスコアを目指すようなゲームです。
近しいジャンルは「脳トレ」です。
ちょっと全然違うイメージを抱かれるかもしれないのですが、ゲーム内容としては知性を要するものになるので、 そういった意味で、脳トレです。
T2：「自分が操作したことによってどう変わるのか」を瞬時に考えて操作するので 反射神経も必要かもしれないです。
コンシューマーでオリジナルを創り始めたきっかけ
──なぜ今、コンシューマーでオリジナルを創ろうと思ったのでしょうか？
I：社内でオリジナルを創れるラインを増やしたいという想いがあります。
これを機会に会社で新しい仕事の幅を広げていきたいです。
──弊社では近年スマートフォンゲームを中心に開発してきたが、なぜコンシューマーを選んだのでしょうか？
I：今の開発チームは、少し前に大きなプロジェクトを終えたメンバーがほとんどです。
そういったメンバーの布陣や会社の状況を考え、やったことないものに挑戦しよう！ という話になりました。
T2：以前からSteamのインディーズが熱いなと感じていたことと同時に、Switchでゲームを創ってみたいという気持ちもあったので
コンシューマー（SwitchとSteam）でオリジナルを開発しようということにりました。
受託開発との違い
──受託と自社開発での大きい違いはありますか？
I：一番大きいことはプロモーションを自社で行う ということでしょうか。
いつもは受託開発ですのでその部分はあまり経験がなく、今現在大変さが身に染みているところです。
──開発方面での違いはどうでしょうか？
I：実を言うと開発自体は受託とそんなに大きく変わらないと思っています。
会社のHPにもありますが、もともと受託開発を請け負っていても、ただ指示通りに創っているわけではなく 「おもしろいと思ったものを提案しますよ」というスタイルでやっていたので。
現在のチームは少人数のチームなのですが、セクション問わず各々の意見を募ってトライできるのは良いなと思います。
T2：今創っているオリジナルゲームは一度テーマ変更しているのですが、変更前の元々の企画も今の企画もチーム全員で話し合って創りました。 まずは開発費と人数規模をしっかりチームで決めて、それに見合う企画を出し合います。
企画を出し合う為には何かとっかかりがないといけないなと思ったので、皆で好きなインディーズのゲームを話し合ったりしました。 最終的には8案くらいでていたかなと思います。 8案全部面白そうで、できることなら全部製品化したかったのですけれど、もちろん難しいので最後は「今自分たちがしっかりと開発できてコストに見合うものは何か」という観点で決定しました。
制作体制や期間
──現在の開発での工数や想定している期間など教えて頂きたいです。
I：大体21人月*1ですかね。
最短で半年くらいで制作しようと思っています。今年の秋冬くらいには…。
今回の開発にあたって工夫したこと
──開発にあたって工夫したことを教えて頂きたいです。
I：開発に使用する予定だったアセットが、ゲームのルールの仕様にあっておらず、 メンバーがアセットの仕様変更を行い使いやすいようにしたことです。 また、マルチプラットフォーム向けの検証も時間をかけて行っています。
今回の開発は「コストを抑えて、ゲームパフォーマンスを最大限引き出す」をテーマにしているのですが
こうして自分たちの手を使わずに作業できることを増やせばコストを抑えることにもつながります。
また弊社には社内基盤を整えるチームがあり、そのチームとも連携して新しいプラットフォームに対応してもらっています。
──開発を始めるにあたり一番最初に調べた技術的仕様はなんでしょうか？
I：まずはSwitchに関するスペックです。 解像度であったり、どのくらいのメモリが使えるのかであったり。
今まではスマートフォンのアプリ開発が多かったので、やはり違う部分は多くありました。 新しいプラットフォームで開発を行う際は、「これでどのようなゲームを表現することが可能なのだろう」と調べることが重要かと思います。
T2：あとは、各種サービスとの連携についても調べました。 ゲーム本体以外でも、どういった遊び方ができるだろうと。 幅広いお客様に色々な楽しみ方をして頂いて飽きない作品にしたいです。
スマートフォンゲームを創る時と比べて、苦労した点
──これまでの開発と比べ苦労した、大変だと感じる点はありますか？
I：先ほどもお答えした通り、新しいプラットフォームで開発するという事自体がとても大変です。
今までの、弊社でいうとアプリゲームが多いですが、それとは入力形式が全く違っていたり…
プランナーもエンジニアもお互い大変です。
T2：スマートフォンですと、タッチしたら反応するというインプットですが、コントローラーやキーボードだと入力したときのUI的なルールが複雑です。こちらもチーム全員と検証して考えました。
Steamですと、マウスで動くのかキーボードで動くのかパッドで動かすのか…パターンが結構あるので、ボタンの出し方などかなり時間を使って検証しました。大変でした…。
おわりに
やはり新しいプラットフォームで開発するということは、技術的な検証に多く時間を使い、様々なお客様に楽しんで頂けるような工夫が行われているようです。
引き続き、コンシューマーゲーム開発チームのインタビューを続けてまいりますので、次回も楽しみにお待ちください！
スマホゲームアプリを創る際に気をつけるべきポイント！複数アスペクト比率端末に対応する必要性について
目次
- はじめに
- 世の中にはどんな端末が存在しているか
- 簡単なレイアウトを考えてみる
- 実際にUnityでレイアウト設定してみよう！
- じゃあアンカーポイントをうまく設定すればなんでも解決するのか？
- +α レイアウトを考える際の更に厄介な問題！『ノッチ』について
- おわりに
はじめに
はじめまして！
アールフォースでクライアントエンジニアをやっております、藤田と申します。
弊社は近年Unityで開発を行うことが多いですが、それはiOS, Androidのマルチプラットフォームのスマホゲーム開発が容易に行えることが理由の１つにあげられます。
そんなスマホゲーム開発を行う際に、最初から意識できているかできてないかで大違いになる
複数アスペクト比率端末に対応する
という必要性について今回の記事ではお話させて頂きます。
コンシューマーや、PC向けに単一解像度でゲームを制作することしか考えてこなかった方にとっては中々興味深い話ではないかと思いますので、是非楽しんでいって頂ければ幸いです！
世の中にはどんな端末が存在しているか
まずは話を簡単にするために、端末提供元がAppleだけであるiOS端末について見て行ってみましょう！
今現在Appleからリリースされている端末の中から、アスペクト比が異なるものをいくつか羅列してみます。 (昨年、iPadは独自のiPadOSというものが搭載されるようになりましたが、ここではまとめてiOSとして扱わせてください)
| 端末名 | 画面サイズ*1 | アスペクト比 | アスペクト比の横÷縦 |
|---|---|---|---|
| iPhone5 | 640 x 1136 | 40:71(≒9:16) | 0.5633 |
| iPhone6 | 750 x 1334 | 9:16 | 0.5622 |
| iPhone6Plus | 1080 x 1920 | 9:16 | 0.5622 |
| iPhoneX | 1125 x 2436 | 375:812(≒9:19.5) | 0.4618 |
| iPhone11 | 828 x 1792 | 207:448(≒9:19.5) | 0.4618 |
| iPad系 | --- | 概ね3:4 | 0.75 |
主にアスペクト比に注目していただきたいのですが、基本的なサイズであるフルHDと比較して３種類のパターンに分けて考えることができますね。
- 16:9のフルHDサイズグループ
- 19.5:9の(16:9と比較して)縦長グループ
- 4:3の(16:9と比較して)横長グループ
それでは早速、まずは16:9端末であるiPhone6の縦持ち画面を基準に、 非常に簡単なレイアウトを考えてみましょう！
簡単なレイアウトを考えてみる
まず、画面のヘッダーとして戻るボタン
フッターとして進むボタン
中央にキャラクター画像(弊社マスコットキャラクターのファンくんです)
を表示しているだけの簡単なデザインを見て行ってみましょう。
このとっても簡単なデザインを、例えば何も考えずにiPad端末でも表示した場合、
実装によって次のどちらかのパターンになってしまうでしょう。
失敗パターン1
座標がそのまま固定されたままになってしまい、上下左右に余白ができてしまうパターン
失敗パターン2
画像が引き伸ばされて表示されてしまうパターン
しかし、本来なってほしいデザインは次の通りのはずです。
期待されるパターン
最初のiPhone比率のスクショと同じように
ファンくんは中央。他のボタンは同じように端に等倍で表示されていますね。
このようにスマホゲームを創るときは
複数のアスペクト比においてレイアウトが適切になるように考える必要があります。
これ、全部プログラムで制御しないといけないの？？
と思われた方もいらっしゃるかもしれませんが、そんなことはございません。
例えばUnityであれば、Unity標準であるUGUIというUIシステムに、こういった問題を簡単に解決してくれる機能があります。
ほんのすこしだけ見てみましょう。
実際にUnityでレイアウト設定してみよう！
まずは何も設定していない場合と、設定してみた場合でどのような違いが起きるのか
gif動画を見てみてください。
いずれも、1920 x 1080のフルHDレイアウトから、2048 x 1536のiPadレイアウトに変更してみたものです。
ちょっと画面外との区切りが分かり辛かったので、背景色を変えています。
何も設定していないもの
設定してみたもの
後者は良い感じですが、前者は画面中央寄りなままになってしまっているのでイケてないですね。
何をやったかというと、UGUIに属するコンポーネントには必ずついているRectTransformというクラスの中の、アンカーポイントというものを設定しました。
デフォルトだと、アンカーポイントは次のように真ん中に設定されています。
(左上に表示している戻るボタンのInspector上の表示です)
これを左上になるように設定することで、2枚目のgifのように
アスペクト比を変更しても自動で左上にくっついてくれるようになります。
このようにしておくことで、たとえどんなアスペクト比に変更したとしても
左上にくっついてくれます。アンカーポイント便利ですね〜。
今回の例はRectTransformとアンカーポイントの力としては触りも触りの部分です。 このアンカーポイントを制御する仕組みは今日のゲームエンジンであれば大体同じようについているはずですので、Unityに限らず一度しっかり身につけておくときっと役に立ちますので、是非勉強してみてくださいね。
じゃあアンカーポイントをうまく設定すれば
なんでも解決するのか？
というと、そんなことはありません。 例えばこんなデザインを考えてみましょう。
一番最初のレイアウトから、バランスを変に崩さない程度にファン君を拡大して上に若干詰めてみました。
これを単純にiPadのレイアウトに移行するとこうなってしまいます。
iPadで表示してみた
あまりにも下側に余白ができてしまいましたね。
これでは流石にバランスが悪くなってしまいます。
16:9のiPhoneだけで表示するなら良かったかもしれないレイアウトでしたが、
他のアスペクト比の端末のことを考えた場合、そもそもやってはいけないデザインだったということがわかります。
少し極端な例ですが、1つのアスペクト比で良い感じに表示されてるからおっけー！
と考えてしまうと、他のアスペクト比で表示した時にカバーしきれないということがわかったかと思います。
さて、ここまでの話はたったの2通りの端末にしか、それもiPhone端末にしか触れておりません。
実際にはいろんなアスペクト比のAndroid端末も発売されており、
スマホゲームを創る際には、その全てに対して適切に表示されるようなレイアウトロジックとデザインを考え、実装を行う必要があるのです。
+α レイアウトを考える際の更に厄介な問題！
『ノッチ』について
ここまでの項目では、とりあえず２種類のアスペクト比におけるレイアウト崩れの可能性に触れてみました。
しかし、現在のスマホにおいては更に考えなければならないことがあります。
皆さんもiPhoneX系端末を見たことがある、もしくは実際に使っているという人も多いかと思いますが、それより前の端末と比較して大きな違いがあることに気づいているでしょう。
そう、ノッチと呼ばれる部分のことです
左からEssentialPhone, Huawei P20, iPhoneX
Android端末においては、ノッチは正しくはDisplay Cutout(切り欠き)と呼ばれます。
iPhoneXが世にリリースされた後、世の中で求められているフルディスプレイに対する現状の最適解はこれだ！とばかりに、2018年頃から爆発的に広まったデザインです。
現在ではGoogleさんが、切り欠きは多くても２つまでにしてくださいねというお触れを
出してくださっているので、上に１つ。あるいは上下に１つずつ。というデザインが多いです。
ノッチの両サイド部分にも画面が表示されていることがわかると思いますが、
例えばこの部分にボタンが表示されてしまっていたとしたら、押しづらい、もしくはそもそも押せないボタンになってしまいますよね。
そうはならないように、例えばAppleはこのようなレイアウトガイドを公開してくれています。
UIを表示しても問題ない領域はセーフエリアと呼ばれます。
このセーフエリア領域外にはUIが表示されないようなUIロジックを考えることが、現在では非常に重要になっています。
アールフォースでも独自の仕組みを創って対応しているのですが、それはまたの機会でお話させて頂ければ幸いです。めっちゃ長くなりますけど！
おわりに
いかがでしたでしょうか？
スマホゲームアプリを創る際には、ただゲームの面白さを追求すればいいというわけではなく、考えなければいけない厄介な問題があるということを知って頂けたのではないでしょうか。
最近では折りたたみ端末とか、アスペクト比3:1の端末とか出てきて頭が痛くなったりもしますが、そういったものが出たとしても問題ないであろうUIロジックを考えることも、
スマホゲームを創る上での醍醐味のひとつです。
他にもスマホゲームアプリを創る際に考えなければいけないことはたくさんありますので、今回のような形でご紹介していきたいです。
ここまでお読み頂きありがとうございました〜！
すぐにできる「アイデアの出し方」
【はじめに】
初めまして。
株式会社アールフォース・エンターテインメント プランナーの阪本です。
好きなアニメのジャンルは「ポストモダンギャグ」です。
プランナーは会社で働いていると、
「なんかアイデア出してよ」と無茶ぶりされることが多々あります。
今回の記事では、
そんな時に使える「アイデアの出し方」をお教えします。
想定されるシチュエーションを3パターンご用意しました。
【なんか良いタイトル案出してよ】
【なんかヤバイ案出してよ】
【企画コンペやるからなんか考えてよ】
【なんか良いタイトル案出してよ】
「こんな施策やるんだけど、良い施策名ない？」
何か施策をやる時やゲームタイトルを決める時、
良いタイトル案ってなかなか出てこないですよね。
例えば「会社のオフィスを掃除する施策」の施策名、
パッと思いつくのはこんな感じでしょうか。
・みんなでお掃除し隊
・モーニングクリーンタイム
・毎日清掃！朝は早朝！
施策の目的となる「掃除」を連想させるタイトルにはなっていますが、
在り来たりでインパクトがないです。
では、インパクトのあるアイデアをたくさん出すためにどうするか？
①忘れる
一旦「掃除」を忘れます。
②別ワードを考える
次に「掃除」に類似するテキトーなワードを出します。
・集める
・学校
・一緒
・キレイ
③別ワードから別ワードを考える
テキトーなワードを英語や別の表現に変え、さらに類似したワードを出します。
・「集める」⇒ コレクション 収集家 トレジャー
・「学校」 ⇒ ハイスクール 学園 授業
・「一緒」 ⇒ トゥギャザー パーティ 団体行動
・「キレイ」⇒ ピカピカ 輝き 美しい
④ワードを組み合わせる
出てきたワードを使って、いい感じに組み合わせましょう。
正直これも先ほどと大差ないタイトル名ですが、
「掃除」と「学校」というテーマがマッチしており、
学生時代、掃除をしていた頃を思い出させる効果もあります。
とにかく箇条書きでも良いので、たくさんのワードを書き出すことが大事です。
完成までの過程も大切にしましょう！
【なんかヤバイ案出してよ】
「ゲームを面白くするヤバイ案なんかない？」
ゲームをより面白くする案を考える時、
良い案ってなかなか出てこないですよね。
例えば「リズムゲームを面白くする案」の場合、
パッと思いつくのはこんな感じでしょうか。
・リズムに合わせてキャラが踊る
・ノーツ*1タップ以外の操作を増やす
・マイクに向かって手を叩いて演奏
上記の案は、既に他のリズムゲームにあるものばかりです。
面白くなる可能性は十分にありますが、二番煎じになる可能性も高いです。
では、ヤバくなるアイデアをたくさん出すためにどうするか？
①忘れる
一旦「リズムゲーム」を忘れます。
②別ジャンルを考える
リズムゲーム以外のゲームを思い浮かべます。
・多彩なキャラが出てくるレースゲーム
・可愛い女の子が爆弾を置いて戦うゲーム
・様々な武器を使って地面に色を塗るゲーム
③面白い部分をピックアップ
そのゲームの面白い部分を思い浮かべます。
・アイテムを投げる
・爆発
・色を塗る
④リズムゲームを思い出す
それらをリズムゲームに無理やり組み込んでみます。
・タップしたノーツが飛んでいく
・タップしたノーツが爆発する
・タップしたノーツ周辺の背景色が変わる
⑤案を組み合わせてみる
組み合わせなくてもいいですが、何事も挑戦が大事です。
ゲーム中、敵に向かってノーツをふっ飛ばす
ふっ飛ばしたノーツは、着弾すると爆発して色をぶちまける
ぶちまけた色の面積によって敵にダメージを与える
もはやリズムゲームとは言えませんが、他のリズムゲームでは見たことないですよね。
「ノーツを敵に向かってふっ飛ばす」など、勢いを感じるモノは僕的には好印象です。
よくわからない案ができましたが、稀に良い案ができたりします。
大事なのは、アグレッシブさです。
【企画コンペやるからなんか考えてよ】
「企画コンペするけどなんか良い案ない？」
企画コンペをやるとなった時、
良い案ってなかなか出てこないですよね。
例として、数年前にApple Watchが発表された時、
急遽開催されたApple Watchの企画コンペの話をします。
事前にApple Watchの機能は発表されていましたが、
明確にどんなことができるかは、わかりませんでした。
そんな中、プランナーさん達が考えた企画案はこんな感じでした。
・未来体重計
・ウソ発見器
・疑似ペット育成
どれも備わっている機能を活用したステキな案でした。
しかし、最優秀賞には選ばれませんでした。
最優秀賞はなんだったのか
最優秀賞は、僕が考えた「犬にApple Watch」でした。
人ではなく、犬にApple Watchを持たせるという案です。
なぜ選ばれたかわかりませんが、ユーモアなところが評価されたと勝手に思っています。
実現するには難しいですが、機能もしっかり考えました。
・喋れない犬のかわりに、Apple Watchが犬の体調や異常などを共有
・災害時、人が通れない所を通り、Apple Watchで連絡手段を確保 等
なぜ「犬にApple Watch」？
まず、Apple Watchを人ではなく、別の何かにつけることを考えました。
そこで、ペットもApple Watchが欲しくなる時代がくることを見据えた結果、この案が誕生しました。
全く現実的ではないですが、できれば面白いですよね。
枠にとらわれず、自由な発想をしていきましょう。
【まとめ】
・軸（メイン）となる題材を一旦無視する
・的外れな案でもいいので、まずはたくさん並べてみる
・枠にとらわれない発想も大事
・流行りを取り入れる
9割以上ボツになる可能性はありますが、アイデアは出やすくなります。
たくさんの案を出したい人は、是非試してみてください。
*1:ゲーム中、リズムに合わせて流れてくるマーカーのこと
アプリ開発でのプランナー役割紹介
目次
はじめに
はじめまして、アールフォース・エンターテインメント(以下アールフォース)でプランナーをしています袖ヶ浦です。
アールフォースでは「ユーザーストーリー重視」「ユーザードリブン手法」*1という考えを大事にし、常日頃お客様重視で企画をつくっています。
そんな企画をつくる仕事プランナーについて本記事では、意外と知られていない(?)プランナーの仕事内容をアールフォースではどのように行っているか、その一部をプロジェクトの開発フェイズに合わせて簡単に紹介していきたいと思います。
またゲームプランナーの仕事は会社やプロジェクト毎に役割範囲や業務内容が異なることが多分にありますので、1つのモデルケースとしてこんなことやっているんだなぁと思って読んでいただけると幸いです。
開発フェイズ毎に異なる役割
ゲーム開発ではプロジェクトの進捗具合によっていくつかの開発フェイズに分けられます。 よく聞くα版やβ版、最近ではプリプロダクションやバーティカルスライスといった各フェイズが存在し、プランナーも基本的にこの開発フェイズに合わせて様々な役割を順次遂行していくことになります。
①プロジェクト化以前及び初期段階
- プランナーの役割：「企画書」の作成、そのプレゼンテーション
- キーワード：企画書、プレゼンテーション、ターゲット、ペルソナ、コンセプト
- ワンポイント：書類のまとめ方やテンプレは書籍やネットに参考が複数存在するので、まずは企画内容に合った形式を真似してアウトプットに慣れていこう
まずゲーム開発初期段階では、どんなゲームをつくるのか？ターゲットは誰か？どの位の売上が見込めるか？などを調べ思考し企画書としてまとめます。 プランナーと聞いてよくイメージされる仕事がこちらです。
弊社では業種問わず定期的に企画コンペを行っており、意見交換やレビューを行い、そこからプロジェクト化となる機会もあり、アイデア次第で夢の企画が通るかもしれない非常にやりがいのある仕事でもあります！
作成する形式については多種多様ではありますが、主にPowerPointやGoogleスライドなどのプレゼンテーションツールで作成されることが多く、ここでは物事をシンプルに分かりやすく伝えられる様に文字だけでなく図やイラストを用いて読み手に出来るだけ伝わるように心がけています。
②α版開発
- プランナーの役割：「仕様書」の作成、その運用、説明
- キーワード：仕様書、コミュニケーション、常に更新、共有連絡
- ワンポイント：確定仕様に更新があったら関係者に連絡を入れ、認識のズレを解消しよう
ゲームをエンジニアさんに実装してもらう為に、企画書を元に、より詳細を記載したゲームの設計図とも言える仕様書をまとめます。 仕様書は各画面でどんな機能がどう動くかを明記した資料になります。 大規模なゲーム程仕様書自体のボリュームが大きくなる為、機能や画面毎に仕様担当者も割り振りを行い、インゲームやアウトゲーム担当、強化成長画面やガチャ画面担当などに分け作業を行います。
また各機能を仕様化するにあたり、エンジニアさんと実装の可否や手法の相談、デザイナーさんとUIとしてどう見せたら良いかの相談などを密にこなすことで仕様としてのクオリティアップは勿論のこと、 各セクションにスムーズな作業進行をもたらすことができる為、プランナー採用で求めるスキル欄に「コミュニケーション能力」や、あると好ましいスキル欄に「プログラミングやデザインなど別セクションの知識」が書かれていることが多いです。
こちらも主にPowerPointやGoogleスライドなどのプレゼンテーションツールを用いて書面化されています。
この仕様書制作業務はゲームプランナーの仕事でも比較的大きな割合を占めている役割になります。
③β版開発
- プランナーの役割：ゲームデータの設定、及びその調整
- キーワード：レベルデザイン、ゲームサイクル、成長曲線、報酬設計、マップデザイン
- ワンポイント：型をつくることで、修正、量産の手順をできるだけ省こう
仕様が固まったら次にキャラクターの強さやステージの構成、ミッション内容といったゲームの各パラメータを入れていきます。 レベルデザインともいわれる部分で、ここの設定をミスると折角今までつくったものがパーになってしまいかねない大事な部分になります。 マスターデータと呼ばれるデータをまとめた専用参照シートを用いて、プランナーが各自設定したHPの上限値などの値を入力していくことでゲームに設定されていきます。 アールフォースでは最近GoogleSpreadSheetを使用してマスターデータの管理運用を行っています。
ポイントとしては数値の出し方は決して感覚値だけに頼ることなく、参考としている他ゲームの場合はどうであったかや、他機能との関係性を総合的に鑑みつつ計算式や曲線などを用いつつ出来るだけ型にはめた上で調整していくことで、狂いの少ないデータをつくっていきます。
この工程もゲームプランナーの役割では非常に大きな割合を占めています。
④テスト期間
- プランナーの役割：ゲームバランスの調整
- キーワード：テスト、デバッグ、QA
- ワンポイント：テストにしっかりと時間を割き、ゲーム全体を見渡そう
仕様実装が完了し、データ入稿後はゲームが意図通りに仕上がっているか、プレイしていて本当に面白いかをリリースする最後まで確認していくことになります。 各機能とデータが全て揃うことで今まで想定していなかった問題や発見が様々な部分で大小出てくる為、QAさんと連携を取りながら仕様バグの修正、データの再チェックなど行います。
またこちらフェイズ上③のΒ開発と分けましたが、データ調整やテスト作業自体は上記③から常に行い、トライ&エラーを繰り返し、よりよいバランスに仕上げていきます。
⑤リリース後運用
- プランナーの役割：イベント制作
- キーワード：イベント、KPI
- ワンポイント：開発時から運用を意識したデータつくり、機能設計を行い、テンプレ化しておこう
無事リリースを迎えた後は、運用フェイズに入ります。 プランナーとしては、イベントの開催に合わせ上記の③データの設定と④バランスの調整を各イベント毎に行っていくことになります。 イベント制作も近年ではハロウィンやエイプリルフールをはじめ、各社が季節に合わせたこだわりのイベントを提供するのも恒例となってきており、プランナーの腕の見せ所でもあります。
またリリース後は計測したKPI、お問い合わせされる内容、SNSなどの動向を元に、ユーザーが何を求めているのか？どこに不満をもっているのか？どうしたら売上を上げることができるかなどを、 適切に分析し対応していくことで息の長いサービスを提供していくことを目指します。
とあるプランナー1日のサイクル
ここでは実際に出社してから退社するまでのプランナー1日の動きを、少しだけ紹介したいと思います。
仕様書作成期間中の1日の例
- 10:00～11:00：業務開始の1時間は、メールやチャットのチェックや前日タスクの進捗確認、今日の作業予定の洗い出しなどを行います。ここは基本どのフェイズやプロジェクトでも変わりません。
- 11:00～13:00：機能Aを仕様書にまとめます。事前に必要な資料などはまとめておき、大枠から詳細へと仕様を固めていきます。
- 13:00～14:00：お昼休憩です。仲間と外にランチに出かけたり、コンビニ弁当を買い、YouTubeを流しつつイベント周回をして休憩します(笑)
- 14:00～15:00：午前にまとめた機能A資料を元に、プランナーチームで仕様打ち合わせを行いレビューや意見交換を行います
- 15:00～16:00：打ち合わせで上がった要望や矛盾や不整合を修正し、資料に再度落とし込みます
- 16:00～18:00：Aとは別の機能Bを仕様書にまとめます。
- 18:00～19:00：チーム単位で簡単な進捗報告会をデイリーで行い、情報の共有を計ったり、今後のスケジュール調整を行います。
このように扱う資料やデータが違うだけで、普通のサラリーマンと取り分け特別なことをしている分けではありません。 1つ1つの機能や設計、データに対してお客様にどう感じて欲しいのか、どうしたら喜んで貰えるかを丁寧に考え、 最終的に最高のゲーム体験を届けられるように、日々我々も勉強しながら取り組む毎日です！
おわりに
ということで今回は開発フェイズ毎のプランナーの役割と、1日のサイクルについてざっと簡単に説明していきましたがいかがだったでしょうか？
企画書つくりだけではないプランナーの役割を少しでもお伝えできていれば幸いです！ 次回のプランナー記事では実際のテクニックやノウハウなどを交えて、もう少し細かく紹介していきたいと思います。
ここまで読んで頂きありがとうございました。
*1:ゲームの画面や機能、システムに対してユーザーに「どう思ってもらいたいか、どう遊んでもらいたいか」ということを意識すること
アールフォース流！Unityチーム開発 ~アーキテクチャ編~
目次
はじめに
はじめまして、アールフォース・エンターテインメント（以下アールフォース）でエンジニアをしております波多野です！
今回はR-FORSCHOOLの第一回目のテック記事を担当させていただきます。
さて今回のテック記事のお題ですが、『アールフォース流！Unityチーム開発とは~アーキテクチャ編~』となっています。
ゲーム開発エンジンといったらUnityと言われるほどメジャーになりましたが、アールフォースでもUnityを使った開発がメインになっています。
そこでアールフォースではどのようにUnityを使ってチーム開発をしているのかご紹介していきたいと思います！
今回の記事では開発アーキテクチャについてご紹介します。
※このテック記事ではUnityの初歩知識を有していることが前提になっておりますのでご注意ください。
チーム開発で気をつけたいこと
Unityでの開発は自由度が高いです。
だからこそ開発時にしっかりとした開発ルールを定めなければ、各開発者が統一性のない開発を行ってしまいます。
その結果、
- 可読性の低いコーディング
- メンテナンス性の悪い実装
- 解決困難なバグが生まれる
といった開発に大きな影響を与えてしまうことがあります。
そこでアールフォースでは、より円滑にチーム開発を進めるためにどのような開発アーキテクチャでチーム開発を行っているのか、説明していきたいと思います。
主な開発アーキテクチャ
2020年2月現在のアールフォースのUnity開発では主にMV(R)Pパターンで実装を行っています。
MV(R)Pパターンとは簡単に説明すると一般的にMVPパターンとUniRxを組み合わせたアーキテクチャになります。 MVPパターンとは
- Model（データ ViewもPresenterも知らない）
- View (表示 ModelもPresenterも知らない)
- Presenter (ModelとViewの仲介役 ModelとViewを監視している)
に分けてプログラムを組むアーキテクチャになります。
概念図はこうなります。
UniRxは上記画像のModelの値の変更の検知に使用しています。
UniRxを追加した概念図はこんな感じです。
MV(R)Pパターンの詳細について記載していくと、それだけで記事が埋まってしまうので割愛させて頂きますが、実際にどのような感じでUnityの実装に落とし込んでいるのか説明していきます！
例） +10ボタンを押したとき、０の値が10ずつ加算されるSampleのMV(R)Pの実装例
/// /// @brief モデルクラス /// using UniRx; namespace RFORSCHOOL { /// <summary> /// モデルクラス /// </summary> public class SampleModel { /// <summary> /// カウント /// </summary> private ReactiveProperty<int> _count; /// <summary> /// カウントのプロパティ /// </summary> public IReadOnlyReactiveProperty<int> Count { get { return _count; } } /// <summary> /// コンストラクタ（初期化処理) /// </summary> public SampleModel() { _count = new ReactiveProperty<int>(0); } /// <summary> /// カウントを追加する /// </summary> public void AddCount(int count) { _count.Value += count; } } }
/// /// @brief ビュークラス /// using System; using UnityEngine; using UnityEngine.UI; namespace RFORSCHOOL { /// <summary> /// ビュークラス /// </summary> public class SampleView : MonoBehaviour { /// <summary> /// 加算するカウントの定数 /// </summary> private static readonly int AddCount = 10; /// <summary> /// 数字を表示しているテキスト /// </summary> [SerializeField] private Text _countText = null; /// <summary> /// +10ボタン /// </summary> [SerializeField] private Button _countUpButton = null; /// <summary> /// +10ボタンが押されたときのリスナー /// </summary> public Action<int> OnCountUpButtonClickedListener = null; /// <summary> /// 初期化 /// </summary> public void Initialize() { OnCountUpButtonClickedListener = null; _countUpButton.onClick.AddListener(OnCountUpButtonClicked); } /// <summary> /// +10ボタンが押されたときのイベント /// </summary> private void OnCountUpButtonClicked() { OnCountUpButtonClickedListener(AddCount); } /// <summary> /// カウントの切り替えが呼ばれる /// </summary> public void OnChangeCount(int count) { //カウント表示を切り替える _countText.text = count.ToString(); } } }
/// /// @brief プレゼンタークラス /// using UnityEngine; using UniRx; namespace RFORSCHOOL { /// <summary> /// プレゼンタークラス /// </summary> public class SamplePresenter : MonoBehaviour { /// <summary> /// ビュー /// </summary> [SerializeField] private SampleView _view = null; /// <summary> /// モデル /// </summary> private SampleModel _model = null; /// <summary> /// Start処理 /// </summary> private void Start() { Initialize(); } /// <summary> /// 初期化 /// </summary> private void Initialize() { _model = new SampleModel(); _view.Initialize(); Bind(); SetEvent(); } /// <summary> /// ViewとModelの紐付け /// </summary> private void Bind() { //Countの値に変更が入ったときにOnCountChangeが呼び出される _model.Count .Subscribe(OnCountChange) .AddTo(gameObject); } /// <summary> /// イベントを設定 /// </summary> private void SetEvent() { //+10ボタンを押したときのイベントをセット _view.OnCountUpButtonClickedListener = OnCountUpButtonClicked; } /// <summary> /// Viewから送られてきたカウントでモデルを更新する /// </summary> private void OnCountUpButtonClicked(int count) { _model.AddCount(count); } /// <summary> /// Modelのカウントが切り替わったときに呼ばれる /// 引数はModelのCountと同じものが返ってくる /// </summary> private void OnCountChange(int count) { _view.OnChangeCount(count); } } }
いかがでしょうか？
こちらの実装を概念図に当てはめるとこんな感じになります。
一見クラス数も多くなり、余計にややこしくなったのでは？と思う方もいると思います。
しかし各クラスに要素を分けることによって、作業者のコーディングに個性が出にくくなり可読性が上がり、拡張性も広がります！
それによって、コードのメンテナンス性が高まり開発速度も向上します！！
自由度の高いUnityチーム開発では、いかに各作業者の個性をなくすことが重要となります。
Model、View、Presenterと、役割を明確にすることで、バグが発生したときの早期発見、早期解決や新規機能の追加のしやすさに繋がります。
また開発アーキテクチャだけでなく、Inspector上からPrefabを操作したり、値を操作するときは[SerializeField]をつけるようにするなど、コーディング規約をしっかりと定めることも重要な要因となります。
終わりに
今回はMV(R)Pパターンの説明でしたが、これはUnity開発における一つの回答であって、正解というわけではありません。
開発の一つの手法として参考にしていただけると嬉しいです。
引き続きアールフォースの文化をガンガン発信していきますので、是非またR-FORSCHOOLに足を運んでいただけると幸いです。
ここまで読んで頂きありがとうございました。
アールフォース・エンターテインメント技術広報ブログ、始めました！
はじめに
はじめまして！
株式会社アールフォース・エンターテインメント広報担当です。
この度、皆さんによりアールフォース・エンターテインメントのことを知って頂きたいと思い、ブログを始めました！
会社での出来事に加え、月に１・2回のペースで弊社の現場社員によるテック記事も更新していきますので是非お楽しみに！
- アールフォース・エンターテインメントとは？
- R-FORSCHOOLって？
- なぜブログを始めたのか
- 今後予定している記事を少しだけご紹介
- 最後に
アールフォース・エンターテインメントとは？
株式会社アールフォース・エンターテインメントは日本国内大手パブリッシャーからの受託制作を中心に、333本以上のタイトルを開発している会社です。
そして2019年の8月には創立20周年を迎えることができました！
近年ではスマートフォンゲームの開発が多くなっておりますが、コンシューマーの開発経験はもちろん、今後はパブリッシングも行っていく予定です。
ちなみに画面に散らばっている緑の生命物体は弊社マスコットキャラクターの「Faun(ファン)くん」です。
R-FORSCHOOLって？
このブログのタイトルです！
株式会社アールフォース・エンターテインメントとスクール(学校)を混ぜてつくった造語になります。
「このブログをご覧いただいた皆様にとって学びの場になるように、また弊社社員にとっても【アウトプット、発信】の文化を創り積極的に学んでいけるように」 という想いから、運営チーム全員で考えました！
今年の5月、6月には弊社の現役社員による講演会も行う予定ですので、学校に遊びに来るつもりでいらして頂ければ嬉しいです！
なぜブログを始めたのか
前述したとおり、弊社は2019年に創立20周年を迎え、「新しいこと始めよう！」「挑戦していこう！」という目標をたてました。
そしてこの機会に、皆さんに弊社のゲーム創りや弊社で働く社員の魅力をお伝えしたいと思い、一念発起！ブログを始めることにしました！
広報からだけではなく、現場のエンジニア、デザイナー、プランナー、ディレクターなどなど様々な社員が発信していく場を作っていきますので是非、ご覧頂ければと思います。
今後予定している記事を少しだけご紹介
- アールフォース・エンターテインメントってどんな会社？(深堀バージョン！)
- プロの現場目線でみたUnity開発
- 社長に直接提案！「にこみ超会議」とは？
などなど様々な記事を月に３～４回のペースで更新していく予定です！
最後に
ここまでお読み頂いてありがとうございます。
まだまだ始まったばかりのブログですが、今後も頑張って発信していきますのでよろしくお願いします！
(良ければ「読者になる」等登録頂けると嬉しいです！)
