きっかけ
ある日ふと、「ゲーム作りたいな」と思ったのが始まりでした。
当時いろいろ調べてみると、ちょうどUnityが流行り始めていた時期。
触ってみたものの、GameObjectとMonoBehaviourという仕組みが
どうも自分の頭にはしっくり来なかったんです。
実際さわってみて、制御権が常に「Unityエンジン側」にあるという構造─
今だからこそ少し認識できるようになったのですが、つまりMonoBehaviourが
「ライフサイクルを自動管理するコールバックの集合体」のように感じられて、
自分がコードの主導権を持てない感覚にかなり混乱していたんだと思います。
当時は趣味でFlashDevelopとActionScript 3くらいしか触ったことがなく、
Unityの「ツールとしての抽象化された世界観」にも拒否反応が出てしまいました。
要は、Unityは最初からできることが多すぎる。
ルールや仕様は存在するけれど、
「どこから手をつけていいのかわからない」。
サンプルどおりにやっても頭に入らない。
あれもこれも、覚えないと置いて行かれる感覚。
そんな“情報の多さによる迷子状態”でした（個人差！）。
Playmakerとの出会い
そんなあるとき、ふと見かけたのが
=> David Wehle さんの動画
この動画が、自分の転機になりました。
紹介されていたのが「Playmaker」のアセット。
最初は「またツール群か…面倒そう」と思いつつ触ってみたら、
“状態遷移ごとにコードを実行する” という発想が
すんなり頭に入ってきたんです。
PlaymakerでMonoBehaviourを“直接書かない”開発
そこからはもう、どハマりでした。
Playmakerを使うことで、MonoBehaviourのライフサイクルを自分でコードに書かず、
代わりに状態遷移（FSM）として制御レイヤー化できるようになりました。
いつしか複雑な処理は Pure C# や C++でDLL に分離し、Playmakerから呼び出す構成に。
こうして、ゲーム全体の流れを視覚的に制御しつつ、
下層ロジックはコードで最適化するハイブリッドな開発スタイルに落ち着きました。
この頃から、ポインタ、ポリモーフィズム、インターフェース、
コーディングルールなどの基礎を少しずつ吸収していくようになりました。
ステートマシンの最適化と整理術
最初の頃は「RPGのスキルツリーみたいに無限に広がる」
ステートグラフを組んでいました。
でも、理解が広がりできることも増えるにつれて
自然と最適化されていきました。
「処理を外だしするなら制御系全部書けばいいじゃん」
と同僚に言われたことがあります。
でも実際のところ、毎回コードを追うより、
Playmakerの遷移を追った方が数倍速かったんです（作っている物による）。
柔軟な仕様変更にも強かったです。
レガシーコードとFSMのありがたみ
レガシー案件で「ゲームコントローラー」プレハブに
MonoBehaviourが無限に貼り付いたコードを見ることがあります。あるよね？
マジックナンバーだらけ、イベントで飛ばしまくり、
Time.deltaTimeを考慮していないフレーム依存処理─ まさに地獄。
そんな時、心の中でいつも思います。
「この処理…状態遷移でよくない？
Playmakerで組んでくれたら100倍わかりやすいのに…」
Playmakerで“手を動かして理解する”
Playmakerはまず、簡単に
- 表示させる
- 動かす
といったことを数クリックで始められます。
そこから「テキスト表示」「シーンロード」「セーブ・ロード」など
やりたいことが増えていくうちに、
FSM同士の連携やデータの受け渡し、
アクションを自作する流れ、拡張アセット導入へ自然と発展します。
「Playmakerだけで何でも作れるの？」への答え
よく聞かれるのがこれ：
「Playmakerと標準アクションだけで、なんでも作れるの？」
作りたいものにもよる
| 質問 | 答え |
|---|---|
| 実用に耐えるもの作れますか？ | Yes。実際、Playmakerはヒット級の商用ゲームでも一部フローで採用されています。（Hollow Knight,INSIDE,Hearthstone,TheFirstTreeなど） |
| Addressableやリソース開放系は？ | カスタムアクションで実装可能。LoadAssetAsync呼び出しもOK。 |
| 課金や広告は？ | C#ラッパー経由で実装可能。 |
| DOTS使える？ | 制御層としてPlaymakerを使い、C#ブリッジでDOTS呼び出しは可能（直接は不可）。 |
| VisualScriptingとは？ | 構造が異なる。Playmakerはイベントドリブン型、VisualScriptingはフローチャート型。用途で使い分け可能。 |
要は「何をPlaymakerに任せるか」のバランスの問題です。
Playmakerは状態遷移とイベントドリブンを可視化する箱。
万能スクリプトツールではなく、
ロジックを整理し、動作を見える化するツールとして使うのが正解。
上手に分担すれば、Playmakerは “軽くて速いUI付きFSM” です。
そしてUnityは怖くなくなった
気づけば、あれほど苦手だったUnityを
まったく臆することなく使えるようになっていました。
確かに、不便な部分はまだまだあります。
でも、Playmaker中心のこのスタイルなら
「Unityを自分の得意な形で使う」 ことができる。
それが、何よりも楽しいんです。
まとめ
Playmakerは“初心者の補助輪”ではなく、“思考を整理するための設計ツール”です。
書かないことで理解を深め、見えることで全体を掴む。
そのシンプルさが、Unityでの開発をもっと自由にしてくれます。
最後に
初投稿でしたが、書いているうちに思い出があふれてまとまりきらなかったです。
どうしても伝えたかったのはただひとつ。
Playmakerはいいぞ！
ここまで読んでくださって本当にありがとうございました！