Autor Wątek: Jednostka klasą?  (Przeczytany 6146 razy)

Offline Nevermind77

  • Użytkownik

# Czerwiec 28, 2007, 14:56:41
Witam!

Tworzę tego swojego wspaniałego RTSa który ma być klonem Age of Empires. Mam pytanie skierowane do was. Jak lepiej zaprojektować system jednostek?

Ja się skłaniam do tego żeby każda jednostka była osobną klasą. Czyli pikinier to cPikinier, pan piechur to cPiechur, a japoński samuraj to cSamuraj.

Można kod zorganizować inaczej. Na przykład stworzyć klasę jednostek która walczy wręcz, inną klasę to wszelkie jednostki rażące, a jeszcze inne to statki. Poszczególny rodzaj jednostek to po prostu inaczej zainicjalizowane obiekty. Pikinier by był cWręcz z 5 ataku 2/2 obrony a samuraj to również cWręcz ale by miał 7 ataku i 3/3 obrony.

Jakie zalety ma jedno i drugie rozwiązanie? Pytanie kieruje głównie do osób doświadczonych.

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline Daniel22

  • Użytkownik

# Czerwiec 28, 2007, 15:07:49
Jakie zalety ma jedno i drugie rozwiązanie? Pytanie kieruje głównie do osób doświadczonych.

Chyba nie jestem osobą doświadczoną, ale również zamierzam tworzyć RTS-a którego mam zaprojektowanego. Ja zaplanowałem to tak że mam jedną klase CJednostka, tam pełno wirtualnych metod typu OnRender, a potem dziedzicze inną klase po tej np. CŁucznik gdzie ma swoje staty i inne bajery.
Zresztą wedłuyg mnie ten problem można rozwiązać na wiele różnych sposobów.

Offline Nevermind77

  • Użytkownik

# Czerwiec 28, 2007, 15:09:49
Oczywiście że można na wiele sposobów, tylko osoby które mają doświadczenie mogą się wypowiedzieć jak to wygląda w praktyce ;) Może to uchronić przed jakimiś pułapkami których nie przewidziałem. ;)

Offline PlayeRom

  • Użytkownik
    • PlayeRom

# Czerwiec 28, 2007, 15:14:00
E tam sie rozwodzisz o szczegoly. Ile programistow tyle bedzie rozwiazan. Usiadz na spokojnie, przemysl, sam wiesz najlepiej czego potrzebujesz - przynajmniej sam cos zaprojektujesz. A jak sie pomylisz to przynajmniej staniesz sie "dowiadczony" :)

Offline Kurak

  • Użytkownik

# Czerwiec 28, 2007, 15:26:25
Warto pomyśleć nad możliwością dodawania nowych typów jednostek np. w edytorze do gry :)

Offline Xion

  • Redaktor
    • xion.log

# Czerwiec 28, 2007, 17:42:31
Zakodowanie wszystkich jednostek na sztywno w postaci klas ma podstawową wadę: chcąc cokolwiek w tym względzie zmienić, trzeba rekompilować projekt. Proponuję w klasach zastosować tylko ogólny podział na kategorie (ziemna, wodna, latająca, itp.), a konkretne jednostki zapisywać w plikach konfiguracyjnych i z nich wczytywać ich parametry.

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Czerwiec 28, 2007, 17:59:37
Zakodowanie wszystkich jednostek na sztywno w postaci klas ma podstawową wadę: chcąc cokolwiek w tym względzie zmienić, trzeba rekompilować projekt. Proponuję w klasach zastosować tylko ogólny podział na kategorie (ziemna, wodna, latająca, itp.), a konkretne jednostki zapisywać w plikach konfiguracyjnych i z nich wczytywać ich parametry.
Ja bym poszedł jeszcze dalej i w plikach trzymał wszystkie parametry. Specjalizowane właściwości można zrobić na pseudo-skryptach - tabeli wskaźników na funkcje. Wiem, że w C++ do tego jest dziedziczenie i funkcje wirtualne, ale po co tworzyć nową klasę skoro chcę podmieniać jedną metodę? Nie kupuję świni, jeżeli chcę zjeść hot-doga. :)

Offline Masterio

  • Użytkownik

# Czerwiec 28, 2007, 18:07:25
Ja bym zrobił to w klasach i zastosował dziedziczenie.  8)

Offline Nevermind77

  • Użytkownik

# Czerwiec 28, 2007, 19:26:26
Póki co skłaniam się ku zaimplementowaniu kilku podstawowych klas i dam pliki w których będę przechowywać zmienne konkretniej definiujące obiekt. Nie chcę się bawić w języki skryptowe. Zrobię różne AI dla różnych klas i w pliku dam które ma być ładowane.

Offline Reg

  • Administrator
    • Adam Sawicki - Home Page

# Czerwiec 29, 2007, 11:36:12
Ja proponuję proste kryterium:

- Jeśli jakieś rodzaje obiektów różnią się bardzo swoim działaniem, zrób osobne klasy dziedziczące z jakiejś bazowej CObjekt.
Na przykład murki i wszelkie przeszkadzajki stoją tylko nieruchomo i robią kolizje, podczas gdy wszelkie jednostki mogą się poruszać, strzelać, mieć swoje AI itp.
- Jeżeli różnice są tylko kwestią parametrów np. siła, prędkość, flaga czy lata czy chodzi, rodzaj broni itp., to zrobiłbym jako jedną klasę z odpowiednimi polami.

Mogą z tego wyjść trzy różne rozwiązania:

1. Każda jednostka to osobna klasa, tak jak proponujesz - czyli CPiechur, CSamuraj itp.
Tego nie polecam.
2. Coś pośredniego - klasy do ogólnych rodzajów obiektów (CPrzeszkadzajka, CBudynek, CJednostka), a reszta paremetrów jako pola tych klas.
3. Jedna klasa i wszystko opisywane przez parametry. To rozwiązanie jest najbardziej elastyczne i uniwersalna, ale niekoniecznie prostsze ani bardziej eleganckie od 2.

Pamiętam, jak wiele lat temu bawiłem się jakimś nieoficjalnym edytorem do StarCraft i tam można było sobie ustawić żeby dowolny obiekt, nawet budynek był uznawany jako jednostka, mógł chodzić, latać itp. Nie ma wątpliwości, że tam zastosowali rozwiązanie nr 3 :)

Offline Nevermind77

  • Użytkownik

# Czerwiec 29, 2007, 13:57:56

2. Coś pośredniego - klasy do ogólnych rodzajów obiektów (CPrzeszkadzajka, CBudynek, CJednostka), a reszta paremetrów jako pola tych klas.

Chcąc zrobić 1. i tak bym zrobił pomiędzy cSamuraj a cObiekt jakąś klasę typu cRuchomy ;)

Póki co do tego typu się przymierzam. I tak jestem dopiero na fazie projektowania. Zamierzam korzystać z C++ a tam mam wspaniałe dziedziczenie wielokrotne z którego zamierzam aktywnie korzystać.

Cytuj
3. Jedna klasa i wszystko opisywane przez parametry. To rozwiązanie jest najbardziej elastyczne i uniwersalna, ale niekoniecznie prostsze ani bardziej eleganckie od 2.

Takie rozwiązanie jest okropne! :P

Jak już to bym się skłaniał do 2. i loadera który by ładował obiekt do odpowiedniej klasy.

Próbuje opisać relacje pomiędzy klasami w UMLu ale nie mam doświadczenia więc robię żeby było to czytelne dla mnie ;) Jak zrobię to zapewne wrzucę i wtedy będzie coś konkretniejszego do krytyki czy oceny poprawności.

Offline Charibo

  • Redaktor

# Czerwiec 29, 2007, 19:20:02
GPG2, Francois Dominic Laramee: Fabryka jednostek w grze

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Czerwiec 29, 2007, 19:31:18
Cytuj
3. Jedna klasa i wszystko opisywane przez parametry. To rozwiązanie jest najbardziej elastyczne i uniwersalna, ale niekoniecznie prostsze ani bardziej eleganckie od 2.

Takie rozwiązanie jest okropne! :P
Powiedz to Carmackowi, bo tak był napisany Quake. ;) Tam gracz, przycisk, broń, potwór, rakieta, czy apteczka - wszystko korzystało z tej samej struktury Entity i zmieniało tylko jej parametry (w tym wskaźniki na funkcje skryptów). Podobnie w Thief'ie 1 i 2 wszystko było zgeneralizowane dzięki czemu w edytorze po prostu tworzyło się obiekt i ustawiało mu parametry (dziedziczenie było, ale zrobione na poziomie edytora, a nie silnika). W moich projektach takie podejście też sprawdza się wyśmienicie. :)

Offline Riddlemaster

  • Użytkownik
    • Moja strona domowa

# Czerwiec 29, 2007, 20:09:39
Cytuj
Takie rozwiązanie jest okropne!
Jeśli dodasz klasy "na sztywno" to w poważniejszym projekcie co kilkanaście minut będziesz nękany przez designera, który zmienił jakiś parametr i koniecznie MUSI zobaczyć jak to będzie wyglądało w praktyce (i co gorsza ma rację). Jeśli zastosujesz podejście 3. to Ty sobie będziesz robił coś innego (albo nic), a projektant będzie zadowolony, bo w każdej chwili będzie mógł edytować dowolny parametr.
Patrząc na dzisiejsze gry, jest już normą, że logikę oddziela się od danych (a parametry jednostek do nich należą). Nie należy więc iść pod prąd.

Offline Liosan

  • Redaktor

# Czerwiec 29, 2007, 23:59:17
To rozwiązanie numer 1 jest OKROPNE (nie boję się tego krzyknąć!) Przerabiałem to:

 - Prowadzi do burdelu, saigonu, spaghetti i innych fajnych określeń na wygląd kodu.
 - Uniemożliwia napisanie sensownego (w sensie: łatwego w obsłudze i łatwego do napisania) edytora jednostek
 - Uniemożliwia tworzenie modów do gry i w ogóle modyfikowanie parametrów gry bez rekompilacji

Moja opcja w tej chwili to wrzucic jak najwięcej do pliku konfiguracyjnego (czytaj: gdzieś między rozwiązaniem 2. i 3.), np. w XML (XNL...? rozwiązanie rega :) ). W takim XML byś miał np. opis (nazwa, wygląd, animacje, opis tekstowy, zestaw dźwięków) parametry (życie, szybkość, jakie ma ataki: na odległość, wręcz, czary, naprawianie budynków) i róźne strategie/zachowania (np. strategia "trzymaj dystans", strategia "szarża", strategia "stój", strategia "i tak nie możesz się ruszyć" etc)

Liosan