關於最近學習的一些雜談

來自專欄 羽喵家的遊戲雜談

最近在做一款獨立遊戲，小羽一個人包攬了主策和主程兩大職責。

很遺憾的是，主策我還是稍稍能勝任的，但是主程嘛，就比較呵呵了。

經過了一個多月對於unity引擎的熟悉，以及C#語法的了解，小羽目前的進度已經脫離了最開始那個艱難的時期。期間還重構了一次代碼來儘可能地解耦各個模塊。前些天看了幾篇有關設計模式的文章，同時也簡單學習了C#的委託及事件機制，對觀察者模式稍稍有了些了解。不得不說，優秀的程序員能夠在一開始就考慮到策劃（設計師）天馬行空的腦洞，設計出擴展性足夠強、耦合度足夠低的遊戲系統，但是，在我這裡事情發生了一點小小的變化：因為我就是那個有著天馬星空腦洞的設計師。

最關鍵的是，我們是一個獨立遊戲，小成本開發，儘可能地降低遊戲複雜度，不需要做特別多的版本迭代，這意味著我並不需要設計出一個有足夠深度的遊戲系統（更何況我是第一次做這種事情）。於是我可以說稍稍有些釋然了，把目標定位在學習和了解，而不是那種一蹴而就，單靠一個項目就能寫出別人10年經驗積澱下來的代碼上，我發現之前我太過看重看過的許多設計模式的文章，或者說我是因為水平的局限性，只能照貓畫虎般地去學習 文章中的設計模式，卻忽略了對於思想的總結歸納。

舉例來說，守望先鋒中的ECS模式，關於這個的文章有騰訊GAD的翻譯文，也有雲風前輩BLOG里的那篇文章，兩者都很好地介紹了ECS模式的理念，優點，以及一些實現的思路。但是，我在閱讀的過程中不知不覺地就忽略了我遊戲的實際情況，如果一味地去按照ECS模式解耦，未免有大材小用之嫌——用守望先鋒的引擎去寫超級瑪麗，這顯然是有些滑稽的。

後來我也看了知乎有關OOP的一些討論，我覺得有一個說法提醒了我：不能為了多態而多態，OOP的核心理念是封裝與歸一化。幸好我C++課基本沒怎麼認真聽，C#也只是自己有個OOP的概念就開始胡亂瞎寫，對於class的認知也不過是「這是一種引用類型的數據結構，new一個類意味著開闢了新的內存空間」，再加上我學C的時候對於內存、指針有著天然的恐懼感，內心中一直有一個聲音告訴我要關注內存（所以很多文章都在說無需注意C#的內存管理，但是我每學一個新知識點，每寫一個新邏輯都很小心地檢查我對於資源尤其是內存資源的佔用），所以我對於OOP的很多概念並不是很清楚。

在這裡我不得不要感謝騰訊GAD群里的前輩們，能夠在我提出問題後給我解答，甚至還有幾位前輩特意幫我理清思路，指出我思路中的不當之處。也正是因為這幾位前輩，我在對介面、抽象類、多態等概念完全不清楚的情況下，就已經對封裝和歸一化有了一個明確的概念。

所以我在學習unity和C#的過程中，我覺得我不僅僅掌握了一個引擎還有一門語言（其實也不是掌握，堪堪入門而已），更重要的是我理解了一種思想：設計是為實際需求而服務的，人不能為了設計而設計。其實從一開始我的職業規劃就是做產品或者策劃，最遠大的目標也不過是一個產品經理或者遊戲的主策，在我對於遊戲開發領域有了一個淺顯的認知以後，我覺得我以後如果真的步入了職場，無論是做什麼樣的工作，至少會少給其他人帶去一些麻煩。