Entitás-komponens-rendszer

Az entitás-komponens-rendszer (ECS) egy architekturális minta, amit többnyire játékfejlesztésben használnak. A minta az inkább aggregáció, mint öröklődés elvét, ami nagyobb rugalmasságot enged meg, ahol minden jelenetben minden objektum önálló entitás, mint például ellenség, muníció, közlekedési eszközök. Minden entitás egy vagy több komponensből áll, amelyek plusz funkcionalitást vagy viselkedést adnak. Egy entitás viselkedése futás időben megváltoztatható komponensek hozzáadásával vagy elvételével (lásd stratégia programtervezési minta), továbbá kiküszöböli a jojó-effektust, azaz a túl mély és terebélyes öröklődési körmentes gráfot, amit túl nehéz megérteni, karbantartani és kiterjeszteni. Az általános megközelítéseket gyakran kombinálják adatorientált fejlesztéssel.

Története

Az 1998-ban megjelent Thief: The Dark Project az első, amiről azt írták, hogy használja az entitás-komponens-rendszer mintát, habár technikai részleteket nem fedtek fel.

A 2002-ben megjelent Dungeon Siege az első játék, amiről nyíltan közölték, hogy a mintát használta. Erről Scott Bilas még abban az évben beszélt a GDC-nek. A beszéd explicit említi a később szabvánnyá vált koncepciókat: adatbázis a kompozícióhoz, a séma adatvezérlése, komponensek mint önmagukat tartalmazó itemek, és más elképzelések.

2007-ben az Operation Flashpoint: Dragon Rising csapata kísérletezett az entitás-komponens-rendszer szerinti tervvel, azzal is, amit a Bilas/Dungeon Siege inspirált. Adam Martin később részletesen leírta az architektúrát, terminológiával és fogalmakkal. A cikk népszerűsítette a rendszer ideáját, mint első rangú osztály elemet, továbbá szerepeltek entitások mint azonosítók, komponensek mint nyers adatok, és a kódot a rendszerek tárolják, nem a komponensek vagy entitások.

Az Unity játékmotornak megugrott a népszerűsége 2008-2010-ben. Ezzel az entitások és komponensek is ismertekké váltak, és széles körben használni kezdték őket. Azonban az Unity nem adott nevet a tervmintának, így entitás-komponens-rendszeren azt értették, amit Bilas írt le.

2015-ben az Apple bevezette a GameplayKitet, ami egy API az iOS, macOS és tvOS operációs rendszereken végzett játékfejlesztés számára. Ezek már tartalmazták a minta megvalósítását is. Habár nem vesz tudomást a grafikus motorról, ami rendereli a játékot, tartalmaz támogatást az Apple által fejlesztett SpriteKit, SceneKit és the Xcode Scene Editor motorokhoz.

Elemek

A minta elemeinek nevei Martin szóhasználatát követi, amit sokan átvettek:

• Entitás: Az entitás egy általános célú objektum. Rendszerint csak egy egyértelmű azonosítóból áll. Minden durvaszemcsés játékobjektumot külön itemként jelölnek meg. Általában egyszerűen egy integer.
• Komponens: Az objektumok egyik aspektusának nyers adatai és interakciói. Az entitás megcímkézi, amikor ezt az aspektust birtokolja. Többnyire rekorddal, osztállyal vagy asszociatív tömbbel valósítják meg.
• Rendszer: Minden rendszer folyamatosan fut, és mindegyiknek saját privát szála van. Globális akciókat végeznek az azonos aspektusú komponenseket birtokló entitásokkal.

Példa

Tegyük fel, hogy van egy rajzoló függvény. Ez egy rendszer, ami végigiterál azokon az entitásokon, amiknek látható és fizikai komponensei vannak, és kirajzolja őket. A látható komponens tartalmazza, hogy mit kell kirajzolni, a fizikai pedig azt, hogy hova. Embert, szörnyet, nyílvesszőt, de láthatatlan embert nem.

Egy másik rendszer foglalkozik az összeütközés detektálásával. A fizikai komponenseken halad végig, nem törődve a kirajzolással. Ez veszi észre, ha nyilak találják el a szörnyet, és gondoskodik arról, hogy meghívódjanak az ütközés eseményére reagáló függvények, amik eldöntik, hogy mi történik.

Egy harmadik rendszer foglalkozik az egészséggel és az életerővel. Ez azokkal az objektumokkal foglalkozik, amiknek van egészsége, tehát emberrel, szörnnyel igen, de nyíllal nem. Reagál azokra az eseményekre, amelyek megváltoztatják az egészséget, például ha nyílvesszők találták el az objektumot, vagy megivott egy gyógyitalt. Végigiterál azokon az objektumokon, amelyeknek van egészségük, és bevezeti a változásokat, ha kell.

Entitások tervezése

Az entitások azonosítóból és egy komponenseket tárolóból állnak. Az alapötlet az, hogy ne legyenek játékmetódusok az entitásokba ágyazva. A tárolónak nem kell fizikailag ott lennie, ahol az azonosítónak, de könnyen elérhetőnek kell lennie.

Általában minden entitásnak egyértelmű azonosítója van. Ez több előnnyel jár:

• Az entitás pointer helyett hivatkozható azonosítójával. Ez robosztusabb, mivel nem kell külön törődni a csellengő pointerekkel az objektum törlésekor.
• Megkönnyíti az állapot kimentését. Visszaállításkor nem kell pointereket visszaállítani.
• Az adatokat ott lehet tárolni a memóriában, ahol éppen célszerű.
• Hálózaton keresztül is megtalálhatók az entitások azonosítójuk segítségével.

Az előnyök egy része okos pointerekkel is elérhető.

Előnyök

Ez az architektúra nagyon biztonságosan és egyszerűen kezeli a függőségeket. Maguk a komponensek egyszerű adattárak, nincsenek közvetlen függőségeik. Minden rendszerbe regisztrálni kell azokat a komponenseket, amikkel egy entitásnak bírnia kell ahhoz, hogy kezelje őket. A rendszer minden entitást végigjár, és ami bír az adott komponenssel, azt kezeli. Ha nem, akkor átugorja. Ezzel ki vannak küszöbölve a terebélyes függőségi körmentes gráfok. Azonban az egymástól függetlenül működő rendszerek kezelhetik ugyanazt a komponenst, így hibát okozhatnak egymás működésében.

Az architektúra öröklődés helyett kompozíciót használ. Egy entitás tipikusan egy azonosítót tartalmaz, és egy adatszerkezetet komponensekkel. Egy újabb objektum úgy hozható létre, hogy egy új azonosítóhoz hozzáadjuk a megfelelő komponenseket. Ez megkönnyíti kiegészítők készítését, amikben az egyes objektumok átalakításához hozzáadnak vagy elvesznek komponenseket, vagy új komponenseket vezetnek be az új objektumokhoz, és ezzel nem okoznak függőségi problémát. Például hozzáadhatnak egy új varázslatot, amitől a játékos felveszi egy lövedéknek azt a tulajdonságát, hogy kárt okoz abban, amibe beleszalad.

Hátrányok

A rendszerek közötti kommunikáció normális módja az, hogy a rendszerek komponensekben tárolják az adatokat. Például a pozíciót egy rendszer tartja karban, de több más rendszer is használja, például a grafikai, aminek azért kell, hogy a megfelelő helyre rajzolja az objektumot.

Ha sok különböző ritka esemény van, akkor egy vagy több komponens tartalmaz hozzájuk logikai adatot. A rendszerek minden iterációban megvizsgálják ezeket, de mivel csak ritkán változnak, a hatékonyság romlik. Ekkor a megoldás a figyelő programtervezési minta lenne, amire feliratkoznának az események. Ekkor a rendszereknek elég akkor végigiterálniuk, ha a figyelő üzen.

Naiv megvalósításokban minden rendszer végigiterál az összes entitáson, és kiválasztja azokat, amikre reagál. Ha sok az entitás, vagy sok a rendszer, akkor a költségek túl nagyra nőhetnek. Más megvalósítások ezt úgy kerülik ki, hogy egyes komponensek helyett listákban tárolják a megfelelő entitásokat. Ha egy entitás új komponenst kap, vagy elveszt egyet, akkor bekerül egy másik listába is, vagy kikerül egy listából. Ezzel az egész sokkal hatékonyabbá válik, ami a sebességben is megnyilvánul.

Források

• Anatomy of a knockout
• Evolve Your Hierarchy
• Entity Systems Wiki
• Component - Game Programming Patterns
• Component Based Engine Design
• ECS design to achieve true Inversion of Flow Control

Fordítás

Ez a szócikk részben vagy egészben az Entity–component–system című angol Wikipédia-szócikk fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.