但終於算是有一個結論了
接下來應該就是靠著實戰次數驗證看看想法對不對

還有一點不敢確定這個做法跟脈絡是否 scalable

可是我不想重複造輪子

a710594: 實作方式跟要不要重造輪子是兩回事

還是會有辦法在使用遊戲引擎的情況下調整成更接近一般軟工的寫作方式，但要特別努力去思考要怎麼做才好
我純粹只是討厭明明是寫軟體，但依賴關係卻很大程度會需要靠遊戲引擎來resolve 的這個現實──但我不否認這對一般大家使用上是比較方便

老實說如果沒特別被軟工的思考方式荼毒(就是當你開始思考依賴、測試、軟體的唯一狀態怎麼產生，物件要怎麼建模和溝通，軟體架構要怎麼設計的時候)
現行的遊戲引擎很容易讓你在軟體工程世界學了一堆然後發現自己的知識要用只能跟引擎對著幹

平心而論，我覺得能做出遊戲就好事也沒啥差別，實際上甚至只是想要做遊戲的前提下，這些軟工思維可能也沒有太大的價值(看過很多 code 很不怎樣但是還是賣很好的遊戲 lol，只是維護起來會比較痛苦)

所以我只敢說我找到我自己想要寫作的方式，而不會覺得說這個方式肯定是最好的XD

突然想到可能沒講清楚所以做個補充：噗首在討論的事情是指寫作上你的設計的各種行為一定需要變成以 monobehaviour(unity) 或 node(Godot)為中心，然後物件的依賴關係變成需要靠著遊戲引擎來設定這件事情
這個寫作模式我個人來說不是很喜歡（而且也會導致很多本來在軟工世界可以用的解決方案變得不可行、或是變得難以進行好的設計假設

是不是類似我放棄使用 unity 原生的animator，自己寫狀態機的那種感覺？

a710594: 有點類似? (但不確定你具體做了什麼所以不確定)
不過我想討論的主要是比方說你想要做一個遊戲的行為(比方角色可以攻擊敵人)，在遊戲引擎的世界中，你很容易被引導到就是去繼承 monobehaviour 或是 node，然後在這個框架下做事情
本來的話框架確實是想要做到這樣的引導沒錯，但這樣的話你的程式寫作的寫法就會變成被這些引擎預設的寫法限制住了
作為引擎的角度來說，這種風格的寫作方式確實可以讓你的遊戲變得更好在使用引擎的時候改變他的行為(因為你就透過增加會減少 script 就可以了)
但作為軟體工程的角度我自己是覺得就不是很漂亮，你會開始遇到有些功能明明是純粹的軟體概念你也必須把它變成 gameobject 才能符合遊戲引擎的狀況

本質上來說，我認為實際的問題比較像是，如果你現在可以自己寫遊戲的執行架構，你會想要怎麼寫的問題
或者也可以這樣看待這個問題：要怎樣才能夠讓自己的軟體一定程度的脫離引擎強加的假設

總覺得這個問題我講得不太好QQ 有點亂亂的
我再試一下能不能整理一下完整的脈絡好了QQ

我的寫法是角色行為的部分從mono分離出去,mono只是個控制器

HackMD - Collaborative Markdown Knowledge Base整理好啦~!

用 chatgpt 整理了一下我的想法，我自己有再精修過，應該比較能讀到我準確想表達的意思了~

a710594: 大致上來說方向是這樣的概念沒錯~(不過會需要看你把這件事推到多極致的感覺)