Architektura serwerów dla gier wieloosobowych?

Question

Mam zamiar zbudować małą grę wieloosobową, którą można uruchomić jako applet java lub plik flash w przeglądarce internetowej. Nie robiłem wcześniej żadnego programowania serwera, więc zastanawiam się, jaką powinienem mieć architekturę serwera.

Z łatwością utworzę pliki perl/php na serwerze, z którymi kontaktuje się java/flash code, aby zaktualizować pozycję gracza/akcje itd. Ale zastanawiam się, czy powinienem otrzymać dedykowaną stronę host, który system operacyjny ma obsługiwać, którą bazę danych itp. Uwzględnia się również ilość wykorzystanej przepustowości i skalowalność.

Inną opcją może być wykorzystanie systemu hostingu chmurowego (w przeciwieństwie do serwera dedykowanego), więc zadbają o dodanie dodatkowych maszyn w miarę rozwoju gry. Dopóki każdy serwer uruchamia podstawowe pliki perl/php w celu aktualizacji bazy danych, powinien działać poprawnie.

Jeszcze inną opcją może być używanie silnika aplikacji Google.

Wszelkie przemyślenia dotyczące architektury serwera, wyboru systemu operacyjnego i bazy danych oraz tego, czy moja metoda używania skryptów perl/php/python do programowania po stronie serwera jest dobra, zostanie doceniona!

Answer 1

Musisz wyjaśnić więcej na temat gry i lepiej poznać architekturę niż konkretne szczegóły implementacji.

Główne pytanie dotyczy tego, czy twoja gra będzie rozgrywana w czasie rzeczywistym, turowym czy w oparciu o długie opóźnienia (np. Szachy e-mail). Kolejne pytanie brzmi, czy zamierzasz zamrozić państwo do kolejnych przeładunków.

Zdecydowanie zaleca się ustalenie z wyprzedzeniem, czy wszyscy gracze w tej samej grze będą hostowani na tym samym serwerze (np. 1000 meczów 4 graczy w porównaniu do 4 meczów po 1000 graczy każdy). Jeśli to możliwe, idź za pierwszym i trzymaj wszystkich, którzy są w tej samej grze pod tym samym serwerem. Będziesz mieć wystarczająco dużo czasu na synchronizowanie wielu klientów z jednym serwerem, zamiast posiadania wielu serwerów, przeciwko którym gracze są zsynchronizowani. W przeciwnym razie definicja spójności jest problematyczna.

Jeśli to możliwe, każdy klient powinien komunikować się z serwerem, a następnie z serwerem rozpowszechniającym aktualizacje dla klientów. W ten sposób masz jedno "oficjalne państwo" i możesz wykonywać różne rozwiązania konfliktu, fantomy, itp. Peer to peer zapewnia lepszą wydajność w szybszych grach (np. FPS), ale wprowadza mnóstwo problemów.

Nie mogę do końca życia zobaczyć przekonujący powód, aby to zrobić i perl lub PHP. Twoja gra nie jest oparta na Internecie, dlaczego piszesz ją w języku opartym na sieci? Użyj dobrego starego J2EE dla serwera i wymieniaj dane z klientami za pomocą XML i AJAX. Jeśli to możliwe, uruchom prawdziwą aplikację Java na klientach, a nie na serwletach. Możesz wtedy skorzystać z JMS, który odciąży Cię ogromnie, przez zsumowanie wielu szczegółów komunikacji dla ciebie.

Answer 2

Dla architektury twojego serwera możesz rzucić okiem na Three Rings' code. Napisali wiele bardzo skalowalnych gier w Javie (zarówno po stronie klienta, jak i po stronie serwera).

Answer 3

Chciałbym również zniechęcić do korzystania z PHP, również HTTP nie jest najlepszym pomysłem, ponieważ jest bezpaństwowy i rozmowny. Pracowałem przez jakiś czas w firmie, która obecnie tworzy naprawdę masywną grę dla wielu graczy. Back-end to zwykła JVM (połączenie przez tomcat przez wielu klientów i z telefonów komórkowych po jednym kliencie). Tak więc wiem, że im mniej danych przesyłasz mniejsze bufory na serwerze -> więcej klientów na jednym komputerze, a także nieco szybsze odpowiedzi. Weź również pod uwagę bezpieczeństwo, https jest dość drogi, zwłaszcza jeśli potrzebujesz przenieść grafikę i dźwięki.Protokół Binnary z kontenerem klienta spoza przeglądarki będzie działał najlepiej (dobrym wyborem jest protokół przełączany na czas projektowania i debugowania). Może brzmi skomplikowanie, ale tak nie jest.

@ Sarah dobra podpowiedź, dzięki też;)