【Unity】DOTweenのDOCounterは使い方に注意が必要

憑りつかれる

帰宅したらゲーム制作しようブログのネタを考えよう、と心に誓うのに、帰宅後は何故かPSのコントローラーを握り、狭間の地を彷徨っている皆さんこんにちは。前作のダークソウルではゲーム内で「ソウルに憑りつかれる」というセリフがよく使われていましたが、まさにエルデンリグに憑りつかれている状態なのかもしれない。

DOCounter

DOTweenのPro版(有料版)には無料版には無い便利な機能が幾つかあり、その中の一つにDOCounterというAPIがあります。
これはTextMeshProでint型によるカウンターが実装できるAPIで、例えばSTGのスコアや、RPGの経験値等の値が変わる際のアニメーションを作るときに有用なAPIです。

現在の値=10000から新しい値=30000に変わるアニメーション

上のソースコードで分かるように任意の時間で値を変化させられるので、変更したい値＝変更する時間とすればカウントアップ(ダウン)タイマーとしても使えるかと思ったのですが、そのような使い方をしたい場合はちょっとだけ注意が必要なようです。

カウントアップ(ダウン)タイマー

経過時間や制限時間を表示させるタイマーを作る場合、1秒間で数字が1加算(減算)されれば良いので、0→60に変化させたい場合は動作時間に60.0fを指定すれば良い(EasingはLiner)という事になります。

では、実際にどうなるか見てみましょう。比較としてFixedUpdateでTime.deltatimeから計算した経過時間を上に表示します。

う～ん、明らかにカウントが早いです。実際の時間より0.5秒ぐらい早いタイミングでカウントがアップされています。

恐らくDOCounter内では時間の経過をFloat型で計算しつつ、TextMeshProにInt型で引き渡す際に四捨五入して引き渡しているのでしょう。

試しにDOVirtualを使ってInt型の数字を同じようにカウントアップさせて比較しましたが結果はどちらも同じタイミングでカウントアップされます。

どちらも0.5秒ぐらい早い

まぁ、DOVirtualはFloat型でも数字を変更できるのでFloat型でカウントアップさせてInt型にキャストすれば正確にカウントアップタイマーとして動作します。

こうすれば・・

DOVirtualを使ったほうは正しくカウントアップされます。ではDoCounterではどうするか・・・

対処法はなし

元も子もない結論ですが、、DOCounterは残念ながら指定できる数字はInt型固定なのでDOViratualのような対処はできません。

暫定的にSetDelayで0.5秒開始を遅延させる対処を取れば表示の問題は解決します。

が、OnCompleteのコールバックでタイマーの終了を検知して処理をしたい場合はDelayを設定した分、完了タイミングがずれてしまうので根本的な解決法にはなりません。

DOCounterはタイマーとして使用するのでなく、時間経過とは関係のない値の表示に使用した方が良いと思います。

【Unity】Timescaleを変更しないRigidbodyの時間制御

終わりが見えない

総プレイ時間は100時間を超えているのに未だにエルダの王になれない皆さんこんにちは。先日は足場の狭い高い塔を登ったり下りたりで1時間以上を費やし、地下の白いベールを被ったボスの撃破に2時間以上かかりました。時間溶けすぎ。

UnityのTimescale

Unityではゲーム中の一時停止などを行うときにTimeクラスのTimescaleの値を変更して各オブジェクトの動作を停止状態にしますが、このTimescaleはシーン内の時間に対して影響を及ぼすので、例えばオブジェクトの動きは止めてもUI等は動いてほしい場合にはTimescaleではなく、別の対処が必要となります。

オブジェクトがDOTweenを使って動いている場合やAnimationで動いている場合などは、それぞれのコンポーネントのspeed値を変えることで停止・加速等を実装できますが、Rigidbodyを使っている場合はPhysics.Simulateメソッドを使うのが正攻法とされているようです。

Physics.Simulate

Physics.Simulateは「指定した秒数分、Rigidbodyの物理演算を進める」事のできるAPIです。
通常は物理演算はTimescaleに従って進みますが、このAPIを使うと超高速もしくは超低速でRigidbodyの位置や向きを計算することになります。ただし、事前にPhysics.autoSimulationをfalseにしておくことが必須条件です。
また「指定した秒数分進めた」演算を行う場合は、周囲のオブジェクトとの接触判定をすっ飛ばす結果になることもあるので注意が必要です。

お試し

試しに下のような箱の中で弾む白いボールの挙動をPhysics.Simulateを使って超高速、超低速で移動させたりします。

前述のようにAwakeでPhysics.autoSimulationをfalseにしておき、FixedUpdateでPhysics.Simulateをコールしますが、Time.fixedDeltaTimeに係数を掛けた値を指定します。

この係数が1超過なら超高速、1未満なら超低速でRigidbodyの挙動が計算される事になります。

Rigidbodyだけが影響を受けていることが分かるように、経過時間を画面に表示させています。
また、前述のTime.fixedDeltaTimeにかけ合わせる係数はDOTweenのメソッドを使って変化させます。中央の赤いボールも白いボールが当たるとDOTweenを使って振動させます。

「Slow」ボタンを押すと全ての白いボールの動きがスローになり、「Fast」ボタンを押すと早くなることが分かります。

逆に、経過時間を示すテキストや赤いボールの振動には何も影響がないことも分かると思います。

このようにPhysics.Simulateを使うと、他のコンポーネントには影響せずRigidbodyだけが早くなったり遅くなったりできるので中々楽しい機能ですが、その分負荷が高いようです。
オブジェクト数がある程度絞られた場面で使う等、使用するにはある程度の考慮が必要です。

【Unity】ScreenToWorldPointで位置がずれる場合の対処

制作者視点

そろそろYoutubeで「皆さん、エルデンリング楽しんでますか？一般の方はきっと無邪気に楽しんでらっしゃるかと思いますが、私みたいなゲーム制作者の視点から意見を言わせていただくと・・・」みたいな動画がアップされそうでワクワクしている皆さんこんにちは。どんな意見が聞けるのか今から楽しみですが、共感性羞恥心が発動して見れないかもしれない。

FlatFx

最近「FlatFx」というアセットを購入しました。

assetstore.unity.comこのアセットは2Dグラフィックのようなエフェクトが表示できるというアセットです。

www.youtube.com

動画を見るとUIのイメージアニメに見えますが、実体はScirptで指定した位置にRendermodeがBillboardのパーティクルが表示されるという仕組みなので、Z方向の座標は絶えず０となります。

このため、マウスでクリックした位置をScreenToWorldPointで取得して、「FlatFx」のエフェクトを表示させようとすると下の動画のようにズレた位置に表示されてしまいます。(青い円がFlatFxのエフェクト)

比較用に同じ位置に白いボールを移動させていますが、クリック位置が画面下の方に行くに従ってズレが大きくなるのがわかります。

ソースはこんな感じ、クリック位置はScreenToWorldPointで取得してFlatFxに渡しています。

原因

この事象の原因はシーンを横から見るとわかります。
上記のソースではScreenToWorldPointにはクリック位置(X,Y)にカメラのZ方向の位置を指定して座標を変換していますが、メインカメラが傾いている場合、取得した位置はカメラの傾きと平行になる平面内の位置が取得されます。

前述のようにFlatFxは「Z方向の座標は絶えず0」であるため、ScreenToWorldPointで取得した位置を指定しても「Z=0のXY平面」に投影された位置に表示される事になります。

これをメインカメラ側の視点で見ると、傾き分Y方向がズレた位置にFlatFxが発生するように見える、というわけです。

対処

「Z=0のXY平面」に指定する位置は、ScreenToWorldPointで取得した位置にメインカメラの傾きを考慮してY方向の位置を補正する必要があります。

下の図のようにY方向の補正位置を計算して、「Z=0のXY平面」の位置を求めます。

対応後のソース

クリック位置に「FlatFx」のエフェクトが表示されるようになります。

まとめ

ちょっとわかりづらいテーマでしたが、ポイントは

• ScreenToWorldPointはカメラの傾きと平行になる位置が取得される
• 特定のXY平面の位置を取得するにはカメラの傾きを考慮する必要がある

ということで、もし自プロジェクトでScreenToWorldPointの位置ずれに悩んでいる方は上記ポイントを見直してください。

【Unity】PC用ビルドのウィンドウサイズ指定

寒いのか暖かいのか

近くの公園では梅の花も咲いて春の訪れが近いのに人生の春の訪れは未だ見えない皆さんこんにちは。
最近は大きな不幸事はないものの、小さい嫌がらせみたいな嫌な出来事が重なってやる気が全く出ません、エルデンリング以外。昨日は2時間かけてやっと漂流墓地のボスを倒しました。

GameBBQ

集英社のインディーゲーム支援企画「GameBBQ」の結果が発表されました。
私の企画は二次面接で箸にも棒にも掛からぬ結果となったので、残念ながら開発は中断となってしまったのですが良い経験になりました。
今回は実績が足らなかった事が落選の最大の原因だと思うので、もっとゲーム開発の実績を積んで機会があれば再度挑戦したいと思います。

iGiインキュベーション

これで各出版社の企画には全て落ちてしまったのですが、懲りずに今度はiGiインキュベーションに応募してみました。
こちらの応募にはプレイ可能なデモ版が必要、とのことで、現在制作中の3D脱出ゲームの方で応募しています。
ゲーム内容的に各出版社に応募したものと比べてインパクトも新規性もないので二期メンバーには選ばれる事はないと思うのですが、選考の過程で寸評程度でも貰えれば開発の参考になるなぁ、という淡い期待で応募しています。

フルスクリーン表示

前述のようにiGiインキュベーションではプレイアブルデモが必要なのでWindows-PC用としてビルドしたのですが、どうもデフォルトはフルスクリーン設定なっているらしくビルド後に起動してみるとちょっとビックリします。
ビルドしたアプリをウィンドウモードで起動したい場合はビルド設定を変える必要があります。

File > Build Settings

で表示される画面でPlayer Settingsボタンを押下

Player > Resolution and Presentationに進むとFullScreenModeの設定があるので、これを「windowed」に変更します。

これで再ビルドするとウィドウモードで表示されます。

ちょっと分かりづらいけど

【Unity】繰り返し使うと重くなるDOTweenTMPAnimatorへの対処

腕組しながら語る

話題のエルデンリングについて、その面白さよりも騎馬戦や召喚魔法等の救済措置の多さを取り上げて「SEKIROに比べるとフロムも随分丸くなったなぁ」とか気持ち悪い感想をつぶやいてる皆さんこんにちは。
とにかく今作はボリュームがありすぎて、15時間プレイしても未だ噂のマルギットさんとお会いしてません。ちょっと歩くと中ボスやらドラゴンやらダンジョンがあるし。

DOTweenTMPAnimator

みんな大好きDOTweenのPro版にはTextMeshに対するTweenのメソッドが用意されています。
それらはText全体に対するアニメ動作を実装するものと、Textを1文字ずつ個別にアニメーションさせるものがあります。

Textを1文字ずつ個別に動作させる場合はDOTweenTMPAnimatorクラスを使用しますが、これはTextMeshをラップしたDOTweenTMPAnimatorクラスを生成し、それに対してTweenを行う方式で実装します。

現在作成中の「W.T.」でもこのクラスを利用して下の動画のようなテキストアニメーションを実装しています。

一文字ずつ左に移動させながらフェードアウトするアニメ
ソースはこんな感じ

DOTweenTMPAnimator textAnim2 = new DOTweenTMPAnimator(MyTextMesh);
for (int iCnt = 0; iCnt < textAnim2.textInfo.characterCount; iCnt++)
{
    textAnim2.DOOffsetChar(iCnt, Vector3.left * 30.0f, 1.5f).SetDelay(0.1f * iCnt);
    textAnim2.DOFadeChar(iCnt, 0, 2.5f).SetDelay(0.1f * iCnt);
}

問題点

上述のように非常に便利なDOTweenTMPAnimatorクラスですが、同じTextMeshに対して文字列を入れ替えてテキストアニメーションさせようとした場合、
当然ながらその度にDOTweenTMPAnimatorクラスを再生成(new)する必要があります。

この場合、数回なら問題ないのですが、それ以上になるとテキストアニメーションの開始に遅延が発生し、下手するとゲーム全体が一時停止したような状態になります。
表示するテキスト毎にそれぞれTextMeshを定義すれば大丈夫なのでしょうが、そうすると1シーン内に大量にTextMeshが必要になったりしてあまり現実的な対応ではありません。

解決法

色々試した結果、以下の二点の対応を行うと解消されることが分かりました。

• DOTweenTMPAnimatorクラスをメンバ変数として使いまわす。
• Tweenが完了したらDOTweenTMPAnimatorクラスのResetメソッドをコールする。

特にDOTweenTMPAnimatorクラスをメンバ変数として使いまわす事は重要で、一つの関数内のローカル変数として毎度生成させていると3,4回目ぐらいで激重状態になります。
また、DOTweenTMPAnimatorクラスでも完了時のコールバックは指定可能なので、最後の文字のTweenが完了したらResetメソッドをコールするようにしましょう。

対処後のソース

DOTweenTMPAnimator TextAnim;

public void TextFadeColor()
{
    for (int iCnt = 0; iCnt < TextAnim.textInfo.characterCount; iCnt++)
    {
        TextAnim.DOOffsetChar(iCnt, Vector3.left * 30.0f, 1.0f).SetDelay(0.1f * iCnt);
        if (iCnt == TextAnim.textInfo.characterCount - 1)
        {
            TextAnim.DOFadeChar(iCnt, 0, 1.5f).SetDelay(0.1f * iCnt).OnComplete(() => OnComplete_FadeOut());
        }
        else
        {
            TextAnim.DOFadeChar(iCnt, 0, 1.5f).SetDelay(0.1f * iCnt);
        }
    }
}

public void OnComplete_FadeOut()
{
    TextAnim.Reset();
}

【雑記】進捗報告いろいろ

SNS

Twitter等のSNSで一人称が「俺」の人は何となく苦手な皆さんこんにちは。10代、20代ならともかく30も過ぎて「俺」呼びの方とは距離を置いて過ごしたい日々です。

講談社ゲームクリエーターズラボ

二期候補生を審査中ですが、私の企画は残念ながら一次面接で不合格となってしまいました。

creatorslab.kodansha.co.jp面接中は相手の方からかなり持ち上げられて浮かれていたのですが、ちょっと考えが甘かったようですね。

これまで大した実績が無いのもマイナスポイントだったのかもしれません。
もし次があれば今回の企画をブラッシュアップしたもので挑みたいと思います。

ゲーム制作進捗

そんなわけで年末に浮かれていたのが嘘のように真っ暗闇に落ち込んでいるのでブログの新しネタを書く気も起きない状況です。

代わりに現在制作中の脱出ゲームについて、出来上がったところまでの紹介動画を作成したので、これでご勘弁ください。

youtu.be

とりあえず完成まで漕ぎ着けるようにこれからも頑張ります。

【Unity】Linecastを利用して遮蔽物を判定する

冬季オリンピック

いつの間にか冬季オリンピックが始まっていてビックリしている皆さんこんにちは。ここ最近の報道がコロナ禍一色でそれほどオリンピックの話題が無かったし、個人的にはブレスオブザワイルドの剣の試練にドハマりしていたこともあって全く意識にありませんでした。週末の新聞の一面がオリンピックの話題で埋まっていてビックリ。

表か裏か

現在開発を進めている3D脱出ゲームにて、プレイヤーの視点の先にあるアイテムについて説明文を表示するという機能を作成しました。

仕組みとしては簡単で、まずアイテム側にプレイヤーの視点を検知する為のColliderを取り付けて、

このCollider内にプレイヤー側の視点(camera)の視界を表すCollider(下の図の青いBoxの部分)が接触(OnTriggerEnter)したら説明文を表示するという仕組みですが、

例えば上図のPCモニターのようにアイテムに表と裏がある場合、プレイヤーがPCモニターの裏面側に回ったとしてもColliderの接触判定は有効なので説明文が表示されてしまいます。

なので、この問題を回避するためにLinecastを利用してプレイヤーが裏側に回った際の遮蔽物を判定するように対応しました。

裏側を判定する

まずPCモニターの裏側に、裏側だと判定するためのColliderを設置します。下の図の紫の箇所がそのColliderです。
このColliderには「PlayerRayIsBlocked」のタグが設定してあります。

そして、PCモニター側のOnTriggerEnter内でプレイヤー側の視点Colliderを検知した際、プレイヤーとPCモニターの間に「PlayerRayIsBlocked」のタグが付いたColliderが存在すればプレイヤーは裏側にいると判定することができます。
この「PlayerRayIsBlocked」Colliderの存在有無を判定するためにLinecastを使用します。

Linecast

Linecastは始点と終点を設定してそこに線を張り、その範囲内でヒットしたCollider情報を取得する事ができます。
Colliderが複数接触してる時、始点に近いCollider情報を取得できるようです。
こういった手法を取る場合、主にRaycastを使用する事が多いと思いますが、今回のケースでは明確に始点と終点が分かるのでLinecastを使用することにしました。

public void OnTriggerEnter(Collider other)
{
    Vector3 startPos = this.transform.position;
    Vector3 endPos = other.gameObject.transform.position;
    RaycastHit hit;

    if (Physics.Linecast(startPos, endPos, out hit, myLayerMask))
    {
        if (hit.transform.gameObject.CompareTag("PlayerRayIsBlocked"))
        {
            return;
        }
    }
}

上記のソースでは始点(PCモニター)と終点(Player視点)の間にLinecastで線を張り、ヒットしたColldierのタグ名が「PlayerRayIsBlocked」であるかどうか判定しています。

この対応によって

プレイヤーがPCモニターの裏側にいる場合、説明文は表示されなくなり、表に回ると表示されるようになりました。