Zi 字媒體

我試著儘力從鳥瞰的角度回答一下這個問題。從根本上來說，一切程序都是邏輯程序。而遊戲邏輯程序恰好是最難寫好的程序之一，業務穩定性弱（需求變化快）、評價因素主觀性強（綜合評價流暢性、手感、趣味性、操作方便性），同時還要滿足一般程序的評價標準（正確、清晰、易維護、效率OK）。遊戲開發中最大的基本模塊，UI、Gameplay、遊戲AI，其實就是邏輯程序。我們把眼光抬高一些：先說軟體工程方面。所有軟體工程的書籍，通篇來說，都是講人多了怎麼幹活。從《人月神話》到《敏捷開發》，書很是不少，汗牛充棟。那麼要這麼多人寫程序，寫什麼東西？絕大多數必定是具體業務邏輯。總不可能200個工程師一起扎堆寫渲染器、寫內核調度或是寫語法分析器？「高精尖」的底層代碼，要保持簡潔和一致性，核心開發者一定不能多。那麼說到底，廣義的軟體工程方法百家爭鳴，討論的無非是許多人怎麼一起寫「邏輯程序」的問題。再說設計模式方面。設計模式正是對具體業務邏輯的全局觀式的歸納總結，即在面向對象的框架下，把具體業務問題抽象為N種模式。這種將複雜問題歸納總結的思想值得學習。但是也要看到一個事實：總結歸總結，問題並沒有更少，反而可能更多了。一方面是面向對象的框架本身具有局限性，數據驅動等等新的思路可以彌補之前的經典設計的缺陷；另一方面，也充分說明了具體業務邏輯的複雜性是無法估計的，所謂「沒有銀彈」。高處著眼過後，還是要回到實際。為什麼專門搞邏輯程序的人很容易走進瓶頸呢？我覺得還是目前國產遊戲的邏輯部分，同質化比較嚴重，邏輯程序員發展的天花板低。做完一個項目，很少有值得分享的事情，成就感也不足。相比之下《守望先鋒》這個遊戲有多成功暫且不提，由這部遊戲而誕生的討論、文章、技術分享、視頻講座等等，可不在少數~~而這些資料討論的內容，並非渲染、AI等等高深的問題，而僅僅是集中在兩點：1、邏輯架構。2、同步策略。僅此而已。對比而言，我們能否在做項目的時候，把一兩個問題分析透徹，後期總結一兩篇技術分享呢？我覺得並不難做到。舉幾個例子（某些可能看似很Low）：1、周期性CD的總結。對每天、每周、每月定時刷新的問題的處理方法總結。2、實時戰鬥類（MMORPG、MOBA）遊戲，技能框架設計總結。3、技能系統，狀態機式框架和樹式框架對比分析。4、實時SLG類遊戲（例如《巨龍爭霸》），戰鬥邏輯總結。包括派兵、合兵、集結等複雜情況的處理。5、實時遊戲，宕機恢復的處理策略。6、MMORPG的同步策略優化。以上只是冰山一角，任意一條都值得深思並寫下來交流。這裡推薦一個技術博客雲風的 BLOG這個博客我的感覺是常看常新，拜服於作者思考問題的深度。裡面偶爾會出現和遊戲邏輯有關的乾貨，值得仔細思考，值得從純技術角度寫一篇贊同或者反駁的文章，或是運用到項目里，那都是益處多多。寫到這裡我感覺有點啰嗦。也許知道自己該做什麼的邏輯程序員，不會來知乎看這個問題吧？XD希望能引起所有還奮戰在一線的開發者們的思考。總之，遊戲邏輯程序並不是一項不值一提的工作，事實也許恰恰相反——而這需要我們來證明。