No sé si empezar con este proyecto

[Drumpi]

Buenas a todos:


Llevo tiempo dándole vueltas a la cabeza a una idea. El Echo se me eterniza por la complejidad que ha alcanzado el código, y quería hacer algo sencillo para desbloquearme las neuronas.
Había pensado hacer algo en vista aérea, no sé si tipo Zelda, JRPG o simplemente plataformas.
Quería hacer una aventura, en principio que se pudiera saltar, moverse en las 8 direcciones, y usar un mapa de durezas 3D, aunque todo sea en 2D, para poder añadir puentes, túneles... no sé si eso se me iba a complicar mucho, pero lo veo más sencillo que hacerlo todo con un mapa de durezas 2D. Incluso que el juego sea más un Metroid que un Zelda.
Luego se me ocurrió que podía meter a foreros y personajes suyos en la historia (Momia, Pixel, Splinter, InventoMan, Panta, el Bennu del logo..) y hacer una Drumpilocura de historia, con muchas referencias a la programación y a los tropos de los videojuegos, pero eso me fuerza a tener varios personajes, y ya las plataformas y el estilo Zelda se me quedan cortos. Hacer un JRPG implica tener que diseñar los combates, y eso me iba a complicar más las cosas, al tener que incluir una jugabilidad diferente al meollo.


También quería ir subiendo versiones a medida que fuera añadiendo una cierta cantidad de contenido, por lo que la historia y los mapas los iría improvisando, e irían cambiando con el tiempo, y se podría ver su evolución con el tiempo.


Pero claro, está lo de seguir con el Echo, y que cada vuelta que le doy a este proyecto se me complica más y más, así que me gustaría contar con alguna opinión de fuera de mi cabeza, si es posible. Y de paso, en qué plataformas programarlo, porque hacerlo para Wiz para jugarlo yo solo no me gusta, o que luego se me pida un port a una consola de 320x240 y que no pueda. ¿Cómo lo véis?

[SplinterGU]

ya, 320x240, me parece poco...

[Drumpi]

Pues es la resolución que uso en la mayoría de mis juegos :D
Además, me ayuda a no tener que hacer sprites con muchos detalles y reduzco el tiempo que paso en el apartado gráfico. Pero de esa forma llego a menos público, la gente prefiere jugar en PC antes que en una consola china de emulación :D

[SplinterGU]

Pues es la resolución que uso en la mayoría de mis juegos :D
Además, me ayuda a no tener que hacer sprites con muchos detalles y reduzco el tiempo que paso en el apartado gráfico. Pero de esa forma llego a menos público, la gente prefiere jugar en PC antes que en una consola china de emulación :D

asi es...

[Drumpi]

Le sigo dando vueltas a la idea, y me gustaría probarlo, porque hay mecánicas que me gustaría ver si funcionan, y cómo de grande puedo hacer un escenario.

La primera gran duda es ¿cómo planteo la detección de colisiones con el escenario? Tengo claro que tengo que usar un sistema de durezas. Estaba pensando en usar algo similar al Echo, basándome en los tiles de durezas, lo cual me ayuda a reducir información y evito el GetMapPixel.
La duda viene en que no debo tomar sólo la referencia del centro de los pies, porque el personaje tiene un volumen, y no quiero que medio cuerpo esté atravesando la pared. También quiero que si se choca de frente con una pared en ángulo, que la recorra.

Básicamente, quería preguntaros si alguno había hecho algo parecido, y si tomaba las durezas desde las esquinas del gráfico, sólo desde el centro, si toda la línea frontal mediante un bucle... algunas ideas para no complicarme demasiado la vida, porque cuantas más vueltas le doy, más se me enrevesa el código en mi cabeza, y quiero que sea sencillo, y no la monstruosidad del Echo, con 2500 líneas ^^U

[warrior_rockk]

En mi caso, para esas situaciones, he utilizado un array de puntos de colisión en las posiciones arriba/izquierda, arriba/derecha, centro/izquierda, centro/derecha, abajo/izquierda, abajo/derecha y abajo/centro.
Según el tamaño del sprite te toca dividir en mas posiciones para evitar que el cuerpo sobresalga de los obstáculos, pero para un sprite de baja resolución está bien con esos 7 u 8 puntos y así puedes comprobar las colisiones con bastantes puntos del personaje.


Para seguir una pared en ángulo, tienes que escoger el comprobar la colisión con el punto lateral (izquierda/derecha) que mas te interese (arriba, centro o abajo) y comprobar la colisión con trazado de rayos, esto es, comprobar en bucle todos los pixeles que hay desde tu punto a comprobar hasta la posición siguiente una vez le apliques la velocidad que lleva. Si encuentra colisión, que te devuelva cuantos pixeles hay hasta la línea y te posicione justo en ella o a -1 pixel de distancia.


Es el mismo procedimiento que para situarte sobre rampas en un plataformas.


Cuando lo he realizado, he implementado un sistema de desactivación de puntos de control ya que, cuando estás en un ángulo, hay puntos de colisión que quedarán "dentro" del obstáculo y tienes que ignorarlos hasta que salgas de la colisión con el ángulo.

[Drumpi]

Mmm, sí, un sistema clásico de durezas, usando 8 puntos de control.
Más o menos es una de las ideas que barajaba, esa y la de  comprobar el siguiente tile y actuar en consecuencia.

Lo que me gustaría saber es cómo tratas los conflictos de dos puntos. Por ejemplo, imaginemos que vamos hacia abajo, y que llegamos a una pared en V. El punto de la derecha empujará al prota hacia la izquierda, y el de la izquierda hacia la derecha ¿Qué sucede entonces? ¿Cada punto de la parte inferior contiene sus variables de hacia dónde se puede mover el prota y se contrarrestan, o va todo a la misma variable y se impone la última comprobación?

[warrior_rockk]

Esa situación se resolverá por si sola. Las colisiones de cada punto de control deben ir separadas en colisiones en eje X y en Y.
En el caso concreto de una pared en V, se recorrerá el bucle de puntos de control para controlar las colisiones en X y , primero corregirá la X de un lado que colisiona, luego la del otro.
Luego se recorrerá el bucle de puntos de control para las colisiones en Y y moverá hacia arriba los puntos que colisionen con la pared en V.
Al final de ejecución del algoritmo, tendrá al personaje fuera de la zona de colisión de la pared y pegado a uno de los lados válidos de la pared.
Para que las detecciones sean correctas y el sistema no entre en una corrección continua cada frame,  hay que tener en cuenta que los puntos de colisión deben ser proporcionales entre ellos (a la misma distancia del centro) y la pared en V debe formar una figura de triángulo distinta a un escaleno (ningún lado igual).


Por último señalar que, en muchas ocasiones , y sobretodo para los vídeojuegos, los programadores tendemos a crearnos problemas complejos para solucionar con algoritmos con todo los inconvenientes que llevan de aparición de bugs y complicación de código cuando la respuesta adecuada es .. ¡evitar ese problema!
Es mas correcto analizar la necesidad de hacer una pared en V cuando el juego no tiene porque necesitar esa complicación programática y, si es un requerimiento a nivel artístico, el juego siempre puede mostrar los tiles de pared en V pero tratar la dureza como ángulos rectos y siempre puede dejar al personaje, mas o menos, bien posicionado.


En definitiva, a veces nos complicamos demasiado por el placer de resolver problemas pero en los juegos se espera algo más practico. Es por ello que no veras en juegos plataformas clásicos rampas descendientes y ascendientes juntas (\/) ni paredes en V en juegos tipo RPG (y si se ven gráficamente, es posible que se estén tratando internamente de otra manera).


Estudiando el código de juegos clásicos se aprenden un montón de trucos ingeniosos que se utilizaban para resolver o "engañar" al jugador ante distintos problemas con las mecánicas.

[Drumpi]

Bueno, me consta que sí se da el caso en juegos, como Chrono Trigger.
A ver, mi idea no es crear tiles muy complejos, sólo el tile vacío, el tile lleno, y las 4 diagonales, y ya repetir el set para los diferentes tipos de suelo. Por ahora, serán un set para "no hay suelo", es decir, para caerse al piso de abajo o al abismo, otro para suelo normal, otro para ir al 50% de la velocidad (especialmente diseñados para vehículos), un set de agua y probablemente un set para lava, ácido y cualquier suelo dañino.
Incluso estaba pensando organizarlos según los 4 bits menos significativos, para que cada uno de ellos me indique si cada uno de los lados del tile está libre de paso o no, y así me ahorro aquellos case infinitos de:

Code Select Expand

if (tile_siguiente)
case 1,2,3,5,8,11,12,13,15,18: tile_libre = false; end
case 4,6,14,16: mover_diagonal(); end
default: tile_libre = true; end
end //switch

Sería más bien algo como:

Code Select Expand

if (velx > 0 and (tile & 1))
    velx = 0;
else
    comprueba_suelo;
end

La duda está en que si voy de frente contra una pared diagonal, avanzo de frente y hacia el lado. Pero lo dicho, si me muevo hacia dos tiles formando una V, el punto de control izquierdo me permite avanzar y desplaza al prota un pixel a la derecha, y el derecho lo hace hacia la izquierda, finalmente no me desplazo de lado, pero tengo que procurar entonces no avanzar más, y lo que pase en un punto lo debo tener en cuenta en el otro... y así en las 4 direcciones.

Estoy de acuerdo en que a veces nos complicamos demasiado, pero esos "trucos" de los que hablas prefiero evitarlos porque, a menos que los tengas bien documentados y en un lugar de acceso tan fácil que lo veas hasta por accidente, al final se pasan por alto y empiezan a verse bugs que no sabes de dónde vienen hasta que haces una traza exhaustiva del programa..

[Drumpi]

Jo, me he estado leyendo el subforo del SBTime, de cuando Fede, Futu, Caleb y Prince nos pusimos a desarrollarlo, y me han entrado unas ganas locas de hacer un sucedáneo de Mario Kart en modo7 con varias plantas, aprovechando el motor del nivel 3 del juego, que ya lo tengo adaptado :D
Naturalmente habría más cambios (andaba pensando en meterle editor de circuitos), pero básicamente, sólo con poder meterle diferentes plantas, y quizás un botón de salto, sería suficiente para que sea distinto a todo lo visto hasta ahora :D

"Hazlo ya en 3D" me dirán algunos, pero no me quiero meter con físicas en 3D, que me dan mal rollo :D

[Drumpi]

Volviendo a la idea del juego de carreras en modo7, me estaba preguntando ¿y si aprovecho y lo hago en PixTudio, como primer proyecto en serio? :D
La pega sería tener que reescribir el motor, pero no creo que haya demasiados problemas, sólo serían cambiar los nombres de algunas funciones, y sustituir la lectura de teclas.
Por otro lado, sería interesante saber a qué nivel de implementación está el modo7, por si puedo aplicar efecto tipo niebla, con un modo7 transparente o cosas así.