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