□ 湯田洋晃のぼやき・・・・
|
|
・・・・と言っちゃおう。この際（笑）
この手のゲーム好きなんだよ。「ガーディアン・ヒーローズ」とか。
でも意外とフリーソフトでは作られてなかったりする。
「じゃあ作っちゃえ！！！！」
|
|
|
企画（よりも実現可能かどうか）を考えていくうちに、
「何故パソコンソフトで作られていないか？」が分かった。
ほかにも理由はありそうだけどこれが一番の（大きな）障害だと思う。
ＶＲＡＭが足りないんだよ〜ＶＲＡＭが〜（泣）
|
|
|
まず、キャラクターの大きさ。
画面の１／３の高さは欲しい。
手足を伸ばすから横幅も同じくらい欲しい。
画面の比率は縦３：横４に必ずなるから、
１画面＝１２ポーズ分と考えておこう。
ちなみにＫｎｕｃｋｌｅ−ＦｉｇｈｔｅｒＸ（格闘ゲームのフリーソフト）では、
１キャラで約７０ポーズぐらいは使っているみたいだ。
だから同じクオリティで動かすなら、７０ポーズが必要。
敵はＣＯＭが操作するため「ある程度手抜き」が出来る。
それでも使用ポーズ数は１／３に出来るかどうか。
仮に最大出現敵キャラ種類を「３種類」にしても主人公キャラと同じ７０ポーズ。
合計約１４０ポーズ。
（全キャラのポーズ数）１４０／（１画面当たりのポーズ数）１２ ＝ 約１２画面
キャラクターで１２画面使用する。
プログラムの話になるが、
プレイヤーに見える画面（プライマリ）と編集用画面（バック）と
スクロール背景用の画面がそれぞれ１枚づつ。３画面消費。
１２ ＋ ３ ＝ １５
最低でも１５画面分を保存するＶＲＡＭが必要になる。
あくまでも最低。
他にもシステム用の確保も必要だろうし出現する敵の最大種類が３種類ですむわけが無い。
|
|
|
画像を高速に表示するにはＶＲＡＭに保存しないといけない。
１５画面分がＶＲＡＭに保存できれば問題無いが・・・・。
１画面どれぐらいのサイズになるのか計算。
サイズは使用する画面の「解像度」・使用する「色数」で大きく変化する。
計算式は、
縦のピクセル数 × 横のピクセル数 × 使用する「色数」 ÷ ８ ÷ １０６（単位：ＭＢ）
・・・・で計算できる。
ちなみに「色数」は、
１６色のみ ・・・・「４」
２５６色のみ ・・・・「８」
ハイカラー ・・・・「１６」
フルカラー ・・・・「２４」を代入する。
ここからが面白い。
一般的なゲームの解像度６４０×４８０、フルカラーで計算すると１画面当たり
６４０ × ４８０ × ２４ ÷ ８ ÷ １０６ ＝ ０．９２ＭＢ
一般のユーザーはＶＲＡＭは４ＭＢくらいだから４画面？！
私にどうしろというのだ（笑）
「色数」を２５６色（２４から８）にしても、１／３で１２画面。まだ届かず。
１６色だと２４画面だけど背景・キャラ共通１６色で
ＣＧ描ける人は今はいないんじゃないか？
それに１・２年古いＰＣだとＶＲＡＭは２ＭＢなはず。
素直に解像度を落とす。
３２０×２４０のフルカラーだと、
３２０ × ２４０ × ２４ ÷ ８ ÷ １０６ ＝ ０．２３ＭＢ
６４０×４８０の１／４だから１６画面・・・・１５画面をクリア。
ただし遊べるのは４ＭＢの人だけ。
２ＭＢでも遊べるように２５６色にして１／３だから４ＭＢで４８画面か。爆発的に増えるな。
２ＭＢの人でも２４画面だから１５画面をクリア。
ちょっと余るぐらい。
|
|
|
プレイヤーが見える画面（プライマリ）と編集画面（バック）を、
フルカラーにできれば背景・キャラ共通２５６色にしなくてもすむな。
背景でもアニメーションさせたいから、１枚余計に欲しいな。
整理しよう。
解像度 ：３２０×２４０ ２５６色（表画面・裏画面だけフルカラー）
最大ＶＲＡＭ ：２ＭＢ
最大使用画面数 ：２４枚
プライマリ ：３枚
バック ：３枚
スクロール用 ：１枚
背景アニメ用 ：１枚
−−−−−−−−−−−−−−−
計８枚
システムだけで８枚使用する。最大使用画面数から引いて、
最大枚数 システム
２４枚 − ８枚 ＝ １６枚
１６枚で主人公キャラと敵キャラを作る事になる。
半分ずつに分け８枚・８枚。
主人公キャラが８枚 ＝ １２ポーズ×８ ＝ ９６ポーズ
Ｋｎｕｃｋｌｅ−ＦｉｇｈｔｅｒＸでも約７０ポーズ・・・・
なんとかなりそうだね。
敵キャラも敵１匹当たり２０ポーズですめば４匹＋α楽に入る。
多少敵キャラが大きくなっても１６色で描ければ１／２ですむからね。
|
|
|
いまどき解像度３２０×２４０のゲームなんて３Ｄでも少ないけどしょうがない。
え〜と。１キャラの高さが画面の１／３だから、
２４０の１／３は・・・・８０ピクセル。
あれ、結構小さいぞ。
Ｄ−Ｐｉｘｅｄでサイズを確認。
ディスプレイの解像度が１０２４×７６８だからかもしれないけど見た感じ・・・・
ＲＰＧのドット絵に毛が生えた程度（笑）
今見ている解像度の１／１０の高さだからね。
「ＣＧ」というよりも「ドット絵」だね。感覚は。
大変だぞ。キャラ描くの。いやキャラのドット打つの。
|
|
|
普通であれば「操作」や「システム」を書いていくのだが、
この手のゲーム（アクション）の場合ほとんど意味が無い。
「ロジック」といっても私の場合、
２Ｄゲームであれば「ぷよぷよの思考」以外はほとんど分かる。
私にとって一番重要なのは
「どうやってデータを作っていくか？」にある。
データと一口にいってもたくさんある。
今回のゲームで使用するデータは、
「キャラ画像」
・すべての動き（ポーズ）をＢＭＰで用意
「キャラ画像の加工」
・余分な空白をカット
・ＶＲＡＭの効率化を図るために規則性を持たせて分解し１枚の絵に組み立てる
・１枚の絵から１ポーズ取り出せるように組み立てる方法をデータ化
・再構築を考え１ポーズのファイル名・切り抜いたｘ、ｙ、ｗ、ｈをデータにして記憶
・地面・中心を決める
・攻撃・当たり判定のデータを作る
・攻撃力・攻撃の種類・ＨＩＴ時の移動量を設定
「キャラアニメーション」
・行動名と表示するポーズの順番をデータにする
・行動の種類（基本技・通常技・必殺技）の設定
・行動・ポーズ毎にキャンセル可・不可を設定
・行動・ポーズ毎に表示時間を設定
「コマンド入力」
・入力方向を数値化
・コマンドごとに発動する行動をデータ化
「スクロールする背景画像」
・スクロールする背景を１枚絵でＢＭＰで用意
「アニメーション・障害物背景画像」
・アニメーションする個所だけをＢＭＰで用意
・障害物もＢＭＰで用意
「背景アニメーション」
・スクロール用背景とアニメーション・障害物をつなげるデータ（座標）を作る
・障害物の当たり判定を設定
あとはＢＧＭ用のＭＩＤファイルと効果音のＷＡＶファイルも作る必要がある。
敵の思考データも・・・・魔法・飛び道具もある。
大まかに書いたつもりでもこれだけ・・・・
アマチュアで作る人がいない原因がここにもある（笑）
分類すると、
・制御系のデータ
・既存フォーマットのデータ・・・・・がある。
|
|
|
画像・ＢＧＭ・効果音は既存のデータフォーマットがあるし、
それを作成するツールも手に入るから問題無い。
問題は「制御系のデータ」を作る方法。
方法は３つ。
「制御 ＝ プログラム」なわけだからプログラムでも数値を設定できる。
ただ行動アニメーション・ポーズごとにプログラムを加えていかなければならない。
７０ものポーズに１つ１つ似たようなプログラムを記述し、
その後ゲーム調整をする事を考えると、
プログラムを知っている人間は、
デンジャラスな嫌な色の汗を大量に分泌してしまう（笑）
これは絶対に避けたい。
|
|
数値で設定していた所を汎用的に変数に置き換え、
プログラムの始めにテキストファイルを読み込みその変数に代入する。
Ｋｎｕｃｋｌｅ−ＦｉｇｈｔｅｒＸはこの方法をとっていたはず。
これで似たようなプログラムを書かなくてすむ。
数値の変更もテキストエディタでＯＫ。
実行ファイルを作り直す事も無くなる。
ただ変数にいれるデータを読み込む順番に合わせてデータ作り・・・・
つまり「書式（フォーマット）」を決める必要がある。
数値の羅列をコンマ（，）で区切り、
左から１つめは「ｘ座標」２つめは「ｙ座標」・・・・と、
データを作る側が読み込む順番を考えて作成しないといけない。
|
|
ゲームの読み込む順番に合わせて書き込めるツールを作ってデータを作る方法。
ツールにしてしまえばデータの書式を気にせずに作成できる。
座標設定なんかも数値入力にせずマウス入力にしてしまえばもっと楽に作成できる。
こうやって書くと「いい事尽くめ」だがデータを作る前のツール作成に、
メインのゲーム作成と同じぐらいの時間・労力が裂かれる。
|
|
・・・・で、今回の作成方法は３つめの「ツールで作成」を選択。
ツール作りは面倒。
ただ、なんとなく分かる。
この手のゲームは調整に相当時間がかかるだろう・・・・と。
テキストエディタで数字の羅列から拾って調整するよりも、
ツールを作成して調整した方が全体の効率はよくなるはず。
|
|
|
どのようなツールが必要なのか？
上記のデータから考えると、
「キャラ絵加工ツール」
「キャラアニメーション調整ツール」
「コマンド入力ツール」
「背景アニメーション調整ツール」
・・・・の４つ。
「キャラ絵加工」は作業項目が多すぎて、１つのツールにまとまりそうに無い。
だから画像を操作する「キャラ絵加工」と
それ以外の「攻撃・当たり判定」を分ける事にした。
「キャラアニメーション調整」も、
ＤｉｒｅｃｔＤｒａｗに関係する「アニメーション調整」と
行動のステータスを設定する「行動設定」とに分けた。
飛び道具・魔法データと敵の思考データも追加する
最終的にツールは、
「キャラ絵加工」
「攻撃・当たり判定」
「行動設定」
「アニメーション調整」
「コマンド入力」
「背景アニメーション調整」
「飛び道具・魔法」
「行動判断」
・・・・の８つ。
泣きたくなってくるぞ（笑）
全部作るんか？これ？
直接ゲームを作らず第一段階として
「入力したコマンドに合わせてアニメーションするソフト」を
作ろうと思う。
まずは
「キャラ絵加工」
「行動設定」
「アニメーション調整」
「コマンド入力」
・・・・の４つのツールを作成しなければ・・・・はぁ〜、ため息が出る（笑）
|
|
|
ツール系のソフトの作成には、
「Ｖｉｓｕａｌ Ｂａｓｉｃ」でしょう。
こいつは「データ操作がメインのソフトを開発するためにある」
・・・・といっても過言じゃない。
デザインも楽だし、データのやりとりも楽だし。
ＶＢでツール作ってデータ作成。
ＶＣでゲーム作って作成したデータを読み込む。
これが基本。
昔と違って処理うんぬんはそれほど問題じゃない。
ＶＢだろうとＶＣ＋＋だろうと同じ処理であれば、
ほとんど同じ道（ＡＰＩ）を使うわけだから大きな差はない。
重要なのは「欲しいソフトを開発するのに都合のいい言語」を使う事。
ＶＣ＋＋はゲーム専用のＡＰＩ「ＤｉｒｅｃｔＸ」を使うのに１番相性がいいからね。
あとは
「ツールを開発するのに適した開発効率の良い言語」で作る。
ツールまでＶＣ＋＋で作る必要は全くない。
ＶＢよりも「開発効率が良い言語」があれば、もちろんそれを使いたい。
最近よくＤｅｌｐｈｉの評判を聞く。
機会があったらぜひ試したいね。
|
|
|
これが制御に関するデータのフォーマット。
プログラムできない人にも分かるように言うと
「使用する全データを入れる容器を１つ１つ考えて作った」のがこれ。
まだスクロールと敵の思考のデータは出来ていない。
あの英語は辞典で調べてそのまま使っているので
間違ってる所があると思うけど気にしないで（笑）
あれだけの量を一気に作ったわけじゃない。
おつむは・・・・あまり良い方じゃないので、
「あ。これも必要！。」とかツール作りながらどんどん追加していったら、
あの状態に・・・・。
「データ作り」と「プログラム負担」は反比例するから、
これだけしっかり作っておけば原因不明のバグに泣く事は少なくなる・・・・はず（笑）
しっかり作りすぎたかな。
いま制作中のアクション以外、
「２Ｄ格闘ゲーム」にも対応できる
汎用性を持たせてしまった。
作成中のこのゲーム、
しゃがめない以外は「格闘ゲーム」と共通する所が多いから。
しゃがみはプログラムの方だからデータには影響ない。
あといろいろ対応できるようにしたらこうなってしまった。
プログラムさえ作れれば、
「キャンセル」「複数ヒット」「ガードキャンセル」「１０連コンボ（？）」「浮かせ」等
投げ以外はほとんどの２Ｄ格ゲーシステムがデータの規格変更無しで出来てしまう。
・・・・やりすぎたね。
ふと思ったんだけど、
もしかしたら格闘ゲームの方が簡単なんじゃない？
Ｚ軸移動がないぶん・・・・ねぇ・・・・。
いっそ格闘ゲームにしちゃおうか？（笑）
|
|
|
困った。問題が出てきた。
アニメーションの時間調整だ。
・・・・といっても正確な「時計の時間」ではなく、
何回表示したかという「ゲーム時間」なんだけど。
表示方法がＶＢとＶＣ＋＋じゃ根本的に違う。
ＶＢはＷｉｎ３２ＡＰＩの「Ｂｉｔｂｌｔ」
ＶＣ＋＋はＤｉｒｅｃｔＤｒａｗの「Ｂｌｔ」
ＶＢではＤｉｒｅｃｔＤｒａｗは使えない。
「Ｂｉｔｂｌｔ」じゃ遅すぎてゲームにならない。
処理速度だけだったら、計算で誤差は調整できる。
これは描画方法が違うから計算でも誤差が出るのは容易に想像できる。
アニメーションの所だけＶＣ＋＋・・・・やだな。
あ。そういえば・・・・。
|
|
|
あった。あった。あった。ＶＢで使えるやつが。
えーと。「VB用DirectDraw活用モジュール1.6」
これ使うとＶＢでもＤＤｒａｗできてしまう。
ただウィンドウ全部が描画場所になってしまって
せっかくのＶＢの良さ「デザイン作成の容易さ」がなくなってしまう。
・・・・と思ったら、バージョンアップ？
お。ＰｉｃｔｕｒｅＢｏｘに指定可能になってる！
これだったら描画のプログラムを変えるだけで、
あとは普通どおりに組めるぞ。
さっそく描画ルーチンだけ変更。
面白いほど簡単。
ＶＣ＋＋でまともにやったら２０行ぐらいかかる所を１行ですむからね。
それに意外と・・・・どころか結構速い。ＶＣ＋＋なみの速さ。
「これならＶＣ＋＋でゲーム作らなくてもいいんじゃないか」と思って色々いじくる。
さすがにそれは甘かった。色数の問題でＶＲＡＭの使用効率が悪くなってしまう。
ＶＣ＋＋は細かく設定できるからね。
ＶＲＡＭの使用量の少ないＲＰＧとかなら十分使える。
これはいいね〜。シミュレーションはこれで作ろう。
・・・・って、いつになるかは分からないけどさ（苦笑）
|
|
|