【Unity】【進捗報告】脱出ゲームを作ろう

今ここにある危機

コロナ騒動の中、日々黒人差別と闘っている意識高い皆さんこんにちは。意識の低い私にはこの日本の中で一体どこに向かって石を投げているのか、なぜ今なのか、ちっとも分かないのですが、とりあえず直近の危機回避としてクラスターが発生しないことを祈るばかりです。

そんなわけで井上陽水の「傘がない」よろしく、大局よりも目の前の問題解決に奔走するしがない小市民として、この週末は部屋に閉じこもってゲームを作っていました。

というのも、以前ブログで取り上げた"Portal"のアセットが非常に優秀だったので、これを有効活用するようなゲームをお試しで作っているといつの間にか時間が過ぎてた。

ここ2週間の成果がコレ

上ってきた階段を戻って降りると違う部屋に繋がっていて、仕掛けを解除するまで同じ部屋をグルグル回り続けるという、ちょっと不思議な感覚が味わえる脱出ゲームとなっています。

一体どうなっている

簡単に言うと階段の途中にポータルが設置されていて、ポータル自身の姿は見えないのでプレイヤーが気づかない間に上ってきた階段の元の位置へ飛ばれされているだけです。

このステージはSceneビューで見るとこんな構造をしています。

分かりづらいので簡略化するとこんな感じ

1Fから2Fへ上る途中にA、3Fから出口に上る途中にBのポータルがあり、Aが上る方向を、Bが降りる方向を向いています。

これにより3Fのフロアから上に上る階段を見ると、途中から1Fから2Fへ上る階段が見えることになりますが、階段の形状、色、大きさを同じものにそろえているため、プレイヤー側は3Fの階段がそのまま上の階に続いているように見えます。

2Fのフロアから1Fに下りる階段(ポータルA)を見た時も同じです。

一度このエリアに入るとプレイヤーは階段を上り続けても3Fの途中でB→Aに飛ばされ、2Fのフロアにたどり着くことになります。

逆に降り続けても1Fに向かう途中でA→Bに飛ばされて3Fに到着、延々と同じフロアを歩くことになります。ようは無限回廊の出来上がり。

ポータルの裏側

先程の動画ではドアを開けて最初の階段を上るとポータルで飛ばれされず1Fのフロアにそのままたどり着きます。

これはポータルには向きがあり、裏から通り抜けた場合は特に何の処理(移動)も発生しないからです。

そして、ポータルを裏側から覗くと透明なので何事もなく1Fのフロアに続く階段がそのまま見えています。

ポータルのデモシーン、裏側から見たときは特に何もないように見え、そのまま通り抜ける。

仕掛けを解除して無限回廊を終える場合はポータルのオブジェクトを非活性化します。

ここら辺はスクリプトを組む必要がありますが、ただ該当のGameObjectにsetActive(false)を設定するだけなので苦労することはないと思います。

ポータルを非活性化して3Fのフロアから階段を見上げた場面、本来の3Fの階段と出口のドアが見える。

今回はポータルの境目が分からないように壁の色を白一色で統一させています。少し見づらい感じもしますが、これはこれでおしゃれかなぁ、と(言い聞かせ)

後は完成するかどうかが心配・・・

使用アセット：Fluid Portals System & Non-euclidian Tunnels

assetstore.unity.com

【Unity】シンプルな物理ツールキット-磁力・水・風-VR対応

一段落

全国的に緊急事態宣言が解除されプロ野球やJリーグも再開が決まって、長く続いたコロナ禍が一段落したのと呼応したわけではないのですが、個人的に仕事の面でも一段落がつき、プライベート面はとっくに波が停止しているので、ここ最近は何事もない平穏な日々が続いております。

その所為かゲーム制作の方はGameJamに参加するも箸にも棒にも掛からぬような感じだったこともあり、全くモチベーションが上がらない状態で、1年掛けた2.5DSTGも進捗が進まないどころか大きく作り変える事にしたり、今年中にゲームアプリをリリースできるのか不透明な情勢です。

そんな訳でブログネタにするようなUnityの技術的な知見も広がっていないので、今回もアセット紹介となります。

物理ツールキット

『切磋琢磨するしかない！』を制作する際に物理演算に沿ったギミックを作れないか考えていたのですが、コガネブログさんの以下の記事を見つけて、ギミックとして使えそうだったので購入しました。

baba-s.hatenablog.com

その名の通り"磁力・水・風"の物理の挙動を再現できるアセットとなっています。

"Simple"とあるようにパラメータ等はシンプルで特に難しい設定無く導入することができます。

磁力

磁力を使う場合は磁力の影響を受ける全てのオブジェクトにRigidbodyとこのアセットの「Magnet」コンポーネントを設定します。

磁石が引き付けられる範囲を"OuterRadius"、引き付けれて停止する(オブジェクトがくっつく)範囲を"InnerRaius"で指定します。

挙動はこんな感じ

浮力

浮力は浮力が発生するオブジェクト(水となるオブジェクト)にRigidbodyと「Water」コンポーネントを設定します。

この「Water」が設定されたオブジェクトに接触したRigidbody全てに対して「浮力」の効果を加えます。

キャラクターのお尻が浮いてるのは重心設定の関係です。

風力

風力の場合はまず空のオブジェクトにBoxCollider等のColliderを設定します。これが風力を受ける範囲になります。

そして「Wind」コンポーネントを設定します。

風の方向はSceneビュー内にて水色の線で表示されるので、それを見ながらオブジェクトを回転させて風向きを設定します。

浮力と同様、この「Wind」が設定されたオブジェクトのCollider内にある全てのRigidbodyに対して「風力」の効果を加えます。

分かりやすいように風の範囲にパーティクルを表示しています

 簡単に導入できる

前述のように"磁力・水・風"の物理効果を簡単にゲーム内に導入することができます。

『切磋琢磨するしかない！』では風力だけ使用しましたが、アイデア次第で多種多様なギミックを作ることができるかと思います。

assetstore.unity.com

【Unity】流体ポータルシステム と 非ユークリッドトンネル

猿か

成功体験に味を占めたのか毎日のように扇動的なハッシュタグがTwitterのトレンド入りしてくることにウンザリしている皆さんこんにちは。よっぽど「～に抗議ます」って言葉が好きなんでしょうね。無駄に吠える猿。

さて、まるで数学の問題のようなタイトルですが、これは最近購入したUnityアセットの名前です。Google先生に日本語訳をお願いするとこんな感じの名前になる。

"Fluid Portals System & Non-euclidian Tunnels"

assetstore.unity.com

 "Portal"とついていることから察しの言い方は気づくかもしれませんが、これはPortalシステムを簡単に導入できるアセットで、今回はこのアセットについて紹介したいと思います。

Portal的システム

特に説明する必要もないぐらい「Portal」というギミックは同名のゲームの存在で有名かと思いますが、その仕様を一言で説明すると「どこでもドア」的なもの、と言えます。

「Portal」は二つの空間を繋ぐゲートとなり、Portal越しに互いの世界を覗き見ることができるし、Portalをくぐり抜けることで両空間を行き来することができるシステムです。

この「Portal」をUnityで実現する手法については色々なブログで取り上げられていますが、大抵は同じ手法で説明されています。

曰く、Portal的システムを構築するには以下の3つの処理が必要らしい。

1. 相手側の世界を表示する
2. こちら側の視点と相手側の視点を連動させて動かす
3. 相手側の世界へ移動させる

例えばAとBの二つの空間があったとして、AのエリアにPlayerがいるとします。そして、Player側の映像はMainCameraで撮影されているとします。

一方、BのエリアにもCameraを設置します。しかし、こちらの映像はゲーム画面に直接映すのではなくA側のPortalに設定されているRenderTextureに表示させます。

二つのCameraは連動しておりPlayerに合わせてMainCamraが動くと、BエリアのCameraも同じように動きます。

MainCameraが上を向くとBエリアのCameraも上を向き、Playerが前後左右に移動するとそれに合わせてどちらのCameraも動きます。

そして、PlayerがPortalに接触(Collider内に侵入)するとPlayerをMainCamraと共にBエリアのPortal位置へ移動させます。

この時、B側のCameraは無効化され、逆にA側にMainCameraと連動したCameraが設置されます。

手法だけ聞くと簡単そうに思えますが、いざ実装しようとすると意外と面倒くさいです。

 というのも、カメラの動きを連動させるにも互いのPortalの向き(方向)を考慮しないといけないし、Playerを相手世界へ移動させるにも違和感のないスムーズな移動をさせるにはPortalに対する進入角度と退出角度を合わせる必要がでてきます。

そこで今回紹介するアセット「Fluid Portals System & Non-euclidian Tunnels」の登場です。

Fluid Portals System & Non-euclidian Tunnels

前置きを長々と説明しましたが、それもこのアセットではセットアップ等の作業が殆どいらずに済む為、特に書くことがないからです。

 Fluid Portals Systemを使ってPortalシステムを実現する手順は以下の3つ

1.Prefabs配下にある「portals_back_and_forth」をシーン内に配置

2.子オブジェクトのportal_one, portal_twoを双方向で移動させたい位置に置く

3.Prefabs配下の「Player(dg_simpleFirstPersonController)」をシーンに配置

以上になります。各Prefabをシーンに配置するだけ。もし、導入するシーンにCameraが既に設置されている場合は3.の工程は不要です。その代わり

• Cameraに"MainCamera"のtagを設定する
• Portalで移動させるPlayerのオブジェクトに"Player"のtagを設定する

上記二つの設定を行う必要があります。

また、CameraはPlayerオブジェクトの子オブジェクトであることが望ましいみたいです。(そうでないとPortal移動時に変な回転が起きる)

前置きの中で説明したMainCameraと連動させるCamera等はゲームPlay時に自動的に生成される為、こちら側での設定は不要です。

ただ、Portalを同じシーン内に複数個設置する場合はPortalSetupコンポーネントのGroupID欄にIDを設定する必要があります。

試しにA,Bの部屋を作ってそれぞれにPortalを設定しました。

オレンジの部屋(Room-A)にある青いポールはPlayerです。

この状態で動かしてみるとこんな感じ、奇麗にPortalシステムが実現されていることが分かります。

実はこのアセットの導入から上の動画を撮るまで一時間もかかっていません。

ドキュメントが全て英語で簡単な説明しかない、かつ設定手順はYoutubeを見ないけない、と不親切な点もありますが、先程も紹介したように殆ど設定不要で導入できるし、何よりPortal間の移動、表示がスムーズで違和感のないPortalシステムを作ることができます。

製作中のゲームでPortalシステムを使う事を考えている方はこのアセットの導入を検討されてはどうでしょうか。

【雑記】作りたかったゲームと作ったゲーム：GameJamを振り返る(実装編)

話題と拡散

「たった1人の投稿が大きな輪に広がって」というSNS神話を信じている純粋な皆さんこんにちは。私はこれまでブログもTwitterもそこまで積極的に利用していませんでしたが、事前の話題も仕掛けもない投稿がバズってTV等に取り上げられて彼方此方のマスコミから取材を受けるようなるとか、そんな幸運が転がっているなのらもっと積極的にSNSを利用していこうと思いました。嘘だけど。

前回からの続き

さて、前回のブログではGW中に製作したGameJam投稿作品『切磋琢磨するしかない！』について企画からコンセプト決めまでの過程を記事に書きました。

【雑記】作りたかったゲームと作ったゲーム：GameJamを振り返る(その１) - 原カバンは鞄のお店ではありません。

『room6GameJam2020』兼『おうちGameJam』投稿作品はこちら

unityroom.com

『切磋琢磨するしかない！』は螺旋状のステージをジャンプだけで進んでいくアクションゲームとなっています。

今回はこのゲームを作るにあたって苦労した点や工夫した点についてを実装編として記事に記したいと思います。

物理演算で公転させる

『切磋琢磨するしかない！』ではステージが螺旋状となっている為、プレイヤーのキャラクターは当然ながら螺旋の中心を軸とした公転となるように動かさないといけません。

Transformを使用した公転運動はRotateAroundメソッドがUnityで用意されていますが、今回の場合は物理演算を活用するのでRotateAroundではなく、Rigidbodyに力を加える方向を調整して公転運動を実現しています。

これについてはブログでも以前記事にしました。

【Unity】RigidBodyを使って螺旋階段を登りたい - 原カバンは鞄のお店ではありません。

要は『円軌道の接線方向に力を加え続ける』ことで公転運動を実現しているのですが、キャラクターは止まっている場合もあるのでジャンプしている間だけ『接線方向に力を加える』ということになります。

しかし、接線方向に加える力はForceMode.Force(継続的な力)となるので、この力を掛けづけるとキャラクターの挙動しては移動方向へ引っ張られたような挙動になります。

試しに、ジャンプ開始時にForceMode.Impulse(瞬間的な力)を加えただけの場合と、ジャンプ中にForceMode.Forceで力を加え続けた場合の動作を比較すると、キャラクターのジャンプ軌道は放射線より不自然に伸びた軌道になりちょっと違和感を覚えます。

ジャンプ開始時のみ

ジャンプ中に力を加えた場合

この為、接線方向に力を加えるのはジャンプ中全てではなく、ジャンプ開始から一定時間だけ、としています。

ここで問題が

実は『円軌道の接線方向』というのは『円軌道から離れる方向』となるので、接線方向に力を加えるのを一定時間だけとすると、その後は着地するまで円軌道から離れていき、どうしても公転運動の円周が徐々に大きくなる運動となってしまいます。

図にするとこんな感じ

この為、『切磋琢磨するしかない！』ではジャンプ中に加える力は『円軌道の接線方向ベクトル』に『軌道を戻す方向ベクトル』を加えた方向に力を掛けるようにしています。

 上の図のオレンジの方向へ力を掛ける

その他の調整

キャラクターの挙動を物理演算に任せると言う事で、上記の対応に加えてジャンプ時に加える力や角度、地面との反発係数や摩擦係数だったりのパラメータを色々変えながらテストが必要でした。

その中で分かった事

• ジャンプを繰り返すなら、着地のタイミングでrigidbodyのvelocityを0にした方が良い
• オブジェクトの重心はRigidbodyのcenterOfMassで変えることができる

他にも色々な修正を加えて納得できる挙動になるまで時間がかかりました。

また、当初はキャラクターが画面の中央に来るように設定していたのですが、足場が螺旋状(円筒状)に並んでいるステージ構成上、どうしても移動先の地点が見ずらくなる、また、前(右)へしか進まない為、自機より後ろの領域が多い(＝プレイヤーにとって無意味な領域が増える)と言う事に気づいて、目標地点が中央に来るようなカメラ位置に変更しました。

自機が中央の場合

左寄りに修正

こっちの方がプレイしやすいし、無駄がない

以降の作業はバタバタ

上記の色々な調整に時間を取られたせいでroom6gamejam2020の締め切りが5/6なのに、2日前になってやっとステージ作成に取り掛かる状態、しかも最終日の5/6はなぜか出勤日だったので実質的な締め切りは5/5、「あー、終わらないかも」と半分絶望的な気分で作業を進めていました。

まぁ、ステージの制作はギミックをステージ上に並べるだけだったのですが、その配置でクリア可能なのか設置する毎にテストプレイで確認する必要があって思った以上に作業が進まない、しかもSEやBGM関連の処理も全然未実装だったので本当にギリギリの作業でした。

それも日が変わって最終日の深夜になってやっと全作業が終了。なんとか期限内にunityroomへ投稿することができました。どうもありがとう。

作業を終えて・・・

振り返ってみると、今回は物理演算を使ったゲームを作るのが初めてと言う事もあって、色々な調整に時間が掛かったという印象です。

作品の出来自体は自分的には満足なのですが、ゲームバランスの考慮等々の配慮が足らなかったせいなのか評価はイマイチで、閲覧数(＝プレイ数)もなかなか増えずにいます。残念。

『おうちGameJam』では実際にプレイ実況を配信されるそうなので、そちらの反応も楽しみにしつつ、今回の反省点を次作以降に繋げていければなぁ、と思っています。

『切磋琢磨するしかない！』では新たに物理演算に関するアセットを購入して使用しているので、そちらに対する使い方、感想等は次回の記事で。

【雑記】作りたかったゲームと作ったゲーム：GameJamを振り返る(その１)

GWはGameJam三昧だったぞい

何の楽しみもないGWが終わり、地方によっては巣籠もりの季節もボチボチ終わりそうですが私の住んでいる福岡では未だに気の抜けない状況となっています。

毎年GWは何もないと言いつつもスポーツ観戦やライブ観戦、お祭り等々の行楽行事が詰まっていたのですが、今年はそれが全くのゼロで本当に何の予定もない長い休日が続いただけでした。

今年はこんな世間の情勢を反映してか、GameJamという名の短期間ゲーム開発イベントが三本連続で開催されていました。

前回の記事では『Unity1Week』と『room6GameJam2020』の二本のGameJamが開催されるよ、と紹介しましたが、その後に『おうちGameJam』というGameJamも開催の発表があり、どれも重複エントリー可能ということもあってゲーム開発者界隈では例年以上に盛り上がっていました。

ちなみに『おうちGameJam』とは・・・

panora.tokyo

5月1日～5月10日の期間にウェブやスマホ、PCなどで遊べるゲームを制作。
5月31日までに専用フォームから必要事項を入力のうえ応募すると、Unityアセット10％割引クーポンが5枚もらえます。
さらにVTuberメディアということで、できあがったゲームを遊んでくれるゲーム好きなVTuberさんも大募集！
好みのゲームを選んで生放送や動画を投稿してもらう企業案件で、最大10名のVTuberさんを募集します。

とのことで、これまではゲームを投稿してもゲーム開発者の内輪による評価がほとんどでしたが、VTuberさんに遊んでもらえると言う事で展示イベントなどに参加できない地方の開発者としては貴重な意見が聞ける(かもしれない)GameJamとなっています。

あとクーポン貰える。これ大事

作った作品の紹介

そんな訳で私は『room6gamejam2020』と『おうちGameJam』の二つに参加させて頂きました。

(『Unity1Week』は期限に間に合わず＆お題に沿ったものにならず・・)

unityroom.com

螺旋状のステージをジャンプのみで前へ進んでいくアクションゲームとなっています。

自機のキャラクターは全て物理演算を活用しており、少し難易度が高いゲームとなっていますが、ゲームオーバーはなくマウスクリックだけで遊べるので気軽に楽しんでいただけると幸いです。

製作過程を振り返る

『おうちGameJam』では応募特典として

• ゲーム作成のノウハウなどをブログで公開：Unityアセット10%割引クーポンを 5枚プレゼント
• ゲーム内で使っているアセット活用ノウハウをブログで紹介：Unityアセット10%割引クーポンを 5枚プレゼント

とあるので、今回は上記のゲームの製作過程を振り返りたいと思います。

 ■企画

 GameJamに参加するにあたり、「物理演算系のゲームを作りたい」というのが最初の目標でした。

これまでキャラクターの挙動は全てスクリプトで制御するようなゲームを作っていましたが、今回は物理演算に制御を丸投げしたゲームを作ってみよう、そんな軽い気持ちでゲームの仕様を決めてました。

ただ「物理演算系のゲーム」という仕様は決まっていても、どんなコンセプトで何を最終目標にするのか、を開発前にハッキリ決めておかないと製作途中で仕様がブレブレになり、結果良く分からないものが出来上がってしまいます。

私が物理演算を使用したゲームとして直ぐに思い浮かんだのが「Getting over it」でした。

「Getting over it」は一部で"壺おじ"という愛称で親しまれているように、奇抜なキャラクターデザインで有名なゲームですが、内容の方はしっかりと計算されたやりごたえのあるゲームデザインで、各種メディアやゲーム実況者に取り上げられて賞賛(?)されているゲームです。

そこで『俺も"壺おじ"ゲーム作りたい』と分不相応な企画を立てるに至ったのです。

■分析→コンセプト決め

今回公開した「切磋琢磨するしかない！」では螺旋状のステージを進んでいくアクションゲームとなっています。

キャラクターは前へ上へ、一方向にしか進めませんがステージが螺旋状となっているため、もし操作ミスでコースから外れると落下して円周一周分(あるいはそれ以上)元の場所に戻ってしまいます。

これは「Getting over it」をパク・・オマージュとするために私なりに分析した結果、「Getting over it」の最大の特徴が「一つのミスでそれまでの進捗がゼロになる」ことにあると考えて、それを最も良く実現できるのが「螺旋状のステージ」だと結論付けたからです。

巷のゲーム実況の動画を観てみると「Getting over it」ではとにかく実況者がイライラを爆発させている場面が多いです、中にはマウスを叩き割らんばかりに怒りを露にする実況者もいました。

これが「操作ミスで別ルートへ進む」だったら、それほど怒りを覚えることもないと思うのですが「元の場所に戻る」は積み上げてきたものを全て失う、と言う事を意味します。思うように事が運ばず逆に元へ戻ってしまったら、誰だってイライラするでしょう。

なので今回の開発にあたりゲームコンセプトとして

• 操作が単純
• トライ＆エラーを繰り返す
• ゲームオーバーがない
• イライラする(させる)

を掲げて、それを実現するために

• 螺旋状のステージ
• マウスクリックだけでプレイ可能
• でも操作は難しい

これらを満たすようなゲームを目標にすることにしました。

長くなったので、実装中に学んだノウハウ等は次回の記事で・・・

【Unity】Colliderをスクリプトから無効化する

unity1weekとroom6gamejam

何処にも行けないGWを目前にunity1weekが始まりました。今回のお題は「密」だそうで、毎年話題の「今年の漢字」並みに世相を反映したお題となっています。これと同時開催として毎年恒例となっていたroom6さん主催のroom6gamejamも始まっています。

同じ作品でどちらのイベントにもエントリー可能だそうですが、ちょっとだけ受付期間や評価方式が異なるので注意が必要です。

■Unity1Week

• 受付期間: 2020/04/27 00:00 ～ 2020/05/03 20:00 (遅刻可)
• お題：『密』
• 投稿時のハッシュタグ：『unity1week』
• 評価期間: 2020/05/04 ～ 2020/05/10
• 評価方式：プレイヤー投票による採点方式
• イベントURL: https://unityroom.com/unity1weeks

■room6GameJam2020

• 受付期間: 2020/04/27 00:00 ～ 2020/05/06 23:59
• お題：なし
• 投稿時のハッシュタグ：『room6gamejam2020』
• 評価期間: 2020/05/07 ～ 5月下旬
• 評価方式：プレイヤー投票、および各審査員による副賞
• イベントURL: https://www.room6.net/room6gamejam2020

一応、前回の記事のネタの為にちょっとだけ作ったプロジェクトがあるので私も参加する予定です。

まぁどちらにも参加できれば良いのですが、期限に間に合わない＆お題に沿ったものになりそうもない、ということで『room6gamejam2020』だけのエントリーになるかと、、、そちらの期限には間に合うように頑張りたいと思います。

 と、いうわけで・・・

前回の記事でも紹介したようにエントリー用の作品はキャラクターがジャンプしながらステージを進んでいくアクションゲームになる予定なのですが、そこ、良くあるやつって言わない、個人的な挑戦としてキャラクターの動作にRigidbodyの物理演算を活用することに取り組んでいます。

これまでは直にtransformの位置や角度を変更してキャラクターを動かしていたのですが、それを今回は物理演算で実現する為、こちらの意図とは違う動作になったりすることが良くあります。

直近でぶつかった問題が・・・

斜面を全く登れない・・・

最初はジャンプ時に力を加える方向が問題なのかと思ってプログラムのロジックを見直したりしたのですが全然直らず。

色々試した末、キャラクターの動きを良く良く見直して、ジャンプの立ち上がりの時にキャラクターのColliderが斜面のColliderに引っ掛かっているのではないか、という結論になりました。

Colliderの設定

キャラクターのColliderには複数のColliderでその形が簡略化したものになるよう設定しています。

キャラクターのCollider

分からいずらいのでColliderだけにするとこんな感じ、どっかのアニメの潜水艦みたいな形になっています。

どうやら、この胴体部分のCapsuleColliderがジャンプの立ち上がりの時に斜面に引っ掛かって、ジャンプしようとしても直ぐに斜面に戻されて全然前に進めない状態になっているようで、つまりはジャンプ開始直後はこのCapsuleColliderを無効化しないといけない、ということになります。

早速、Google先生に尋ねてみると、Colliderの有効/無効の設定は通常、Inspector上のチェックボックスによる設定で行いますが、スクリプトではColliderコンポーネントのenabledオプションの値を変更することで、設定の変更を行うことができることが分かりました。

private Collider[] CapCollArray;

void OnEnable()
{
    // CapselColliderの取得
    CapCollArray = this.GetComponents<CapsuleCollider>();
}

void Enabled_Collider()
{
    // Colliderを有効化する
    foreach (CapsuleCollider col in CapCollArray)
    {
        col.enabled = true;
    }
}

void Disabled_Collider()
{
    // Colliderを無効化する
    foreach (CapsuleCollider col in CapCollArray)
    {
        col.enabled = true;
    }
}

CapsuleColliderは複数あるのでGetComponentsメソッドで配列として取得します。

ジャンプ開始時にDisabled_ColliderをコールしてColliderを無効化、タイマー処理で一定時間、Enabled_ColliderによりColliderを有効化するようにしました。

結果・・・

ちゃんと斜面を登れるようになりました。めでたし、めでたし。。。

後は完成させるだけですねぇ・・・(遠い目)

【Unity】CastShadowとReceiveShadow

半休業状態

未だコロナ禍の脅威が収まらない為、全都道府県で外出自粛せざるを得ない日々が続いております。私の会社でも多分に漏れず、出勤率の低減を実現するために2,3日単位の交代勤務体制となりました。そのため、週の半分ぐらい自宅に閉じこもっているのですが、そんな中、朝昼のテレビ番組を拝見すると、殆ど毎日同じ顔触れが同じ話題を同じように話しているので、だったらマスコミも交代で休止すればいいのに、と思っている皆さんこんにちは。あんなの毎日楽しみにしている人っているのだろうか？

自宅待機中に

プロジェクトのセキュリティ上、自宅でのテレワークができないので自宅待機中は完全な休みとなっています。

よって自宅で暇を持て余してしまい、以前ブログの記事の為にちょっとだけ作っていたものをアレコレ改造していました。

www.karvan1230.com

上の記事の中でRigidbodyを使った公転運動に挑戦し、ボールが螺旋階段を登るような処理を作っていたのですが、それをちょっと改良して・・・

キャラクターがぴょんぴょん跳ねて登るようにしました。
画面をクリックすると力を蓄えて高く遠くへジャンプします。

ここから色々加えてゲーム化出来そうかなー、と思っているのですが、試作段階なので画面がちょっと味気ないです。
なので手始めにキャラクタ－の影を地面に表示してみることにしました。

影を表示する

Unityで3Dモデルに影を投影するには二段階の手順が必要です。

まず、影を落とす側のMeshRendererの設定で「Cast Shadows」の設定をONにします。

次に影が投影される側のMeshRendererの設定で「Receive Shadows」の設定をONにします。

これでキャラクタ－の影が地面に投影されることになります。
早速動かしてみると・・・

・・・お気づきいただけだろうか・・・

透過する影

キャラクターが移動している地面は螺旋階段状になっているのですが、キャラクターの落とした影が二段目の地面と、一段目の地面で二重に投影されています。

どうやらUnityではCastShadowで作られた影はその投影範囲にあるReceiveShadowsが設定されたMesh(3Dモデル)に全て投影されるらしい。

つまりキャラクターと地面の間に他のMeshがあってもその影響は考慮されていない。

なので、地面側もキャラクターと同様に影を落とすよう、「Cast Shadows」をONに設定する必要があると言う事で・・・

上の動画は地面側にも「Cast Shadows」を設定したパターンです。

不自然な影は消えましたが、今度は影ばっかりで画面が暗い、加えてキャラクターのエミッション設定でこっちが不自然に見えるという結果に・・・ん～、一体どうしたものか・・・