最速で最も自分が遊びたいゲームを開発する方法（の妄想）
この記事について
タイトルの通りです。
前から考えてたことを先日ガーッと書いたので、ほぼそのまままとめます。
考えが変わったり具体的な方法が見えた段階で、随時修正していきます。
それぞれの方法論について、この記事が具体的に書いてるよってのあったら記事のコメントとか以下のツイートのリプとかで教えてください。
また、私は Unity でゲーム開発を行っているので Unity が前提の記事となっています。
自分が遊びたいゲームを掴む
まずここを掴まないと始まりません。
大きく求めるゲーム体験とストーリーの要素に分かれると思っています。
自分の場合であれば死闘を体感したいので、死にゲーになり、ストーリー面では分かり合えない同士が理解し合うストーリーが刺さります。
その組み合わせが作りたいゲームの基準になります。
私は、求めるゲーム体験を掴む一歩として、これまでプレイしたゲームを一覧にして、その中でもバイブルと呼べると感じるゲームを洗い出しました。その中の共通点が見つかれば、求めるゲーム体験が分かるはずです。
求めるストーリーについては、どのようなストーリーで心を打たれたかを整理します。
上述のように過去に見た映像作品や読んだ本などを洗い出して、どのような点に心を打たれたかの共通点を探すのも良いでしょう。
飽きに対応する
まず注意したいのは、自分が遊びたいゲームを繰り返しデバッグする中で、感動が薄れるのではという点です。
まず、繰り返しプレイしても完成して通しで遊べる際の感動はあると想定します。
その上で、デバッグプレイを少なくする方法を考えます。一つは、初期の段階からデバッグプレイを外注することで自分がプレイする回数を減らすことです。こちらの方法は費用もかかり、個人開発では厳しい可能性が高いです。
もう一つは難易度が高いがプログラムによる自動プレイテストやモンキーテストを都度実装することでコンピュータに代替させることです。こちらであれば、手間はありますが費用はかかりません。テストについては後述します。
最速で開発する方法を考える
作りたいものを定義した後は、いかに最速で作り上げるかを考えます。これは現状の人類の寿命が有限である以上、何本作れるかというタイムアタックであるということが大きいです。
そこでまず考えたいのは、規模が大きい必要はあるかということです。個人的な意見としては、自分が遊びたい内容を実現するのに大きな規模は必要ありません。
プレイ時間をいたずらに伸ばすほど体験やストーリーの純度が薄まると考えます。もちろん、叙事詩のように伝えたいストーリーに対して長い時間が必要となるものはあります。そのようなものは、長いプレイ時間であっても体験やストーリーへの感動が持続します。
まず、短く純度を絞って遊びたいプレイ体験やストーリーが実現できないかを考えます。
現代においては娯楽の可処分時間の貴重性は増していく一方であり、個人の 1 娯楽あたりの可処分時間を超えてしまうと、検討の土台に登れません。価格よりも可処分時間に収まるかを意識します。
最速で作り上げるということを考える上で、必要な作業を以下に分類し、それぞれの速度を上げる方法を簡易に記します。
粒度の大小・や抜け漏れはあろうが特に時間のかかるものについて優先的に述べます。
なぜ作り上げるという命題において、販売やサポートを取り上げるかというと、売上が重要であるからです。
これは、売上を上げることで開発をするスピードを向上するための投資資金が増えることになるからです。
なお、全ての作業のノウハウについては一定水準の教育や指導を有償で受けていることを前提とします。
企画
プレイ体験の設計
逆説的ですがプレイ体験を作るには、実際にプレイしてみるしかありません。
磨き上げは別途とし、欲しいプレイ体験を最小限で実現したゲームを作ります。
面白いと感じなければ、大胆に方向性を変えます。
また、以下は Amazon の例ですがプレスリリースをまず書くことで企画の方向性を具体化して手戻りを無くす手法も取れます。
ゲームのプレスリリースについては、以下の形式が参考になります。
上達の流れ
以下でプレイ体験を設計するための考え方を学びます。
『ゲームデザインバイブル』
脚本（ストーリー）の執筆
ここについては、速度を上げる方法が見当がつかないのが正直なところです。
『SAVE THE CAT の法則 本当に売れる脚本術』に則り、考えたプロットを他人に話した反応が芳しくなければ、思い切って捨てて次のプロットを書くという方法はあります。
しかし、あくまで売れる脚本を書くための方法です。本文章における命題は、最速で自分が最も遊びたいゲームを開発することです。ここにおいては、自分が読んで刺さるものがなければ、次のものを書くしか無いのかもしれません。
また、外部のアドバイスを有償でもらうのが早いかもしれません。
MENTA というサービスで、色々な分野のメンターを探すことができます。以下は MENTA で「脚本」で調べた場合の結果です。
AI に脚本のレビューをしてもらうのも有効そうです。
上達の流れ
上述の『SAVE THE CAT の法則 本当に売れる脚本術』については既に読みました。
また、具体的な脚本の書き方を学ぶために以下も追加で読みました。訳者が日本語での脚本の書き方を解説してくれています。
以降は、実際に脚本を描いていきながら MENTA で脚本のメンターを探してアドバイスを受けます。
開発
以下においてコーディングは、C#のコードを書くだけでなく Unity 自体の操作方法を含みます。
そのため、設計より前に来ています。
コーディング
Rider のような高機能な IDE の活用によるスピードアップや、有償での有識者とのペアプログラミングによる気づきが効果があると考えます。
Rider のことを知りたい場合は以下の書籍がおすすめです。
AI を活用したコード生成も有効ですが、ライセンスの問題や間違った内容に注意します。
なお、開発するゲームはオープンソースで開発するものします。
これは外部からの機能強化やバグ修正に期待してのものではなく、自分が遊びたいゲームのソースコードを公開することで類似のゲームが開発されて自分が楽しめることを期待するものです。
オープンソースとするのは、効率化のために作成したエディタ拡張なども同様です。
オープンソースで販売もしているゲームの例として以下があります。
また、一般的なオープンソースのライセンスを適用しつつも我々が販売する製品と同名または値段以下の値段で販売しないようにする条項を追加します。そうすることで、オープンソースとしつつも次の開発を効率化するための売上を確保します。
ただし、上記の Mindustry は GPL でライセンスされており、それでどのように販売を成立しているかは要確認です。
オープンソースとする場合に、有料アセットを使用することができない点が最も大きなデメリットです。
可能な限り内部で開発してオープンソースとすることで、今後の開発効率化に繋げたいです。
ただ、本デメリットについては相当に大きいため再考の余地があります。
例外として Unity 公式の無料アセットは再配布が認められているためオープンソースとして組み込むことが可能です。
Q17: アセットを組み込んだ状態でビルドなどはせずにプロジェクトごと配布しても良いですか？
(抜粋)弊社がパブリッシャーとして配布しているアセットで商用利用を禁じていないアセットに限り、その内容物を改変の有無を問わずプロジェクトに同梱して配布しても結構です。弊社がパブリッシャーとして配布しているアセットを改変せずに同梱して配布する場合には、meta データが更新されていないようにお気を付けください。弊社側で将来的に各アセットをアップデートした場合に上書きアップデートされるようにしてください。改変した場合には、別のアセットとして認識されるようにすることでユーザーの利便性を向上させるために、ファイルネーム / meta データ / シェーダーネームの全てを変えることをお勧めします。
また、エディタ拡張の開発はコーディング全般の効率化に有効です。
上達の流れ
私は以下の入門書をこなしたあとに、上記の MENTA でメンターを探しわからないことを都度相談しながら開発を始めました。
両方とも、新しいバージョンの本が出ている可能性があるのでご注意ください。
2 冊実施したのは、それぞれでカバーしている機能が異なったためです。
また、C#の理解が足りていなかったので以下を追加で今読んでいます。
『Unity 3D ゲーム開発ではじめる C#プログラミング』
以下は MENTA で「Unity」で検索した場合の結果を以下に貼ります。
後述の設計関連のメンターを探すのにも有効でしょう。
エディタ拡張の上達方については、知見がありません。
設計
設計開始前の有償での有識者との壁打ち及び設計中のレビューが最も有効と考えます。
設計の自動生成については有効な技術が乏しく、いかに手戻りを無くすかが重要です。
Unity での設計については以下の記事が参考になります。
上達の流れ
まず動かしながら具体的なデザインパターンを試すために以下をダウンロードして実行しました。
自分の現時点の理解では Factory パターンが何をしているかを理解するのが精一杯でした。
現在は、前述の「Unity における設計のパターン」内で勧められていた以下の本を読もうとしています。
『Adaptive Code ～ C#実践開発手法 第 2 版』
『Clean Architecture 達人に学ぶソフトウェアの構造と設計』
テスト
テストにおいて重要なのは、いかに早期にバグを発見して対処できるかです。
有効な方法としてテスト駆動開発を行うことです。
また、ユニットテストレベルだけでなくシナリオテストレベルについても自動化を図ります。
一般にシナリオテストは変更が多く、いわゆる壊れやすいテストと言われます。
一度自動化することで他のゲームを開発する際に基礎の流用ができ、長期的には効率化につながると考えるため自動化を図ります。
自動テストだけでなく自動化全般の考え方については、以下の講演がとても参考になります。
以下にモンキーテストとシナリオテストの自動化ツールの情報が記載されています。
DeNA が開発した Unity 向け自動テストツールがオープンソース化。運用における Tips をまとめた記事が公開される
上達の流れ
テスト駆動開発については、以下の書籍が良書とのことですがまだ読めていません。
『テスト駆動開発』
シナリオテストの自動化については、知見がありません。
パフォーマンス・チューニング
知見がありません。
上達の流れ
知見がありません。
アート（モデル）制作
2D モデルについては、賛否両論あるかと思いますがラフを書ける画力を有償で
身につけて AI の image to image で生成することが現時点においては効率的と考えます。
以下の記事が参考になります。
3D モデルについては、以下で再配布可能な 3D モデルを探すことが可能です。
ステージも探せます。
検索時にライセンスでフィルタリングする事ができるので、再配布可能なライセンスで検索を行うことで探せます。
また、ベースとなる物体を何らかの方法で取り込むことができれば効率化につながると考えますが知見がありません。
調べてみたところ、AI による 3D モデル作成はまだこれからのようですが進んではいるようです。
上達の流れ
私のゲームにおいては 3D モデリングが重要なため、3D モデリングについて記載します。
また、現在はオリジナルの武器を作ることに関心が深いためそちらについて特に記載します。
Blender のスキルを上げて 3D モデルを作成していきます。
Blender での 3D モデリングについて学ぶ場合、以下の講座を活用します。
もしモデリングの学習を進める中で行き詰まった場合は、作りたい武器のデザインを具体化するためにデザインスケッチから
始めることが良いかと考えています。
デザインスケッチについては、以下の書籍で学ぶようにします。
作りたい武器のデザインが表現できるようになったあとは、
以下のような Sci-Fi な武器をモデリングできるようになるのが目指すところです。
また、上記とは別にイラストを学ぶ際は以下のサービスがあります。
アート（ステージ）制作
スキルとしてはモデル制作と共通する部分もありますが、最終的に必要となるスキルは異なるはずですので別立てにします。
3D モデルを探せるサイトで、ステージが配布されていることもあります。
上達の流れ
ダンジョンの作り方という観点ですが、以下をまず読みます。
アート（アニメーション）制作
アニメーションはキャラクターの動きを指します。
アニメーションについては、どのような動きをするかを設計することとその動きを撮影することでフェーズが分かれます。
また、動きはイベントシーンの際の動きとアクションシーンの動きで分かれます。
イベントシーンでは以下のように動きとしての演技が求められます。
動きの設計については、映画などからどのような演技や動きを実現したいかを研究するぐらいしか思いつきません。
撮影については、モーションキャプチャの活用により効率化できる余地があると考えます。
私は以下の mocopi というモーションキャプチャを利用しています。
モーションキャプチャを使用せずにアニメーションを作成する場合は以下を使用することで効率化可能かと思います。
上達の流れ
演技については、以下の本を読みます。
その後、映画を見て研究を行います。
アクションの設計については、まず西洋剣術の本を読んで動きの設計の基礎を作ります。
その後に映画を見て実現したいアクションのイメージを掴みます。
アクションの撮影については自分が制作するのが VR 剣戟アクションであるため、そちらのアクションに習熟するのが上達につながると考えます。
思い通りの動きができるように、カメラで動きを撮影してトレーニングを行います。
西洋剣術を指導してくれる場所として、以下があり並行して指導を受けたいと考えます。
カメラワーク・ライティング
カメラワーク・ライティングについては、効率化することは難しく上達してスキルを高めることになるのが近道と考えます。
上達の流れ
カメラワークやライティング以外の要素も含みますが、以下を読んでいます。
『映像クリエイターのための完全独学マニュアル 不可能を可能にするテクニック〈撮影・録音・照明・ 構図・脚本・編集〉』
上記の本は映画撮影についての本ですが、Unity は現実を模倣可能なようにカメラや照明の設定パラメータが多いため、映画撮影の知見についてもメモしていきます。
- カメラの露出オーバーを使うことで、気分の悪さや方向感覚を失ったような感じを作れます
- 例としてはカジノロワイヤルの毒を盛られるシーンがあります
- シャッタースピードを早くすることで細かい雨の粒やほこりなどを拾う事が出来てリアリティのある絵を作れます
- 被写体の大きさを変えずに背景を拡大して手前に持ってくるためには後ろに下がってフレーム内でズームします
- レンズの絞り値を小さくすることで、背景のボケを大きくして人物が目立つ映画的な雰囲気を作り出すことができます
- 広角レンズを使うことでカメラが役者に近づいたり遠ざかったりする時に強い効果を発揮します
- 広角レンズを使うことで顔が外側に伸びる傾向があり、顔が丸く見えます
- 望遠レンズでロングフォーカスで撮影することで、 二人の距離が親密に見えます
その次に構図の理解のために以下を読みます。
『filmmaker's eye 第 2 版:映画のシーンに学ぶ構図と撮影術:原則とその破り方』
その後、VR は 1 人称なので、1 人称のグレイブエンカウンターズのような映画を見て参考になる構図を集めます。
サウンド（BGM・効果音）制作
BGM・効果音については、オープンソースの場合でも再配布可能な素材で代替できる可能性が高いです。
以下のサイトの音源は 23/02/20 時点で再配布が許可されています。条件変更になるかもしれないので、必要に応じてご確認ください。
また、AI 活用による作曲・効果音作成も考えられます。
初期のうちはそのように乗り切り、長期的には重要な部分については自分でサウンドを制作できるようにするのがよいでしょう。
ここは外にお願いするのか自分で作るのかの判断が難しいところかと思います。
上達の流れ
BGM を制作する場合は、DTM を学ぶことになるので以下のいずれかを受講します。
機器を揃える前に、Mac の Garage Band などで間に合いそうかを確認するのも有効と考えます。
効果音については、当面は素材を活用する方針で考えますが自作する場合は以下を読むことから始めます。
サウンド（ボイス）制作
ボイスについては演技指導とボイスチェンジャーの活用により幅広いキャラクターの声を
自分で録音することができるようになることが、最も効率が良いと考えます。
異性の声を録音したい場合は、音声変換を活用することが有効です。
また、海外対応を行う場合は最低限ボイスは英語を含めたいと考えます。
文法などは後述の翻訳で取り上げるとして、ボイスの観点では発音が重要でしょう。
上達の流れ
以下の、オンラインで声の指導をしてくれるサービスで声の演技を学びます。
その際、声の高さは音声変換で対応するとして変換して異性と感じられる発声の仕方を合わせて学習します。
男性が女性の声を出すための音声変換については、以下の教材で学びます。
英語の発音の上達について、自分はまだ試せてないのですが以下のサービスは有料ですが AI が発音の改善を提案してくれるアプリのようです。
翻訳
早さでいうと DeepL のような翻訳サービスを頼ることになりますが、顧客に意味の通る内容にするのであればチェックが必要です。
ファイルを読み込ませて編集可能な状態で取り出すには、DeepL の有料プランが必要になります。
また、以下のサービスに翻訳した文章を投入することで文法を修正してくれます。
可能であれば英語のスキルを長期的に積んでおいて、最低限自分でチェックができるとよいでしょう。
何かで読んだのですが、英語から他の言語に翻訳してもらう翻訳者は見つけやすいらしいです。
英語以外の精度を翻訳者に頼んで上げたい場合でも英語の精度を上げておくのが重要です。
上達の流れ
ここでは、AI の翻訳結果を読み解く力が求められます。
つまりは、単語の使い方や文法が不自然でないかのチェックです。
取り急ぎ必要なのは英語なので、英語について上達する必要があります。
今後のソースコードのコメントや技術的なアウトプットを全て英語にする方法を取れば、
普段のアウトプットの中で英語力を高められるのではないかと考えます。
販売
リリース前の宣伝
SNS や Youtube チャンネルを開設し、開発の過程を公開することで追加の時間をかけずに宣伝につなげます。
前述の通りオープンソースで開発する場合は、成果物を全て見せて構いません。
また、自分がプレイしたいゲームを実況することで、見込み客がチャンネル登録してくれる可能性があります。
上達の流れ
特に Youtube チャンネル運営を行いたくさんの人に観てもらうという観点では、動画編集やサムネイル作成が重要です。
本格的に学ぶ際は、MENTA でメンターを探します。
リリース作業
Steam などのストアへの登録を含みます。スクレイピングなどによる自動化は考えられますが、登録内容は都度変わると想定され難しいです。登録のノウハウをまとめて対外向けの記事としてまとめるのが関の山かもしれません。
上達の流れ
上達ではないですが、ストアへのアップロードを行った際に方法をまとめて記事として公開しておくことで、時間を空けてアップロードする際に自分の記事に救われるでしょう。
リリース後の宣伝
プレスリリースについては、前述の企画で作成しておけばマイナーチェンジで良いため大きく時間はかからないです。
SNS や Youtube チャンネルが一定の基準を超えている場合で、宣伝を主目的としてクラウドファンディングを行うということが考えられます。その際、先行プレイ権や進捗の先行公開など追加作業が発生しない報酬を設定するとよいでしょう。
上達の流れ
プレスリリースについては、実施する際に以下を読んで実践します。
クラウドファンディングについては、実施する際に以下を読んで実践します。
サポート
顧客の質問への回答
質問の多くは、進行困難である場合に発生すると想定します。
VR 作品においては機器のバリエーションが多く相性問題が頻発するため、各機器での動作確認はもちろんのことリグレッションテストが自動で走るようにすることが理想です。
操作不可能となる事象はモンキーテストの自動化によりできるだけ潰しておくのがよいでしょう。
操作方法が分からなくての質問については、操作解説をユーザが見なくても詰まりそうなタイミングで画面に操作説明が出る動作をデフォルトとすることで問い合わせ自体をなくしていく方法が考えられます。
本動作はオプションで任意にオフにできる他、ある程度進んだ段階でオフにするかを確認する仕様にするとよいでしょう。
上達の流れ
リグレッションテストやモンキーテストについては、テストの項にゆずります。
問い合わせを無くす件については、チュートリアルや詰まらないようにするのが巧いゲームを研究して、ポイントをリストアップします。
バグ修正（機能強化は開発に含む）
バグ修正において時間がかかるのはバグの再現であると考えます。
ユーザの同意を得た上で、バグ発生時のログを開発側に収集できる機能を備えておきます。
そのため、スタンドアロンのゲームであっても開発側のサーバへの通信機能を保持することが望ましいです。
常に取得すると容量が大きくなるため、ユーザがバグ報告を行うために実行するボタンを用意しておき、直近の時間のログのみを収集する機能でも良いでしょう。
上達の流れ
バグ発生時のログを開発側に収集できる機能の学習については、知見がありません。
メンターに質問するのが有効と考えます。
共通
上記以外で、ゲーム制作を行っていく上で共通で発生して時間を取られる諸課題を取り上げます。
各分野の学習に時間がかかる
上記の対策は膨大な学習時間の上に成り立っています。学習自体を効率化できればよいのですが、知見はありません。
上達の流れ
学習スキル自体を向上させる本として、以下があります。
『リファクタリング・ウェットウェア』
実現したいことを他人に伝えるためのコミュニケーションコストがかかる
全ての工程を個人として担当する、つまり個人開発とすることでコミュニケーションコストを無くすことを目指します。
ただ、リリース後に何らかの理由で開発者が開発できなくなった場合に、他の人がリカバリーできるようにメンテしやすいコードであることが求められます。
これは前述の設計やコーディングにおける対策を実施することが重要です。
上達の流れ
設計やコーディングの項にゆずります。
ノウハウが無いことによる迷いで制作が遅くなる
それぞれの開発者が自分が遊びたいゲームを開発しつつノウハウを共有してもらうために、会社組織の形を取り従業員として雇用してノウハウの共有を指示します。
無論、上記のオープンソースでの開発と同じ考えのもと、ノウハウは全て外部から参照できる形で公開します。
上達の流れ
ノウハウをわかりやすく効率的にアウトプットできるようになることを上達と捉えます。
アウトプットの方法としてはブログなどで行う際でも、技術書の書き方が参考になります。
以下で技術書の書き方を学ぶことができます。
YouTubeのvideoIDが不正です
給与決定のための評価の時間がかかる
上記の会社の形態を取ることによる副次効果ですが、給与決定のための評価には経営・従業員共に時間が取られます。
その時間を無くすために、給与は自己決定する制度か全社員役員含めて同一の給与とするかのいずれかの形態を取ります。
上達の流れ
給与を自己決定する会社の例として以下を読みます。
評価制度がない会社の例として以下を読みます。
人を雇う事になった際には、上記を参考にして給与決定ロジックを作ってみます。
インディーゲームを開発し始める前に
開発し始める前に『インディーゲーム・サバイバルガイド』を読んで注意点を把握することが有効です。
上達の優先順位
上記のうち、どの分野の上達を優先するかを整理します。
項目名の横に直近で行う内容のみを書いていきます。
日中のゲーム制作ができてパソコンが触れる時間においては、以下の優先順位で学習を行います。
現状は日中のゲーム制作時間のうち、30 分をアート（モデル）制作に、30 分を読書系に割くことにします。
- アート（モデル）制作：3D モデリングは今後ゲーム制作において多く時間がかかりそうなので、早めに習熟するようにします。Udemy の『【最初に学びたい】最新 Blender3.3LTS 3DCG モデリング集中講座 Part1』をやります。2D の絵の技術は必要に応じて習得します。
- 各分野の学習に時間がかかる：『リファクタリング・ウェットウェア』を読んで今後の上達方法を把握します
- プレイ体験の設計：『ゲームデザインバイブル』を読んで企画の作り方を掴みます
- コーディング：『Unity 3D ゲーム開発ではじめる C#プログラミング』を読んで開発の中で実践します
- 脚本（ストーリー）の執筆：先に同時に参考にするために、カメラワーク・ライティングで上げた本を読みます。自分が好きなストーリーの傾向を過去の好きな作品の洗い出しによって把握し、作品を見て心を動かされた部分や考えたことをスマホにまとめてから映画のことを書く資料にまとめます（後でどこかで公開します）
- アート（アニメーション）制作：演技については、『魂の演技レッスン２２』を読みます。アクションについては、『中世ヨーロッパの武術』を読みます
- 設計：『Adaptive Code ～ C#実践開発手法 第 2 版』を読んで開発の中で実践します
- テスト：『テスト駆動開発』を読んで開発の中で実践します
- カメラワーク・ライティング：紙で『映像クリエイターのための完全独学マニュアル』及び『filmmaker's eye 第 2 版:映画のシーンに学ぶ構図と撮影術:原則とその破り方』を読んで、ゲームづくりに役立てる点をスマホに書いてから本記事にまとめます。
- リリース前の宣伝：動画編集やサムネイル作成をメンターから学びます
- サウンド（ボイス）制作：声の演技のオンラインレッスンで学んだことの練習を行います
- アート（ステージ）制作 ※以降は優先順位低いため、一旦アクションを省略します
- サウンド（BGM・効果音）制作
- リリース後の宣伝
- リリース作業
- バグ修正（機能強化は開発に含む）
- 顧客の質問への回答
- 給与決定のための評価の時間がかかる
以下については、普段の開発作業の中で実施するようにします。
- 翻訳：ソースコードのコメントなども含めた文章的なアウトプットを、可能な限り英語で書きます。また、リリース前の宣伝の一環であるゲーム実況についても、可能なら英語で実施していきます。
残課題
- パフォーマンス・チューニングについてなにも書けてない
- 「脚本（ストーリー）の執筆」の上達のために直近行うことが決定できていない
- オープンソースにすることと有償アセットを使えないことのどちらを取るかを決めきれていない
- エディタ拡張、シナリオテストの自動化、イベントシーンの演技、プレスリリースやクラウドファンディング、バグ修正の上達方法の取っ掛かりがない
Discussion