Arbor2を使ってみよう その４ 処理の流れ

前回の記事はこちら

code.hildsoft.com

検証バージョン

Unity 2017.1.1p1
Arbor 2.1.7

処理の流れ

処理実行順

Arbor2を使ってみよう その１ 概要 - hildsoftのコード置き場

で紹介した簡単なパターンから見ていきます。

Arbor2の処理は開始ステートから始まります。

Behaviourはステートごとに上から順に全て実行されます。

ステートは有効になった時に１度だけ実行されます。 そのステート中であれば常に実行されるというわけではないので注意してください。

(Tween系は更新処理があるので、UpdateやFixedUpdate内での時間経過処理が実行されますが、開始処理は有効になった時のみです)

ただし、Transition系(ステートを変更するもの)は、Updateメソッドを持っているため毎フレーム実行されています。

これはUnityのUpdateと同じ仕様で実行順は不確定ですので、並び順の通りに処理されることを期待してはいけません。

BehaviourのUpdateが実行された時に有効であれば移動先は上書きされてしまいます。 (Behaviourの条件が満たされている中で、最後に呼ばれたものに移動します)

なので、左右両方のキーを押した状態だと、どちらが有効になるかは保証されていません。

ステート更新のタイミング

ステートの変更はUnityのLateUpdateメソッド呼び出し時に更新されます。

ステートが変更されたときに実行されるBehaviourの処理もここで実行されます。

上記のFSMでは入力チェックと移動が分かれているため、キーを押しっぱなしにしても1フレームおきに移動します。

その結果、カクカクとした動きになってしまいます。

Unityのイベント呼び出しの順番はこちらを参照してください。
Unity - Manual: Execution Order of Event Functions

Immediate Transition

Transition系には、追加の設定があり、名前(初期値:Next State)の変更、矢印の色変更ができます。

また、処理に関わる重要な設定に、Immediate Transitionがあります。

このチェックがオンの状態だとLateUpdateを待たず、すぐにステートが切り替わって次のステートの処理も引き続き実行します。

常駐ステート

常駐ステートは、常に有効になっているステートになります。

ここでも注意しないといけないのが、ステートは１度だけ実行されることです。

Updateを持たないBehaviourは起動時に一度だけ実行されて、毎フレーム呼ばれるわけではありません。

処理の順番

画面の左側のTransitionはImmediate Transitionをオンに、右側をオフにしています。

現在のステートと、常駐ステートにKey Transitionで同じキーを監視しているBehaviourがあります。

右キーを押したとき、Updateが早く呼ばれた方のBehaviourのステートへ変更されます。

現在のステートにあるKey Transitionが先にUpdateを呼び出されたとします。

このとき、Immediate Transitionの設定のため、Updateでステートが更新されます。

通常はLateUpdateで実行されるステートの変更呼び出しもUpdate内で呼ばれることになります。

また、Go To Transitionでステート変更が予約されています。

全てのオブジェクトのUpdateが呼び出され、最後にLateUpdateが呼び出されます。

Go To Transitionで予約されていたステートに更新されるため、先ほどのステートまで戻ります。

Key TransitionはUpdateで処理を待つだけなので、実質なにも処理は行われません。

そして次のフレームのUpdateで再びキー入力を待ち受けます。

2017/09/19 21:18
仕様を誤解していましたので、大幅に書きなおしました。申し訳ありません。

code.hildsoft.com

Arbor2を使ってみよう その３ 基本操作

前回の記事はこちら

code.hildsoft.com

検証バージョン

Unity 2017.1.0p4
Arbor 2.1.6

ArborFSM Componentの追加

まずはArborFSM Componentを追加することから始まります。

操作はUnity標準のコンポーネントと同じです。

他にも方法はありますが、この２パターンが多いかと思います。

Hierarchyから追加したいオブジェクトを右クリックしてArbor>ArborFSM

追加したいオブジェクトをInspectorに表示させて、Add ComponentからArbor>ArborFSM

ArborFSM Componentを追加したあと、InspectorにあるOpenEditorでグラフを開きます。

Arbor Editor

ステートの追加

Arbor Editorを開いた何もない状態です。

まずはステートを追加します。

ステートには、ステート、常駐ステートの2種類があります。

ステートのうち一つは開始ステートのフラグが設定されます。

シーンが開始されると、開始ステートから処理が始まります。

ステートの操作はギアのアイコンをクリックして出るメニューで行います。

開始ステートに設定をクリックすると、メニューを出したステートが開始ステートに設定されます。
常駐ステートは開始ステートにすることはできません。

Behaviourの追加

ステートにはBehaviourを追加できます。

ギアをクリックしてメニューを出し、挙動追加をクリックします。

追加メニューが表示されますので、選択します。

今回はStateAとStateBにKeyDownTransitionを追加してみました。

Behaviourの接続

ステートを変更するBehaviourにはNext Stateボタンがあります。

このボタンをドラッグドロップで別のステートに接続することで、次の移動先が決まっていきます。

どのような条件で移動するかはBehaviourに依りますが、ここでの説明は割愛してもう少し先の回で説明していく予定です。

Calculatorの追加

Calculatorはステートと同様にグラフ上で単独に作成します。

右クリックメニューから演算ノード作成を選択します。

追加メニューが表示されますので、選択します。

今回はTransform.Getを追加してみました。

CalculatorもBehaviourと同じく沢山ありますが、ここでの説明は割愛します。

また接続方法も処理の流れを含めて次回解説します。 (注：先に解説するものがあったので、次々回になります)

code.hildsoft.com

Arbor2を使ってみよう その２ 主要な構成部品

前回の記事はこちら

code.hildsoft.com

検証バージョン

Unity 2017.1.0p4
Arbor 2.1.6

Arbor2を構成する主なパーツ

Arbor2は大きく分けて

• Component
• Behaviour
• Calculator

の3つで構成されています。

Component

ComponentはUnityでGameObjectに対して付加します。

ArborFSM：ステート管理するオブジェクトに対して1つ追加します。

ParameterContainer GlobalParameterContainer：今は変数を保存する物という程度の認識でokです。

AgentControllerは少し特殊な用途なので、ここでの説明は割愛します。

Behaviour

BehaviourはArborエディタでステートに対して付加します。

これは沢山ありますが、大きく2つに分類できます。

処理を行うだけの物と、ステートを変更するものです。

ステートを変更するものは、条件を満たしたときのみステートを変更します。

Behaviourは、よく行う処理をFSMの中で記述できるようにしたものです。

オブジェクトの大きさや位置を変更したり、音やアニメーションを制御したり、ステートが変わるタイミングで用いられる処理が用意されています。

もちろん、自分でBehaviourスクリプトを書いて追加することも可能です。

ここでは、ステートの変更を含め、定型処理をしてくれるものとだけ覚えてもらえばokです。

Calculator

CalculatorはArborエディタ上で単独で作成し、BehaviourやCalculatorと結び付けて使用します。

これは変換するためのメソッドと理解しておけば大丈夫です。

Behaviourで使用する値を作ったり、他から参照したりするために橋渡しをすることができます。

値を受け取ったり渡したりできるので、簡単な処理はこれを使い、複雑な処理はスクリプトを書くことになります。

BehaviourとCalculatorの使い方

どのようなBehaviourやCalculatorがあるか、作らなければいけないかを判断して使っていくことになります。

Behaviour、Calculator共に結構な数がありますが、いくつかに分類できますので、覚える量はそれほど多くありません。

こんなこと出来ないかな？と思った時に探してみて、それっぽいものが合ったらリファレンスで確認して使いながら覚えていくくらいで十分です。

code.hildsoft.com

Arbor2を使ってみよう その１ 概要

Arbor2って何？

アセットストアで販売されている、有償のエディタ拡張アセットです。

これを使用することで、FSM(finite automaton machine)をグラフで操作しながらプログラムの見通しをよくすることができます。

Playmakerでも同様のことはできるようですが、Arbor2のメリットは

• 開発者が日本人なので、日本語で質問でき、日本語ドキュメントも用意されている
• ソースコードが開示されているので、開発終了しても独自拡張で使っていける
• Playmakerより安い

です。

デメリットとしては

• まだまだ使用例が少ない
• C#を読み書きできることを前提とした設計

です。

全てFSMだけで処理を書くことは無理で、ある程度はコードを書かなければいけません。

しかし、上記のメリットにもありますが、ソースはあるので魔改造して全てFSMで片づけるシステムを社内開発することも可能だと思います。

過度にリフレクションを多用すると処理速度の面で問題があるので、Arbor2に分岐処理を殆ど任せるような書き方をしたり、処理の重いシステムだとそのままリリースは出来ないかもしれませんが、少なくともモックを高速に作り上げることができるのは大きなメリットになります。

試用版もありますので、まずは購入前に試すことをお勧めします。

また、公式サイトで説明がありますので、一度目を通すと良いかと思います。

arbor.caitsithware.com

試用版でもUnityエディタ上では制限が無く、複雑な処理を書くこともできるので、十分試した上で購入しても良いでしょう。

ちなみに、unity1weekというゲームジャムでArbor2を使い一つゲームを作ってみたので、こちらも参考になれば幸いです。

backyard.hildsoft.com

Arbor2を使ったら何が便利になるの？

まだ完全には使いこなせていないので、ごく一部の例としてご覧ください。

よく、アクションゲームでキャラクターをこのように操作しようとするとき、

public float _Speed = 10f; // 移動速度

void Update () {
  // 右移動
  if (Input.GetKey(KeyCode.RightArrow))
  {
    transform.Translate(_Speed * Time.deltaTime, 0f, 0f);
  }
  // 左移動
  else if (Input.GetKey(KeyCode.LeftArrow))
  {
    transform.Translate(-_Speed * Time.deltaTime, 0f, 0f);
  }
}

と、if文での分岐を書くことがあると思います。

これをArbor2で書くと、この2つのメソッドに切り分け

// 右移動
public void MoveRight()
{
  transform.Translate(_Speed * Time.deltaTime, 0f, 0f);
}
// 左移動
public void MoveLeft()
{
  transform.Translate(-_Speed * Time.deltaTime, 0f, 0f);
}

このようなFSMを書くだけでokです。

ここまでは単純なので、特に問題は無いでしょう。

むしろこの程度の処理であれば、最初に提示したソースコードの方がシンプルで可読性も高いです。

しかし、アクションゲームですから、いろいろなことができなければいけません。

では仕様を追加することを考えてみましょう。

コーディングだけで仕様追加に耐えられるか

• ジャンプキーでジャンプができる
• ジャンプができるのは地上にいるときだけ(2段ジャンプ禁止)
• 空中では姿勢制御ができない(ジャンプしたときの横方向の速度を維持)
• 敵からの攻撃を受けると、反対方向にn秒だけノックバック
• ノックバック中の操作は受け付けない
• 壁にぶつかるとそれ以上進まない

とまぁ、このくらいはどんなアクションゲームでもありがちな設定で、

• 三角跳び
• 減速滑空
• 空中ダッシュ
• ハイジャンプ
• 移動床
• ロープアクション
• イベント中の操作無効or強制移動

などなど、仕様を増やせば増やすほど複雑になっていきます。

これを一つのUpdateメソッド内でif文やswitch文で処理するとバグの温床になりかねません。

勿論プログラムに慣れている人であればバグ無しで書き上げることも可能ですし、コード上でFSMを書き上げるでしょう。

ですが、書いて暫く経ったコードであれば忘れている可能性もありますし、解読に時間もかかると思います。

まして、他人が書いたコードをレビューしたり機能追加やバグ修正ともなるとスパゲティな状態だと自分の読み間違いでバグを生み出さないかと精神的な苦痛を伴います。(ユニットテストでもあれば良いのですが、ゲームだと使えない部分も多々ありますから……)

グラフで示すことで、これらの可能性をゼロとは言わないまでも、減らすことが可能になります。

何より視覚的に状態を切り分けすることで、考える部分を限定することができてスッキリします。

今後の予定

Arbor2の普及運動も兼ねて、基礎的な使い方をまず最初に発信していこうと思います。

そのあとにまだまだ書ききれていない便利な使い方や、FSMとスクリプトのどちらに書くかの判断基準などを紹介していけたらと考えています。

code.hildsoft.com

Unityで対象となるオブジェクトを向くように回転させたい(Quaternion.LookRotation)

Quaternionはさっぱりわからないという人は一度こちらを見てください。

code.hildsoft.com

Unityで使うQuaternionのサンプルコード(LookRotation)

対象となるオブジェクトを向くには、LookRotationを使ってどのくらい回転させればいいのかを求めて、 得られたクォータニオンを使用して回転させると楽です。

このように黒いキューブの方を向くなど、カメラの向き変更などでよく使います。

Quaternion LookRotation(Vector3 forward)

+Z軸を、指定の方向に向けたい時に必要な回転操作が欲しい時に使用します。

+Z方向はVector3.forwardでも定義されていて、カメラの撮影方向もZ軸プラスの方向になります。

今回は黒のキューブに向けてみましょう。

public GameObject targetBlack;

を定義してインスペクタから黒いキューブを設定します。

var aim = this.targetBlack.transform.position - this.transform.position;
var look = Quaternion.LookRotation(aim);
this.transform.localRotation = look;

向きたい方向を指定する必要があるので、ターゲットの座標から自身の座標を引き、相対ベクトルを計算します。

よくあるミスとして、引数に対象の座標を指定することがあるので注意してください。

Quaternion LookRotation(Vector3 forward, Vector3 upwards = Vector3.up)

LookRotationメソッドは第二引数を取るものもあります。

これは、指定方向を向いたあとに上方向をどこに指定してするか、対象を向きながら回転して決定します。

大抵の場合は、Vector3.upかtransform.upを指定することになると思います。

var aim = this.targetBlack.transform.position - this.transform.position;
var look = Quaternion.LookRotation(aim, Vector3.up);
this.transform.localRotation = look;

Vector3.upを指定した場合は、引数が一つのメソッドと同じ動きをします。

キューブのY軸(緑の棒)を見ると分かると思いますが、上を向いている状態です。

初期の状態でY軸がどこを向いていても、Y軸が上を向く(正確に言うとX軸が水平になる)ように回転します。

この場合は設定を省略できるので、引数が一つのメソッドを使う方が良いでしょう。

var aim = this.targetBlack.transform.position - this.transform.position;
var look = Quaternion.LookRotation(aim, this.transform.up);
this.transform.localRotation = look;

こちらのコードは、transform.upを指定した場合です。

単純に黒いキューブを向くだけで、そのあとの自身の回転を行いません。

補足

カメラで使用する場合は、前者は重力を考慮した動き、後者は無重力状態や飛行機などの重力をあまり考慮しない動きをする際に用いられることが多いと思います。

ただ単に方向を変えたいだけなら、Quaternionを使わずに

this.transform.LookAt(this.targetBlack.transform);
this.transform.LookAt(this.targetBlack.transform, this.transform.up);
this.transform.LookAt(this.targetBlack.transform.position);
this.transform.LookAt(this.targetBlack.transform.position, this.transform.up);

でも可能です。

Quaternionを使わないならこちらの方がシンプルになります。

関連リンク

Unity - スクリプトリファレンス: Quaternion

Unity - スクリプトリファレンス: Quaternion.LookRotation

Unityで使うQuaternionのサンプルコード(事前準備)

Unityで使うQuaternion

クォータニオン(Quaternion)の理解はそこそこでも良いからとりあえずサンプルコードが欲しい、 サンプルコードを動かしながら理解したい人向けの準備記事です。

もう少し詳しく知りたい方はこちら。

www.hildsoft.com

www.hildsoft.com

根本的な数学のレベルから理解したい方はこちら。

qiita.com

最低限押さえてほしいこと

流石に全く知らないと説明も難しいので、最低限この３つだけは押さえてください。

1.クォータニオンの持つ意味

クォータニオンは、ある状態から別の状態へ回転させる操作、または回転後の状態です。

Unityでは基本状態では、Rotationの値が、X:0,Y:0,Z:0で作成されます。

これを基本状態(無回転状態)と考えてください。

この状態をクォータニオンではQuaternion.identityとしています。

Quaternion.identityの状態にするには、下記のコードで可能です。

this.transform.localRotation = Quaternion.identity; // 親の座標系
//this.transform.rotation = Quaternion.identity; // グローバル座標系

2.transform.rotationとtransform.localRotationの違い

ヒエラルキー上で親子関係があるオブジェクトです。

分かりやすいように、キューブにx,y,z軸を表す棒を付けています。

ここで子オブジェクトを基本状態に回転させます。

this.transform.rotation = Quaternion.identity; // グローバル座標系

transform.rotationはグローバル座標系が基準です。

this.transform.localRotation = Quaternion.identity; // 親の座標系

transform.localRotationは親の座標系が基準です。

オブジェクトがルートの直下にあるときは、親がグローバルになるため、

transform.localRotationもtransform.rotationも同じ結果になります。

3.クォータニオンの計算

クォータニオンは回転操作なので、計算によりオブジェクトを回転させることができます。

その計算方法ですが、回転させたいものに対して、左側からかけることで可能です。

通常の実数での掛け算は積の交換法則が成り立つので、実数a,bに対してa * b = b * aが成り立ちます。

しかし、クォータニオンの計算では行列の計算と同じく、一般的に積の交換法則は成り立ちません。

X=(今の状態)
A=(回転操作)
B=(結果の状態)

とすると、

B(結果の状態) = A(回転操作) * X(今の状態)

で計算することができますが、

B(結果の状態) = X(今の状態) * A(回転操作)

では意図しない結果になる場合があります。

サンプルコード

記事を書き次第追加していきます。

code.hildsoft.com

Unityでクリックした位置にprefabを作成する(Perspective編)

Unityでクリックした位置にprefabを作成する(Perspective編)

検証環境

Unity:5.6.1f1

カメラの設定

Unityのカメラ設定でProjectionという項目があります。

どのように空間を映すかという設定なのですが、

• Orthographic
• Perspective

の２パターンがあります。

この記事ではPerspectiveの場合について説明します。

Orthographicはこちら code.hildsoft.com

Perspective

設定はカメラのProjectionで変更可能です。

OrthographicもPerspectiveも３次元を２次元に投影する方法ですが、
PerspectiveではPerspectiveとは違いカメラに対して前後の概念も奥行きも影響してきます。

遠くにあるものは小さく、近くにるものは大きく表現されます。

Z正方向を見たカメラに２つのキューブを置きました。

シーンビューで斜め上からPerspectiveで見た図がこちらです。

赤いキューブのZ座標は-5で、緑のキューブのZ座標は0です。

緑から青色の長方形で構成される四角錘台に含まれるものがカメラに映されます。

実際にカメラに映し出されるのがこの図になります。

同じ大きさのキューブですが、赤は遠くにあるため小さく、緑は近くにあるため大きく見えます。これがPerspectiveの特徴です。

通常のカメラでの撮影や人の目の見え方はこの方式になります。

クリックした座標のとり方

画面のクリック位置を取る方法はこちらの記事を参照してください。

code.hildsoft.com

prefabを作成

public GameObject prefab; // prefabはインスペクタから与えてください。

private Camera cam;

void Start ()
{
    this.cam = FindObjectOfType<Camera>();
}
    
void Update () {
    if (Input.GetMouseButtonUp(0))
    {
        var mousePosition = Input.mousePosition;

        mousePosition.z += 18f;  // カメラのZ座標に+18
        //mousePosition.z -= this.cam.transform.position.z; // XY平面上に
        var worldPoint = this.cam.ScreenToWorldPoint(mousePosition);

        GameObject.Instantiate(this.prefab, worldPoint, Quaternion.identity);
    }
}

Input.mousePositionのZは常に0です。

Camera.ScreenToWorldPoint(Vector3 v)

で変換すると、カメラが見ている範囲のx,y座標に変換してくれますが、Zはカメラの座標からの相対値が返されます。

Orthographicとは違い、カメラからの距離によって大きさが変わるため、Zの値によってx,y座標も変わってきます。

Zの値を変更しないとカメラと同じ位置にインスタンスを作成されて見えないので、少し前に移動させます。

Orthographicでもそうですが、ScreenToWorldPointを使用しても座標が変わらない、オブジェクトが見えないなどはこの辺が原因であることが多いです。

この例ではカメラのZ=-20に対して+18に設定し、赤と緑のキューブの間に生成されるようにしました。

実行して適当にクリックしてみたのがこの図です。

赤と緑のキューブの間にprefabで指定したキューブが作成されています。

奥行きについて

画面上は同じ座標になっても、奥に行くほどX,Y座標は変わっていきます。

同じ大きさの比較できる物体があれば前後感は分かるようになります。

しかし、遠くに大きな物、近くに小さなものを配置すると画面上の大きさは同じようになります。 Orthographicと同様プログラム内で位置を知りたい場合はraycastなどで調べることになります。

補足

Perspectiveを使う時に大事なパラメータにField of Viewという項目があります。

これは視野を調整するもので、カメラを動かしたときに人間の目との違和感を感じやすい部分になるので3D酔いの原因になります。

人により差があるため、できればユーザーが設定できるようにプログラムを作成した方が良いでしょう。

その際にクリック位置などの補正が必要になることもあるので注意してください。

参考サイト

tsubakit1.hateblo.jp

関連リンク

Unity - スクリプトリファレンス: Camera

Unity - スクリプトリファレンス: Camera.orthographic