Unity -ben ha egy scripten belül hozok létre egy gyűjtő listát objektumokról/példányokról, és azt hívom meg az egyedi példányoknál, akkor közös referenciaként lesz használatban?
Még csak ismerkedem az Unity -vel. Tehát vannak nekem game objectek, viszont a legegyszerűbb módját szeretném választani, hogy számon tartsam őket, és hogy hozzájuk tudjak férni. Ezt úgyk épzeltem el, hogy van nekem egy üres game objectem, abban létrehozok egy scriptet, ami valójában listát vagy listákat tartalmaz a különböző objektumokról. Lehet abban egy lista, ami a pálya csempéit tartalmazza csak, egy másik, ami csak az enemy -t, harmadik, ami a fákat, dekorációkat, szóval értitek. És a lényeg, hogy ha bárhol bármelyik elemet interakcióba kell hoznom egy másikkal, ami nem csak pusztán ötközésdetektálás, mert ugye azt az Unity megoldja magától is, és van hozzá beépített függvény, hanem minden egyéb. Tehát ha mindegy egyes game object -hez az inspectorban hozzácsatolom ezt a konténer scriptet, ami a listákat tartalmazza, és ha meghívom az adott game object saját scriptjén belül is ezt a fő scriptet, akkor minden egyes példánynál ebből a fő scriptől egy külön példány generálódik le, vagy közös referenciaként kezeli azt az egyet? Feltételezem, ha már Inspectorban kell behúzgálni vagy kitallózni, akkor közös példányra fog mutatni. Tehát a lényeg, hogy van a fő script, amit így hívom meg a külön, egyedi objektumokból:
ContainerScript cont;
Tehát nem mindegy, hogy erről újabb és újabb másolat fog létrejönni, vagy azt az egy közöset használja. Szóval úgy értem a kérdést, hogy az a scriptem, vagy legalább is a benne található listák nem statikus listák, mert akkor tudom, hogy csak egyszer létezik, de mi van akkor, ha csak publikussá teszem, és nem statikussá? Vagy ez amit felvázoltam nem működik, csak a Singleton megoldással?
Ha komponensenként hozol létre egy listát az példányonként csinálja meg.
Viszont tudsz egy gyűjtő komponenst csinálni amit a sok kis komponensed ismer és az ő property-jére hivatkozol (ami ugye a lista).
A harmadik megoldás a static.
Itt a kérdés pontosan mit is szeretnél csinálni, milyen interakciókat szeretnél.
Ha priviben dobsz egy dc-t, akár kicsit beszélhetünk róla szóban is, lehet tudok jobb megoldást. Nem véletlen van Raycast és társai :)
Még nincs konkrét példa rá, hogy mihez kellene, csak egyszerűen tudom, hogy kelleni fog. Most még nagyon az alapoknál vagyok. Előtte évekig csak XNA/MonoGame -ben tanulgattam, ott nagyjából két egyszerű megoldás volt a problémámra, az egyik, hogy minden osztálynak van egy saját statikus listája, amit bárhonnan elérhetek. Aztán lebeszéltek róla, hogy ez a globális statikus megoldás nem éppen jó, és hogy máshogyan kellene megoldani. Hogy különböző interfészek meg dependency injection. Akkor jött az a megoldás, ami kb. majdnem ugyanaz, mint a statikus megoldás, annyi különbséggel, hogy nem magában az osztályban hoztam létre egy hozzá tartozó statikus listát, hanem erre egy külön osztályt hoztam létre, mint pl. ContainerClass, és ebben volt egy nem statikus, de publikus lista, és ezt a többi osztály adott függvényében definiáltam mint függőséget (vagy hogy hívják). Tehát ha egy osztálynak egy adott függvényében szükség volt arra, hogy elérje más osztály példányait, akkor ott rendelkezésre állt mindig a ContainerClass hívás, ebből az osztályból meg természetesen egyetlen példány volt az XNA Framework fő osztályán belül, ami általában a Game1.cs osztály névre hallgat. Itt volt az Inicializáló függvény, a LoadContent, a fő Update, és a fő Draw függvény.
Na most, az Unity világa teljesen más, itt nem tudok olyan osztályról, ami összefog mindent, itt minden egyes példány saját magát kezeli, mind a Start függvény, mind az Update, stb. Igen, a Singleton lenne itt a legegyszerűbb, csak kíváncsi voltam, hogy anélkül megvalósítható -e, de ezek szerint igen.
De hogy mondjak példát is erre, ami nem ütközésdetektálás. Képzeljük el, hogy van egy játékosunk, aki egy olyan mágiát aktivál, ami egy azonos (vagy akár több) osztályban lévő ellenségek példányai esetében csak bizonyos feltételekkel rendelkező példányokra hat. És nem csak olyan értelemben, hogy a játékoshoz mennyire állnak közel a fizikai térben, hanem pl. csak olyan példányokra van kihatással, akiknek teszem fel van egy bool változója, meg egy int, és ezek megfelelő kombinációja esetében történik valami. Pl. csak akkor sérülnek vagy halnak meg ezek a példányok, ha ez a bool változó true, és az int változójuk értéke 0 és 20 között mozog. Tehát ebben az esetben nekem szükségem lehet arra, hogy a player osztályon belül hozzáférhessek a konténer scripthez/osztályhoz, hogy ott hozzáférjek egy vagy több külön enemy listához, és azon belül egy for/foreach ciklussal lecsekkoljam a megfelelő feltételeket. Ugyanez bármi más esetében, ha az enemy -nek van szüksége ahhoz, hogy valamit leellenőrizzen a játékos példánynál, de akár tökre más osztályokkal kell kapcsolatba kerülnie, akkor neki is hozzá kell férnie a konténer osztályhoz. Nem tudom mennyire világos. A lényeg, a könnyű hozzáférhetőség, egyszerűség, és egyben hatékonyság. Most ne nézzük azt, hogy a profi OOP szakik ezeket a megoldásokat nem szeretik.
Hát Unitynél a raycastnál a TAG-ek és Layerek elég fontos szerepet játszhatnak, de persze "kézzel is" lehet olyat csinálni, hogy összegyűjtöd a listát akikre hathat és utána iterálás közben egy feltételben ellenőrzöd amit szeretnél.
Az entity-component-systemnél ugye az entitykre helyezett componentek tárolnak nagyon sok hasznos infót, ez azért is jó, mivel törlésnél, létrehozásnál nem kell regisztrálni, törölni dolgokat.
Viszont a másik jó lehetőséged a jobokban rejlik ahol olyan entityken mehetsz végig amik tartalmaznak X component-et/listát. Persze ennek is megvan a maga felhasználási területe és ez főleg optimalizálásban, több szálúságban játszin fontos szerepet.
Kapcsolódó kérdések:
Minden jog fenntartva © 2024, www.gyakorikerdesek.hu
GYIK | Szabályzat | Jogi nyilatkozat | Adatvédelem | Cookie beállítások | WebMinute Kft. | Facebook | Kapcsolat: info(kukac)gyakorikerdesek.hu
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!