Projekt karcianej gry multiplayer przez przeglądarkę

[gdp (Kroszka K)]

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!

[kostek135]

Czy zastosowanie AJAX i ewentualnie HTML 5 + PHP + MySQL będzie dobrym rozwiązaniem?

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

 

W jaki sposób rozwiązać problem dwustronnej komunikacji na żywo? WebSocket, Long Polling, czy zwyczajne odświeżanie co 1 sekundę?

WebSocket.

 

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ć?

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.

W jaki sposób wykrywać rozłączenie gracza, tak aby można było mu doliczyć dodatkowy czas na akcję w grze?

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.

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

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]

 PHP i MySQL się nie nadadzą.  

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

 

Java odpada

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]

 a to świetny język (JSP) 

 

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

[kostek135]

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

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óż…

 

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

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.

[angh]

• 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?

@1: ajax, w sensie natywnie? po co, jezeli sa rameworki oszczedzajace tego problemu?
php i mysql bedzie oczywiscie dzialalo, o ile dobrze napisane. Ale taki typ rozgrywki prosi sie o microservices / websockets. Moze zainteresuj sie Node.js, a dokladniej jakis framework na to? NUXT integruje Vue, mialbys wszystko w jednym z porzadnym testowaniem rowniez.
mysql to tylko baza danych. Kazda baza danych bedzie dobra, dopoki nie osiagniesz wielkiego sukcesu. I zapomnij o DB2/Oracle. To szalenstwo w tym zastosowaniu (pracuje na tego typu DB). Wystarczy dowolna DB, a najprosciej byloby uzyc jakiejs chmurowej DB do tego - mozesz zaczac z zmazon lub google, na male oblozenie bedzie darmowe, a na wyzszych bedziesz mial pieniadze, zeby to oplacic.

@2 tylko websocket. Inne rozwiazania zabija wydajnosc.

@3 na chmurze. Heroku + jakas DB. Moze byc PostreSql na heroku rowniez, ale ja wybralbym chmure. Odpada problem konfiguracji, padow i tak dalej. W dodatku, brdzo tanie rozwiazanie na poczatek.

@4. nijak. Jezeli nie wykona akcji w wymaganym czasie, jego strata. Kazdy nadmiarowy feature, czy obsluga sytuacji wyjatkowej to dramatyczne zwiekszenie szansy na pomylke, dodatkowy kod, wyjatki, ktorych sie nei spodziewasz. Krotka pilka - nie ma akcji, to akcja defaultowa (pass, poddanie, cokolwiek). Ale pamietaj, ze stan gracza musi byc zapamietany ba serwerze. Jezeli padnie mu windows, i zaloguje sie z laptopa w wymaganym czasie, to powinien widziec swoj stan taki sam, jak w momenci crashu.