Architektura klas entity(postaci,przedmiotów,bloków...) w grze platformowej

Question

Hej,tworzę grę platformową i mam problem ze stworzeniem architektury jednostek. Powiedzmy że mamy sytuację gdzie będzie dużo rodzajów przeciwników,postaci neutralnych,przyjaznych, dużo rodzai przedmiotów i kafelek.

Każdy przeciwnik zachowuje się inaczej,każda kafelka może się poruszać albo stać w miejscu,albo znikać itd.

Stworzyłem na razie klasę Entity,oczywiście według EntityComponentSystem  stworzyłem funkcję rysującą poza klasą, mam specjalną klasę od rysowania obiektów,specjalną klasę InputManager itd. 

Mam też klasę Character która dziedziczy po Entity. Oraz DataTable:

std::vector<CharacterData> initializeCharacterData()
{
	std::vector<CharacterData> data(Character::TypeCount);

	data[Character::Player].hitpoints = 200;
	data[Character::Player].speed = 100.f;
	data[Character::Player].texture = Textures::Entities;
	data[Character::Player].textureRect = sf::IntRect(0, 0, 48, 64);

	return data;
}

Umożliwia mi to tworzenie wielu różnych postaci na mapie z innymi parametrami wyglądu i np. HP. Bez potrzeby tworzenia 100 takich samych klas. Ale co w przypadku gdy wymagam aby nowa postać miała inne zachowanie? Ja bym to rozwiązał tak:

Dla każdego rodzaju przeciwnika (o ile ma inny typ zachowania, bo w przeciwnym wypadku wystarczy użycie DataTable) tworze nową klasę, np. Bee,Zoombie. Bee będzie obiektem latającym a Zoombie będzie chodziło po kafelkach, więc zawartość klasy Update będzie inna. Update w klasie Entity jest virtualne więc potem mogę tworzyć postacie przez wskaźniki

//Analogiczna sytuacja też dla innych obiektów np kafelek 
std::vector<Entity> entities;

entities.push_back(new Bee);

entities.push_back(new Zoombie)

entities[x]->update

Dowiedziałem się że to jednak nie jest dobry pomysł,a poza tym jakbym miał 100 typów postaci to miałbym 100 klas a do tego jeszcze dochodzą kafelki i inne rzeczy. 

 

Innym pomysłem który przychodzi mi do glowy jest zostawienie klasy Character i tworzenie postaci tylko za pomocą DataTable, i stworzenie PhysicComponent. Każdy obiekt Character miałby 

PhyaicComponent *mPhysicComponent;

I tworzyłbym np. klasy z różnymi zachowaniami :

FlyingPhysic : public PhysicComponent 

i przydzielał danie zachowania do obiektów klasy Character:

entity->mPhysicComponent = new Flying Psychic;

i potem updatował. Jakie wy możecie mi dać rady?

Comments

Polecam przeczytać game programming patterns. Na pewno znajdziesz  tam coś co rozwiąże Twój problem.

Answer 1

Ostrzeżenie: Nie jestem ekspertem od architektury. Czytasz dalej na własne ryzyko.

Z mojego doświadczenia wynika, że ilekroć próbowałem zaprojektować sobie hierarchię klas, zanim jeszcze zdążyłem zapoznać się z problemem który chcę rozwiązać, nic z tego nie wychodziło. Wiesz, na początku jak sobie mówisz rzeczownikami, to to wszystko dobrze brzmi. Gra składa się z Obiektów (dużymi literami chcę zaznaczyć co jest klasą): Kafelków i Jednostek. Kafelki mogą być Nieruchome (UnmovableTile), Ruchome i może jeszcze jakieś specjalne? Jednostki sojusznicze i wrogie, latające i pełzające. I tak budujesz sobie wesoło hierarchię klas, ale ona nic nie daje. Sprawia tylko, że jak tworzysz złowrogą pszczołę, to się zastanawiasz co z niej powinno być w jednostce latającej, co we wrogiej, a co jeszcze ma ona unikalnego.

Proponuję zacząć od drugiej strony. Nie od góry, a od dołu. Napisz sobie zwykły kafelek, z kamienia czy tam z ziemi. Makaronem, w mainie. W tym momencie nauczysz się trochę o tym kafelku i zaczniesz już widzieć co wspólnego będzie miał ten kafelek z kafelkiem błotnym czy ognistym. Zaczynasz pisać kafelek błotny i mówisz: "kurde, skopiowałem połowę kodu z kafelka ziemnego". Pojawił się problem -- duplikacja kodu -- i dopiero teraz ma sens rozwiązywanie go. Dopiero teraz tworzysz coś, co przechowuje ten wspólny kod. I w tym momencie ma to uzasadnienie. Bo po co u Ciebie Character dziedziczy po Entity? (Nie mówię, że to bez sensu, tylko że na tym etapie, gdy nic nie wiem o Entity i Characterze, to dla mnie nic nie znaczy).

No i uważaj na "paraliż przez analizę". Zauważyłem, że często to robię. Siedzę przez kilka godzin i myślę jak te klasy poukładać zanim napiszę chociaż linijkę kodu. Do niczego dobrego nigdy mnie to nie doprowadziło.