摘要

游戲編程設(shè)計(jì)和組織是困難而復(fù)雜的，為了簡(jiǎn)化開發(fā)進(jìn)程，會(huì)使用被稱為游戲引擎的游戲框架(framework)，該框架包含了一組實(shí)用工具。本項(xiàng)的目的是探索游戲引擎設(shè)計(jì)和開發(fā)一個(gè)模塊化和可擴(kuò)展的游戲引擎。本文中的設(shè)計(jì)是面向?qū)ο?OOP)的以及兩個(gè)實(shí)體組件系統(tǒng)(ECS)。OOP設(shè)計(jì)常用于計(jì)算機(jī)科學(xué)，使用對(duì)象層次來共享函數(shù)功能，ECS設(shè)計(jì)基于繼承之上的組合的概念，ECS中對(duì)象包含特性而不是繼承它們(特性)。然而，設(shè)計(jì)都有它們的弱點(diǎn)，例如OOP設(shè)計(jì)中的可擴(kuò)展性問題，該問題來自于層次結(jié)構(gòu)的緊耦合性，在層次結(jié)構(gòu)的根附近進(jìn)行的更改需要進(jìn)行有效的代碼重構(gòu)。ECS解決了耦合問題，然而，問題存在于跨系統(tǒng)通信和共享組件。使用了兩個(gè)ECS設(shè)計(jì)來解決這個(gè)問題，分別是Cupcake 和 Artemis。通過一個(gè)簡(jiǎn)單的游戲應(yīng)用來測(cè)試和分析設(shè)計(jì)的功能性。結(jié)合使用Cupcake 和 Artemis的優(yōu)點(diǎn)，本該提出了一個(gè)能最小化架構(gòu)問題的新ECS設(shè)計(jì)。

1 介紹

游戲開發(fā)是一個(gè)復(fù)雜的進(jìn)程，它可能需要圖形、聲音、物理、網(wǎng)絡(luò)、AI以及輸入，一個(gè)常見的實(shí)踐是使用已經(jīng)實(shí)現(xiàn)一種技術(shù)的現(xiàn)有的庫來節(jié)省時(shí)間和精力。即便如此，將幾種技術(shù)結(jié)合到一個(gè)系統(tǒng)中可能也是一項(xiàng)艱巨的任務(wù)。游戲引擎通過提供制作游戲所需的框架和技術(shù)解決了這個(gè)問題。這使得游戲開發(fā)者可以跳過技術(shù)的實(shí)現(xiàn)來專注于游戲開發(fā)。

開發(fā)游戲引擎時(shí)遇到的最大問題是如何表示游戲?qū)ο?，游戲?qū)ο罂梢詮臎]有控制或交互的簡(jiǎn)單2D圖像到具有控制、聲音、動(dòng)畫和AI的異常復(fù)雜3D對(duì)象。在概念上，l很容易將游戲?qū)ο罄斫鉃楸硎居螒蛑芯哂卸鄠€(gè)功能的實(shí)體。

當(dāng)試圖組織一個(gè)能夠處理特性組合的體系結(jié)構(gòu)時(shí)，問題就出現(xiàn)了。

一種常見的方法是使用面向?qū)ο蟮木幊?OOP)體系結(jié)構(gòu)，然而，由于繼承和層次結(jié)構(gòu)的本質(zhì)，在表示游戲?qū)ο髸r(shí)出現(xiàn)了困難。作為解決面向?qū)ο蟮挠螒驅(qū)ο髥栴}的答案，實(shí)體組件系統(tǒng)(ECS)變得非常流行。

本文將討論OOP的缺點(diǎn)、ECS的優(yōu)點(diǎn)、ECS的變體，并提出一種更加模塊化的ECS設(shè)計(jì)。

2 面向?qū)ο缶幊?OOP)

面向?qū)ο缶幊淌且环N可重用和模塊化的程序設(shè)計(jì)，它將信息表示為包含數(shù)據(jù)和邏輯的對(duì)象。面向?qū)ο蟮囊粋€(gè)獨(dú)特而實(shí)用的特點(diǎn)是繼承，這允許架構(gòu)創(chuàng)建共享特性和結(jié)構(gòu)的層次結(jié)構(gòu)，這有助于促進(jìn)代碼重用和組織。

游戲?qū)ο蟮膶哟谓Y(jié)構(gòu)會(huì)是什么樣子？OOP聽起來正是游戲引擎需要的代碼重用和組織。圖1是一個(gè)表示車輛和花盆的層次結(jié)構(gòu)的示例。當(dāng)路徑如前面所示一樣簡(jiǎn)單時(shí)，這就可以實(shí)現(xiàn)，然而，當(dāng)游戲?qū)ο箝_始共享功能時(shí)，問題就出現(xiàn)了。

2.1 OOP的問題

當(dāng)涉及到層次結(jié)構(gòu)中的共享特性時(shí)，設(shè)計(jì)架構(gòu)就變得非常困難。圖1對(duì)于帶有聲音的靜態(tài)對(duì)象或者帶有聲音和控件(比如播放器外觀)的非渲染對(duì)象會(huì)發(fā)生什么變化?圖2顯示了添加了游戲?qū)ο蟮臐撛趯哟谓Y(jié)構(gòu)樹，我們的樹開始在特征和路徑上顯示冗余。添加到游戲?qū)ο蟮墓δ芙M合越多，層次結(jié)構(gòu)就會(huì)變得越復(fù)雜，這使得代碼難以管理和組織。

圖2-冗余的OOP層次結(jié)構(gòu)

這種復(fù)雜層次結(jié)構(gòu)的一個(gè)主要問題是處理游戲?qū)ο?，很難創(chuàng)建一個(gè)函數(shù)來接受持有特定功能的各種類型的游戲?qū)ο?。諸如函數(shù)重載之類的解決方案很難維護(hù)，因?yàn)榘囟üδ艿拿糠N類型的對(duì)象都需要自己的函數(shù)。這將強(qiáng)制所有不同組合使用非直觀的層次結(jié)構(gòu)或代碼重用。

這個(gè)復(fù)雜層次結(jié)構(gòu)的更糟糕的問題是可擴(kuò)展性，每個(gè)子類都在很大程度上依賴于父類的結(jié)構(gòu)。如果沒有大規(guī)模的代碼重構(gòu)，添加新特性或更改當(dāng)前特性可能是困難的，也可能是不可能的。

3 實(shí)體組件系統(tǒng)

繼承之上的組合是解決面向?qū)ο蟮膶哟谓Y(jié)構(gòu)問題的一種方法。這個(gè)概念通過組合而不是繼承來增加功能，使系統(tǒng)更加模塊化和獨(dú)立。例如，使用ECS，車輛對(duì)象包含用于聲音或控制等特性的對(duì)象，而不是創(chuàng)建層次結(jié)構(gòu)鏈。這使得車輛對(duì)象更具動(dòng)態(tài)性，因?yàn)楦奶匦跃拖裉砑踊騽h除對(duì)象一個(gè)簡(jiǎn)單，而不需要主要代碼的重構(gòu)。

3.1 架構(gòu)

ECS由三個(gè)基本部分組成：實(shí)體、組件和系統(tǒng)。實(shí)體是與對(duì)象關(guān)聯(lián)的唯一id，組件是表示實(shí)體信息的數(shù)據(jù)，系統(tǒng)在實(shí)體上運(yùn)行邏輯，以利用或更改來自組件的數(shù)據(jù)。

在游戲開發(fā)中，游戲?qū)ο蟊划?dāng)作實(shí)體，功能被表示為組件和系統(tǒng)。這可以看作是一個(gè)數(shù)據(jù)庫，其中實(shí)體是惟一的id，系統(tǒng)是數(shù)據(jù)庫表，組件是數(shù)據(jù)庫表中的數(shù)據(jù)。

圖3-ECS中的游戲?qū)ο?/p>

圖3顯示了游戲?qū)ο笤贓CS體系結(jié)構(gòu)中的樣子。車輛與一個(gè)惟一的id關(guān)聯(lián)。使用這個(gè)惟一的id，調(diào)用者通過創(chuàng)建與所需特性關(guān)聯(lián)的組件來附加特性。這允許系統(tǒng)使用組件中提供的數(shù)據(jù)處理實(shí)體和應(yīng)用動(dòng)作。

3.2 優(yōu)點(diǎn)

ECS體系結(jié)構(gòu)的優(yōu)點(diǎn)在于它是獨(dú)立的，每個(gè)組件只不過是簡(jiǎn)單的數(shù)據(jù)點(diǎn)，因此本質(zhì)上是與其他組件隔離的。系統(tǒng)需要特定的組件來運(yùn)行其邏輯，這使得系統(tǒng)相對(duì)解耦，因?yàn)閷?shí)體中包含的不同組件的數(shù)量不會(huì)改變系統(tǒng)解釋實(shí)體的方式。只要滿足組件需求，系統(tǒng)就會(huì)在實(shí)體上運(yùn)行其邏輯。

圖4-實(shí)體組件系統(tǒng)(ECS)

圖4顯示了以前層次結(jié)構(gòu)轉(zhuǎn)換為ECS的設(shè)計(jì)。關(guān)于渲染系統(tǒng)，花盆和揚(yáng)聲器有什么不同？渲染系統(tǒng)是否關(guān)心揚(yáng)聲器是否有聲音組件?向屏幕渲染對(duì)象是否需要聲音組件？這是ECS系統(tǒng)如何提高隔離性和強(qiáng)化代碼組織的一個(gè)例子。一個(gè)簡(jiǎn)單的表格可以用來查看游戲?qū)ο蟀男┕δ?，而不是遵循一個(gè)復(fù)雜且長(zhǎng)樹。

圖5-添加功能的ECS

ECS架構(gòu)的另一個(gè)好處是系統(tǒng)的模塊化和可擴(kuò)展性。由于系統(tǒng)和組件是相對(duì)獨(dú)立的，所以很容易添加新特性。例如，向花盆中添加聲音與添加聲音組件一樣簡(jiǎn)單。添加諸如爆炸之類的新特性可以與創(chuàng)建新系統(tǒng)和組件一樣簡(jiǎn)單。更新的圖5顯示了新特性如何對(duì)引擎的總體結(jié)構(gòu)產(chǎn)生較低的影響。

3.3 缺點(diǎn)

雖然ECS系統(tǒng)可以解決OOP帶來的一些問題，但是它們有自己的一些問題，隔離和獨(dú)立是ECS系統(tǒng)的正反兩面。當(dāng)設(shè)計(jì)需要共享組件和跨系統(tǒng)通信時(shí)，就會(huì)出現(xiàn)負(fù)面影響。

共享組件的問題是包含關(guān)系和處理順序，該概念促進(jìn)系統(tǒng)耦合，這與ECS的隔離設(shè)計(jì)背道而馳。根據(jù)設(shè)計(jì)，共享組件的位置是不確定的，此外，處理實(shí)體的順序可能是至關(guān)重要的。例如，在引擎中的移動(dòng)、碰撞和渲染，流程順序?qū)⒏目梢姷慕Y(jié)果。例如，移動(dòng)、碰撞和渲染的順序可以創(chuàng)建這樣一種情況：由于尚未處理碰撞，對(duì)象將會(huì)穿透墻壁。

跨系統(tǒng)通信是ECS的另一個(gè)難點(diǎn)?？缦到y(tǒng)通信對(duì)于事件發(fā)生這一情況是必要的。例如，一個(gè)球與地面相撞時(shí)應(yīng)該發(fā)出噪音。ECS的問題是碰撞和聲音系統(tǒng)是不同的，彼此是隔離的。解決這個(gè)隔離問題的兩種方法是向組件添加狀態(tài)或?qū)崿F(xiàn)消息傳遞系統(tǒng)。無論哪種方式，設(shè)計(jì)一種方法在保持系統(tǒng)獨(dú)立的同時(shí)連接它們都是困難的。

4 CUPCAKE ECS

CUPCAKE ECS架構(gòu)被設(shè)計(jì)成一個(gè)模塊化的ECS系統(tǒng)，其目標(biāo)是在不影響架構(gòu)的情況下方便地添加或刪除系統(tǒng)。這就要求系統(tǒng)之間是完全獨(dú)立的，永遠(yuǎn)不要使用或引用任何其他系統(tǒng)。理想情況下，這將創(chuàng)建一個(gè)用戶可以插入和添加新特性的引擎，并有望提高代碼重用度和用戶之間的共享。

用戶如何使用Cupcake的一個(gè)例子是從基本ECS框架開始。這將包括管理系統(tǒng)、實(shí)體的實(shí)用工具，以及創(chuàng)建新系統(tǒng)和組件的框架。接下來，用戶將從插件(系統(tǒng))列表中選擇所需的功能。例如，用戶可以選擇一個(gè)功能列表，如聲音的FMOD, 3D渲染的OpenGL, 物理的Bullet。最后，安裝腳本將插件和框架編譯成靜態(tài)庫和一組頭文件。結(jié)果將是一個(gè)高度可定制的、特定于用戶的引擎。

4.1 架構(gòu)

Cupcake架構(gòu)分為幾個(gè)部分：引擎、管理器和系統(tǒng)。圖6顯示了Cupcake的基本架構(gòu)。引擎是所有系統(tǒng)、管理器和實(shí)體的頂層接口，它負(fù)責(zé)運(yùn)行游戲循環(huán)和管理系統(tǒng)和實(shí)體。該引擎通過提供添加和刪除附加實(shí)體來管理實(shí)體，同時(shí)為每個(gè)實(shí)體維護(hù)一個(gè)惟一的id，通過提供正在處理的系統(tǒng)和空閑系統(tǒng)兩個(gè)列表來管理系統(tǒng)，正在處理中的系統(tǒng)由引擎游戲循環(huán)進(jìn)行處理。

圖6-Cupcake架構(gòu)

系統(tǒng)負(fù)責(zé)管理組件和實(shí)現(xiàn)幾種抽象方法。抽象方法包括init、release和update(用于正在處理的系統(tǒng))。使用于FOD播放聲音的系統(tǒng)的一個(gè)例子，是一個(gè)包含聲音和位置的組件列表的系統(tǒng)。init函數(shù)將初始化FMOD庫文件，release函數(shù)將釋放所有與系統(tǒng)綁定的資源，如組件和FMOD庫。update函數(shù)用于更新移動(dòng)對(duì)象的聲音位置。

4.2 Cupcake 方案

Cupcake包含與任何具有共享組件和跨系統(tǒng)通信的ECS系統(tǒng)相同的通用問題。為了解決共享組件的問題，Cupcake在引擎外部有一個(gè)外部組件集。這些外部組件在創(chuàng)建時(shí)被傳遞給系統(tǒng)，這允許多個(gè)系統(tǒng)之間具有相同的組件集，而不需要任何方法來保持?jǐn)?shù)據(jù)的同步。此外，它還保持了系統(tǒng)之間的獨(dú)立性。共享組件的一個(gè)例子是渲染和物理系統(tǒng)的位置，通過引用相同的組件列表，物理系統(tǒng)對(duì)位置所做的任何更改都將自動(dòng)用于渲染。

采用外部消息系統(tǒng)解決了系統(tǒng)間的交叉通信問題。此消息傳遞系統(tǒng)由句柄、觸發(fā)器和消息組成。觸發(fā)器是針對(duì)特定條件在每個(gè)循環(huán)中執(zhí)行的一段邏輯，根據(jù)這些條件，將向消息系統(tǒng)發(fā)送一條消息。消息句柄是為系統(tǒng)創(chuàng)建的對(duì)象，用于消息捕獲和基于消息的邏輯執(zhí)行。例如，一個(gè)玩家的移動(dòng)需要三個(gè)部分，基于玩家輸入執(zhí)行的觸發(fā)器，當(dāng)觸發(fā)器注冊(cè)了一個(gè)玩家輸入(事件)時(shí)，它將向系統(tǒng)發(fā)送適當(dāng)?shù)膍ove消息，比如向前移動(dòng)，然后，這個(gè)向前移動(dòng)的消息句柄被物理系統(tǒng)捕獲，然后物理系統(tǒng)將被調(diào)用，根據(jù)該句柄移動(dòng)玩家。

4.3 分析

Cupcake系統(tǒng)通過提高系統(tǒng)的獨(dú)立性和采用數(shù)據(jù)驅(qū)動(dòng)架構(gòu)，保持了實(shí)體組件系統(tǒng)的基礎(chǔ)本質(zhì)。解決常見ECS問題的方法是有效的，但是還有改進(jìn)的余地。

共享組件是解決共享數(shù)據(jù)問題的一個(gè)相對(duì)簡(jiǎn)單的解決方案。外部共享組件的問題是包含共享組件的內(nèi)容的模糊表示。除非明確指示，否則不清楚調(diào)用者應(yīng)該在何處生成或獲取共享組件。通過要求調(diào)用者被指示這個(gè)外部列表應(yīng)該從哪里來，暴露了一個(gè)脆弱的設(shè)計(jì)。它允許調(diào)用者為相同的組件創(chuàng)建重復(fù)列表，這將達(dá)不到共享組件的目的。

事實(shí)證明，外部消息傳遞系統(tǒng)工作得相對(duì)較好。消息傳遞系統(tǒng)的外部性有助于提高系統(tǒng)獨(dú)立性，并允許調(diào)用者定制消息的行為。外部消息傳遞系統(tǒng)的問題在于其與引擎的集成性較弱，創(chuàng)建一個(gè)關(guān)于如何處理跨系統(tǒng)通信的標(biāo)準(zhǔn)會(huì)更有用。通過將消息傳遞集成到引擎中，系統(tǒng)更有可能圍繞標(biāo)準(zhǔn)消息傳遞系統(tǒng)進(jìn)行設(shè)計(jì)。

最后，Cupcake的一個(gè)缺陷是引擎中去除了實(shí)體。由于組件存儲(chǔ)在系統(tǒng)中，所以沒有簡(jiǎn)單的方法可以從系統(tǒng)中刪除實(shí)體。調(diào)用者必須手動(dòng)地從各個(gè)系統(tǒng)中釋放組件來刪除實(shí)體。這就留下了一個(gè)問題––允許在設(shè)計(jì)系統(tǒng)時(shí)不實(shí)現(xiàn)在特定實(shí)體上釋放數(shù)據(jù)的函數(shù)。

5 ARTEMIS ECS 框架

由Gamadu創(chuàng)建的Artemis ECS框架是為游戲開發(fā)而設(shè)計(jì)的，該設(shè)計(jì)與Cupcake很相似。實(shí)體是惟一的id，組件是數(shù)據(jù)，系統(tǒng)使用數(shù)據(jù)來處理邏輯。Artemis框架最初是用Java編寫的，但是本文將使用C來適配Artemis框架，從Java到C，有幾個(gè)特性沒有實(shí)現(xiàn)，所以該分析只對(duì)C++而而言是準(zhǔn)確的。

5.1 架構(gòu)

Artemis框架包含一個(gè)中心化的World對(duì)象，該對(duì)象是這個(gè)框架的接口。World對(duì)象包含所有manager并運(yùn)行游戲循環(huán)，此框架中使用的manager用于系統(tǒng)、實(shí)體、組(group)和標(biāo)記(tag)。系統(tǒng)和實(shí)體的manager類似于Cupcake，它們用于管理實(shí)體或系統(tǒng)。組和標(biāo)記管理器是簡(jiǎn)單的系統(tǒng)，用于將實(shí)體組織在一起并向特定實(shí)體添加標(biāo)記，通過將一些字符串關(guān)聯(lián)到一組實(shí)體或單個(gè)實(shí)體來實(shí)現(xiàn)的。

Artemis中的實(shí)體管理器是惟一的，因?yàn)樗鼘⑺薪M件存儲(chǔ)在引擎中，這是通過一個(gè)二維數(shù)組完成的，其中第一個(gè)標(biāo)識(shí)符是組件類型，第二個(gè)標(biāo)識(shí)符是實(shí)體id。實(shí)體管理器還為每個(gè)活動(dòng)實(shí)體管理惟一的id。

Artemis中的系統(tǒng)要管理需要處理的實(shí)體列表，這是通過為每個(gè)組件類型分配標(biāo)識(shí)符來實(shí)現(xiàn)的。使用組件類型，系統(tǒng)可以通過過濾只處理有效的實(shí)體。為了訪問數(shù)據(jù)，調(diào)用者必須創(chuàng)建組件mapper，以便從實(shí)體管理器獲取組件。

5.2 分析

Artemis有一個(gè)獨(dú)特的解決方案來解決共享組件問題,通過將組件附加到實(shí)體管理器，這使得所有系統(tǒng)都可以訪問組件，這也使得組件在使用它們的系統(tǒng)之間自動(dòng)同步。此外，它還消除了誰包含共享組件的歧義問題，因?yàn)樗薪M件都存儲(chǔ)在同一個(gè)位置。這在調(diào)用者需要?jiǎng)h除實(shí)體時(shí)非常有用，因?yàn)閷?shí)體管理器可以搜索組件列表并刪除與實(shí)體關(guān)聯(lián)的所有數(shù)據(jù)。

Artemis的一個(gè)問題是缺乏跨系統(tǒng)的通信，系統(tǒng)之間唯一共享的是可以用作消息的組件。然而，由于創(chuàng)建和刪除組件的開銷很大，因此這可能是一種開銷很大的消息傳遞方法。

最后，Artemis最大的限制是組件和系統(tǒng)類型的限制，與組件和系統(tǒng)關(guān)聯(lián)的惟一id是用位(bit)完成的，比特?cái)?shù)被限制在32個(gè)，這就產(chǎn)生了一個(gè)問題，當(dāng)用戶超過組件或系統(tǒng)限制時(shí)，過濾就會(huì)失效。新組件分配了未定義的類型，這樣就允許將無效實(shí)體傳遞給系統(tǒng)(譯注：言外之意是有問題的)。

6 提出的架構(gòu)

本文提出的ECS系統(tǒng)架構(gòu)是Cupcake和Artemis的結(jié)合，Cupcake解決了跨系統(tǒng)通信問題，并保持了系統(tǒng)的獨(dú)立性。通過在實(shí)體管理器中本地化所有組件，Artemis解決了共享組件的問題。這兩種技術(shù)的結(jié)合解決了ECS的問題，同時(shí)保持了模塊化。

6.1 架構(gòu)

這個(gè)架構(gòu)像Cupcake和Artemis將有一個(gè)中心接口對(duì)象稱為引擎(engine)，引擎將負(fù)責(zé)管理器和游戲循環(huán)。引擎所包含的管理器是系統(tǒng)、實(shí)體、資源和消息。引擎還負(fù)責(zé)使用系統(tǒng)管理器處理“正在處理的系統(tǒng)”的每個(gè)游戲循環(huán)。

圖7-引擎對(duì)象

系統(tǒng)和實(shí)體管理器的工作方式與Artemis相同，其中組件存儲(chǔ)在實(shí)體管理器中。組件類型將具有唯一id，以便允許系統(tǒng)過濾組件類型，通過使用組件id，系統(tǒng)可以創(chuàng)建具有適當(dāng)組件的有效實(shí)體列表并處理它們。

新增的資源管理器存儲(chǔ)組件可能共享的信息。對(duì)象的mesh是多個(gè)組件共享數(shù)據(jù)的一個(gè)例子，例如，如果游戲中存在50個(gè)相同的敵人，那么為每個(gè)實(shí)體創(chuàng)建重復(fù)的mesh數(shù)據(jù)將會(huì)非常昂貴。資源管理器將處理在實(shí)體之間共享完全相同數(shù)據(jù)這一理想情況。

消息管理器將負(fù)責(zé)跨系統(tǒng)通信，與Cupcake一樣，它將由調(diào)用者創(chuàng)建的處理程序(handler)組成，這些處理程序捕獲消息并在系統(tǒng)中執(zhí)行邏輯。系統(tǒng)將負(fù)責(zé)向消息處理程序發(fā)送消息，而不是觸發(fā)器。

7 使用ECS的項(xiàng)目

在這個(gè)項(xiàng)目中，實(shí)現(xiàn)了兩個(gè)不同的ECS系統(tǒng)，并在一個(gè)簡(jiǎn)單的游戲環(huán)境中使用。Cupcake引擎是用C編寫的，用于測(cè)試應(yīng)用程序Cron。使用基于Artemis框架的C開發(fā)了用于CPE 476項(xiàng)目Carrota的引擎。

7.1 Cron

圖8-Cupcake測(cè)試應(yīng)用

開發(fā)Cupcake引擎時(shí)，創(chuàng)建了一個(gè)測(cè)試應(yīng)用程序來測(cè)試引擎的功能。圖8顯示了示例測(cè)試應(yīng)用程序。球體代表玩家，用戶可以在其中使用控件移動(dòng)對(duì)象。此外，位置音頻是基于球的位置。這些立方體代表了物理作用于它們的測(cè)試對(duì)象，它們播放恒定的音頻。這是用來確保3D音頻正常工作。

7.2 Carrota

圖9-Carrota兔子

圖10-Carrota商店菜單

圖11-Carrota甜甜圈

利用Artemis框架為CPE 476項(xiàng)目開發(fā)了ECS引擎，使用該引擎創(chuàng)建一個(gè)FPS防御游戲。該引擎的特性包括:2D/3D/文本呈現(xiàn)、聲音、碰撞、物理、動(dòng)畫、framebuffer對(duì)象和陰影，其中每個(gè)功能都是相對(duì)獨(dú)立。

8 未來的工作

在未來的工作中，將提出的ECS方案繼續(xù)發(fā)展和完善，首先構(gòu)建框架，然后實(shí)現(xiàn)功能。希望能夠?qū)崿F(xiàn)支持3D渲染和實(shí)時(shí)圖形的功能，最終目標(biāo)是創(chuàng)建一個(gè)冗長(zhǎng)的框架，其中包含多個(gè)可以跨引擎共享的特性。

參考文獻(xiàn)

• [1] Entity-Component-System-Revisited, http://flohofwoe.blogspot.com/2013/07/entity- component-system-revisited.html?m=1: July 6th, 2013.
• [2] Randy Gaul, Component Based Engine Design, http://www.randygaul.net/2013/05/20/component- based-engine-design/: May 20th, 2013.
• [3] Ted Brown, Fast Entity Component System, http://www.openprocessing.org/sketch/18023: January 18th, 2011.
• [4] Bob Nystrom, Component, http://gameprogrammingpatterns.com/component.html
• [5] Gamadu, Artemis Entity System Framework, http://gamadu.com/artemis/
• [6] Alec Thomas, EntityX, https://github.com/alecthomas/entityx/tree/master/entityx: May 15th, 2014.
• [7] Entity System Wiki, http://entity-systems.wikidot.com/

翻譯原文：
https://pdfs.semanticscholar.org/829b/9107c32bb20965400d22a6dad14f56b9b7b5.pdf