SelfNote200604

　ということでHSPLetテスト第２弾。
　GFSから、平面移動のインタフェースだけ切り取ってみました。
　サンプルはこちら。（※注：MIDIで音が鳴ります。別ウィンドウが開きます）
　ソースコードも同じページで公開してますので、煮るなり焼くなり好きにどうぞ。pixel単位のマップスクロールとかも実はすごく仕組みは簡単なのでした。

　HSPLetの公式を読むと、「計算性能は（javaのパフォーマンスのおかげで）本家HSPの数倍、グラフィック処理性能は1/5程度」などと書いてあるわけですが、思ったよりも快適に動きますね。まあこのサンプルはGFSライブラリではなくてスクラッチで書き直し、あくまでマップと主人公スプライトしか表示させてないので負荷的にミニマムだからとも言えますが、この動きからすると結構何でもいけそうです。
　で、肝心の処理速度を調べてみました。
　私が現在メインで使っているInspiron700m（PentiumM:1.6G）では、スタンドアローンのHSPで動かした時と同じFPS値（await20=50FPS）を再現できましたが、寝床に置いてあるMURAMASA（Transmeta900MHz）で実行すると、期待値50FPSに対して3-5FPSしか出ていません（後で最適化したら7-11FPSにはなったが…）。こりゃ駄目だ。
　HSPLetの公式によると、「計算性能は（javaのパフォーマンスのおかげで）本家HSPの数倍だが、グラフィック処理性能は1/5程度」ということで、確かにそんな感じのようです。前回のHSPLetサンプルもフレーム系なのに、どちらのマシン上でも正常に動いていたのは、グラフィック転送回数が少ないためでしょう。
　若干今回のプログラムも速度向上させる事はできますが（※１）、根本的に早くできる気はしませんね。つまり、HSPLetでスクロール系ゲームを提供したい時は、例えばCeleron2.1G以上とかある程度必要スペックを提示したほうがいいかもしれません。

（※１）ソースコードで、マップ作画するときにgmode0をしっかり入れてなかったのと、フレームの最初に無駄なブラッククリアがあるのでこの２点を対処した。

　HSPLet使ってみました。趣味を兼ねたテスト作品はRO系コンテンツのこちらのページに配置。別にゲームでも何でもないですが。（要JRE150系JavaApplet再生環境）
　HSPLetのサイトだとJDK1.4.2以降でよさげっぽいこと書いてた感じなのですが、実際に作ってみたらpicload周りでリソースが無いとかNullPointerException返してくれちゃいました。JRE150系の環境だと大丈夫でしたが、まだ14x系使ってる人って多そうですね。
　このテスト作品は一応フレーム系なのですが静的な情報しか出してないのでいまいちパフォーマンスは測れず。まあ、最低限これくらいの事ができるとわかっただけでもOKなのですが。

　今週は殆どプログラムせずに終了、あまり進展無し（・・; ﾏｽﾞｲ

　ふとしたことから、ウェブページ上で動的な画像生成をして出力してみたくなりました。Perlで確か何かあったよね！　とぐぐってみたら、on the flyというモジュールを発見。（解説してるサイトへのリンク）
　おおこれでとりあえず用は足りそうだと思ったものの、Flashが使えればこういうのはもっと楽勝なんでしょうね。結局去年はFlashの勉強しないままでした（ｘ_ｘ；）。最近はよくできたFlashゲームも増えてきて、ちょっと羨ましいなーとか色々思ってしまったり。
　しかし今Flashを勉強するとGFSの方が進まなくなってしまうので、それはまたいつかの機会に。変わりにというか、今回のこの用件に合いそうなモジュールがもう一つあったのを思い出しました。HSPLetです(HSPLetのサイト)。HSPのjava移植版のようなもので、つまりはWebブラウザ上でHSPコードが実行できるモジュールです。かなり昔からあるもののいまいち普及していない気もしているのですが（・・;）、HSPプログラマモードの鷹月はon the flyのような局所的なコード覚えるよりこっち使いこなせるようになったほうがいいんじゃないかなとか思ってたり。ともあれ存在は知っていてもモジュールをダウンロードしたのは今日が初めてだったわけですが、暇を見て色々いじってみたいところですね。
　スタンドアローンのHSPがそのまんま動くわけでもなくて制約があるわけで、たとえばGFSがそのままウェブ上で動くほど甘くはないし、ファイルの保存周りがセキュリティポリシー上使えない。クッキーを使った偽装的な手段か、あるいは外部のcgiと連動させたりとか、少し特殊な事をしなくちゃ駄目っぽいですね。

　GFSはACT, STG, ARPGの基本骨格ができつつありますが、この先のお話。
　（7日にも書きましたが）RPGライクなものも作れるようにコマンドバトル機能を搭載しようと思っているところですが、やや難航中。
　それが終わったら、AVGインタフェースの強化ですかね。他のジャンルの中でメッセージ処理を行うためのインタフェースは既にありますが、純粋にAVG用として使う場合にはやはりもう少しキチンとした機能がほしいところです。
　で、そこまで実装できたらいよいよ、GFSへのDestuneシステムの搭載をやってみたいなーと思います。Destuneとは、かつてPC98で作っていたコズミックアークという作品で使われたシステム群の総称で、[1] マルチタスク制御 [2] 時間軸制御 [3] 自由座標移動 [4] ％戦闘システム から成ります。
　んで最後に、httpプロトコルを使ったネット連動系の機能実装。
　GFSの基盤開発はそこまでいったら終了の予定です。まあその後でもコードのクリンナップやらライブラリモジュール化とか、やる事は結構あったりはしますが、ともあれ８月まではかかりそうです。多分それより早くは無理。そうして出来上がったGFS開発キットは一般公開すると結構ウケそうな気もしますが、私自身がそれで何作も作り上げてからでないとさすがに勿体無いですね。

　CreationCollege、ページとしてはリニューアルしているものの肝心の記事を更新していませんね（・・;）。今年のどこかの時期からは本格的に追加していきたいと思ってはいますが、それより今は私自身がゲームをリリースする時期だろうということで後回しにしている面があったりします。
　考察だけでも記事は書けるけれど、やっぱり経験を加えて書くのが一番ですし、記事そのものの信頼性も向上します。ゲーム研究を行う人は昔に比べるとだいぶ増えてきましたが、作り手側自身によるそうした記事はまだまだ不足していると思うわけで。

　GFSネタが多すぎるので、もちょっと創作全般の話もしたいところですね。でも今日もGFSネタ。このシステム開発も始めて１ヵ月半が過ぎました。といってもHSPのプログラムを１からやり直しつつもコミコミでしたから、それなりの開発速度と言ってもいいかもしれません。
　mode3と呼んでいるGFSのジャンプACTインタフェースは、それでプロジェクトを動かし始めるというくらいですから、かなりの完成度になってきました。GFSは多彩なゲームモードがウリですが、ジャンプACT一本でも勝負できるくらいのポテンシャルを持っています。その気になればソーサリアンでもドラキュラ２でもイース３でも。（まだボス実装はやっていませんが）
　何よりこれが、HSPの最新版であるHSP3.0で、１から私が書き上げているわけですから、かなり長い将来に渡ってこのGFSシステムを活用できそうな所がいいですね。
　んでまぁプロジェクトとしてジャンプアクション製作に入るわけですが、それとは別にまだまだGFSシステムの拡張も挑戦しています。ちゃちくてもいいのでコマンドバトルのできるインタフェースを作ろうかなとか。

　コンポーザさん募集については、おひとり手を上げてくださいました。多謝！
　と言ってもまだ手が足りなそうなのでもう一人こないかな〜と引き続き募集します。今後もこうやってプロジェクト単位で協力者募集をすることになるかも。（プロジェクトの内容をもうちょっと提示した上でやったほうが良さそうね）

Gumiki ver0.96リリース

　Gumiki公式サイトにてv0.96無事リリースとなりました。肝心のリリースノートとか新規タグの記述をまだやってない状態ですが(〜ﾟーﾟ;)〜 ｱﾄﾃﾞﾔﾗﾅｲﾄ
　今までバージョン値にはずっとαを付けてきたのですが（αとかβはLIMITED VERSIONの意味がある）、このぐみな情報局やWF公式などで問題なく安定稼動しつづけており、またURLエンコード問題も解決した事から充分に対外的に使えるツールであると判断しαを外しました。今月中にVectorなどにも登録しようと思います。まあそこらのWikiに比べると導入難度が高いツールだとは思いますが…

　後日WhiteFluteのOHPでもお知らせしますが、ホワイトフルートにて、GFSを使った小規模アクションゲームの製作が正式に始まりました。
　ところが現在、曲を書く余裕のあるメンバーが誰もおらず、このままだと巷のフリーサウンド系をお借りする事になってしまいそうです。私も久々に１曲くらいトライしようとは思ってはいますが、１曲ではさすがに足りないですしねえ…。
　そういうわけで、このアクションゲームプロジェクトに音楽（Webでのフリーソフト公開を想定していますので.midファイルとなります）を提供してくれる外部協力者の方をこっそりここで募集します（・・;
　手伝ってもいいよーという心優しい方がおりましたら、gumi＠gumina.sakura.ne.jp（＠は小文字で！） までメールをくださいませ。追って詳細連絡さしあげます。

　2D移動インタフェースでゼルダの伝説っぽいものを作ってみるとどうかな？　と色々考えてみると案外このシステムって試行錯誤の末に出来上がってるものなんだなと気づかされます。
　ゼルダでの敵および主人公は基本的にドット単位で移動します。で、主人公の攻撃は上下左右にしかできないわけですが、ここで一つ問題点が出てきます。斜めが死角になるのですね。そういう理由から、斜め方向に移動してくる敵はゼルダでは少なめにデザインされています。また敵の移動についても、表面的にはドット単位ですが、セル単位で方向転換をしたりして、斜め軸を減らしているわけです。
　自由スクロールじゃなくて画面単位でのスクロールをする移動系（ハイドライドもそうですね）についても、その後の流行りから考えるとマイナー気味ですが、敵の出現管理の観点からは寧ろ優れているなぁと気づかされたり。
　そういうわけで、簡単にプログラムできるーってものでもなく、ちゃんとデザイン面で考えてから組むべきジャンルだなあと思ったので今日の時点ではまだ手を付けないことに（・・;

GFS開発状況

　GFS(Gumina Frame System）の開発はここ１週間はゆったりと。接触ダメージ型の2D平面の基本インタフェースを試しに搭載してみたり、アイテム管理を実装したりとか。今月からはサンプルゲームをリリースしたり、WhiteFluteのほうでもこのGFSを使った作品製作などが始まりそうな感じなので乞うご期待？

Gumiki ver0.96

　公式で公開しているビルドはv0.94止まりですが、久しぶりにGumikiエンジンが0.96にVerUpしました。現在は自分のサイトに適用して様子を見て、安定してきたらリリースしようと思います。
　メインの改善点は、3/8に懸案点として書いていた「URLエンコードされたGumikiページへのリンク」に対応したことです。ブラウザのURLエンコードはUTF-16と呼ばれますが一度これをUTF-8に変換し、そこからShift_JISにデコードします。こう書いても分かりにくいかと思いますが、要するに今までのバージョンだと検索エンジンからはGumikiページはうまく検索できないという問題点があったのが改善されたということです。その代わりJcode.pmが必要になったために、今回のv0.96からは要Perl5となります。一応Perl5使えないって人のためのダウングレード手順についてはリリースノートのほうに書いておく予定です。