シグナスA-1さんをフォローして、最新情報をチェックしよう!

マイページへ

Ci-enはクリエイターに対して、金銭的な支援を送ることができるサービスです。

投稿記事

2018年 04月の記事(5)

マップチップについて②

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

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

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

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


   ←新規作成チップ         前回のチップ→

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

空中ブロックに関して

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

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

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

意味のないオブジェクト

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


具体的には図にあるような草や花などです。
これらは当たっても何も起きず、地形的に意味を持ちません。
しかし、何もないよりかは遥かに雰囲気を出すことができます。
これはツクールやウディタのマップ講座等でもよく言われていますね。

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

レイヤーについて

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

感想

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

\いいねで応援!/

マップの接続について②

前回に引き続き、マップの接続について試行錯誤していました。
結論から言うと、無事実装できました!

どの案を採用したか

案2の「同じ数字は同じ部屋として扱う(エリアマップで繋げる)」を採用しました。
mapファイルとは別にareaファイルを用意しそれを元にマップを接続しました。
RPGの場合、案3のイベントチップで接続するほうが汎用性が高いのですが、2Dアクションは基本的に上下左右方向にしか移動しないのでその利点を生かすために案2にしました。

具体的には

プレイヤーに今まで使っていた座標(数値座標)のほかに現在いる部屋の番号(部屋番号)を記憶させました。

エリアマップ

  • 数字は部屋番号
  • 赤丸は基準座標(1の場合(4,3))
  • 青丸は自機がいる場所(図では(5,3))

部屋番号と数値座標と組み合わせることにより、現在いるエリア座標を求めることができます。(図の場合(5,3)が現在いる部屋)
この状態で、自機が右に移動すると予め記憶したエリア番号と現在の場所が異なるため、それを元にマップロード&自機の再配置を行います。
ロードするmapファイルは部屋番号で、数値座標やスクロール値も調整します。

感想

このマップ接続の実装以外にも、今まで使ってなかったSceneManagerも実装してシーン切り替えを行うようにしたため今までで一番苦戦しました。
今持っている技術をフル活用したという形ですね。

これでようやく探索型アクションのスタートラインに立てました。
「探索型」と名乗るにはアイテムを配置しないといけないため次はその作業ですね。

そういえば今回いつも先に作っているボス戦をまだ作っていないんですよね...
まぁステージクリア型より重要度は低いので実装はもう少し先になりそうです。

おまけ

Ci-enのプロフィールを更新しました。
意外と長く続けられていて、まだ余裕があるので週2~3ぐらいで記事投稿していこうと思います。

プランに関しても追記しました。
当サークルでは、フリープランでも体験版の先行プレイができるようにする予定です。
スタープラン(有料プラン)もリワードを書きましたが、未だに実装するかどうか悩んでいる感じです。

とにかく体験版公開に向けて頑張っていくのでよろしくお願いします。

\いいねで応援!/

マップの接続について①

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

マップ接続の検討

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

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


数字が書かれている部屋は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回描写しています。


右上のチップを描写する際は、右下のように各番号のチップを用いて描写していす。
理論上は5^4で625通りありますが、接続の都合もあるのでもっとパターンは少ないと思います。
しかし、逆に言えばその数字さえ記憶すればチップの向きを全部表現できます。
(描写時に計算している場合もあります)

まとめ

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

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

\いいねで応援!/

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

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

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

値の設定

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

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

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

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

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

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


上昇時は重力を軽減しているため、下降よりも長いフレームを要しています。
また、上昇にかかる時間は30フレーム以下だということが分かります。
(実際に40フレームで計算していてもっさりしていた)
操作時の体感重さはRe!Fが普通、ゲーム1が軽い、ゲーム2がちょっと重いぐらいでした。

結局

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

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

\いいねで応援!/

記事を検索