¿Debo mover el mundo o mover al jugador?

11

Estoy a punto de comenzar a desarrollar un juego de desplazamiento lateral donde el objetivo del jugador es viajar lo más lejos que pueda en el eje horizontal antes de tocar tierra. Tenga en cuenta que no necesito volver a viajar en el eje horizontal.

Estoy desarrollando esto con AndEngine para Android que usa OpenGL y Box2d.

Antes de comenzar, necesito decidir algo importante: ¿debo usar el mundo que rodea al jugador para simular el movimiento o realmente mover al jugador y seguirlo con las características de la cámara del motor del juego?

Ambos enfoques parecen tener diferentes puntos fuertes y retrocesos, por lo que no sé cuál se considera mejor. Por ejemplo, ¿qué haría más fácil agregar potenciadores en el camino y tener un lindo fondo animado?

¡Gracias!

2d android java side-scroller andengine monoceres
fuente
2
Mueve la cámara.
Jonathan Dickinson
1
A menos que tenga una razón específica para no querer usar la cámara (que ya ha sido escrita para usted), debe mover el reproductor y la cámara. Agregar "potenciadores" no debería verse afectado de ninguna manera.
Christopher Horenstein

Respuestas:

9

Mueva la cámara (conectada a su reproductor). Me imagino que tu mundo tiene múltiples objetos como enemigos. Si seguía moviendo el mundo, tendría que recorrer todos estos objetos para actualizar sus posiciones cada vez que el mundo se moviera.

Si mueve el reproductor y conecta la cámara al reproductor, el uso de recursos es mínimo. El juego llegará a su fase de renderizado, recorrerá todo una vez como lo hace en cada cuadro y los dibujará en la posición: cámara.posición. La posición de la cámara siempre sería igual a la posición de tus jugadores en este caso.

Jabonaduras
fuente
Por supuesto, si los objetos son enemigos, no tendrás que recorrerlos, solo agrega el movimiento del mundo al de ellos en su método de actualización.
SirYakalot
1
+1. Use camera.setChaseEntity(player);para lograr esto.
MartinTeeVarga
6

Siempre muevo la cámara y la recomendaría; hay muchas razones por las que prefiero esto, pero la más importante probablemente se reduce a esto:

  1. Si mueve la cámara y el reproductor, solo hay dos entidades que deben actualizarse para desplazarse por la pantalla.

  2. Si mueve el mundo entero cada vez que la pantalla necesita desplazarse, eso abarca un número desconocido y posiblemente un gran número de entidades que deberán actualizarse.

David Gouveia
fuente
Estoy de acuerdo, pero agregaría que simplemente agregar una línea + = 'que mueve el movimiento del mundo a la clase enemiga sería bastante trivial.
SirYakalot
@AsherEinhorn ¿Supongo que estás hablando de un escenario como un gráfico de escena donde cada nodo comparte las transformaciones del padre y simplemente moviendo el nodo raíz (es decir, el "mundo") traduciría todo lo demás automáticamente? Porque en todos los demás casos, mover el mundo implica mover todo en el mundo, que era el punto de mi publicación.
David Gouveia
bien si el movimiento del mundo es inversamente proporcional al jugador. es decir, avanzas, el mundo retrocede, entonces podrías simplemente - = el movimiento de los jugadores a todos los objetos del juego. Estoy de acuerdo con usted. Solo digo que hay formas triviales de hacer que ambos trabajen.
SirYakalot
4

Realmente es bastante trivial, realmente no hace una diferencia de las cosas que has descrito.

O mueves el fondo más allá de la cámara y el jugador, o mueves el jugador y la cámara con él. Supongo que hay una cosa menos que hacer si solo mueves el fondo.

Aunque supongo que si mueves el fondo, tendrás que ser padre de cualquier recolección y enemigo, lo que, de nuevo, es trivial pero es algo en lo que debes pensar.

Personalmente, movería al jugador porque me gusta que las cosas se hagan de una manera más realista.

Sir Yakalot
fuente
0

Otras respuestas son buenas, pero me gustaría agregar algunos puntos de lo que es mejor, con la esperanza de ayudar a alguien que intente tomar la misma decisión para un proyecto diferente.

Moviendo al jugador:

  • Es simple, todo lo demás es estático (ish), por lo que, en términos simplistas, lo único que debe hacer para mover el reproductor es player.x += 5;(pseudocódigo).
  • Es "Clics mejor" para la mayoría de las personas. Cuando juegas, siempre piensas que el jugador se mueve, no al revés. Por lo tanto, es más fácil pensarlo como "El jugador debe moverse, no el mundo", lo que a su vez puede facilitar que alguien lo organice en sus cabezas.
  • Fácil de rastrear dónde está el jugador (su posición es también sus coordenadas en el mapa)

Moviendo el mundo:

  • Si su juego es lo suficientemente grande, no tiene que preocuparse por el desbordamiento / desbordamiento, alejándose demasiado del centro del mundo, ya que la posición del jugador siempre está muy cerca 0.
  • De manera similar a lo anterior, si se mete con cálculos en 3D, no tiene que preocuparse por resultados inexactos con puntos flotantes, porque todo lo que ve en la pantalla debería estar bastante cerca 0.
  • Si se hace correctamente, puedes hacer un mundo "infinito".
  • Tiene que rastrear al jugador manualmente, la posición del jugador siempre será un valor pequeño, lo que significa dónde está el jugador en la pantalla (un poco), para saber si el jugador está en la parte superior izquierda del mapa o en la esquina inferior derecha, tendrías que hacer un seguimiento de eso de alguna manera.

Al final del día, depende del proyecto. Si alguien está haciendo un clon original de Mario, mover el mundo podría ser complicado, mientras que mover el reproductor realmente no crea muchos problemas. Sin embargo, queriendo hacer un gran juego de mundo abierto, puede ser mejor mover el mundo.

TomTsagk
fuente