基於混合組件的設計和模型視圖（ - 控制器）模式

Question

正在開發2D遊戲，我希望將遊戲引擎從圖形中分離出來。我決定用以下方式使用模型視圖模式：遊戲引擎擁有實現接口（敵人，子彈，爆炸）的遊戲實體（EnemyModel，BulletModel，ExplosionModel）。

視圖在創建實體時接收事件，獲取指向界面的指針：以這種方式，View只能使用界面方法（即詢問信息來執行繪圖），並且不能更改對象狀態。視圖有它的onw類（EnemyView，BulletView，ExplosionView），它擁有指向接口的指針。 （還有一個涉及事件的模式，以便模型可以通知視圖關於實體的變化，因爲純粹的查詢方法是不穩定的，但我不會在這裏討論它）。 *模型類使用編譯時組件方法：它們使用boost :: fusion庫來存儲不同的狀態組件，如PositionComponent，HealthComponent等等。

目前，視圖並不知道基於組件的設計，而只知道模型視圖部分：爲了獲得敵人的位置，它調用Enemy :: get_xy（）方法。實現接口的EnemyModel將此調用轉發給PositionComponent並返回結果。

由於子彈也有位置，我也必須將get_xy方法添加到Bullet中。 BulletModel然後使用與EnemyModel類相同的實現（即它轉發呼叫）。

這種認識會導致有很多重複的代碼：接口有很多類似的方法和*模型類充滿了前向方法。

所以我基本上有兩種選擇：

1）暴露的成分，它爲基礎的設計，使每個組件都有一個接口，以及：查看可以使用此接口直接查詢組件。它保持視圖和模型分離，只在組件級別而不是實體級別。

2）放棄模型視圖部分，進行純基於組件的設計：View只是一個組件（RenderableComponent部分），它基本上完全訪問遊戲引擎。

根據你的經驗，哪種方法最好？

Answer 1

我會給我兩美分的價值。從你描述的問題來看，在我看來，你需要一個抽象類來完成所有類中常見的操作（例如get_xy，它應該適用於子彈，敵人，爆炸等）。這個班級是一個完成基本工作的遊戲實體。繼承類可以覆蓋它，如果他們想要的話。

這個抽象類應該是所有接口的核心（幸運的是，你在C++中，類和抽象類和接口之間沒有物理差異）。因此，視圖將知道具體的接口，並且仍然有通用的實體方法。

我有一個經驗法則 - 如果不止一個類具有相同的數據成員或方法，它應該可能是它們繼承的單個類。

無論如何，暴露你的Model類的內部結構不是一個好主意。假設你想用別的東西替代增強？你不得不重寫整個程序，而不僅僅是相關的部分。

Answer 2

MVC對遊戲來說很不容易，因爲當遊戲變得更大時（包括菜單，敵人，關卡，圖形用戶界面......）和轉換，它會中斷。

組件或實體系統對於遊戲非常不錯。

作爲一個更簡單的情況，你可以考慮使用HMVC。您仍然會遇到轉換問題，但至少您的代碼將以更乾淨的方式組合在一起。你可能希望你坦克的代碼（渲染和邏輯）靠得很近。

Answer 3

已經有專爲基於代理的系統設計的演示架構，例如演示抽象控制。設計這樣一個系統的難點在於您最終最終會在代理之間進行硬連線的協作。

您可以這樣做，但不要使用OO繼承來模擬消息傳遞層次結構。你會後悔的。如果你仔細想想，你真的不想使用OO繼承關係，因爲定義的接口實際上只是對象可以響應的「函數記錄」。在這種情況下，您最好對通信協議進行正式建模。

如果您有任何問題，請詢問 - 這不是一個明顯的解決方案，容易出錯。