余興のゲーム…
Windowsで動作するインタプリタ型プログラム言語「HSP(Hot Soup Processor)」にて開発した余興で使うゲームのサウンド関係が、うまく動作しないことが判明したのは当日の朝のこと。正月休み中に行ったテストではオープニング曲が問題なく再生されていたので、そのほかの効果音については「当日、再生する場所を指定するだけでいいな…」と安心していたのだけれど、オープニング以後の効果音などがまったく再生されないことに気づいたのです。どうやら私の見通しが甘かったようですね。それを解決してことなきを得た…そんなお話。
昨年のバージョンでは、ひと通りのサウンド再生ができていたのになぜだろうか? 今から間に合うのか? 焦る私(笑)。昨年と今年のバージョンで異なるのは、キャラクター表示に関する処理。つまりはスプライトを使ってキャラクター描画を行うようになったこととなんらかの関係があるのかもしれません。ですが…今からその原因を探るのはとても難しいこと。すぐにほかの方法を探さねばなりません。
そこで、これまで使っていた標準命令(mmload、mmplayなど)とは異なる命令を使ってのサウンド再生を試してみることにしました。外部プラグインはできる限り使わないと決めているので、純正のプラグインから拡張マルチメディア制御命令「hgimg3」を選択。そこにあるdmm系の命令を使ってみることにしたのです。
まずは「dmmini命令」でサウンド機能を初期化。続いて「dmmload命令」で再生したいオープニング曲を読み込んでおきます。その後、「dmmplay命令」でオープニング曲を再生…ところが再生されません。調べてみると「dmm」系の命令はBGMはWAVかOGGじゃないと使えないようなのです。私がこれまで用意していたのはオープニングなどはmp3で、効果音がWAVでした。そこでmp3をWAVに変換しなくてはならなくなりました。
Windowsで音楽を簡単に変換できるアプリ…家ではMacを使っているのでよくわかりません。調べてみると「Rip!AudiCO」(http://pino.to/audico/)というのを見つけました。ドラッグ&ドロップで簡単に各種サウンドファイルの変換が可能らしく、本来はシェアウェアですが、機能が制限されたFree版もあります。Free版をインストールして使ってみると、本当に簡単にMP3からWAVへの変換ができました。そして再び「dmmload命令」でオープニング曲のWAVを読み込み「dmmplay命令」で再生。今度はうまくいったのだけれど、使い慣れていない命令なので、今回はBGMを使わず効果音だけでいくことにしました。
で、宴会の余興では…バグが出ることなく動いてくれました。テストでは必殺技が出ることなくあっさり勝負がついたりすることもあったのだけれど、奇跡の展開で拮抗(きっこう)した勝負になり、それなりに盛り上がったのではないかと思います。
HSPでのゲーム開発…バグ取り
宴会の余興で使うすごろくのようなゲームをWindowsで動作するインタプリタ型プログラム言語「HSP(Hot Soup Processor)」にて開発中です。今日は子ども達の協力を得て実際にゲームを行い、その中で発生したバグを修正していく作業を行いました。そんなお話。
すでにあらかたのバグはつぶしてきたので滅多にないのだけれど、何度かゲームを繰り返しているうちに突然発生したりします。やはりテストがしづらい、必殺技使用時などの状況で起こるケースがほとんどで、途中まで進んでいたゲームの内容がリセットされ最初からやり直しになってしまいます。
バグの対処法が見つかっていないため、とりあえずの対策としてゲームの途中経過を随時セーブする機能を付けることにします。こうすれば、かりに本番である宴会の余興時にバグが発生しても乗り切ることができると思います。
あとは…ゲーム音楽のテストがまだです。正月休み中の作業はできるだけ避けたいので、これは当日となる4日、ぎりぎりまでやろうと思っております。
ただ、私が現在、最も懸念していること…それは開発に使ったネットブックでは外部モニターへの出力端子がなくプロジェクターに接続できないため、開発したゲームを別のPCに入れて起動させねばならないため、キャラクターのアニメーションや各種処理が、PCのパフォーマンスに左右される可能性があるからです。うまくいくだろうか…やはり心配です。
ゲーム 開発、一応の完成…
新年会の余興で使うゲームをWindowsで動作するインタプリタ型プログラム言語HSP(Hot Soup Processor)で開発しておりましたが、一応の完成をみました。とは言っても目標とするところまでできたわけではなく、あくまで当初計画した仕様でゲームが動く…ところまでです。さっそくテストを開始したのだけれど…バグが出まくって大変なことになっております。そんなお話。
6種類のキャラクターが20マス先のゴールをめざす、ごろく形式のゲーム。過去のバージョンと比べてキャラクターに個性があり、「1~3マス進む」確率がスピードのパラメータによって変化するだけでなく、スタミナのパラメータによって一回休みの確率が変動。さらには運のパラメータによって後退してしまう確率が変動するばかりか、パラメータの合計値は最大が6なのに対し、スピードとスタミナを1にした代わりに運を4にしたキャラクターのみが、通常ならば30分の1の確率で出る必殺技が30分の2の確率で出るようになっております。
この必殺技の発動時にバグが出まくるのです。何度もテストしているうちに単純なソースの記述ミス(等号、不等号が間違っていたり、変数が異なっているなど)に気付くのだけれど…つぶしてもつぶしてもバグがなくならず難儀しております。とにかく時間を見つけてバグをつぶし、余興に穴をあけぬよう頑張ろうと思います。
宴会用ゲーム開発が佳境に…
色々とせっぱ詰まっていた年末の仕事が終わり、ひと息つく間もなく今週末までに説明書きを配布するためプログラム開発に本気で取り組んでおります。このままですとゲームの完成を待たずにとりあえず説明書きを用意せねばなりません(泣)。現在はどうしても解決しなければならない問題が解決するまで完成のめどが立たない状況です。そんなお話。
Windowsで動作するインタプリタ型プログラム言語「HSP(Hot Soup Processor)3.3」で現在開発中なのは、新年会の余興で使うすごろくのようなゲーム。処理の高効率化をはかるべくスプライト用のアイコン群をひとまとめにして読み込むなどの対応をとりましたけれども、編集と保存を繰り返しているうちにアイコンがきたなくなったため結局、バラバラの状態で読み込む方式に戻しました。幸いなことにパフォーマンスには影響がないようです。
ゲームの過去のバージョンでは1~6種類の登場キャラクターに個性はなかったのだけれど、今回からスピードやスタミナ、運のパラメーターを与えることにしてゲーム性を高めています。各キャラクターにはパラメーターに影響されたパネルが30枚用意されていて、そこに行動が記されております。
たとえば…スピードのあるキャラクターは2~3マス進める確率が高く、遅いキャラクターは1~2マス進める確率が高いように設定してあります。スタミナの有無は、1回休みとなるパネルの増減に関係があります。また、運勢が低いと1マス戻ってしまう後退のパネルが出る確率が高くなります。反対に、運勢が高いと後退の出るマスが少なくなるばかりか、最も運勢が高いキャラクターは後退のパネルがゼロとなり、必殺技のマスが2つ(ほかの5キャラクターは1つ)と確率が2倍になっておりますが、その分ほかのパラメーターが低いため通常進マスは1マスが中心で1回休みの確率も高くなっています。
必殺技は、30分の1または2の確率で技を使用することができ、その技はよいものも悪いものも含めて6種類の中からランダムで選ばれるようになっています。順位を入れ替える技や自分以外を後退させる技もあったりするので、一発逆転も可能です。
昨日までに30枚のパネルのうちいずれかに止まった際の挙動を実装。今日はゴールのチェックとスタート位置での後退のチェックを組み込みました。必殺技のアイコンは今日作成しましたけれども、プログラム上での処理は明日以降です(泣)。正月返上の作業にならぬよう、頑張って開発を進めようと思っております。
HSPでのゲーム開発…続き
Windowsで動作するインタプリタ型プログラム言語HSP(Hot Soup Processor)でゲームを開発中です。馬を使ったすごろくのようなこのゲームは、年明けの新年会の余興で使うもの。スプライトを使ったゲームプログラムは不慣れとあって時間がかかっているのだけれど、キャラクター表示やアニメーションがうまくいったなぁと思えば、とんでもない事態におちいっております。それは表示の遅さです。そんなお話。
キャラクター・アニメーションの表示が遅いことに気付いたのは昨日のお話。ランダム表示しているサイコロの目がゆっくりになり、アニメーションがスローモーションになってしまったんです。単純に処理スピードが追いついていないような感じです。ところがCPU使用率もメモリも余裕があります。単純に描画と処理に時間がかかっているような感じだったのです。
思い当たるような原因としては、キャラクターサイズによって複数のBMP画像を用意、それらを不可視ウィンドウに読み込みスプライトをたくさん使って描画している点でしょうか。不慣れなゲーム開発のためプログラムの中で効率の悪い処理がいたるところにあるはずです。
とりあえず思い当たるところに手を入れてみます。まずはキャラクター画像を見直し数を整理。スプライトで表示しなくてよいところは背景に含めたり違う方法をとるなどして効率を上げます。しかも複数のBMP画像をすべて統合し不可視ウィンドウの数を減らしました。チカラ技で書いた処理も効率よく見直したのだけれど…それでも遅いままです。
もう仕方がないので、処理が遅くなった部分を判別するためプログラムを書き直しつつ検証をしようと思ったのだけれど、もう最初から処理が遅いんです(笑)。「これは今開発中のプログラムが原因ではなさそうだ…」。そう思った私は参考にしたサンプルプログラムのシューティングゲームを実行してみることにしたのです。
すると案の定、滑らかに動いていたはずのキャラクターがスローモーションになっているではありませんかっ。原因はWindowsのシステムそのものだったようです。思い当たるふしはないのだけれど…システムの復元を使って開発環境を整えたあたりまで戻してみると…あっさり解決しました(笑)。こんなことならばソースの見直しなんてしなくてもよかったような気もしますけれども、効率がよくなったことは悪いことではないので、それはよしとします。