Autor Wątek: wzorzec fasadowy i powiazania obiektow  (Przeczytany 6908 razy)

Offline Esidar

  • Użytkownik

# Maj 27, 2007, 01:45:42
Ok, ale zalezy mi na odpowiedzi Esidara jako, iz ma on podobna wizje budowy silnika jak ja.

No nie do końca :) Nie jestem zwolennikiem hermetyzacji i enkapsulacji silnika czy jakiejkolwiek jego części. Moim zdaniem wszystkie wspólne elementy powinny być w miarę możliwości łączone i używane przez różne elementy silnika. Gdy się pisze silnik do gry, to się go tworzy jako całość, nie jako zlepek funkcji ogólnego przeznaczenia :) Tak więc wszelkie dane które posiadają różne elementy, powinny być dostępne przez każdy inny element, zwłaszcza jeśli dane zajmują bardzo dużo.

Metoda którą Ci podałem czyli komponentowa hierarchia dynamiczna, pozwala głównie na łatwe zarządzanie kodem. Ułatwia dynamiczne, bez konieczności ingerencji w kod, zmienianie struktury obiektów (w przeciwieństwie do zwykłego dziedziczenia klas), ułatwia synchronizację danych między kilkoma wątkami i różnymi bibliotekami, ułatwia rozszerzanie możliwości silnika bez ingerencji w jego strukturę/powiązania. Przyśpiesza przetwarzanie logiki (przetwarzane są tylko obiekty które posiadają konkretny komponent) itd itp :) Ta metoda rozwiąże problemy w twoim silniku, ale to tylko "efekt uboczny", pokazujący jak uniwersalna jest to metoda :)

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

upshader

  • Gość
# Maj 27, 2007, 01:55:50
Ta metoda rozwiąże problemy w twoim silniku, ale to tylko "efekt uboczny", pokazujący jak uniwersalna jest to metoda :)

Ale ta metoda wyklucza sie z wspoldzieleniem drzewa OCT(i innych struktur) przez rozne moduly! Sam napisales, ze moduly nie widza sie wzajemnie i nie wiedza nic o sobie. Zgadza sie?

Offline Esidar

  • Użytkownik

# Maj 28, 2007, 20:00:37
Można np. w ten sposób.

    objekt = new GOS();
    obiekt->AttacheComponent( "VisualizationComponent", "Human.model" );
    obiekt->AttacheComponent( "LogicComponent", "Rycerz.logic" );

class VisualizationComponent : GOSComponent
{
    VisualizationComponent( string plik_z_definicja, GOS* obiekt )
    {
        OctTreeComponent* octtree = obiekt->AttacheComponent( "OCTTree" );
        FasadaGrafiki->UstawOctTree( octtree->GetOctTreeStruct() );
    }
};

class LogicComponent: GOSComponent
{
    LogicComponent( string plik_z_definicja, GOS* obiekt )
    {
        OctTreeComponent* octtree = obiekt->AttacheComponent( "OCTTree" );
        FasadaLogiki->UstawOctTree( octtree->GetOctTreeStruct() );
    }
};


Jeśli pamiętasz, metoda AttacheComponent dodaje nowy komponent lub zwraca już istniejący.

Tak też można:

    objekt = new GOS();
    obiekt->AttacheComponent( "VisualizationComponent", "Human.model" );
    obiekt->AttacheComponent( "LogicComponent", "Rycerz.logic" );

class VisualizationComponent : GOSComponent
{
    VisualizationComponent( string plik_z_definicja, GOS* obiekt )
    {
        FasadaGrafiki->UstawOctTree( FasadaOctTree->GetOctTreeStruct() );
    }
};

class LogicComponent: GOSComponent
{
    LogicComponent( string plik_z_definicja, GOS* obiekt )
    {
        FasadaLogiki->UstawOctTree( FasadaOctTree->GetOctTreeStruct() );
    }
};


A najlepiej oczywiście jest zrezygnować z hermetyzacji (chociażby z powodów które wcześniej wymieniłem) i poprostu udostępnić wszelkie moduły/obiekty/części silnika całemu silnikowi, tak żeby każdy element mógł korzystać z każdego elementu. Oczywiście komponentów można użyć mimo wszystko z powodów o których też wcześniej pisałem :)


upshader

  • Gość
# Maj 28, 2007, 20:19:23
I wtedy zaden modul (graficzny ani logiczny) nie zawiera bezposrednio OCTTree, tylko OCTTree jest oddzielnym modulem?
Tylko wtedy modul logiczny musi widziec OCTTree (wkoncu z niego korzyta) ktore jest w oddzielnym module. Czyli jest zlamana ta zasada o ktorej pisales ze moduly nie widza sie nawzajem (nie wiedza o sobie).
« Ostatnia zmiana: Maj 28, 2007, 20:23:10 wysłana przez upshader »

Offline Esidar

  • Użytkownik

# Maj 28, 2007, 21:55:34
Tylko wtedy modul logiczny musi widziec OCTTree (wkoncu z niego korzyta) ktore jest w oddzielnym module. Czyli jest zlamana ta zasada o ktorej pisales ze moduly nie widza sie nawzajem (nie wiedza o sobie).

Heh :)

Komponenty wiedzą o wszystkich modułach z których korzystają. Czyli komponent Visual i Logic wiedzą o OCTtree... Visual wie o grafice, Logic wie o logice... inne nie muszą jeśli nie potrzebują :)
Mam wrażenie, że już nie do końca wiesz o co Ci chodzi w tej całej hermetyzacji :) Tak jakbyś chciał aby nikt o niczym nie wiedział i wszystko jakoś magicznie łączyło się w jestestwie czasoprzestrzeni :)

upshader

  • Gość
# Maj 28, 2007, 22:47:55
Dziwisz sie, ze nie rozumiem? Przeciez, Ty nawet nie odpowiadasz na moje pytania z watpliwosciami wiec jak mam zrozumiec Twoje nazewnictwo i wizje. Pytalem czy wedlug Twojej interpretacji OCTTree jest modulem? Nie odpowiedziales.
Po tym fragmencie
OctTreeComponent* octtree = obiekt->AttacheComponent( "OCTTree" );
mniemam, ze OCTTRee ma byc "komponentem". Ale jak by to mialo wygladac? Z tego co zrozumialem z Twoich dotychczasowych opisow komponenty tworze juz w "GameSystem" czyli tam gdzie pisze juz sama gre (GameSystem nie nalezy do silnika) a OCTTree musi nalezec do silnika skoro korzystaja z niego moduly silnikowe.
Chbya najlepiej byloby gdybys w kilku zdaniach opisal ta cala ideologie modulo-komponentow ;)
Po urwanych z kontekstu abstakcyjnych fragmentach kodu ciezko odkryc Twoja wizje.

Pozdrawiam.

//EDIT
Oczywiscie, gdzies musi byc "styk" tych wszystkich modulow. I gdzies musza sie one ze soba kontaktowac. Z tego co zrozumialem (i z tego co ja rowniez uwazam za sluszne) jedynym takim miejscem powinien byc pozasilnikowy GameSystem. Z tego co twierdziles wczesniej MODULY MAJA NIE WIDZIEC SIEBIE NAWZAJEM. Cytuje:
Jeśli użyte są wszystkie 3 paterny, to uzyskasz enkapsulację jakiej oczekujesz:
1. Żaden z modułów nie musi wiedzieć o istnieniu pozostałych modułów (renderer nie musi wiedzieć o istnieniu logiki)
Natomiast jesli uwazasz OCTtree za modul musi on wiedziec o istnieniu zarowno modulu logicznego jak i graficznego. Ba, musi byc nawet bardzo silnie z nimi powiazany! I gdzie tu spojnosc logiczna?

//EDIT2
Cytuj
Komponenty wiedzą o wszystkich modułach z których korzystają.
Czemu Ty mi mowisz o komponentach? Ze komponenty wiedza o modulach z ktorych korzystaja to jest jasne. Ale ja nie o to pytalem i nie o tym mowilem. Mowilem O MODULACH
To moduly mialy nie wiedziec o sobie nawzajem (cytat wyzej). A jesli OCTtree jest modulem i Renderer jest modulem to te moduly musza wiedziec o sobie i spojnosc logiczna wizji budowy silnika ktora przedstawiles rozpada sie jak stluczona szklanka.
Odpowiedz na ponizsze pytanie:
czy OCTtree jest "modulem" czy "komponentem"?

/EDIT3
Znalazlem jeszcze jeden Twoj cytat ktory moim zdaniem nie bardzo ma sie do Twoich ostatnich wypowiedzi:
Cytuj
Komponenty są widoczne tylko wewnątrz modułu "GameSystem".
Skoro komponenty sa widoczne tylko w GameSystem, to jakim cudem Renderer widzi OCTTree?
« Ostatnia zmiana: Maj 29, 2007, 00:54:33 wysłana przez upshader »

Offline Esidar

  • Użytkownik

# Maj 29, 2007, 23:14:38
GameSystem nie nalezy do silnika
To również część silnika. Jest to tak samo ważny element silnika co moduł dźwieku czy grafiki. Jest on też tak samo "stały". Raz napisany może być wykorzystany do wielu gier. Na samej grafice gry się nie zrobi. Tak samo jak na samym dźwięku czy na samym GameSystemie. Wszystko musi tworzyć jednolitą całość.

Cytuj
Chbya najlepiej byloby gdybys w kilku zdaniach opisal ta cala ideologie modulo-komponentow ;)
Komponenty nie są powiązane z ideą modułów. One nie wymuszają podziału całego silnika na jakiekolwiek części. Mogą działać w dowolnej konstrukcji silnika.
Kilka linków do opisu:
http://www.drizzle.com/~scottb/gdc/game-objects.ppt
http://www.gamasutra.com/features/gdcarchive/2003/Duran_Alex.ppt
http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

Cytuj
czy OCTtree jest "modulem" czy "komponentem"?
Jest zwykłą strukturą danych wspólną dla wielu elementów silnika. Dla grafiki, dla fizyki, dla dźwięku. Takich wspólnych struktur jest więcej, np. FileSystem lub zasoby modeli (np. model wczytywanego obiektu może mieć 2 meshe. Dla grafiki i dla fizyki).

Cytuj
Skoro komponenty sa widoczne tylko w GameSystem, to jakim cudem Renderer widzi OCTTree?

Tak jak napisałem:
FasadaGrafiki->SetOctTree( globalne_octtree );


I nie chodziło mi o to, że nie rozumiesz co ja piszę, tylko o to, że sam nie wiesz co chcesz osiągnąć zamykając każdą klasę na cztery spusty, drzwi pancerne i plaster :)
Jak już pisałem nie jestem zwolennikiem hermetyzacji i enkapsulacji silnika. Zazwyczaj każdy kto w ten sposób pisze silnik, zastanawia się "jak mam go pozabijać gwoździami żeby nic się nie dało z nim zrobić". A każdy powinien myśleć "jak mam go maksymalnie otworzyć i uprościć, żeby zrobić na nim cuda wianki" :)