Diskuze: Java - interaktivní přepínače ve hře
V předchozím kvízu, Online test znalostí Java, jsme si ověřili nabyté zkušenosti z kurzu.
Martin Petrovaj:28.8.2018 22:49
Neviem, v čom tú hru vytváraš a teda aké máš možnosti a aké postupy musíš využívať, ale ja keď som dávnejšie robil jednu svoju podobnú hru v Unity, tak som si vytvoril jednu triedu (napr. 'Usable'), ktorá v mojom prípade implementovala rozhranie Interactible, aby s ňou vedel hráč interagovať + nejakú základnú logiku, užitočné helpery atď. (btw nezameriavaj sa až tak na moju konkrétnu implementáciu, len na myšlienku).
Inštancie Usable držali kolekciu objektov, ktorých typ bol odvodený od nejakej ďalšej mojej triedy (napr. 'UsableStrategy', namiesto triedy môžeš ofc použiť rozhranie, čo ti už vyhovuje viac). Každý potomok tej Strategy triedy potom robil pri zavolaní zdedenej spoločnej metódy (alebo spustení eventu, it's up to you) nejakú jednu svoju vec - napr. ParticleUsableStrategy by prepínal k sebe priradený particle effect, AnimationU.S. by spúštal k sebe priradenú animáciu atď.
V praxi boli potom inštancie potomkov Strategy vytvorené na herných objektoch, ktoré manipulovali (napr. stena, dvere, mína, svetlo…) a skript Usable bol na objekte, ktorý interakciu spúšťal (páčka, tlačidlo a pod.). K Usable som potom len nalinkoval tie Strategy skripty, ktoré som chcel a Usable ich pri interakcii spustil.
Keď bolo napísaných dosť konkrétnych stratégií a boli napísané dobre
a univerzálne, vytváranie takýchto interactible objektov, udalostí a scén
bolo fakt ako skladanie lega v editore 
Martin Petrovaj:29.8.2018 8:45
V pohode, to nie je žiadna medzera vo vzdelaní, stačí len prísť s implementáciou, ktorá pasuje do tvojej aplikácie, alebo využiť vhodný design pattern.
Ak by som mal ďalej vysvetľovať na svojom minulom projekte, tak "definování akce(funkce) přímo k té dané instanci" nebolo tak úplne to, čo som spravil - každý druh akcie (spustenie animácie, pohnutie objektom, vypísanie správy atď) bola osobitná trieda (samozrejme všetky mali spoločného predka), každá inštancia si potom držala referenciu len na tie objekty, ktoré ona sama ovplyvňovala (príp. si tie referencie nejako rozumne získala vtedy, keď ich potrebovala).
Spomínané prepájanie objektov nie je opäť nič iné, než klasické
referencie. V tvojom prípade mi to znie tak, že problém je skôr kde a kedy
tie referencie získavať, kam ukladať samotné skripty (myslené ako ich
inštancie) a ako ich navzájom prepojiť. To zase veľmi závisí od toho, čo
už máš vytvorené, čo z toho môžeš na riešenie tohto problému využiť
a ak to nebude stačiť, tak aké riešenie by do zvyšku tvojho projektu
pasovalo najlepšie. A to už je niečo, nad čím sa ako autor hry musíš
zamyslieť sám a podľa toho sa rozhodnúť
Ak mám hovoriť za seba, pri podobných problémoch sa mi najčastejšie
osvedčilo tlačiť na modularitu základných častí projektu - v tvojom
prípade by si mohol napr. porozmýšľať nad nejakým systémom komponentov
pre entity v hre. Nemusel by si ako komponenty dokonca reprezentovať len rôzne
funkčné skripty, ale aj ďalšie dáta a behaviour - napr. polohu entity, jej
grafickú reprezentáciu atď. Takýmto využitím composition patternu by si sa
vyhol nutnému neustálemu rozširovaniu pôvodných tried (a následnej
prekomplikovanej špagetovej abstrakcii, do ktorej je odtiaľ ľahké
spadnúť). Pre správu vzťahov medzi komponentami a entitami vidím dve
najbežnejšie možnosti - buď nejaký vyšší mechanizmus s využitím
inversion of control, ktorý bude nad entitami v tvojej hre a bude ich zhora
sám spravovať (komplikovanejšie riešenie), alebo vytvoriť nástroje,
pomocou ktorých budú môcť komponenty samy komunikovať medzi sebou, napr.
formou helperov a extension metód pre vyhľadávanie iných komponentov a
entít a pod. (návrhovo škaredšie riešenie, ktoré môže zvádzať k
neprehľadnému kódu a tight couplingu). Prípadne vymysli / nájdi niečo iné
sám 
+20 Zkušeností
Zobrazeno 5 zpráv z 5.