Creación de juegos para 2024 Reset64 4KB CRAPTASTIC Game Competition

[josepzin]

Tablas precalculada, por supuesto. En mi caso, una única tabla de 16 enteros de 16 bits para la función trigonométrica seno basta. Siempre lo he hecho así.

Supongo que es la forma mas óptima.

¿Nadie ha utilizado nunca coma fija de 16 bits? ¿Cómo hacéis entonces desplazamientos fraccionarios (no enteros)? Bueno, también he visto utilizar coma fija sobre 24 bits en micros de 8 bits, por aquello de utilizar 16.8 y evitar los bitshifts que son algo pesados en estos micros, pero eso en C no sabría hacerlo.

Yo en el tema desarrollo para C64 soy un metido, conozco del tema pero de forma bastante superficial y me falta meterme a hacer algo de verdad.
Por aquí pueden estar @Laddh @Dozznar @Zub @riq @Jeff @Iapetus  (siempre serás woodmaster) y algunos más que seguramente algo más saben.

[Laddh]

Aún así, me ha sorprendido muy gratamente el compilador Oscar64 y en mi opinión es totalmente recomendable. No sé por qué no se usa mucho más y desplaza al ensamblador.

Sacrílego! ..., pero en realidad tú mismo te contestas mas abajo..

#2 Space Shooter con título aún por decidir
Para el test he activado el multiplexor de sprites, pero eso me ha dejado prácticamente al límite de los 4 kbytes (y faltan muchas cosas aún )

El codigo objeto que te generan estos compiladores siempre es más grande que si lo programas directo en ensamblador y así no gastas ni un byte de más, necesario si te metes en un proyecto de 4K, además, utilizando funciones ya creadas no aprendes realmente como funciona. Estos compiladores están bien para iniciarse porque a bote pronto consigues cosas, pero si quieres saber como funciona la máquina por dentro hay que llegar al ensamblador.

¿Nadie ha utilizado nunca coma fija de 16 bits? ¿Cómo hacéis entonces desplazamientos fraccionarios (no enteros)?

Ni idea, supongo que son expresiones del lenguaje C y no se a que se refieren.

Con esto solo expreso mi opinión y no voy en contra de nada ni de nadie, cualquier creación para el C64 tiene mi voto a favor, por supuesto. (menos seuck y similares)

[SkyBerron]

Respecto a la utilización de coma fija en la programación de juegos para C64, he encontrado un ejemplo muy interesante en el código fuente de una eminencia en la programación de juegos en ensamblador para Commodore 64. Se trata de Shallan y el código fuente creo que pertenece a su juego Pik'n'Mix:

https://github.com/smnjameson/LetsMakeAC64Game/blob/master/src/player/player.asm

Aquí se declara la coordenada X del jugador como 3 bytes, con 2 bytes para la parte entera y 1 byte para la parte fraccionaria, lo que equivale a coma fija formato 16.8:

Código: [Seleccionar]

Player1_X:
// Fractional / LSB / MSB   
.byte $00, $88, $00 // 1/256th pixel accuracy

Sin embargo, para la coordenada Y, utiliza sólo un entero de un byte:

Código: [Seleccionar]

Player1_Y:
.byte $c0 // 1 pixel accuracy

Aquí se declara el desplazamiento a aplicar cuando el personaje se mueve a derecha o izquierda con formato coma fija 8.8:

Código: [Seleccionar]

Player1_WalkSpeed:
.byte $80, $01

Y así es como se aplica el desplazamiento hacia la izquierda:

Código: [Seleccionar]

sec
lda Player1_X
sbc Player1_WalkSpeed
sta Player1_X
lda Player1_X + 1
sbc Player1_WalkSpeed + 1
sta Player1_X + 1
lda Player1_X + 2
sbc #$00
sta Player1_X + 2

Y el desplazamiento a la derecha:

Código: [Seleccionar]

clc
lda Player1_X
adc Player1_WalkSpeed
sta Player1_X
lda Player1_X + 1
adc Player1_WalkSpeed + 1
sta Player1_X + 1
lda Player1_X + 2
adc #$00
sta Player1_X + 2

El mismo fichero también tiene el código para comprobar colisiones, límites de pantalla, actualizar sprite, etc.

Desgraciadamente, en lenguaje C esto no creo que sea posible de hacer fácilmente ya que no hay soporte para números en 24 bits, así que por ahora seguiré utilizando coma fija sobre entero de 16 bits.

[SkyBerron]

Sacrílego!

Jajaja, ¡gracias!

El codigo objeto que te generan estos compiladores siempre es más grande que si lo programas directo en ensamblador y así no gastas ni un byte de más, necesario si te metes en un proyecto de 4K, además, utilizando funciones ya creadas no aprendes realmente como funciona. Estos compiladores están bien para iniciarse porque a bote pronto consigues cosas, pero si quieres saber como funciona la máquina por dentro hay que llegar al ensamblador.

Totalmente de acuerdo. El desafío que me he marcado es participar en el concurso con juegos programados en C que cumplan con el requisito de tamaño. Si para eso tengo que adaptar y retorcer mi código en C para que sea más eficiente y quepa en 4k, lo haré. Incluso no renuncio a mezclar un poco de código asm en mi código C para supervitaminarlo. Lo de aprender cómo funcionan las cajas negras no es mi prioridad, lo dejo para otra ocasión.

Con esto solo expreso mi opinión y no voy en contra de nada ni de nadie, cualquier creación para el C64 tiene mi voto a favor, por supuesto. (menos seuck y similares)

No faltaba más. Veo que tú también programas juegos para la máquina. ¿Te animas a participar en el concurso?

[josepzin]

Venga Laddh, participa!

[Laddh]

No faltaba más. Veo que tú también programas juegos para la máquina. ¿Te animas a participar en el concurso?

Uuff! no vería como..., lo mío con el código ya es droga dura, cuanto más se, mas cosas quiero hacer y se me quedan cortos los 40 y pico kb de ram libres, intentar meterlo solo en 4 k ya me parece un ejercicio de masoquismo puro  , luego eso sí, flipo con las joyas que consiguen.

[SkyBerron]

Uuff! no vería como..., lo mío con el código ya es droga dura, cuanto más se, mas cosas quiero hacer y se me quedan cortos los 40 y pico kb de ram libres, intentar meterlo solo en 4 k ya me parece un ejercicio de masoquismo puro  , luego eso sí, flipo con las joyas que consiguen.

Con estas restricciones, acertar con el diseño conceptual del juego es fundamental. No sirve cualquier idea, hay que pensar en las mecánicas, cuántas entidades con comportamiento diferente hay, cuántos datos precalculados se van a necesitar, cuántos sprites diferentes y caracteres definidos se van a incluir. Para mí, es difícil calibrar ahora que tengo poca experiencia con la máquina y el compilador, pero andando se hace camino. Y no es masoquismo, te aseguro que se disfruta mucho con el desarrollo y la satisfacción que da obtener un resultado jugable con tanta restricción.

Y una pregunta para los muy cafeteros: Hacerlo en lenguaje C debería ser más difícil porque se consumen más bytes por la ineficiente generación de código del compilador. ¿O no? Esa es la cuestión.

[josepzin]

Con estas restricciones, acertar con el diseño conceptual del juego es fundamental. No sirve cualquier idea, hay que pensar en las mecánicas, cuántas entidades con comportamiento diferente hay, cuántos datos precalculados se van a necesitar, cuántos sprites diferentes y caracteres definidos se van a incluir. Para mí, es difícil calibrar ahora que tengo poca experiencia con la máquina y el compilador, pero andando se hace camino. Y no es masoquismo, te aseguro que se disfruta mucho con el desarrollo y la satisfacción que da obtener un resultado jugable con tanta restricción.

Es un desafío dentro del desafío de crear con las restricciones del 64, un doble desafío y que permite hacer algo sin buscar que sea una genialidad.
Ya me estás picando... a ver si el año que viene o la próxima edición.-

Y una pregunta para los muy cafeteros: Hacerlo en lenguaje C debería ser más difícil porque se consumen más bytes por la ineficiente generación de código del compilador. ¿O no? Esa es la cuestión.

Ganas por un lado y pierdes por otro... me parece que en C hay que saber usar el lenguaje para no inflar el código. Pero al final, en ambos casos hay que saber optimizar porque hacerlo en ensamblador tampoco es garantía que quede mas pequeño si no se tiene un buen manejo.

[SkyBerron]

#2 Craptastic Space Wars

He llevado este desarrollo hasta un punto en el que la lógica del juego está prácticamente completa. Las mejoras respecto al test anterior son:

- Se ha prescindido del multiplexor de sprites. No era realista mantenerlo y poder cumplir con el límite de 4 kbytes. Al desactivarlo se ahorra casi 1 kbyte, espacio que es imprescindible para implementar las funciones básicas. Por tanto, el número de enemigos en pantalla se limita a 7.
- Se ha dado soporte a múltiples trayectorias de enemigos y se pueden incluir en la misma oleada varias trayectorias con un número variable de enemigos siempre que el total de enemigos no sume más de 7.
- Hay un número de trayectorias preconfiguradas y una secuencia prefijada de oleadas.
- El ataque de los enemigos consiste en que cada cierto tiempo uno de ellos, elegido de modo aleatorio, se sale de la formación y se dirige a doble velocidad en línea recta hacia la nave del jugador. Sólo hay 16 ángulos posibles de movimiento de los enemigos, así que la mayoría de las veces el ataque no acierta con una trayectoria de colisión correcta. Podría añadir soporte para una trayectoria curva, pero necesitaría disponer de más espacio para código.
- Se disponen de 5 vidas, cada contacto con un enemigo resta una vida. Tras perder una vida, hay un pequeño tiempo de inmunidad para poder reaccionar y llegar a un punto seguro.
- Los enemigos tienen más de un punto de vida. Cuando un enemigo pierde todos los puntos de vida se destruye con una animación de explosión de partículas. Para no tener que incluir los datos de animación de los sprites, esta animación se genera con un sistema de partículas implementado en el código que escribe directamente sobre los sprites.
- Aunque actualmente el juego se encuentra bajo el límite de 4096 bytes, no hay más espacio para ampliar el catálogo de oleadas y poder añadir efectos de sonido. He observado que la codificación de trayectorias y oleadas actual no facilita a Exomizer alcanzar un buen ratio de compresión, por lo que más adelante probaré otros esquemas.

https://www.youtube.com/watch?v=uu6sxOqEId8

Reconozco que llevar el desarrollo a este punto me ha costado más trabajo del que esperaba y ya estaba empezando a impacientarme. En parte, esto ha sido debido a que he tenido que desarrollar herramientas adicionales para visualizar y codificar las trayectorias y la secuencia de oleadas, pero espero que este trabajo me sirva también para otros juegos.

En este punto ya puedo pasar página y empezar con el desarrollo de otro juego. Tengo muchas ideas en la cabeza de juegos sencillos que podrían funcionar y encajar en menos de 4 kbytes.

[SkyBerron]

Esta semana he estado desarrollando dos juegos más en paralelo y pronto añadiré otro más a la lista de desarrollos:

#3 Juego de recorrer un laberinto, ya le buscaré un nombre exótico cuando tenga claro de qué va a ir el juego

Ahora mismo, tengo funcionando la generación procedural aleatoria de un laberinto bastante sencillo y la lógica de movimiento por el mismo muy similar a la de un comecocos. Falta por añadir sprites presentables, enemigos, recarga de energía, movimiento de ataque tipo dash, concretar el objetivo del juego (eliminar enemigos, recargar energía, llegar al punto de salida), y diseñar el aumento progresivo de dificultad.

Espero que con los 700 bytes que ahora mismo tengo de margen hasta el límite de 4096 sea suficiente para todo lo que tengo pensado añadir 







https://www.youtube.com/watch?v=UVVmJ-4UAdM

#4 Stairs Action

Juego inspirado en Elevator Action, pero sin ascensores, sólo escaleras, que aquí no tenemos presupuesto para tanta modernidad. Básicamente, hay que liarse a tiro limpio contra todos los enemigos que salen por las puertas. Ahora mismo no hay objetivo, ni un ajuste fino de la dificultad, ni un ajuste de la posición de escaleras y puertas, ni nada. Pero con lo que ya tiene es un auténtico caos de disparos y enemigos moviéndose por las tres plantas, así que vamos bien.







https://www.youtube.com/watch?v=BhUSLrC30Qw

En casi todos los desarrollos me estoy acercando peligrosamente al límite de los 4096 bytes y todavía he de añadir sonidos y mejorar mucho la presentación. Espero que tirando de algunos trucos pueda exprimir un poco más el tamaño de ejecutable y sacar algunos bytes más.

Una cosa importante que he aprendido es qué es lo que hay que darle de comer a Exomizer para que se porte como un campeón y me dé una buena compresión del binario 

Eso es todo por ahora.

[josepzin]

IMpresionante... parece que hubieras puesto en marcha una churrera.

Toda mi admiración al ver tus avances, las cosas que vas implementando y tus explicaciones.

En el juego de naves me gusta el efectito de explosión con partículas, si pudieras, creo que quedaría bien que cuando reciba un impacto el sprite se mueve un pixel hacia arriba y vuelva a su posición anterior. Pero en un juego de naves se pueden poner muchos detalles asi, con las limitación de 4kb cada cosa suma.

[SkyBerron]

IMpresionante... parece que hubieras puesto en marcha una churrera.

¡Gracias! En construir minijuegos tengo algo de experiencia. Lo que no tengo es experiencia con la máquina, pero me ha sorprendido lo fácil que es gestionar los 8 sprites, poner un fondo de pantalla hecho con caracteres y darle algo de animación. Salvo que me embarque en efectos gráficos mucho más complejos, veo fácil hacer todo lo que quiero hacer.

Toda mi admiración al ver tus avances, las cosas que vas implementando y tus explicaciones.

Escribir mis avances en algún sitio y observar la evolución me anima a seguir. Además, tengo mala memoria, por lo que me viene bien repasar los apuntes antes de retomar un proyecto aparcado temporalmente.

En el juego de naves me gusta el efectito de explosión con partículas, si pudieras, creo que quedaría bien que cuando reciba un impacto el sprite se mueve un pixel hacia arriba y vuelva a su posición anterior. Pero en un juego de naves se pueden poner muchos detalles asi, con las limitación de 4kb cada cosa suma.

Tienes razón, si hay un impacto sobre el enemigo tiene que notarse bien. El cambio temporal de color no es suficiente y no tengo espacio para un sprite distinto. Lo que comentas es factible sin que haya que alterar el código de seguimiento de trayectorias, bastaría superponer un desplazamiento vertical tipo ping-pong (ida y vuelta) con varios píxeles de amplitud. También tengo pendiente añadir color a las partículas, se ven muy sosas y así cada explosión tenga un poco del color del enemigo. En este desarrollo voy muy justo de espacio, así que veré cuánto espacio gano cuando cambie la codificación de trayectorias para que Exomizer las digiera mejor y cuando defina unas oleadas más vistosas.

[PacoBlog64]

Muy chulos los 2 minijuegos nuevos, tienen muchas posibilidades, a ver en qué quedan al final 

[SkyBerron]

Muy chulos los 2 minijuegos nuevos, tienen muchas posibilidades, a ver en qué quedan al final 

Gracias. Sé que ahora mismo se ven un poco burdos y mal acabados. Pero trataré de pulir los detalles esta semana, no vaya a ser que con el ansia de empezar juegos nuevos, los deje inacabados.

[Bieno]

Ohhhh. Me parece genial !
Puedes presentar mas de 1 juego?