リフスローコードレビューリフスローチーム和泉真西村和晃お題目  計画的なお話 ◦ 改めてプロトタイプについて ◦ リフスローでどうなったのか ◦ 気をつけるべきこと  技術的なお話 ◦ リフスローの良かった点の解説 ◦ リフスローの悪かった点の解説担当：和泉真前半～計画的なお話～改めてプロトタイプについて  ゲームの動きを見るためのもの  プロトタイプ ≠ メイン  使い捨てリフスローでどうなったのか  ゲームの動きを見るためのもの ◦ 成功  プロトタイプ ≠ メイン ◦ 移行時期で大失敗  再利用するかの判断、実際に移動 ◦ 同上の理由で大失敗気をつけるべきことプロトタイプであるという意識  メインへの移行計画を具体的に  そのクラスは他で利用できるのか？  チーム内での仕様を徹底して把握   ちなみに メインで利用しないプログラムでも、取っておいた方が良いです担当：西村和晃後半～技術的なお話～ここからの流れ  良かった点 ◦ 入力判定の統一化 ◦ データベースの使用 ◦ ステージエディタの作成  悪かった点 ◦ 時間配分 ◦ ベース関数説明・リファレンスリフスローPGの大まかな流れ初期化処理・入力デバイスから入力を受け取る・データベースの内容を更新する・ステージ処理からの要望で、新しいステージを作る・ステージ処理からの要望で、ゲームを終了するベース処理ステージ処理終了処理・モデルや画像を動かす・モデルや画像を描画する・音を鳴らす・新しいステージを作るようベース処理に要望する・ゲームを終了するようベース処理に要望する入力判定の統一化  リフスローの入力仕様 ◦ キーボード・ゲームパッド両方に対応 ◦ キーコンフィグに対応結局実装できなかったけど…  これらをどう処理するか？ (キーコンフィグ設定をこれからの入力判定に反映させる); if(キーボード判定||ゲームパッド判定){ … } 入力判定の統一化  リフスローでは ◦ 入力処理を受け取るための専用クラスを設計（CInputクラス）  キーボードからの入力を受け取って保存  ゲームパッドからの入力を受け取って保存  キーコンフィグの設定を受け取って保存  テーブル処理で、必要な時に設定を参照  1フレーム前の入力情報も保存  「今押したか」「前から押されてるか」の判定が可能入力判定の統一化  そしてどうなった ◦ if文一つで完全な入力判定が可能に       キーコンフィグはどんな設定になっているか？キーボードはどのキーの入力を調べるか？ゲームパッドはどのボタンの(ry キーボードの方ではキーは押されているか？ゲームパッドの方ではボタンは(ry 今押した？前から押されている？ ◦ 入力デバイスによって判定回数を増やす必要がない！入力判定の統一化  こんな感じ BTN1が今押された BTN2が押されてる Bボタンがゲームパッド押されてる入力クラス押されたよ！キーコンフィグ Zキーが今キーボード押された Type Key Pad BTN1 Z A BTN2 X B UP ↑ ↑ RIGHT → → BTN1って今メイン処理押された？入力判定の統一化  入力判定はゲームの根幹 ◦ 入力が受け取れないゲームなんて無い ◦ まともな操作もできないゲームは論外 ◦ つまり・・・  入力の仕様はとても重要です ◦ できれば最初に実装しておきたい箇所 ◦ 必要であればキーコンフィグも実装 ◦ あとで仕様変更の無いように！ ※ここの内容は、キーコンフィグ以外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 ◦ 2D画像の処理に特化したDB  まあfkut_SpriteModelがあれば十分だけどね…  effectDB ◦ エフェクト（3D画像）処理に特化したDB ◦ カメラ「こっち向いて～」  関数1つでカメラの方へ！面倒な計算不要！データベースの使用  soundDB ◦ BGMとSEを扱うDB ◦ 音量を一律で変更  音量設定はconfigDBから受け取る  configDB ◦ オプションで設定した内容を持つDB  音量設定  フルスクリーン設定データベースの使用  systemDB ◦ 細かな処理を担当するDB  フェードアウト・フェードイン  カメラモデルのポインタを渡す  fk_Sceneのポインタを渡す  rankingDB ◦ ランキングデータを持つDB  実装には至りませんでしたデータベースの使用  変数の管理はしっかりと！ ◦ むやみな変数の宣言は混乱のもと ◦ ややこしい変数や関数は全部クラス化 ◦ 変数を管理する専門の人を作るのも良いステージエディタの作成  ステージを作るには ◦ コードに数値をガチ打ち  やめてください ◦ とりあえず txt or  まあ多少は楽だけど… ◦ ステージエディタ  こっちの方が楽だよね csv ステージエディタの作成  リフスローでは ◦ フィールドを3次元のマス目で表現 ◦ ブロックが存在するマス目を保存 ◦ 読み込み時マス目から実際の座標へ変換 7 6 5 4 3 2 1 1 2 3 4 5 6 7 ステージエディタの作成  管理しやすい保存ルールを！ ◦ 1行目にはエディタのver.を ◦ 2行目にはプレイヤーの初期座標を ◦ 3行目以降にはブロックの座標を  特に大量のステージを作る時に有効 ◦ プレイヤーにステージを創作してもらう時は必須悪かった点  時間配分 ◦ ベースを作るのが遅かった  一通り作り終えたのが7月中旬ごろ  しかもバグが多発  プロトタイプから移行する時の障害の一因に ◦ ベースは早めに作ろう！  ベースを作る人のペースがその後の作業全体に影響します悪かった点  ベース関数説明・リファレンス ◦ 何もかも説明不足だった  「この関数はどうやって使うの？」が数百回  用意した関数が活躍できなかった ◦ 他人のコード程分かりにくいものは無い  詳細な説明が必要です  コメントだけでなく、実際に使っているサンプルプログラムなどがあるとすごく良い最後に  プログラムの腕はほぼ経験で決まる ◦ ◦ ◦ ◦ ◦  どれだけゲームを作ったか？どんなゲームを作ったか？どんなライブラリを使ったか？どんな人たちと一緒に作ったか？失敗も成功も全てが経験！泣いても笑っても、ゴールは来年9月 ◦ 悔いの無いゲーム制作を！ご清聴ありがとうございました