Autor Wątek: Gry on-line  (Przeczytany 4055 razy)

Offline BTM

  • Użytkownik

# Sierpień 05, 2008, 18:38:46
W związku z założeniem dot. ilości graczy PHP(chyba, że użyjesz hybrydy) po każdym resecie serwer troszkę by "muliło", czyli pozostaje Ruby on Rails
A dlaczego właśnie RoR? Poproszę jeden porządny powód dla którego konfiguracja serwer w C++ i thin client w PHP jest gorsza niż serwer w C++ i thin client w RoR? :-)

Robiąc tylko w języku skryptowym (ASP/JSP/JSF/PHP/RoR czy co tam wolisz) opowiadał bym się raczej za JSP / ASP ze względu na ich pseudo stanowość (obiekty mogą istnieć dłużej niż do czasu wykonania się skryptu).

Offline Mr. Spam

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

Offline Capad

  • Użytkownik

# Sierpień 05, 2008, 18:56:41
Może być przejrzystość kodu, liczne wtyczki, możliwość instalowania tylko wybranych funkcji i cytując Wikipedię:
Cytuj
eguła DRY (ang. Don't Repeat Yourself), polegająca na unikaniu powtarzania tej samej pracy w różnych miejscach

Offline BTM

  • Użytkownik

# Sierpień 05, 2008, 20:27:49
Może być przejrzystość kodu, liczne wtyczki, możliwość instalowania tylko wybranych funkcji i cytując Wikipedię:
Cytuj
eguła DRY (ang. Don't Repeat Yourself), polegająca na unikaniu powtarzania tej samej pracy w różnych miejscach
Znaczy ... piszesz o PHP? :D
Kod mam piękny, liczne wtyczki (PEAR) i instaluję co tylko chce ( ./configure --enable --disable --whateverable :P)

Offline peter

  • Użytkownik
    • BirdStorm.net browser based MMO

# Sierpień 06, 2008, 21:55:03
Pozwolę sobie na wypowiedź od strony technicznej.

Rozwiązanie z serwerem w C++ oraz cienkim klientem w PHP, Ruby czy innym Pythonie ma niemałą wadę... jest niebanalne ;-)
W samym języku skryptowym nie musisz myśleć o wyciekach pamięci, kolizjach wątków, czy ogólnie o wywalaniu się całego serwera przez jeden, drobny błąd.
Do tych typowych problemów dochodzi jeszcze potrzeba zaprojektowania i zaimplementowania dobrze przemyślanego, wydajnego i elastycznego middleware, chyba, że użyjesz gotowca w stylu Corby lub ICE (jeśli już pójdziesz tą drogą to polecam to ostatnie rozwiązanie).
Wypadałoby też zadbać o dobry (najlepiej generyczny) sposób na serializację danych - oczywiście są tu gotowce jak Persistance, ale są to raczej dość drogie i specyficzne produkty.

Jednak rozwiązanie to ma też niemałe zalety:
- dobrze zaprojektowany middleware pozwoli Ci na łatwą podmianę warstwy prezentacji, fe. na migrację ze statycznego HTML'a to Flasha, zapewni też stosunkowo łatwy sposób implementacji wersji na komórki
- rozwiązanie to powinno być znacznie szybsze, niż sam język skryptowy - pal licho różnice w wydajności samych języków, ale stanowość serwera C++ zapewnia diametralny spadek ilości zapytać do bazy
- jest "z natury" skalowalne na wiele maszyn, wspomniany cienki klient może znajdować się na innej maszynie, niż serwer, co więcej skoro klient może się odwołać do obiektu (zakładam system komponentowy) na serwerze to sam serwer może się odwołać do innego obiektu na innym serwerze
- jest ciekawsze dla uczestniczących w projekcie deweloperów (liczba mnoga jest tu nieprzypadkowa)
- zastosowanie statycznie typizowanego języka jest zwykle uważane za zaletę

Generalnie uważam takie rozwiązanie za lepsze, acz trudniejsze. Oczywiście jest to wyłącznie moja, prywatna opinia, acz poparta pewnym doświadczeniem... od dłuższego czasu sam piszę sobie taką grę ;-)

O marketingu czy reklamie nie będę się tu wypowiadał bo się na tym nie znam, ale Kyroman zdaje się mówić całkiem sensownie, ja tam prosty developer jestem ;)
« Ostatnia zmiana: Sierpień 06, 2008, 22:07:59 wysłana przez peter »