Jak poprawnie przewidzieć ruch, gdy gracz jest niewidzialny?

Mam grę wieloosobową i przewiduję po stronie klienta, ale niektórzy gracze mogą wypić miksturę i stać się niewidzialnym ...

Problem polega na tym, że gdy stają się niewidzialni, nie udostępniam niczego, co klient mógłby wykorzystać, aby wiedzieć, że tam jest, więc kiedy gracz próbuje wejść na płytkę zajmowaną przez niewidzialnego gracza, przewiduje, że mu się to uda, a następnie dostaje brzydka korekta pozycji wysłana przez serwer.

Jednym z rozwiązań byłoby udostępnienie czegoś, aby klient mógł to powiedzieć, ale hakerzy mogliby to wykorzystać, aby dowiedzieć się, gdzie są niewidzialni gracze, oszukiwający.

Przy okazji rozwiązałem już przewidywanie ruchu, działa idealnie.

Można to uznać za problem z animacją. Jeśli korekcja pozycji powraca z serwera z powodu próby przejścia do niewidocznego obiektu, odeślij nie tylko korektę, ale flagę wskazującą, dlaczego korekta była potrzebna. Zamiast rzucać gracza do tyłu, może wykonać „woah” animację cofania, dzięki czemu bardziej prawdopodobne jest, że po prostu wpadł na coś.

W grach korzystających z tego podejścia nierzadko zdarza się (przynajmniej chwilowo) niewidzialność wszystkiego, na co wpadł. Między innymi daje to zachętę niewidzialnym graczom do unikania tłumu lub zbliżania się do innych postaci, co zmniejsza częstotliwość zderzeń z niewidzialnym graczem. Zatem nawet jeśli twoja animacja dla tego rodzaju kolizji jest słaba (lub nie istnieje), jest ona nieco ukryta przez niewidzialną postać pojawiającą się w widoczności i wyraźnie telegrafującą do wszystkich, co się właśnie wydarzyło.

Potrzebę animacji można usunąć, nie pozwalając niewidzialności działać z bliskiej odległości. Daje to jeszcze większą motywację niewidzialnym graczom, aby uniknąć zbliżania się do innych postaci. Jest to powszechne podejście do gier opartych na ukryciu i sztucznej inteligencji (zamień „niewidoczny” na „niewidoczny dla celu”) i można je zobaczyć w grach PvP, takich jak World of Tanks. Nie musisz się martwić reakcją na kolizję z niewidzialnymi postaciami, jeśli nic niewidzialnego nigdy nie jest wystarczająco blisko, aby się zderzyć (w granicach opóźnień).

Dobrym rozwiązaniem jest również rozwiązanie Dracora polegające na ignorowaniu kolizji z niewidzialnymi obiektami. To znowu wymaga animacji (dla klienta niewidzialnego gracza), więc obiekty nie tylko przecinają awatar gracza na jego ekranie. Jeśli nic więcej nie możesz spowodować, że widoczne obiekty będą zawsze popychać niewidzialne, tak że niewidzialny gracz zostanie automatycznie odsunięty na serwer, jeśli ktoś z nim zderzy się.

Niewidzialne-niewidoczne kolizje są nieco trudniejsze. Korzystne może być wyłączenie na nich kolizji, ponieważ nikt nie może zobaczyć, czy dwa niewidzialne obiekty się ze sobą przycinają (zakładając, że „niewidoczny” oznacza, że ​​oba obiekty nie są widoczne dla tego samego klienta). Jeśli jeden z obiektów stanie się widoczny, automatycznie powraca do widocznej niewidzialnej reakcji na kolizję (odepchnij niewidzialny obiekt).

To wszystko staje się trudniejsze, jeśli niewidzialność ma skomplikowane zestawy osób, które mogą zobaczyć, kogo. Pierwsze lub drugie rozwiązanie powyżej jest prawdopodobnie najlepsze tutaj, jeśli jest potrzebne. Nie każdy taki problem wymaga rozwiązania technicznego; wiele tylko potrzebuje rozwiązań projektowych (np. nie zezwalaj na tę funkcję swoim projektantom).

Naprawdę widzę tutaj tylko dwie opcje, jeśli nie chcesz powiedzieć klientowi, gdzie jest niewidzialny gracz: 1) Ignorujesz kolizję jednostek dla niewidzialnych graczy - proste rozwiązanie, a gracze nie byliby w stanie znaleźć niewidzialnych graczy według testy zderzeniowe. 2) Po podjęciu decyzji o przewidywanej ścieżce, wyślesz serwerowi przewidywaną ścieżkę i poprawisz samą ścieżkę po stronie serwera, a następnie odeślesz nową ścieżkę z powrotem.

O ile czegoś nie rozumiem, rozwiązanie jest proste. Nie wysyłaj informacji o kliencie na temat wszystkich niewidzialnych graczy, tylko tych, którzy znajdują się w zasięgu, że mogą być narażeni na kolizję w granicach ruchu podczas przewidywanego interwału. Innymi słowy, jeśli klient musi przewidywać tylko 200 ms w przyszłości, wysyłaj informacje tylko o niewidzialnych graczach w max_player_velocity units/sec * 1/5 secoddalonych od siebie jednostkach.