你有時候會聽到關於軟體架構和相關概念的批評聲，尤其在遊戲開發中：它會影響到遊戲的效能。許多模式讓你的**更加靈活，但是它依賴於虛函式派發、介面、指標、訊息以及其他至少有一些執行成本的機制。
乙個有趣的範例是c++模板。模板元程式設計有時可以讓你獲得抽象介面而沒有任何執行時開銷。模板元程式設計介於兩者之間。在模板元程式設計中，在編譯期間你就能決定在模板例項化時呼叫哪個類。對靈活的定義，不同人有不同的看法，當你在某些類中呼叫乙個具體方法時，你相當於將這個類固定（很難做出改變）。當你使用乙個虛方法或者介面時，被呼叫的類將直到真正執行起來才能被追蹤到，這樣的程式更具靈活性但是會增加額外的執行成本。
還有乙個原因。很多軟體架構的目標是使你的程式更加靈活，這樣只需較少的代價便可對**進行改變，這也意味著在程式中更少的編碼。你使用介面，以便**可以與任何實現這些介面的類進行工作，而不是使用具體類。你使用觀察者模式（第4章）和通訊模式（第15章）使得遊戲的兩部分互相溝通，而將來它們自身就會成為另外兩個需要溝通的部分。
但是效能優化總是在某些假設下進行的。優化的方法在特定的條件下進行更好。我們能肯定地假設永遠不會有超過256個敵人嗎？好極了，我們可以將id打包成乙個單位元組。在這裡我們只會在乙個具體型別上呼叫方法嗎？好，我們就靜態排程或者對它內聯。所有的實體都是同乙個類嗎？太好了，我們可以將它們做成乙個很棒的連續排列（第17章）。
這並不意味著它的靈活性很差！它可以讓我們快速地進行遊戲更新，開發速度是讓遊戲變得有趣的關鍵性因素。沒有人，哪怕是will wright[1]，可以在紙上設計出乙個平衡的遊戲。這需要迭代和實驗。
你越快地對想法付諸實踐並觀察效果，你就能越多地嘗試並越有可能找到一些很棒的東西。即便在你已經找到合適的技術之後，你也要用充足的時間來進行調整。乙個細小的不平衡就會破壞掉遊戲的樂趣。
這裡沒有簡單的答案。將你的程式做得更具有靈活性，以便能夠更快速地進行原型編寫，但這會帶來一些效能損失。同樣地，對你的**進行優化會降低它的靈活性。
根據我的經驗，將一款有趣的遊戲做得高效要比將一款高效能的遊戲做的有趣更簡單些。一種折中的辦法是保持**的靈活性，直到設計穩定下來，然後去除一些抽象，以提高遊戲的效能。
遊戲程式設計模式 框架 效能 遊戲
恢復內容開始 好的設計意味著當我們做出乙個改動時，就好像整個程式都在期待它一樣。我們可以呼叫少量可選的函式來完美地解決乙個問題，而不會為軟體帶來其他的多餘的 只管寫我們自己的 框架會幫我們收拾一切！關鍵部分 框架意味著變化。衡量乙個設計好壞的方法就是看它應對變化的靈活性。好的改變，是在下乙個人在新增...
遊戲程式設計模式學習 第一章命令模式
命令模式 將乙個請求封裝成乙個物件，從而允許你使用不同的請求，佇列或者日誌將客戶端引數化，同 時支援請求操作的撤銷與恢復 該設計模式主要是為了隔離請求和實際執行者之間接觸，實現兩者的解耦。所有的請求統一有乙個類負責 該類負責管理這些請求。這樣命令物件和接收者之間的耦合度就會降低。命令物件不用直接施加...
《遊戲程式設計模式》一1 1 什麼是軟體架構
哇，此段簡直為這本書打了乙個糟糕的廣告。相反，這本書是關於上面這一切要使用的 的組織方式。這裡少談 多談 組織。每個程式都具有一定的組織性，即使它只是 把所有東西扔到main 函式裡然後看看會發生什麼 所以我認為討論如何形成好的組織性會更有趣些。我們如何分辨乙個架構的好壞呢？我大概有5年時間一直在思...