gamescience.jp

リフスロー
コードレビュー
リフスローチーム
和泉真
西村和晃
お題目

計画的なお話
◦ 改めてプロトタイプについて
◦ リフスローでどうなったのか
◦ 気をつけるべきこと

技術的なお話
◦ リフスローの良かった点の解説
◦ リフスローの悪かった点の解説
担当：和泉真
前半
～計画的なお話～
改めてプロトタイプについて

ゲームの動きを見るためのもの

プロトタイプ ≠ メイン

使い捨て
リフスローでどうなったのか

ゲームの動きを見るためのもの
◦ 成功

プロトタイプ ≠ メイン
◦ 移行時期で大失敗

再利用するかの判断、実際に移動
◦ 同上の理由で大失敗
気をつけるべきこと
プロトタイプであるという意識
 メインへの移行計画を具体的に
 そのクラスは他で利用できるのか？
 チーム内での仕様を徹底して把握


ちなみに
メインで利用しないプログラムでも、
取っておいた方が良いです
担当：西村和晃
後半
～技術的なお話～
ここからの流れ

良かった点
◦ 入力判定の統一化
◦ データベースの使用
◦ ステージエディタの作成

悪かった点
◦ 時間配分
◦ ベース関数説明・リファレンス
リフスロー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月
◦ 悔いの無いゲーム制作を！
ご清聴
ありがとうございました

Download Report