Gra internetowa - hierarchia klas Opcje

[KOMPsognat]

Witam!
Wiem, że jest już jeden temat o tym samym zagadnieniu, lecz dyskusja tam jest według mnie bez sensu.

Do rzeczy: piszę aktualnie dość zaawansowaną grę i chciałbym, żeby była jak najbardziej elastyczna. W grze jest kilka ras (każda ma inne ceny budynków, produkcję itp... ) oraz niektóre parametry są zależne od pory roku (jak na przykład produkcja). Wydaje się, że wystarczy zastosować dekorator, lecz sprawa jest trochę bardziej skomplikowana. Różne pory roku w mniejszym lub większym stopniu modyfikują parametry u różnych ras. Na chwilę obecną było mnóstwo różnych klas w stylu WinterCarthageBakery, SpringCarthageBakery... więc w finalnej wersji wyszłoby mi ponad 600 klas co jest niedopuszczalne i nieelastyczne. Kolejnym pomysłem było coś takiego:

Każda klasa budynku dla danej rasy dziedziczyłaby po jakiejś klasie abstrakcyjnej w której zaimplementowany byłby mechanizm wyboru odpowiedniej zmiennej z danymi (tzn. czy zimową czy może letnią tablicę z kosztami).

W ten sposób ograniczyłbym liczbę klas do ok. 150, lecz rozwiązanie znowu nie jest zbyt elastyczne.

Może macie jakiś propozycje, jak zbudować elastyczniejszy system? Może trzymać ceny w bazie danych i cache'ować tylko te dla danej pory roku? Czekam na wszystkie opinie na ten temat.

Ten post edytował KOMPsognat 10.02.2007, 19:34:20

[KOMPsognat]

Ad.1. Czemu odpada? Mam powiedzmy porę roku pobraną z bazy danych i zapisane w jakiejś zmiennej, rasę gracza i typ budynku. Z tego wszystkiego można skonstruować odpowiedni obiekt:

[PHP] pobierz, plaintext 
<?php
  $class = $season.$tribe.$building;
  $object = new $class($level);
?>
[PHP] pobierz, plaintext 

Ad.2. Każdy budynek ma zapisaną w sobie cenę, produkcję na godzinę oraz kilka atrybutów specyficznych dla danego budynku. Wszystkie mechanizmy są dziedziczone po klasie abstrakcyjnej budynku.

Ad.3. Budynki różnią się produkcją i ceną. Specyficzne budynki po prostu nie mają nazwy klasy z przedrostkiem innej rasy niż tej u której występuje.

Ad.4. I tu jest pies pogrzebany. Modyfikacje mogą być różne. To zostanie podniesione, a to wręcz przeciwnie. W zimie u jednej rasy może być coś zwiększone a u innej zmniejszone.

Ad.5. Dodanie nowej rasy to nie modyfikowanie, lecz dodanie ok. 140 klas (na chwilę obecną).

Ad.6. Co do samej bazy danych. Na chwilę obecną widzę to tak: tabele w formacie "SezonRasa" i tam zapisane ceny i produkcja. Te dane byłyby cachowana przy każdej zmianie pory roku. W sumie działa to tak samo jak te setki klas w formacie SezonRasaBudynek, ale modyfikacje łatwiejsze.