本文連結：https://ndark.wordpress.com/2023/04/10/%e9%82%84%e6%98%af%e8%ab%87%e8%bb%9f%e9%ab%94%e7%ae%a1%e7%90%86%ef%bc%8d%e5%be%9e%e9%9b%b6%e9%96%8b%e5%a7%8b3-0/
本文短連結：https://tinyurl.com/22xapu7h
回到台灣先後從兩間 Hyper-Casual 的公司服務後，2022 年初與觸寶的同事一起加入 Bloxmith 作自研案<Raiders Rumble(時空突襲)>(link)。這個自研案的特色已經在此篇"These facts let’s shout out loud. 大鄉共出來！"(link)說明。
加入此案最初設定的目標是 A)協助該公司將團隊建立起來，B)協助產品上線。此案在 2023 第一季送上商城進行公開測試（玩家可直接從商城下載遊戲）。
這個案子（團隊）的屬性是Ａ）自研，Ｂ）無IP，Ｃ）非續作，Ｄ）整個團隊在開案之初大多數不互相認識，Ｅ）玩法聲稱要特殊。為避免贅述以下簡稱相同屬性的案子為：非續作自研案。
多年以來，如同"從零開始2.0″ (link)所論述，我關注的領域是軟體工程，軟體管理，或稱製程。
我個人遇到一個困難。大多數從業人員即便每天照三餐抱怨，但其實對這領域感觸不深/興趣不大。大多數的從業人員比較專注在其專業及設計上（在個人能夠改變的範圍）。即便是同為管理人員，不同的專案內容（代理，本地化，續作開發），其實也都會對此領域產生不同的結論。（我們可回憶某年的研討會上曾出 IP王道 vs 玩法王道 同場比拚，處理的問題不同，導致開發者得到不一樣的 Best Practice）
對我的演講內容比較有感觸的比較接近現役管理者，或是公司管理層。也就是能體悟：遊戲專案管理相對於遊戲開發的各環節是唯一不容易也“很難用資源能砸出成果”的領域。這也是為何我把此領域認為是每個團隊/成員/管理者都應該要好好思考，因為終究會遇到困難。
當然先賢曰：一人靠毅力，兩人靠忍讓，三人以上才需要管理。這點我認同。
在"These facts let’s shout out loud. 大鄉共出來！"(link)說到，本案開案之初就到部的程式人員中共五位（其中一位伺服器端，四位客戶端），全部都是沒有作過"遊戲商業作"的開發者。其中有幾位甚至是畢業後第一份工作。說明到此，讀者可停下一口氣深思估量自己曾經做過的案子中是否有類似的經驗。遇到這樣的情況時該作何反應。（塊陶啊？）
補充：本案在開發後期伺服器人員最高擴增到 4.5 位（其中包含一位的短期約聘，一位兩端雙棲）客戶端則是最高 5.5 位。
不過在我從業生涯中，這已經是第二次面對這樣的情況。生涯中我也看過不少同公司同業的專案在類似情境面對各種困難。所以我並沒有生出”驚訝“這種情緒。
破題說明我的感想：唯一的問題就是時程評估
從我的觀察，非續作自研案很有機會一作作三年。而這些案子都不是一開始就知道或計畫要作三年。大多數最初的規劃都可能過分樂觀估算三個季度應可完成（其中也許有些是為了討好金主而只好評估出這樣的預想，但本人認為這樣的預想也許更會惡化投資人與開發團隊的關係，此為題外話）。不過只要持續推進確實大概半年左右會完成到主要戰鬥畫面（做玩法驗證），整體專案會在第一年期作到可上架的里程碑。
這時（一年期）的產品可推估是：可執行，是一個完整（甚麼都有）的產品，但應不到 Product Owner 心中的標準。接著就會開始以下的循環：設計變更，時程延展，人員流失，重新補進新人（甚至是更換製作人），新人會帶來更多的設計變更，時程再度延展，新舊人員在設計上出現歧異再度流失，回到重新補進新人的循環。這樣的循環會到第三年期， Product Owner 終於無法信任開發團隊，最後會找來一個救援投手，負責收拾殘局，產品能上線止損就好。
專案時程如何接近原先規劃
第一重要
要將專案濃縮到如原先規劃，其實最重要是 Product Owner 的意志是否堅定。不會在中途增加看到畫面之後產生原先規劃之外的規格變更。當然以一個"玩法聲稱要特殊"的案子來說，這點並不容易。即便是獨立遊戲有著極小化的人員配置及管理成本，都很常看到結果發現先前設計有問題，規格需要變更一作作三五年的情況。而這三五年絕對不是用砸錢換人力可以縮短的時程。多出來的人力會帶來多餘的管理問題。反而會將專案開發時間延長。請謹記軟體開發不是製造業，而是服務業，很難透過買斷技術或素材來縮短開發（很難換一個/多一個髮型設計師，理髮的時間會變短，多半是剪得更好看。買斷人力資源做人月神話不能說是不可行的方法，但必須完全專用）。
如前述，方向修正這個問題在商業作品及獨立遊戲專案或小專案都會發生，不能專說這是商業遊戲的問題。不過有個絕對的差異是來自心理層面。獨立遊戲的決策幾乎是團隊內自己決定，而商業作品的這種變革是必來自於 Product Owner，所以領薪水的工作者會有被改變的不安全感，這種感受在以作品為 credit 的遊戲產業又特別強烈（在以公司名氣為 credit 的科技產業就比較感覺不會這麼強烈）。在科技產業爛主管爛老闆都是上層的問題。只要公司有名，底層員工心態上比較能夠跟案子切割清楚。遊戲產業容許部分的自主性（組織鼓勵大家貢獻點子）反而帶來了靈魂無法與專案切割的被改變不安全感。
當然華人界也有其獨特不理性的情形，也就是過分期待希望自己遇到的是明主及高明的團隊。但其實任何高手也都是普通人。也都要面對普通人會面對的資訊不足，資訊飽和，人際關係，七情六慾，以及人生家庭問題。
此處插入職涯錨定關於人和的議題
我在"從零開始2.0″ (link) 中提到職涯錨定。也就是工作者對職涯的追求其實不同。找尋同伴或同事時如果不是有長時間的相處磨合進入平衡。多半最後都會走向因為職涯錨定的不同（價值觀不同）導致鄙視鏈。因為人生的意義不同，所以人與人相處之間會產生摩擦。我在 2017 年專心在軟體人員招募的議題(link) 在招募時我也盡量能關注合作性而非技術力。合作造成的效率低落是巨大到時程呈現兩倍到三倍的成長。網紅創業家 Gary V 曾有一個演講標題是這樣的：“有時候你必須讓團隊中的高手離開”。我能與他理解了類似的東西。如何在技術與合作性間找到平衡點至今對我仍是一個考驗，特別是資源及選擇有限的情況下。
第二重要
回到上述要將專案時程如原先規劃，第二重要的就是團隊成員互相理解功能組的每個人中：自己應該負責的部分，以及應該要交給別人負責的部分。這個理解必須是他觀與自觀同時符合。他觀與自觀衝突時產生的不一致終究會造成人際關係的崩壞。最終究會成為"又是一個爛人，一個爛主管，一個爛專案，一個爛老闆，一個爛公司"這樣的簡單結論。
簡單來講，也是合作性大於技術力的平衡。對於每次的招募來說，都是個人對公司，其實比較缺乏個人對團隊其間成員的思量。
結論：不管是求職者或是用人單位，不管是對於設計或是人事，說"不"比較難，但是多半說"不"或是"拒絕規格進入"對長遠比較有幫助。
第三重要
要能將時程縮短，在同一個案子開發中，技術（或是製程）方案我認為必須獨裁。也就是不要讓團隊陷入選擇技術方案之爭。而要達到這樣的結果，最簡單的方法就是主管的獨裁：不要讓團隊（在技術選用上）思考（當然前提是複數方案都可行，不可能選用一個方案無法達到妥協後的目標）。專案與專案間需要比較的時候，最好在不同專案都有成果時，才能夠有超出技術人客觀的比較）
id software的討論串(link)中提到團隊中一定會有喜歡產品的人以及喜歡技術的人。而當團隊中缺乏喜歡產品的成員的時候"your product never ship（專案就不會結束，因為技術重構優化的工作的優先度永遠都高過於把專案做完）"。因此控制招募進團隊的成員使得產品人的數量高過於技術人的數量可以在此發揮一點作用。
談軟體架構（框架）
從先前服務的幾個案子中我其實學到蠻多有趣的體悟，要談軟體架構就必須先談這些案子的獨特之處。
先說結論：軟體架構的好處是將多個專案相同的地方拆出減少重複製作輪子重複解相同問題的現象。
但這個前提（多個專案）在非續作自研案上其實不存在。在這種案子上談架構接連地會導致一些技術選擇上的矛盾。也就是說技術派的開發者，會自動地選用可以擴充的技術或架構，當然，一定對"未來"比較好。
而可以擴充（專案會完成，導致會有二代）這前提，若把它當作規格。此規格不一定存在。
2018~2020 我在 Ubisoft 維護 Growtopia，先前有翻譯過一篇 Growtopia 作者的自述開發心路歷程(link)，其中作者提到，之所以 Growtopia 可以在三個月完成第一個原型並上線驗證，其中很重要的原因就是，他透過先前的幾個案子，已經不需要再額外開發什麼模組（也可以說這個案子他決定不再額外研究系統）。當然兩人開發減少了溝通問題，獨立開發也減少了投資人發行商的意見問題也對此有貢獻。而當本人在這個專案的服務過程（當然是這個案子已經被賣給 Ubisoft 後），從製作人到主程式都很正式的跟技術團隊說明，這個案子雖然從內部看很陽春，但強烈建議團隊"不要"進行重構，甚至講明白了不要使用 JSON 格式。所謂的陽春是什麼意思？這個專案的寫作方式就是把全部功能及設定寫死在程式碼內。直到我離開這個專案時仍是如此。
舉個例子，這個案子的設定表是像這樣一個類別 ItemSettingTable 的初始化時會去跑一個建構子（簡單理解就是 Setup() / Initalize() 這樣的函式），而每個道具的參數，就是寫死在這幾千行的程式碼內，修改時，就是改程式碼重新 build 版本，重新部署。而非透過一個 database 來管理。我相信，如果有從業人員在商業公司中這樣寫作，肯定會被臭罵不夠有彈性，沒有經過專業訓練的寫作方式。
成敗論英雄，Growtopia 年營收是用百萬歐元做單位來計算。這個產品現在還在營運中。
Hyper-casual 類型的團隊開發及部署節奏
我在 2020~2021 年連續服務於兩間 hyper-casual 的開發公司。基本上開發及部署的週期都是少於一週，也就是在一週之初企劃會開出本週要做的事情，這些工作項目也必然大多是一週內可以完成的調整，團隊在一週內完成這些項目，然後在週期結束時發佈到商城。企劃會接著回收數據，作為下週的方向調整依據。在這樣的節奏下，很重要的是團隊每日建置測試的慣性。更重要的是企劃的能力：能否在每個週期開始前就把美術項目發包完成“回收”，讓開發團隊可以在新的週期開始時取得能實作的素材，在每個週期開始前，就知道要埋什麼樣的數據點（同時規劃 A/B Test 的方法），在每個週期完成後，能夠回收數據及 A/B Test 結論，將結論納入下一個週期的設計。再次開始新的週期（此時已經完成回收第二週期的美術發包）
在這樣的案子訓練出來的企劃有一個特質，就是能夠適應每次的設計都是從現況逐步改變，而非規劃長期工作。當然我不認為這麼短的時間貢獻的知識能有多高竿，但確實這種企劃能夠提高團隊的輸出效率。
在我這次參與的案子中，我使用了這些概念，包含不過分使用框架（直接使用Unity再搭配團隊自己提出開發時需要的插件），在問題出現前不過分標準化寫作方式（我們沒有規範coding style，唯一定義的是網路協定的命名方式），每日建置並追蹤問題（我把這部分叫做快速迭代：每個人在功能線上開發每天進行整合，每天建置，每天有新版，每天追蹤是不是有什麼東西壞掉，即時或盡快修復那些整合失敗的部分）
id software的討論串(link)中也提到架構/系統這件事，就我的理解，每產生一個架構與系統都會產生設定資訊（meta），而這些資訊是專案中獨有的，不管文件怎麼詳細，最後這些資訊都存在於開發者的腦袋裡。架構就是想辦法把開發者的腦子內的這些資訊，抽出為非開發者也能理解。
譬如說，某些框架會去規範每個美術資料夾的貼圖的解析度大小，當檔案變動時自動跑一個腳本把貼圖解析度自動優化。當這樣的設定資訊被抽出為架構，也就是美術人員或管理層也都必須知道美術檔案要放在這裡，解析度會被自動調整。（才不會遊戲出來之後發現圖為什麼糊掉了或解析度跑掉了，再跑去怪美術人員或是開發人員）
如前述，這個案子中有成員在程式設計領域有困難，所以為了不要在前期花費太多時間“教學”。更支持了我不特地選用框架或建立規範（減少知識的傳遞導致的時間浪費）。
當然缺點很明顯，程式碼每個人習慣不同，花式命名對每個開發者來說維護起來確實造成一些困擾。但是經過適當的切割，每個人都能安全地在所屬的功能中開發，我們每天有十幾次的 feature merge。其實鮮少有 merge conflict。發生了衝突也都會在一天內解決。我想，光每個開發者，能夠放膽把當天的開發功能在一天之內合進主線，就不是每個團隊每個開發者都做得到。包含我在內沒有人能夠寫出完美不用驗證的程式碼，這樣的開發模式能夠運作的最後一片拼圖是每天與我們配合的測試人員。
開發方法與製程
快速迭代的軟體開發方式
在我早期的針對品質管理演講(link)中提到，每個修改（包含美術資源的更新）都有可能引發副作用。修正副作用也可能觸發額外的副作用。副作用的產生就只能透過測試修正逐步解決。測試的方式我想在此不多做說明。不管哪一種，投注的時間越多，效果都看得見。
這個案子我要求成員放膽完成功能就通知我整合進主線。因此如此篇文章所說，每天大概會有十多次的整合(merge)。一定會發生有什麼人改了什麼導致主線無法成功運行。（ex. compiler error/null reference）。如果成員持續地在主線上開發，那麼一定會有人發現通知團隊並儘快修正。（若無法及時修正，可以直接revert回前一版）每天建置版本的好處，revert最早也不會超過一天的量（幸運地我們從未 revert 這麼多的量）。測試員作為每日建置版本的第一道防線，如果建置的版本不能跑，或跑起來有嚴重錯誤，就立即派人檢查並修復再出一個新版。其他非致命的功能錯誤，就由測試員持續地回報。這樣的做法的好處就是把整合期會發生錯誤的修復時間，有別與傳統開發方式（有指定測試時間），從測試期拿到開發時間來。修復這些整合性問題也當作是完成功能的重要指標（發生在功能線上正常但整合後失敗的情況也代表功能的未完成。）
這樣的成果在issue系統上可以顯示出來，我們的臭蟲數目維持一個動態穩定的數字。每天都有增加新的臭蟲，但每天都有一定數量的解決。直到里程碑進入測試期我們大多要處理的問題就是品質與期待落差造成的修改。
資訊傳遞/開會仍是一個困難的議題
本案在資訊傳遞上也遇到了跟任何一個專案的相同問題。開會的次數及長度應如何拿捏？開會多了，就是大家的工時就浪費在會議中。開會少了，點對點的溝通會讓團體運作像瞎子摸象，每個人都摸到象的一個部分。資訊傳遞在少數人中，其他人就不知道這些重要資訊。這個問題到了專案後期我也還沒有找到解決方法。只能在里程碑的斷點，強迫團隊成員分享，整理文件。
早期軟體管理的困難
如前述，這個案子中有成員在程式設計領域有困難。在第一個季度，我的難處是在於如何正確評估每個成員的能力，指派適當難度的任務。不管多與少，盡量讓每個人產生產值。
在自動演出的部分，很幸運地我參考了我在 <Taiwan War> 及 <Growtopia> 的經驗。前者當時的案子剛好就是自動戰鬥，我將每個伺服器運算的戰鬥行為轉為一個行為陣列，客戶端則依照這個陣列來演出。後者的經驗告訴我演出系統是靜態系統，也就是設計希望這樣演，設計結束之時可視為變動就固定，所以在客戶端我依照當下的需求設計了一個時序演出+角色分割寫作的方式，將所有的角色的演出除了伺服器戰鬥參數外全部都寫死在客戶端。（這也是 <Growtopia> 每個月產出新裝備新特效的做法）程式人員透過簡單的函式來呼叫美術人員的素材，透過單一寫死的時序流程（"Coroutine"）逐步實作需求。幸運地設計端也能夠體諒這樣的開發方式，沒有過分提出跳躍式的需求。最大的弱點就是自動演出無法中間插入變化（幸好我們沒有戰鬥中人為觸發技能施放這個功能）
意外學到的經驗
瞎子摸象造成的設計問題
前述有提到瞎子摸象（團隊常見透過點對點溝通但訊息不同步）的情形，本案中也會發生。也用此來告誡設計人員，遇到問題不要只看自己的專業，而必須各方問題整合起來思考找到共識。在本案的戰鬥前流程，有一個佈陣階段（雙方角色擺放位置進行戰略優勢調整），專案推進時因為有問題而不斷做調整改版。最初是因為戰鬥時角色演出要有空間，所以拉大了敵我雙方的陣型距離（楚河漢界的位置有跑動演出的空間）。同時因為要方便玩家觀察佈陣結果所以改用了俯視視角。兩個設計需求綜合後在視覺上立即出現問題，因為俯視，所以佈陣時放下3D角色就變成頭頂方向，失去了角色的鑑別度，可惜了3D角色的創作優勢。因為雙方陣營距離拉大，所以俯視戰場的攝影機距離就要拉遠，才能同時看到兩邊的佈陣，又更加劇前述俯視的問題（角色因距離拉遠而變小）。因此這個流程陷入了多方設計人員互相折衝的難題。後期介面進行大改版，採用了大版面的2D角色介面，也更加劇了這個現象（因為介面佔據了更多視覺空間，要在有限的空間放入雙方陣營，只好再把攝影機距離拉遠）
沒有想到要錯誤處理導致未初始化的介面引發玩家不滿
在一次的封閉測試中，玩家的網路品質導致某流程初始化的流程網路要求 time out ，沒有收到重要資料。而後續的介面仰賴這些重要資料也沒有檢查做例外處理。導致初始化發生 null reference。介面則赤裸裸地以原始狀態顯示給玩家。好死不死，設計人員不只沒有提供例外處理的計畫，也沒有提供初始介面的設定。所以開發者憑藉自己的感覺來設定一個99999的最大位數視覺檢查方式。更糟糕的是，這個錯誤的情況被社群貼到網路上。最糟糕的是，這次的封閉測試有辦玩家間的比賽。這些錯誤的介面被玩家認為是官方在偏袒某些玩家作弊（給某些帳號偷塞錢）。當然，在開發環境中很難意識到這些重要的網路溝通流程會失敗，而需要多防範。但完全推給玩家網路不佳，也是過度卸責的表現。只能團隊吞下來事後檢討修改。
最後檢討
在客戶端，本案我覺得我將我以往的開發經驗極大化但未全部地發揮出來，在工程上，成績算是超過我預期。在伺服器端，有鑒於伺服器人員都不是從遊戲產業來的開發者，所以在與企劃溝通上我算是少做了太多控場的工作。導致伺服器有很多不必要的重構時間成本。如果再給我一次機會，我會用另一種方式來運行伺服器人員怎麼開發，簡單來講我必須花更多時間自己寫一套伺服器（邏輯及協定部分）。在其他部門合作部分，程式組採取了快速迭代的工作方法，可是並沒有將這套工作流程傳播到其他部門（畢竟我只管技術），導致其他部門對於製程部分都處於管線末端必須有意地適應及被迫調整學習。這點希望部門管理者能引以為鑒。合作性大於技術力在部門間也必須有意識地思考。
線上營運事件與後續優化混在一起讓製程更加的複雜
本段落是在發售後補充。幸運地，我們順利發售了，感謝參與的各位。我當時心態上已準備好面對線上的問題（伺服器端與客戶端都有）。但令我感到寸步難行的是，當除錯與行銷需求，素材更新一起發生時，同時品管人力沒有補充的情況下，前進的速度像陷入沼澤一般緩慢，尤其相較於我們開發時期使用快速迭代的節奏，反差極大。（啊～對！很戲劇性地，在我寫最後一段的同時，開發團隊的大多數人員也結束了服務。）
Black Straits Historical 