Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

Entity Component System - iskustva

[es] :: C/C++ programiranje :: Entity Component System - iskustva

[ Pregleda: 976 | Odgovora: 0 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

glorius
Damir Nikolic
C++ developer
SR

Član broj: 4366
Poruke: 428
80.240.144.*

ICQ: 208550327


+14 Profil

icon Entity Component System - iskustva28.10.2016. u 13:41 - pre 40 meseci
Proucavam ovih dana ECS i svestan sam da se moze implementirati na kvadrilion nacina pa za pocetak moja implementacija i ne mora (a i verovatno nece) biti fleksibilna i genericka sto se, koliko razumeh, i ocekuje od dobrog ECS.
Ne zelim debatu oko toga da li je ovo optimalan sistem za pravljenje video igre/simulacije, to cu i sam provaliti kada ga naucim i uporedim sa prethodnim nacinom dizajna svojih igara (drz se OOP i ne pustaj), tako da, drzimo se ECS teme.

Generalno sam pohvatao dosta koncepata oko ECS ali neke stvari su mi malo mutne pa da ih navedem, mislim da ce diskusija biti korisna i za druge koji planiraju dizajniranje igara a ne koriste Unity :)

Kako uopste treba razmisljati o pravljenju System klasa u odnosu na postojece komponente?
Sigurno necu praviti za svaku komponenticu poseban sistem. Ili hocu??? Na koji nacin treba razmisljati kada se izgradjuju komponente i sistemi? RenderingSystem i RenderComponent su mi prilicno jasni, enkapsuliraj sve oko grafike (Sprite, Alpha, AnimationFrame, IsLoop, ...) u RenderComponent i ako postoji pointer na ovu klasu u Entity koji se trenutno procesira EntitySystemom, renderuj ga. Stvari se komplikuju kod drugih feature-ova igre. Ako imam Health komponentu i imam HealthSystem koji obradjuje Health, i sad zelim da dodam ManaComponent, po nekoj paradigmi ECS, dodacu novu komponentu i sistem ne dirajuci postojeci Health sistem iako su Health i Mana dovoljno slicni koncepti u ovom kontekstu da se mogu obradjivati u jednoj klasi (EnergySystem, npr.) posto bi ovaj sistem ispitivao da li je Health ili Mana dosla do kraja. Ocigledno da je ovakav nacin razmisljanja los tako da je verovatno oko ovoga razmisljati na drugi nacin. Na primer, CharacterProperties da bude komponenta koja sadrzi sve parametre Playera... Ni u klasicnom OOP dizajnu nije lako podeliti odgovornosti klasa ali je nekako mnogo lakse.

Nastavak RenderingComponent i RenderingSystem price:
E sada, zelim da se nesto desi kada AnimationFrame dodje do kraja animacije, npr, zavrsila se animacija otvaranja poluge, Door objekat treba da se 'baci' u State OPENING. Koji sistem ovo obradjuje, ako je odgovor AnimationSystem, to mi zvuci kao ok ideja, a gde se ovde, the heck, salju notifikacije vratima da treba da se otvore na AnimationEnded event kod AnimationComponent? U proslim dizajnima sam koristio observer pattern ali ne znam kako Observer ovde 'uglaviti'? Tako da stizemo do...

Komunikacija izmedju objekata.

Ovaj deo mi je potpuno nejasan. Ok, event nastaje kada se neki podatak Component promeni ali ko tu salje event i kome? Neka ideja je da podaci komponente budu Property objekti koji salju event kada se pozove operator= ali, opet, verujem da to nije tako zamisljeno u originalnim konceptima ECS jer su Components plane data klase.

Do sada sam shvatio da je sustinska korist od ovog ECS to sto preferira kompoziciju a ne nasledjivanje da bi se izbegla staticka priroda nasledjivanja i omogucilo pravljenje objekata dinamicki gde se komponente mogu ponovo iskoristiti (npr. default RenderingComponent i RenderingSystem ne bi morale da se customizuju za vecinu objekata u igri). Jos kada dodamu tu i Decorator pattern ceo sistem se dize na jos visi nivo. Lepo sve zvuci ali spomenuti problemi i slabo kapiranje sustine ideje ne dozvoljavaju dalje napredovanje...
EOF
 
Odgovor na temu

[es] :: C/C++ programiranje :: Entity Component System - iskustva

[ Pregleda: 976 | Odgovora: 0 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.