Be creative, write anything.

鈊象遊戲業工作三年心得

沒有留言
鈊象遊戲業工作三年心得
注意:此為 2012-2014 年在遊戲業-鈊象的工作回憶與心得,文中提到的公司工作環境狀況都為當年個人感受經歷,不能做為鈊象電子公司之現今工作情況的參考

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

捨棄研發替代役

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

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

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

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

經驗同 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 會比較好,待下一次已完成調整的版本試玩卻可能會改變主意,覺得可能一開始的版本比較好的窘境。

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

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

沒有留言: