Warsztat » Forum

[Inne] Co z czym ma gadać - powiązania między paroma klasami

Jul 10, 2009 | Kurak |
18 wypowiedzi na 2 stronach:
1 2
Kurak
Jul 10, 2009

Co z czym ma gadać - powiązania między paroma klasami

Mam taki niepalący zupełnie "problem", który problemem nie jest, ale zastanawiam się nad nim od rana i nie mogę dojść do rozwiązania.
Właśnie przepisuję zachowanie przeciwników w Wyprawie Rysia i muszę zrobić tak, że, gdy gracz zbierze znajdźkę z efektem "niewidzialność", to przeciwnik ma go nie zauważać i dalej trwać w stanie patrol.
Klasa bohatera (Rysio) może w każdej chwili zwrócić m. in. pozycję i czy Rysio jest widzialny. Na początku (zaraz, jak doszedłem do tego miejsca kodu) chciałem zrobić tak, że przeciwnik po prostu pyta się obiekt Rysia, czy ten jest widzialny, i w którym miejscu się znajduje (sprawdzenie widzialności - w tym sprawdzenie, czy Rysio nie jest zasłonięty przez jakąś przeszkodę terenową). W ten sposób, klasa przeciwnika musi mieć dostęp do
- obiektu Rysia
- managera obiektów sceny (test widoczności)

Potem dostałem nieproszony czas na przemyślenia (szkoła ;D) i przyszedł mi do głowy inny pomysł: przeciwnik pyta się managera obiektów sceny, czy widzi gdzieś coś niepokojącego [Rysio], natomiast manager wtedy pyta się obiektu Rysia, czy ten jest widoczny, sprawdza sobie widoczność i ew. zwraca przeciwnikowi pozycję zauważonego Rysia. W ten sposób przeciwnik musiałby mieć dostęp tylko do managera sceny.

Który sposób wybrać?

Co prawda nie jest to problem, bo jak bym nie zakodził tego, to będzie działać (przynajmniej na początku ;D), ale może wskażecie mi dobrą drogę :)
k_b
Jul 10, 2009

Odp: Co z czym ma gadać - powiązania między paroma klasami

Na Twoim miejscu wybrałbym ten drugi sposób - w sumie oba mało się różnią, lecz można powiedzieć, że dostęp przeciwnika tylko do managera sceny jest... bardziej realistyczny? I jakby bardziej logiczny, w końcu przeciwnik nie powinien mieć dostępu do bohatera gry (Rysia).

Ale to tylko moja subiektywna opinia.
Kurak
Jul 11, 2009

Odp: Co z czym ma gadać - powiązania między paroma klasami

Mnie się też wydaje, że się niewiele różnią, ale różnica jest, i czułem potrzebę zapytać się o to tutaj :]  Mam nadzieję, że do pola temat nie trafi :)
BTM
Jul 12, 2009

Odp: Co z czym ma gadać - powiązania między paroma klasami

A co będzie w takiej sytuacji:
Kod: 

A | B
  |
  |
C
Gdzie A to Rysio, B i C to wrogowie a | to ściana. Jeżeli Rysio mówi Managerowi czy jest widoczny, i ten to powtórzy C to ok, ale jeżeli zapyta się B, to raczej nie powinien dostać info, że Rysia widać ;-)
Kurak
Jul 12, 2009

Odp: Co z czym ma gadać - powiązania między paroma klasami

Cytat:

A co będzie w takiej sytuacji:
Kod: 

A | B
  |
  |
C
Gdzie A to Rysio, B i C to wrogowie a | to ściana. Jeżeli Rysio mówi Managerowi czy jest widoczny, i ten to powtórzy C to ok, ale jeżeli zapyta się B, to raczej nie powinien dostać info, że Rysia widać ;-)
Sprawdzanie widoczności, jeśli chodzi o przeszkody na levelu (czyli np. ściany) będzie wykonywane dla każdego przeciwnika z osobna - najpierw ma być sprawdzenie, czy Rysio nie ma przypadkiem efektu "niewidzialność", a jeżeli go nie ma, to wtedy:
1. sprawdzam odległość pomiędzy przeciwnikiem a Rysiem, jeżeli jest za duża, to przeciwnik nie może zauważyć Rysia
2. jeśli jednak jest wystarczająco blisko, to wtedy sprawdzam, czy Rysio znajduje się w polu widzenia przeciwnika (określone dla każdego przeciwnika kąty widzenia (poziomo i pionowo)
3. jeśli Rysio jest w polu widzenia przeciwnika, wtedy dopiero sprawdzam, czy odcinek pomiędzy pozycją przeciwnika a pozycją Rysia nie koliduje z jakąś częścią mapy

Punkt 3 w tym przypadku na pewno rozwiązuje problem z przeciwnikiem B :) Całe sprawdzanie odbywałoby się w managerze (bo po co Rysiowi informacje o innych przeciwnikach).

Jakieś rażące błędy widać w tym? :)
Moriturius
Jul 12, 2009

Odp: Co z czym ma gadać - powiązania między paroma klasami

Wg mnie ten drugi sposób jest lepszy i bardziej `naturalny` ;)

PS:
Cytat:

(bo po co Rysiowi informacje o innych przeciwnikach).


żeby siać zniszczenie jak czołg - z nienacka :P
puch
Jul 11, 2009

Odp: Co z czym ma gadać - powiązania między paroma klasami

Jak Moriturius. Drugi sposób naturalniejszy. Pierwszego nie skumałem do konca ;D Za dużo tych Rysiów :P

pozdro
Kurak
Jul 11, 2009

Odp: Co z czym ma gadać - powiązania między paroma klasami

Cytat:

Jak Moriturius. Drugi sposób naturalniejszy. Pierwszego nie skumałem do konca ;D Za dużo tych Rysiów :P
W tym pierwszym chodziło w skrócie o to, żeby cały kod wpakować do klasy przeciwnika, a ten kod zajmowałby się ustaleniem widoczności itp :)
Skoro wszyscy są za drugim to już wiem jak to zakoduję :]

Dzięki wszystkim za odpowiedzi - już dokarmiłem ;D
Regedit
Jul 18, 2009

Odp: Co z czym ma gadać - powiązania między paroma klasami

Też jestem za drugim sposobem, ale skoro sprawa jest rozwiązana to zadam szersze pytanie: Jak ogólnie zorganizować w grze kolekcję obiektów i interakcję między nimi typu kolizje, AI, zbieranie, strzelanie, zabijanie itd.? Ja zawsze mam z tym problem i wychodzi wielka kula błota w której wszystko używa wszystkiego - takie monolityczne jądro gry, którego nie potrafię podzielić :) Są jakieś dobre wzorce? Może jakieś artykuły na ten temat? Na czym warto się wzorować?
J0KeR
Jul 20, 2009

Odp: Co z czym ma gadać - powiązania między paroma klasami

Cytat:

Jak ogólnie zorganizować w grze kolekcję obiektów i interakcję między nimi typu kolizje, AI, zbieranie, strzelanie, zabijanie itd.? Ja zawsze mam z tym problem i wychodzi wielka kula błota w której wszystko używa wszystkiego - takie monolityczne jądro gry, którego nie potrafię podzielić :) Są jakieś dobre wzorce? Może jakieś artykuły na ten temat? Na czym warto się wzorować?


Rownież dołączam się do pytania. Czy ktoś, kto rozwiązał problem (ma to jakoś napisane, ma pomysl) mogłby wytłumaczyc jak to wykonał (interakcje między obiektami itd.)?

PS. Najlepiej jakas grupa klas i ich powiązania. Ale Jakie?  :P
mINA87
Jul 17, 2009

Odp: Co z czym ma gadać - powiązania między paroma klasami

A nie można modelik OO - interfejs bazowy IObject, metody onCollision, onDamage, onTake do których podajemy właśnie IObject'y. Jakiś manager będzie analizował scenę (silnik fizyczny? :]) i łączył obiekty - wywoływał na rzecz jednego metodę z drugim w parametrze. Wtedy ten obiekt - master będzie analizował czy np. może podnieść obiekt, ile damage'u dostał itp. Można jeszcze wprowadzić jakieś proxy-wiadomości żeby nie było konieczności przesyłania informacji o obiekcie podrzędnym IObject np. CDamageInfo. W przypadkach krytycznych - zebranie obiektu, zginięcie obiekt informuje manager sceny że nie ma się on takim obiektem zajmować już dłużej zjamować (zakładam że IObject jest kontenerem na IObject'y). Albo IObject<->IObject, albo IObject<->CMessage.
Liosan
Jul 20, 2009

Odp: Co z czym ma gadać - powiązania między paroma klasami

Ja za którymś razem wymyśliłem tablice dwuwymiarową indeksowaną grupami obiektów (np. grupa "pociski Zenka", "monety" etc). podczas inicjalizacji ta macierz jest wypełniana wartością "czy sprawdzać kolizje pomiędzy tymi dwoma" oraz "co zrobić wykryjesz kolizje pomiędzy tymi dwoma". Menadżer obiektów fizycznych sprawdza wszystkie kolizje i wykonuje odpowiednie funkcje. Ja to napisałem dla kolizji, ale można to rozszerzyć na dowolny rodzaj interakcji.

Zaletą tego rozwiązania jest elastyczność - tablice można wypełniać w czasie ładowania lub zmieniać w czasie działania gry. Wadą jest strata obiektowości - funkcje obsługi kolizji nie należą ani do jednego, ani do drugiego obiektu; nie zawsze da się elegancko obsłużyć polimorficzność.


Liosan
Regedit
May 16, 2009

Odp: Co z czym ma gadać - powiązania między paroma klasami

mINA87: Tak to też robię (tylko bez klas komunikatów czy innych proxy), ale wtedy każda klasa korzysta z każdej innej, bo na przykład kiedy Ludzik dostanie wywołanie metody OnCollision z podanym obiektem IObject, to musi sobie go zrzutować w dół do Pocisk i jeśli to faktycznie jest pocisk, odpytać o obrażenia żeby odjąć je sobie od swojego życia.

Ewentualnie możnaby to uogólnić na szereg abstrakcyjnych klas bazowych dziedziczących z IObject (np. IPostać, IPocisk, IPrzeszkoda) i tylko między nimi rzutować w dół, bez znajomości konkretnych klas pochodnych (np. Fireball i Rakieta dziedziczące z IPocisk). Nic lepszego już się chyba nie uda wymyślić...
mINA87
May 16, 2009

Odp: Co z czym ma gadać - powiązania między paroma klasami

Nie podoba mi się Reg to rzutowanie. Kompletnie to psuje model OO a podchodzi już trochę pod ADT, bo psuje abstrakcję. Jeśli chcesz iść w stronę ADT, to bezpośrednie klasy komunikatów CMessage, CDamageInfo etc (to wydaje się w sumie najsensowniejszym podejściem), albo rozwiązanie czysto OO - IObject dziedziczy po IDamagable, IZadająceObrażenia itp i korzystamy z ich abstrakcyjnych interfejsów, ale tu się sieczka robi...
W sumie jak tak sobie myślę, to najlepiej jakieś proxy wiadomości np. CDamageInfo postaci:
Kod: 

class CDamageInfo
{
   int mDamageType;
   std::list<int,float> mDamageModificators;
   IObject* mParent;
   ...
}

I taka klasa umożliwi nam wszystko - w klasie na rzecz której wywołujemy liczymy sobie statsy i jak coś to zwracamy CDamageResponse na podstawie którego klasa mParent wie ile krzywdy zrobiła graczowi którego atakowała i ewentualnie powie managerowi sceny co się stało. 
A kolizje raczej typowo IObject<->IObject.
Steel_Eagle
May 17, 2009

Odp: Co z czym ma gadać - powiązania między paroma klasami

Reg: a dlaczego to wszystko musi sie dziac w klasie Ludzik?

Kod: 

void pocisk::OnCollision(IObject* collided)
{
  collided->TakeDamage(this->ObrazeniaPocisku,this->TypObrazen,this->Sprawca);
  Destroy();
}


Domyslna implementacja TakeDamage zupelnie nic nie robi ;) Dopiero w klasie Ludzik wywoluje metode OnTakeDamage(...) ktora po ewentualnym uwzglednieniu pancerza odejmuje HP-ki.

Kurak: mam jeszcze jeden sposob na zorganizowanie tego, troche wydajniejszy ale to potem, bo teraz nie mam casu pisac ;)
Kurak
May 18, 2009

Odp: Co z czym ma gadać - powiązania między paroma klasami

Cytat:

Kurak: mam jeszcze jeden sposob na zorganizowanie tego, troche wydajniejszy ale to potem, bo teraz nie mam casu pisac ;)
Pisz, pisz, czekam :) Jak będzie fajny to pewnie przerobię to co już napisałem wg. punktu 2 :)
Co do tego ogólniejszego tematu, na który jest ostatnie kilka postów, to ja też bym chętnie poczytał na temat jakiegoś sensownego ułożenia tych wszystkich klas i powiązań :)
Strony:
1 2