在整個系統中，如何在libgdx中將實體組件系統與舞台，組和演員一起用於游戲設計？

Question

實體組件系統能夠解決游戲開發中OO編程過程中可能出現的規模問題。 我對ECS的查詢很少：

概述一下：有些實體包含一些組件（具有數據）和系統，這些邏輯具有行走邏輯，戰斗邏輯等邏輯。因此，在任何游戲中，敵人都是一個實體，英雄是一個具有自己系統的實體等。 每個玩家/敵人成為一個實體。

1. 最初，我使用舞台，組和演員，舞台使用層次結構將事件傳遞給演員，並基於事件進行處理。 現在，當我擁有實體時，什么會成為我的新演員？ 每個實體都是演員嗎？ 如果是，那么在每個動作中，我將調用所有組件的update函數並繪制draw函數，對嗎？
2. 實體組件系統僅用於演員，還是應該用於舞台，團體，攝像機？ 如果應該全部使用，有人可以幫助您了解如何？

在OO中，很簡單，因為我在組中添加了演員，然后根據事件我執行適當的任務將事件傳輸到演員。 很抱歉，如果我缺少某些東西，因為在ECS中進行思考對我來說是新的。 我開始編寫代碼，但隨后在考慮整個系統時就感到困惑。 我知道如何為演員工作，但如何使其與小組，舞台，攝像機等一起工作。

Answer 1

實際上，這個問題無法回答，因為Stage實際上是某種實體系統本身。 Stage可以解釋為您的實體系統。 Group將是具有特定組成部分的所有實體，而Actors是您的實體。 一起使用Stage和自定義實體系統沒有多大意義。

某些技術/獨特事物（例如“ Camera根本不應建模為實體。 沒必要將所有內容都壓入實體系統中，而且最終也不會真正適合。

總之，您應該重新考慮為什么實際上需要實體組件系統。 這種編程風格背后的主要思想是通過將內存中的所有組件組合在一起來優化內存布局。 使用Java還是很困難的，因為您無法精確地控制對象的位置（就像在C ++中一樣）。 另一個動機是擁有可用於實體的抽象可重用組件，但實際上您也可以使用標准的OO實體層次結構來實現。 對於用於移動設備的小型游戲，您可能總會沒有足夠的實體，要真正感覺到性能上的顯着差異，我認為實體組件系統樣式並不適合任何地方。

如果仍要堅持下去，請不要使用Stage 。