Tworzenie gier multiplayer, a dobre praktyki...

Hej,

W tym semestrze studiów, na przedmiot przetwarzanie rozproszone, miałem ze znajomymi stworzyć grę wykorzystującą sockety.
Postanowiliśmy stworzyć grę akcji (widok z góry jak w GTA, zwykła strzelanka).
Prowadzący zajęcia wymagał jedynie żeby gra była grywalna, oraz musi podłączyć się do niej 4 graczy.

My w sumie nie mieliśmy wcześniej żadnego doświadczenia w grach sieciowych.
Po przedyskutowaniu projektu założyliśmy takie rzeczy:

-projekt będzie miał architekturę klient-serwer,
-klient, jak i serwer będzie dostępny na Linuxa i Windowsa,
-klient i serwer będzie napisany w C++,
-na serwerze będziemy mieli prawie identyczne klasy jak na kliencie (na serwerze klasy będą pozbawione np metod draw, jak i wszystkich innych graficznych elementów)
-serwer jak i klient będą miały odpowiadając sobie obiekty, które będziemy synchronizować między sobą. Oczywiście nie dotyczy to obiektów klienta, które nie wymagają synchronizacji, np wykorzystywana przez nas mapa kafelkowa.
- to serwer będzie pierwszy tworzył obiekt, rozsyłając potem go do innych klientów
- do synchronizacji obiektów i ogólnej komunikacji z serwerem używamy json'a

Po wypisaniu założeń postanowiliśmy użyć do tego SFML 2.1

Jednak po napisaniu gry dotarła do nas bardzo smutny wniosek:
Albo strasznie źle to napisaliśmy, albo nasze założenia były po prostu złe (prawdopodobnie to i to :D ).
Gra nie była grywalna.
Podłączenie 4 graczy powodowało to że serwer nie wyrabiał. Mieliśmy straszne lagi i generalnie był to koszmar.
Próbowaliśmy projekt uratować, i pewnymi trickami to się pewnym sensie udało, ale jak na tak małą liczbę graczy i prostotę gry i tak to wyglądało mizernie w porównaniu  z CS'em czy grami MMORPG.

Czego jesteśmy świadomi, to między innymi tego, że za dużo danych wysyłaliśmy pomiędzy serwerem i klientami, gra była praktycznie jednowątkowa (klient posiadał dwa wątki: wątek główny gry oraz wątek komunikacji z serwerem, a sam serwer był jednowątkowy),a sekcja krytyczna w kliencie była ogromna (na czas synchronizacji klienta z serwerem za pomocą mutexów zatrzymywaliśmy w głównej pętli gry update obiektów, obsługę zdarzeń, oraz rysowanie obiektów).

Co wy o tym wszystkim sądzicie?
Jakie są wasze doświadczenia z takimi grami?
Jakie błędy popełniliśmy już na samym wstępie ?

Ruch siecowy powinien odbywać się na osobnym wątku zarówno do odbierania jak i wysyłania. Oczekiwanie na wyrenderowanie sceny to niepotrzebne generowanie opóźnień. Dobra komunikacja siecowa wymaga sporego nakładu pracy, umiejętności liczenia wysyłanych/odbieranych bajtów danych, znajomości wielowątkowości i przede wszystkim doświadczenia w samodzielnym programowaniu różnych algorytmów (czytaj: kreatywne myślenie, umiejętność samodzielnego radzenia sobie z problemami oraz umiejętność samodzielnego i świadomego wykorzystywania składniowych możliwości używanego języka programowania tak, aby kod był prosty w rozwoju i utrzymywaniu).

Jak znacie JS to wygodniej będzie napisać serwer w NodeJS, a sam klient używając jakiegoś wygodnego silnika np. Phasera.

'Ruch siecowy powinien odbywać się na osobnym wątku zarówno do odbierania jak i wysyłania'
a to dlaczego? przeciez mozna uzyc gniazd nieblokujacych lub blokujacych na selektorze i wtedy tez smiga wszystko pieknie, do prostej gry 2d powinno wystarczyc, przykladowo endless-online byl w ten sposob robiony a serwer z latwoscia utrzymywal niegdys 2tys graczy online ;)

@up: gry czasu rzeczywistego nie uciągną Ci 2 tys graczy, więc jest to zły przykład. Gry turowe lub gry o małej bardzo precyzji czasowej można realizować w sposób który podałeś. Skoro powołujesz się na zasłyszane informacje, a nie na swoje doświadczenie to chociaż zaznacz, że to są Twoje przypuszczenia, bo kolega napisał właśnie, że gniazda nieblokujące i jeden wątek okazały się nieefektywne (co sam też mogę potwierdzić z własnych doświadczeń), pomimo iż aplikacja działa poprawnie. Poza tym szczerze wątpię w Twoją opowieść o aplikacji na socketach nieblokujących, obsługującej 2tys graczy online.

PS.

(...) lub blokujacych na selektorze i wtedy tez smiga wszystko pieknie, (...)

Jeżeli użyjesz gniazd blokujących na selektorze to i tak zablokujesz wątek, więc Twoja teoria realizowania wszystkiego na jednym wątku właśnie upadła :)