HSPでのゲーム開発…続き
Windowsで動作するインタプリタ型プログラム言語HSP（Hot Soup Processor）でゲームを開発中です。馬を使ったすごろくのようなこのゲームは、年明けの新年会の余興で使うもの。スプライトを使ったゲームプログラムは不慣れとあって時間がかかっているのだけれど、キャラクター表示やアニメーションがうまくいったなぁと思えば、とんでもない事態におちいっております。それは表示の遅さです。そんなお話。
キャラクター・アニメーションの表示が遅いことに気付いたのは昨日のお話。ランダム表示しているサイコロの目がゆっくりになり、アニメーションがスローモーションになってしまったんです。単純に処理スピードが追いついていないような感じです。ところがCPU使用率もメモリも余裕があります。単純に描画と処理に時間がかかっているような感じだったのです。
思い当たるような原因としては、キャラクターサイズによって複数のBMP画像を用意、それらを不可視ウィンドウに読み込みスプライトをたくさん使って描画している点でしょうか。不慣れなゲーム開発のためプログラムの中で効率の悪い処理がいたるところにあるはずです。
とりあえず思い当たるところに手を入れてみます。まずはキャラクター画像を見直し数を整理。スプライトで表示しなくてよいところは背景に含めたり違う方法をとるなどして効率を上げます。しかも複数のBMP画像をすべて統合し不可視ウィンドウの数を減らしました。チカラ技で書いた処理も効率よく見直したのだけれど…それでも遅いままです。
もう仕方がないので、処理が遅くなった部分を判別するためプログラムを書き直しつつ検証をしようと思ったのだけれど、もう最初から処理が遅いんです（笑）。「これは今開発中のプログラムが原因ではなさそうだ…」。そう思った私は参考にしたサンプルプログラムのシューティングゲームを実行してみることにしたのです。
すると案の定、滑らかに動いていたはずのキャラクターがスローモーションになっているではありませんかっ。原因はWindowsのシステムそのものだったようです。思い当たるふしはないのだけれど…システムの復元を使って開発環境を整えたあたりまで戻してみると…あっさり解決しました（笑）。こんなことならばソースの見直しなんてしなくてもよかったような気もしますけれども、効率がよくなったことは悪いことではないので、それはよしとします。
余興ゲーム開発…
来年の新年会の余興で使うゲームをHSP3.3（Hot Soup Processor）にて開発中です。年内に説明書きを配布することを考えて逆算すると、もう開発日数が足りなさそうなことは明白なので、今週から家でも開発をすすめております。昨年は会社のパソコンで開発しましたけれども、DirectXが正しく動作しないため、スプライトを使っ
たゲームが作れないことから、今年はネットブック上での開発に切り替えました。この恩恵で家に持ち帰って気軽に開発することが可能になったわけです（笑）。そんなお話。
実を言うと前回はもっと開発日数が足りなかったため、ゲーム内の音楽関連の作業は正月返上で自宅でやりました（泣）。幸いなことに今年はゲーム音楽をほぼ使い回すのでその部分はラクです。あとは必要になるとしたら、エフェクトサウンドがいくつか…そんな感じだと思います。
ただし、基本的なゲームの仕様は同じですが、キャラクターに個性を持たせたことによる動作の違いや、内部処理が一新するため、ほぼ新規で作り直しているところです。はっきりとここで書けないので抽象的な表現にとどまってしまうのが心苦しいのだけれど、すごろくゲームみたいなものです。
今日はようやくキャラクター6種類の特性が決まりました。パラメーターはスピード、スタミナ、そして運の3つ。これらをもとに30個の手持ちパネルから選ばれた1つの項目によって行動が決まります。パターンは1〜3マス進むか、その場で足踏み、または1マス後ずさり、そしてスペシャル技のどれかです。それぞれの数はパラメーターの内容によって差がついているというわけです。
スペシャル技はキャラクター固有にするか、いくつかの中からランダムで発動させるか検討中です。明日からパネルのアイコン作りと出た目に応じたアクションの作成に入ろうと思っております。
HSPでゲーム開発…
Windowsで動作するインタプリタ型プログラム言語HSP（Hot Soup Processor）で、年明けの新年会の余興で使うゲームを開発中です。年末の忙しい時期、大きな仕事の合間にちまちまと開発しているので効率がよいとは言えないのだけれど、時間を見つけながらなんとかやっております。
ゲームは馬が走るすごろくのようなものです。昨年末に作って今年の新年会で使ったのが最初のバージョン。突貫工事で開発し完成とは言い難かったので、初夏に会社行事の余興でも使うことになった際に、改良型のバージョンを開発しました。しかし、こちらはキャラクター表示に不具合が出るバグがひどく、2ゲーム目は初期型のバージョンを引っ張り出して、ことなきを得ました。
敗因は、チカラワザを多用しすぎたことです。HSPでは仕事用の文字処理関連のプログラム開発しかしておらず、ゲーム開発のスキルを持っていなかったために、スプライトなどが扱えず、画像の描画するのに背景から表示し直すという無理矢理な方法をとっていたため処理落ちしていたのでした。
スプライトを使うためにHSPのヘルプを見て試そうと思ったのだけれど…DirectXのアップデートしても結局Windows98SEではどうにもならなかったようで試せないでいたのです。
3世代目となる今回のゲームは、ネットブックのHDDをフォーマットしてWindows XP SP3を入れ、そこで開発することにしました。おかげでスプライトの処理も試すことができ、やっと背景を表示した上でキャラクター表示とアニメーションに成功しました。
ただ、キャラクターが256色ビットマップじゃないとダメだということを知らずに試行錯誤したり、透過色が黒（0,0,0）じゃないとダメだということを知らずにとまどったりしております。
今回はキャラクターに個性を与えたり必殺技的なものを用意するなど新たな試みもあるので、できるだけ早く開発を進めたいと思っております。
ただ、キャラクターを描くのが苦手なので…外部に出回るゲームじゃないからと割り切って裏技を使っております。あ、そう言えばゲーム内の音楽もそうでしたね（笑）。
年末用プログラムの改良…
Windowsで動作するインタプリタ型のプログラム言語「HSP（HotSoupProcessor）」で仕事用のアプリケーションを開発し日々運用しております。今回は年1回、この季節に使う年末用プログラムの改良のお話。私にはめずらしく単なるテキスト処理のアプリではなく、テキストのデータを元に対応するアイコンを寄せ集め、ひとつのjpgファイルに加工するアプリについての内容です。
自分の日記を読み返してみると…昨年も今時期にこのプログラムを改良…いや書き直したようです。その時は問題なく動いたのに今年はエラーが出て動かない…。どうやら先方から送られてきたテキストデータに微妙な変更があって、それを私のアプリが認識できなかったのが原因のようです。
ならば…とばかりに自分のアプリのソースを見直してバグ回避の処理を書き加えます。勢いでプログラムのを書いてしまったときは別ですが…普段は後でプログラムを見たときに処理が分かりやすくなるよう、ソース内にできるだけコメントを記述しておくように心がけているので、今回はエラーの発生ヵ所がすぐに分かりました。
1年に1度のプログラムとは言え、もし動かずに手作業で画像を用意しなければならない事態におちいることは避けたいところですからね。無事にプログラムが動作し、処理することができました。
そうそう。年末に向けた大きな仕事がいよいよ佳境。もう待ったなしのところまで来ております。基本的に私の仕事は材料（データ）が集まらなければできないものなので、自分のペースで仕事をこなすのは難しいものがあります。なかには自分でデータも作成して処理する仕事もあるので、そちらを優先させつつ、なんとか作業を進めていきたいと思っております。
【HSP】テキスト整形アプリのアップデート
Windowsで動作するフリーのインタプリタ型プログラム言語「HSP」（Hot Soup Processor）にて、仕事の合間に小さなアプリケーション開発をしております。今回は週に1度、仕事仲間のT女史に使ってもらっているテキスト整形アプリのバグを解消したお話。
いつからだったか、T女史から送られてくるテキストファイルに不備が出始めました。これは私が開発したアプリのバグのせい。テキストファイルを選択するとファイル内容を解析し、データの並び替えを行ってくれるというアプリなのだけれど、テキストファイルの内容は定形なので解析は簡単だったはずが、どうやらいつのまにかテキストファイルの仕様が変わっており、その変化に追従できていなかったようなのです。
まぁ、不備とは言え微々たるものであれば、受け取ったファイルを開き中身を取り出す際に私が少しだけ手を加えれば問題がなかったのだけれど、データの並び替えの順序が正しくない場合もあって、これではマズイなぁと思い、プログラムそのものを書き直すことにしたのでした。
そもそもからT女史が加工する前のテキストファイルは、取り引き先から送られてくるExcelのファイルがテキスト化されているもの。そのデータをT女史が開いて中身を確認、追加・修正をしてから所定の形式に変換して私にくれる手はずになっておりましてて、所定の形式に変換するためにHSPで開発したアプリがそれなりに役立っていたわけです。
このアプリの開発記録を見てみると…過去の私は必要に迫られ急いで作ったようで、バグの処理も甘く汎用性の低い仕様になっておりました（笑）。とりあえず問題となっている整形処理の部分を書き直し解決しました。
EXEファイルにして動作確認…バグは出ていないはずなのに、それでも並び替えたデータがおかしい…。よくよく調べてみれば、先方から届いたデータそのものに間違いがありました（笑）。まぁ、そんなこともありますよね。
