Przesyłanie danych w grze multiplayer - Qt.

0

Witam.
Jestem w trakcie pisania dynamicznej gierki 2d multiplayer na 4 graczy. Serwer mam napisany w Qt przy użyciu QTcpServer. Mam dylemat co do przesyłania informacji pomiędzy klientami. W tym momencie działa to tak, że jeśli gracz się rusza to przesyła na serwer swoją pozycje x i y co 10ms i jest ona rozsyłana do wszystkich innych graczy. W tym momencie mam problem, bo jeśli odpalę gierkę dla 4 graczy i poruszają się oni w tym samym momencie to są straszne lagi. Myślałem nad zrobieniem tego tak, że jeśli jak zacznie się ruszać np. w lewo to na serwer wysyłana jest informacja, że zaczął się ruszać w lewo i jest rozsyłana do innych gracza, dopiero jak puści strzałkę w lewo to na serwer jest wysyłana informacja, że się zatrzymał, następnie otrzymują ją inni gracze i w swoich klientach go zatrzymują. Czy ta druga opcja będzie lepsza? A może coś jeszcze innego może wpływać na te lagi. Byłbym wdzięczny jakbyście się wypowiedzieli.
Z góry dzięki! :)

2

Jeśli to klient ma sobie odtwarzać ścieżkę innych klientów to szybko pojawią Ci się rozbieżności (np. u jednego informacja o zakończeniu ruchu dotrze 10ms później - 10ms dłużej będzie trwał ruch). Dlatego też będziesz musiał i tak co jakiś czas aktualizować bezwzględną lokację. Najlepiej, żeby trzymał ją serwer, inaczej klient może oszukiwać i się teleportować.

O ile dobrze pamiętam, w Quake'u 2 lub 3 jest to rozwiązane w ten sposób, że klient co jakiś czas wysyła swoją pozycję bezwzględną a potem kolejne delty od niej (aż do następnej bezwzględnej), dzięki czemu nawet przy utracie pakietów w przypadku transmisji UDP ruch zachowuje płynność i precyzję.

0

przysyłanie delty czy wartości bezwzględnej nie ma znaczenia, problem synchronizacji danych w czasie rzeczywistym pozostaje ten sam.

Problem jest jak rozstrzygać różnice czasowe by uzyskać dobre wrażenie z gry.
Pytanie jest kto ma rozstrzygać kolizje. Np dla FPS-a kolizje pocisk cel ma rozstrzygać maszyna: strzelającego, serwera, czy trafionego? Każdy z tych aktorów doznaje innego opóźnienia danych i rozstrzyganie na korzyść jednego daje artefakty u drugiego.
Jedną z technik rozwiązania tego problemu jest zapamiętywanie przez serwer historii aktorów i rozstrzygania jej w miarę jak przychodzą nowe dane historyczne.
Wysyłając informację o nowej pozycji użytkownika, nowych pocisków∑ itp, należy wysłać też oznaczanie czasowe danych, które w danej chwili posiada klient i oznaczanie obecnego czasu.
Problem jest skomplikowany i za mało tu jest miejsca by rozstrzygać wszelkie związane z tym problemy.

Jedną z metod poprawy jakości gry, bez rozwiązywania powyższego problemu, jest zrezygnowanie z połączania TCP na rzecz UPD, które jest szybsze, ale za to bardziej zawodne.

0

Mozna zobaczyc w zrodla Quake2 albo Quake3 jak zostalo to zrobione (oba sa dostepne)

roznica pomiedzy tymi dwoma jest znaczaca. Bo w Quake2 roznica 10 milisekund robila roznice podczas gdy w Quake3 mogles miec ping 100 i calkiem ok sie gralo

1 użytkowników online, w tym zalogowanych: 0, gości: 1