2015年10月31日土曜日

ハロウィンゲームをハロウィン当日ぎりぎりリリース(・`ω・´)

急に冷えてきてもう眠いけど
ハロウィンのうちにブログを書きたいので頑張ります(´ぅω・`)

先月下旬あたりから作り始めたゲームをついにリリースできました!
タイトルは「胡桃坂(くるみざか)ハロウィンパーティ」です。

胡桃坂ハロウィンパーティ:無料ゲーム配信中! [ふりーむ!]



いつものようにBGMと効果音は「フリー音楽素材/魔王魂」様の素材を利用させていただきました。
特にメインのBGMがすごくハロウィンっぽい雰囲気を出してくれています。

先月からのブログを見ている方には見慣れた画面かもしれませんが、このラスト10日間で劇的な速さで実装が進んだ気がします。

システムを使うためのデータ作り


キャラの描画やマップ移動のシステムが大事なように、話したりアイテムをくれたりするNPCの設定も大事です。
矛盾がないようにフラグを管理しながら、NPCを追加していきました。
衣装を細かいものまで数えたら53種類になっていましたが、それをどのように配置するかなども悩みました。
そのためのクエストやミニゲームへの自然な流れなども作っては少し修正して作りました。
プログラミングとは違った難しさがありましたが、短いストーリーを考えるのも楽しい気がします。

にぎやかしのNPCの配置


某人探しのカリスマ的な絵本「○oー○ーを探せ」とまではいきませんでしたが、各マップに40体のエキストラ的なNPCを配置しました。
このNPCはにぎやかさと人探しのゲームのために配置しているので、話したりはしません。
それでもいろいろな衣装をつけて配置するのは、割と気合と時間がかかりました。

ミニゲーム「魔女のゲーム」の実装


ミニゲームは以前のブログでも追加したいといっていたのですが、実装したのはリリースの3日前くらいです。
半ば諦めていたのですが、勝手に脳内でこんなん作りたいと仕様が少しずつ固まってきていたのでほぼ1日で作ることができました。
基本的なシステムは通常のマップと同じですが、マップの雰囲気やリアクション(話しかけるとAIがランダムから一定の場所に向かうようになる)の変化という末端の部分の追加だけですんだのもスムーズにいった要因だと思います。

列車も動いたよ!


列車の絵は用意していたのですが、実装の優先度を低くしていたので、リリース前日まで実装していませんでした。
でも、テストでプレイしているうちに、線路があって「TRAIN」という看板もあるのに、列車がこないのもなんだか変だなと思うようになり、やってみたら意外と簡単に実装できました。
単純に、絵を位置をずらしながら描画するだけなので今思えば簡単でした。

あとは、マップの当たり判定や重ね合わせの微調整をしました。
まだまだ粗はありますが、壁に飲み込まれるようなこともなくなり、だいぶましになりました。

何とかハロウィンに間に合ってよかったです。
しかし、間に合わせるために睡眠不足が続いているので明日は超だらけたいと思います。

コンテストにも何とか間に合った


まだ結果は反映されていませんが、HSPプログラムコンテストにも参加の申請をさせていただきました。
HSPはちょっとしたツールを1回作ったことがありますが、触れた日数はトータルしても3ヶ月を超えないと思います。
それでも、さくさくとGUIのアプリケーションを作れてしまうのが便利だと思います。

間違い探し?


コンテストのほうへ提出したものはすぐに直したんだけど、ふりーむ!に出したほうは審査中だったこともあり直していない点があります。
起動するためのショートカットのファイル名が胡桃坂ではなく胡桃沢になっています。(´・ω・`)
とはいっても、ゲーム内の要素ではないし、ちょっとした間違い探しとして笑ってもらえればそれはそれで良いかと思いました。
胡桃坂(くるみざか)という名前は架空のショッピングモールの名前を考えていたときになんとなく思い浮かんだ語呂のよさそうな名前でハロウィンシーズンぽいかなと思い決定しました。
ただ、いろいろとてんぱった状況で胡桃沢になってしまったみたいです。
それではおやすみなさい。ハッピーハロウィーン(ゝω・)v

ニコニコのほかに youtube にもあげてみたよ。

2015年10月21日水曜日

ハロウィンに間に合いたいHSPゲ製の経過報告

先月始めたころは、1ヶ月あるから何とかなるでしょうと思ってたけど
ハロウィンまであと10日を切ってしまいました。
ここ10日間くらいは、ブログを書く余裕もない感じでした。

そもそも、まだキャラの素材がぜんぜん足りてなかったり、マップも調整必須な状況です。
でも、21:30を過ぎるとプログラミングの速度がものすごく低下することが最近わかってきたので、
その時間を有効利用してブログを書こうと思います。₍₍ (ง ˘ω˘ )ว ⁾⁾
#明日のこの時間はFFの新作アプリが出るからそっちをやりたい。。。

進捗報告


製作途中ですが、動画をとったので宜しければご覧ください。
テキストで説明するよりも、どんな感じに作っているかがわかりやすいと思います。
音楽と効果音は「フリー音楽素材/魔王魂」様の素材を利用させていただいています。
いつも思いますが、音楽をいれるとゲームの雰囲気が格段にあがります。


動画のとおりですが、次のような実装をしました。

・PC(プレイアブルキャラクター)のほかのNPCを配置して勝手に移動するようにした。
・HSP3Dish 対応をした。
・マップを4つ作った。
・マップに配置したポータルで他のマップへ移動できるようにした。
・花火のエフェクトを追加した。

NPCを移動させるのは、スプライトを表示する機能を前回の段階で実装していたので簡単にできました。
移動とはいっても、ランダムな方向に毎回1歩進むだけです。
PCと同じように移動できるかどうかの衝突判定をしています。

HSP3Dish 対応


HSP3Dish 対応は、なんで最初からやらなかったのヽ(`Д´#)ノ ムキー!!という感じになりました。
HSP3Dish でリリースしたいという人は、最初から #include "hsp3dish.as" をいれて開発するといいかもしれません。

主に困ったのは画像の扱いです。
HSP3Dish でない場合は、アルファチャンネル付きの画像を描画するときに、アルファチャンネル用の画像をRGBの画像の隣に配置して gmode 7 で転送します。
これが、HSP3Dish では便利になって、 png のアルファチャンネル付きの画像をそのままバッファ読みこんで使えるようになりました。
便利なのですが、最初に HSP3Dish ではないやり方を使っていたため、画像転送のロジックやら、画像自体もアルファチャンネル付きに加工する手間がかかりました。

画像関係でもうひとつ、原因がはっきりわかりませんが、 picload ではうまくアルファチャンネル付きの画像が扱えず celload を使うことになりました。
picload と違い、ウィンドウバッファのサイズを変更せずに読み込むことができません。
picload を使っていたときは、細かな画像をぺたぺたとウィンドウバッファにはっていたのですが、それができないので、あらかじめバッファに対応する1枚の画像として用意することにしました。
スクリーン(#0)以外のウィンドウバッファの編集が制限されていることと関係しているのかもしれません。

もうひとつは、 mref 66 により VRAM のピクセルデータを見ることができなくなったことです。
前回書いたように、当たり判定は白黒の画像の画素値で判定しています。
pget で配列にコピーしようと思いましたが、毎回マップ読み込みで行うのも時間がかかるし、実際に試してみたら HSP3Dish には対応していないようでした。
そのため、画像をバイナリファイルに一度変換して、それを bload で配列に読み込んで使うようにしました。

HSP3Dish は制限はあるもののスマホやウェブブラウザでもソフトを実行できるようになることが魅力的だと思います。
あと、音量調整の mmvol という便利な関数もあります。

マップの実装


マップの絵を描くのはすごく時間がかかりました。
うまいとは決して言えないのですが、そこは百も承知です。
ただ、下手なりに丁寧に書こうと頑張りました。
1日1マップが限度でした。プログラミングとはまた違う疲れがでてきます。

ポータル移動は、ポータルをスプライトで実装して、zキーを押したときに、ポータルが近くにあればそのポータルに対応したワープ処理をするようにしました。
動画ではわかりにくいのですが、最初は使えないポータルが、緑の服を着たNPCにzキーで触れるとポータルが有効になるようにしています。

花火の実装


これは、エンディングで使おうと思っている花火です。
小さな星がつくことでかなり花火らしくなりました。

全体的に薄暗くして夜っぽい感じにするには、 gmode と grect を使います。
この命令で半透明の矩形を描画して簡単に薄暗くすることができました。
 参考:画面を暗くしたい - HSPTV!掲示板

gmode 3, , , 100
color 0, 0, 64
grect x, y, 0, width, height

これだけで、少し青っぽいうすぐらい感じになります。

今後の予定


キャラがまだお団子キャノンの主人公しかいない状態なので、キャラを増やそうと思います。
それと、マップも壁にめりこんだり、重なり方が不自然なところがあるので当たり判定などを調整します。
それと、できたらミニゲームをさらに追加したいと思っています(これ自体ミニゲームですが…)
ハロウィンの日まで間に合うか微妙ですが頑張ります(`・ω・´)ゞ

2015年10月11日日曜日

HSPでマップをスクロールさせてみた

先日は、アニメーションするスプライトを作ってマップをうろちょろさせました。
今回は、そのマップをスクロールする機能を実装しました。


テスト用のアプリケーションでは、スプライトではなく円を塗りつぶしたものを移動させています。

そんなに大きくないマップですが、スクロールすると広く感じたり探検気分がでてきた気がします。
スクロールってわくわくするね₍₍ (ง `・ω・´ )ว ⁾⁾

スクロールの処理の概要


赤線の枠は、フレームと呼んでいます。
フレームはスクロール機能の設定値で、この枠からはみ出す場合にスクロールします。
追跡対象が枠の中で移動している間はスクロールはしません。
ただし、スクロールの範囲はマップ画像の範囲内です。

描画処理は前回書いたとおり、背景、キャラ、前景の順番で描いています。

描画のあとで、キー入力に応じて、キャラの移動先を決めます。
障害物があれば移動はしません。

障害物の判定


障害物の判定は、次のような当たり判定用の画像の色情報で決めています。
移動先の座標の色を取得して、色が黒でなければ移動します。
HSP には pget という色を取得する関数がありますが、
それより高速に行う方法が紹介されていたので、そちらを試してみました。
参照:buffer上の特定の1色の座標(1点)の高速検索方法は? - HSPTV!掲示板

mref bufVram, 66
で、変数に操作中のウィンドウの画像が割り当てられます。
あとは、 peek を使って bufVram の色情報へアクセスします。


idxVram = ((heightBuffer - y - 1) * widthBuffer + x) * 3
_b = peek(bufVram, idxVram + 0)
_g = peek(bufVram, idxVram + 1)
_r = peek(bufVram, idxVram + 2)

widthBuffer, heightBuffer はウィンドウのサイズです。
VRAM はボトムアップの 24bit ビットマップ形式になっています。
 参照:VRAMデータについて - HSPTV!掲示板

当たり判定用の画像は、だいぶ雑なので壁に少しのめりこんでしまいました。
このあたりは、今後微調整していこうと思います。

スプライトの描画順の改善


そういえば、スプライトの機能のテストをしていて、あれからひとつ改良しました。

キャラが複数重なる場合、手前にいるキャラをあとで描画する必要があります。
そのために、キャラの Y 軸の座標の値でキャラをソートする処理を実装しました。
これについては、 HSP の wiki で提供されているヒープソートの処理を参考にしました。
 参照:Module/ヒープソート - HSP開発wiki

Y軸の座標の値が小さいものから昇順で描画することで、違和感なくキャラを重ねられるようになりました。

予定


次回は、スプライトの機能と今回のスクロールの機能をあわせて、複数のキャラが移動しているマップをスクロールしながら移動したいと思います。
キャラももうちょっと種類を増やしたり、かわいくしたりしたいです。

2015年10月7日水曜日

HSPで作っているゲームでキャラが動くようになったよ!

ノーベル賞すごいね!
昨日と今日と続けて日本人がノーベル賞に選ばれていて、ニュースが楽しい。
世界の多くの人類や家畜を救う研究とか知らなかっただけですごい人が日本にいるんだなぁ。
ニュートリノに重さがあったとか、その分野の人にとっては大ニュースなんだろうなぁ。
ヒッグス粒子が重さの粒子とか聞いた気がするけど、それと関係あるのかな?

科学番組は好きだけど、
結局なんとなくしかわからない SakuraCrowd です。₍₍ (ง ˘ω˘ )ว ⁾⁾

進捗報告


先月下旬から作っているゲームなんですが、
マップの上をちょこまかとキャラが移動する仮組みを作ることができました!
ヽ( ´¬`)ノ ワ~イ !!


やしの木とかの前景にはキャラが隠れるようにしました。
あと、おおざっぱですが当たり判定をいれて、障害物がある場所は通れないようにしています。
移動は上下左右にななめを加えて8方向に対応しました。

パソコンもソフトウェアも進化しているらしく、高速化を意識していない処理でもさくさく動きます。ヽ( ´¬`)ノ ワ~イ !!
とはいっても、あからさまに無駄な処理はしないように注意しながら作りました。

おおざっぱな流れをいうと、

  1. 背景画像を描く
  2. キャラクタを描く
  3. 前景画像を描く
  4. 矢印キーの入力を調べて、キャラクタの向きと位置を変えたりする。
  5. 一定間隔でキャラクタのアニメーションのフレームを切り替える

この繰り返しです。

キャラクタは先日のブログに書いた方法で、パーツを重ねて描いています。
前景画像もキャラクタと基本的な処理は同じです。

入力処理


入力処理についてだけ、新しく追加したのでコードを抜粋します。

// 矢印キーにより移動させる
stick key, 15
dx = 0: dy = 0
if key&1 : dx -= 8
if key&4 : dx += 8
if key&2 : dy -= 8
if key&8 : dy += 8
if (dx != 0 or dy != 0) {
ScSpriteMoveBy IDX_SPRITE0, dx, dy, 1, idxPartAtariMap
}
await 33

stick という標準命令で矢印キーの入力状態を取得して、上下左右ごとに押されていたら移動量を変化させています。

ScSpriteMoveBy は自作の命令です。
当たり判定をして、障害物がない場合は指示されたとおりに移動します。


移動のときに進行方向を向くようにしています。

stick の第2引数


stick の 15 という引数は、押しっぱなしを入力として受け取るかを決めるマスク値です。
stick key, 15 だと矢印キーを押しっぱなしで、キャラクタが移動します。
stick key, 0 だと矢印キーを連打して1歩ずつ移動させないといけません。

stick では、ビット単位で入力の有無を表しています。
下位1ビットが左、2ビットが上、3ビットが右、4ビットが下です。

15 はバイナリだと 00001111 となり下位4ビットが全て 1 の状態です。
つまり、上下左右の矢印キーについては、押しっぱなしのときに入力を受け取る設定です。

stick は通常は押された瞬間しかビットを1にしません。
押しっぱなしだと、押された瞬間以外はビットは 0 です。
これが、マスクを指定すると、それに対応したビットは、押しっぱなしの間でもずっとビットが 1 になり、押されていることがわかります。

そういえば stick のほかにも2つほど便利な命令を見つけました。

便利な命令 await


入力処理にもでてきている await という命令は、 wait と似ていて指定した時間だけ待機します。

便利な点は、前回の await 終了時点からの経過時間を計測することです。
wait では wait 33 とすると呼び出しから 330 ミリ秒待ちます。

1回目の await が終わった後、処理に 15 ミリ秒かかったとします。
その後 2 回目の await 33 とすると 33 - 15 = 18 ミリ秒だけその場で待機します。
これにより FPS を簡単に管理することができます。
それと await は wait より 10 倍精度が高く指定でき、 1 ミリ秒単位で指定できます。

便利な命令 redraw


もうひとつの便利な命令は redraw です。
たくさんの描画処理を直接スクリーンにすると、画面がちらついて表示されます。
そのため、バッファに描いてから、完成したバッファの画像をスクリーンに転送するダブルバッファリングなどがあります。
しかし、 redraw を使うことでダブルバッファリングをしなくてもちらつきを防ぐことができます。

具体的には、
  1. redraw 0 // スクリーンに描画処理を反映しない
  2. 任意の描画処理
  3. redraw 1 // スクリーンに描画処理を反映する
というふうに、ちらついてしまう描画処理の間に redraw をはさみます。
redraw は gsel で選択しているスクリーンのみが対象になるので、 redraw の前に gsel でスクリーンの番号を指定したほうがよいです。

予定


次はマップをオートスクロールしたいと思います。

ハロウィン期間中にリリースしたいけど
絵も実装もまだぜんぜん足りないよおおお。。゚(゚´Д`゚)゚。
なるようになるか₍₍ (ง ˘ω˘ )ว ⁾⁾