hildsoftのコード置き場

プログラム関連で調べたことやコードの保管場所です

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

スポンサーリンク

Arbor2って何?

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

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

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

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

です。

デメリットとしては

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

です。

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

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

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


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

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

arbor.caitsithware.com

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


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

backyard.hildsoft.com


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

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

f:id:hildsoft:20170830035004j:plain

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

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です。

f:id:hildsoft:20170830043703j:plain

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

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

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

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


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

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

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

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

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

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

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

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

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


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

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


今後の予定

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

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

code.hildsoft.com