原カバンは鞄のお店ではありません。

Unityを使ったゲーム制作のあれこれを綴っていきます。

【Unity】窓シェーダーを使ってみた

ゴール前が一番しんどい

どこかのブログに「ゲーム作りは80~90%出来上がってからが大変」みたいな記載があって、当初はそれを疑っていたのですが、いざ自身が制作する身になってみると本当にその通りらしく、3日間頭を抱えたバグの原因がスクリプトにたった一行足らなかっただけだったりして、仕様書も書かずに行き当たりばったりで作っている自分が悪いとはいえ、ゴールを目の前にして足踏み状態が続く苛立ちとか心の叫びを文字におこしたら結構すごいわ、とか、わけの分からない言葉が頭を巡っている日々が続いています。

 

窓シェーダー

そういえば以前「窓越しにオブジェクトを表示する」窓シェーダーを紹介したのですが、そのときは当該の記事をリンクするだけで実際のユースケースについては触れていませんでした。

 

styly.cc

窓シェーダーを使用すると「窓越しにオブジェクトを表示する = 窓越しに見ないとオブジェクトは表示されない」といった表現が可能になるのでビックリするような仕掛けを作ることができます。

 

使い方も簡単で「窓」オブジェクトと「窓の向こうに置く」オブジェクトのそれぞれに専用のシェーダーをアタッチするだけです。

 

実際のシェーダーのコードは上記のリンクを参照してください(コードの転記はしません)。

 

こんな感じの絵を作る

f:id:Karvan:20190205232731p:plain

 

「Dull Things No Life」ではタイトル画面でMoterBikeが登場するアニメで使用しています。MoterBikeが転送されて現れるようなイメージを表現したかったんです。

 

作り方は単純でMoterBikeに「窓の向こうに置く」用シェーダを適用して、「窓」側のオブジェクトの奥(カメラから見て)に配置
ただ、「窓」が一面だけでは立体感がでないので二面用意して、その上下にそれっぽいスプライトを配置しています。

 

f:id:Karvan:20190205232952p:plain

 

こんな感じ、ちなみに「窓」側のオブジェクトは見えない(表示されない)です。

で、後は「窓」側のオブジェクトのサイズをDoTweenを使って動かします。

 

f:id:Karvan:20190205233050g:plain

 

結構いい感じに出来たのではないでしょうか?

 

で、ここから宣伝

「Dull Things No Life」では主に柱やCUBEなどが自機であるMoterBikeの前に立ちふさがりますが、それ以外にもステージによっては特殊な動きで自機の行く手を阻む障害物が存在します。

 

これらの障害物はその動作を良く見れば回避方法は分かるのですが、初見では意外と厳しいかもしれません。MoterBikeも結構な速さで動いているし。
なのでレビューサイト等で「初見殺しじゃん、クソゲー」とか言われない為にも、その幾つかを回避方法とあわせて紹介したいと思います。

 

Missile

空中から自機に向かって飛んでくるのでスライディングでその下を潜り抜けて回避します。自機が移動しても追尾して真直ぐ飛んでくるのでかわすタイミングが難しい障害物です。

f:id:Karvan:20190205233418g:plain

 

どうしても難しいなら自機をローリングさせれば回避できます。

f:id:Karvan:20190205233454g:plain

 

Rain

天井から無数のBOXが降り注ぎます。近づくと安全地帯が表示されるのでそちらに進んで回避します。安全地帯にはBOXが降って来ません。

f:id:Karvan:20190205233609g:plain

 

Box

上空に向かってレーザーを発射します。一部のBOXからは発射されないので、その空いたところをジャンプして回避します。
動きを良く見るとレーザーを発射するBOXは事前に回転するので、回転しないBOXの位置へ自機を移動⇒ジャンプします。

f:id:Karvan:20190205233831g:plain

 

この他にもまだまだあるのですが、それは次回以降に紹介したいと思います。

 

 

【Unity】負荷削減のTipsとか

突然の通知

GooglePlayにアプリをリリースして開発者登録をしていると時折Googleから通知メールが届くのですが、大抵(ってかほとんど)が英語で書かれているので、学生時代に英語が嫌いすぎて理系を選択した私としては読むのが面倒でそのまま放置していました。が、しかし、、先日、何気にGoogleのコンソールを開くと赤枠でデカデカと「ポリシー違反のため、1 つ以上のアプリが Designed for Families プログラムから削除されました。」との表示が。

 

どうやらGooglePlayのポリシーが最近変更になったようで、おそらく「交換条件として広告を表示してはいけない」ってのに違反していると思われる。


つまり、「広告を視聴するとスタミナ回復」だとか「広告視聴でコンティニュー」だとかが軒並みNGということで、イヤイヤ、

 

f:id:Karvan:20190129201805p:plain


それじゃぁ「ステージクリア毎に広告を強制表示」みたいな手法が良いっていう事?それはウザすぎる。いまさらバナー広告に移行しようとは思わないし、もういいや。。。ってこれも放置していたら、当該アプリのAdwordsの広告表示回数が10分の1以下になった。ギャフン

 

そして宣伝

そんな感じでGoogleから虐げられながらも近々リリース予定のアプリの宣伝

 

「Dull Things No Life」では左右に動いて障害物を避ける以外に、画面をタップすることで主機であるMotorBikeに独自のアクションをさせて障害物をかわす事ができます。

 

アクションの種類は3種類で、それぞれ目の前の障害物に応じてMotorBikeが自動的に判断し、その動作を行います。

 

■ドリフト

f:id:Karvan:20190129202017g:plain

 

■ジャンプ

f:id:Karvan:20190129202121g:plain

 

■スライディング

f:id:Karvan:20190129202221g:plain

 

ただ、いつでもタップすればよい、と言うわけではなくてMotorBikeの前方にある黄色いラインに障害物が差し掛かると赤色に変わるので、そのタイミングで画面をタップします。

 

要は音ゲーで良くある、ここのラインにノーツがきたらタップ!と同じ操作だと思ってください。

 

このアクション動作による回避方法は「Dull Things No Life」では非常に重要で、障害物の一部にはアクション動作をさせないと回避不可なものがあります。

 

次回は「Dull Things No Life」で登場する特殊な障害物について紹介したいと思います。

 

負荷軽減をしなくては・・・

携帯向けのアプリを作成しているとどうしても突き当たる問題が、開発用PCと実機(携帯端末)とのスペック差

 

前回の記事でも書いたようにPC上ではスムーズに動くのに実機ではモッサリ動作、音楽と同期させようとするとズレて動作したりなどゲームとして成り立たなくなるので出来るだけ軽量に動くように対処する必要があります。

 

負荷軽減のまず第一歩としてよく取り上げれるのは「ドローコール(SetPassCall)を減らす」と言う題目で以下のような対処方法が有名です。

 

ドローコール(SetPassCall)を減らす対策

  • 動かないオブジェクトはstaticにチェックを入れておく
  • 複数マテリアルを1つのテクスチャにまとめる
  • メッシュの結合を行う(専用アセットが必要です「Mesh Baker」とか)
  • カメラのEffectをはずす
  • 影を描画しない

 

これらは確かに有効な方法ですが、主にGPU負荷に対する軽減策となっているのでCPUの負荷に対してはスクリプトを見直す必要があります。

 

スクリプトによる負荷軽減

スクリプトの見直しとして主に取り上げられる対策は

  • 不要なStart,Updateメソッドを削除する
  • FindやGetComponentなど処理の重いメソッドを減らす
  • JobSystemを使ってマルチスレッドで処理する
  • foreachやstringの結合などGCが発生するものは避ける

 

等がありますが、これに加えて以下の方法も意外と有効です。

 

  • gameObject.tag == "タグ"ではなく gameObject.CompareTag("タグ")を使う

 

  • Materialのプロパティを操作をする際に文字列でなくユニーク ID で指定する
int material_Color = Shader.PropertyToID(“_Color”);
material.SetColor(material_Color, Color.white);

 

  • Animatorのステートの指定は文字列でなくHash値を使用する
int anim_Attack = Animator.StringToHash(“attack”);
animator.SetTrigger(anim_Attack);

 

それでもダメなら・・・

上記の対策をしても未だモッサリ動作が直らない場合は、画面の解像度を下げる、という手があります。

ここ最近の携帯端末はカメラの性能競争が激しく、結果としてゲームを動かすにはオーバースペック気味の解像度を持ってたりします。

 

なので、この解像度を下げることでGPUの描画性能を上げて負荷軽減につなげる手法です。やり方はScreen.SetResolutionで画面の解像度を指定するだけ。

 

Screen.SetResolution( Screen.width*0.5f , Screen.height*0.5f, true);

 

上記の場合は解像度を半分に下げています。携帯の画面サイズだと解像度が半減したとしても意外とバレません。


ただ、テキスト等のUIも解像度が半減するのでネイティブ解像度と比較して若干見難くなるかもしれないので注意が必要です。

 

ドローコールやらスクリプトやら見直した後の最後の切り札として使ったほうが良いかと思います。

 

参考資料:

qiita.com

baba-s.hatenablog.com

 

【Unity】Objectを音楽と同期させて動かす時の注意

最初に宣伝から

現在、開発中のゲーム「Dull Things No Life」ですが、ようやく完成の目処が立ってきたので今回の記事からそのゲーム内容について紹介をしていきたいと思います。

 

f:id:Karvan:20190122223555p:plain


「Dull Things No Life」はいわゆるラン系ゲームというやつで、操作キャラクターが自動で走っているところをタップ操作で左右に移動させ、迫り来る障害物をかわしてゴールを目指して進んでいく、といった内容のゲームとなっています。

このゲームの操作キャラクターは赤色のMotorBikeで、画面の左右をタップすることでMotorBikeも左右に移動します。
またMotorBikeの走る経路はトンネルのように壁で囲まれていますが、上下左右どこの壁にも移動することが出来ます。

 

f:id:Karvan:20190122223646g:plain

 

こんな感じ、大きな柱が走路を塞いでいる場合は左右の壁に移動してそれを避ける事ができます。

画面の左右をタップするだけで難しい操作はありません。まぁ、類似のアプリは多々あるので「ああ、よくあるやつね」と思って頂いて結構です。

 

ただ、「Dull Things No Life」ではMotorBikeは左右移動だけでなく特殊な動作で障害物を避けることが出来るのですが、宣伝が長くなるのでこれについてはまた次回紹介したいと思います。

 

で、本題

UnityではObjectを移動させる処理は様々ありますが、よく使われる手法としてUpdate内で移動速度×前フレームからの時間差分=移動量を計算してObjectのtransformに反映する、という方法があります。

 

このとき前フレームからの時間差分にはTime.deltaTimeを使用しますが、このdeltaTimeはTime.timeScaleに影響を受けます。

 

Time.timeScaleはUnity内(ゲーム内)の時間の定義しているので、Time.timeScale = 1であれば現実の時間と同じ時間、この値を小さくすると現実の時間 > ゲーム内の時間となり、例えばtimeScale = 0.5とすると、deltaTimeが1.0(sec)だとしても現実の時間は2.0(sec)経過していることになります。

 

通常、timeScaleを意図的に変更しない限りは(timeScale = 1のままであれば)、現実の時間=ゲーム内の時間となるのでdeltaTimeを使用しても現実の時間と食い違うことはなく特に問題ない、と思っていました。

 

だが、しかし・・・

Mobile端末でゲームを動かす場合、PCと比べると演算性能や描画性能は劣るので、PC上のUnityEditorで確認した動作よりももっさりした(処理に時間が掛かる)動作になるのは仕方ないことだと思います。

 

ただ、どうもUnity内部にて(私の推測だけど)、処理に時間が掛かる分だけゲーム内のtimeScaleを調整しているようで、deltaTimeと現実の時間が一致しない状態になります。
つまり、こちらはtimeScaleを変更していないのに、現実の時間 > ゲーム内の時間、みたいな事象になるということ。

 

まぁ、現実の時間とリンクしない、ゲーム内の時間だけで完結するようなゲームの場合、それでも問題ないのでしょうが、音楽と同期させてObjectを動かしたい場合はちょっと問題です。

 

何が問題なのか

AudioClipによるSEやBGMの再生はtimeScaleの影響を受けません。つまり、かならず現実の時間と同じ時間だけ経過して音声を再生していきます。一方、Objectの方はtimeScaleの影響を受けてゲーム内の時間で動作するとなると、例えば、下図のような典型的な音ゲーを作る場合

 

f:id:Karvan:20190122224035p:plain

 

こんな感じの仕様となるので、各ノーツはそれに対応する音が再生されるより前に画面に表示する必要があります。

 

f:id:Karvan:20190122224156p:plain

 

しかし、移動処理でdeltaTimeを使用していると現実の時間 > ゲーム内の時間なのでノーツ移動が間に合いません。

 

f:id:Karvan:20190122224257p:plain

 

これはゲームとして致命的です。しかもUnity内部にて処理速度に応じて勝手に調整されているので(あくまで私の推測)、こちら側(製作者側)で遅くなるのを見越して移動速度を調整するような対処も行う事ができません。

 

なのでこんなときは・・・

timeScaleに影響ない前フレームからの時間差分を得る場合にはTime.unscaledDeltaTimeを使用します。

 

deltaTimeとunscaledDeltaTimeの違いはtimeScaleの影響ありなしだけなので、通常時はdeltaTime=unscaledDeltaTime=現実の時間となっていますが、上記のように音楽と同期させるために必ず(勝手にtimeScaleが変わっても)現実の時間とリンクが必要な場合はunscaledDeltaTimeを使用して処理を組み込む必要があります。

 

ちなみに、Objectを移動させるのにiTweenやDoTweenを使っていても特にオプションを指定してない限りは同様の現象になります。また、Animatorでも同様です。

 

以下にtimeScaleを考慮しない場合のオプションを記載します。

 

  • iTweenの場合:ignoretimescaleプロパティをtrueに設定する

   Hashtable ht = new Hashtable ();

   ht.Add ("ignoretimescale", true);

 

  • doTweenの場合:Updateオプションをtrueに設定する

   DOTween.To( ~ ).SetUpdate( true );

 

  • Animatorの場合:updateModeプロパティにUnscaledTimeを設定する

        animator.updateMode = AnimatorUpdateMode.UnscaledTime;

 

注意事項

前述のようにunscaledDeltaTimeはtimeScaleを考慮しないので、例えばPause処理などでtimeScale=0としていても関係なく動作します。

 

また、オブジェクトが一旦非Active状態になると、その間の差分時間が加算されていくのでActive状態に戻ってUpdateでunscaledDeltaTimeを取得すると、最初フレームでunscaledDeltaTime = 非Active状態だった時間、が返ってきて、一気に時間が経過したような動作になるようです。


これについては以下のkan.kikuchiさんのブログに詳しく書かれています。

 

kan-kikuchi.hatenablog.com

 

 

 

 

 

【Unity2018.3】ビルドが「Building scene ~」から進まないので困った話(Android)

『コーラを飲むと骨が溶ける』って誰かが言ってた

社会人になって最初のころ、右も左も分からない私を根気よく指導してくれて信頼を寄せていた会社の先輩に「重要な話がある」と呼び出されたので行ってみると、ダイヤモンドのセールスマンを紹介されて危うく15年ローンを組まされそうになって以来、他人の話を安易に信じない、例えば『炭酸水を飲むとお腹が空く』みたいな似非科学話に対して「言われてみると、そんな気がしないでもない・・・」とかアホみたいに受け入れるのは止めようと自分を戒めるようになったのですが、やっぱり人間切羽詰ってくると藁にもすがると言うか、すがれるものなら何でもすがりたくなる様で、今回の記事はエラー原因がちっとも分からないけれどネットでそれっぽい話があったので試してみたら案外上手くいったよ、って話。

 

前回の続きから

前回の記事で、Unity2018.2からUnity2018.3へバージョンを上げたらコンソールにエラーが出たという話を書いたのですが、

 

www.karvan1230.com

そのエラーをアレコレで改修した後、Andorid機でテストしようとビルドしてみると・・・

 

「Building scene 4: Credit」の表示とともにビルドのプログレスバーが全く進まない

 

最初は「バージョンアップした一発目のビルドだから時間が掛かるのかな?」とか根拠のない楽観論でビルドが終了するのを待っていたのですが、

 

一時間経過・・・

f:id:Karvan:20190116001150p:plain

 

二時間経過・・・

f:id:Karvan:20190116001150p:plain

 

三・・・

f:id:Karvan:20190116001258p:plain

もうだめだ!待てない!⇒ビルドキャンセル

 

といわけで対処法を探りました。

 

止まっているわけではないらしい

例によって例のごとくGoogle先生に尋ねてみるとそれっぽい記事を紹介されました。

 

ikosami.hotcom-land.com

で、上記の記事によると「GI(Global Illumination)というのが異常に時間がかかり・・(中略)・・ビルドが止まっているのかと思うほど全然進まなくなります。」と書かれている。

 

GI(Global Illumination)とはライティングの機能で、シーン内のオブジェクトに対して光源からの反射光を考慮した光の様子を再現するという機能です。
例えば青い立方体に白い光を当てたらその反射光で周りが少し青くなる、みたいな状態を表現する時に使用されます。

 

この説明だけを聞くと、ビルドが止まったかのように進まない(進んでいるけどすごく遅い)のも分かるのですが、ここで疑問となるのは、止まってている(ように見える)scene 4: Creditには3Dオブジェクトが存在しない、という事です。

 

ええ、シーン名が「Credit」となっていることから分かると思いますが、当該のシーンはTextを表示するのみで光の影響を受けるような3Dオブジェクトは一つもありません。

 

f:id:Karvan:20190116001536p:plain

 

こんな感じの画面。黒バックに白い文字が表示されるだけの画面です。

 

ないからこそ逆に・・・

このGI(Global Illumination)の設定はデフォルトでONとなっているので何もしていない場合は必ず適用されます。


GIが適用されるとビルド時に光の影響を計算してテクスチャに書き込む処理が動くのですが、3Dオブジェクトが何もない空間でライトだけ設定されている場合、光の影響範囲が無限に大きくなって計算に時間が掛かるのではないか?・・・と上記の記事を読んで全く根拠のない推測を立てる私。

 

90%ぐらいは"(原因が)そうであってくれ"という願望が占めているのですが、何はともあれ、藁にもすがる思いでGIの設定をOFFに変えました。

 

OFFにするにはMenu からWindow->Lighting を選ぶとLighting Window が開くので、

 

f:id:Karvan:20190116001725p:plain

 

ここのRealtime LightingとMixed LightingのBaked Global Illuminationチェックを外します。

 

Unityのマニュアルを参考にするとMixed Lightingの設定をOFFにすれば良いだけの様な気もしますが、今回のシーンではそもそも光の影響は受けないのでどちらもチェックを外しました。

 

で、この状態でビルドを再実行すると・・・

 

f:id:Karvan:20190116001926p:plain

ビルドが数分完了!!あ~、よかった。。。

 

一応解消された

上記の対応でビルドが進まない、という現象は解消されたましたが、そもそもUnity2018.2では同じ設定でもビルドは進んでいたので、これはUnity2018.3独特の現象なのかもしれません。

 

また、3DオブジェクトがないからGIに時間が掛かる、というのも私の勝手な推測なので正しいかどうか分かりません。

 

ただ、GIをONにするとビルドに時間が掛かるだけでなく、アプリサイズも大きくなるそうなので、見栄えが少し変わることに問題がなければ通常のシーンでも切ったほうがよいと思います。

 

といわけで、次回からはいよいよリリース間近の「Dull Things No Life」の紹介をしたいと思います。

 

 

 

【Unity】Unity2018.3へアップデートしたらエラーが出た(何度目だ)

年末年始はほぼニート生活

明けましておめでとうございます。ちなみに年が明けてこの挨拶をするのはこのブログが初めてです。なんせ人と会ってなかった。

というのも、私の勤めている会社では年末が12/27で締め、年始は1/4が休みとなっていたので今年の年末年始の休みは10連休もあったのですが、私はそのほぼ全てを部屋で過ごすという仮想ニート生活を謳歌していました。

あまりに部屋から出ないので新年早々、父親からダメ人間判定をされるなど過酷な出来事を乗り越えつつ、PCとPS4に立ち向かう怠惰な日々をダラダラと過ごしていました。今年もよろしくお願いいたします。(←この挨拶も今年初)

 

Unity2018.3へアップデート

さて、年末話題になった某レコード大賞の楽曲のように認知度や知名度、浸透度よりも誰も知らなくていいから売上だけはミリオンを達成したいという気持ちで10連休の殆どはゲーム製作に費やしていたのですが、その途中、そういえばUnity2018.3にアップデートしていなかったことを思い出して、それまで使っていたUnity2018.2からUnity2018.3へアップデートする作業を行いました。

 

Unity2018.3ではPrefabの編集機能やタイルマップ機能の追加など、Unity2018.2と比べて多くの機能の追加と処理の改善が行われているようなので「多少コンバートに時間が掛かるかも」とは思いつつワクワクしながらアップデートしたのですが、見事に目論が外れました。

 

だが、しかし・・・

 

振り返るとUnityのアップデート時には度々トラブルが起こっていてこのブログでも度々記事に書いてきました。

 

www.karvan1230.com

www.karvan1230.com

ただUnity2018.2になってからは内部アップデートは頻繁にあるものの、これといったトラブルが起きなかったのでこの時は完全に油断していました。裏を掛かれたとはこのことです。

 

Unity2018.3のインストールが終わり、プロジェクトを起動したらコンソールに以下のエラーが発生

 

f:id:Karvan:20190108223028p:plain

[Physics.PhysX] RigidBody::setRigidBodyFlag: kinematic bodies with CCD enabled are not supported! CCD will be ignored.

 

なんだこれ?

 

Google先生から得た答え

エラー内容から察するにRigidBodyコンポーネントのオプションにあるiskinematicオプションが関係しているようですが、詳しいことはチンプンカンプン。なにせUnity2018.2では問題なく動いていたんですからね!!

 

怒っても仕方ないのでエラーメッセージについてGoogle先生に尋ねてみるとUnity2018.3では物理演算の処理が大きく変わった事による影響で、iskinematicオプションをONにしている場合、Collision Detectionオプションの設定を「Discrete」にしないといけないようです。

 

これまでCollision Detectionオプションの設定はデフォルトで「Discrete」となっていたので特に問題なかったのですが、Unity2018.3からこのデフォルト設定が変わり、上記の設定を手動で行う必要が出てきました。なんだそれ。

 

なので、RigidBodyコンポーネントをつけていてiskinematicオプションをONにしているオブジェクト全てに対してCollision Detectionオプションの設定を見直すことになるのですが・・・

 

f:id:Karvan:20190108222739p:plain

 

さて、どーれだ

 

元々、行き当たりばったりで作っているのでどのオブジェクトにRigidBodyがあって、その中のどれがiskinematicオプションがONになっているのかさっぱり見当もつきません。アセットストアから購入した物をそのまま使っているオブジェクトもあるし、記憶だけを頼りに見つけ出すのはちょっと骨が折れる。

どうしよう・・・

 

そんなときに使えるツールが!!

GitHubにエラーの原因となっているオブジェクトを見つけるスクリプトが上げられていました。めっちゃ有り難い。

 

https://gist.github.com/Arakade/dc1d6623cafaab07aeee92a8a1cf661f

 

使い方は、まず上のリンクからPhysXCCDEditorHelper.csのをダウンロードするか、コードをCopy&Pasetして作成したらそれをEditorフォルダに格納

 

しばらくするとメニューのTool配下に「UGS」が追加されるのでそれを選択。

 

f:id:Karvan:20190108223205p:plain

 

ウインドウが表示されるので「Find bad PhysX in scene」ボタンを押下

 

f:id:Karvan:20190108223247p:plain

 

すぐに問題のあるオブジェクトの名前が表示されるので、そのオブジェクトのInspectorからCollision Detectionオプションの設定を変更します。

 

f:id:Karvan:20190108223347p:plain

 

このツールは現在表示しているシーン内のオブジェクトのみチェックするので、プロジェクト内に複数のシーンがある場合には各シーン毎にツールを起動してチェックする必要があります。

ただ、このツールを使って修正してもエラーが表示される場合は、修正したオブジェクトがPrefab化していないか確認してください。Prefab化している場合はPrefab側の設定も同じように修正する必要があります。

エラーは解消されたものの・・・

これらの作業でコンソールに表示されていたエラーは解消されたのですが、今度はプロジェクトをAndroidビルドする際にまた問題が発生しました。

 

Unityのビルドが「Building scene 0: ~」から進まない・・・

 

いやいや、訳分からん。なにせUnity2018.2では問題なく動いていたんですからね!!(二度目)

 

長くなったので続きは次回の記事で

 

 

【Unity】オープニングシーン作成

寒風吹きすさぶ

「Dull Things No Life」の製作も大詰めということで、この三連休は気合を入れてゲーム作りに励んでいたわけですが、そんな中、近くのコンビニまで夕飯を買いに出かけた帰り道、そういえば部屋の電気をつけっぱなしだったなぁ、なんてことを思いながら自宅のマンションを眺めていたら、7階建てのマンションの中で自分の部屋しか灯りが点いないことに気づいて、そして思い出したんです、ああ、今日はクリスマスイブか・・・って。大丈夫です。別に泣いてません、今日も元気に心も体も寒風吹きすさぶ日々を過ごしています。

 

そんな中・・・

そんな感じで血の涙を流しながら何を作っていたのかといえば、「Dull Things No Life」の初回起動時に流すオープニングのシーンをTimeLineとCinemachineの勉強をしながら作っていました。

 

TimeLineとはオブジェクトやCamera,AudioClipなどを時系列に並べて動かすことの出来るエディタで、Cinemachineとはカメラの動きをいい感じにコントロールしてくれるアセットです。

 

TimeLineはUnityに標準で搭載されています。CinemachineはAssetStoreからダウンロードする必要がありますが、無償なので気兼ねなくダウンロードして使うことができます。

 

どちらもゲームのカットシーンや、映像シーケンスを作るのに非常に有用で、テラシュールブログにもその使用法が度々取り上げられています。私は以下の記事を参考にしながらオープニングのシーンを作っていきました。

 

tsubakit1.hateblo.jp

出来上がり

で、こんな感じのシーンが出来ました。
CinemachineとTimeLineで細かいカット割りが以外と簡単に作れました(とはいえ、3日掛かったけど)

 

youtu.be

BGMにはD’elfさんの「Re_cybernetic」を使用しています。

www.d-elf.com

普段はPCのUnityエディタ上の画面をキャプチャして動画を作成しているのですが、PCの性能がショボイ所為なのか速い動きのある場面をキャプチャするとガタガタになってしまうので、実機(Android端末)で動かした画面をキャプチャして動画を作成しています。

なので画面中にキャプチャソフト(DU Recorder)のアイコンが映りこんでますがご容赦ください。

 

年内リリースは無理だったので、来年1月中にはなんとか・・・

(じゃないと次の予定が立たないし・・・)

【Unity】DoTweenで360度回転したかった。。。

需要が読めない

最近ブームの話題作だ、ということで寒風吹きすさぶ中、わざわざ映画館まで足を運んで「ボヘミアン・ラプソディ」を観て来たました。まぁ、Queenに思い入れも何もない人間なので「感動!」「泣いた!」みたいな絶賛をする気もないし、「クイーンってはさぁ、こんな美談で語るようなバンドじゃないんだよ・・・」みたいなうざい薀蓄を語る気もないのですが、映画ラスト20分のライブシーンは必見だと思います。映画を観た後、実際のライブ映像も観たくなるし。

 


ただ、昼間の回ということもあってか観客が爺さん婆さんばかりでビックリ。あれだよ、ブームってのは若い女性の間とかで流行っているからブームって言うんじゃないですか?シルバー世代とか演歌しか聴かない、とか固定観念に染まっていたので、まさか洋楽ロックが主題の映画を観に行って敬老会の中に混じるような状態なるとは夢にも思いませんでした。学生はおろか同世代の人間も見当たらなかったし。

 

メニュー画面作り

そんな感じで需要もターゲットも読めないような人間が今日もゲーム作りに励んでいるわけですが、「Dull Things No Life」の製作も本編の主要な部分はだいぶ作り終えたので、枝葉となるメニュー画面等々の作りこみ作業へ移ってきています。

 

こんな感じ(前回の記事でも紹介したけど)

f:id:Karvan:20181211195710p:plain

 

そのメニュー画面も上の画像にあるように大体は完成したのですが、左上に見える掲示板みたいな部分、ユーザにいろいろな情報を表示する部分の作りこみで問題が発生しました。

 

表示情報を切り替える

掲示板みたいな部分には、現在の状態やスコア情報等を一定間隔で切り替えて表示しています。(全てテキスト情報)
これは各情報を表示するTextMeshを四角柱型に配置して、それを90度づつ回転することでユーザ側に見える情報を変えています。

 

f:id:Karvan:20181218233821p:plain

この90度づつ回転させる、という機能にはDoTweenのDoRotateメソッドのRelativeオプションをtrueにすることで実装しています。
このRelativeオプションは非常に有用でこれを設定した場合、移動角度を相対的に計算するようになります。


つまり、現在角度からZ軸方向に90度回転させたい場合、

 

// 回転処理
 MessageBoardObj.transform.DOLocalRotate(new Vector3(90.0f, 0.0f, 0.0f), 0.3f)
                                        .SetRelative(true);

 

としてコールすると、オブジェクトの角度は順に0度⇒90度⇒180度⇒270度⇒360度へと回転してくる、はずです。ですが、実際に実行してみる・・・

 

0度⇒90度の場合

f:id:Karvan:20181218234430g:plain

うん、大丈夫

 

90度⇒180度の場合

f:id:Karvan:20181218234501g:plain

OK、OK

 

180度⇒270度の場合

f:id:Karvan:20181218234535g:plain

コレまでとは逆方向に回転、なんでやねん。

 

調べてみるとDORotateは動作として回転方向は指定した角度の近い方へ回転する仕様らしい、例えば270度に回転する場合は、0度から回転して0->1...269->270となるのではなく、360度から回転して360->359...271->270で回転するみたい。

 

つまり、0度⇒360度を90度づつ回転させる場合、全て同じ指定で回転させるのではなく、180度⇒270度の場合は逆方向に回転させないと上手くいかないようです。
なので、コードとしては

 

/// <summary>
/// メッセージ表示処理(順次回転表示)
/// </summary>
private void RotDisp_MessageBoard()
{
    // Indexの設定
    nextIndex++;
    if (nextIndex >= 4) nextIndex = 0;

    if (nextIndex != 3)
    {
        // 回転処理
        MessageBoardObj.transform.DOLocalRotate(new Vector3(90.0f, 0.0f, 0.0f), 0.3f)
                                    .SetRelative(true);
    }
    else
    {
        // 回転処理
        MessageBoardObj.transform.DOLocalRotate(new Vector3(-90.0f, 0.0f, 0.0f), 0.3f)
                                    .SetRelative(true);
    }

}

 

 

と、超ダサいコードに。うーん。。。


ちなみに結果としては

f:id:Karvan:20181218235128g:plain

こんな感じで、上手く一回転してくれるようになりましたが、なんだかなぁ・・・・
 




 

◇プライバシーポリシー

●個人情報の利用目的

当ブログでは、メールでのお問い合わせ、メールマガジンへの登録などの際に、名前(ハンドルネーム)、メールアドレス等の個人情報をご登録いただく場合がございます。

これらの個人情報は質問に対する回答や必要な情報を電子メールなどをでご連絡する場合に利用させていただくものであり、個人情報をご提供いただく際の目的以外では利用いたしません。

●個人情報の第三者への開示

当サイトでは、個人情報は適切に管理し、以下に該当する場合を除いて第三者に開示することはありません。

・本人のご了解がある場合
・法令等への協力のため、開示が必要となる場合

個人情報の開示、訂正、追加、削除、利用停止
ご本人からの個人データの開示、訂正、追加、削除、利用停止のご希望の場合には、ご本人であることを確認させていただいた上、速やかに対応させていただきます。

アクセス解析ツールについて

当サイトでは、Googleによるアクセス解析ツール「Googleアナリティクス」を利用しています。

このGoogleアナリティクスはトラフィックデータの収集のためにCookieを使用しています。このトラフィックデータは匿名で収集されており、個人を特定するものではありません。
この機能はCookieを無効にすることで収集を拒否することが出来ますので、お使いのブラウザの設定をご確認ください。

●免責事項

当サイトからリンクやバナーなどによって他のサイトに移動された場合、移動先サイトで提供される情報、サービス等について一切の責任を負いません。

当サイトのコンテンツ・情報につきまして、可能な限り正確な情報を掲載するよう努めておりますが、誤情報が入り込んだり、情報が古くなっていることもございます。

当サイトに掲載された内容によって生じた損害等の一切の責任を負いかねますのでご了承ください。

●プライバシーポリシーの変更について

当サイトは、個人情報に関して適用される日本の法令を遵守するとともに、本ポリシーの内容を適宜見直しその改善に努めます。

修正された最新のプライバシーポリシーは常に本ページにて開示されます。