プログラミングやる前に先お風呂はいっちゃいなさい

43月/090

ゲームプログラミングのためのフレームワークについて本気出して考えてみた2

こんにちわ、DarkOmemeです。

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

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

--

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

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

--

何コレ?

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

ま、それはいいとして。

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

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

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

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

--

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

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

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

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

例を挙げるならば、RPG。

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

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

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

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

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

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

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

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

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

--

ゲームのモデル

ゲームのモデル

こんな感じ。

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

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

(更に続く)

23月/092

ゲームプログラミングのためのフレームワークについて本気出して考えてみた

どうも、DarkOmemeです。
定期的になにか自分の考えたことを文章にしないと端から忘れます。

--

ゲームをいくつか開発していると、だいたいソースコードの一覧性が悪くなっていく。

そのうち状態管理ができなくなってきて、今自分はどこの画面のどこの状態のソースコードを書いているのかわけがわからなくなってくる。

というか、そもそもゲームプログラミングをするにあたって、作りたくない部分ばっかり手間取って、作りたい部分はおろそかになる。

考えても見れば、僕はもともと物語りが書きたかったのだ。
それが、なにをまかり間違ってプログラマーなんかになったのだ。

物語を書きたい!

小説を書く

ノベルゲームにはまる

この小説をノベルゲームにしてしまおう!

俺ストーリー書くから、お前プログラミングやれよ

いやだよ。面倒くさい。それに今日俺塾だからもう帰るわ。

ポツネン

・・・プログラミング勉強するか

VB6.0とか、なにこれプログラミングとか簡単ジャン!

ノベルゲームのストーリーを記述するためのマークアップ言語を開発しよう!

え、なに、パーサー開発?なんぞそれ美味しいの?

うがー!マークアップ言語じゃ限界あるわ!こうなったらスクリプト言語を開発しよう!

え、逆ポーランド記法?演算子の優先度?

普通のテキストエディタじゃ使いづらくてせっかくの面白いストーリーが台無しだ!作る!

もー、画像とか音声とか連携取りづらいっちゅう話!フレームワーク作んないとアイディアがどんどん形にならない!作る!

VB.NETの度重なる仕様変更に心が折れてスクリプト言語開発・エディタ開発・フレームワーク開発を投げる(VB厨涙目)

死のう・・・

え、Flashって動画作るソフトじゃないの?

Flex Builder?プログラマ向けFlash開発環境?

無名関数とかwwwwwwシングルスレッドとかwwwwwwOS依存ないとかwwwwwwwwwwwうめええええwwwwwwwwwwwwww

なにこれ、Effectとかカッコヨス!

じゃあ、せっかくActionScript3とかMXML覚えたんだしゲーム作ろう!

とりあえずRPG作る!

RPGは扱うデータが多すぎるから、エディタをちゃんと作らなきゃ!

エディタ作りは大変だなあ

エディタ作りは大変だなあ

エディタ作りは大変だなあ

あれ?←いまようやくココ

なげえええええ。
で、その後、桶屋がどうなるかというと・・・

--

さておき。

あれ、本気出して考えてないのに、投稿が長くなっちゃったよ。

じゃあ、フレームワークの概要は次回。