Gry Android UDP/TCP?

Question

Widzę, że to pytanie zostało zadane wcześniej, ale kontekst wokół pytań jest zwykle niejasny. Chciałbym stworzyć grę w trybie dla wielu graczy na Androida w czasie rzeczywistym, w której istnieje globalny stan, który musi być udostępniany wszystkim klientom. W związku z tym mam skłonność do przypuszczeń, że UDP może nie wystarczyć. TCP zapewnia niezawodność, ale z nieodłącznym obciążeniem. Ponieważ jednak po raz pierwszy poradziłem sobie z takim problemem, szukam informacji zwrotnych od doświadczeń innych ludzi.

Z tego względu (ogólnie) w kontekście gry wieloosobowej w czasie rzeczywistym na smartfonie z Androidem, obciążenie związane z protokołem TCP jest na tyle akceptowalne, że użytkownik nie odczuwa tak niekorzystnego wpływu na użytkownika? Warto również wspomnieć, że połączenie TCP musi być stałym połączeniem. Ponadto, czy UDP w połączeniu z pewnymi niezawodnymi mechanizmami opracowanymi przez klienta byłoby lepszym rozwiązaniem? Wszelkie dane wejściowe naprawdę mi pomogą & będą bardzo mile widziane.

bardzo dziękuję

Answer 1

Najlepsza odpowiedź to prawdopodobnie "spróbuj i zobacz".

jestem zdania, że ​​narzut TCP nie jest aż tak wielkiego dla większości zastosowań. Rozmiar nagłówka jest rzędu 10 bajtów większy, a komunikaty ack muszą być wysyłane tam iz powrotem dla każdej wiadomości.

Prawdziwy zabójca do gry w czasie rzeczywistym będzie opóźnienie. UDP to fire-and-forget. Oznacza to, że każda wiadomość jest opóźniona o czas tranzytu między dwoma węzłami. Ponieważ protokół TCP wymaga potwierdzenia, wiadomość nie jest tak naprawdę uważana za "wysłaną", dopóki druga strona nie zostanie ponownie odebrana.

Generalnie problem między nimi sprowadza się do wykrycia błędów. Jeśli jakaś wiadomość zostanie zagubiona w interwebs, w jaki sposób chcesz ją obsłużyć? Jeśli każda wiadomość jest dość istotna, to jeśli użyjesz UDP, będziesz musiał zaimplementować swój własny protokół podobny do protokołu TCP. Równie dobrze możesz użyć protokołu TCP i pozwolić, aby sprzęt sieciowy Ci pomógł. Jeśli jednak stare wiadomości po pewnym czasie będą wymagały kilku prób (każdy z opóźnieniem sieci) i tak będą śmieci, a pojawią się nowe aktualizacje, to TCP jest dla ciebie marnowaniem pasma.

Answer 2

To naprawdę nie jest pytanie na Androida, chociaż protokół i inne wybrane mechanizmy będą miały wpływ na urządzenie (np. Żywotność baterii).

Jaki protokół wybrać zależy głównie od Twoich wymagań (średni rozmiar pakietu, średnio pakiety na sekundę, czy zgubione pakiety są problemem, ile danych wysyłasz na raz, to jitter, problem itp.). Mogę jednak podać kilka wskazówek.

Oto bardzo dobry artykuł na temat wdrażania sieci Quake3:

http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking

Prosty, ale skuteczny, bardzo podoba mi się to i mogę tylko polecić ten jeden.

Tutaj także dobry wątek na ten temat:

http://www.gamedev.net/topic/319003-mmorpg-and-the-ol-udp-vs-tcp/

niektórych grach używa UDP (zwłaszcza FPS i RTS typy), niektóre TCP, a niektóre z nich pewnej kombinacji z nich (np UDP wyślij dane gry, TCP na czat i inne rzeczy). Każdy może pracować. Należy również pamiętać, że użytkownicy mogą chcieć pracować w sieciach 2G, 3G lub WiFi, a nawet sieci Wi-Fi mogą być opóźnione i przekraczać pojemność. Proponuję wdrożyć szybki prototyp i przetestować go w różnych środowiskach sieciowych.

Answer 3

Mam do czynienia z tym samym problemem. Z przeglądu literatury robiłem Proponuję przeczytać ten artykuł:

„Doświadczenia z Wdrożenie Komórka multiplayer w czasie rzeczywistym gra dla sieci bezprzewodowych z wysokim latency” - http://www.hindawi.com/journals/ijcgt/2009/530367/

Answer 4

Możesz zobaczyć moją grę (wciąż rozwijaną) - https://market.android.com/details?id=com.reality.weapons.ak47

Używa ona TCP/IP. Możesz odczuwać opóźnienia, strzelając i obserwując powiadomienia w postaci wiadomości "Battle log".

Do tej pory byłem dość zadowolony. Na obszarach miejskich o dobrym zasięgu GSM, obie

„ogniowej> podróż do server-> obliczenia WYNIKI> Wyniki podróży Back> Pokaż notfication”

trwa zwykle mniej niż 200 ms.

Czasami może to być 2 sec. Ale w 99% jest to mniej niż 500 ms.