プレイヤーをジャンプさせる
最終更新：
orika_ex_miyako 2020年06月25日(木) 15:02:39履歴
プレイヤーをジャンプさせるための設計を考える 
移動の処理が実装されたので、今度はジャンプの処理をプレイヤーに実装していきます。
ジャンプの設計について考えながら、実装方法を考えていきましょう。
アクションゲームですので、ジャンプボタンを押したら、それに合わせてプレイヤーがジャンプし
さらにジャンプと同時にジャンプのアニメーションが再生される、という流れが自然かと思れます。
ジャンプとは、どのようにすれば実装できるのでしょうか。
プレイヤーの移動は、位置情報を更新していくことで実装が可能でした。
ジャンプも同じ考え方でよいと思います。
ゲームオブジェクトのY軸（高さ）の位置情報を更新することができれば、ジャンプしているように見えるでしょう。
つまり、プレイヤーの位置が地面の位置よりも高くなれば、ジャンプしている状態になりますね。
そのまま地面まで落下が出来、プレイヤーと地面が前と同じ位置になれば着地となり、ジャンプしていない状態になります。
そのY軸の位置情報を更新するのに合わせてジャンプのアニメーションも再生できれば、上手く同期が出来そうです。
気を付けるべきは、Y軸の位置情報をどのように更新するか、です。
例えばゆっくりとした位置情報の更新では、ゲーム画面のPlayerもゆっくりと移動してしまうため
それではジャンプ、という挙動には見えなくなってしまいますね。
ジャンプということであれば、ある程度の高さまで勢いよく移動をし、その後、落下してくるという挙動が
ユーザーの期待するジャンプになると思います。
また、位置情報を変化させる方法はいくつかありますが、「勢いよく」移動するのか、「一瞬でその位置まで」移動するのかでは、
位置情報を変更させる処理を行う機能が異なります。一瞬で移動ではなく、地面から空中に勢いよく滑らかに飛び上がる方法が、よりジャンプに見えますね。
そのため、ここでも移動の時と同じように、RigidbodyのAddforce関数を使ってY軸の位置情報の更新を実装すればジャンプのように見える挙動になります。
ユーザーの考えるゲーム内の見た目の動きを、どのような機能を使ってプログラムをすれば期待している挙動になるのか
これを念頭に置いて設計を考えていくとよいと思います。また、位置情報の更新方法も何種類かありますが
それらの特徴を理解することにより、どの処理が最も実装に適しているのか、判断をすることが大切です。
そのためにも色々な処理を試して、どのような挙動をするのかを知っておくことが必要になります。
では次に、ジャンプする際には、どのような順番の制御処理が必要になるか、考えていきましょう。
期待する挙動と、そのために考えられる制御方法です。
�．廛譽ぅ筺爾�地面にいる際にジャンプボタンを押すことでジャンプが出来る。
=> 地面とプレイヤーとの接地判定が必要
�▲献礇鵐彙罎忘禿戰献礇鵐廛椒織鵑魏，靴討癲�二段ジャンプなどはしない。
=> ジャンプ中であるという判定、あるいは、それに見合う状態が必要
�０榮庵罎縫献礇鵐廚靴疹豺隋�移動先に着地する。
=> その場でジャンプした場合は、その場に着地し、移動中であった場合には、移動先の位置で着地する
�っ綯呂靴燭藝禿戰献礇鵐廛椒織鵑妊献礇鵐廚�出来る。
=> �，寮榁枠縦蠅汎韻現萢� 判定の結果により、地面にいるのか、いないのか（空中なのか）が判定される
ジャンプの設計について考えながら、実装方法を考えていきましょう。
アクションゲームですので、ジャンプボタンを押したら、それに合わせてプレイヤーがジャンプし
さらにジャンプと同時にジャンプのアニメーションが再生される、という流れが自然かと思れます。
ジャンプとは、どのようにすれば実装できるのでしょうか。
プレイヤーの移動は、位置情報を更新していくことで実装が可能でした。
ジャンプも同じ考え方でよいと思います。
ゲームオブジェクトのY軸（高さ）の位置情報を更新することができれば、ジャンプしているように見えるでしょう。
つまり、プレイヤーの位置が地面の位置よりも高くなれば、ジャンプしている状態になりますね。
そのまま地面まで落下が出来、プレイヤーと地面が前と同じ位置になれば着地となり、ジャンプしていない状態になります。
そのY軸の位置情報を更新するのに合わせてジャンプのアニメーションも再生できれば、上手く同期が出来そうです。
気を付けるべきは、Y軸の位置情報をどのように更新するか、です。
例えばゆっくりとした位置情報の更新では、ゲーム画面のPlayerもゆっくりと移動してしまうため
それではジャンプ、という挙動には見えなくなってしまいますね。
ジャンプということであれば、ある程度の高さまで勢いよく移動をし、その後、落下してくるという挙動が
ユーザーの期待するジャンプになると思います。
また、位置情報を変化させる方法はいくつかありますが、「勢いよく」移動するのか、「一瞬でその位置まで」移動するのかでは、
位置情報を変更させる処理を行う機能が異なります。一瞬で移動ではなく、地面から空中に勢いよく滑らかに飛び上がる方法が、よりジャンプに見えますね。
そのため、ここでも移動の時と同じように、RigidbodyのAddforce関数を使ってY軸の位置情報の更新を実装すればジャンプのように見える挙動になります。
ユーザーの考えるゲーム内の見た目の動きを、どのような機能を使ってプログラムをすれば期待している挙動になるのか
これを念頭に置いて設計を考えていくとよいと思います。また、位置情報の更新方法も何種類かありますが
それらの特徴を理解することにより、どの処理が最も実装に適しているのか、判断をすることが大切です。
そのためにも色々な処理を試して、どのような挙動をするのかを知っておくことが必要になります。
では次に、ジャンプする際には、どのような順番の制御処理が必要になるか、考えていきましょう。
期待する挙動と、そのために考えられる制御方法です。
�．廛譽ぅ筺爾�地面にいる際にジャンプボタンを押すことでジャンプが出来る。
=> 地面とプレイヤーとの接地判定が必要
�▲献礇鵐彙罎忘禿戰献礇鵐廛椒織鵑魏，靴討癲�二段ジャンプなどはしない。
=> ジャンプ中であるという判定、あるいは、それに見合う状態が必要
�０榮庵罎縫献礇鵐廚靴疹豺隋�移動先に着地する。
=> その場でジャンプした場合は、その場に着地し、移動中であった場合には、移動先の位置で着地する
�っ綯呂靴燭藝禿戰献礇鵐廛椒織鵑妊献礇鵐廚�出来る。
=> �，寮榁枠縦蠅汎韻現萢� 判定の結果により、地面にいるのか、いないのか（空中なのか）が判定される
�．廛譽ぅ筺爾�地面にいる際にジャンプボタンを押すことでジャンプが出来る
地面となるゲームオブジェクトと、プレイヤーとの間に接地しているかどうかの判定を盛り込むことで
「プレイヤーが地面にいる」という条件を分岐することが可能であると考えられます。
この接地判定の方法にはいくつかやり方があります。ここでは今まで利用していないLayer（レイヤー）の機能と
それを利用するLinecast（ラインキャスト）の機能を利用して、判定を行っていきます。
Layerにはあらかじめ何種類か登録されており、Groundというレイヤーがあります。
地面役のゲームオブジェクトを選択し、LayerをDefaultからGroundに変更しましょう。
これにより、より地面としての役割を担うことが出来ます。
Linecastは、Unityの持つPhysics（フィジクス）によって利用可能な機能の１つです。
if文と組み合わせることで、指定されたゲームオブジェクト（ここではPlayer）から見えない光線を発射し、
その光線と指定したレイヤー（ここではGroundのレイヤーを持つゲームオブジェクト）とがぶつかっているかどうかを
Bool型の戻り値として返してくれます。
このBoolの値を接地状態として読み替えることにより、接地判定として実装を行います。
Linecastの結果がTrueならば、Playerから発射された見えない光線がGroundレイヤーを持つ地面のゲームオブジェクトとぶつかったことになります。
つまり、ゲームオブジェクト同士がくっついている状態であると考えることが出来ますので、「地面にいる」状態であると言えます。
逆にFalseの場合は、先ほどの光線がレイヤーとぶつかっていない状態になりますので、ゲームオブジェクト同士がくっついていない状態であり
「地面にいない」状態であると言えます。
判定方法は他にもいくつかありますが、このLinecastによるBool型による処理が接地判定に有用であるため、
この機能を接地判定として実装することにします。
ジャンプ用のボタンを押した際の条件に「地面にいる状態で」ジャンプボタンを押したらジャンプできるとすれば、１つ条件を盛り込めばよいでしょう。
「プレイヤーが地面にいる」という条件を分岐することが可能であると考えられます。
この接地判定の方法にはいくつかやり方があります。ここでは今まで利用していないLayer（レイヤー）の機能と
それを利用するLinecast（ラインキャスト）の機能を利用して、判定を行っていきます。
Layerにはあらかじめ何種類か登録されており、Groundというレイヤーがあります。
地面役のゲームオブジェクトを選択し、LayerをDefaultからGroundに変更しましょう。
これにより、より地面としての役割を担うことが出来ます。
Linecastは、Unityの持つPhysics（フィジクス）によって利用可能な機能の１つです。
if文と組み合わせることで、指定されたゲームオブジェクト（ここではPlayer）から見えない光線を発射し、
その光線と指定したレイヤー（ここではGroundのレイヤーを持つゲームオブジェクト）とがぶつかっているかどうかを
Bool型の戻り値として返してくれます。
このBoolの値を接地状態として読み替えることにより、接地判定として実装を行います。
Linecastの結果がTrueならば、Playerから発射された見えない光線がGroundレイヤーを持つ地面のゲームオブジェクトとぶつかったことになります。
つまり、ゲームオブジェクト同士がくっついている状態であると考えることが出来ますので、「地面にいる」状態であると言えます。
逆にFalseの場合は、先ほどの光線がレイヤーとぶつかっていない状態になりますので、ゲームオブジェクト同士がくっついていない状態であり
「地面にいない」状態であると言えます。
判定方法は他にもいくつかありますが、このLinecastによるBool型による処理が接地判定に有用であるため、
この機能を接地判定として実装することにします。
ジャンプ用のボタンを押した際の条件に「地面にいる状態で」ジャンプボタンを押したらジャンプできるとすれば、１つ条件を盛り込めばよいでしょう。
�▲献礇鵐彙罎忘禿戰献礇鵐廛椒織鵑魏，靴討癲�二段ジャンプなどはしない
上記�，亮汰�と同時に、この�△僚萢�も自動的に実装されます。
ジャンプ中、つまり「地面にいない」状態のときにはジャンプボタンを押しても反応をしないようにするのが、一番実装しやすい条件となりますが
�，離献礇鵐廚任�る条件としてすでに「地面にいる状態でジャンプボタンを押したらジャンプできる」という条件がありますので
これはそのまま「地面にいない状態ならジャンプボタンを押してもジャンプできない」というように逆に読む解くことが可能です。
�，亮汰�と同時に、この制御も実装されていることになりますね。
ジャンプ中、つまり「地面にいない」状態のときにはジャンプボタンを押しても反応をしないようにするのが、一番実装しやすい条件となりますが
�，離献礇鵐廚任�る条件としてすでに「地面にいる状態でジャンプボタンを押したらジャンプできる」という条件がありますので
これはそのまま「地面にいない状態ならジャンプボタンを押してもジャンプできない」というように逆に読む解くことが可能です。
�，亮汰�と同時に、この制御も実装されていることになりますね。
�０榮庵罎縫献礇鵐廚靴疹豺隋�移動先に着地する
移動とは、位置情報を更新することで実装していますので、ジャンプした際に移動する位置を0にするという処理がない限りは
この状態も自動的に実装されることになります。
移動していない状態であれば、位置情報も更新がありませんので、ジャンプした位置に着地することになります。
この状態も自動的に実装されることになります。
移動していない状態であれば、位置情報も更新がありませんので、ジャンプした位置に着地することになります。
�っ綯呂靴燭藝禿戰献礇鵐廛椒織鵑妊献礇鵐廚�出来る
これも�，亮汰�と同時に制御が実装されます。
LinecastによるBool型での戻り値はUpdateにて処理されていますので、このif文によるBool型は常時監視されている状態です。
ですのでジャンプが終わって地面との接地判定が取れればLinecastはTrueを返すようになりますので、
結果、またジャンプができる状態が成立するようになります。
以上のように、発生するであろう問題点や疑問点は、それらにつきすべての処理を実装しなければならない訳ではなくて
いずれかの処理によって問題がクリアされるもの、あるいは逆に問題となってしまうものなど、様々な結果を生じさせます。
これをイメージすることにより、設計の段階で多くの疑問点が露呈できれば、実装する前にそれを見越したプログラムを考えていくことが出来ます。
今回の場合は� 銑い泙覇段未閉媛箪萢�を加えずともジャンプの処理を追加すればすべて問題なく実装されますので、安心してプログラムを組んでいくことが出来ます。
LinecastによるBool型での戻り値はUpdateにて処理されていますので、このif文によるBool型は常時監視されている状態です。
ですのでジャンプが終わって地面との接地判定が取れればLinecastはTrueを返すようになりますので、
結果、またジャンプができる状態が成立するようになります。
以上のように、発生するであろう問題点や疑問点は、それらにつきすべての処理を実装しなければならない訳ではなくて
いずれかの処理によって問題がクリアされるもの、あるいは逆に問題となってしまうものなど、様々な結果を生じさせます。
大切なのは、１つの処理をいれることで多くの場所に影響が出る（少なくとも今回ジャンプを入れるだけでも� 銑い量簑蠹世鮃洋犬靴覆い箸覆蕕覆ぁ砲箸いΔ海箸覆里任后�
これをイメージすることにより、設計の段階で多くの疑問点が露呈できれば、実装する前にそれを見越したプログラムを考えていくことが出来ます。
今回の場合は� 銑い泙覇段未閉媛箪萢�を加えずともジャンプの処理を追加すればすべて問題なく実装されますので、安心してプログラムを組んでいくことが出来ます。
ジャンプのアニメーションを同期する
下記のスクショを参考にAnimationシーンを編集します。
ジャンプの処理とジャンプアニメーションの処理の実装例です。
Playerのインスペクター上にジャンプ力の数値を入力する項目が追加されますので、150〜300位で設定します。
またGroundLayerには、Playerとの接地の判定の対象となるレイヤーを設定できるようになりますので、こちらをGroundに変更しましょう。
isGroundのBool型は、本来はPrivateの変数で問題ありません。
ですが今回は、Debugの関係上、インスペクター上にて接地状態を確認できるようにPublicにしています。
これはDebug.Logを入れ込む場所がUpdateでの処理が行われるため、非常に多くのDebug.LogがConsoleに流れてしまい
実際に接地判定のBoolの値の動きを追うのが困難になるためです。
接地判定としての動きが問題なく追えたのであれば、あとでPrivateに戻しておきましょう。
Playerのインスペクター
ここまでの動画です。
https://gyazo.com/ca46a8a17bc2c2c9d2d1fb08988e2872
https://gyazo.com/5eef536f37e49c86c93a976098113120
ジャンプの処理とジャンプアニメーションの処理の実装例です。
<= ＋ボタンを押すと開きますので、自分なりの実装を行った上で確認をしてみましょう。
Playerのインスペクター上にジャンプ力の数値を入力する項目が追加されますので、150〜300位で設定します。
またGroundLayerには、Playerとの接地の判定の対象となるレイヤーを設定できるようになりますので、こちらをGroundに変更しましょう。
isGroundのBool型は、本来はPrivateの変数で問題ありません。
ですが今回は、Debugの関係上、インスペクター上にて接地状態を確認できるようにPublicにしています。
これはDebug.Logを入れ込む場所がUpdateでの処理が行われるため、非常に多くのDebug.LogがConsoleに流れてしまい
実際に接地判定のBoolの値の動きを追うのが困難になるためです。
接地判定としての動きが問題なく追えたのであれば、あとでPrivateに戻しておきましょう。
Playerのインスペクター
ここまでの動画です。
https://gyazo.com/ca46a8a17bc2c2c9d2d1fb08988e2872
https://gyazo.com/5eef536f37e49c86c93a976098113120
コメントをかく