讀《遊戲設計模式》第一部分

第一部分位址

什麼是好的軟體架構？

對我而言，好的設計意味著當我作出改動，整個程式就好像正等著這種改動。我可以僅呼叫幾個函式就完成任務，而**庫本身無需改動。評價架構設計的好壞就是評價它應對改動有多麼輕鬆。

這聽起來很棒，但實際上不可行。「把**寫成改動不會影響其表面上的和諧」就好。

你如何處理改動？

在你改動**去新增新特性，去修復漏洞，你需要理解**正在做什麼。

你將一些**加入了遊戲，但肯定不想下乙個人被留下來的小問題絆倒。除非改動很小，否則就還需要一些微調新**的工作，使之無縫對接到程式的其他部分。

解耦幫了什麼忙？

可以用多種方式定義「解耦」，但我認為如果有兩塊**是耦合的，那就意味著無法只理解其中乙個。如果解耦了它們倆，就可以單獨地理解某一塊。

解耦的另一種定義是：當一塊**有改動時，不需要修改另一塊**。肯定也得修改一些東西，但耦合程度越小，改動會波及的範圍就越小。

代價呢？

天下沒有免費的午餐。好的設計需要汗水和紀律。每次做出改動或是實現特性，你都需要將它優雅的整合到程式的其他部分。需要花費大量的努力去管理**，使得程式在開發過程中面對千百次變化仍能保持它的結構。

你得考慮程式的哪部分需要解耦，然後再引入抽象。同樣，你需要決定哪部分能支援擴充套件來應對未來的改動。每當你新增了抽象或者擴充套件支援，你就是在賭以後這裡需要靈活性。當你過分關注這點時，**庫就失控了。導致介面和抽象無處不在，外掛程式系統，抽象基類，虛方法，還有各種各樣的擴充套件點。

效能和速度？

軟體架構和抽象有時因損傷效能而被批評，而遊戲開發尤甚。讓**更靈活的許多模式依靠虛擬排程、介面、指標、訊息和其他機制，它們都會加大執行時開銷。

一種折中的辦法是保持**靈活直到確定設計，再去除抽象層來提高效能。

糟糕**的優勢？

但就像早先提到的，遊戲設計需要很多實驗和探索。特別是在早期，寫一些你知道將會扔掉的**是很普遍的事情。

原型：一坨勉強拼湊在一起，只能完成某個點子的簡單**，是個完全合理的程式設計實踐。雖然當你寫一次性**時，必須保證將來可以扔掉它。可拋棄的**即使看上去能工作，也不能被維護，必須重寫。如果有可能要維護這段**，就得防禦性地好好編寫它。

保持平衡？

有些因素在相互角力：

1. 為了在專案的整個生命週期保持其可讀性，需要好的架構。（需要時間維護，思考可能的擴充套件）

2. 需要更好的執行時效能。（**更容易變到不靈活，很難改動）

3. 需要讓現在想要的特性更快地實現。（更容易考慮不周）

總有今日事今日畢的壓力。但是如果盡可能快地實現特性， **庫就會充滿黑魔法，漏洞和混亂，阻礙未來的產出。沒有簡單的答案，只有權衡。

糟糕的**很少是執行時最快的，提公升效能需要很多的開發時間。而高度優化的**不靈活，很難改動，會汙染**庫。

簡單？最近，我感覺如果有什麼能簡化這些限制，那就是簡單。在我現在的**中，我努力去寫最簡單，最直接的解決方案。正確獲得資料結構和演算法，然後再從那裡開始。注意我並沒有說簡單的**需要更少的時間編寫，好的解決方案不是往**中注水，而是蒸乾**。

最後？還有些建議給你，希望對你有用：

抽象和解耦讓擴充套件**更快更容易，但除非確信需要靈活性，否則不要在這上面浪費時間。

在整個開發周期中為效能考慮並做好設計，但是盡可能推遲那些底層的，基於假設的優化，那會鎖死**。

快速地探索遊戲的設計空間，但不要跑得太快，在身後留下爛攤子。畢竟你總得回來打掃。

如果打算拋棄這段**，就不要嘗試將其寫完美。搖滾明星將旅店房間弄得一團糟，因為他們知道明天就走人了。

但最重要的是，如果你想要做出讓人享受的東西，那就享受做它的過程。