我因為最近在學習游戲開發相關知識，然後意識到自己設計模式知識缺乏，所以就去尋找相關書籍，這時候《游戲設計模式》這本書就跳到了我的眼前。 github上有大佬將這本書翻譯了，中文版閱讀地址在這：架構，性能和游戲 · Introduction · 游戲設計模式 (tkchu.me) 序章：架構，性能和游 ...
我因為最近在學習游戲開發相關知識，然後意識到自己設計模式知識缺乏，所以就去尋找相關書籍，這時候《游戲設計模式》這本書就跳到了我的眼前。
github上有大佬將這本書翻譯了，中文版閱讀地址在這：架構，性能和游戲 · Introduction · 游戲設計模式 (tkchu.me)
序章：架構，性能和游戲
1.好的軟體架構
對於作者而言，好的設計意味著改動輕鬆。
2.如何處理改動？
需要改動代碼之前，你必須理解代碼。而當你改動代碼後，下個編寫代碼的人就需要重新理解代碼。
這是編程中最耗時的部分，而解耦可以幫上忙。
3.解耦幫了什麼忙。
作者認為如果兩塊代碼是耦合的，那麼無法只理解其中一個。如果解耦它們，就可以單獨理解某一塊，這樣理解代碼的時間就減少了。
對作者來說，軟體架構的關鍵目標是：最小化在編寫代碼前需要瞭解的信息
當然，解耦後，可以單獨修改其中某一塊，這樣波及的範圍就會少。
4.解耦很好，那麼代價是什麼呢？
如果你足夠熟練，也許能花少的力氣寫出最優雅的代碼。
但事實上，我們大多數每次做出改動或是實現特性，都需要花費大量的努力去管理代碼，使程式在千百次的變化中仍能保持它的結構。
所以，你得考慮程式的那部分需要解耦，再引入抽象。
但是，事情從這裡開始變得棘手。每當你添加抽象或擴展支持，你就是賭以後這裡需要靈活性，這些代碼以後會被需要。如果賭對了，那麼非常好，但是賭錯了，你就得處理更多代碼。
而當你過分關註這點時，代碼庫就失控了。因為介面和抽象無處不在，各種各樣的擴展點，它們遍地都是。因此，你會消耗無盡的時間回溯所有的腳手架，去尋找真正做事的代碼。
理論上解耦意味著改動需要理解的代碼變少了，但抽象層本身也會填滿大腦。
這樣的代碼庫，會使得人們反對軟體架構，特別是設計模式。
5.性能和速度
軟體架構和抽象有時因損傷性能而被批評，而游戲開發尤甚。
讓代碼更靈活的許多模式依靠虛擬調度、介面、指針、消息和其他機制，它們都會加大運行時開銷，因為知道運行時才知道調用的類。這更加靈活，但增加了運行時開銷。
而寫代碼調用類中的具體方法時，你就是在寫的時候指定類——硬編碼了調用的是哪個類。這更快，但不靈活。
模板編程這是兩級之間。在編譯時初始化模板，決定調用哪些類。
要麼損失一點點性能的前提下，讓程式更加靈活以便更快地做出原型；要麼優化性能，損失一些靈活性。
作者認為：讓有趣的游戲變得高效比讓高效的游戲變有趣簡單得多。 一種折中的辦法是保持代碼靈活直到確定設計，再去除抽象層來提高性能。
6.糟糕代碼的優勢
編寫構架良好的代碼需要仔細地思考，這會消耗時間，而在項目的整個周期中保持良好的架構需要花費大量的努力。
而游戲設計需要很多實驗和探索，特別是早期，寫一些你知道將會扔掉的代碼是很普遍的事情。
與此同時，你得讓人們清楚，可拋棄的代碼即使看上去能工作，也不能被維護，必須 重寫。
作者的小技巧：
一個小技巧能保證原型代碼不會變成真正用的代碼：使用和游戲實現不同的編程語言。 這樣，在將其實際應用於游戲中之前必須重寫。
7.保持平衡
有些因素在相互角力：
1. 為了在項目的整個生命周期保持其可讀性，需要好的架構。 2. 需要更好的運行時性能。 3. 需要讓現在想要的特性更快地實現。
好的架構長期來看提高了生產力， 也意味著每個改動都需要消耗更多努力保持代碼整潔。
草就的代碼很少是運行時最快的。 相反，提升性能需要很多的開發時間。 一旦完成，它就會污染代碼庫：高度優化的代碼不靈活，很難改動
8.簡單
作者認為：簡化這些限制的辦法就是——簡單。努力去寫最簡單、最直接的解決方案。目標是正確獲得數據結構和演算法（大致），然後再從那裡開始。
簡而言之就是，蒸乾代碼，對於多種情況，我們想象最優雅的代碼時，想的是通用的那個：只需要很少的邏輯就可以覆蓋1整個用況。
9.作者建議：
-
抽象和解耦讓擴展代碼更快更容易，但除非確信需要靈活性，否則不要在這上面浪費時間。
-
在整個開發周期中為性能考慮並做好設計，但是儘可能推遲那些底層的，基於假設的優化，那會鎖死代碼
-
快速地探索游戲的設計空間，但不要跑得太快，在身後留下爛攤子。畢竟你總得回來打掃。
-
如果打算拋棄這段代碼，就不要嘗試將其寫完美。搖滾明星將旅店房間弄得一團糟，因為他們知道明天就走人了。
-
但最重要的是，如果你想要做出讓人享受的東西，那就享受做它的過程。
