きっかけ

ある日ふと、「ゲーム作りたいな」と思ったのが始まりでした。
当時いろいろ調べてみると、ちょうど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はいいぞ！

ここまで読んでくださって本当にありがとうございました！