Chapter 25無料公開

┣ 俺がよくやる実装方法

このチャプターの目次

俺はアホなので、超絶シンプルな形でしか実装できない。それが俺の実装スタイル！

数をこなすと自分のやりやすいスタイルに気づく。俺の場合は脳内メモリが少ないので、怠惰に流れる方向でやっている。

ほんとにこれだけ。なぜか？シンプルに俺がアホだからだ。あとコードを書く時間より、Youtubeを見る時間がほしいからだ。 簡単に作れたらそれでいいのだ！

小さい機能を作って、ObserverパターンでEventをDispatchして疎結合にしてやりとりをする。データ層はシングルトン状態でどこからでもゲットできるようにする。

シングルトンが悪だとかすべての参照が集まる神クラスがあるとか、そんなの関係ねえ！どうせ一人で作るのだから…。 (でもまあ、最低限のコード技術は必要だよ)

Unityで例えると、メインのシーンで機能の開発はしない。一つの機能を開発するためだけの小さいシーンを作り開発する。できあがったらメインのシーンに追加して結合していく。

いきなりメインのシーンで全部を作り出すと、バグったときにどこが悪いのかがわかりにくくなったりする。小さい機能の集合体として扱ったほうが、少ない頭のメモリでも対応しやすいだろう。

Node.jsでいうとEventEmitter。こいつをグローバル空間に置いて運用すると、どこの誰でもメッセージを送受信できる。

完全に疎結合になり、参照を気にせずに開発可能
- 気にするのは飛んでくるイベント名とパラメータのみ
どこからでも、何かしらのメソッドを叩けるようになる
- 例えばキャラクターの移動
  - キーボード等の物理デバイスで操作するのは当然として、ソケット経由で操作することもある
    - ソケットからDispathcer.dispatch("locomotion", {x: 1, y: 1}) などと送ることで、物理デバイスだけでないプログラマブルな操作ができるようになる

誰がどこからでもイベントを聞けるようにしておく
俺の場合、いつも Dというstatic classを使っている
- イベント送信側: D.Emit(HogeEvent.Hoge);,
- イベント受信側: D.On(HogeEvent.Hoge', handler);
タイトル画面に行くボタンが押された→ D.Emit(SceneEvent.Title) というように書く

このD クラスおかげで爆速で開発できる。誰がメッセージを送ったのかがわかりにくいかもしれないが、IDEのFind Usage 的な機能で HogeEvent.Hoge などのイベント名の参照を検索すれば、一瞬で見つけれる。

いまやFluxパターンは化石かもしれないが、データの扱いを固定できると、考えることが減る。

どこにどのデータがあるのかわからないオレオレな作り方になるよりかは、シングルStoreにしとけばシンプルになる。

ただし、Unityにはそれっぽい解決策があんまりない…。
- UniduxというFluxパターンの実装がある
- シングルStoreっぽい作り方とUniRxでなんとか乗り切るのもアリ。

とにかくシンプルで簡単に作れる状態にしておくのが吉。だいたい企画から何からすべてがカオスになるのだから、作り方くらいはシンプルにしておくといいだろう。

あと、省力化するためのビルド・デプロイを自動化するのも重要。余計な労力は削ろう。