rpg

[Poradnik] Piszemy grę RPG

Wstęp


Piszemy grę RPG jest serią poradników gdzie piszemy wspólnie od zera do samego końca grę RPG, jest to także bardziej rozbudowana wersja kursu Piszemy grę w SFML.

Nie ukrywam, że materiał omawiany na tym kursie jest dużo bardziej rozbudowany, a co za tym idzie trudniejszy i wymagam na niej poznania SFML na poziomie co najmniej średnio-zaawansowanym (np. przejście przez kurs SFML i Piszemy grę w SFML). Ten sam poziom dotyczy programowania w c++, a konkretnie znajomości programowania obiektowego (w tym dziedziczenia).

Podczas tego kursu poruszymy tematy związane z planowaniem pisania gry, pisania systemu ekwipunku, NPC, questów, systemu walki, wczytywaniu i obsługiwaniu bardziej skomplikowanych poziomów, a także paru mniejszych tematów związanych z grami RPG.

UWAGA: Ten kurs nie jest skierowany do osób, które nie miały nigdy wcześniej styczności z SFML!

Przydatne informacje

  • używam SFML 2.2 (dokumentacja) SFML 2.3 (od lekcji 3),
  • piszę i kompiluję projekt przy użyciu Microsoft Visual Studio Professional 2012,
  • kod z każdej lekcji będzie dostępny tylko do pobrania (link pod każdą lekcją),
  • pod każdą lekcją pojawi się możliwość obecnego pliku „.exe” gry,
  • poradnik z racji swojej złożoności, będzie się pojawiał raz na 2-6 tygodni.

[!] Prace nad poradnikiem zostały wstrzymane i nie wiem kiedy zostaną wznowione. [!]

— (15.05.2015) seria najprawdopodobniej doczeka się rebootu na streamach w wakacje —

— cały kod jest dostępny na [repo] —

 

Spis treści


  1. Budujemy szkielet gry
  2. Klasa „Level”, czyli obsługujemy poziomy (mapy) w grze
  3. Gracz – poruszanie i kolizja z otoczeniem
  4. Gracz – system klasowości oraz zarys systemu walki
  5. Gracz – drzewko umiejętności oraz kończymy walkę z przeciwnikami

  • Crow

    Link do pierwszej części czyli Budujemy szkielet gry na nic nie wskazuje… 🙂

    • Jeszcze na nic nie wskazuje, tak jak pisałem w odpowiedzi na twój komentarz: 1. lekcja pojawi się w pierwszym tygodniu kwietnia.

  • Adam Pajkert

    Jestem ciekaw jaką masz wizję na szkielet gry 🙂 Od dawna chciałem coś takiego zobaczyć, ponieważ zawsze gdy sam piszę taki framework, pojawia się myśl „Czy dobrze to robię? Chyba nie bardzo… Ciekawe jak robią to inni… pewnie milion razy lepiej i logiczniej ode mnie… nie pokaże nikomu swojego kodu bo uznają mnie za idiotę…”, tak wygląda to u mnie 😀 Z niecierpliwością więc czekam ( i nie tylko ja 😀 ) na twoją serię poradników i bardzo ci kibicuje 😀 Dodatkowo mam nadzieję że napisana przez ciebie gra będzie Cross-Platformowa 🙂 Powodzenia 😉

  • Crax

    Szkoda że projekt zawieszony…
    Myślę jednak, że mogę zapytać jak zbudował byś system przeciwników od momentu ładowania danych do rysowania ich na mapie. dokładnie chodzi mi jak poradził byś sobie z zarządzanie dużą liczbą obiektów, umieścił w tablicy i kolejno obsługiwał, wektorem? Może jest jakiś algorytm? Słownie, jak?
    Pozdrawiam, Crax.

    • Słowo „wstrzymany” brzmi lepiej, bo najprawdopodobniej do niego wrócę chociaż będę go kontynuował najprawdopodobniej w nieco innej formie niż dotychczas.

      Wracając do twojego pytania, to jeżeli chodzi o kolizje to najlepiej jest to chyba załatwić zmodyfikowaną wersją quad tree (na podobne pytanie odpowiadałem w komentarzach pod wpisem http://szymonsiarkiewicz.pl/poradniki/goto/sfml-i-przechwytywanie-znakow/ ).

      Samo rozwiązanie tego problemu powinno się pojawić w serii „howTo” (liczę, że do końca miesiąca).
      Pozdrawiam

      • Crax

        System drzewa czworkowego w kolizjach obiektu dynamicznego z obiektem stałym jeszcze jakoś wyjdzie…

        A co z kolizjimi obiektów dynamicznych (gracz – przeciwnik).

        Kontrola obiektu reprezentującego przeciwnika, nie sprowadza się tylko do kolizja ale i wykrywania akcji z graczem innym obiektem, system walki itd… tutaj znowu pojawia się pytanie jak się do tego zabrać.

        Np sytem walki, klasyczny rodem z tibi klasa enemy * musimy sprawdzić czy odległość gracza od przeciwnika jest odpowiednio mała, jeśli nie wykonać ruch przeciwnikiem, jeśli tak za atakować gracza. Przy jednym obiekcie jeszcze mi to idzie… Jeśli zaś pojawia się grupa przeciwników, musimy sprawdzić stan każdego z nich, i tu pojawia się problem. Przy tablicy jest taki problem że w danym momencie obsługuje jeden obiekt, reszta czeka na swoją ,, kolej ” jeśli mogę to tak opisać.

        * klasa enemy do wszystkich rodzajów przeciwników czy osobna klasa do każdego obiektu, można też zastosować szblon klasy…

        • Powiedz mi jeszcze co rozumiesz przez „dużą ilość przeciwników”, jak będą się oni zachowywać (możliwy ruch jest tylko w poziomie, czy to jest gra z widokiem od góry), chociaż najprawdopodobniej w większości przypadków najlepsze jest wrzucenie przeciwników do listy wg kolejności jakiej zostali stworzeni, następnie wg tej listy uruchamiasz ich skrypty od AI itd. Gorzej jeżeli chcesz aby system był bardziej zaawansowany, tzn nie atakowali jednocześnie, a gracz musi mieć szanse na zrobienie kontry czy czegoś podobnego. Aby podrzucić jakiś pomysł musisz podzielić się efektem, który chcesz osiągnąć, jak ten system ma wyglądać w praktyce?

          • Crax

            Nie trudno zrozumieć o co mi chodzi, klasyczny silnik gry tibia gotowy do dalszej rozbudowy.

            Duża ilość przeciwników, „tyle ile ekran pomieści”, gracz w środkowej, przeciwnicy ustawieni, do o koła niego.
            Wymiary okna 224 x 224, wymiar kafla 32 x 32 wychodzi 48 pól (minus jedno które zajmuje gracz ).
            48 przeciwników, ich zachowanie zależne od rodzaju ataku itd…

          • Tak, ale mogłaby istnieć sytuacja gdy przeciwnicy mogą ze sobą nie kolidować, tak samo mogą być pomiędzy kaflami więc mogłoby ich być więcej. Przy 48 przeciwnikach nie ma znaczenia do jakiej struktury ich wrzucisz.
            Jeżeli chcesz żeby gracz miał szansę na zrobienie uniku/kontry możesz sprawdzać czy przeciwnicy są w odpowiedniej odległości i wtedy wrzucać ich do kolejki na atak.