Loadingloading
Visualworks-G G@ck
  1. ホーム
  2. 技術備忘録
  3. ゲーム開発効率化のススメ

化猫の生態

表紙-UX

ゲーム開発効率化のススメ

不思議とこの仕事を始めてからというもの、嬉しい(?)ことに新規タイトルの開発に携わることが多く、 幾つかの大型タイトルのリリースも見届けてきました。
しかし、新規開発に慣れているメンバーが不足していることもあり、無駄な作業の繰り返しや開発の遅延が頻発することは日常茶飯事です。
そこで今回は、プロジェクトを効率よく、かつ安全に運営していくための原則をご紹介します。 今回はかなりな長文です。最後までお付き合いいただければ幸いです。

1何を作るか決める

なにを当たり前なことをいっているんだ? と思われるかもしれませんが、 実はこれが出来ていないプロジェクトは非常に多いです。
何を作りたいのかが企画の段階で曖昧なために、開発を進めると次々と問題が発覚して、 開発が頓挫したり、遅延したりするのです。

作りたいものは何ですか?

例えば、家を建てようと思ったときに『どんな家にしようか』 というのは誰でも考えることだと思います。 Houser シンプルモダンな現代風や、最近流行りの北欧風。外壁の色はどうしようか?木造にしようか、コンクリートか?(予算の都合もあると思いますが)
特にこだわりたいひとは、どんな家にしたいかの 具体的なイメージまで思い描くことでしょう。

モノづくりの現場において、この ”最終的な完成系のイメージ” というのはとても重要で、 ゴールが見えているかいないかで プロジェクトの成功が大きく左右されます。 build

ゴールの見えないマラソンなんて走りたくない!

目的地を決めずに船出すれば遭難します。設計図がなければ家は建ちません。ゴールが見えず、いつまで走り続ければいいのかわからない状態で全力疾走なんてしていたら、すぐにスタミナが切れて倒れてしまいます。
最終的に出来上がる完成予想図を明確にしておくことで、全員が目指すべき目標を見失わずにすむので、プロジェクトはスムーズに進みます。

到達目標を決めるだけで開発メンバーは不安を抱かなくなり、モチベーションの維持にも繋がるのです。
開発が長引きそうならチェックポイントを設けましょう。「つぎはここまで!」という中間ゴールが見えているだけで心理的なストレスは軽減されます。 marathon いきなり作り始めないで、まずはゴールを決めましょう。

2コンセプトを決める

どんなゲームを作るか? が決まれば、自然とゲームシステムや世界観などが見えてきます。
剣と魔法のRPGやSFシューティングなど、より具体性を持ったイメージを作ることは、プロジェクトを効率よく進めるためのガイドラインになります。
開発中に迷ったり、立ち止まることがあっても、予め定めたルールに則って軌道修正すればゴールには必ず辿り着けるのです。

コンセプトはすべての原点

ゲームの世界観やキャラクターデザインなど、グラフィック(見た目)の指針になる ファンタジー作品ひとつとっても ダークなものやコミカルな冒険譚など、テーマによって世界観やデザインは大きく変わります。
コンセプトでテーマを定義することでデザインやストーリーが作りやすくなります。 fantasy ゲームシステムやレベルデザインなど仕様全般を決定する際の指針になる コンセプトに沿って作られたゲームシステムは、一貫したUXをユーザーに提供し、ゲーム全体の構造をイメージしやすくしてくれます。 不自然な機能の付加などが起こりにくくなります。

ターゲットユーザーやシナリオを想定したゲームデザインの指針になる 誰に向けて作るサービスなのか? はコンセプトが明確に定義できるものなので、ユーザーシナリオやイベントを作る上で分かりやすい基準となります。 target エンジニアリングにおける機構や構造化の意思決定に大きく関わる どんな機能がゲームに必要で、どんな構造をしていれば、ゲーム進行上最適なのか? がコンセプトにより定義されるので、 必要な用件を満たせるデータ構造やプログラムの機構を考えるうえでの判断材料になる。

開発中の疑問や想定外の問題に対処できる明確なルールになる 目指すべきゴールと従うべきレールがしっかり見えていれば、迷っても混乱することはなくなります。 errorimage コンセプトとはゴールを見失わないためのレールです。一度決めたコンセプトは絶対に変えてはいけません!

コンセプトが不十分で無理やり推し進めるとどうなるか?

  • コンセプトが曖昧なので 開発メンバーは何を作ればいいのか 解らなくなって、いずれプロジェクトが暗礁に乗り上げる。
  • 何をするゲームなのか解らないものが出来上がり、普通に面白くない。
  • 作って、壊してをひたすら繰り返すので、 永久に作り続ける負のスパイラルに陥る。開発期間が無尽蔵に伸びていく。

アクションゲームを作っていたはずが、気づくとパズルゲームになっていた・・・なんてこともよくあります。。。 当初の設計プランが崩れるのも当然ですよね。作り直しです。そうならないようにコンセプトの掘り下げはしっかりと行っておきましょう。 standbyme

3仕様決定&UX設計

ソーシャルゲームの開発はコンソールに比べると非常に早いですが、アプリ開発に移行してからはだんだんと開発期間が延びてきているのが現状です。
原因としては、ブラウザゲームのように頻繁に更新ができないため、一つの完成品として作品を作りきらなければリリースできないことが挙げられると思います。
そのため開発を始める前に、できるだけ詳細な仕様とUIUX設計を用意しておくことが重要になってきます。

細部にこだわる前に全体設計

ゲーム開発の場合、メインの機能を中心にゲームサイクルを形作る個々の機能を考えていくような方法をとることは多いですが、メイン機能ばかりに目が向いてそこだけをひたすら掘り下げてしまうと、全体設計のフェーズに入ったときに、うまく繋げられなかったり、思わぬ矛盾や問題に気付くなど非常に苦労します。 chess 『とりあえずメインの機能だけ作ってみる』という方法は袋小路に迷い込む要因になりえるのでやめたほうが無難です。

料理するには材料とレシピが必要

作る料理が決まってもレシピが無いと材料調達すらできません。
レシピ【仕様書】 を書くことで 必要な素材【UIやSE】 を厳選し、 調理工程【ワークフロー】 を整理できるので、作業を始める前に必ずレシピは用意しましょう。
curry 調理(開発)開始後のメニュー(仕様)の変更は作り直しか、中断を意味します。
変更内容があっさり決まれば続行できますが、多くの場合はその状況下で試行錯誤を始めてしまうので最悪の場合、中止に追い込まれます。

開発開始前にある程度 詳細な仕様とUIUX設計をしておくことで、大きな問題には気づけるので無駄なビルド&スクラップを省けます。
開発中に気づく問題点もありますが、クリティカルなバグは事前に潰しているので、遅延や中断が発生しにくくなります。

準備はいいか?いや、ちょっと待て!

開発が始まると、実はあれもこれもと後出しで機能追加が増えていくことがよくあります。
こうなると、初期の設計が狂ってしまう上に内部的な構造やゲームサイクルが繋がらなくなるなど、製品としてのクオリティが担保できなくなっていきます。
既に作ってしまった機能に対して改造を行ということは、コンセプトレベルから丸ごと見直す必要が出てくるため、場合によっては作り直し。最悪開発中止です。
やりたいことは始める前に全部だす!ことがとても重要です。 deel

後の追加を想定して作っておくことが大事なのですが、いざ開発が始まると見積もりが甘くて想定以上のボリュームだった。という事態に陥ることがよくあります。
これは追加内容がゲームサイクルに深く関わるほど顕著に顕れます。
このあたりは経験則からくる感覚が大きいので判断が難しいのですが、思いついた時点でできるだけ詳細まで詰めておけば回避できます。

現状維持のための中途半端な改修で本来想定したUXをユーザーに提供できなければ開発自体が無意味です。
既存機能との整合性をとるためのトライ&エラーや他機能の圧迫などが発生すれば、開発延期や中止を招く要因になります。jenga 全ての機能を網羅した上で、具体的な内容を考慮し、それらに耐えうる拡張性を持たせた設計にしておくのが最も賢い方法です。

事前の準備をしっかりしておきましょう。無計画に走り出して迷子にならないように。

4プロトタイプの制作

さて、ここまで綿密な事前準備を色々としてきましたが、実際に物を作り始めてから気づく問題や改善点はやはり出てきます。そこでまずはプロトタイプを作ってみましょう。 特に新規開発の場合はあらかじめ見本を作っておくことで、作業の流れや問題点などを前もって確認しておくことができるので大切です。

いきなり製品版は無理

仕様の精度がよほど高くなければ、いきなり製品クオリティを目指すのは無理です。
ここまで行ってきた事前の準備はあくまで脳内イメージです。
具体的にものづくりをしていくと見落としていたことや、書類上では見えなかったことが出てくるのは仕方がありません。
この段階で細かい部分まで突き詰めて作ろうとすると試行錯誤が始まってしまうので大幅なタイムロスとなります。
この段階では全体の流れを把握するだけの ”モックレベル” で留めておきましょう。 puzzle
主要機能だけ作ってもダメ とにかくまず主要な機能だけ作りたい!・・・のはわかりますが、何度も言うように危険です。やめましょう。
プロトタイプでいいものができていたのに、リリース版に向けて他の機能を盛り込んだら、プロトタイプのいいところが全て削られてしまった。といった事態を何度も経験しました。

プロト時点で考慮されていなかった機能を開発開始後に無理に入れようよした結果、既存機能と辻褄を合わせるためにすでに出来上がっていた”いいところを食いつぶしてしまう”ありがちな失敗パターンです。
一部分だけ掘り下げるのでなく、全体のバランスに常に気を配りましょう。

UXもきちんと設計しよう

プロト開発をエンジニアとプランナーだけで進めて、プロト終了後にデザイナーがアサインする。という流れがよくありますがこれも危険なフローです。
UXの専門家がプロトに関わっていないので、出来上がったプロトタイプにユーザビリティが全く考慮されていないのです。
後付け的にUXを付与しようとすると、内部構造や画面仕様が邪魔をして最適なUXが提供できなかったり、UIありきの操作でありながらUIを組み込む余地がなかったりするので、ユーザビリティ向上のためにせっかく作ったプロトを崩壊させてしまいかねません。
それでいいものに仕上がれば問題ないのですが、たいていの場合はゲームが壊れてしまうので意味がありません。 gear 開発の初期段階からきちんとUXの専門家を招いてユーザビリティを考慮しておけば無駄を省けます。

UX不在のプロト開発

最近はアプリも3Dが主流になってきましたね。
プロト開発時にP/Eに3Dアーティストを加えた3者体制での制作が増えてきました。しかしここにもUXデザイナーが不在。
3Dの場合、カメラのアングルやズーム率、ライティングの都合など、ちょっとした修正でも大きな工数がかかるので、アーティストだけで画面構成を決めてしまうのは危険です。
また、3DオブジェクトにUIの機能を持たせるといった工夫も可能になるので、UXの専門家を交えて3Dビューの仕様を策定していくのが安全なワークフローになるでしょう。 3D


最後に必ず出来上がったものをチェックしましょう。作って満足。とはならないように。
思い描いていたイメージに近いものができそうか?必要な機能は揃っているか?ゲームサイクルが正しく繋がっているか?回りそうか?サービスとしてきちんと完成できそうか?などなど。
モックでつまらないものはどんなに精度をあげてもつまらないです。
この時点で上手くいかなかったり、つまらなかったら、それは企画がよくない証拠です。
いきなり完成品を目指すのではなく、段階を踏んで徐々に制度を上げていきましょう

5ワークフローを整理する

事前の準備が整ったら、いよいよ開発開始です。でも、ちょっと待ってください。
プロジェクトの規模が少人数なら、常に相談しながら進められるのでそれほど大きな混乱は起こらないかもしれませんが、 50人以上の中~大規模開発となると、意思疎通が難しくなり、連絡ミスなどヒューマンエラーが発生しやすくなります。 作業を始める前にワークフローを整理しましょう。

マイルストーンを確認する

会社の制作体制や組織作りによって違いはあると思いますが、主にWEB開発から始まった会社では、ゲーム作りのワークフローが確立されていないことが散見されます。
私の経験上、開発メンバーが50人を超えると、きちんとしたルールがないプロジェクトでは 開発が迷走し始めるので、 ここでは50人~100人規模の開発におけるワークフローをご紹介します。 flow

ポイントは各フェーズごとにしっかりと確認をとること。
作業内容が職域で区切られているので、次の作業に移行する前に出戻りが発生しないよう最終チェックと意思統一をしておくことが重要です。

全員が同時に違う作業を行うので、作業をマニュアル化していかないと混乱してしまうわけです。
工場の生産ラインに似ているかも知れません。

関わる人数が増えるほど厳密なルールが必要です

6まとめ

事前の準備と計画が何よりも重要です。
そしてルールをきちんと整備して全員がその決め事を順守することで、ようやくプロジェクトが効率よく回り始めます。

  1. 何を作るか決める
    コンセプトを決定する
  2. 仕様を決定する
    UIUX設計をする
    エンジニア開発の仕様決定
  3. 仕様/UI/エンジニア 全体を俯瞰して確認
    開発前チェック
    すべて揃っているか確認
    後の追加項目を考慮した構造化を準備しておく
  4. ワークフローを整理する
    チーム開発においてのルール化
  5. 開発開始!
    新規開発の場合はプロトを作成
※機能追加や仕様の変更は2のフェーズからやり直します※

事前の準備をしっかり行い、メンバー全員でチェックする。
フローとルールを整え、常にホウレンソウを心がけましょう。
安心安全なプロジェクト運用で効率的な開発を目指しましょう。

さいごに

『作ってみなきゃ、解らない。』というセリフを開発現場ではよく耳にしますが、私はこのセリフが大嫌いです。

クリエイターである以上、どんなものが出来上がるのか話を聞けばある程度想像できます。
既に完成している機能に対しての調整や触り心地のチェックなど、チューニングレベルでの話であれば理解できるのですが、 まだ実装すらされていないものに対して  ”その機能を入れることでユーザーがどう反応するのか。どういった使われ方をするのか。プレイサイクルがどう変化するのか” などということに対して、やってみなきゃわからない というのは、想像することを諦めてしまった愚かなセリフだと私は思っています。 hint

デザイナーだろうと、エンジニアだろうと、プランナーだろうと、ゲーム開発に携わる人間は皆クリエイターです。
クリエイターにとって想像力は必要不可欠な能力です。
常に想像力を磨き続けることはクリエイターにとって最低限の礼儀であり、義務だと私は考えています。

想像することを辞めてしまった時点でその人はクリエイターではなくなるのだと私は思います。

最後までご覧いただきありがとうございました

PVアクセスランキング にほんブログ村

ARCHIVES