Projekt karcianej gry multiplayer przez przeglądarkę


(Kroszka K) #1

Witam,

Jestem w trakcie zastanawiania się nad rozwiązaniami, jakie powinienem zastosować aby stworzyć wieloosobową grę karcianą. Jako punkt odniesienia należy przyjąć jakąkolwiek grę karcianą online, np pokerstars.com (aplikacja Windows/Mac OS X), lub gryonline.wp.pl (JAVA)

 

Założenia i problemy do rozwiązania:

 

  • Gra musi być jak najbardziej uniwersalna, uruchamiana w przeglądarce, bez instalacji dodatkowych wtyczek (Flash i JAVA odpada)
  • Gra musi być wydajna, gdyż (a jak! ;] ) liczę na sukces, czyli duże obciążenie serwera spowodowane bardzo dużą ilością prowadzonych na raz gier (uruchomionych stołów gry)
  • Rozwiązanie problemu dwustronnej komunikacji SERWER<=>KLIENT
  • Hosting
  • Jako że w grze będzie dostępna wirtualna waluta, konieczny jest wysoki poziom bezpieczeństwa
  • Disconnect Protection 

 

A teraz pytania:

 

  • Czy zastosowanie AJAX i ewentualnie HTML 5 + PHP + MySQL będzie dobrym rozwiązaniem?
  • W jaki sposób rozwiązać problem dwustronnej komunikacji na żywo? WebSocket, Long Polling, czy zwyczajne odświeżanie co 1 sekundę?
  • Wiadomo że docelowo, wraz ze wzrostem popularności trzeba będzie zainwestować w wydajne maszyny. Lecz na początek i pierwszy okres rozruchowy na czym to odpalić?
  • W jaki sposób wykrywać rozłączenie gracza, tak aby można było mu doliczyć dodatkowy czas na akcję w grze?

 

Będę bardzo wdzięczny za wzięcie udziału w dyskusji, odpowiedź na powyższe pytania, oraz być może inne sugestie, o których nie pomyślałem.

 

Jako, że brakuje mi trochę umiejętności, będę poszukiwał osoby do współpracy przy projekcie, tak że również potencjalnych zainteresowanych zapraszam.

 

Pozdrawiam! :slight_smile:


(kostek135) #2

Po stronie przeglądarki, jeśli ma to być uniwersalne, to HTML nie jest ewentualny, tylko must have. Natomiast po stronie serwera wymagania jasno wskazują, że PHP i MySQL się nie nadadzą, bo w tym to można napisać program do pchania karuzeli, a nie poważny serwis.

Na bazę danych DB2 albo Oracle.

Java odpada, ale tylko w wersji apletów. Może być to natomiast dobry pomysł, by użyć jej po stronie serwera (np. NYSE chodzi w całości na Javie, bo po przeprowadzenia analizy, nie udało się znaleźć innego języka/dostawcy, który spełniłby warunek dostępu czasu rzeczywistego do zasobów).

Inne języki, które nadadzą się do skalowalnych rozwiązań to C#, Erlang, Scala (kolejność alfabetyczna).

 

WebSocket.

 

Nie podałeś jeszcze rozwiązania, a już chcesz robić sizeing. Good job, Good job… To co powinieneś zrobić to użyć technologii, która pozwala napisać aplikację w oderwaniu od ilości serwerów, a potem zrobić sizeing przy odpowiedni klastrowaniu i tyle. Z fusów nikt ci nic nie wywróży.

Najsensowniej reszcie graczy wyświetlić czas oczekiwania powiedzmy minuta. Jeśli ktoś po tym czasie nie wróci, to założyć, że już nie wróci. Pomoże to w krótkich rozłączeniach, np. ktoś sobie wcisnął krzyżyk od okna przeglądarki, a na długie rozłączenia i tak nic nie poradzisz, chyba, że chcesz zmusić jakoś drugą osobę do oczekiwania 8h, zanim komuś kable naprawią, bo mu myszy przegryzły.

Widełki płacowe. Naprawdę, nie którym nie chce się iść na rozmowę o pracę, tylko po to, żeby usłyszeć, że nie dostaną 8000 na rękę, bo osoba prowadząc firmę myśli, że w IT to popijasz herbatkę i przeglądasz internet i w sumie z 2000 powinieneś być zadowolony.


(kalamita) #3

 To chyba raczej zależy od koncepcji gry. Jest wiele gier typu multiplayer napisanych w PHP (i całkiem  nieźle funkcjonują)

 

WIdzę, że kolega sceptycznie nastawiony do Javy, a to świetny język (JSP)  i doskonale działa jako narzędzie do budowania serwisów internetowych (nie osadzonych na apletach).


(Frankfurterium) #4

 

JSP to niezalecany staroć. Rozwój dosyć dawno przekierował się na JSF.


(kostek135) #5

Po co wyrwałeś moje dwa słowa z kontekstu i piszesz, że jestem sceptycznie nastawiony do Javy, skoro piszę, że jako jedyny język wypalił w przypadku NYSE?

Te dwa słowa odnoszą się do tego co napisał OP. Poza tym jeśli twoja webowa Java kończy się na JSP… no cóż…

 

PHP jest po prostu wolne. A MySQL to wydajnościowy szmelc.

Poza tym w PHP już sam problem stanowi współdzielenie pamięci między użytkowników. W Javie zapewne zrobisz jakąś mapę o konkurentnym dostępie w scopie statycznym i dzięki temu gracze będą się mogli wymieniać informacjami jak wyłożone karty bez udziału bazy danych. Dopiero całość rozgrywki (wynik) zostanie wrzucony do bazy. Zapisywanie go w trakcie nie ma sensu, bo nawet zakładając, że coś padnie, nie wiem jak byś chciał odnaleźć tych graczy i powiedzieć im, dobra panowie powtarzamy grę. Częste operacje dyskowe to zaprzeczenie skalowalności. W PHP zapewne orałbyś bazę jak pole i byś się obudził, że wolne.

PHP może się co najwyżej nadać do gier Request-Response jak Ogame, gdzie tak naprawdę gracz nie jest podłączony do serwera, tylko coś tam se grzebie ustawia cyferki w kratkach formularza i na koniec wysyła to co sobie poklikał raz na 30-60 sekund (i tak naprawdę “gra” naraz 200.000 użytkowników, ale przetwarzanych równolegle jest 500 żądań, bo reszta klika to sobie lokalnie), a nie do karcianki czasu rzeczywistego z założeniem low-latency. W takim przypadku już lepiej użyć Node.js, jeśli nie chcemy uczyć się Javy czy Erlanga, bo za trudne, “PeHaP” był łatwy.