Fri
27
Jul 2007

Architektura całej gry, choć nie o nią mi w obecnej chwili chodzi, przewija się w literaturze którą obecnie analizują i też mnie interesuje. Szczególnie, że ilekroć staję przed tym zadaniem, zawsze mój kod zamienia się w jedną wielką kulę błota, w której wszystko korzysta ze wszystkiego beztrosko rzutując klasy w dół hierarchii dziedziczenia. Ciekawy wątek forum na ten temat jest TUTAJ.

Wyczytałem właśnie, że architekturę gry można podzielić na:

• Wielowarstwowa, w której kod podzielony jest na warstwy, a każda z nich korzysta tylko z warstw niższych i oferuje pewne usługi dla warstw wyższych, o których nic nie wie.
• Z centralną bazą danych (repozytorium), która przechowuje wszystkie dane gry i do której odwołują się niezależne od siebie podsystemy np. grafiki, dźwięku czy fizyki.
• Z niezależnymi komponentami, które komunikują się między sobą wyłącznie za pomocą przesyłania jakiś określonych komunikatów.

Wprowadzanie takich podziałów wydaje się trochę na siłę, szczególnie że można tu wymyślić jeszcze dużo innych opcji. Gdzieś kiedyś na forum pisali nawet o takiej, w której każdy obiekt gry posiadać ma swoje pod-obiekty odpowiedzialne za grafikę, dźwięk, fizykę itd. Tylko czy coraz większe komplikowanie rozwiązuje ten i tak skomplikowany problem? :)

Comments | #algorithms Share

Comments