研發替代役身分在鈊象遊戲業工作三年心得

某種忘記為什麼刺激開始寫這篇，算是某種懺悔文，要求自己未來不要重複一樣的錯誤。感謝前主管同事們的包容，才能順利渡過研發替代役漫長三年。

捨棄研發替代役

不是鈊象研發替代役這職缺不好，而是研發替代役這制度不好，當你開始對公司文化有所了解，因為組織策略調整或是其他因素，而不再喜歡這工作職缺時，要繼續待在相同位置三年，這太痛苦了。

當開始不喜歡這工作，又沒有辦法離開該職位，變容易會開始抱怨，進而影響到其他同事。之後週遭同事受不了抱怨的負能量紛紛躲開，然後會開始放空。

自己個人經驗是，研發替代役生涯還剩下一年半時，就有點不喜歡這公司的工作文化。到剩下九個月時就開始抱怨酸主管，最後半年一整個放空，沒有幹勁有氣無力的把交代是像做完而已。

工作放空是多麼浪費時間的事情，每天至少需要在公司待上九小時，一個禮拜就可以放空四十五小時…。假日則拼命玩遊戲，想要排解放空抱怨的糟糕情緒，但排解速度終究比不上一周四十五小時工作怨氣的積累。某種惡性的循環螺旋，時光飛逝，研發替代役三年過去了，都已經二七八歲了。

經驗同 XDITE 的人生建議，不要選擇研發替代役，無奈我是經歷過這些，才看到這篇文。

沒有人可以幫你處理情緒問題

職場工作總是有些不愉快，不愉快所產生的負面情緒沒有必要展現給同事看，也沒必要對主管有壞臉色，因為他們根本不能幫你解決情緒問題。

中期自己不再喜歡公司文化所導致的情緒，怒氣矛頭指向可憐主管，一有機會總是在那裏酸言酸語，以為這樣會讓自己好一些，但心裡並沒有感受比較好，反倒是賠上了良好的溝通管道。記得後來冷戰一年，沒有再跟調到別組的主管聊過話。後悔總是有的吧，實在是沒有必要。

真的很不爽，不再喜歡這個工作，公司這艘大船與自己當下想前進的目標不再相符時，揮一揮衣袖跳船離開，到外面去尋找自己工作熱情的所在。但前提，不要是研發替代役，沒有被綁在船頭上不能跳。

準時下班才是王道

能夠準時下班，享受自己的時間才是正解，這時間可以是用來參加活動，增長生命經驗。也可以是學習進修，增強自己的職場工作能力。而不要為了沒有生產力的加班而加班。

當時鈊象電子有個內規是每月加班要滿 20 小時，平均每個禮拜要加班 5 小時，週間加班時數沒有滿足標準時，有時會主管會找我到小房間去聊聊怎麼沒有加班。

這種半強迫加班造就工時長，會造成自以為認知，反正不管交辦事項有沒有做完，都必須留下來加班的話，那為什麼需要鞭策自己提高效率，提早把工作做完呢。且加班會使得自己的休閒時間減少，導致沒有足夠休息心情好不起來。

初期都很聽話，每週都有加班到足夠的時數，包著糖衣的加班費那時也是個甜美的誘惑。現在回想起來，如此花費數多時間待在公司，沒有多多接觸外面的活動，不知道除了公司以外的美好世界…。

現在回想，若當初加班內規不能破，先逼迫自己在短時間內完成工作所交辦的事項，然後利用加班時間拿來自我進修，學新的工具，新的程式語言，甚至做些自己的研究專案才是。

相信自己最強能 Carry 全隊友

其實要屎事一肩擔起，所有規格不明確，所有還沒有人認領功能，就強迫自己去接下，並且逼迫自己在時間之內完成。什麼都嘗試去做，可以讓自己進步飛快。

一開始是懵懂無知的新鮮人，第一次接觸 Unity 來開發遊戲（當時的版本是 Unity3.x），在學校之前沒有人教 Unity，所屬的專案成員也是第一次使用 Unity，軟體組員是一名資深的成員加上一位新鮮人。Unity 當時是完全是陌生的領域，也沒有辦法依靠組員教學，只能靠自己啊。

在強迫自己另一名軟體同仁開發 Unity，幫助美術導入資源到 Unity，教企劃使用 Unity 編輯遊戲關卡，教同組組員使用 Git Version Control，一肩擔起與遊戲機構部門開發 IO 板硬體與遊戲對接，以及初期自己要負責編譯版本放在遊戲機台上…。總總的雜事，對於 Unity 學習上根本進步飛快，且從同事溝通中也可以學習互相遇到的問題是什麼，然後迫使自己快速找到解決方案。

回想當時沒有到外面多接觸，多看看外面的強者怎麼工作做事，沒能讓自己產生「如何讓工作做得更好」的想法。例行公事自動化以及分享教學這兩塊議題完全沒有去做。

自動化像說每次編譯遊戲版本，並發布到遊戲機台上這件 Dirty work，能夠由機器自動完成，其實就是建立一個 Build Server，定時自動建立版本。（最近有使用 Jenkins 建立一個 Build Server）

分享教學是將經驗傳授給他人，讓別人去教別人，自己不要這麼累都必須出面解決同事的問題。更應該寫成文章公開分享，寫作是一個整理好思緒的好方法，也可以積累下一份工作的談判籌碼。

記得留下紀錄

做任何事情溝通，給予任何建議，會議的結論事項，甚至是工作技術的積累應該都要留下紀錄。

深為遊戲業的軟體人員，常常需要與遊戲企劃或是美術人員討論協做功能的開發問題，當討論結束應該花時間寫一封信來確認雙方討論的結論，並且要將該信件一併寄給遊戲製作人跟雙方的主管（e.g. 軟體頭子，美術頭子，企劃頭子）。花點時間的信件可以帶來的好處有：

• 確認結論，信件所寫的結論有錯對方會主動來確認
• 練習工具，整理討論結論思路的練習工具
• 打臉證據，當對方口頭翻臉不認帳時，拿出來信件狠狠的巴對方（爽在心裡）
• 展現自己，讓大主管知道自己多麼主動積極，印象考績會好一些

另外工作技術的積累寫成文章，為下一份工作的履歷經歷累積展現籌碼，因為漂亮的履歷是靠平時一點一點的積累而成。

遊戲需求一直在改變

這算是在遊戲業最大也是最痛的收穫，需求永遠在改變。了解不要把程式架構設計的太死，永遠保持彈性。要保持開放的心胸，接受任何的修改挑戰。

當初專案中的工作流程，通常是企劃開會討論，思考遊戲世界觀，規劃遊戲玩法，找遊戲風格參考圖片。然後部分文件交給美術，美術開始規劃遊戲場景，製作場景或是角色模型，並繪製貼圖以及製作角色動作，或是寫美術外包文件。程式也根據玩法設定開始製作程式架構，然後把美術初步做的簡易模型動作整合，並撰寫遊戲編輯器，訓練企劃學會如何編輯遊戲，交由企劃編輯遊戲，最後發佈測試。

主要企畫、美術以及程式三方互相把遊戲完成，團隊試玩後可能會有些新想法，想讓遊戲更好玩。然後開會討論，確認進行修改。此外在時程的里程碑上，會特別製作一些較完整試玩版本（Prototype、Alpha、Beta 等），通常這些版本前幾天是加班地獄。

該些試玩版本給展示給一堆大主管看，大主管們通常是求好心切，總是會給一些跟原先規格差異很大的需求，認為感覺做起來不錯的需求功能。這些需求有時候是無視團隊成員意見，需求最後就是要執行，沒有否決的空間，單方面的命令。

最糟糕是有些試玩版本覺得已完成 A 功能拿掉，加入新功能 B 會比較好，待下一次已完成調整的版本試玩卻可能會改變主意，覺得可能一開始的版本比較好的窘境。

當時遊戲開發循環就是一直改一直改，上頭說什麼就做什麼，遊戲功能比較沒有自己的主觀意見，一切想辦法滿足上頭原則為原則。

人生不也是如此，自己的人生階段性目標可能會因為環境需求或是自身想法，而一直在改變，但社會氛圍以及道德枷鎖總是會要求你要如何如何。但與職場不一樣的是，人生可以自由選擇自己想要做的事，而不是被強迫做那些自己可能不喜歡的事情。