Unityに関連する記事です

 2回に分けて、敵キャラの移動処理を実装します。
この手順では敵キャラの経路に沿った移動を行う機能を実装し、敵の移動処理を完成させます。

 以下の内容で順番に実装を進めていきます。


<実装動画>
動画ファイルへのリンク


手順10 ー敵キャラの移動と移動アニメの同期処理の実装ー
16.EnemyController スクリプトを修正して、敵キャラの移動している方向を取得し、その後、移動アニメと同期させる処理を実装する
17.EnemyController スクリプトのリファクタリングを行い、処理を簡潔化する



 新しい学習内容は、以下の通りです。

 ・TryGetComponent メソッドと out キーワード宣言
 ・Animator.SetFloat メソッド
 ・DOTweenの補間機能と実装例◆ OnWaypointChange メソッドー
 ・Vector3.normalized 変数を利用した正規化処理



16.EnemyController スクリプトを修正して、敵キャラの移動している方向を取得し、その後、移動アニメと同期させる処理を実装する

1.設計


 実装動画を確認してみてください。このような動画になる挙動を行うためにはどうすればよいか、考えてみましょう。

 ポイントは次の点です。

 ・敵キャラの移動方向に合わせて、その移動方向のキャラの移動アニメが再生される

 今回は実装していませんが、停止中のアニメを用意して足踏みを止めるようにしてもいいと思います。



 Animator こちらにて製作したアニメの遷移処理は、ゲームオブジェクトの Animator コンポーネント内にある Controller プロパティの部分で制御されています。
このコンポーネントは複数の画像をまとめてヒエラルキーにドラッグアンドドロップした際には、自動的に追加されます。


Animator コンポーネント



 Controller プロパティに登録されている情報が、先ほど Blend Tree などを設定した情報になります。
そのため、この Controller を変更することによって、異なるアニメの遷移を行うようになります。
 
 また Animator ビューの Parameters に設定した情報を操作するためにも、この Animator コンポーネントが必要になりますので、
アニメの制御を行う場合には、この Animator コンポーネントをスクリプト内で変数に取得して、それを利用するという方法で制御を行います。



 敵の移動に際しては現在の敵キャラの位置と、移動の目標となる地点の位置との比較によって「現在敵キャラが向いている方向」の情報を設定出来るようにします。

 この値を利用して、移動アニメの方向も制御するようにします。

 Blend Tree の部分でキャラのアニメが値の変化に合わせて上下左右の方向に切り替わったと思います。
その部分の制御に、この値を利用し、例えば右方向( Vector2 (1, 0) )の値が取得出来た場合には、その値を Blend Tree の値と同期させることにより、
移動アニメを右方向を向いて歩いているアニメに切り替えるようにします。


<Blend Tree と Parameter>
動画ファイルへのリンク


 動画を観るとわかりますが、インスペクターの Parameter を操作してキャラのアニメが切り替わると
Blend Tree の中にある X と Y の値が一緒に動いていることがわかります。
つまり、キャラの向いている方向の情報を、Parameter の X と Y の部分と同期させることができれば、
そのままキャラの移動アニメにも適用することができるということになります。

 これが今回の移動アニメとキャラの移動とを同期させるロジックになります。



 敵キャラの制御は EnemyController スクリプトにおいて行っていますので、
以上の制御処理を EnemyController スクリプトに実装して、キャラの移動と移動アニメとを同期させていきます。

 今回は実装例をそのまま掲載していますが、今後、自分で移動アニメなどの実装を行う場合も、同じような考え方で実装が出来ます。
どの処理とどの処理がつながっているのか、Unity の制御をどのようにすればスクリプトから行えるようになるのか、
設計の考え方、ロジックの作り方を覚えていって、自分のゲームにも活用できるようにしてください。



2.EnemyController スクリプトを修正する


 それでは実装をしてみましょう。
BlendTree の Palameter には Animator コンポーネントが持つ SetFloat メソッドを利用することで float 型の情報を送って制御することが出来ます。
そのためには Animator コンポーネントの情報を取得しておく必要がありますので、変数を用意しておくことから始めます。


EnemyController.cs


 スクリプトを修正したらセーブをします。


3.<TryGetComponent メソッドと out キーワード宣言>


 Unity2019.2以降に追加されたメソッドです。処理結果として bool 型で戻り値を返してくれます。
このときの処理結果というのは、指定したコンポーネントの型の取得を行い、それが取得できればtrue、取得できなければfalseが戻ります

 また out キーワードによる宣言があります。
 out キーワード宣言を行うと、out を付けた引数で指定した変数はメソッド内で必ず結果が入ることが保証されるものです。
そのため、処理結果の戻り値が true の場合には必ず、この out の後に宣言した変数内に型が代入されます

 端的にいうならば、GetComponent メソッドの処理に加えて、その処理の成否判定(コンポーネントが取得出来たか、出来なかったか)を同時に行ってくれるメソッドになります。

<実装例 
  TryGetComponent(out anim);

<実装例◆〔瓩蠱佑魍萢僉
if(col.gameObject.TryGetComponent(out Bullet bullet)) {

   // 処理を書く
}

 今回は実装例,僚萢として利用しています。スクリプト内に TryGetComponent メソッドを直接記述した場合、GetComponent メソッドと同様に、
このスクリプトがアタッチしているゲームオブジェクトのコンポーネントから指定されている種類のコンポーネントを取得してます。
それを out キーワード後の anim 変数に代入しています。GetComponent メソッドのように<型引数>を指定していないのは、anime 変数によって型を推論することが可能であるためです。

 out キーワード以降にはゲームオブジェクトから取得したい型と変数を宣言します。今回のように事前に変数の宣言をしている場合には、変数のみを用意しておくことが出来ます。

 もしもこの TryGetComponent メソッドの処理結果が実行可能ならば、つまり、ゲームオブジェクトに Animator コンポーネントがアタッチされているのであれば、
out として用意した anim 変数に Animator コンポーネントの情報が代入されます''。また、true の値が、それとは別に処理結果として戻ります。

 TryGetComponent メソッドの処理結果が false の場合には Animator コンポーネントの取得ができなかったため、anim 変数は null のままで、false が処理結果として戻ります''。


 なお TryGetComponent メソッドには複数の書式があります。こちらは下記のリファレンスを参照してください。

参考
Unity公式スクリプトリファレンス
Component.TryGetComponent
https://docs.unity3d.com/ScriptReference/Component...


4.<Animator.SetFloat メソッド>


 Unityのアニメーションは、Animatorクラスによって様々なアニメーションの制御が行えます。
Unity公式スクリプトリファレンス
Animator
https://docs.unity3d.com/ja/current/ScriptReferenc...

 今回はアニメーションの遷移のために、SetFloat メソッドを利用し、遷移の条件をこのメソッドの引数に指定してアニメーションの遷移を行っています。

 各メソッドの引数にはそれぞれ型の指定が異なりますが、いずれも第1引数は string 型です。この部分には、パラメータで設定した文字列を指定します。
文字列ですので大文字小文字は区別されます。パラメータに登録した文字列をこの第1引数に指定することでパラメータのもつ情報を変更することが出来ます。
そして、パラメータの値を変更する内容を第2引数に指定します。

 例えば、SetFloatであれば、第1引数に float 型のパラメータである "X" の文字列を指定し、第2引数に float 型の値を指定します。

  anim.SetFloat("Y", 0f);
  anim.SetFloat("X", -1.0f);

 こうすることで、このパラメータの値をスクリプトから書き換えることができます。その結果として、条件が合致したアニメーションに遷移することが出来ます。


<パラメータと Set〜メソッドの関連性>


参考サイト
Unity公式スクリプトリファレンス
SetFloat
https://docs.unity3d.com/ja/current/ScriptReferenc...


5.ゲームを実行して動作を確認する


 ゲームを実行してみましょう。敵キャラをヒエラルキーで選択した状態で Animator ビューを表示すれば、BlendTree の遷移の確認も行うことが出来ます。

<実装動画>
動画ファイルへのリンク

 Console ビューを確認してください。

 無事に制御を行うことが出来ていますが、処理として Update メソッドで移動アニメの変更を監視して制御しているため、
非常に大量の Debug.Log メソッドが実行されている、つまり、それだけ Update メソッドの処理が動いていることが分かります。

 敵キャラ1体でこれだけの処理を行いますので、もっと敵キャラが増えることが想定した場合、ゲーム内にかかる負荷は非常に高くなってしまうでしょう。

 次の手順ではこの観点から、どのようにすれば同じように制御を行いつつ、負荷を軽減していくことができるのか、設計から考えていきます。


17.EnemyController スクリプトのリファクタリングを行い、処理を簡潔化する

1.設計


 無事に敵キャラの移動と移動アニメとを同期させて、画面上の不具合を修正することができました。

 ここでは実装した処理の内容について、再度考えて、何か問題点はないか、あるのであれば修正が可能な部分がないかを精査していきます。
これは手順8でも学習したリファクタリングという作業になりますので、内部的な処理の修正になります。
そのため、現在実装している処理自体は修正前と同じように動いていることを念頭に処理を修正していく必要があります。

 修正したら、アニメが同期しなくなってしまった、ではリファクタリングとは言えないためです。
 


 EnemyController スクリプトをしっかりと読み返して、処理の内容を把握してください。
それを前提に、リファクタリングのための設計を説明します。

 現在の移動アニメの制御処理は、Update メソッドから毎フレーム ChangeAnimeDirection メソッドを実行し、現在の敵キャラの位置と
目標地点となる位置とを比較して、その比較結果によって移動アニメの再生を分岐処理して制御しています。
いわば、常に敵キャラの位置を監視し、それに基づいて、移動アニメの制御している設計です。
 
 このときの主な問題点としては、「同じ方向に移動していても、その都度、移動アニメへの分岐処理によって再生命令が実行されている」部分です。
それはつまり、Update メソッドを利用している現在の設計自体に問題がある、とも言えます。ここを改善できないか、改善するにはどうすればいいかを考えてみます。

 移動のアニメは移動している方向が同じである場合には、アニメを変更する必要はありません。右方向に移動している最中に、何回も右方向のアニメを再生する必要はないためです。
これを元に、では、どんな時にアニメを変更する必要が生じるのか、を考えていくことが大切です。

 それは敵キャラの移動する方向が変更になったときに、アニメの変更をする必要が可能性として生まれます。
A 地点から B 地点へ移動したときに、同じ方向であれば、改めて同じ方向の移動アニメを再生し、それ以外の方向であった場合には
その方向に応じた移動アニメへ切り替える必要があります。

 つまり、敵キャラの移動している間を監視するよりは、敵キャラが1つ目の目的地に着いたときに、次の目的地の方向が決まったタイミングで
移動のアニメの変更も行えれば、タイミング的に適切な処理になるということです。

 この処理の方法のよい部分は、Update メソッドによる毎フレームの監視処理ではなく、目的地についたら、というタイミングが明確になったことで
そのタイミングに合わせて、ChangeAnimeDirection メソッドを実行することが出来れば今までと同じように移動アニメの変更が可能になります。



 もう1つは、分岐処理の多さ、です。
現在は、敵キャラと目的地とを比較し、その差分値に合わせて移動アニメを4種類に分岐処理しています。
この処理をどのようにすれば簡潔に記述することが出来るようになるか、と検討してみます。

 分岐の数を減らす方法で考えて、最終的には分岐自体をなくして1つの処理として記述することが可能かどうか、までを突き詰めて考えていきます。

 このように設計とプログラムのロジックは密接な関連性があります。よいロジックを考えて処理を記述できないかを念頭に置いて作業をしましょう。


<設計変更目標>
 1.Update メソッドを利用しない設計を考える

 2.分岐を少なくする、あるいはなくして処理を簡潔にする

 そのため今回は、これらの問題点を2回に分けて、スクリプトのリファクタリングを行います。

 どのようにすればいいのかを、まずは自分で考えてみて、実際にスクリプトを修正してみましょう。


2.EnemyController スクリプトを修正する


 まずは、Update メソッド自体を利用しない、という観点から、Update メソッド全体をコメントアウトしてから作業を開始します。
どうすれば、ChangeAnimeDirection メソッドを適切なタイミングで実行できるのかを考えて処理を記述します。

 敵キャラの移動には DOTween の DOPath メソッドを実行して制御しています。
この DOPath メソッドには専用で拡張用の OnWaypointChange メソッドが用意されています。

 OnWaypointChange メソッドの機能は、DOPath メソッドに続けて記述することにより、第1引数にしている移動地点に到達するたびに、
OnWaypointChange メソッド内に登録しておいた処理を1回だけ実行してくれる、という便利なメソッドです。
このように、指定されたタイミングで自動的に実行されるようになっているメソッドをコールバック、またはコールバック・メソッドといいます。
すでに利用しているものとしては、OnTriggerEnter2D メソッドなども同じコールバックメソッドの1つです。
 


 今回実装しようとしている「移動地点が変わって移動方法が変わるたび」というタイミングとぴったりなコールバック・メソッドですので、
Update メソッドではなく、OnWaypointChange メソッド内で ChangeAnimeDirection メソッドを実行するように処理を変更します。

 この OnWaypointChange メソッドは、目標地点に到達するたびに自動的に1回だけ呼び出されます
このとき、引数として DOPath メソッドの第1引数に指定している Vector3 型の配列の現在の要素番号を int 型で取得しています。
つまり、この配列の番号まで移動が終了している、ということを教えてくれるようにもなっていますので、この情報も活用します。



 移動アニメの分岐処理には currentPos 変数を利用していましたが、これは Update メソッドで常に動いている敵キャラの位置を監視するための変数です。
この情報は、Update メソッドを利用しないため、今回の変更では利用できなくなっている情報です。

 分岐処理にはこの値と現在の敵キャラの位置とで比較して移動している方向を把握してから、移動アニメの分岐処理を行っていましたが
この部分を「次に移動する地点の情報」に変更します。次に移動する地点とは、paths 配列変数の何番目という情報になります。

 最初のスタート地点であれば paths[0] の要素(中身の値)が、そこからみて次の地点とは paths[1] の要素となります。

 先ほどもお伝えしたように、OnWaypointChange メソッドでは、この番号を int 型で教えてくれるようになっていますので、
paths 配列の要素番号に OnWaypointChange メソッドの引数の情報を利用することで、自動的に次の地点を確認することが出来る仕組みです。

 これらの複合的な処理を組み合わせて、1つのロジックを考えて、処理を記述します。


EnemyController.cs


 スクリプトを修正したらセーブをします。


3.<DOTweenの補間機能と実装例◆ OnWaypointChange メソッドー>


 新しく実装を行った DOTween の機能について、各メソッドを順番に説明します。

 // 各地点に向けて移動
  transform.DOPath(paths, 1000 / moveSpeed).SetEase(Ease.Linear).OnWaypointChange(ChangeAnimeDirection);


1.OnWaypointChange (int index)

 DOPath メソッドを実行している処理にのみ追加できるメソッドです。これ単体では動作しません。

 この処理を記述しておくことにより、DOPath メソッドの第1引数で指定している配列の座標に移動するたびに、1回だけ処理を実行します。
OnWaypointChange メソッドの実行にあたり、int 型の現在の配列の番号を取得してくれます。
そのため、OnWaypointChange メソッドの中にある処理を実行する際には、この番号を利用して処理を記述することが出来ます。
なお、引数が自動的に入りますが、よりわかりやすく記述する場合には以下のようにも記述できます。

  transform.DOPath(paths, 1000 / moveSpeed).SetEase(Ease.Linear).OnWaypointChange(x => ChangeAnimeDirection(x));

transform.DOPath(paths, 1000 / moveSpeed).SetEase(Ease.Linear).OnWaypointChange(ChangeAnimeDirection);

 どちらも同じ処理になります。自分のわかりやすい方の書式を利用してください。


4.ゲームを実行して動作を確認する


 それでは、ゲームを実行して動作を確認します。
漠然と動かすのではなく、どの部分が変更にあっているかを理解した上で、ゲームを実行していくようにしてください。
プログラムへの理解度が変わってきます。


<実装動画>
動画ファイルへのリンク


 目標地点に到達のタイミングで ChangeAnimeDirection メソッドが1回だけ呼び出されるようになったので、
Debug.Log メソッドの実行タイミングもそれに合わせて1回ずつになっており、処理回数が激減していることが分かります。

 これにより、ゲームの見た目上は同じですが、Update メソッドによる負荷のかかる監視型の処理から、必要なタイミングに応じて適切な処理を1回だけ行う、という
無駄を省いた処理に変更になりました。

 手順8でも学習しましたが、このように、ゲームの見た目や表面上の動きは変えず、内部的な修正のみを行い、
処理の効率化を図っていく手法をリファクタリングといいます。


<ケーススタディ ー移動アニメーションの向きが移動方向と反対になってしまう場合ー>


 BlendTree による設定や、EnemyController のプログラムを正しく書いているにもかかわらず、
移動アニメーションの向きが、移動方向は反対になってしまうことがあります。


<検証動画>
動画ファイルへのリンク



 これはプログラムの内容に関係しています。

 敵キャラの向きの計算方法ですが、敵キャラを Instantiate した位置をスタート地点とし、その位置から次の目標となる地点を計算して移動方向を算出する内容です。
ですが現在は、Instantiate ではなくて、デバッグ用にヒエラルキーに配置している状態から移動を開始しているため、座標の計算がずれてしまっています。

 現在地点 → 目標地点で動いているのですが、Instantiate した場合の現在地点は配列の 0 番目の座標で生成されて、配列の1番目が目標地点となります。

 最初からヒエラルキーにある場合、生成の手順がないので、配列の 0 番目が目標地点となります。

 このように、利用する情報が、Instantiate を使うか使わないかでずれてしまうため、このような現象が発生しています。

 この部分は手順13で敵キャラを自動生成する機能の処理が出てきまして、その機能を実装することで正常な移動の向きに戻ります。
そのため、いまはちょっと気になると思いますが、そのままで問題ありません。


5.EnemyController スクリプトを修正する


 最後に2つ目の問題点を修正します。
現在、移動アニメを制御するためには分岐が4つあり、そのいずれに分岐するかを敵キャラと次の目的地との距離によって判定しています。

 この部分を修正し、分岐のために固定値で利用している SetFloat メソッドの第2引数を変数化することによって処理を一元化します。

 敵キャラと次の目的地の位置は、Vector3 型同士の減算を行うことにより距離を計算できますが、この時、一緒に方向の情報も取得しています。
取得した値に対して正規化という処理を行うことにより、方向の情報はそのままに、距離を一定値に変換することが出来ます。

 BlendTree では2つの Palametr X と Y に -1 〜 1 の値を設定することによって、キャラの移動アニメが4種類に自動的に分岐します。
この正規化して算出された情報は、-1 〜 1 (0 もある)のいずれかの情報のになりますので、これをそのまま BlendTree 側に設定することで
4つに分岐して制御していた処理を1つの処理としてまとめることが出来ます。

 以下の状態を実装するイメージです。

<Blend Tree と正規化された敵キャラの方向情報との連動>
動画ファイルへのリンク


 それではこの処理を実装してみましょう。


EnemyController.cs


 スクリプトを修正したらセーブをします。

 なお、この場合でも移動の方向と移動アニメの向きが反対になる場合もあります。
その場合には、一旦、下記のように計算式を逆にしておくことで改善できます。

// 目標の位置と現在の位置との距離と方向を取得し、正規化処理を行い、単位ベクトルとする(方向の情報は持ちつつ、距離による速度差をなくして一定値にする)
Vector3 direction = (paths[index] - transform.position).normalized; // ← 計算式を逆にしている

 ただし、この方法を利用した場合、手順13にて敵キャラの自動生成の処理を追加したあとには、元の正しい計算式に戻す必要があります。


6.<Vector3.normalized 変数を利用した正規化処理>

 
 正規化処理です。magnitude(マグニチュード。長さ)を1としたベクトル(単位ベクトル)を返します。戻り値は Vector3 型になります。

// 目標の位置と現在の位置との距離と方向を取得し、正規化処理を行い、単位ベクトルとする(方向の情報は持ちつつ、距離による速度差をなくして一定値にする)
Vector3 direction = (transform.position - paths[index]).normalized;

 現在のベクトルの方向を維持したまま、magnitudeが1、あるいは0の単位ベクトルを作成することが出来ます。(ベクトルの値が小さいと0になります。)

 この正規化を行うことによって位置の遠近に関わらず、magnitude がすべて 1、あるいは 0 に統一された単位ベクトルの値となるため、
左と下の方向であれば -1右と上の方向であれば 1の値がベクトルとして作成されます。値が 0 に近い場合には 0 がベクトルとして作成されます。

 この値を BlendTree の各値として利用することにより、BlendTree の Palameter の設定値とこの正規化された値とがリンクして、移動アニメの切り替え処理が実装出来ています。

Unity公式スクリプト・リファレンス
https://docs.unity3d.com/ja/current/ScriptReferenc...
TechProjin様
UnityのVector3でよく使うものまとめ
https://tech.pjin.jp/blog/2016/02/16/unity_vector3...



 ポイントとしてですが、Vector3 の情報同士を計算しただけでは正規化は行われません

 仮に、こんな値を入れてみましょう。

Vector3 direction = (10, 5, 0) - (5, 3, 0);

 normalize がない場合、direction の値は単純に引き算された結果が入るため、

Vector3 direction = 5, 2, 0;

 この値が代入されることになります。値を見れば一目瞭然なのですが、正規化された値にはなっていません。

 この値に対して正規化の処理を行うと、算出結果の値を単位ベクトルに変換します。

Vector3 direction = 1, 1, 0;

 正規化されると、このような単位ベクトルの値が代入されることになります。

 単位ベクトルは、方向の情報はそのまま保持し、速度のみを 1 か 0 か -1 に作り直します。

 つまり、方向の情報だけは最初に計算した (5, 2, 0) の情報を持ちつつ、速度のみ (1, 1, 0) に作り直しています。
(このとき、値はすでに正規化されているので、Debug.Log メソッドを用いても元になっている方向の情報自体は確認できません。)



 なぜこの処理が必要になるか、ですが、これは Unity の教科書のイガグリを飛ばすゲームの中(373ページ)でも簡単にですが、解説されています。

 まず単純に Vector3 同士を計算しただけですと、方向と速度が同じ値として保持されます。
イメージしにくいのですが、Vector3 の (x, y, z) の値というのは座標の情報だけではなく、
それを元に「どっちを向いている」「速度がどの位である」という2つの情報を持っています。

 先ほどの例を元に説明すると、(5, 2, 0) と (10, 2, 0) というベクトルの値があった場合、
同じ斜め方向を向いていても、値の大きい (10, 2, 0) の方が速度が速くなります。

 そのため、2つの地点が遠く離れれば離れる程、速度が速くなってしまうため、単純に引き算した値を移動の値に直接使ってしまうと
同じ方向に対して、異なる速度の情報で処理が行われるようになってしまいます。
 
 その場合、同じ方向に対して移動する際に、より遠くに移動する速度の方が早くなってしまいますので、
今回の場合であれば、移動する際の速度が移動地点が離れていれば離れているほど早くなることになります。

 A → B に移動するとき、その差分値である direction が (5, 2, 0) と (10, 2, 0) であったら、
同じ方向に移動するのですが、 (10, 2, 0) の方が早く移動してしまう、という挙動になります。
イガグリの場合であれば、画面の端をクリックすればするほど、カメラの位置より遠くなるので、同様に発射速度が速くなります。

 こういった、方向と速度による挙動の不全を防ぐために、
「方向の情報はそのまま」で「速度を均一化」する、正規化の処理が必要になっている、ということになります。

 その結果、(5, 2, 0) と (10, 2, 0) は、そのまま速度で使ってしまう(単純に引き算しただけだ)と、移動の速度が変わってしまいますが、
normalize することで、地点の遠近があったとしても、どちらも (1,1,0) になるため、常に同じ速度で移動してくれる、という仕掛けです。

(5, 2, 0) を正規化 → 速度は (1, 1, 0) ただし、方向は(5,2,0) のまま
(10, 2, 0) を正規化 → 速度は (1, 1, 0)  ただし、方向は(10,2,0) のまま

 このように正規化の処理を利用することによって、想定している処理の挙動になります。


7.ゲームを実行して動作を確認する


 ゲームを実行前に、ヒエラルキーにある敵キャラのゲームオブジェクトを選択し、Animator ビューにしておきます。
Animator コンポーネントがアタッチされているゲームオブジェクトを選択している場合、ゲームを実行すると、そのアニメの状態に合わせて
リアルタイムにアニメの遷移処理を確認することが出来るためです。

 ゲームを実行して挙動を確認します。いままでと同じように移動アニメの制御が行われていれば成功です。


<実装動画>
動画ファイルへのリンク


 Update メソッドでの負荷のかかる監視処理もなくなり、適切なタイミングでのみ移動アニメの切り替えが行われるようになりました。
また、移動アニメの制御についても、長い分岐処理ではなく、1つの処理を変数によって BlendTree 側で自動的に制御を行えるようになりました。

 このように実装して完成、ではなくて、修正箇所がないかどうかを考えることで、コーディング技術や設計技術を養っていくことが出来ます。


8.Enemy ゲームオブジェクトと PathTranSet ゲームオブジェクトをプレファブにする


 Enemy ゲームオブジェクトと PathTranSet ゲームオブジェクトと両方のゲームオブジェクトをプレファブにしてください。
Enemy ゲームオブジェクトをプレファブにすると、PathData 変数のアサインが外れてしまいますので、
必ずプレファブにした PathTranSet ゲームオブジェクトをドラッグアンドドロップしてアサインし直してください。

 プレファブにしましたが、次の手順以降でまだこれらの情報を使います。
それが終了してから、ヒエラルキーにある Enemy ゲームオブジェクトと PathTranSet ゲームオブジェクトを削除するようにします。



 以上でこの手順は終了です。

 次は 手順11 −味方キャラの攻撃範囲の設定と敵キャラの破壊処理の実装− です。

コメントをかく


「http://」を含む投稿は禁止されています。

利用規約をご確認のうえご記入下さい

Menu



技術/知識(実装例)

2Dおはじきゲーム(発展編)

2D強制横スクロールアクション(発展編)

3Dダイビングアクション(発展編)

2Dタップシューティング(拡張編)

レースゲーム(抜粋)

2D放置ゲーム(発展編)

3Dレールガンシューティング(応用編)

3D脱出ゲーム(抜粋)

2Dリアルタイムストラテジー

2Dトップビューアドベンチャー(宴アセット使用)

3Dタップアクション(NavMeshAgent 使用)

2Dトップビューアクション(カエルの為に〜、ボコスカウォーズ風)

VideoPlayer イベント連動の実装例

VideoPlayer リスト内からムービー再生の実装例(発展)

AR 画像付きオブジェクト生成の実装例

AR リスト内から生成の実装例(発展)

private



このサイト内の作品はユニティちゃんライセンス条項の元に提供されています。

管理人/副管理人のみ編集できます