# 成長的心態，成長的模組 ## 模組化的誕生 公司有數不清的老虎機遊戲，它們主遊戲玩法都差不多，只有小遊戲不一樣，主題不一樣，噴的特效不一樣，但其他真的看起來都一樣。有些玩家可能以為，我們做產品真簡單，就複製後換個皮貼上就完事了。 內行的就知道，這「複製貼上」一點都不簡單。 早期不少團隊在開發老虎機，真的是用複製一份程式碼，再客製成新遊戲的方式。優點是可以視為一款獨立的新遊戲，缺點是修正問題與新增同一個功能時，就需要回頭同步修改之前已上架的N款遊戲。老虎機開發時程通常較短，就會更加凸顯這個缺點造成的影響。 金猴爺與金虎爺專案可以快速移植老虎機，不單只是整個平台與遊戲架構類似，而是他們有定義出「**模組**」與「**平台**」之間的界線。當看見金猴爺的老虎機有出現「核心引擎」這個概念時，就讓我很確信這件事：模組最重要的目標，便是**減少重複性的功能開發**，**提高資源的複用性**，**制定出一套標準化的流程**，**將重要的開發心力和時間，花費在特殊玩法的刀口上**。 這個目標帶來的便是「LobbyAgent」，要用來解決平台與遊戲之間，界線不清楚而導致耦合的問題。 ## 大家都"懂"，但"共識"都不一樣 以往協助專案串接遊戲模組，總是直接支援處理遊戲平台網路接不上、美術不好換、UI不好接、平台怎麼接、規格怎麼調等等議題。遇到議題總想著只要讓模組可以辦到這些事便足以，於是不斷的更新模組，並告訴對方使用方式便認定問題解決了，但實際上卻忽略了，*對方可能根本不理解為什麼要這麼做*，甚至根本不明白這個模組到底能做什麼、不能做什麼，因此同樣的問題一直被攤出來，形成一個雞同鴨講的局面。 *「是什麼」到「為什麼」的認知差異，真的是有一段距離的*。例如很常被提到的LobbyAgent，即使我不厭其煩的一再說明，這個模組的目的是要讓用戶將遊戲模組的API，與平台的功能做串接，因此一個遊戲模組就會對應一個該遊戲的LobbyAgent。當下大家似懂非懂都點了頭。然而，每當落地到專案用戶必須建立遊戲專屬的那個LobbyAgent時，「這樣不就要維護好幾個LobbyAgent？！」的聲音就會蹦出來。 奇怪？！你們不是應該都懂的嗎？ 專案用戶看來也是這麼想的。後來我才知道，LobbyAgent這個詞就像「土豆」在兩岸的字面意思不同一樣。LobbyAgent被專案理解成：那些需要跟遊戲互動，而散落在四處的平台功能"代理者"。這其實跟我一開始定義的「串接遊戲模組API」是完全兩回事(經過多次的反省後，我覺得是這個名字取得不好，讓人誤會)，原來大家的「懂」到「共識」，有這麼大的差距。 ## 完整的模組，很難完整的導入 「**越龐大的東西，學習成本就越高**」，老虎機模組就是一個絕佳的例子，不僅制定了一套開發製程，也有著完整的遊戲流程，更具備了許多標準化的元件，並劃分了核心引擎、遊戲、平台等三道程式邊界。就遊戲模組而言，它的確很完整，但如果不了解它，使用上就會是一個負擔。 雖然我確實寫了整個老虎機模組的文件，然而在寫這些文件的時候，都有個盲點，就是我*假設*了所有用戶都了解「遊戲模組」與「平台」分別是什麼。所以若讀者對這兩個名詞的定義不清楚，或大家沒有共識，從文件中得到的理解就會有所不同。 另一個疏漏則是沒有整體架構的類別圖(這後面會補上)。這就是「是什麼」到「為什麼」的認知中缺乏的那一塊拼圖。缺了這塊，用戶就會有種「見樹不見林」的黑盒子的感覺。和iGaming的國棟在合作的時候，他可能是最瞭解的伙伴，或許可以從他這邊獲得更多建設性的觀點。 「文件」對開發者和用戶的而言，都是很大的一份考驗。 若用戶從模組化中獲得好處，為了更想駕馭這個模組，或是再尋求新的可能性，才會開始認真去閱讀文件。可對新手用戶而言，「文件」很容易給他們一個「要讀完它」的錯覺，因此會有很大的排斥感。有一個人可以手把手的協助on boarding的過程，才是他們真正需要的。 對開發者而言，最大的考驗就是「去寫它」以及「換位思考」。 就我自己看過的文件來說，很多文件都是以作者的世界觀構成的。閱讀時常常都會發現，若自己沒有前置知識，就會很容易卡關看不懂。這是開發者的肓點，但根本問題就是不容易做到換位思考。不過，比起看不懂文件，更大的問題通常是，開發者根本壓根就沒想要寫文件。 ## 以為是導入模組，但比較像是導入「現實」 專案在產品時程的壓力下，執行人員不見得有足夠的時間學習模組與相關知識，更不用說是準確評估模組是否適用。最終就變成需要什麼，就先改了再說(同事疑惑問：你人不是就在現場，怎麼還會這樣"先斬後奏"呢？實際上的狀況是：不是他們不奏，是之前已經砍了好幾個，忘了要奏什麼了…😅)。改得動的，無法確定是否改對地方而心理不踏實；改不動的，就認定模組不適用而產生排斥感。 我以為我是來導入模組，解決問題的，結果沒想到一進來就先看到*模組是第一個"被解決"的問題*。 「模組化」無疑是現今公司內最夯也最具爭議性的名詞，而其中最早視為遊戲模組化成果的老虎機模組更是眾矢之的。曾有一陣子，常常一邊忙著工作，一邊聽到別人對於模組的批評與抱怨，日積月累下來，不僅在心裡築起了一道牆，自己也漸漸地對工作迷失了方向。直到這次模組無法順利導入，我被賦予了救火任務，不只要協助導入，還要深度協助釐清導入不順的原因。原以為*兩周內*可以快速搞定，沒想到這一投入，就是**兩個月**。 原本我想的是，只要能用既有的方法，讓遊戲能在平台上運行就搞定了。然而在進駐專案，並開始了解狀況後才發現，*模組離產品化的距離，遠大於表面敘述的樣子*。在支援期間，除了解決技術難題外，也花了不少時間跟專案的執行人員交流。在這些過程中不免發現，執行人員有時候*不是認為"辦不到"，而是不知道該"怎麼辦"*；有時候並不是不想，而是根本沒空想。 之所以「模組化」會有這麼大的爭議，很大一部分的理由來自於對本質的誤解。這很像是當「人工智慧」"再度"變成熱搜字(Buzzword)後，大家就以為AI是解決所有疑難雜症的銀彈一樣。當大家以為模組化可讓自己的工作從一週變成一天，以為可以"無痛"把任何功能移過來翻過去，以為可以像捏臉一樣把想要的功能愛怎麼捏就怎麼捏…回到現實世界的破滅感，後勁就會難以承受。 模組本身是有自己一個框架的。當然每個團隊都有自己的開發習慣，模組支援的是將其包裝成團隊想要的介面來調用，而不是直接改造它。雖然有人會抱怨模組限制了開發方式，但其實這就是硬幣的兩面，不管是哪一面，都是同一個硬幣。=="框架"能加速元件或遊戲的移植，其原理就是"限制"==，所以自然會有滿足不了的需求，我們希望用戶做的是回報給開發團隊，一同討論看怎麼改會成長的更好。雖然公司並沒有規章要求，"一定"要模組化開發，但現今已是高度協作的時代，所謂的「Team Play」，重點並不是怎麼Play，而是怎麼搞清楚「Team」是怎麼Play的。 雖然有時會有些無奈，甚至會感到有些無助，但自己該做的，就是要讓專案感受到，自己跟他們是在同一個Team的。 ## 沒有完美的模組，只有持續成長的模組 我知道現在的老虎機模組不是什麼完美無缺的模組，但裡面真的有很多人寶貴的經驗累積。雖然我很希望大家能深入了解，然後在使用的過程一同討論及優化，但我也能理解"前線戰事"有多吃緊。有時遇到問題，專案人員想破框快速解決，雖能理解，但是我不能這麼做。除了繼續跟他們說明背後的設計思路，我也漸漸帶著開放心態，接受一個新的思維： ==沒有完美的設計，但設計可以逐漸優化== 我不再堅持著「*模組不該被改動*」的思維來導入專案，反而以是「**導入專案能為模組帶來什麼**」正面的成長心態來接納專案的意見，並試著抽離一些功能，讓專案能有更大的操作彈性。 用不同的角度看架構，將老虎機模組串接平台、UI等操作，視為不同的模組組合在一起，這也讓我意識到，*「老虎機模組」其實只是老虎機遊戲的其中一個部份而已，不能總是把模組不提供的功能，與客製化的內容皆視為平台*。重新定義LobbyAgent，使之更符合專案的想像，它就是一個定義平台串接的介面，不會因為面向不同的遊戲而有不同的樣子。最後則是為了避免組合各種模組，會造成同一支程式太過肥大的問題，而採用了新的設計方式，完成整個老虎機遊戲的串接，為的就是專案在後續維護上的考量。 與其阻止對方改動模組，不如幫助對方了解模組應該怎麼改，大家在這個過程都能獲得成長。 改變是艱苦的，收穫是甜美的。這次的合作是一個成長經歷，不管是在技術上，還是在交際上都有不錯的收穫，而老虎機模組在這次的調整中，也躍進了一個版本，並發展出了一套新的接法。希望未來專案能因為這套模組的導入而有不錯的效益，也希望藉由這次的合作，讓專案能對模組有更進一步的認識，讓模組可以漸漸發展成大家理想中的樣子。 --- 參考資料： - [嘉慶的訪題](/FgIPrNlVQEaghvp4tMRpQQ)