Ingresso di un gioco ritmico

Question

Quindi, Unity non fa molti giochi ritmici su Android. Ho deciso di scoprirne il motivo e programmarne uno come compito (comunque i principi fondamentali). Il mio ostacolo più importante è l'input dell'utente. Poiché sappiamo che l'input è basato sul frame rate in unità, e un gioco musicale (presumo) preferirebbe il più piccolo ritardo possibile tra la pressione del pulsante e l'azione.

Se guardiamo alla musica, a circa 15-20 ms di ritardo, l'orecchio umano sente qualcosa "fuori ritmo".

Ho sentito i giochi Android Unity eseguiti a 30 FPS (poiché 60FPS fa schifo la batteria), matematica semplice indica: 1000/30 = 33ms per frame. Calcolando nei 15ms che probabilmente non possiamo notare, siamo a 18ms di possibile disastro. supponendo che raggiungiamo sempre questo 30FPS in qualsiasi momento.

Quando ottengo l'input da un utente, posso riprodurre un suono su quell'ingresso sullo stesso fotogramma. Tuttavia, potremmo essere 18ms fuori.

Ora c'è un modo per ottenere controlli DIRETTI da mouse e tastiera, che utilizza OnGui() invece di Update(), per ottenere gli eventi della tastiera o dei clic del mouse sul posto. Il problema è che Android probabilmente non funziona con questo, (questo non funziona neanche per i gamepad) ei metodi sembrano decisamente strani, specialmente quando proviamo a riprodurre suoni dal metodo OnGui().

La mia domanda: Cosa vorresti fare, e perché? Dovremmo semplicemente accettare i 18ms possibili, e supponiamo di raggiungere il 30FPS, o dovremmo cercare un modo affidabile per ottenere input direttamente, invece di aspettare che arrivi un aggiornamento?

Grazie per qualsiasi intuizione puoi darmi, non ho trovato nessun articolo su questo che sia ancora utile. -Smiley

EDIT ho solo fatto dei test di base con un metronomo, in esecuzione a 100FPS nell'editor (che dovrebbe essere di 10 ms per frame) toccando la mia barra spaziatrice su un metronomo all'interno dell'unità. I risultati che ho ottenuto sono stati semplicemente orribili. Toccando rapidamente: mi avvicino di 20 ms al mio tick metronomico, ma niente di più vicino. Toccando sul ritmo: ho ottenuto almeno 200ms dal mio bersaglio. A meno che non sia confuso con questo ritmo, questo è semplicemente sbagliato.

Attualmente utilizzo Debug.Log per ottenere i dati di test nel registro. Qualcuno può confermare per me se questa potrebbe essere la causa (causa qualche ritardo lungo? So che il debug non è ottimizzato), o il tempo è effettivamente così brutto?

Grazie in anticipo, -Smiley

Answer 1

In primo luogo, vorrei aggiungere un paio di cose ai vostri commenti e le analisi:

c'è un inferno di molto di più per misurare la latenza tra l'input tattile e ciò che i tuoi occhi percepiscono.

Probabilmente il più grande che mi manca nei test è la latenza tra la scheda grafica e il monitor del PC su cui si sta eseguendo il test. Many common LCD monitors these days have a latency of between 15-30ms in processing lag. Non so quanto questo si riferisca a schermi mobili e hardware, ma ti suggerisco di prendere il tempo per eseguire test aggiuntivi sull'hardware di destinazione prima di trarre ulteriori conclusioni.

Per rispondere più direttamente alla tua domanda:

avrei continuato a utilizzare l'unità tuttavia vorrei continuare a ricercare i migliori metodi di prendere l'input e l'alimentazione di nuovo al giocatore il più velocemente possibile. Nei commenti sopra @rutter ti ha indicato quello che sembra essere un buon thread on the issue.

Di una nota specifica, guarderei usando FixedUpdate() per disaccoppiare il framerate del gioco dalla velocità di elaborazione dell'input.

Penso valga anche la pena dedicare tempo alla ricerca della psicologia della percezione della latenza. Ad esempio, se il tuo gioco è una sorta di gioco Guitar Hero per abbinare la canzone, puoi semplicemente prendere in considerazione il ritardo che conosci e nella tua logica di gioco tenerne conto al momento del controllo dell'input.

Answer 2

Penso che tu ti stia complicando troppo, e che il problema di accuratezza non è affatto male come pensi.

Le persone di solito toccano i pulsanti un po 'prima per sincronizzare ciò che vedono e ascoltano.

Dipende anche un sacco se si dispone di un qualche tipo di scorrimento del display che stanno cercando di abbinare a ... se il display scorre senza intoppi a 30 fps (senza grandi salti) che sono ancora in grado di fare la loro tempistica pressa abbastanza preciso.

Immagino che sebbene le persone possano sentire quando il loro tempo è disattivato, il loro effettivo tempo di colpire i pulsanti esattamente nel momento giusto non è comunque accurato.

Ecco un'altra soluzione semplice ... che credo sia quello rock band e guitar hero spesso fare ... Si inizia a suonare la nota/suono al momento giusto in ogni caso .... poi si cambia in una suono rotto se si scopre di averlo perso o di aver perso tempo.