僕が考えた 最強のゲーム制作フロー Coading guu

目次 第1部 全体の流れをざっくり解説  企画  ゲーム企画の考え方  企画を詰める・文書化  設計  画面設計やり方  役割分担やり方  実装  見直し 第2部 ゲームシステムの考え方 じっくり解説  必要な機能を考える  機能を具体的に  機能をさらに分割  機能をグループ分け  機能を関数に  変数、関数をクラスに  公開する範囲を考える  クラスのグループ分け  クラス同士をつなげる  同じものは共通化する

第1部 全体の流れをざっくり解説企画

最強のゲーム制作フロー 企画 •案出し •企画を詰める •企画の文書化 設計 •画面設計 •クラス設計 •役割分担 実装 •ひたすら制作 見直し •バグ、エラーチェック •使用感の改善 •仕様変更

ゲーム企画の考え方 何のためにゲームを作る？ 誰が 私 30代の仕事で 疲れた男性 大人数で遊ぶのが好き な小学生 技術力向上 仕事忘れられるといい 簡単なルール 何を学びたい？ ローカルマルチゲーム 短時間で遊べる サーバを動かす 必要があるゲーム 爽快感があるゲーム ソーシャルゲーム的な 少ない操作で遊べる 白熱するゲーム

ゲーム企画の考え方 何を感じてほしい 吹っ飛ばした 時の爽快感 悲壮な世界への 苦い気持ち ステージクリア の達成感 UIとかのデザインを統一 ストーリが必要？ やりこみ要素が欲しい 死にゲーとかもあり 演出凝りたい 吹っ飛ばしたら何かよいことある？

おすすめツール  オンラインホワイトボード  思い付きを付箋で張っていく  共有しやすい  基本無料 https://miro.com/ja/

企画を詰める・文書化  コンセプトを文字にしよう  どんな気持ちになってほしいか入れておくのがポイント  ex:「逃げられない恐怖」→閉鎖的な状況になるようにしよう  ゲームジャンルの設定  どんなゲームなのか分かるように 企画の文書化も進めよう‼

企画を詰める・文書化 ゲームの仕様を決めよう  ゲームスタートからゲームクリアの流れは？  できるだけ詳しく  ゴール扉に入るとステージクリア → ゴールの扉にプレイヤーが触れたら、扉に入る動作をしてリザルト画面を表示 この時、プレイヤーは空中にいてもよい また、プレイヤーはいかなる動作中でもそれを中断し、 扉の地面に移動した後、扉にはいる動作を行う  認識の違いを減らす  ゴールの扉にプレイヤーが触れたら、扉に入る動作をしてリザルト画面を表示 →プランナーは、空中でゴールしたら、扉の前まで移動するモーションが入ると思っていたが、 プログラマーは、扉の前に瞬間移動すると思っていた

おすすめツール  オンライン上の共有スペース  素材や文書、URLの共有がやりやすい  様々なツールが使える  スプレッドシート  ドキュメント  miro などなど  基本無料 https://workspace.google.com/intl/ja/prod ucts/drive/

画面設計 ゲーム画面に何があるか決めよう  ゲーム画面は何がある  コマンド選択画面、攻撃画面、オプション画面などなど  画面はどんな遷移になっている？  コマンド選択画面から、ポーズ画面に遷移できるの？  特に、UIは念入りに設計しよう  設計したUIの配置をそのままゲームに持っていけるように

おすすめツール  デザインツール  画面に必要なパーツを作成しすいし、配置しやすい  共有しやすい  基本無料 https://www.figma.com/login?is_not_gen_0=true&res ource_type=team

クラス設計 どんなスクリプトを作る？ クラス同士はどういう関係？ クラス図を書こう 詳しくは、第2部で

おすすめツール  クラス図が書きやすい  共有しやすい  基本無料 https://www.drawio.com/

役割分担 どこの機能をだれが担当するか決めよう  大きな機能の塊ごとに分けるとよい  アウトゲーム、インゲーム、プレイヤー、ステージなどなど  いつまでにどの機能を制作完了するか決めよう  他の機能制作までに完成しておく必要がある機能があるかも

実装 ひたすら決めた仕様に沿って実装 確実に動くように、機能単体でテストはしておこう できた機能は、他のチームメンバーに見てもらおう 実装の考え方は、第２部で

見直し 実際に遊んでみよう 実施に遊んでみると、大抵バグ・エラーが発生したり、使用感が悪いなどの問題 が発生する 残りの時間を気にしながら、どこを修正するのか重要度を決めて修正しよう‼ 重要度  高い → ゲームプレイに深刻な被害を及ぼす  進行不能バグ、コンセプトから外れた機能  低い → ゲームの完成度に影響が少ないもの  発生度が低く、問題にならないバグ、あってもなくてもいいもの

第2部 ゲームシステムの考え方じっくり解説

お題とするゲーム 横スクロールアクションゲームを題材に考えていく プレイヤーの歩き動作を制作していく

必要な機能を考える プレイヤーは何ができる？ できることを書きだそう 歩く 走る しゃがむ ジャンプ 大きくなる 小さくなる 炎を投げる 泳ぐ ヒップドロップ 無敵

機能を具体的に 洗い出した機能を具体的にしていく 歩く 左方向の入力があった時に、 毎フレーム0.1(Unity座標)ずつ x座標を増加する 右方向の入力があった時に、 毎フレーム0.1(Unity座標)ずつ x座標を減少する

機能をさらに分割 機能を具体的にすると 複数の機能が含まれている場合がある 左方向の入力があった時に、 毎フレーム0.1(Unity座標)ずつ x座標を増加する 左方向の入力を受け取る 毎フレーム0.1(Unity座標)ずつ x座標を増加する

機能をグループ分け これまでの過程で生まれたたくさんの機能を 同じような機能同士でグループ化します 右方向の入力 を受け取る x座標を 0.1減少 マウスのクリック を受け取る スペースキーの 入力を受け取る 入力 座標変更 y軸を基準に 180度回転 y座標を 1増加

機能を関数に 機能を実際にプログラムにしていきましょう 数値や文字は、変数にしておきましょう(生のデータは避ける) const string HORIZONTAL_KEY_PARAM = "Horizontal"; float IsHorizontalKeyDown() { return Input.GetAxisRa(HORIZONTAL_KEY_PARAM); } void Move(float speed) { transform.position += new Vector3(speed, 0, 0); } 入力 座標変更

変数、関数をクラスに 1つのクラスには、1つの責任 作成した変数、関数をクラスにまとめるときには、複数の機能が入り込まないよ うに気を付けましょう public class PlayerInputReader: MonoBehaviour { const string HORIZONTAL_KEY_PARAM = "Horizontal"; float IsHorizontalKeyDown() { return Input.GetAxisRaw(HORIZONTAL_KEY_PARAM ); } } 入力 public class PlayerMover: MonoBehaviour { void Move(Vector3 direction, float speed) { transform.position += direction * speed; } } 座標変更

公開する範囲を考える どの機能を他のクラスが使うのか考えよう 特別な理由がない限り、基本はprivateな方がいい

公開する範囲を考える public class PlayerInputReader: MonoBehaviour { private const string HORIZONTAL_KEY_PARAM = "Horizontal"; public float IsHorizontalKeyDown() { return Input.GetAxisRaw(HORIZONTAL_KEY_PARAM ); } } 入力 public class PlayerMover: MonoBehaviour { public void Move (Vector3 direction, float speed) { transform.position += direction * speed; } } 座標変更

クラスのグループ分け 作成したクラスをプレイヤーや敵など カテゴリごとにグループ化しましょう PlayerInputReader PlayerMover Player

クラスのグループ分け 名前空間を使ってモジュール化しましょう 名前空間をつけるとプログラム上でカテゴリ分けされます namespace Player { public class InputReader: MonoBehaviour { // 省略 } } 入力 namespace Player { public class Mover: MonoBehaviour { // 省略 } } 座標変更

クラス同士をつなげる 作成したクラスは独立しています クラスをつなげるクラスを 作成しましょう namespace Player { public class Mediator: MonoBehaviour { [SerializeField] private Transform _transform; [SerializeField] private float _speed = 0.1f; [SerializeField] private InputReader _inputReader; [SerializeField] private Mover _mover; private Vector3 _forward => _transform.forward; pivate void OnValidate() { _transform = _transform ?? Transform; } private void Update() { if(_inputReader. IsHorizontalKeyDown >= 1f) { _mover. Move(_forward, _speed); } } } } クラスをつなげる

同じものは共通化する コードのコピはエラーの元 同じコードは書かないように共通クラスや共通メソッドなどにまとめましょう namespace Common { public static class UtilityData { public static float MIN_ROTATION = 0f; public static float MAX_ROTATION = 360f; public static float ClampRotation(float rotation) { return Mathf.Clamp(rotation, MIN_ROTATION, MAX_ROTATION ); } } }

おわりに これが最強のゲーム制作フローだー‼ 今回は全体的な流れをざっくり解説しました。 皆さんも自分自身の最強のゲーム制作フローを見つけましょう‼