こんにちわ、DarkOmemeです。

昨日はつい興奮して本題が書けなかったので今日こそ書きたいと思います。

その前に、昨日のアブストラクトをどうぞ。

–

フレームワークなしにゲームプログラミングしていると、以下の事が発生する

1. 状態管理ができなくなってくる
2. 作りたくない部分ばっかり手間取る
3. 修正や機能追加の際に、一体どこをいじればいいのかが分からなくなってくる

–

何コレ？

昨日の内容がたったの3行という。

ま、それはいいとして。

つまり、僕が目指すFlexのゲームプログラミングフレームワークはこんなものを目指すということです。

「簡単に見通しの良いソースが書けて、修正や機能拡張に柔軟なゲームプログラミングフレームワーク」

これを解決するために、色々とゲームというものについて考えてみました。

以下は、ゲームというものの定義およびモデル化です。

–

ゲームというものは、単純化してしまえば『入力』と『反応』だと考えます。

つまり、人間がある『入力』を与えて、それに対して面白い『反応』を返す。
これがゲームというシステムの一番ベースの部分。

但し、電源ゲームに関して言えばもう一つ、次のこともベースとなります。

『仮想競合相手（敵）』もこの二つを行う。

例を挙げるならば、RPG。

モンスターA が あらわれた！
コマンド？
ゆうしゃ の こうげき
モンスターA に 10 のダメージ！
モンスターA の こうげき
ゆうしゃ は 6 のダメージ！

こんなRPGの場合、あるゲームに対して、ゆうしゃ（プレイヤー）とモンスターA（仮想競合相手）がいて、お互いにコマンドを選択し、そのコマンドと自分のパラメータを攻撃計算式に当てはめて結果を出します。
それらの結果から次のコマンドを選び、最終的に自分のライフポイントが０になった方が負け。

コマンドが『入力』で、攻撃計算式の結果が『反応』、そしてその二つをモンスターA、つまり仮想競合相手と行います。

もう一つ例を挙げるとすると、シューティングゲーム。

プレイヤーが画面に登場
敵が画面に登場
プレイヤーが敵から逃げる
敵がプレイヤーを狙って弾を撃つ
敵の弾が画面に登場しプレイヤーの現在座標方向に向かって直進
プレイヤーが弾を撃つ
プレイヤーの弾が画面に登場しプレイヤー上に向かって直進
プレイヤーの弾が敵に当たる
敵のライフポイントが0になる
敵が爆発する

RPGと違って、シューティングゲームはリアルタイムなゲームです。
でも、それだからと言って、この『入力』と『反応』、そして『仮想競合相手』というゲームの定義が揺らぐわけではないと思います。

トランプと同じように、7並べのようなゲームもあれば、スピードのようなゲームもあるということ。

シューティングゲームで入力とは『プレイヤーキャラクターの移動と攻撃』、仮想競合相手の場合も『敵キャラクターの移動と攻撃』。
反応とは『プレイヤーキャラクターの座標変化・攻撃弾が画面に登場し直進、弾が当たる、弾が当たったキャラクターのライフポイントが減る、ライフポイントが0になると爆発する』。

ゲームをこのように、『入力』・『反応』・『それらを操る仮想競合相手』という3つの要素で考えることができるなら、以下の様にモデル化できるんじゃないでしょうか？

–

こんな感じ。

この仮想競合相手とPlayerがコマンドキューにコマンドを追加するタイミングが順番であればRPGのような非リアルタイム型
早い者勝ちであればリアルタイム型のゲームを表現できるというわけです。

と言うことで、DarkOmemeが本気出して考えたゲームプログラミングフレームワークはCommand駆動のフレームワークになります。

（更に続く）

Filed under: ゲーム開発, DarkOmemeの本気, Flex, ME Framework, それより今週のノルマはどうした？日記

Trackback URL