Projekt gry SFML

Question

Chcę napisać grę w sfml

Mam już w głowie w miarę dokładny pomysł, proszę o ocenę, komentarz, radę i odpowiedz na pytania na końcu

Klasy silnika (będą po angielsku, w fazie projektowej po polsku):

• Obiekt (pozycja oraz wskaźnik na funkcję efektu kolizji)
• Ruch (przyjmowanie movePerSec i elapsedTime)
• Kolizja (przyjmowanie dwóch obiektów. Sprawdzanie i if(collision == true){czynność}; czynność ==  ruch wstecz, i reakcja na ruch, czyli wykonanie funkcji przekazanej przez klasę Obiekt)
• Animacja (przechowywanie sf::IntRect i zwracanie odpowiedniego sf::IntRect)
• Rysowanie obiektów (pętla, jeden sf::Sprite, jedna sf::Texture
• Wyświetlanie tekstu
• Ewentualnie odtwarzanie muzyki

Klasy gry:

• Gra (start gry)
• Menu (będzie wywoływać między innymi klasę Gra)
• Level (to będzie kilka obiektów, których wskaźniki będzie przechowywać klasa Gra)
• OknoTekstowe (Wyświetlanie tekstu - będzie wywoływane przez klasę kolizja)

Logika gry:

Menu -> Gra -> pętla gry

Pętla gry:

Level -> Obiekty -> Ruch -> Kolizja -> Animacja -> Rysowanie

 

Pytanie:

Jak planować logikę gry i jak ją programować. Czy realizacja wydarzeń w grze w klasie Kolizja np. wyświetlanie tekstu, albo reakcja botów na zbliżenie się jest dobrym zabiegiem. Jakie macie na ten temat zdanie.

Jak zrobić z sf::Sprite, zajmuje 272 bajtów a więc trochę dużo.

Ja myślałem, zeby zrobić jedną teksturę i jeden sprajt i jedno po drugim wywoływać w pętli: window.setTextureRect(IntRect); i window.draw(sprajt);

P.S.
Jeżeli ktoś chciałby spróbować zrobić grę np. w dwie osoby to proszę o kontakt :)

Comments

Twój projekt jest koszmary. Zapoznaj się z paradygmatami programowania obiektowego, regułami SOLID i wzorcami projektowymi. Oczywiście przy programowaniu gier nie trzeba się trzymać reguł tak mocno jak przy oprogramowaniu biznesowym. Przy projektowaniu swojej gry może ci się przydać UML. Zapoznaj się jeszcze z jakimś otwarto źródłowym silnikiem np Godot Engine, na którym będziesz mógł się wzorować.

---

Ok. Poczytałem trochę. Co myslisz o dwóch elementach silnika update i draw. Gra nie ma nic wspólnego z draw. Gra zawiera całą logikę i wszelkie udziwnienia i wymienia się informacjami z update. Update zbiera informacje i przesyła je do draw. Czy taki plan jest do przyjęcia. Możesz przedstawić mi swój opis zależności. Myślę, że nie potrzebuję używać wzorców projektowych czy wzorować się na dużych projektach takich jak godot. Jedyne co chcę osiągnąć do możliwość animowania, wyświetlania i wykrywania kolizji.

---

Chcesz mieć możliwość animowania, wyświetlania i wykrywania kolizji, to robisz klasę
Animation odpowiedzialną za animowanie, klasę Image odpowiedzialną za rysowanie obrazka, klasę CollisionDetector odpowiedzialną za wykrywanie kolizji. Nie wiem o co ci chodzi z tymi update i draw, to są klasy, funkcje czy co? Tym bardziej pomysł z klasą Kolizja jest dziwny, bo klasa odpowiedzialna za sprawdzanie kolizji nie powinna robić nic innego jak sprawdzać kolizje.

---

to robisz klasę

Chodzi mi o to, że nie wiem jak planuje się tworzenie projektu. Jak planować komunikacje między klasami. Bo skoro po przedstawieniu mojego planu określiłeś go słowami

Twój projekt jest koszmary //nie neguję, zapewne masz racje

To liczę na pomoc. Możesz teraz powiedzieć - "Powiedziałem o SOLID, o wzorcach, o inspiracji open source np. Godot Engine" ok, ale nie odniosłeś się to moich wypocin z pytania. Myślę że o SOLID, wzorcach itd. można powiedzieć przy każdym błędnie zaprojektowanym projekcie.

Oczekuję pomocy dotyczącej mojego pytania. Jeżeli uważasz, że takiego czegoś się nie poprawia tylko pisze od nowa, to proszę o wyjaśnienie np. od czego zacząć pisanie gry, jakie elementy gry są elementami pierwotnymi a które złożonymi. Może skomentujesz koncepcje jednej tekstury i jednego sprajta opisaną na końcu pytania.

Proszę o rozmowę i jestem otwarty na konstruktywną krytykę o ile jest dobrze przedstawiona

Answer 1

Przecież wyjaśniłem w poprzednim komentarzu, że pomysł z klasą Kolizja jest zły bo klasa powinna robić tylko jedną rzecz. O tym właśnie mówi pierwsza reguła SOLID. Koncepcja jednej tekstury dla tej samej jednostki to wzorzec projektowy pyłek. Twój pomysł na wywoływanie w pętli "window.draw(sprajt)" jest kiepski bo jest typowy dla paradygmatu proceduralnego,  Jeśli chcesz narysować sprite to na nim wywołujesz draw, a nie na window. Nie rozumiem zresztą o co chodzi z tym zdaniem: "Jak zrobić z sf::Sprite, zajmuje 272 bajtów a więc trochę dużo". Co zrobić? W ogóle nie powiedziałbym, że 272 bajty to jest dużo w czasach kiedy komputery mają po kilka GB ramu.

Comments

Jeśli chcesz narysować sprite to na nim wywołujesz draw, a nie na window.

Chodzi o dziedziczenie klasy sf::Drawable ?

---

Możliwe. Nie znam SFML i odnoszę się jedynie do projektu.
Główna pętla gry powinna wywoływać draw na obrazkach, a nie na window z argumentem obrazka.

---

pomysł z klasą Kolizja jest zły bo klasa powinna robić tylko jedną rzecz

Ja to rozumiem tak:

Każda klasa wykonuje jedna rzecz:

Kolizja sprawdza kolizje (true/false) ->
kolejna klasa reaguje na kolizję, np. obiciem, zniszczeniem, reakcje mogą być różne na różne obiekty, więc? klasa abstrakcyjna Reakcja i wskaźnik na klasy: Odbicie, zniszczenie itd. ? ale zaraz, muszę wiedzieć jaki obiekt koliduje z jakim czyli tą informacje ma mi wysłać klasa Kolizja, czy może jeszcze kolejna klasa. Dalej.
Klasa reagująca na kolizje może wykonać różne czynności, blokadę ruchu w stronę obiektu z którym koliduje, wymuszenie ruchu w przeciwnym, zniszczenie obiektu z którym kolidowano, ogólnie przekazuje informacje do klasy Ruch. Klasa ruch z kolei porusza obiektem klasy Obiekt. Klasa Rysuj rysuje obiekt na podstawie pozycji zawartych w klasie Obiekt.

Powstaje jeden wielki ciąg klas, modyfikacja jednej może zmusić do modyfikacji kolejnych. Właśnie takie mam rozumowanie. Tego chce uniknąć. Właśnie dlatego stworzyłem to pytanie.

---

A jeśli wszystko wsadzisz do jednej klasy to myślisz, że projekt będzie odporny na zmiany. Uwierz mi będzie jeszcze gorzej. Nie musisz się silnie trzymać reguły jednej odpowiedzialności, ale trzeba znać umiar. Taka klasa CollisionDetector powinna udostępniać informację czy kolicja zachodzi oraz w jakim punkcie zachodzi i może jeszcze ewentualnie przyjąć odpowiedzialność za fizykę ruchu, ale umieszczanie w takiej klasie dodatkowych rzeczy jak reagowanie zniszczeniem czy zadaniem obrażeń to już będzie przesada.