SelfNote200603

　しばらく休職していた鷹月ですが、そろそろ資金が減ってきたのでぼちぼち働かなくちゃなーと思っていたりします。ゲーム売って食えれば良いのですが、その体制にするにはまだ時間掛かりそうなので……。去年１年何やってたって感じですね。まあいいリフレッシュにはなりましたけれど。結果的にはこうやって創作プログラムも再開できたわけですしね。
　HSPのフレーム系プログラムはとりあえずコツを掴めました。HSPがMSX-BASIC並みに扱いがカンタンだからという理由もありますが、まあこのへんは昔とった杵柄というやつなんでしょうね。

GFS開発状況

　現在までにGFSに搭載したゲームインタフェースは３つ。それぞれの開発状況ですが、

2D平面: 特に進捗なし。2D平面空間を動くというだけ
ジャンプACT: 装備概念の実装＋攻撃処理、ステージ開始時セーブ確認画面の実装、敵の復活機能、ゲームオーバー処理
シューティング: シールドの実装、爆発エフェクト
全体: JoyPad仮対応、JoyPadコンフィグ仮機能、DirectSoundによる多重発音処理

　こんな感じ。確か今回、「2D平面系で何か考える〜」とかいう方向性で始まっていたはずなのですが、気が付いたらジャンプACTばかり手を入れていますね（・・;
　このジャンプACTですが、ほぼ「迷牢」同等のシステム（MOA-1というコードがあった）に育ちました。まだ実装していない機能もいくつかありますが、代わりにというか、迷牢ではあえて使わなかった装備アイテム機能を実装し、既にGFSのポテンシャルはMOA-1を越えました。
　2001/4にリリースした迷牢からほぼ５年が過ぎました。GFSが安定してきた頃に久々に迷牢の続編を開発するかもしれません。まあ、あのタイトルを受け継ぐ作品は、それなりのボリュームを必要とするので、やるとしてもその前にもう少し小ぶりのオリジナルジャンプACTをリリースすることになるでしょう。
　まー開発っていっても、もううちのサークルは開発力が乏しくなっちゃってたりして、どうしようか困っていたりします。いまアクティブで動ける人２−３人しかいないんですよね。プログラムはこうやって私が動けば良いのですが、音楽書く人すら困ってる状況です。メンバ募集しても誰も来ないもので……まぁ、ホワイトフルートのOHPってページビュー自体少ないから仕方ないのですが。
　何とかメンバ増やすなり、あるいはサークルメンバーでなくてもいいからプロジェクト毎に開発に参加してくれる人を募るなりしたいところだなぁ。

さて２Ｄ平面

　ジャンプACTのほうに手をかけっぱなしで放置しまくっていた2D平面系。
　まあ現状でも、マップの上を歩いて調べたり会話したりする事くらいはできるわけで、これ単独ではゲームにならなくても、このモードからジャンプACTやらシューティングに遷移する中継地として活用はできるわけですが、ぼちぼちこの2D平面もゲーム的機能を追加してあげたいと思っています。
　なぜ開発が進まなかったのか？　2D平面系ゲームはジャンプACTなどに比べてバリエーションが豊富だったために、どれを選ぶか二の足を踏んでいたのでした。戦闘一つ取り出してみても、


　ほらこんなにある。まだありそうですが。
　今回の開発では、コマンドバトル系はまだ開発の敷居が高いのでa.b.d.はパスかなあ。開発難度が高いとかじゃなくて、パラメータ系を相当気を使わなくちゃいけないのですごく時間が掛かるという意味です。
　c.のリンクタイプは、せっかくジャンプACTのインタフェース作ったわけだから接続してみると面白そうですね。ただしまだ現状のジャンプACTは攻撃こそできるものの非常に簡易的なものなので、リンクのような戦闘ACTにするにはだいぶ手入れが必要そうです。
　e.のゼルダ型は普通に無難。ただし現状の2D平面は自由スクロール型なので、このままだとゼルダ的な再現はちょっと難しい。敵の出現管理とかは、ゼルダ式スクロールが適してるんですよね。
　f.のハイドライド型は……まあ、イースとかサークと言ってもOKですが。基本的には敵とぶつかるだけでダメージの応酬ができるのが楽なのですが、前面側面背面の概念とかを考えると、敵の方角毎にチップ描かなくちゃいけないとかが面倒が多くて多くて。
　しかし、これらを将来的にどれでも実装できるようにとか考えるなら、2D平面というゲームモードで統一せずに、別途分けていったほうが無難そうですね。

ちなみに

　29になりました。三十路へのカウントダウンスタート。

　結局というかGFSにパッドコンフィグ機能を仮搭載しました。と言ってもGFSの中にコンフィグを作ったのではなくて、Delphiでこしらえただけですが。この手のはGUIベースの言語はやっぱり楽ですね。
　この機能を作ったはいいけどテストはどうするか。
　ということでアキバに行って来てジョイパッドを買ってきました。
　今まで私が長らく使ってきたのは、サンワサプライのVIRTUA GRIP USB（PS配列）だったので、サターン６ボタン配列であるサンワサプライのEASY GRIP(JY-P56US)。それと、半分ネタでしたが片手でプレイできるPlayOnlineモバイルコントローラ(JY-PMUB)。
　滞りなくテストそのものは完了しました。不具合っぽいものといえば、別なボタンに同じアクションをコンフィグで割り当ててGFS上で同時押しすると、値加算されて結果が帰ってくるので別なボタンを押したと認識される、という事象が発生して、うわーこういうことも考えなくちゃいけないんだなぁとかなかなか頭が痛くなりました。
　まあそれはそれとして、EASY GRIPって「格闘ゲームやSTG、アクションに最適！」という触れ込みで売られている安物パッドだったのですが、買って使ってみると最悪。押し心地が悪いからすぐ手が疲れるし、方向キーを全押しすると左上の信号が出てしまう。シューティングでテストしてみても、気をつけていても左上にスススと動いてしまう。
　どう見てもアクションゲームに向いてないパッドでゴミ商品です。
　本当にありがとうございました。
　PlayOnlineのほうもなんかボタン押しやすいとも言えないですね。まあアクションには向いてないパッドというのは最初から見れば分かるので、こちらの評価は今回は避けておきますが。
　改めて、相当昔に買っていた我が愛用パッドのVIRTUA GRIP USBを使ってみるとその操作感の良さ、ボタンの押し心地の良さにびっくりさせられます。まあこれPSコントローラのクローン品として有名なのですが、ハズレとアタリって結構あるんだなぁと思わされた一瞬でした。まあ、最初に買ったこれが良かったからこそ買い換える必要がなかったわけなのですよね。

　最近ちょっと忙しかったのでGFS開発はそんなに進んでなかったり。
　さて、サークルの面々にGFSを見せてみたのですが、「このジョイパッドボタン配列じゃまずいよ」と言われました。私の手持ちのジョイパッドはPS配列型なのですが、上=△(2)、右=○(4)、下=×(3)、左=□(1) という設定になっていました。PSに合わせると○がメインであり、△がサブかなと思ったのですが、そうすると4-2ボタンを中心に利用することになります。
　しかし、メーカー毎にボタン配列はてんでバラバラなようで。
　「だめだよー」と指摘した人の持っているパッドはサターン６ボタン配列。上に並んでいる３つのボタンが４５６（XYZ）、下が１２３（ABC）。確かに混乱しそうですね。サターン配列なら１-２の順で確かに良さそうなのですが、PSでは□-△を使うことになってちょっと違和感？
　これだけで済めばまだいいんですが、SFC配列なるものだと上=X(3)、右=A(1)、下=B(2)、左=Y(4)だったり、PS型でない汎用４ボタン配列なるものだと上=3、右=4、下=2、左=1。
　さらに、片手で操作できるらしいPlayOnineパッドなるものだと、上左=3、上右=4、下左=1、下右=2。このPlayOnineパッドは１、２ボタンは片手で常時押せるボタンになっていないのに１，２がアサインされている。

　結論：PCゲームのパッド対応ゲームはキーコンフィグが無いと、誰かしらから文句が来る
　……ううむ面倒ですねぇ。

　GFS開発中とか書かれても、文章だけではどこまで進んでるのか分かりにくいので、現在動いているもののスクリーンショットを用意しておきました。


　▲GFS:2D平面。メニューとか戦闘とかプレイヤーステータスといったものはまだありません。とりあえず2D-RPGっぽく動かせて会話や選択肢イベントができますよという程度。考えなしに全画面マップにしましたが、改めて考えると全画面にするとステータス表示とか面倒でしょうがないですね。画面外オブジェクトの表示処理とか放置できるのは楽なんですが。


　▲GFS:サイドビュー。迷牢の再現開発中みたいな感じ。敵さんの実装中。ポリンが友情出演中。


　▲GFS:シューティング。敵弾処理がようやく出来たところ。ゼビウスとかスターフォースっぽいオーソドックスな縦シューティング。スクリーンショットだけ切り出すとなんか遊べそうに見えますが、実際は遊べる状態ではありません（^^;

　GFS開発継続中。フレームの安定化ってどうするのかしばらく悩んでました。
　１フレームの時間計測は、HSP標準機能ではまともなものがなかったので、winmm.dll（マルチメディアAPI）のtimeGetTime() を使っています。なんか精度設定しっかりしないとデフォが5ms精度なので信頼性に欠けますよとか指摘もらっちゃいましたが。
　前後フレームの差を取ればms値が出るので1000でこれを割れば無事にFPS値が算出できるわけですが、あとはここから。
　sleepでのウェイトだと純粋にそのmsecしか待ってくれないわけで、計測FPS値と目標fps値を比較して、sleepの値を調整する仕掛けがいるんだろうなあとか思っていたわけですが、Sinonさんから「HSPのawaitって一定フレーム値に保つような仕掛けが最初から入ってるよ」と指摘が。な、なんだってー。だからHSPでのリアルタイム系ゲーム製作ってみんなスマートに作れちゃってるのね。なるほど。
　とは言いつつもこのawait、使ってみると分かりますが信頼性にはちょっと乏しい（^^;）。waitが10ms単位でawaitが1ms単位とか言ってるわりには精度誤差が目視上10msはあり、しかも遅い方に合わせられている感じなのですよね。その代わり他のWindowsのタスクには影響を最小限にしてくれてるみたいなんですが。
　んで現状は、どのみちゲームはJoyStickに対応する必要があり、これ標準のHSP関数で提供してくれないのでDLL使う必要があるのですが、使わせてもらおうと思ってるck_joyForceのDLLにオマケのようにsync関数が付いており、これをawaitの代わりにしたところ、20のsyncwaitを入れたらFPS値50、25にしたら40とか凄く正確になってビックリ。変わりにだいぶタスクリソース占有はするみたいで、特にDirectX使う他アプリが動いてると競合して動きがおかしくなるようでした。まあ作るゲームによって切り分けすればいい感じです。

GFSアップデート状況

　仮のジョイパッド対応およびセーブ＆ロードの仮実装を行いました。但し現状ではセーブデータフォーマットは迷牢でやってたベタ出力状態。最低限チェックサムでのデータ捏造防止、できれば暗号化もかましたいのですが、やりたい事が多すぎて優先順位の待ち行列状態になっています。
　ほか、ジャンプアクションインタフェースに、プレイヤーのダメージ処理を実装。敵にぶつかったりとか剣山とか溶岩ダメージですね。ここらへんは単純に迷牢をなぞった実装。
　あとはメッセージ処理系で一枚絵を表示したりする機能とか細かいところの実装。
　ぼちぼち、実際のゲームに特化した機能の埋め込みも始めていきますかねえ…

アンテナとかGumikiの問題とか

　ここのセルフノートをはてなアンテナなどに追加しようとすると、見事に文字化けして失敗します。これ、別にはてなアンテナの問題でもなかったりしまして、リンク元がShift_JIS世界なら大丈夫なんですが、EUCやUTF-8で記述されているHTMLから、Gumikiの「コンテンツタイトルに日本語を含むページ」へリンクを張ろうとするとほぼ失敗します。要するに本来リンクアドレスには日本語を含んじゃいけないのですよね。ブラウザでうまくエスケープしてくれるやつもあるのですが大抵UTF-8だったりして、これはこれでGumikiはPerl4で書かれてるからやっぱり対応してなかったりする。
　Gumikiの各ページ名は英数字を推奨しておいたほうがよさげですねぇ。但しページタイトル（H1になる部分ね）には日本語で代替できるような仕掛けを作っておく必要がありますけれど。
　とりあえず問題を一旦棚上げして、暫定対処なのですが、Gumikiのページ名はcgi内部ではpageIdに変換されてまして、このpageIdを直接指定すれば日本語は一切使わなくてすみます。アドレスで書き直すと↓こんな感じ
http://gumina.sakura.ne.jp/gumiki/ent/gumiki.cgi?mode=view&realmId=1&pageId=3
　アンテナ系は上記URLを使ってもらえばうまくいきますので、使っている方はよろしくです。

　ここしばらくは他の用事も入ったのでプログラミングはそんなに進まなかったのですが、少しずつ手を加えています。この開発しているフレーム系システムにGFSというコードが正式に付与されました。まんまGumina Frame Systemの略ですけど！
　このGFSは、ゲームモードという概念を中心に組み立てられています。たとえば「２Ｄ平面移動」がmode0、「メッセージ処理」がmode1、「フェードインアウトでの移動処理」がmode2、「ジャンプアクション」がmode3、「シューティング」がmode4といった感じ。それぞれのmodeでは共通で使うパーツ（マップ表示とか主人公表示とか）を選びつつ、そのモード専用の処理のコードを追加していくという感じになります。
　そして、それぞれのモードにおける実ゲームデータは、≪イベントファイル≫と≪スクリプトファイル≫という統合スクリプトで管理・制御できるようになっています。ゲームモード間の行き来も命令一つで行うことができます。２Ｄ平面のＲＰＧ風インタフェースで、洞窟の中に入ったらいきなりジャンプアクションになったりとか、シューティング中にいきなりメッセージ＋選択肢モードに入ったりとか、こういった複合表現も自由自在です。

　とか書くと「おおなんか凄そう！」と思われそうですが、実際のところはまだそれぞれのmodeは鋳型を作っただけです。それぞれのモードの作りこみをこれから進めていかなくてはいけません。しかしどうやら私は、TGWコンポーネントの時代から卒業し、任意のジャンルのゲームプログラミングを進めていけそうな気がしています。