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

[NuLL]

wyszłoby mi ponad 600 klas co jest niedopuszczalne i nieelastyczne

A dlaczego niedopuszczalne ?

[KOMPsognat]

Ech... złe słowo Ale nieelastyczne jak najbardziej. Na jeden budynek przypadałoby wtedy 20 klas (nie licząc interfejsów), więc nie jest to najlepsze rozwiązanie.

Wydaje mi się, że to z bazą danych jest najlepszym rozwiązaniem, gdyż wtedy wszystko można by zmodyfikować z poziomu panelu admina, ale czekam na inne propozycje.

PS. Przy aktualnym systemie należy do tych 600 klas dolicz ok. 200 klas dla jednostek i 100 dla różnych bogów w świątyni... Wychodzi spora liczba samych danych, a modyfikacja tego to byłby koszmar.

Ten post edytował KOMPsognat 3.02.2007, 15:24:59

[dr_bonzo]

Kilka przemyslen, moze cie gdzies doprowadza.
[przyjmuje do obliczen 4 pory roku, 3 klasy]

1. pora roku nie moze byc zapisana w klasie budynku, bo gdy zmieni sie pora roku ot bedziesz musial wymienic obiekt budynku (zniszczyc stary utworzyc nowy), czyli SpringCarthageBakery odpada.

2. jak bardzo sa podobne sa do siebie budynki? Wszystkie maja tylko atrybut Produkcja? czy roznia sie ? Produkcja Tego, Prod. Tamtego,inny budynek Tego nie produkuje?

3. jak bardzo roznia sie od siebie budynki roznych ras? To sa te same budydnki rozniace sie tylko wielkoscia produkcji? czy kazda rasa ma specyficzne budynki, o roznej produkcji?

4. jak bardzo rozne sa reguly modyfikujace produkcje? Dla danej pory roku i danej rasy modyfilkator dla wszystkich budynkow bedzie taki sam (4x3 klas) czy inny (4x3xilosc_rodzai_budynkow)?

5. przechowywanie modyfikatorow (dla pogody i rasy) w samym budynkow tez odpada: dodanie nowej rasy to wyedytowanie wszystkich klas budynkow

//
6. Wlasciwie wszytko zalezy od jednolitosci budynkow i jednolitosci wyznaczania modyfikatorow. Jesli budynki sa identyczne a modyfikatory wyrazaja sie "pojedynczym" prostym wzorem

i wtedy:

[PHP] pobierz, plaintext 
<?php
$modifier = $season->getProductionModifierFor( $player->race );
$production = $building->getProduction( $modifier )
...
function getProduction( $mod )
{
	return $this->baseProduction * $mod
}
 
// albo
 
return $mod->modifyProduction( $this->baseProduction )
?>
[PHP] pobierz, plaintext 

A jak to w samej bazie wyliczac? -- woooo, nie wiem

[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.

[dr_bonzo]

1-6.
Sorry -- myslalem za bardzo OOP i o aplikacji dzialajacej w czasie rzeczywistym a nie uruchamianej z kazdym requestem



Jak chcesz to z bazy czytac to raczej proscizna:
- w jednej tabeli masz budynki + ich podstawowa produkcje
- w drugiej dla kazdego budynku masz kilka rekordow z modyfikatorami dla (danej pory roku)X(danej rasy)

lub wrzuc do jednej tabeli z koncowymi wartosciami produkcji.

[KOMPsognat]

Tak też od początku myślałem, ale wpadała mi do głowy jeszcze taka myśl. Brały by udział trzy klasy: budynek (np. Bakery), plemię (np. Carthage) oraz sezon (czyli np. Winter). I teraz widzę to tak:

1. Konstruktor budynku oczekuje nacji gracza
2. Następnie tworzy egzemplarz klasy nacji i pobiera z nich tylko interesującą tablicę (w tym wypadku Bakery) z modyfikatorami parametrów budynku
3. Podczas tworzenia klasy Carthage ta wywołuje konstruktor klasy Winter która zwraca modyfikatory dla danego budynku danej nacji.
4. Klasa Carthage zwraca już dane po "konfrontacji" z danymi z klasy Winter.
4. Gdy klasa Bakery otrzyma wszystkie dane to zwraca ostateczny koszt budynku.

Wymyśliłem to na szybko jadąc w tramwaju, ale może coś się z tego się urodzi coś sensownego. Bardzo prosiłbym o opinie na ten temat.

Aha. Nie przejmujcie się chwilowo modyfikacją parametrów tych poszczególnych klas... Jako tako również mam to obmyślane.

----------
Edit:
----------
Kolejne przemyślenia:

Całkiem przez przypadek wyszedł mi z tego co wyżej napisałem najzwyczajniejszy dekorator:

[PHP] pobierz, plaintext 
<?php
$object = new Winter(new Carthage(new Bakery($lvl)));
?>
[PHP] pobierz, plaintext 

1. Klasa Bakery zwracałaby podstawową cenę.
2. Klasa Carthage sprawdza jaki to budynek i wybiera odpowiednie modyfikatory:

[PHP] pobierz, plaintext 
<?php
//tablica
$mods = array(
		'Bakery' => array ('tutaj modyfikatory'),
		'Następny budynek' => array ('modyfikatory'));
 
 
//konstruktor klasy Bakery
public function __construct($building) {
	return $this->mods[get_class($building)];
}
?>
[PHP] pobierz, plaintext 

3. Na podobnej zasadzie działa klasa Winter, zwracając kolejną tablicę po modyfikacjach.

Ten post edytował KOMPsognat 4.02.2007, 08:25:03

[dr_bonzo]

Dekorator to nie bedzie, bo w dekoratorze wszystkie klasy musza byc z tej samej hiearchi, czyli Winter musialby byc Budynkiem, tak samo jak i nacja/rasa.

http://www.dofactory.com/Patterns/Diagrams/decorator.gif

[PHP] pobierz, plaintext 
<?php
public function __construct($building) {
	return $this->mods[get_class($building)];
}
?>
[PHP] pobierz, plaintext 

To nie przejdzie w takiej formie Konstruktor niczego nie moze zwracac, wiem, pospiech itd.

[KOMPsognat]

Ad.1. Równie dobrze można to nazwać WinterDecorator. Tak mi było szybciej Ważne, że miało działać na podobnej zasadzie.

Ad.2. Ostatnio przyszło mi pracować na PHP3, więc jeszcze nie wróciłem do siebie Trochę bez sensu byłoby użycie return w konstruktorze

PS. Problem rozwiązany. Moje cholerne nawyki po niedawnej pracy w przestarzałej wersji php. Po cholerę samym kosztom wydzielać klasę Zrobię po prostu stałe z cenami i gotowe.

PS.2. Wystarczy to rozwiązać w taki sposób:

[PHP] pobierz, plaintext 
<?php
  $building = new Bakery($season, $tribe, $lvl);
?>
[PHP] pobierz, plaintext 

a konstruktor będzie składał to w całość z wartości zapisanych w stałych.

Ten post edytował KOMPsognat 4.02.2007, 14:12:20

[Secator]

Swoją drogą w nie lepiej stosować czegoś w stylu:

funkcja pobierzcene( )
{
cena = cena_podstawowa* (1 + rasa1*2 + rasa2*2) + 666*zima +333*wiosna -100*lato
return cena
}

gdzie rasa1 = 1 jesli gracz jest rasą 1, zero jesli jest jakąs inną i podobnie z innymi parametrami...
(w tym wypadku przy cenie podstawowej 1000 cena w lecie dla rasy 1 wynosi np.
3*1000-100=2900)

Jest to chyba prostsze i do wykonania i do późniejszych modyfikacji i wystarczy wtedy mieć tyle klas ile jest różnych budynków bedacych rozszerzeniem klasy budynek zawierajacej wszystko to co każdy budynek posiada ;]
edit:: Ew. żeby budynek dziedziczył modyfikatory po klasie nacji zawierajacej parametr 'pora roku'??

[KOMPsognat]

Napisałem, że modyfikatory są zróżnicowane. Nie ma zasady, że u rasy1 będzie zawsze 0.7 a u rasy2 1.3 . Modyfikator jest różny dla każdego budynku itp.

Co do rozwiązania problemu. Rozwiązałem to w taki sposób:

Struktura:

Kod

costs
|- rasa1.php
|- rasa2.php
|- ...

Kod poszczególnych plików:

[PHP] pobierz, plaintext 
<?php
  $budynek1 = array(
				   'Winter' => array('Gold' => x, 'Wood' => x, '...'),
				   'Spring' => array('Gold' => x, 'Wood' => x, '...'),
				   '...' => '...'
				   );
 
  $budynek2 = array(
				   'Winter' => array('Gold' => x, 'Wood' => x, '...'),
				   'Spring' => array('Gold' => x, 'Wood' => x, '...'),
				   '...' => '...'
				   );
?>
[PHP] pobierz, plaintext 

Oraz sama implementacja:

[PHP] pobierz, plaintext 
<?php
  //...
  public function getCosts($lvl, $season, $tribe)
  {
	include_once ('./costs/'.$tribe.'.php');
	return $$this->building[$season]; //zmienna building przechowuje informacje jaki to budynek
  }
  //...
  print_r($building->getCosts(x, 'Winter', 'Romans');
?>
[PHP] pobierz, plaintext 

[KG-]

No i to jest wg mnie najlepsze rozwiązanie, bawienie się w 600 klas z dziedziczeniem i dekoratorami, jeśli można coś zrobić dużo łatwiej na tablicach to zdecydowanie przerost formy nad treścią, w końcu gra docelowo będzie obsługiwana przez tysiące ludzi więc chodzi o to żeby kod działał jak najszybciej (i jednocześnie był łatwy w modyfikacji)

Jedynie zamiast zmiennych $budynek1, $budynek2 itd zrobiłbym po prostu tablice budynków, chyba że to ma jakiś głębszy sens którego nie dostrzegam

[Secator]

Napisałem, że modyfikatory są zróżnicowane. Nie ma zasady, że u rasy1 będzie zawsze 0.7 a u rasy2 1.3 . Modyfikator jest różny dla każdego budynku itp.

Myśle ze trzymanie modyfikatorów jako zmiennych nie jest problemem... ale rób jak chcesz :] Sam wiesz lepiej co Ci jest potrzebne.

Swoja droga to wydaje mi sie że ta gra bedzie tak skomplikowana że gracze nie beda w stanie sie połapać X budynków dla Y nacji z Z parametrami zależnych od Ź czynników... :] Masz już jakąs wersje beta do testów?? Chętnie bym po testował, może własnie coś wartego uwagi powstaje

pozdro

Ten post edytował Secator 8.02.2007, 23:06:36

[KOMPsognat]

Hehe... akurat w tym przecież nie ma nic trudnego (z punktu widzenia gracza). Każda rasa ma inne ceny budynków i ich produkcję. Trudności może przynieść obsługa pór roku, ale myślę, że gracze sobie poradzą.

Co do bety: Chwilowo nie ma. Co do możliwości gry:

• 5 nacji: Kartagina, Partia, Rzym, Egipt, Grecja
• 4 pory roku
• ok. 30 budynków: http://atofaq.yoyo.pl
• 10 jednostek na każdą nację.
• możliwość "zbierania" i handlowania niewolnikami.
• losowe zdarzenia zależne od zadowolenia bóstw w świątynii
• zaawansowany system bitewny: możliwość grupowania w oddziały, generałowie, dowódcy, formacje wojenne, typy ataku (szarża lub normalny), doświadczenie oddziałów...
• hołd lenny (przydatna opcja dla osób, którym nie chce się farmić :] )

Ten post edytował KOMPsognat 9.02.2007, 17:48:54

[bacca]

Miałem kiedyś taki problem. Jeśli mogę jakoś pomóc to spróbuję.

1. Olej zawieranie takich ilości powiązanych danych na twardo w kodzie. Zrób sobie klasę (lub kilka), która odczytuje swoje parametry dynamicznie na podstawie otrzymanych parametrów. Zrób sobie tabelę i z niej odczytuj wszelkie parametry budynków. W ten sposób znacznie ograniczysz liczbę klas.

2. Zrób sobie edytor parametrów do obsługi tejże tabeli. Tak, żebyś sobie dla danej rasy i pory roku i typu budynku edytowal parametry. W ten sposób łatwiej Ci będzie wypełnić tabelę danymi i korygować późniejszą rozgrywkę.

3. Wszelkie możliwe konfiguracje parametrów danego budynku serializuj i buforuj np. do pliku, żeby nie zarzynać bazy milionami odczytów.

4. Możesz się też zapoznać z wzorcem Prototype i technikami buforowania. To załatwi problem całkowicie.

Gdybym wyraził się niejasno spróbuję zilustrować pseudokodem.

[PHP] pobierz, plaintext 
<?php
class Budynek {
private $nazwa;
private $rasa;
private $typ;
private $cena;
private $produkcja;
// itd....
 
public function __construct($typ, $rasa, $pora_roku, $itd, $itp) {
  $result = $db->query('SELECT * FROM `budynki` WHERE `rasa` = $rasa AND `pora_roku` = $pora_roku itd.it
p. ');
	foreach ($result as $prop) {
	  $this->$propname = $prop;
	}
}
}
?>
[PHP] pobierz, plaintext 

U mnie wyglądało w dużym uproszczeniu mniej więcej tak. Na pocieszenie dodam, że problem da się rozwiązać w kilku do kilkunastu klasach. Powodzenia

[KOMPsognat]

Chyba zostanę przy swoim pomyśle, gdyż nie będzie trzeba wykonywać zapytania SQL. Podane pliki z cenami będą generowane automatycznie z poziomu admina, więc modyfikacje będą w miarę wygodne.

[bacca]

Przeczytaj jeszcze raz punkt 3. i 4. Naprawde da sie w ten sposób uzyskać całkiem wydajny sposób odczytywania tych danych.

[KOMPsognat]

No to muszę przyznać, że Twój sposób drastycznie różni się od mojego...
Poza tym wydaje mi się, że zapis w postaci tablicy będzie po prostu szybszy (choć testów nie przeprowadzałem). Modyfikacje tego z poziomu admina będą zapisywane w bardzo łatwy sposób - skasowanie i utworzenie nowych plików z cenami.

Trudne? Nie sądzę.
Elastyczne? Tak.
Szybkie? Tak.

Same zalety :]

[Ace]

heh... Nie po to sa bazy danych, zeby zapisywac potrzebne rzeczy w plikach...

To moze zrob sobie zarzadzanie tego z poziomu bazy, a takie generowanie plikow php z dokladnymi informacjami potraktuj jako cache?

Ja osobiscie wykonalbym to na bazie danych. Latwo znalezc, latwo zmienic, latwo dodac.

[KOMPsognat]

I łatwo zerżnąć komputer. Jeżeli mam wykonywać ok. 1000 zapytań na sekundę po same ceny to ja dziękuję...