Załóżmy, że jest do napisania gra platformowa, gdzie jest sobie ludek którym gramy, ma kilka broni ze sobą i różnych przeciwników np. kosmici i wampiry. Można zbierać na planszy po drodze bonusy np. dodające punkty lub kolejne życie. Dodatkowo na planszy są aktywne przeszkadzajki jak kolce które wychodzą z ziemi i chowają się, i tak bez przerwy.
Co prawda mam to wszystko na myśli w kontekście Javascript, ale to bez większego znaczenia i pomijam oficjalny brak klas abstrakcyjnych. Klasycznie stworzyłoby się prawdopodobnie klasy takie jak: Broń, klasa abstrakcyjna Przeciwnicy i “przydzielone” jej klasy Kosmici oraz Wampiry. Stworzyłoby się także klasę abstrakcyjną Bonusy, a przydzielonymi jej klasami byłyby typy bonusów np. klasa “(Bonus) Więcej Życia”, podobnie podchodzimy do przeszkadzajek, które byłby wstępnie klasą abstrakcyjną. Ludek nie miałby klasy, pozostałby obiektem bezklasowym, ponieważ tworzymy go tylko raz, wydaje się, że bez wyjątku.
Jak Wy rozplanowalibyście podział na klasy i obiekty? Może zrobilibyście to inaczej? Czy może lepiej obiekt Ludek czy tam Gracz tworzyć z klasy, czy może miałby to być “suchy” obiekt, zakładając pewność, że nie wdrożymy np. Multiplayera? Czy właściwości opisujące wygląd można traktować jak obiekt danego obiektu np. kosmita.wyglad.kolor: zielony? “wygląd” jako tako nie byłoby przecież obiektem, bo jak wygląd może być obiektem? Byłby to raczej zbiornik na właściwości i czy odpowiednie jest tu zastosowanie obiektu? Wiem, że tak się robi.
Chciałbym poznać Wasze zdanie i wizje odnośnie takiej mini-gierki. Być może lepiej się rozeznam i ugruntuje swoją wiedzę.
Zacznij może od tego, że chcesz w przyszłości mieć multi. Pisząc wszystko po stronie javascript nie jesteś w stanie kontrolować niczego. Najlepiej wszystko trzymać po stronie serwera, a do klienta wysyłać wektor zmiany pozycji, w zamian otrzymując parametry / zdarzenia na twoim obiekcie oczywiście mapę możesz sobie buforować ale nie możesz polegać na kliencie, bo user usunie sobie przeszkodę, zmodyfikuje broń / mapę itd.
Obiekt z jednym elementem nie ma sensu. ale jeśli miałby on kilka elementów w jakiś sposób z sobą powiązanych to jak najbardziej.
To może jednak ten multiplayer i brak możliwości oszukiwania odpuśćmy sobie, bo albo musiałbym się zająć PHP, albo node.js czy coś w tym rodzaju i co gorsze, większość w nich zrealizować. Jak w przypadku takiego założenia?
Potem każda z klasy mogłaby dziedziczyć po tej klasie np. główna postać dla gracza, przeciwnicy.
class Weapon
useWeapon();
i po tej klasie dziedziczą np. jakieś tam bronie, rozpisz to sobie. Na Twoim miejscu jeśli się interesujesz programowaniem zorientowanym obiektowym to bym poczytał o wzorcach projektowych
Znam mniej więcej wzorce projektowe, ale one niezbyt mimo wszystko odpowiadają na pytanie “co jako obiekt, co jako atrybut i czy w ogóle tworzyć klasę?” Co więcej chyba nawet doświadczonym robi to problemy, ale chciałem znać Wasze opinie.
Póki co doszedłem do tego, że najlepiej wszędzie gdzie się da tworzyć obiekty i klasy, ponieważ program jest łatwo rozszerzalny i aby taki był, lepiej nie zakładać sobie wersji typu “nie będę robić więcej niż jednego ludka, więc stworzę bezklasowy obiekt”.
Natomiast co do Twojego pomysłu to wydaje się całkiem niezły Acz poznałem już programowanie oparte na kompozycji, komponentach i to także rozważam. Tylko widzisz… ja mało praktykuje, dużo czytam. Normalnie programista tworzy pierwszą grę w oparciu o klasyczny model obiektowy i potem dopiero szuka lepszych rozwiązań, a ja maniakalnie niepotrzebnie chyba dążę do nie-wiem-czego, aby mieć już pierwszy kod nie-wiem-jaki.
U mnie najczęściej jest wersja inicjalizacyjna np. strukturalna w tym przypadku i od razu po niej wersja którą chcę mieć nie-wiem-jaką (doskonałą?)
Przestrzeń problemu jest tak mała, że nie ma szczególnego powodu by budować hierarchię klas. Jeśli chcesz w jakiś sensowny sposób podzielić dane, znacznie lepiej nadadzą się komponenty (które swoją drogą są bardzo popularne w game devie).
Zależy w jakim języku i / lub na jakim silniku opierasz swoje gry. Ogólnie można to zrobić tak że tworzyć klasę abstrakcyjną np.: APotwory, po której będą dziedziczyć różne potwory. Później tworzysz inne klasy abstrakcyjne np. APostać, APogoda, itd, w zależności co chcesz zaimplementować. To jest zrozumiałe. Teraz w jakim języku chcesz tworzyć? Wzorce projektowe najłatwiej (dla mnie) implementuje się w javie. Tylko nie wybieraj języka bo “lepiej się pisze” tylko żeby gra lepiej działała. JavaScript? Czemu nie. Jak wiesz że na 100% ten język będzie dobry na potrzeby twojej gry to go użyj.
Ostatnio jestem po lekturze książki “Czysty Kod” Roberta Martina. Zatem…:
dobra hierarchia jest pomocna, ale zbyt mocne rozbicie kodu, tym bardziej w językach czy raczej IDE (a do JS, nie ma tak fajnie) nie pomagają w tym. Dla małego programu nie ma sensu zbytnio rozbijać kod na masę klas.
Nie zależnie czy w dużych czy małych aplikacjach ważne jest logiczne i czytelne rozłożenia kody na klasy.
Klasy czy raczej ogólnie obiekty, są w aplikacji odzwierciedleniem RZECZOWNIKÓW. No chyba że chcesz pisać w językach funkcyjnych, ale wątpię.
Rzeczowniki, czy też Aktorzy i Rekwizyty.
Klasy powinny być też jak najbardziej jednostkowe. Jeśli klasa nazywa się LayoutAndTime (i robi to co wynikło by z nazwy), to już jest dobrze. Nie powinno być też tak że klasa się jakoś nazywa a robi dodatkowo jeszcze coś.
metody klas są czynnościami, czyli w większości przypadków są (powinny być) CZASOWNIKAMI - get, set, go, talk itd.
cała reszta to też rzeczowniki ale określające składowe - czyli wszystkie pola
Ludek jak najbardziej jest obiektem, więc ma jakąś klasę (choćby object);
“wygląd” nie wydaje się Tobie obiektem, bo powinieneś rozdzielić warstwę logiki od prezentacji; (koncepty takie jak MVC czy MVP nie wymyślono znikąd) Zresztą jest to obiekt, klasy View.
W JS można zrobić coś na zasadzie klasy bazowej i po niej dziedziczyć.
Czytałem pobieżnie o MVC czy MVP, ale kompletnie sobie nie powiązałem tych konceptów z moją niewielką grą. No ale było to i tak na tyle pobieżnie, że poza wiedzą, że kod ma podział na np. widok i logikę to za wiele nie wiem. Na pewno się dokształcę i dzięki za dość rzeczowe odpowiedzi.
Co do wiedzy odnośnie samego gołego JSa to mam dość sporą, wiem więc na jakiej zasadzie działa tam dziedziczenie (prototypowe), domknięcia i znam zalety (i wady) wynikające z tego, że JS jest wysoko poziomowy.
A i małe pytanie - czyli obiekt traktować raczej jako zbiór właściwości i metod adekwatnych do danego obiektu, niż jako bezpośredni obiekt rozumiejąc go przez pryzmat rzeczywistości?
Acz poznałem już programowanie oparte na kompozycji, komponentach i to także rozważam. Tylko widzisz… ja mało praktykuje, dużo czytam. Normalnie programista tworzy pierwszą grę w oparciu o klasyczny model obiektowy i potem dopiero szuka lepszych rozwiązań, a ja maniakalnie niepotrzebnie chyba dążę do nie-wiem-czego, aby mieć już pierwszy kod nie-wiem-jaki.