Come prevedere correttamente il movimento quando un giocatore è invisibile?

Ho una partita multiplayer e sto facendo una previsione sul lato client, ma alcuni giocatori possono bere una pozione e diventare invisibili ...

Il problema è che quando diventano invisibili non condivido nulla che il cliente possa usare per sapere che è lì, quindi quando un giocatore cerca di entrare in una tessera occupata da un giocatore invisibile, predice che ci riesce e poi ottiene un brutta correzione della posizione inviata dal server.

Una soluzione sarebbe quella di condividere qualcosa in modo che il cliente possa dirlo, ma poi gli hacker potrebbero usarlo per scoprire dove sono i giocatori invisibili, barare.

A proposito, ho già risolto la previsione del movimento regolare, funziona perfettamente.

Questo potrebbe essere considerato un problema di animazione. Se una correzione di posizione ritorna dal server a causa di un tentativo di spostarsi in un oggetto invisibile, rispedire non solo la correzione ma un flag che indica il motivo per cui la correzione era necessaria. Invece di un giocatore che salta all'indietro, può fare un tipo di "woah" di animazione all'indietro, facendolo sembrare più credibile come se avesse appena incontrato qualcosa.

Nei giochi che utilizzano questo approccio, non è insolito rimuovere l'invisibilità (almeno momentaneamente) da qualsiasi cosa si sia verificata. Tra l'altro, ciò incentiva i giocatori invisibili a evitare la folla o ad avvicinarsi troppo agli altri personaggi, riducendo in primo luogo la frequenza con cui un giocatore invisibile si scontra con un giocatore invisibile. Quindi, anche se la tua animazione per questo tipo di collisione è debole (o inesistente), è in qualche modo nascosta dall'invisibile personaggio che entra in visibilità e telegrafando chiaramente a tutti ciò che è appena accaduto.

Il bisogno di animazione potrebbe essere rimosso non lasciando che l'invisibilità funzionasse a distanza ravvicinata. Questo dà ancora più incentivo ai giocatori invisibili per evitare di avvicinarsi ad altri personaggi. Questo è un approccio comune per i giochi basati sull'intuizione e l'intelligenza artificiale (sostituisci "invisibile" con "non visibile al bersaglio") e può essere visto in giochi PvP come World of Tanks. Non è necessario preoccuparsi della risposta alle collisioni con personaggi invisibili se nulla di invisibile ti è mai abbastanza vicino da scontrarti (entro i limiti di latenza).

Anche la soluzione di Dracor per ignorare le collisioni con oggetti invisibili è buona. Ciò richiede di nuovo alcune animazioni (per il client dei giocatori invisibili), quindi gli oggetti non si limitano a tagliare l'avatar del giocatore sul suo schermo. Se non altro, puoi far sì che gli oggetti visibili spingano sempre quelli invisibili in modo tale che il giocatore invisibile si sposti automaticamente sul server se qualcuno si scontra con lui.

Le collisioni invisibili-invisibili sono un po 'più complicate. Può essere vantaggioso disabilitare solo le collisioni su di loro poiché nessuno può vedere se due oggetti invisibili si stanno unendo (supponendo che "invisibile" intendiamo che entrambi gli oggetti non sono visibili allo stesso client). Se uno degli oggetti diventa visibile, ritorna automaticamente alla risposta di collisione visibile-invisibile (allontanare l'oggetto invisibile).

Tutto ciò diventa più complicato se l'invisibilità ha insiemi complicati di chi può vedere chi. La prima o la seconda soluzione sopra è probabilmente la migliore qui se ne hai bisogno. Non tutti i problemi come questo richiedono una soluzione tecnica; molti hanno solo bisogno di soluzioni di design (ad esempio, non consentire questa funzionalità ai vostri progettisti).

Vedo davvero solo due opzioni qui se non vuoi dire al cliente dove si trova il giocatore invisibile: 1) Ignori la collisione dell'unità per i giocatori invisibili: una soluzione semplice e i giocatori non sarebbero in grado di trovare i giocatori invisibili test di collisione neanche. 2) Dopo aver deciso il percorso previsto, si invia al server il percorso previsto e si corregge il percorso stesso sul lato server, quindi si rinvia il nuovo percorso.

A meno che non fraintenda qualcosa, la soluzione è semplice. Non inviare al cliente le informazioni su tutti i giocatori invisibili, solo quelli che si trovano nel raggio d'azione potrebbero essere soggetti a collisioni entro i limiti di movimento durante l'intervallo previsto. In altre parole, se il cliente deve solo prevedere 200 ms in futuro, invia solo informazioni su giocatori invisibili a max_player_velocity units/sec * 1/5 secdistanza di unità.