Devo muovere il mondo o muovere il giocatore?


11

Sto per iniziare a sviluppare un gioco a scorrimento laterale in cui l'obiettivo del giocatore è viaggiare il più lontano possibile sull'asse orizzontale prima di toccare. Nota che non ho mai bisogno di viaggiare indietro sull'asse orizzontale.

Lo sto sviluppando con AndEngine per Android che utilizza OpenGL e Box2d.

Prima di iniziare, devo decidere qualcosa di importante: dovrei usare il mondo intorno al giocatore per simulare il movimento o effettivamente muovere il giocatore e seguirlo con le caratteristiche della fotocamera del motore di gioco?

Entrambi gli approcci sembrano avere diversi punti di forza e fallback, quindi non so quale sia considerato il migliore. Ad esempio, cosa semplificherebbe l'aggiunta di power-up lungo la strada e un piacevole sfondo animato?

Grazie!


2
Sposta la fotocamera.
Jonathan Dickinson,

1
A meno che tu non abbia un motivo specifico per non voler usare la fotocamera (che è già stata scritta per te), dovresti spostare il lettore e la fotocamera. L'aggiunta di "power-up" non dovrebbe essere influenzata in alcun modo.
Christopher Horenstein,

Risposte:


9

Sposta la videocamera (collegata al tuo lettore). Immagino che il tuo mondo abbia più oggetti come i nemici. Se sei andato con lo spostamento del mondo, dovresti scorrere tutti questi oggetti per aggiornare le loro posizioni ogni volta che il mondo si muoveva.

Se si sposta il lettore e si collega la videocamera al lettore, l'utilizzo delle risorse è minimo. Il gioco arriverà alla sua fase di rendering, passerà in rassegna tutto una volta come fa ogni fotogramma e li disegnerà in posizione - camera.position. In questo caso, la posizione della telecamera equivarrebbe sempre alla posizione dei tuoi giocatori.


Naturalmente se gli oggetti sono nemici, non dovresti attraversarli, aggiungi semplicemente il movimento dei mondi ai loro nel loro metodo di aggiornamento.
SirYakalot,

1
+1. Utilizzare camera.setChaseEntity(player);per raggiungere questo obiettivo.
MartinTeeVarga,

6

Sposto sempre la fotocamera e la consiglio - ci sono molti motivi per cui preferisco questo, ma probabilmente il più significativo si riduce a questo:

  1. Se sposti la fotocamera e il lettore, sono solo due le entità che devono essere aggiornate per scorrere lo schermo.

  2. Se sposti il ​​mondo intero ogni volta che lo schermo deve scorrere, questo comprende un numero sconosciuto e possibilmente elevato di entità che dovranno essere aggiornate.


Sono d'accordo, ma aggiungerei che aggiungere semplicemente una linea + = 'ing il movimento dei mondi alla classe nemica sarebbe abbastanza banale.
SirYakalot,

@AsherEinhorn Suppongo che tu stia parlando di uno scenario come un grafico di scena in cui ogni nodo condivide le trasformazioni del genitore e semplicemente spostando il nodo radice (cioè il "mondo") tradurrebbe automaticamente tutto il resto? Perché in ogni altro caso, spostare il mondo implica spostare tutto nel mondo - che era il punto del mio post.
David Gouveia,

bene se il movimento del mondo è inversamente proporzionale al giocatore. cioè - vai avanti, il mondo torna indietro, quindi potresti - = il movimento dei giocatori verso tutti gli oggetti di gioco. Sono d'accordo con te, sto solo dicendo che ci sono modi banali per far funzionare entrambi.
SirYakalot,

4

È davvero banale, in realtà non fa differenza dalle cose che hai descritto.

O sposti lo sfondo oltre la videocamera e il giocatore, oppure sposti il ​​giocatore e la videocamera con lui. Suppongo che ci sia un'altra cosa da fare se si sposta semplicemente lo sfondo.

Anche se suppongo che se sposti lo sfondo, dovrai fare da genitore a qualsiasi pickup e nemico, il che è di nuovo banale ma è qualcosa a cui pensare.

Personalmente sposterei il giocatore perché mi piace che le cose vengano fatte in modo più realistico.


0

Altre risposte sono buone, ma vorrei aggiungere alcuni punti di ciò che è meglio, sperando di aiutare qualcuno che cerca di prendere la stessa decisione per un progetto diverso.

Spostare il giocatore:

  • È semplice, tutto il resto è statico (ish), quindi in termini semplicistici, l'unica cosa che devi fare per spostare il giocatore è player.x += 5;(pseudocodice).
  • "Clic meglio" per la maggior parte delle persone. Quando giochi, pensi sempre che il giocatore si muova, non viceversa. Quindi è più facile pensarlo come "Il giocatore dovrebbe muoversi, non il mondo", che a sua volta può rendere più facile per qualcuno organizzarlo nella propria testa.
  • Facile da tracciare dove si trova il giocatore (la sua posizione è anche le sue coordinate sulla mappa)

Muovendo il mondo:

  • Se il tuo gioco è abbastanza grande, non devi preoccuparti di overflow / underflow, spostandoti troppo lontano dal centro del mondo, poiché la posizione del giocatore è sempre molto vicina 0.
  • Come sopra, se si scherza con i calcoli 3D, non è necessario preoccuparsi di risultati imprecisi con punti mobili, perché tutto ciò che si vede sullo schermo dovrebbe essere abbastanza vicino 0.
  • Se fatto correttamente, puoi creare un mondo "infinito".
  • Devi tracciare il giocatore manualmente, la posizione del giocatore avrà sempre un piccolo valore, il che significa dove si trova il giocatore sullo schermo (kinda), per sapere se il giocatore si trova in alto a sinistra sulla mappa o in basso a destra, dovresti tenerne traccia in qualche modo.

Alla fine, dipende dal progetto. Se qualcuno sta realizzando un clone di Mario originale, spostare il mondo potrebbe essere complicato, mentre spostare il giocatore non crea davvero molti problemi. Volendo creare un enorme gioco open world, potrebbe essere meglio invece spostare il mondo.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.