[jacku]

Chciałbym wprowadzić multiplayer do gry ale nie wiem na ten temat nic.
Pomysł mam taki aby przenosić tylko 2 zmienne: gaz i skręt i resztę komputer sobie wyliczy lokalnie. Czy takie podejście jest ok czy tak się nie robi?

Czyli player 1 widziałby swojego przeciwnika w płynnym ruchu, ew. co sekundę byłby skok na wyrównanie transforma przeciwnika gdyby dane za bardzo się rozjechały.

Z drugiej strony Unity MLAPI i Photon oferują ciekawe rzeczy typu synchronizacja rigid body z predykcją ruchu ale ten mój pomysł z wysyłaniem tylko 2 zmiennych byłby na logike kilkukrotnie szybszy.
#gamedev #unity3d #csharp

[p.....k]

@jacku: tak się nie robi. Tzn nikt ci nie zabroni tak zrobić ale parę zgubionych pakietów albo opóźnienie na sieci całkowicie rozjedzie twój algorytm. Prawdopodobnie nawet w normalnej sytuacji się rozjedzie bo akcje graczy na urządzeniu przeciwnika będą niezsynchronizowane z faktycznym "lokalnym" stanem (np auto przeciwnika skręci o 100ms później)

Na początek poczytaj o

https://en.m.wikipedia.org/wiki/Dead_reckoning

I potraktuj to jako punkt wyjścia. Ogólnie przesyłanie pozycji i interpolowanie ich brzmi znacznie stabilniej ale

[MichalPypek]

@jacku:
Mam małe doświadczenie w multi, szczególnie przy takim, gdzie liczy się dynamika, ale ( ͡° ͜ʖ ͡°):

Photon: próbowałem kiedyś zrobić top-down multiplayerową ścigałkę używając photona (PUN, nie bolty i cała reszta)- i grając na tym samym komputerze wszystko się rozjeżdżało o 1-2 długości samochodu. To akurat pewnie wynikało z tego, że pun nie ma do końca legitnego serwera, tylko robi za dziwny przekaźnik między urządzeniami,

[zibizz1]

@jacku: użyj gotowego rozwiązania.
Photon używa shared simulation więc każdy gracz wysyła do wszystkich innych pozycję i prędkość.
Użyj Fusion jeśli chcesz mieć architekturę host +clients
Synchronizacja inputu ma tylko sens w deterministycznej symulacji Quantum, ale musisz też wtedy używać deterministycznej implementacji fizyki (Unity takiej nie ma w standardzie)
Synchronizacja symulacji to moja specjalność

[jacku]

@powaznyczlowiek: przeczytam ale jeszcze co do tego opóźnienia to nie miałoby ono aż takiego znaczenia bo przeciwnik nie reagowałby w ogóle z autem gracza, byłby to tzw. ghost. A jako że jadą po tej samej planszy to skręt o 100 ms później nic nie zmienia, po prostu ghost jest przesunięty o 100 ms. później ale skręca w to samo miejsce, tylko później. Dopiero na koniec wyścigu możnaby puścić więcej danych jak

[zibizz1]

@MichalPypek: jak chce się mieć na wszystkich ekranach dokładnie to samo to tylko z resymulacja. Czyli jak dostajesz stan z serwera, cofasz symulacje do tego momentu i przeliczasz na nowo swój input z bufora od tego momentu i tak za każdym razem. Jak masz duży lag do serwera to robi się to kosztowne obliczeniowo, ale masz płynny ruch i wszystko wygląda super

[jacku]

@MichalPypek: @zibizz1: poczytam trochę najpierw. Pełnej fizyki na pewno nie chcę bo to będą miesiące walki z niepewnym wynikiem, na razie spróbuję zrobić czerwony punkt który będzie pokazywał pozycję przeciwnika i na to właściwie szukam rozwiązania (chyba w MLAPI). Jak pójdzie to w miarę bez opóźnień to będę to rozwijał

[zibizz1]

@jacku: najszybciej pójdzie Ci z PUN Real-Time, do 20CCU za darmo

[NevilX]

@jacku: Wysyłasz aktualną pozycję/orientację, kierunek ruchu, prędkość, opcjonalnie aktualne pozycje sterowania. Aktualizacja pozycji ma pierwszeństwo. Jak przez dłuższy czas nie masz nowych informacji, przewidujesz ruch na podstawie tego co dostałeś ostatnim razem.

Ścigałki tak właśnie się synchronizują, w przypadku problemów z łączem pojazd często "odlatuje".
https://youtu.be/A1s5pD5ilGw?t=274
ACC przez jakiś czas miało problem taki, że niektórzy specjalnie gubili pakiety chwilę przed dohamowaniem jadąc za kimś. Klient tego kogoś estymował pozycję jako ciągły

[NevilX]

@jacku: W sumie Battlefieldy mają podobny system. W którymś dało się wyłączyć estymację w konsoli. Wtedy wszyscy na mapie przestawali się płynnie poruszać, "skakali" za każdym razem jak klient dostawał info o nowej pozycji.

[jacku]

@zibizz1: Photon PUN i Photon Realtime to dwa osobne rozwiązania z tego co piszą, chodzi Ci o to żeby użyć Realtime zamiast PUNa do przesyłu minimalnej ilości danych?

[zibizz1]

@jacku: Nie, ogólnie wszystkie rozwiązania od exit games działają prawie na tym samym backendzie. Czyli infrastruktura serwerowa jest identyczna. Produkty typu Fusion czy Quantum wymagały pewnej modyfikacji ale nie wielkiej.
PUN po stronie klienta zawiera lepszą integracje z Unity, masz np od razu komponent do synchronizacji animacji. Można powiedzieć że PUN to taka nakładka, ale jak zajrzysz jeden level niżej to masz cały Photon realtime.

Cała architektura składa się z
-

[jacku]

@zibizz1: dzięki za wyjaśnienie, to w takim razie startuje na PUNie. Trochę mnie zniechęcają takie pakiety gdzie wszystko jest w postaci gotowców bo kojarzą mi się z bloatwarem i niepotrzebnym mieleniem danych, np. mając animację zapisaną na dwóch kompach potrzebowałbym wysłać tylko bool który ją odpali bez żadnych skomplikowanych narzędzi. Ale zobaczymy bo jeszcze nawet nie zacząłem

[zibizz1]

@jacku: no tak to działa, wysyłasz minimalne ilości danych, jak np masz bardziej skomplikowany typ danych to implementujesz jego własna serializacje na streamów (kiedyś było do tablicy bajtów ale było mało optymalne).
To jest sprzedawane od CCU więc troszczą się żeby przesyłać malo.