Hace un Exploding Fist?
Hace un Exploding Fist?
Venga, vamos a dar vidilla a esto...
¿Os hace un The Way of The Exploding Fist paso a paso?
Si es así, ¿en qué lenguaje/herramienta lo hacemos? Creo una "encuesta" para que opineis. Si lo hago yo, mi opinión será la que más pese pero por si alguien quiere probar a hacer cambios en el fuente, quizá sea interesante que sea un lenguaje que conozcais...
En la encuesta pongo los motivos que me parecen "de más peso" para cada lenguaje/herramienta, y permito votar hasta 3 opciones, para que podais indicar más de una, si varias os gustan.
¿Os hace un The Way of The Exploding Fist paso a paso?
Si es así, ¿en qué lenguaje/herramienta lo hacemos? Creo una "encuesta" para que opineis. Si lo hago yo, mi opinión será la que más pese pero por si alguien quiere probar a hacer cambios en el fuente, quizá sea interesante que sea un lenguaje que conozcais...
En la encuesta pongo los motivos que me parecen "de más peso" para cada lenguaje/herramienta, y permito votar hasta 3 opciones, para que podais indicar más de una, si varias os gustan.
Re: Hace un Exploding Fist?
¡¡Genial este juego!!
Me va a encantar ver el desarrollo del mismo en C++
Me va a encantar ver el desarrollo del mismo en C++
Salu2,
Arta
Arta
- litos.net
- Loading, Please Wait...
- Mensajes: 5961
- Registrado: Mié 05 Oct , 2005 7:57 pm
- Ubicación: Madrid
- Contactar:
Re: Hace un Exploding Fist?
Estoy tan desenganchado de la programación que cualquiera será bueno con tal de verlo
Si es CPC es en Color
Re: Hace un Exploding Fist?
Por ahora gana C++... para bien o para mal...
Si no hay un giro drástico en las opiniones, la herramienta que usaré será el entorno CodeBlocks para Windows, en su versión 1.0rc2, que ofrece las mismas posibilidades que Dev-C++, pero con algún bug menos, y con la misma facilidad (o incluso más) para instalar bibliotecas (¿librerías) adicionales desde el propio menú, como SDL.
Se debería poder usar también Dev-C++, o CodeBlocks 8.02, o MinGW Developer Studio, o, los más atrevidos, Borland C++ 5.5 o incluso quizá Visual Studio, pero yo dejaré preparado el fichero de proyecto de CodeBlocks, y los ficheros .H y .DLL que son necesarios para compilar y para ejecutar el juego, así que quien use otro compilador para probarlo, estará "un poco más sólo", no tendrá todo el trabajo hecho. Hay gente a la que eso le parece un reto y gente a la que le parece un incordio, así que, cada cual que decida.
Más adelante incluiré en el proyecto el "makefile" y/o un .sh para compilar también bajo Linux (lo siento por los usuarios de Mac, no tengo ningún Mac -moderno-, aunque se aceptan donaciones )
Las imágenes del juego serán capturas del juego original, tomadas con CPCE, recortadas a 320x200 y luego escaladas a 800x600 (250% de escala, 800x500 reales) , lo que permite conservar la apariencia visual original o bien conservar la estética básica y el número de colores pero hacer las figuras un poco más detalladas... o incluso que el juego permita escoger con cual de las dos "calidades gráficas" se quiere jugar, y cargar unas imágenes u otras según elija el usuario.
Para que esto quede más o menos organizado, como este es el hilo de la encuesta, el desarrollo lo iría haciendo en otro hilo.
La intención, si el tiempo libre lo permite, sería crear una nueva "versión" cada semana, de modo que los interesados tengais tiempo de ojearlo, y yo tenga tiempo de respirar y de recoger sugerencias.
El orden estimado empezaría siendo algo así (cada punto indica una "versión"):
Si no hay un giro drástico en las opiniones, la herramienta que usaré será el entorno CodeBlocks para Windows, en su versión 1.0rc2, que ofrece las mismas posibilidades que Dev-C++, pero con algún bug menos, y con la misma facilidad (o incluso más) para instalar bibliotecas (¿librerías) adicionales desde el propio menú, como SDL.
Se debería poder usar también Dev-C++, o CodeBlocks 8.02, o MinGW Developer Studio, o, los más atrevidos, Borland C++ 5.5 o incluso quizá Visual Studio, pero yo dejaré preparado el fichero de proyecto de CodeBlocks, y los ficheros .H y .DLL que son necesarios para compilar y para ejecutar el juego, así que quien use otro compilador para probarlo, estará "un poco más sólo", no tendrá todo el trabajo hecho. Hay gente a la que eso le parece un reto y gente a la que le parece un incordio, así que, cada cual que decida.
Más adelante incluiré en el proyecto el "makefile" y/o un .sh para compilar también bajo Linux (lo siento por los usuarios de Mac, no tengo ningún Mac -moderno-, aunque se aceptan donaciones )
Las imágenes del juego serán capturas del juego original, tomadas con CPCE, recortadas a 320x200 y luego escaladas a 800x600 (250% de escala, 800x500 reales) , lo que permite conservar la apariencia visual original o bien conservar la estética básica y el número de colores pero hacer las figuras un poco más detalladas... o incluso que el juego permita escoger con cual de las dos "calidades gráficas" se quiere jugar, y cargar unas imágenes u otras según elija el usuario.
Para que esto quede más o menos organizado, como este es el hilo de la encuesta, el desarrollo lo iría haciendo en otro hilo.
La intención, si el tiempo libre lo permite, sería crear una nueva "versión" cada semana, de modo que los interesados tengais tiempo de ojearlo, y yo tenga tiempo de respirar y de recoger sugerencias.
El orden estimado empezaría siendo algo así (cada punto indica una "versión"):
- Mostrar la imagen de presentación (la pantalla de carga) y esperar a que el usuario pulse una tecla, para poder probar el entorno y ver cómo cargar y mostrar imágenes.
- Tras la presentación, mostrar el fondo y un personaje que se mueva de lado a lado (todavía sin animación).
- Personaje que se mueva "de forma animada".
- Personaje que salte, se agache y dé un primer tipo de golpe.
- Enemigo que se mueva al azar, a la vez que el personaje.
- Personaje con toda su gama de movimientos.
- Poder "golpear" al enemigo.
- Que el enemigo nos pueda "golpear" al azar.
- Mejorar la inteligencia del enemigo.
- Contar puntos, ippones, tiempo.
- Varios niveles.
Re: Hace un Exploding Fist?
Por cierto, un remake ya existe, de la versión de C64 (y aparentemente sin código fuente disponible):
http://www.geocities.com/exploding_fist_remake/
Y otro sin terminar (desde 2002), también sin fuentes, y con gráficos algo más "modernizados":
http://remakeszone.com/juegos/juego.php ... 20jugables
Aun así, seguimos adelante, ¿no?
http://www.geocities.com/exploding_fist_remake/
Y otro sin terminar (desde 2002), también sin fuentes, y con gráficos algo más "modernizados":
http://remakeszone.com/juegos/juego.php ... 20jugables
Aun así, seguimos adelante, ¿no?
Re: Hace un Exploding Fist?
Sigue, hijo mío, sigue... ardo en deseos de seguir el curso del programa desde el principio porque me intriga mucho, sobre todo, la parte de la inteligencia del enemigo. Pero el resto tampoco desmerece... seguro que se puede aplicar luego para hacer algo para cierto ordenador de 8 bits que yo me se
Salu2,
Arta
Arta
Re: Hace un Exploding Fist?
No sé yo hasta qué punto será aplicable en 8 bits: la estructura que iré usando será aplicable para crear otros remakes en PC: juegos de plataformas (o similares en 2D) para Pc, pero como como el diseño será orientado a objetos, no creo que haya herramientas similares para portarlo con rapidez a un CPC, ni creo que durante el desarrollo os descubra grandes cosas en las que nadie haya caído... de hecho, es muy fácil que los que programais con frecuencia propongáis formas alternativas (y mejores) de conseguir lo mismo...Sigue, hijo mío, sigue... ardo en deseos de seguir el curso del programa desde el principio porque me intriga mucho, sobre todo, la parte de la inteligencia del enemigo. Pero el resto tampoco desmerece... seguro que se puede aplicar luego para hacer algo para cierto ordenador de 8 bits que yo me se
Esta estructura es en la que me he basado para remakes anteriores, como uno de Krakout que hice hace un par de años (en C++), el del Freddy que están haciendo entre mis alumnos (en C#) y el de Fruity que está a medio hacer como ejemplo para ellos (también en C#). Es una estructura un poco "parcheada", y que tiene más de una carencia, pero servirá. De hecho, supongo que todos esos remakes acabarán llegando a este subforo...
En cuanto, al Exploding Fist, la grafista de la familia está terminando de retocar la pantalla de carga, para adaptarla a 800x600 conservando la paleta de colores original. En cuanto esté lista (casi seguro que mañana mismo), abro un nuevo hilo y publico la versión 0.01.
Re: Hace un Exploding Fist?
¿Y para qué abrir otro hilo si ya tienes éste?
Re: Hace un Exploding Fist?
Por eso de que este era el hilo de la encuesta para ver si había interés y para ver qué lenguaje os apetecía más. Si preferís que sigamos en este mismo hilo, ningún problema por mi parte.¿Y para qué abrir otro hilo si ya tienes éste?
Re: Hace un Exploding Fist?
Vamos con la primera entrega...
En esta entrega hay 3 clases (lo que equivale a 6 ficheros en C++: los 3 ficheros .H de cabecera y los 3 ficheros .CPP de desarrollo).
La clase "Juego" por ahora mismo no hace casi nada: sólo mostrar una presentación (algo que dentro de poco ni siquiera será responsabilidad del juego, sino de una nueva clase "Presentación").
El bucle de juego, que debería ser la parte repetitiva del juego (mover personajes, comprobar colisiones, dibujar todos los elementos, etc), de momento no hace nada de eso: se limita a mostrar la pantalla de bienvenida:
Y esta función "bienvenida" muestra la imagen de carga "original" del juego, dos segundos después escribe un par de textos, y finalmente dibuja la imagen de carga "retocada" a 800x600 y espera a que se pulse una tecla. Cuando se pulse la tecla, se sale del "juego":
Ese "cartelAntiguo" y "cartelNuevo" se cargan desde el constructor de la clase "Juego":
Adjunto el fichero con los fuentes, las dos imágenes usadas por ahora y el proyecto de CodeBlocks para quien quiera recompilar.
¿Dudas por ahora? ¿Sugerencias? ¿Mejoras?
En esta entrega hay 3 clases (lo que equivale a 6 ficheros en C++: los 3 ficheros .H de cabecera y los 3 ficheros .CPP de desarrollo).
- La clase Hardware, que se encarga de ocultar la librería gráfica que estamos empleando, para hacer más fácil su manejo y para permitir usar una librería gráfica a otra sin tener que hacer cambios muy drásticos al fuente del juego en sí. Esta clase tiene preparadas funciones para dibujar imágenes y textos en una pantalla oculta (para evitar parpadeos), volcar esa pantalla oculta a la pantalla visible, comprobar teclado y ratón, etc.
- La clase ElementoGraf (elemento gráfico), que se encarga de ciertas tareas habituales en la manipulación de "sprites", como moverlo a otra posición, indicar un color transparente, o comprobar posibles colisiones con otro sprite.
- La clase Juego, que se encarga de la lógica del juego.
Código: Seleccionar todo
int main ( int argc, char** argv )
{
Juego j;
j.bucleJuego();
return 0;
}
El bucle de juego, que debería ser la parte repetitiva del juego (mover personajes, comprobar colisiones, dibujar todos los elementos, etc), de momento no hace nada de eso: se limita a mostrar la pantalla de bienvenida:
Código: Seleccionar todo
void Juego::bucleJuego() {
bienvenida();
}
Código: Seleccionar todo
void Juego::bienvenida() {
// Primero muestro el cartel antiguo
cartelAntiguo.moverA(0,50);
hard.dibujarOculta(cartelAntiguo);
hard.visualizarOculta();
hard.pausa(2000);
// Dos segundos despues, textos, el nuevo cartel... y pausa
hard.escribirTextoOculta("The way of the Exploding Fist",
200, 10, 0xFF9966,
hard.Fuente_sans24);
hard.visualizarOculta();
hard.pausa(1000);
hard.escribirTextoOculta("Remake 2009",
300, 560, 0x9999FF,
hard.Fuente_sans24);
hard.visualizarOculta();
hard.pausa(1000);
cartelNuevo.moverA(0,50);
hard.dibujarOculta(cartelNuevo);
hard.visualizarOculta();
hard.esperarTecla();
}
Código: Seleccionar todo
Juego::Juego() {
hard.inicializar();
cartelAntiguo.crearDesdeFichero("data\\fist_present0.png");
cartelNuevo.crearDesdeFichero("data\\fist_present.png");
}
¿Dudas por ahora? ¿Sugerencias? ¿Mejoras?
- Adjuntos
-
- fist01.zip
- Entrega 0.01: Fuentes, imágenes, proyecto de CodeBlocks
- (73.84 KiB) Descargado 156 veces
Re: Hace un Exploding Fist?
Como se acerca una racha de poco tiempo libre, adelanto la segunda entrega, que ya muestra un primer personaje que se mueve de lado a lado (estático, sin animación) cuando se pulsan las teclas del cursor. Si se pulsa ESC, se sale del cuerpo del juego y se vuelve a la pantalla de bienvenida.
El juego ya incluye una primera versión de lo que será el "bucle de juego":
El personaje forma parte todavía de la clase juego (la presentación ya no lo es, ahora es una clase independiente).
El método "dibujarPantalla" muestra los dos únicos elementos que hay ahora mismo en la pantalla: el fondo en las coordenadas (0,50), y el personaje, en coordenadas variables:
Y "comprobarTeclas" mira si se pulsa ESC (para salir) o las flechas izquierda o derecha (para mover el personaje):
Las otras funciones previstas, "comprobarColisiones" (para ver si el personaje ha golpeado al enemigo o viceversa), y "siguienteFotograma" (para proseguir las animaciones que estén a medias, aunque no pulsemos ninguna tecla) no hacen nada por ahora.
Adjunto nuevamente todos los fuentes (9), junto con las imágenes en uso (presentación, fondo y personaje en posición de combate, mirando hacia la derecha).
El juego ya incluye una primera versión de lo que será el "bucle de juego":
Código: Seleccionar todo
void Juego::bucleJuego() {
nuevaPartida();
do {
dibujarPantalla();
comprobarTeclas();
comprobarColisiones();
siguienteFotograma();
// Pausa de 40 ms, para velocidad de 25 fps (1000/40 = 25)
hard.pausa(40);
// Fin de la parte repetitiva
} while (! partidaTerminada); // Hasta tecla ESC
}
El método "dibujarPantalla" muestra los dos únicos elementos que hay ahora mismo en la pantalla: el fondo en las coordenadas (0,50), y el personaje, en coordenadas variables:
Código: Seleccionar todo
void Juego::dibujarPantalla(){
/// (Por hacer)
hard.borrarOculta();
fondo.moverA(0,50);
hard.dibujarOculta(fondo);
personaje.moverA(xPersonaje,yPersonaje);
hard.dibujarOculta(personaje);
hard.visualizarOculta();
}
Código: Seleccionar todo
void Juego::comprobarTeclas(){
if (hard.comprobarTecla(TECLA_ESC))
partidaTerminada = true;
if (hard.comprobarTecla(TECLA_DCHA))
xPersonaje += 4;
if (hard.comprobarTecla(TECLA_IZQD))
xPersonaje -= 4;
}
Las otras funciones previstas, "comprobarColisiones" (para ver si el personaje ha golpeado al enemigo o viceversa), y "siguienteFotograma" (para proseguir las animaciones que estén a medias, aunque no pulsemos ninguna tecla) no hacen nada por ahora.
Adjunto nuevamente todos los fuentes (9), junto con las imágenes en uso (presentación, fondo y personaje en posición de combate, mirando hacia la derecha).
- Adjuntos
-
- fist02.zip
- Entrega 0.02: Fuentes, imágenes, proyecto de CodeBlocks
- (83.42 KiB) Descargado 166 veces
Re: Hace un Exploding Fist?
Vamos con la tercera entrega.
Ahora hay una clase "Personaje", independiente de la clase "Juego". A su vez, hay dos subclases de ésta, llamadas "PersonajeA" y "PersonajeB", por eso de que en el juego hay dos personajes "casi idénticos" salvo por el hecho de que uno está en color azul y otro en color blanco. Ambos podrán moverse a derecha e izquierda, dar golpes, etc., así que sólo se distinguirán en el constructor, que se encargará de indicar su posición inicial y de cargar sus imágenes.
Ya de paso, podemos crear un método "moverDerecha", que no sólo desplace un personaje (sea el A o el B) hacia la derecha, sino que también permita que cambie su apariencia, alternando distintos fotogramas:
donde ese "siguienteFotograma" es el que se encarga realmente de alternar una imagen por la siguiente, algo que se puede hacer en todos los fotogramas o mejor, para que el movimiento no sea demasiado rápido, cada cierto número de fotogramas:
Así, en cada pasada del bucle principal del juego se dibuja tanto nuestro personaje como el enemigo:
pero el enemigo está inmóvil, porque por ahora sólo se comprueban dos teclas, las que mueven a derecha e izquierda nuestro personaje, y el enemigo todavía no tiene ninguna "inteligencia" que le ayuda a moverse sólo:
Adjunto nuevamente los fuentes (ahora ya son 15, pertenecientes a 7 clases) y las imágenes (presentación, fondo, dos imágenes para nuestro personaje y una imagen para el enemigo).
Ahora hay una clase "Personaje", independiente de la clase "Juego". A su vez, hay dos subclases de ésta, llamadas "PersonajeA" y "PersonajeB", por eso de que en el juego hay dos personajes "casi idénticos" salvo por el hecho de que uno está en color azul y otro en color blanco. Ambos podrán moverse a derecha e izquierda, dar golpes, etc., así que sólo se distinguirán en el constructor, que se encargará de indicar su posición inicial y de cargar sus imágenes.
Ya de paso, podemos crear un método "moverDerecha", que no sólo desplace un personaje (sea el A o el B) hacia la derecha, sino que también permita que cambie su apariencia, alternando distintos fotogramas:
Código: Seleccionar todo
/** moverDerecha: mueve el personaje hacia la derecha
*/
void Personaje::moverDerecha() {
posX += 4;
siguienteFotograma();
}
Código: Seleccionar todo
/** siguienteFotograma: anima el personaje si corresponde
*/
void Personaje::siguienteFotograma() {
contadorFotogramas ++; // No se actualiza siempre
if (contadorFotogramas < 2)
return;
contadorFotogramas = 0;
if (pose == POSEDCHA1) // Alterno posicion derecha
{
pose = POSEDCHA2;
imagen = imagenDcha2;
}
else if (pose == POSEDCHA2)
{
pose = POSEDCHA1;
imagen = imagenDcha1;
}
}
Código: Seleccionar todo
/** dibujarPantalla: dibuja todos los elementos en pantalla
*/
void Juego::dibujarPantalla(){
hard.borrarOculta();
fondo.moverA(0,50);
hard.dibujarOculta(fondo);
hard.dibujarOculta(enemigo);
hard.dibujarOculta(miPersonaje);
hard.visualizarOculta();
}
Código: Seleccionar todo
/** comprobarTeclas: comprueba pulsaciones de teclas y avisa
* a cada elemento implicado
*/
void Juego::comprobarTeclas(){
if (hard.comprobarTecla(TECLA_ESC))
partidaTerminada = true;
if (hard.comprobarTecla(TECLA_DCHA))
miPersonaje.moverDerecha();
if (hard.comprobarTecla(TECLA_IZQD))
miPersonaje.moverIzquierda();
}
- Adjuntos
-
- fist03.zip
- Entrega 0.03: Fuentes, imágenes, proyecto de CodeBlocks
- (89.92 KiB) Descargado 157 veces
Re: Hace un Exploding Fist?
Vamos con la cuarta entrega.
Vamos a añadir un par de movimientos al personaje, lo que además ayudará a ver la problemática de este juego concreto...
En concreto, vamos a añadir dos movimientos aparentemente simples: agacharse y saltar.
En otros juegos, las animaciones del personaje son secuencias predefinidas que se repiten a intervalos regulares, para dar la impresión de movimiento, por ejemplo, A-B-C-D, algo que se puede conseguir con un "array" de imágenes.
Si hay distintas secuencias según la dirección en que se mueva el personaje, podemos hacerlo con un "arrays multidimensional", o con "array de arrays", según las posibilidades del lenguaje que empleemos y según si las secuencias son igual de largas en todas las direcciones o si hay unas secuencias más largas que otras.
En el caso del Exploding Fist, la situación cambia:
- Si el personaje se agacha, debe permanecer agachado mientras la tecla esté pulsada, y volver a levantarse cuando dejemos de pulsar la tecla. Además, sólo hay un fotograma para mostrarlo agachado.
- Si salta, existen dos fotogramas en el salto, uno de los cuales dura muy poco tiempo, y otro que dura una mayor cantidad de tiempo. Además, mientras está saltando no podemos hacer otra cosa, hasta que se complete la secuencia del salto.
Esto hace que no se pueda atacar con una solución tan sencilla como la del "array de imágenes". En su lugar, tenemos que buscarnos un poco más la vida, añadiendo cosas como una opción "volver a espera" cuando no se pulse ninguna tecla:
Asi, la opción de agacharse sería muy sencilla:
Por el contrario, la opción de saltar se complica, porque tenemos 3 posibles fotogramas que se alternan, uno de los cuales debe durar bastante más que los otros, algo que podríamos hacer así:
Y ahora necesitaremos una función "animarMovimiento", que se encargue de seguir animando esos movimientos que vayan a durar más de un "fotograma" del juego, y que en su estructura será muy parecida a la "siguienteFotograma" que habíamos usado para intercambiar los movimientos al andar:
Pero esta función se llamará en cada "fotograma" del juego, aunque no pulsemos ninguna tecla, desde la función "siguienteFotograma", que hasta ahora no hacía nada:
Suficiente por hoy. Adjunto nuevamente los fuentes (que ahora no aumentan en cantidad, aunque sí un poco en complejidad) y las imágenes (que incluyen las del salto y el personaje agachado).
¿Dudas? ¿Cosas que se podrían mejorar?
Vamos a añadir un par de movimientos al personaje, lo que además ayudará a ver la problemática de este juego concreto...
En concreto, vamos a añadir dos movimientos aparentemente simples: agacharse y saltar.
En otros juegos, las animaciones del personaje son secuencias predefinidas que se repiten a intervalos regulares, para dar la impresión de movimiento, por ejemplo, A-B-C-D, algo que se puede conseguir con un "array" de imágenes.
Si hay distintas secuencias según la dirección en que se mueva el personaje, podemos hacerlo con un "arrays multidimensional", o con "array de arrays", según las posibilidades del lenguaje que empleemos y según si las secuencias son igual de largas en todas las direcciones o si hay unas secuencias más largas que otras.
En el caso del Exploding Fist, la situación cambia:
- Si el personaje se agacha, debe permanecer agachado mientras la tecla esté pulsada, y volver a levantarse cuando dejemos de pulsar la tecla. Además, sólo hay un fotograma para mostrarlo agachado.
- Si salta, existen dos fotogramas en el salto, uno de los cuales dura muy poco tiempo, y otro que dura una mayor cantidad de tiempo. Además, mientras está saltando no podemos hacer otra cosa, hasta que se complete la secuencia del salto.
Esto hace que no se pueda atacar con una solución tan sencilla como la del "array de imágenes". En su lugar, tenemos que buscarnos un poco más la vida, añadiendo cosas como una opción "volver a espera" cuando no se pulse ninguna tecla:
Código: Seleccionar todo
void Juego::comprobarTeclas(){
if (hard.comprobarTecla(TECLA_ESC))
partidaTerminada = true;
if (hard.comprobarTecla(TECLA_DCHA))
miPersonaje.moverDerecha();
else if (hard.comprobarTecla(TECLA_IZQD))
miPersonaje.moverIzquierda();
else if (hard.comprobarTecla(TECLA_ABAJ))
miPersonaje.moverAbajo();
else if (hard.comprobarTecla(TECLA_ARRB))
miPersonaje.moverArriba();
else
miPersonaje.volverAEspera();
}
Asi, la opción de agacharse sería muy sencilla:
Código: Seleccionar todo
void Personaje::moverAbajo() {
posY += 12;
imagen = imagenAgachadoD;
posY -= 12;
}
Código: Seleccionar todo
void Personaje::moverArriba() {
if (imagen == imagenSaltoD1) { // Si empieza a saltar: sigue saltando
posY -= 16;
imagen = imagenSaltoD2;
pose = POSESALTOD;
enMovimiento = true;
}
else if (imagen == imagenSaltoD2) {
// Si se está animando el salto, no hay nada que hacer desde aqui
return;
}
else { // Si está en el suelo: empieza a saltar
posY -= 8;
imagen = imagenSaltoD1;
}
}
Código: Seleccionar todo
void Personaje::animarMovimiento(){
if (!enMovimiento) // Solo si hay algo que animar
return;
if (pose == POSESALTOD) // Salto
{
contadorFotogramas ++; // No se actualiza siempre
if (contadorFotogramas < 4)
return;
contadorFotogramas = 0;
posY += 24;
pose = POSEDCHA1; // Al final: en el suelo, a la derecha
imagen = imagenDcha1;
enMovimiento = false;
}
}
Código: Seleccionar todo
void Juego::siguienteFotograma(){
/// (Por completar)
miPersonaje.animarMovimiento();
}
¿Dudas? ¿Cosas que se podrían mejorar?
- Adjuntos
-
- fist04.zip
- (94.67 KiB) Descargado 150 veces
Re: Hace un Exploding Fist?
Vamos a por la quinta entrega.
El juego deberá permitir (finalmente, aunque todavía no) jugar partidas de dos jugadores o de un jugador contra el ordenador.
Eso supone que el personaje debe ser capaz de "moverse solo". Vamos a hacer un primer acercamiento, y de paso, a corregir algún fallo de la versión anterior.
Una primera forma de que se mueva "solo" podría ser escogiendo un número al azar. Por ejemplo: si sale 1, se moverá a la derecha; si sale 2, se moverá a la izquierda. Para que sea un poco más real, podemos añadir también la posibilidad de que permanezca estático. También podríamos hacer que las probabilidades de cada movimiento no sean justo exactamente las mismas (por ejemplo, que sea más probable que se acerque a nosotros, en vez de alejarse). Para ello, podemos generar un número del 1 al 10 o incluso del 1 al 100:
En cuanto a los fallos de la versión anterior, tenía alguno:
Y así, la función "moverArriba" se encargaría de marcar que está en medio de un movimiento:
mientras que "animarMovimiento" iría encadenando los siguientes fotogramas, aunque ya no estemos pulsando ninguna tecla:
El juego deberá permitir (finalmente, aunque todavía no) jugar partidas de dos jugadores o de un jugador contra el ordenador.
Eso supone que el personaje debe ser capaz de "moverse solo". Vamos a hacer un primer acercamiento, y de paso, a corregir algún fallo de la versión anterior.
Una primera forma de que se mueva "solo" podría ser escogiendo un número al azar. Por ejemplo: si sale 1, se moverá a la derecha; si sale 2, se moverá a la izquierda. Para que sea un poco más real, podemos añadir también la posibilidad de que permanezca estático. También podríamos hacer que las probabilidades de cada movimiento no sean justo exactamente las mismas (por ejemplo, que sea más probable que se acerque a nosotros, en vez de alejarse). Para ello, podemos generar un número del 1 al 10 o incluso del 1 al 100:
Código: Seleccionar todo
void Personaje::moverAlAzar() {
// Genero un numero del 1 al 10
int n = rand() % 10 + 1;
switch(n)
{
case 1:
case 2:
case 3: moverDerecha(); break;
case 4:
case 5:
case 6: moverIzquierda(); break;
case 7:
case 8:
case 9:
case 10: /* No hacer nada */ break;
}
}
- La posición agachada quedaba un poco "alta". Una forma sencilla de solucionarlo, en vez de modificar la coordenada Y, es hacer que la imagen sea igual de alta que las demás (tendrá más espacio en blanco por encima).
- Durante el "salto", se podía pulsar la tecla derecha o izquierda, con lo que el personaje se movía hacia el lado inmediatamente, y quedaba un poco más alto cada vez.
Código: Seleccionar todo
void Personaje::moverIzquierda() {
if (enMovimiento)
return;
posX -= 4;
siguienteFotograma();
}
Código: Seleccionar todo
void Personaje::moverArriba() {
if (enMovimiento)
return;
enMovimiento = true;
imagen = imagenSaltoD1;
posY -= 8;
}
Código: Seleccionar todo
void Personaje::animarMovimiento(){
if (!enMovimiento) // Solo si hay algo que animar
return;
contadorFotogramas ++; // No se actualiza siempre
if (contadorFotogramas < 4)
return;
contadorFotogramas = 0;
if (imagen == imagenSaltoD1) { // Si empieza a saltar: sigue saltando
posY -= 16;
imagen = imagenSaltoD2;
cout << "am1 ";
}
else if (imagen == imagenSaltoD2)
{ // Si se está animando el salto, no hay nada que hacer desde aqui
posY += 24;
pose = POSEDCHA1; // Al final: en el suelo, a la derecha
imagen = imagenDcha1;
enMovimiento = false;
}
}
- Adjuntos
-
- fist05.zip
- Entrega 0.05
- (96.85 KiB) Descargado 149 veces
Re: Hace un Exploding Fist?
¡Genial! ya me he instalado (por fín) el codeBlocks y lo he compilado. Ahora a seguir el curso en condiciones y así aprendo C++ que me va a venir bien.
Salu2,
Arta
Arta
¿Quién está conectado?
Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro
La Comunidad Española |