遊戲：誰負責顯示？

Question

實體是否應該知道如何繪製自己？我已經使用了這種方法：它很簡單並且可行，但是在學習MVC模式之後，我對此感到不安。當所有顯示邏輯都隱藏在模型中時，很難改變藝術風格。

可以引入一個視圖類，該視圖類將層次作爲參數並繪製它，但這意味着它必須識別實體類型並引入一個「switch」語句，我學到的語言也很糟糕。

哪裏應該繪製一個地方代碼，以一種可擴展，易於更改，乾淨和乾燥的方式？

Answer 1

Theres在你的實體中有一個抽象的Draw（）風格的方法沒有任何內在的錯誤，它們可以讓他們決定如何繪製它們，特別是對於可能不會顯着擴展的小型遊戲。我已經在很多小項目中使用了這種方法，並且效果很好。

您可以對該策略進行的改進是將您的遊戲資源用作實際繪圖操作的代理。例如，敵方實體可以通過它擁有的代表網格的資源對象推遲所有渲染;同樣適用於紋理/皮膚和效果。

我最近轉而將我的實體用作定義其行爲的接口的「啞」容器。玩家實體可能包含IMoveable，IControllable，IRenderable以及更多的接口，這些接口只是根據其包含的數據對該實體應用專門的操作。實體對此並不十分了解，並且在場景圖遍歷用於剔除/呈現時，所有執行都會發生。

Answer 2

MVC不一定非常適合遊戲。 MVC是爲傳統GUI而設計的，通常基於離散事件更新，而遊戲更像是仿真，其中不斷進行更新，演示需要立即反映。

儘管如此，你仍然沒有理由不再努力將狀態與演示分開。實體不需要知道如何繪製自己 - 這意味着他們知道渲染操作，這是不必要的 - 但應該可以問問他們如何看待此時間點，然後使用該信息渲染場景。例如。 2D實體應該能夠返回其當前動畫幀。或者3D實體應該能夠返回其三維網格，位置和方向。這裏不需要switch語句，只要您具有可以返回到渲染器的泛型表示形式即可。具有截然不同渲染算法的實體可能不得不在這一點上返回相當不同的對象。

Answer 3

通常我用繼承來解決這個問題。

例如，在我正在使用測試驅動開發編寫遊戲邏輯的一個項目中，通過手動測試渲染。下面這個C＃示例顯示了大概的想法。

class GameObjecet { 
    // Logic, nicely unit tested. 
} 

class DrawableGameObject : GameObject { 
    // Drawing logic - manual testing 
} 

這通常是我發現的最佳解決方案。這使得代碼可以被測試，而不會用諸如繪圖，模型加載等表示代碼來混淆遊戲邏輯......

Answer 4

這個問題在遊戲開發中經常出現，因爲各種工作室和組在新引擎上啓動。

簡而言之，它取決於遊戲實體的複雜程度。對於簡單的實體，它並不重要。

當你進入更復雜的實體時，你必須重新思考你的方法。一般來說，你會想要抵制擁有循環遍歷每個實體的uber循環的衝動，並調用一些更新/渲染/任何函數。除非每次更新，渲染或任何層次結構完全相同，否則這根本無法擴展。對於像幾何戰爭這樣的遊戲來說，這很好，但不適用於比這更復雜的任何事情。

你想要做的是給出最一般的實體集合提取特定於使用情況的遍歷。例如，如果你想渲染場景，你應該有一種方法來從實體集合中提取所有可渲染的實體，然後以一些任意的可按順序渲染它們。這同樣適用於物理，碰撞，AI等

一些有用的鏈接：

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/ http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf

我強烈建議兩者;首先進入構建遊戲實體出組件的設計原理，即渲染組件，物理組件，AI組件。第二個涉及各種遊戲實體方法的性能特徵。