PlayMakerって便利なの?使ってみた感想

以前の記事で、UnityとPlayMakerのことをおススメしました

UnityとPlayMakerについての記事はこちら

では、実際にPlayMakerを使った開発における、メリットとデメリットのお話をしたいと思います。
有償アセットのため、気になっている人もいると思います。
ちなみに私の結論としては、可能な限り導入することをおススメしたい一品です。

メリット編

プレイメーカーを導入して、開発全体を通して自分が感じたメリットをいくつかお伝えしたいと思います。
いくつかありますが、大きく2点にしぼりました

バグ発生箇所特定が簡単

これにが最高に便利過ぎます。
たとえば、こちらの様な状態を持っているキャラクターを作ったとします。

サンプルキャラクターの状態

開発中、歩くけど、走る状態にならないというバグが発生したとき、「歩く」のアクション部分だけを確認するだけでよいのです。
これは、デバッグ時に修正箇所を特定する作業が最高に短縮されます。
実際のプログラムでも、遷移処理を集約して作成してチェックする場所は1箇所かもしれませんが、コーディングミスなどで、思わぬ不具合がまぎれることがたまにあります。
そういった不安要素がなくなるのは、緊迫したデバッグ中ではかなりの精神安定剤になります。

バグの内容にもよりますが、普通だと2,3時間はかかってしまうようなバグ調査が一瞬で終わります。

バグ発見が簡単!

ここで、金額面でどのくらいお徳かを計算してみましょう。
Unityエンジニアさんの時給を4000円と仮定します。1つのバグ発見に仮に3時間かかってしまった場合、その損失はおよそ12000円相当と言うことに鳴ります。
PlayMakerは65ドルなので、高く見積もって150円/ドルだとしても9750円あれば購入できます。
なんとたった1つのバグ発見だけで元が取れてしまいます(しかもお釣り付き)

ゲームに限らずプログラムは、作っている期間と同じぐらいデバッグしている期間があります。
そしてデバッグ中は、どれだけ分かりやすく開発できたかによって修正具合が大きく変わります。
コードオンリーで作った場合、パッチ修正を行ったつもりでもエンバグが発生する可能性が付いて回りますが、PlayMakerの場合、そのリスクをぐっと下げることが可能です。

実際、バグが見つからない最中というのは、お金で解決できるならいくらでも払いますぅ!というような精神状態に陥りがちです。
PlayMakerを導入してからは、本当にバグ発見がスムーズになり、とても快適です

状態遷移変更・デバッグがとても簡単

PlayMakerはビジュアルスクリプトです(今さら)
使ってみると実感できるんですが、とにかく変更や追加に強いです。
たとえば、先ほどのキャラクターの状態に対して、「歩く」から「走る」に移動した回数をチェックしたくなるとします。

もしプログラムで更新が必要な場合、「走る」状態の初期化処理の場所を見つけて、カウンターを追加しなければいけません。
しかし、その初期化処理は、必ず「歩く」からの遷移でしか行われないことをコード上で調査する必要があります。

その点PlayMakerで作成している場合、次のような修正を行うことで完結します

デバッグ用の状態を一つ追加

このようにデバッグチェッカーという状態を追加して、ここで欲しいカウンターの管理を行うことで安全に計測が出来ます。

また、ゲームの仕様変更で、「歩く」をなくして「待機モーション」からいきなり「走る」ようにしてください!みたいな仕様変更の依頼が来たとします。
この手の変更は、作りによっては青ざめる人、結構いるんじゃないでしょうか?
そんなときもPlayMakerで作っていると、こんな感じに直すだけで終わります。

歩かないバージョン

今まで「歩く」に繋がっていた矢印を「走る」につなげて、ちょっと疲れた場合も「待機モーション」に戻るように修正しました。
どうですか?なんだかとっても簡単に見えませんか?
この手の修正が本当にスムーズになります。
また、ゲームを作っていると、「やっぱり歩けるようにして!」と再度戻しの依頼が来ることもしばしばありますが、先ほどの状態を消さずに矢印を外しただけにしておけば、もう一度つなぎなおすだけで元に戻すことが出来ます。

よく仕様を決めてからプログラムをする、と言うのが一番工数が短く済むと言われますが、実際にそんなにすんなり作れることの方が少ないです。
現場は生ものなので、こういったツールを駆使することで、修正に時間を大幅に減らすことが出来ます。
修正が短く済むということは、それだけゲームを面白くするための時間を取れるということ!
僕たちはプログラムを書くのが目的ではなく、ゲームを作るのが目的です!
そのためにPlayMakerを導入することで、きっとゲームをより面白くすることが出来ること間違いなしです!

デメリット編

さて、ここまでは調子のいいことばっかりを挙げましたが、ここからはデメリットです。
自分は、PlayMakerが手になじむまで、なんだかんだで1年ぐらいはかかったと思います。
その感自分の感じたことを紹介しようと思います。

学習コストが大きい

とにもかくにもコレです。とにかく学習コストがとても高かったです。
基本的には直感的に出来ることが多いのですが、たまにかゆいところに手が届かなかったりして、その解決に多くの時間が必要だったりしました。

Web上でもいくつか情報やチュートリアルはあるのですが、なかなか欲しい情報が手に入らずに苦労しました。
問題のいくつかは手探りで解決したような気がしてます。
解決する際も、Unity自体の知識が必要だったり、初心者の方だとかなり骨の折れる作業になると思います。

書籍とか出てくれるともっと触りやすくなるんでしょうけど、需要と供給の問題なんですかね・・・

階層を持たせた構成が作れない

PlayMakerにはテンプレートという機能があります。
ざっくり説明すると、クラスのような塊がテンプレートです。

このテンプレート自体はとても便利な機能で、PlayMakerで作ったものを、別のインスタンスでも同じような処理を使うことが出来ます。

で、ここからが問題なんですが、PlayMakerではテンプレートの中から、別のテンプレートを呼び出すことが出来ます。
たとえば攻撃のアクションの中で、ダメージ計算を行うテンプレートを呼び出す、という感じのことが出来ます。

この機能を知ったとき、自分は直感で、関数の引数と戻り値のような使い方が出来るはずだ!と思いました。
下層のテンプレートで計算した変数を、呼び出し元に渡すことで、個別に処理を作れるなら、めちゃくちゃ便利だぞ!と胸躍りました。

が、実際には全然上手くいかず、何が問題なのか分かりませんでした。
いろいろやり方を模索している最中、丁度開発者の方にツイッターで質問を投げたところ、返答がいただけました

you can’t communicate as is between templates, but you can use the host fsm set of variables ( you can write from a template to the host if you know the of its variables), not ideal, but possible— Jean Fabre (@JeanAtPlayMaker) March 9, 2018

おーまいがー

ざっくり言うと、テンプレート間でのやり取りは考えてない。グローバル変数使ってね。という感じです。
これは使ってみると実感できるのですが、階層を持たせた構成が作れないと、出来ることがかなり限定されます。

オブジェクト指向的な作りをしたい場合、結構な足かせになります。

利用している会社が少ない

これは、あくまで自分の実感ですが、採用している会社が少ないように思えます。
いくつかの現場でUnityのお仕事をした際に、一度もPlayMakerを使っているところはありませんでした。

今お世話になっているところにいたっては、Unityのバージョンが古くて、最近のアップデートを行うまでPlayMakerを入れることが出来ませんでした。

現場で使われていると、熟成したノウハウなんかがありそうなものですが、なかなかそういった場面に遭遇しないですね。
なので、PlayMakerのみに依存するUnity使いになってしまうと、お仕事としては少し苦労してしまうかもしれません。

自分で使うだけであれば、特に気にすることは無いのですが、せっかくのPlayMaker術を披露する場所もなくて寂しいかもしれません。
ちなみに私の場合は、修正箇所からじわじわ侵食させてます。PlayMakerは便利ですからね。

まとめ

PlayMakerのメリット・デメリットのお話、いかがだったでしょうか?
最初にも申し上げましたが、自分としてはデメリットを差し引いても断然導入をおススメします!

デメリットの階層を持たせられないという問題も、実は別の方法で擬似的にクリアしています。
おそらくはPlayMaker側の推奨している方法とは違うのかもしれませんが、やりたいことは実現可能です。

次は、実際にPlayMakerを使ってどのように開発を進めるのかについてお伝えしようと思います。