Koncepcja Serwera Gier Strategicznych
Im planuje stworzyć opartą na WebGL, strategiczną grę czasu rzeczywistego, w której gracze będą mogli grać razem. Używam węzła.js do tworzenia serwera gry i websockets dla połączeń w czasie rzeczywistym.
Ive broken my mind about what would be the best concept to synchronization the clients.
Jedną z możliwości byłoby wysyłanie tylko zamówień użytkowników (przenoszenie jednostek, budowanie budynków itp.) na serwer, który wysyła je do wszystkich innych klientów. Ale tutaj mam problem z opóźnienie. Myślę, że gry będą asynchroniczne w ten sposób.
Inną możliwością byłoby kalulowanie gry na serwerze. Klienci nadal wysyłają instrukcje do serwera, ale serwer wysyła teraz wszystkie zmienione stany wszystkich jednostek i budynków do klientów w wysokim przedziale. Problemem jest tutaj duża ilość danych i jak szybko może to być...
Masz jakieś inne pomysły lub propozycje ulepszeń?
Dzięki!
6 answers
W zasadzie musisz zdecydować między prędkością A bezpieczeństwem .
Pozwala klientowi wykonać zadanie i obliczenia jest szybsze, ale dane są zagrożone, ponieważ klient może manipulować danymi.
Z drugiej strony, wykonywanie wszystkich zadań przez serwer jest wolniejsze, ale dane są bezpieczniejsze.
Możesz zdecydować się na podwójne podejście, zdecydować, aby Klient obliczył tylko niektóre dane, zsynchronizował, a następnie sprawdzał ich ważność, a reszta została wykonana na serwerze.
Zależy również od szybkości działania gry, ilości danych do obliczenia, szybkości serwera i pasma / połączeń itp...
Powinieneś prototypować obie metody i wypróbować kilka testów, aby emulować obciążenie klienta i serwerów.
Jeśli gra jest mała, zdecydowałbym się na bardziej serwerową pracę. Z drugiej strony, dla znacznie skomplikowanej gry prawdopodobnie dzielenie więcej pracy do klienta jest najlepsze. W każdym razie uważam, że zawsze potrzebna jest wymiana.
Oto kilka linki, które możesz znaleźć przydatne
Wprowadzenie Do Programowania Gier Multiplayer
Wątek programowania Multiplayer (stary, ale wciąż z wieloma przydatnymi linkami)
Zapobieganie Oszustwom W Trybie Wieloosobowym
Pierwszy link Bardzo mi pomógł w dawnych czasach i imho nadal jest jednym z najlepszych zasobów dostępnych na temat.
Książki
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 12:23:56
Sugerowałbym obejrzenie tych zasobów dotyczących koncepcji tworzenia gier opartych na przeglądarce:
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-08-24 09:24:28
Niestety nie mam doświadczenia w grach online opartych na WebGL, ale zazwyczaj jest to dobre podejście, aby pozwolić logiki gry być wykonywane po stronie klienta, i zsynchronizować wyniki.
W tym podejściu ważne jest, aby śledzić, jaki obiekt gry jest "własnością" jakiego klienta. Klienci wysyłają aktualizacje (tworzenie, aktualizowanie, usuwanie) tylko z własnych obiektów i otrzymują aktualizacje innych obiektów gry od innych klientów.
DODATKOWO możesz skonfigurować wiadomość framework do dostarczania dodatkowych wiadomości typu "Player has entered/left" lub coś w tym stylu.
Ta koncepcja okazała się przydatna w grze, którą stworzyłem i mam nadzieję, że będzie równie przydatna dla Ciebie.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-08-24 08:54:03
Powinieneś mieć stan gry i logikę na serwerze, w przeciwnym razie twoja gra jest szeroko otwarta na oszustwa. Serwer jest ostatecznym autorytetem stanu gry.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-08-24 09:50:27
Nie jestem pewien co do WebGL, ale według mojego zrozumienia następujące podejście będzie dobre.
- Zainicjalizuj wszystkie obiekty (które są wspólne dla graczy) na serwerze i uruchom je
- przy uruchomieniu klienta zażąda wszystkich rendererów (związanych z konkretnym klientem) dla obiektów uruchomionych na serwerze.
- klient wyrenderuje obiekty w interfejsie użytkownika dla wszystkich otrzymywanych rendererów.
- Gdy klient dokona jakiejkolwiek aktualizacji UI, zmiany zostaną zgłoszone do serwera, a serwer zaktualizuje obiekt odpowiednio
- gdy obiekty wspólne między graczami są modyfikowane przez jednego gracza, każdy gracz (Klient) zostanie powiadomiony o wprowadzeniu zmian w interfejsie.
To podejście będzie specyficzne dla zwykłych obiektów, a nie dla UI / obiektów specyficznych dla klienta.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-08-24 09:06:07
Ze względów bezpieczeństwa Cała logika powinna być po stronie serwerów, a cała aktualizacja danych jest na serwerze.
Ale klient jest w stanie przewidzieć pewną logikę i odtworzyć animację najpierw, co nazywa się prognozowaniem klienta.
Strona serwera jest odpowiedzialna za weryfikację logiki klienta, jeśli nie ma oszustwa, wszystko zrobione. Jeśli ktoś oszukuje, serwer może powiedzieć klientowi, aby wrócił do właściwego stanu.
Jeśli używasz node.js dla serwera, istnieje framework open source , pomelo . Istnieje również pełne demo kodu źródłowego i demo online dla niego: lordofpomelo
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-12-12 07:00:48