smaraggi
commented
1 year ago Hola, super detallados los videos, muy buen trabajo.
Vamos de lo macro a lo micro. Para aprobar la materia bien no es necesario que el movimiento sea fluido, pero dado el buen trabajo que vienen haciendo, entiendo que tengan la inquietud por lograr este resultado de la mejor manera y los aliento a que lo hagan, siempre mejora el producto final y por tanto la nota. Y especialmente, su sentimiento de satisfacción con el propio trabajo. Esto es muy importante a largo plazo. Hasta acá el comentario de "coaching" (o como se llame).
Para mover la cámara, en este mundo 2D ustedes manejan 2 espacios de coordenadas: las coordenadas del mundo (escena, terreno, posición del jugador, etc.) y las coordenadas de pantalla.
La famosa vista del MVC debe poder consultar al modelo, que solamente gestiona las coordenadas del mundo, y a partir del estado de las cosas determinar las coordenadas en patnalla correspondientes a cada cosa de ese mundo.
Cuando utedes pegan saltos discretos de cámara del tamañó de un bloque, están vinculando rígidamente las coordenadas del mundo con las coordenadas de cámara... eso siempre va a ser así, pero pueden hacer que la correspondencia no sea de a saltos discretos por bloque, sino como bien dicen, por pixel... siendo que solamente la vista maneja y entiende de píxeles, no el modelo!! El modelo no sabe de la existencia de píxeles ni pantallas, en lo que al modelo concierne, podría estar siendo renderizado con visión estereoscópica en realidad virtual (aunque sea 2D, salteemos este caso extremo... quiero destacar, que el modelo no sabe qué hace la vista con los píxeles). O sea, el modelo no se toca.
Pueden hacer que la vista haga una conversión de coordenadas de la siguiente manera, en seudocódigo:
midX = windowResolutionX / 2; midY = windowResolutionY / 2;
screenPlayerPosition = (midX, midY);
Dada una posición del jugador en el mapa, el resto de los objetos tendrían su posición en la pantalla por relación al jugador. Pueden plantearlo vectorialmente
En coordenadas de mapa:
Posición del Jugador en Mapa: j_m Posición de otro objeto en mapa: o_m Diferencia jugador-objeto: d_j-o = j_m - o_m
Luego, en coordenadas de pantalla, tienen que
Jugador en pantalla es j_p
Ya vimos que j_p = screenPlayerPosition (un vector 2D, recuerden que las coordeanades de pantalla se miden desde arriba a la izquierda positivo hacia la derecha y hacia abajo, en unidades de píxeles).
Luego, posición de objeto en pantalla relacionada al jugador (en la vista):
o_p = j_p + d_j-o (objeto en pantalla = vector de jugador en pantalla + diferencia de jugador objeto en el mapa)
Verán que esta asociación de espacios vectoriales es válida en tanto la pantalla y el mundo mantengan la misma escala de distancias y orientación, cosas que estamos asumiendo por válidas. Para escenas 3D y casos más complejos se usan matrices de proyección, pero es algo que viene también resuelto por bibliotecas gráficas.
fe-martinez
claram97
Hola profe, el juego esta progresando bien y esta casi completo, por lo menos en el apartado de jugabiidad pero estos dias nos encontramos con un problema que no podemos resolver del todo. La idea es que el movimiento del jugador sea de este estilo y se mantenga en el centro de la pantalla:
https://user-images.githubusercontent.com/83876019/204566337-8794cea1-3b5f-4372-a16f-eaca6cf0ee86.mp4
Ahora mismo, se dibuja un rango de casillas para que el jugador quede en el medio, se toma una casilla de inicio para empezar a dibujar y se toma una casilla de fin para terminar de dibujar, y asi en todas las actualizaciones. El movimiento de arriba sucede cuando el personaje esta cerca de uno de los bordes del mapa, pero cuando este se mueve lo suficiente como para tener que actualizar la vista, esta se actualiza de a 1 bloque:
https://user-images.githubusercontent.com/83876019/204567870-7bb9ef7f-822c-4e93-80f8-334edd22610d.mp4
Los ejemplos son con el personaje taladrando pero tambien sucede lo mismo cuando se mueve:
https://user-images.githubusercontent.com/83876019/204584467-6594de04-d424-4df7-9d6d-aec9364e9193.mp4
Y nosotros tratamos de buscar un movimiento mas fluido, como sucede en los bordes:
https://user-images.githubusercontent.com/83876019/204584649-36e8a1ea-33c3-41db-ae84-7cff8f09505e.mp4
Lo que queriamos saber era si existia alguna solucion conocida a esto, Estuvimos googleando y muchos juegos similares, sidescrollers en general, se manejan de la forma que venimos haciendo. Lo unico que se nos ocurrio es meter render(drawImage de GraphicsContext) "de mas" dentro de un pane e ir recortando, cosa de poder hacer una actualización mas fina, pixel a pixel en vez de hacerla tile a tile como pasa ahora, pero tampoco terminamos de entender como lograr algo asi. La otra solucion seria mantener el movimiento mas basico y que se actualize como ahora, casilla a casilla.