Re: [心得] 容易被遺忘的遊戲設計模組(2)

[NDark (溺於黑暗)]

※ 引述《NDark (溺於黑暗)》之銘言：


十年前我寫了關於 Event 事件系統的文章．
十年過去其實我經歷過很多專案，發現了越來越多的反例（Anti-Pattern，
使用了事件系統專案的開發者卻無法駕馭，發現了問題無法除錯解決的情況）．

簡單來講，事件系統的目的是把混沌整理為有序．
但在某些情形下也有機會產生更多的陷阱．

專案使用了事件系統，
但沒有配套系統（或是團隊文化）的事件系統仍然會受到執行順序的困擾．
（這邊講的配套系統是負責顯示記錄的系統，
能夠即時或事後檢查遊戲過程中發生了甚麼事．
團隊文化指得是團隊中是否有遇到問題能夠細心檢查的成員及工作環境）

在系統及設計還未進入穩定態的（新案）
或是在舊案裝上新系統（尤其是演出，如跑馬燈，彈出介面）特別容易發生這個問題．

以Unity來說．這個問題就是因為各腳本執行是有順序的（即便沒有設定腳本的執行順序)
．Update() 都是一個一個腳本依序執行．

那麼同一個畫格送進事件系統也就有了順序．那麼陷阱就來自於
１．有時候我們希望A的執行順序要高於B．而有時候又希望B的順序高於A．
２．事件的結果發動有時候需要時間（尤其是動畫／Coroutine），事件發動下去又繼續
會有順序的問題．

舉例來說：

A腳本中總共寫了A1 A2兩個事件．
B腳本中總共寫了B1 B2兩個事件．

在某個運作中A1 B1會同一個畫格發動．
另一個運作中A2 B2會同一個畫格發動．（假設A的執行順序快過B）

規格剛開始實作時A1->B1 的順序是對的，
但過了一陣子實作另一個系統時卻又希望 B2 -> A2 這樣的順序．這時候就會出現衝突．

沒有一個配套系統很難發現問題在哪裡．
第二最簡單的修理方式就是把B調整為比A快．
這樣就會反過來讓A1->B1（或更多的類似流程）這條壞掉．
次簡單的方式就是讓A2去等B2．這可以臨時解決問題．
但是要祈禱未來不要再對這個規格做修改．

這個問題的複雜度會隨著
事件數（事件類別的種類及包含產生的結果）ｘ系統數
（通常是專案內被命名為Manager的類別）
而以乘法線性而更複雜．也就是越複雜的專案，這個連鎖效應就越大．

不會感覺到這個問題，最有可能的情形是：
專案已經穩定了，系統不變只是擴充遊戲內容的專案．（通常是續作）；
或是專案就不夠大或久到會有這個問題．

blog連結:
https://ndark.wordpress.com/2021/06/25/%e4%ba%8b%e4%bb%b6%e7%b3%bb%e7%b5%b1%e7%9a%84anti-pattern/


--
"May the Balance be with U"(願平衡與你同在)

遊戲設計教學，討論，分享。歡迎來信。

黑水溝歷史文庫 https://ndark.wordpress.com/

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.129.48.101 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/GameDesign/M.1624619586.A.119.html
推 wulouise: 一個腳本只有一個事件會有什麼問題嗎？
→ NDark: 不太懂樓上的問題. 意思是把所有事件都分腳本寫?
→ NDark: 全分開就屬於不管理的方式.
→ NDark: 不管理.就是是事件運作滿天飛. 一樣會有順序的問題.
→ NDark: A腳本等B腳本 B腳本等C腳本 然後C腳本發現又要等A腳本.
→ NDark: 就死結了.
→ NDark: 事件系統的初衷就是 至少有一個統一入口.
→ NDark: 然後後續怎麼運作.就要看事件管理系統怎麼設計.
→ NDark: 譬如說當甚麼介面顯示的時候,甚麼事件不要觸發,延遲觸發.
→ NDark: 因為是單一系統.所以才有辦法接報表(Log)系統.
→ NDark: 分腳本的方式Log系統會更難寫.
推 wulouise: 啊沒看清楚，我原本以為AB只有event, 其實是有包邏輯