A un árbol me subí
donde manzanas había.
Si manzanas no comí
y manzanas no dejé...
¿cuántas manzanas había?.
donde manzanas había.
Si manzanas no comí
y manzanas no dejé...
¿cuántas manzanas había?.
El ejemplo:
Mi idea inicial era que el personaje consiguiese, en un momento determinado del juego, una cuerda que podría lanzar para poder subir y bajar. He programado el lanzamiento de la cuerda pero al ir a integrarlo con el movimiento del muñeco he visto que se complicaba mucho. ¿Cuándo recoger la cuerda? ¿Difícil acertar para que se enganche? ¿Hacia dónde está mirando el muñeco?. En definitiva, ¿qué pasa, si como en la mayoría de los juegos, dejo las cuerdas ya colocadas?. Así que descartado el lanzamiento y cuerdas colocadas. ¿Qué pasa con las cuerdas? ¿Por qué los juegos utilizan escaleras? Si engancho las cuerdas en los troncos de arriba el muñeco al subir quedará en el aire, subiendo sin cuerda, ya que no tiene sentido que las cuerdas sobresalgan por encima de los troncos. Para resolver esto nada más sencillo que poner escaleras en lugar de cuerdas ya que las escaleras sí sobresalen. En muchos juegos las escaleras se ven de frente. Después de programar esta parte está claro que esa solución es muchísimo más sencilla ya que no hay que tener en cuenta hacia qué lado mira el personaje y no hay que tener más que una animación con el muñeco de espaldas. En mi caso he dibujado la animación de subir y bajar en la escalera de la derecha (con el personaje mirando hacia la izquierda). Así las manos coinciden con la escalera. Al reflejar el personaje para que suba por el otro lado las manos ya no quedan en la escalera, si no que vuelan. Debería retocar las animaciones, cosa que no hubiera sucedido con la escalera de frente. Además si hubiésemos descartado la poca profundidad que tiene mi escenario también nos hubiésemos evitado el tener que estar mirando qué queda delante y qué queda detrás. Necesitamos poner un plano en el frente para ocultar las manos cuando se sube por la escalera detrás de los troncos.
Para manejar por donde se mueve el personaje y para definir la pantalla he creado el javascript pantalla.js. Se crean segmentos por donde se puede mover el personaje, fuera de ellos no se permite el movimiento (hay que llegar al final del segmento para poder cambiar de dirección, quizás sea necesaria una pequeña ayuda aquí). Además los segmentos verticales se marcan para saber si el personaje debe mirar hacia la derecha o hacia la izquierda. Esta definición es automática y sólo hay que proporcionar los puntos que unen los segmentos de izquierda a derecha. En el caso de esta pantalla, el recorrido se define como:Pantalla([0,255,180,255,180,54,546,54,546,255,736,255]);
El recorrido a realizar es el mostrado en negro pero teniendo en cuenta la posición y el tamaño de las imágenes del sprite y que se su posición es la esquina superior izquierda, nos queda el recorrido mostrado en rojo.
Además dentro de la Pantalla hemos metido un par de métodos que nos indicarán si se llega al final del recorrido (siguiente pantalla) o si se va al inicio (pantalla anterior).He ampliado el script “listeners” para tener en cuenta las teclas para subir y bajar. Aunque por el momento las teclas son las flechas tendré que cambiarlas ya que se utilizan para mover el scroll y si éste existe es un problema (ahora lo eliminado impidiendo en el html que aparezca).
El código de sprite.js también lo he modificado adaptándolo a los nuevos movimientos y “generalizándolo” para sprites que se mueven con el teclado en todas direcciones (¡sólo uno!).
¿El tamaño “de la cámara”? No tengo muy claro qué tamaño del personaje elegir. En las pantallas donde va haber conversación con otros personajes lo ideal es lo mostrado en los primeros ejemplos, de cerca, pero para otras pantallas, como la primera de este ejemplo, da mucho más juego poner “la cámara” más alejada. Esto nos obliga a meter más imágenes con distintos tamaños o a escalarlas en el canvas. Otra opción podría ser elegir un tamaño intermedio pero, a mí, el cambio de escala me resulta más atractivo de cara al peque.
No hay comentarios:
Publicar un comentario