リフスロー　コードレビュー リフスローチーム 和泉　真 西村　和晃

お題目 計画的なお話 技術的なお話 改めてプロトタイプについて リフスローでどうなったのか 気をつけるべきこと リフスローの良かった点の解説 リフスローの悪かった点の解説

担当：和泉真 前半 　～計画的なお話～

改めてプロトタイプについて ゲームの動きを見るためのもの プロトタイプ　≠　メイン 使い捨て

リフスローでどうなったのか ゲームの動きを見るためのもの プロトタイプ ≠ メイン 再利用するかの判断、実際に移動 成功 移行時期で大失敗 プロトタイプ　≠　メイン 移行時期で大失敗 再利用するかの判断、実際に移動 同上の理由で大失敗

気をつけるべきこと プロトタイプであるという意識 メインへの移行計画を具体的に そのクラスは他で利用できるのか？ チーム内での仕様を徹底して把握 ちなみに メインで利用しないプログラムでも、 取っておいた方が良いです

担当：西村和晃 後半 　～技術的なお話～

ここからの流れ 良かった点 入力判定の統一化 データベースの使用 ステージエディタの作成 悪かった点 時間配分 ベース関数説明・リファレンス

リフスローPGの大まかな流れ 初期化処理 ・入力デバイスから入力を受け取る ・モデルや画像を動かす ・データベースの内容を更新する ・ステージ処理からの要望で、新しいステージを作る ・ステージ処理からの要望で、ゲームを終了する ・モデルや画像を動かす ・モデルや画像を描画する ・音を鳴らす ・新しいステージを作るようベース処理に要望する ・ゲームを終了するようベース処理に要望する ベース処理 ステージ処理 終了処理

入力判定の統一化 リフスローの入力仕様 これらをどう処理するか？ キーボード・ゲームパッド両方に対応 キーコンフィグに対応　結局実装できなかったけど… これらをどう処理するか？ (キーコンフィグ設定をこれからの入力判定に反映させる); if(キーボード判定||ゲームパッド判定){ … }

入力判定の統一化 リフスローでは 入力処理を受け取るための専用クラスを 設計（CInputクラス） キーボードからの入力を受け取って保存 ゲームパッドからの入力を受け取って保存 キーコンフィグの設定を受け取って保存 テーブル処理で、必要な時に設定を参照 1フレーム前の入力情報も保存 「今押したか」「前から押されてるか」の判定が可能

入力判定の統一化 そしてどうなった if文一つで完全な入力判定が可能に 入力デバイスによって判定回数を増やす 必要がない！ キーコンフィグはどんな設定になっているか？ キーボードはどのキーの入力を調べるか？ ゲームパッドはどのボタンの(ry キーボードの方ではキーは押されているか？ ゲームパッドの方ではボタンは(ry 今押した？前から押されている？ 入力デバイスによって判定回数を増やす 必要がない！

入力判定の統一化 こんな感じ BTN1が今押された BTN2が押されてる Bボタンが押されてる ゲームパッド 入力クラス メイン処理 押されたよ！ Zキーが今押された キーボード キーコンフィグ Type Key Pad BTN1 Z A BTN2 X B UP ↑ RIGHT →

入力判定の統一化 入力判定はゲームの根幹 入力の仕様はとても重要です 入力が受け取れないゲームなんて無い まともな操作もできないゲームは論外 つまり・・・ 入力の仕様はとても重要です できれば最初に実装しておきたい箇所 必要であればキーコンフィグも実装 あとで仕様変更の無いように！ ※ここの内容は、キーコンフィグ以外FKUTにも実装されています

データベースの使用 1つのモデルには複数の変数が必要 ゲーム全体で反映される値もある 管理がめんどくさい！ fk_Shape fk_Model fk_Material CMotionCharactor ゲーム全体で反映される値もある 音量設定 管理がめんどくさい！

データベースの使用 リフスローでは 「データベース」（以下DB）を作成 用途に応じた複数のDBが存在する modelDB（モデルを扱う） graphDB（2D画像を扱う） effectDB（エフェクトを扱う） soundDB（BGMやSEを扱う） configDB（各種設定を扱う） systemDB（システム系操作を扱う） rankingDB（ランキングデータを扱う）

データベースの使用 modelDB 大半のモデルはmodelDBに登録 モデルをいじる時は モデルの後片付けも全部お任せ！ 用意された関数を使う モデルのポインタをもらう　ホントはよくないけど… モデルの後片付けも全部お任せ！ DBの中ではこいつが一番活躍しました

データベースの使用 graphDB effectDB 2D画像の処理に特化したDB エフェクト（3D画像）処理に特化したDB まあfkut_SpriteModelがあれば十分だけどね… effectDB エフェクト（3D画像）処理に特化したDB カメラ「こっち向いて～」 関数1つでカメラの方へ！面倒な計算不要！

データベースの使用 soundDB configDB BGMとSEを扱うDB 音量を一律で変更 オプションで設定した内容を持つDB 音量設定 フルスクリーン設定

データベースの使用 systemDB rankingDB 細かな処理を担当するDB ランキングデータを持つDB フェードアウト・フェードイン カメラモデルのポインタを渡す fk_Sceneのポインタを渡す rankingDB ランキングデータを持つDB 実装には至りませんでした

データベースの使用 変数の管理はしっかりと！ むやみな変数の宣言は混乱のもと ややこしい変数や関数は全部クラス化 変数を管理する専門の人を作るのも良い

ステージエディタの作成 ステージを作るには コードに数値をガチ打ち とりあえず txt or csv ステージエディタ やめてください まあ多少は楽だけど… ステージエディタ こっちの方が楽だよね

ステージエディタの作成 リフスローでは フィールドを3次元のマス目で表現 ブロックが存在するマス目を保存 読み込み時マス目から実際の座標へ変換 7 6 5 4 3 2 1

ステージエディタの作成 管理しやすい保存ルールを！ 特に大量のステージを作る時に有効 1行目にはエディタのver.を 2行目にはプレイヤーの初期座標を 3行目以降にはブロックの座標を 特に大量のステージを作る時に有効 プレイヤーにステージを創作してもらう 時は必須

悪かった点 時間配分 ベースを作るのが遅かった ベースは早めに作ろう！ 一通り作り終えたのが7月中旬ごろ しかもバグが多発 プロトタイプから移行する時の障害の一因に ベースは早めに作ろう！ ベースを作る人のペースがその後の作業全体に影響します

悪かった点 ベース関数説明・リファレンス 何もかも説明不足だった 他人のコード程分かりにくいものは無い 「この関数はどうやって使うの？」が数百回 用意した関数が活躍できなかった 他人のコード程分かりにくいものは無い 詳細な説明が必要です コメントだけでなく、実際に使っているサンプルプログラムなどがあるとすごく良い

最後に プログラムの腕はほぼ経験で決まる 泣いても笑っても、ゴールは来年9月 どれだけゲームを作ったか？ どんなゲームを作ったか？ どんなライブラリを使ったか？ どんな人たちと一緒に作ったか？ 失敗も成功も全てが経験！ 泣いても笑っても、ゴールは来年9月 悔いの無いゲーム制作を！

ご清聴 ありがとうございました