次回作について

世間は各種イベントでバタバタしていますが、本サークルはGWに出展できる制作物などあるはずもなく。
ただただゲームの土台を作っている感じです。

次回作＆体験版について

で、そろそろ構想が固まってきたので少しだけ次回作の話でも。
ゲームジャンルとしては前から言っている通り「2D探索型アクション」で例のごとく弾幕要素を入れるので「2D探索型弾幕アクション」になります。
作品形態としては東方二次創作ゲームで秦こころが主人公です。

前からの進み具合としては、アイテムを実装して取得時にステータスが上がるようにしました。
（現在はマップを切り替えるたびに復活します）
また、敵画像をつけたりレイヤー情報を基にしたチップ配置等も行いました。
要するに前作と同じ仕様まで実装できたかな？という程度です。
ただ、探索型アクションとしてはまだ形になっていない感じです。

本当はGWに一気に作り上げて明日にエア例大祭として体験版を出したかったのですが、思ったよりも進捗が悪くて...
さすがに作り始めてから約一ヶ月なので間に合いませんでした。
よくよく考えると前作も2ヶ月半かけて体験版出していたので、C++の勉強＆新ライブラリの時点で無理な予定でした。

今後の予定

今後の予定としては以下のようになります。

• 自機の攻撃方法の追加
• 独自の自機システムによる攻撃方法の変化
• アイテムの種類の追加＆保存
• 雑魚敵の種類の追加
• ボス戦の追加

これが全て実装できたら自信を持って体験版を出せますが先はかなり長くなりそうです。
プログラムだけならまだしもグラフィック、BGM、SEとまだまだタスクが残っています。
ある程度タスクを消化した段階でプロトタイプとして出してもいいのですがプレイヤーとしてはどうなのかなぁ？と気になるところです。

こんな感じでやっていきますので見守っていただけると幸いです。

マップチップについて②

前回の記事ではマップチップはタイル上でオートタイルという技術もあるよ！という話をしたところで続きを。
今日は説明だけではなく、気づいたこと＆実際にやったことが主です。

2Dアクションにおけるマップチップについて

通常、RPGで使われるマップチップはトップビュー（上から見た図）用の素材です。
そのため、前作ではそれに習って作っていました。
具体的には線対称＆点対称な形をしています。

しかし、よくよく2Dアクションで使われるマップチップを良く見ると、上部だけ加工されているマップチップがあることがわかります。
それを踏まえた上で、マップチップを描いてみました。

このようにすれば上部だけ違う印象を与えることができます。
サイドビューで見た場合、確かに「道」として存在するのは上部だけであるためこのような表現の方が適しているとも言えるでしょう。
場所にもよりますがこんな感じでマップチップは作っていきます。

空中ブロックに関して

探索型アクションでは雰囲気を出すことが重要になります。
そのため、2Dアクションでよく用いられる「空中ブロック」はあまり多用しないほうがいいと考えました。

例えば、左のブロックの配置などは2Dアクションではよく見る配置です。
しかし、じゃあなんでそこにブロックがあるのか？と聞かれると答えることが困難です。
機械的や幾何学的なものならまだしも自然物が上部にあるのは考えにくいです。

そのため、中央のように地上から繋げれば段差だとすぐに分かります。
この場合、ブロックではなく上に乗れる床なので当たり判定は異なります。
同じ当たり判定にする必要があるならば右のように奥側に背景を置くことで解決できます。
これで奥から手前にブロックが飛び出ているとすぐに分かります。
こういうちょっとした工夫が大事なんじゃないかなーと思います。

意味のないオブジェクト

ゲーム雰囲気を出す方法には重要な要素があります。
それは、システム的に何の意味もないオブジェクトです。

で、この事実自体は前から知っていたので前作でも積極的に配置するようにしていました。
しかし、システム的に1つ問題があったのです。
それがレイヤーです

レイヤーについて

レイヤーとは同じ場所に重ねることができる機能です。
これがあることによってレイヤー1に地形、レイヤー2に草を置くことで重ねることができます。
しかし、前作では時間不足＆技術力不足によりなんとレイヤーが1つしかなかったのです！
さすがにこれはマップ設計上大きな足枷となるのでここ最近はこれを頑張って実装していました。
アイテムも並列で実装していますが、より優先すべき内容だと判断し先に終わらせました。

感想

マップ設計っていろいろ考えることがあるんですね...
プレイヤーとしてゲームに触れている間はこんなこと気にも留めていませんでしたが、いざ実装してみると物足りなさから気づくことが多いです。
自分が作成できる元画像は決して上級とはいえない分類なので、表現方法を工夫してグラフィックの質を向上させたいですね。

マップの接続について①

次の作品は探索型アクションゲーム（別称：メトロイドヴァニア）を作ろうと思っています。
しかし、効率のいいマップの保存方法が分からずマップツールを拡張できずにいます。
というわけで思いついた案を列挙してみます。

マップ接続の検討

例としてエリアマップが下のようなゲームを作るとします。

• 緑:部屋
• 黄色:部屋と部屋の接続

案1:全ての部屋を大きさ固定の部屋で分ける

違う数字でも同じ数字でも全部違うデータとして扱います。
例の場合、画面サイズ固定の14つの部屋があります。
マップロード時に同じ部屋番号を全部ロードし、エリアマップを元に繋げ合わせます。
無駄なデータが出ない分、ロードが複雑化する、マップ配置が大変になります。

案2:同じ数字は同じ部屋として扱う（エリアマップで繋げる）

番号によって大きさが違う部屋に分けます。
例の場合6つ部屋があります。
（1:5×1　2:2×1　3:1×1　4:1×3　5:1×1　6:2×1）
データ数として6つでマップ配置もし易いです。
部屋移動はエリアマップを元に行います。

案3:同じ数字は同じ部屋として扱う（イベントチップで繋げる）

案2と同じく6つ部屋として扱いますが、エリアマップを元に移動を行うのではなく、各部屋にイベントチップをおきます。
例として、3の左端には1の右端に移動するように指示、3の右端には4の上段左端に移動するように指示します。
ウディタでも使用されているマップ移動方法で、最も確実な部屋移動です。
エリアマップとは直接的な繋がりは持ちません。（あくまで地図画像としてのみ）

案4:全部同じ部屋として扱う

例の場合、9×4の大部屋が1つあると仮定します。
それぞれに仕切りを設定してロードし、ブラックアウトの有無の仕切りで判断します。
無駄なデータが多く出る(14しか部屋がないのに36部屋分のデータを消費）上にロードが複雑化するためこれはよくないかなと。

というわけで

誰かいい方法知っていませんかという話です。
ステージ突破型アクションなら一方通行なので考えなくてよい話だったのですごく苦戦しています。
自分の頭では案1～4ぐらいが限界だったのでもっと効率のいい保存方法があるかもしれません。
詳しい情報がある本やサイトを教えていただくだけでも構いません。
よろしくお願いします。

マップチップについて①

昨日今日とクラスのカプセル化を行いました。
すごく大変だったのですが後になればなるほど作業量が増えるので早めに行いました。
具体的に書いてもいいんのですがおそらく大半の人には意味不明なので、要約すると前作で苦戦していたプログラムの問題が解決しました。
すなわち、ゲーム拡張が楽になったのでギミック追加やボリュームアップがやりやすくなったということです。

と、こんなこと書いていてもプレイヤーとは関係ないのでマップチップの話をします。

マップチップとは

マップは1つ1つのチップを組み合わせて出来ていて、それに使うチップをマップチップと呼びます。
マップタイルとも呼ばれていてそちらの方が分かりやすいかもしれません。

ちなみにこの画像は自作ソフトの画面です。（初公開！）
敵やアイテム、リフト等も設定できますが、一般的には地形の部分だけですね。
それぞれのチップを見ると様々な角度に対応するために多くの種類が必要かと思われます。
しかし...

オートタイル

実は地形部分で描く画像はなんと5種類だけで十分なのです。

描写するときは1チップにつき4回描写しています。

まとめ

オートタイルってすげー！
もともとはRPGツクールやウディタなどトップビューで使用するものですが、自分はサイドビューでも使えるじゃね？と思い使っています。
それらのツールは使ったことありませんが、とあるゲームの制作生放送を見てオートタイルの使い方が分かったという話です。
まぁ最初は5種類しか向きないじゃん！って思いますよね。（多分）

今回もこれで表現しようかなーと思っています。
そこで、ちょっと気づいたことがあったのですが今回はここまで。
①があるなら②もありますよー

2Dアクションにおける重力

最初の記事ですが、ちょっと難しいお話でも。

今日は自機にかかる重力の調整をしていました。
一般的にジャンプ時に速度を与え、重力加速度を設定すれば自然な放物線になります。
しかし、2Dアクションではジャンプキーを押す長さによって最大高度が変わります。
つまり適切な処理を入れなければジャンプの高さを変えられません。

値の設定

とりえあず小ジャンプと大ジャンプで必要な値を設定しました。

• 小ジャンプ：64px以上
• 大ジャンプ：256px以上

設定する値は以下の通りです。

• 重力加速度
• 重力加速度(上昇時)

一定時間の間は、ジャンプキーを押している間だけ重力が小さくなります。
この条件のみで試行錯誤していましたが、なかなか上手くいきません。
で、ジャンプにおける大事な要素は何かと考えた結果、ジャンプ時間ということに。
1回のジャンプであまりにも時間がかかると大きくテンポが失われます。
といっても感覚じゃよくわからないのでちょっとだけ他のゲームを調査しました。

各ゲームの最大ジャンプ時の所要フレーム

結局

上昇30フレームで調整するために、初速度を大幅に上げました。
しかし、それでは最小64pxにするにはすごい重力が必要です。
そこで、キーが離されたときに速度を下げるようにしました。
そんなこんなでジャンプ処理はとりあえず終わったかなーという具合です。
これを決めないといろいろ決定できないのでまぁ早めにやりました。

ゲーム画面を見せられなくてすみません。
まだ図形や仮画像なのでもう少しだけお待ちください。