2012-06-17 3 views
5

Attualmente sto sviluppando un gioco per Android, e mi piacerebbe la tua esperienza su un problema che ho avuto.Sviluppo giochi Android: rilevamento collisione non riuscito

Priorità:

  1. mio gioco incorpora cornice tasso di movimento indipendente, che tiene conto del valore tempo delta prima di eseguire necessaria Velocity calcoli.

  2. Il gioco è un tradizionale platform 2D.

il problema:

Ecco il mio problema (semplificato). Facciamo finta che il mio personaggio sia un quadrato in piedi su una piattaforma (con "gravità" che è una velocità costante verso il basso di carattereVelocityDown).

Ho definito il rilevamento collisione come segue (supponendo punti dell'asse Y verso il basso):

Dato characterFootY è la coordinata y della base del mio carattere quadrato, platformSurfaceY è y superiore -coordinate di mia piattaforma, e platformBaseY è inferiore coordinata y della mia piattaforma:

if (characterFootY + characterVelocityDown > platformSurfaceY && characterFootY + characterDy < platformBaseY) { 

        //Collision Is True 
        characterFootY = platformSurfaceY; 
        characterVelocityDown = 0; 

       } else{ 
        characterVelocityDown = deltaTime * 6; 

Questo approccio funziona p perfettamente corretto quando il gioco funziona a velocità regolare; tuttavia, se il gioco rallenta, il tempo delta (che è il tempo trascorso tra il fotogramma precedente e il frame corrente) diventa grande, e characterFootY + characterVelocityDown superano i confini che definiscono il rilevamento delle collisioni e il personaggio cade proprio dritto attraverso (come se teletrasportarsi).

Come dovrei affrontare questo problema per impedirlo?

Grazie in anticipo per il vostro aiuto e non vedo l'ora di imparare da voi!

+0

Se qualcun altro sta avendo questo problema, una possibile soluzione a questo è di limitare il valore deltaTime in modo che quando si trova su un certo valore, basta impostarlo uguale al cap. Ciò renderebbe la velocità di gioco incoerente, ma dovrebbe essere ok nella maggior parte dei casi. – SeveN

+0

Hai entrambi i valori delta prima e dopo, dato che il confronto potrebbe essere fatto lì? – cjk

risposta

1

Quello che devi fare è eseguire il tuo ciclo fisico con costante delta time e iterarlo per il tempo necessario con il tick corrente.

const float PHYSICS_TICK = 1/60.f; // 60 FPS 
void Update(float dt) 
{ 
    m_dt += dt; 
    while(m_dt > PHYSICS_TICK) 
    { 
     UpdatePhysics(PHYSICS_TICK); 
     m_dt -= PHYSICS_TICK; 
    } 
} 

ci sono varie tecniche utilizzate per gestire il segno di spunta a sinistra (m_dt)
Tappi per tick miniumum e il massimo segno di spunta sono anche un must.

+0

E per la maggior parte dei giochi è meglio/più semplice fissare il passo temporale per l'intera logica di gioco (non solo fisica). –

1

Immagino che il problema qui sia che i rallentamenti sono inevitabili. Puoi provare e ottimizzare il codice ma avrai sempre utenti con dispositivi lenti o sezioni occupate del tuo gioco, dove ci vuole un po 'più del solito per elaborare tutto. Invece di assumere un delta coerente, assumere il contrario. Codice in base al fatto che qualcuno potrebbe provare a installarlo su un abaco.

Quindi, in pratica, come dice SeveN, il tuo ciclo di gioco gestisce i rallentamenti. L'unico vero modo per farlo (nella mia esperienza dichiaratamente limitata) sarebbe di mettere un berretto su quanto può essere grande delta. Ciò farà sì che l'orologio non funzioni esattamente nel tempo, ma quando ci pensi, è così che la maggior parte dei giochi gestisce il rallentamento. Non accendi StarCraft sul tuo pentium 66 e fallo girare a 5 FPS ma a piena velocità, rallenta e lo elabora normalmente, anche se in una presentazione.

Se hai fatto una cosa del genere, durante i periodi di rallentamento nel tuo gioco, sarebbe visibilmente rallentato ... ma i calcoli dovrebbero essere tutti ancora azzeccati.

modifica: mi sono appena reso conto che sei SEMPRE. Molto bene.

+0

[Profanity is not welcome here] (http://meta.stackexchange.com/a/22233/142838). – meagar