Projektowanie kodu gry

Dzisiaj zajmiemy się tematem o który zostałem poproszony, jak więc widać warto proponować jakieś tematy o których powinienem wspomnieć. Jest to temat dosyć ważny, ponieważ planowanie jak mniej więcej będzie wyglądała sama gra oraz jak będzie wyglądał kod może pozwolić nam uniknąć problemów, które możemy natrafić gdy kodu nie planujemy. Gdy go nie planujemy zazwyczaj w kodzie robi nam się istny chaos, a kod robi się dla nas mało czytelny (przykładem takiego kodu może być kod Shipping is Fun, którego nie pokaże bo się go wstydzę ;)). Wielkim plusem planowania kodu jest fakt, że znamy mniej więcej kolejność implementowania poszczególnych fragmentów i dzięki temu możemy w wydajniejszy sposób napisać aplikację.

art_projektowanie kodu

Skoro wiemy już dlaczego warto projektować kod do czas odpowiedzieć sobie na pytanie jak to zrobić. Z góry uprzedzam, że nie jestem specjalistą w tej dziedzinie więc ewentualne błędy w moim rozumowaniu proszę zgłaszać.


Przed właściwym właściwym zaplanowanie kodu należy mieć rozpracowany przynajmniej w minimalnym stopniu pomysł na grę, czyli rozpisujemy sobie jak gra powinna wyglądać, pomoże nam to nieco w opracowaniu klas,  gdyż pogrupujemy w jakiś sposób nasze pomysły, przykładowa lista luźnych (głównych) założeń:

– gra 2D, widok top down

– survival z elementami sandbox

– gra z elementami strategicznymi (zarządzanie ludźmi, ich relacjami etc)

– losowe eventy (klęski żywiołowe, najazdy bandytów, etc)

Z tych założeń, można rozwinąć wiele mniejszych, te założenia mogą ci przypominać grę RimWorld i masz rację bo ona posłuży nam za przykład. Teraz rozwińmy nieco nasze ogólne ogólne założenia:

Na survival może się składać:

  • uzupełnianie żywności, pragnienia
  • magazynowanie żywności
  • leczenie obrażeń
  • zapewnienie sobie schronienia

Elementy strategiczne:

  • sterowanie postaciami
  • magazynowanie surowców
  • zachowanie postaci wobec siebie, a także w określonych okolicznościach

Losowe eventy:

  • zrzuty żywności
  • klęski żywiołowe: burza słoneczna, zaćmienie słońca
  • szaleństwo wśród zwierząt, szkodniki w roślinach
  • napady bandytów

Oczywiście tego można wypisać zncznie więcej, ale my nie chcemy przecież pisać drugiego RimWorld ;). Oczywiście nasuwa nam się tutaj jeszcze takie elementy jak postacie, zwierzęta oraz ekwipunek:

Postacie:

  • ludzie lub zwierzęta
  • AI
  • ekwipunek i cechy (tylko ludzie)

Jak zapewne zauważyłeś ten spis zaczyna przypominać klasy, które gdy będą w odpowiedni sposób rozmieszczone będą pozwalały na rozwój kodu bez potrzeby zmian wielu elementów, szczególnie tutaj przydaje się dziedziczenie, oto jak mógłby wyglądać schematycznie klasy (lepiej widoczny obrazek TUTAJ):

Jak widzimy na powyższym przykładzie, ze zwykłych założeń zaplanowaliśmy sobie +/- jak powiniem wyglądać schemat kodu gry, klasa Survival jest tutaj klasą główną, która zarządza wszystkim, oczywiście nie wypisałem na tym schemacie wszystkich obiektów, metod czy też klas jakie w grze mogą się pojawić. Te przykład ma jedynie na celu pokazanie Ci jak dużą rolę w programowaniu gier ma dziedziczenie, ułatwia ono dodawanie kolejnych obiektów do gry.

Na obrazku powyżej możemy także zauważyć pewną hierarchię klas, tzn każda z tych klas nie ma dostępu do każdej klasy, np Człowiek może korzystać z Ekwipunku, lecz Zwierzęta nie ma już takiej możliwości (np. bo po co krowie shotgun :P). Przy projektowaniu kodu należy się zastanowić z czego dana klasa będzie korzystała, dlatego warto wiedzieć wcześniej co będzie zawierała gra, przynajmniej w jakimś małym stopniu. Co warto jeszcze zauważyć to fakt, że elementy „najmniejsze” są na samym dole drzewka, cyli nie mają dostępu do klas powyżej (jeżeli stworzymy obiekt „pistolet” klasy Ekwipunek to nie może on używać metod Człowieka, za to Człowiek może używać metod pistoletu)

Niestety nie ma żadnych gotowych uniwersalnych schematów do tego jako powinien wyglądać schemat klas gry. To zależy od jej gatunku oraz naszej implementacji, jeżeli chcesz napisać oryginalną grę raczej nie warto trzymać się wytyczonych ścieżek, które po prostu stworzą niemal identyczną grę tylko z innymi teksturami (szczególnie to widać w grach tworzonych w gamemakerze, nie żebym coś miał do tego silnika, ale większość gier tak stworzonych są do siebie strasznie podobne).

Na koniec mam dla ciebie szkielet większości gier, ten schemat mogę ci w 100% polecić 😉


Mam nadzieję że komuś artykuł się przydał, może czegoś nie dopowiedziałem, albo powiedziałem źle. Dajcie znać o tym w komentarzach. Miłego pisania gier!


  • Kamil

    Dobrym szkieletem jest ten, który zrobiłeś w „Piszemy grę w SFML’u”. Enum i pętla główna w której jest switch sprawdzający aktualny status gry. Na chwilę obecną próbując coś pisać w sfml’u trzymam się twojej koncepcji, bo jest prosta i przejrzysta. Po prostu miodzio! :>