Proyecto: Juego con scroll horizontal y posterior port para CAANOO

NesKy · November 21, 2010, 12:23:20 PM

Hola gente,

Como primera aportación al foro traigo este proyecto del que sólo tengo la idea y este primer boceto que cuelgo al final del mensaje. Se trata de un juego con scroll horizontal contínuo (no controlamos nosotros) donde tenemos que ir matando a los aviones/helicópteros/ovnis... que nos van saliendo en la parte superior de la pantalla desde los dos lados. Nosotros nos encontramos en la parte inferior del mapa (carretera/camino...) siendo un vehículo tipo tanque/coche/plataforma... Para quien no lo entienda, me baso en el juego para xbox360 arcade "Heavy Weapon" salvando las distancia claro :D: http://www.youtube.com/watch?v=wgD0OWgk0lY.

De momento sólo tengo hecho el proceso para el protagonista, los enemigos y los disparos. El fondo está sacado del mismo juego anterior y las demás (aviones, misiles,...) también sacadas de por ahí. Lo que sería interesante es poder crearlas yo mismo, pero de creación artística no voy muy sobrado. Aun tengo que encontrar la imagen para el protagonista (ahora hay un rectangulo rojo).

Una vez terminado el juego, o durante, se tendria que hacer el port para la consola CAANOO, ya que me la compré para algo ;D. Ya tengo estudiado el sistema para hacerlo, lo único que tengo dudas es en el tema de los 16/32 bits. Tengo entendido que sólo se pueden pasar juegos con profundidad de 16 bits? Luego no se podrian hacer juegos con estas imágenes que tengo? Me lo tengo que mirar mejor o si alguien me puede guiar le estaría agradecido.

A continuación cuelgo los dos únicos archivos que tengo del proyecto. Vereis que la cosa está bastante verde, a continuación postearé los próximos pasos que seguiré y los principales fallos que tengo que corregir o que de momento no sé como solventar.

Juego: 05/12/2010

nota: Como entorno de programación utilizo Ubuntu, así que si hay alguien interesado podríamos compartir mi carpeta con UbuntuOne para mas comodidad.

Lista de los principales errores hasta el momento 22/11/2010 (AYUDA!?):

[HECHO 22/11/10]- Colisiones entre los procesos tiro() y enemigo(): Ahora estan puestas dos sentencias de "Type collision" en cada proceso y existen fallos en la ejecución, sólo colisionan algunas imagenes y la secuencia de explosioń de tiro() no queda "quieta" en cuanto chocan. Además, parece que solo colisionan en el centro de la imagen del avioń, tendrían que colisionar en todo el gráfico (entre el morro y la cola) -/- Solucionado con signal() dentro del IF(idtiro=collision (type tiro)...
[HECHO 21/11/10]- Depurar el scroll: actualmente el protagonista cuando esta quieto sigue el sroll, se tendría que quedar quieto si no se pulsa ninguna tecla y que lo "arrastre" la pantalla si toca el límite izquierdo. Lo solucioné mediante una sentencia "ctype=C_SCROLL;" en el proceso "protagonista()" pero luego no combinaba bien al disparar -/- Se tiene que poner el "ctype=C_SCROLL;" a todos los procesos.
[HECHO 23/11/10]- Depurar el scroll: los enemigos generados a la izquierda del scroll no se ven en pantalla -/- Al final he puesto un tercer parámetro a enemigo() donde le digo la dirección a seguir.

Lista de los próximos pasos a seguir:

[HECHO 21/11/10]- Hacer que los enemigos dejen caer bombas sobre el protagonista (de momento de forma aleatoria en calquier lugar).
[HECHO 21/11/10]- Que estas bombas hagan daño al protagonista (ya esta definida una TYPE con las características del proceso).
[HECHO 25/11/10]- Que el protagonista sólo pueda disparar "x" tiros a la vez. Que sólo puedan haber "x" procesos tiro() en pantalla. -/- Ahora se dispara con mas pausa entre ejecuciones. Implementado con una variable "contador".
- Diseño de armas.
- Diseño de items de mejoras.
[HECHO 01/12/10]- Encontrar una forma de "bonus" de armas, ya sea como en el Heavy Weapon con avion amigo que deje caer items, haciéndolos caer del cielo, que te lo traiga un espontáneo por el suelo,...-/- Al morir el enemigo saldra un item diferente cada x veces.
- Que las armas cambien en cuanto se recoja un bonus y establecer un daño superior/inferior para éstas.

NOTAS:

- Sonido: de momento no hay sonido. Alguna sugerencia?
- Si este post no tiene éxito lo dejaré como seguimiento personal del proyecto.

Bueno, de momento eso es todo. Si has llegado hasta el final, gracias por leer y espero que te guste lo expuesto.

Saludos!

Drumpi · November 21, 2010, 01:37:53 PM

Primero: bienvenido al foro. Espero que te lo pases bien programando, ya verás que con Bennu es realmente fácil.

Segundo: enhorabuena, eres de los pocos novatos que escoge un juego fácil de implementar para los principiantes, y creo que el primero que pasa de los típicos matamarcianos (aunque bueno, este también lo es, pero es algo más original ^^U).

Respecto a tus dudas, te solventaré algunas:
-Si vas a poner al prota dentro del scroll usando CTYPE, todos los demás procesos deberías situarlos también en él, o tendrás que hacer una conversión de coordenadas (ten en cuenta que la esquina superior izquierda de la pantalla está determinada por la posición de scroll[0].x0 y scroll[0].y0 para los procesos con ctype=c_scroll, mientras que los de pantalla lo están por la coordenada (0,0).
-No es recomendable que dos procesos que chocan entre sí detecten la misma colisión, puesto que si uno de ellos desaparece de forma inmediata (como suele ser con el disparo), el otro proceso ya no podrá chocar con él. Uno debe detectar el choque y luego avisar al otro proceso o actuar sobre él.
-Si vas a pasarlo a CAANOO, hazlo pensándolo desde el inicio. CAANOO tiene unos recursos mucho más limitados que el PC y creeme, encontrarse de pronto que hay que reescalar, separar gráficos, cambiar formatos y recortar virguerías gráficas, no es una buena sensación. Como poder se puede, pero ya depende mucho del tipo de juego. CAANOO tiene una resolución de 320x240 y se pueden usar los modos gráficos de 8 y 16 bits, no se puede usar el de 32 por algún tipo de limitación. Si estás usando FPGEdit, tiene una opción para convertir la calidad, aunque no se si puede pasar de 32 a 16 ni los resultados que se obtienen.
-Por último, si vas a compartir, debes pasar el código (el .prg) o de lo contrario no podremos decirte los fallos que veamos, el .dcb no se puede leer. Y si compartes el .dcb, debes decir qué versión de Bennu has usado, por si acaso.

Un saludo y suerte con el proyecto ;)

NesKy · November 21, 2010, 03:07:57 PM

Ya he colgado el *.prg. Te ha descargado bien el archivo? Estoy probando lo del UbuntuOne pero no se muy bien como va...

Lo que me comentas de avisar al otro proceso ya lo probé con el "signal()" y poniendo como parámetro el identificador del proceso tiro (mediante una varible global "idtiro") pero no me funciona. Le echare otro vistazo.

Y lo de la CAANOO y los 16/32 bits aun no entiendo bien la diferencia. Probaré de hacer un reescalado de toda la ventana y pasarla a 320x240, la pega es que tengo todos los *.png a 32 bits... A ver que tal va lo de la conversion a 16 que dices que hace el FPGedit.

Yawin · November 21, 2010, 03:53:09 PM

mmm, me recuerda muchísimo a mi marcianitos. Luego, por la noche te colgaré mi carpeta entera de códigos para ese juego (igual te resulta un desorden xD).

Igual, en alguno de los códigos encuentras alguna ayuda xD

NesKy · November 21, 2010, 04:29:41 PM

Parece que el FPGedit no me puede convertir los .png a 16bits. Hay 2 opciones: para convertir a 16bits para CDIV y para Fenix; sólo me funciona el primero pero las imagenes no se me ven en el juego.

SplinterGU · November 21, 2010, 06:49:39 PM

algunas cosas que veo en el hilo.

- los procesos para que colisionen correctamente deben ser todos (los que van a colisionar entre si) del mismo ctype, si no lo son, entonces no colisionaran correctamente.

- si tus procesos se mueven dentro del scroll y el scroll no es solo un decorado, entonces todos los procesos deben ser c_scroll.

- la limitacion de los 32bits en caanoo es por que el hardware no lo soporta.

- el signal no es para mandar mensajes, el signal es para matar, congelar, mandar a domir o despertar un proceso.

- no es del todo correcto decir que solo 1 haga la colision cuando chocan entre si o sobre un mismo tipo de proceso, lo unico que tenes que tener en cuenta es que si el que detecta la colision mata al proceso con el que colisiona, solo 1 de todos los procesos que chequean a ese tipo detectara la colision, porque para el siguiente proceso el proceso en cuestion habra desparecido.

NesKy · November 21, 2010, 08:15:53 PM

- Utilizaba el signal del siguiene modo dentro del proceso "enemigo()" y a su vez dentro de un LOOP-END:

Code Select

IF(collision (type tiro1))
			carac.vida-=3;
			signal(idtiro1,S_KILL);			//Envia una señal a tiro para que "muera" (¡¡¡no funciona!!!)
			IF(carac.vida<=1)
				puntos+=1;	
				BREAK;
			END
END

La variable "idtiro" la defino dentro del proceso protagonista() cuando se ejecuta. A lo mejor el fallo esta aquí.

- Ahora tengo todos los procesos en el scroll ("ctype=C_SCROLL;"), lo que pasa que al ejecutar el enemigo de forma aleatoria para que salga a izquierda o a derecha, los de la izquierda no se ven en pantalla. Puede que sea porque se queda fijo en el scroll y no avanza por el eje "x".

DjSonyk · November 21, 2010, 08:22:50 PM

Buenas, la respuesta a esa pregunta ,una vez que los procesos se les asigna ctype=C_SCROLL las variables deven ser relativas al scroll ...Porque si tu haces por ejemplo X=RAND ( 1,500), es proceso se dibujaria en esa X pero el Scroll igual se llega por el 1000 con lo que queda fuera de vista,al no ser que retrocedieras y ya verias el proceso.Algo asi:

x=rand(0,500)+scroll[0].x0;

te solucionaria el problema.

Yawin · November 21, 2010, 09:35:59 PM

Bueno, estos son los códigos de mi juego. Espero que te ayuden en algo:
http://pensarescompartir.com/lahsoft/lahsoftcorp/?direc=fenix/&id=c%F3digos.rar

SplinterGU · November 22, 2010, 01:13:33 AM

bien, mas alla de que sea la solucion o no a tu problema, estas haciendo un mal uso de colision...

collision te da el id del proceso que colisiona, por ende, vos tenes que obtener eso en una variable, y luego enviarle la señal, asi

IF(idtiro1=collision (type tiro1))
         carac.vida-=3;
         signal(idtiro1,S_KILL);         //Envia una señal a tiro para que "muera" (¡¡¡no funciona!!!)
         IF(carac.vida<=1)
            puntos+=1;
            BREAK;
         END
END

NesKy · November 22, 2010, 08:34:19 AM

Gracias a los 3 por contestar. Luego le hecho un vistazo a tu .prg yawin :).

DjSonik, si, ya he tenido en cuenta lo de que se tienen que crear los procesos en las coordenadas con referencia al scroll. Lo que pasa es que los que se crean a la izquierda digamos que no avanzan hacia la derecha. Supongo que se deben quedar quietos siguiendo el scroll. Por otro lado, los que se crean a la derecha si que se ven, pero se quedan quietos en el scroll, no avanzan.

SplinterGU, voy a probar lo que dices. Pero, en la declaración del IF no tendrias que poner un "==" en vez de "="? Si pones = es que defines la variable y podria dar problemas, creo...

Yawin · November 22, 2010, 09:12:00 AM

precisamente, lo que le estas diciendo es:

Si (el resultado de guardar en esta variable (el resultado de una colisión) tiene algún valor)

SplinterGU · November 22, 2010, 02:37:47 PM

Quote from: NesKy on November 22, 2010, 08:34:19 AM
Gracias a los 3 por contestar. Luego le hecho un vistazo a tu .prg yawin :).

DjSonik, si, ya he tenido en cuenta lo de que se tienen que crear los procesos en las coordenadas con referencia al scroll. Lo que pasa es que los que se crean a la izquierda digamos que no avanzan hacia la derecha. Supongo que se deben quedar quietos siguiendo el scroll. Por otro lado, los que se crean a la derecha si que se ven, pero se quedan quietos en el scroll, no avanzan.

SplinterGU, voy a probar lo que dices. Pero, en la declaración del IF no tendrias que poner un "==" en vez de "="? Si pones = es que defines la variable y podria dar problemas, creo...

no, lo que quiero es que se asigne el resultado de collision a la variable idtiro1, como bien dice yawin

NesKy · November 22, 2010, 09:24:28 PM

OK, las colisiones de momento solventadas. THkx de nuevo, ahora queda profesional y todo con las explosiones 8) jaja.

Ahora me meto con las jkeys.lib y probar que sólo puedan haber "x" procesos disparos en pantalla.

De cara al port para CAANOO, ahora estoy programando con una resolución 640x480x16. Después del set_mode he puesto la sentencia: "scale_resolution=m320x240;". Me harà la conversión a la resolución nativa de la CAANOO o tendré que cambiar los .png y reducirlos a la mitad? Alguna solución para que pueda utilizar 640x480 en el PC y 320x240 en la portátil?

SplinterGU · November 22, 2010, 10:06:26 PM

el scale_resolution va antes del set_mode.

el juego correra a 640x480, visualmente estara a 320x240.