カテゴリー: 自作ゲーム

書く内容は色々とあるものの気を抜くと11月も終わりになってしまってこれはよくない。
今はブラックフライデーのセールの真っ最中ですね。
最安値ではありませんが気になるので多分自分が買うのはSpectre。

---

前回Unityでレースゲームを作る話を書きましたが、その後シェーダーのポストプロセスを使ってみようと思い立つついでにUniversal Render Pipelineによる描画に切り替えてみました。

まず導入としてパッケージをインストールして、デフォルトのマテリアルのシェーダーを全てURPのものに置き換えていきます。
この作業が手間なので移行するなら開発の初期段階がいいわけですね。

そして組み込みのポストプロセスが機能することを確認した後でカスタムポストプロセスの組み込みに入りました。
導入にあたって参考にしたのは以下のページ等（どちらもQiitaで見つかった）の記事。

• 【Unity】UniversalRPでカスタムポストプロセスを作る【ZoomBlur】（ポストプロセス）
• 【Unity】URPを拡張して、Normal描画パスを追加してみた（オブジェクトのカスタム描画パス）

そして色々と試行錯誤しながらフォグと輪郭抽出エフェクトを加えてみた動画が以下。
輪郭線の計算はRoberts Cross法で。

割としっかり輪郭が出ていますね。
輪郭線がフォグに関係なく抽出されているので、背景の山が盛り上がる様子がリアルタイムで見えてしまっています。これはこれで面白いかも？
ただこの方法で輪郭線を描くとピクセルごとの判定になるため、解像度が高くなると相対的に線が細くなっていく点が難しいところかも知れません。

もう9年か10年前くらいになりますか、レースゲームを作りかけていたことがあります。
OpenGLで作っていて、コース4つとCPUの動きまで出来ていたのですが、それ以降のUIまわりの対応や自分の技術的問題で公開できないままとなっていました。

今でもそのゲームに未練がありまして、何ならUnityを使えば当時よりもはるかに作りやすいんじゃないのと思い立ちました。
そして先日Twitterにも投稿した動画がこちら。

……いかにもUnityですね。まずは動くことが大事。

当たり判定の計算の都合で平らに見える地面でも派手に跳ねていますが後々空を飛ぶ予定なので（恐らく）問題なし。
Terrainで地面を作ってブロックを置くくらいならだいぶ楽に作れますね。その割に当たり判定にやや苦戦しました。
以下ごく基本的な内容ですが、自分が試した方法を書いてみます。

続きを読む レースゲームリメイクへの道

今年の正月の休みにLÖVEを使って大量のオブジェクトの当たり判定を行うテストを作ってみました。
やっていることは（検索で上に出てくるところの解説が親切な）四分木での判定です。

850個の丸を動かしてみたのがこれ。

実際に自分で試したことが無かったのと言語の都合上ビット演算が使えなかったりでわりと苦戦しました。
全てのオブジェクト同士で比較を行うと毎フレーム約36万回の判定を行う必要があるところ、四分木判定で大体1/6くらいに回数を減らすことができました。丸の大きさが小さいとさらに判定回数が減ります。
座標の計算等に無駄は多そうですが、今の状態でもそれなりに速くなったので成功と言えそうです。

しかしこの四分木判定だと、画面の中央に丸がある場合は領域を分割できずに全ての丸との判定を行う必要が出てくるので、真ん中に大きいオブジェクトが固定される場合に少し弱そうですね。
それでも十分使えることが分かったので、アクションとかシューティングゲームを作るときには今後取り入れていきたい所存。

前回Waveファイルのサンプリングレート変換らしいことをしてみたので、次はビットレートの変換もできるようにしました。ビットレートというよりはビット深度ですか。
前回軽く解説的なことをしたので、今回もメモ的に残してみます。とはいえややこしいところは少ないので、周波数の変換に比べればだいぶ楽ですね。

Waveファイルのフォーマットではだいたい8ビット、16ビット、24ビット、32ビットの4種類が使われていて、
それぞれsigned char, short, int, floatの型で表すことができます（32ビット整数型もありますがややこしいのでスルー）。

それぞれのビットレートで持てる値の範囲は以下の通り。

8bit

0 ～ 255

16bit

-32768 ～ 32767

24bit

-8388608 ～ 8388607

32bit float

-1.0 ～ 1.0（範囲外の値も持てる）

基本的に値が0の時に無音なのですが、8ビットのみ128で無音になるので注意が必要ですね。

続きを読む ビットレート変換の段

今作っているゲームでは音声の再生にWASAPIを使ってみているのですが、
PCの設定次第で出力される音声フォーマットが違うのでそれぞれ対応する必要があることに気付きました。

用意している音声データは16bit/44100Hzで、同じ出力フォーマットの環境だと問題ないものの
HDMI側の音声出力を使ってサウンドコントロールパネルから16bit/48000Hzの形式に変えると音が間延びして再生されます。
これを正しく再生させるための対応として、44100Hzの音声データを別のサンプリングレートに変換する必要が出てきました。
Unity等だとこの辺りは自動でやってくれそうですね。

というわけでサンプリングレート変換の方法は大まかに下の二つの模様。

• 音声データをn倍したり1/nに間引く
• フーリエ変換して周波数成分を取り出し、逆変換して戻す

……このあたりの知識はあまり無いのですが、後者の方法は見るからに大変そうな上にちゃんと戻せるのか不安なところがあります。
というわけで前者の方法を取ることにしました。（10/4 フーリエ変換の方法を試してみました）
続きを読む サンプリングレート変換の段

もう5月も終わりですね。
COVID-19による緊急事態宣言も一往は解除されたということで、徐々にステイホームしなくてもいい感じになりますね。しっかり手洗いをしたり適度に距離を開けたりといった自己防衛は引き続き大事です。

自宅にいる期間が長かったこともあり、去年の5月にほんの少しだけ作りかけて放置していた音楽ゲーム（予定）の続きを進めてみました。
ひとまず曲を読み込めて演奏できるところまで。曲はアレっぽい風味でとりあえず。

……動画で見ても分かりにくいかもしれませんが、譜面のスクロールは手動で行う形です。曲の現在の演奏箇所も基本的には表示されず、練習時のアシスト機能としては自動スクロールと合わせて表示できる形にする予定。

この動画の状態からスコアの計算を入れたら一往は音楽ゲームらしい形になりそうです。多分。
続きを読む 音楽ゲーム作りの段

スマートフォンから記事を更新するようになったとは言うものの、電車やバス等で長めに座っている時間が無いとなかなか更新できませんねー。
書こうと思っている内容は溜まっているくらいなのですが、時期を過ぎてしまうとさらに動きづらくなるという。

先日、所謂Lo-Fi的な感じの曲を試しに作ってみました。

boorx-lのステージとして作ると効果音で不協和音のような音が生まれる点はどうしようもないですね。
効果音もランダムでいくつか鳴らす形なので、曲に展開があってもそれに合わせて変更することができないという問題もあります。
展開をつけられない故に1分くらいの曲をさくっと作って組み込めるというあたりは利点。
曲を作った段階では効果音について考えていないので蛇足となりがちなあたりは難点。

続きを読む Lo-Fiというもの

完と云うか一区切りですけれども。
前回で基本的な図形を描画できるようになったので、数年前にDirectX10で作りかけたアクションゲームを同じくらいのところまで作りかけてみました。

ゲームとして作るなら探索系かなーと思っていたところ、新作の海腹川背Fresh!が既に探索系なのでした。ちょうど今日体験版が配信開始とのこと。Switchを持ってる方はチェック。

非常に遅々としていますが、DirectX11でのスケルトン？作りをまだ進めています。
本当は前回のものを作った時点で以前作りかけたアクションゲームを移植してみようかと考えていたのですが、
単純に置換するだけではどうにもならず二進も三進もいかなくなってしまったので、改めて一から作ろうと思いなおしました。
作業の半分以上は車輪の再発明である。

そして現在の状況がこちら。

……何だかよく分からない状態になっていますが、回転する立方体2つと板2つを用意して

• 全画面をビューポートにした立方体2つ
• 小さいビューポートで違うカメラから見た立方体2つ
• 最前面に色を付けた板2つ

を描画しています。違うレイヤーで順番にオブジェクトを描画するみたいな。
続きを読む 続々・DirectX11