[NES] [HO] Bandolero, nuevo proyecto homebrew

Responder
1, 2
Bandolero (2025)


Videojuego basado en la vida de un bandolero español del siglo XIX que, durante los sucesos de la rebelión del 2 de mayo contra la ocupación napoleónica de España, escapa de la cárcel de Casa y Corte, a fin de conservar su libertad y buscar una nueva vida mientras busca a los componentes de su antigua banda.

Durante los seis distintos niveles, deberá luchar contra los soldados franceses que asedian el reino, convirtiéndose de esta forma en un anti-héroe, que sin quererlo, acabará ayudando en la lucha por la independencia del país.

El planteamiento del videojuego es que sea un videojuego de acción con plataformas, con sprites grandes al estilo Batman: Return of the Joker (1991), programado por Sunsoft para NES.

Las fases, que como he dicho antes, serán seis, estarán compuestas en principio por tres subfases. Estas se desarrollarán en scroll direccional de derecha-izquierda, y otras con scroll arriba-abajo. Cada fase terminará con un combate con un boss.

Además, en algún momento quiero poner acción montando a caballo, pero convirtiéndolo en un juego de disparo, moviendo la mira con la cruceta.

La primera fase, todavía está en proceso, pero tengo claro que tiene que ser en una cárcel española del siglo XIX, donde controlaremos a nuestro bandolero intentando escapar y asediado por franceses.

Hasta ahora he conseguido programar el engine del scroll, y ando aún metiéndome con los distintos movimientos del bandolero. Anda de izquierda a derecha, salta, se agacha, dispara, e incluso puede atacar con una navaja. Además, he conseguido programar que en ciertos sitios pueda esconderse para evitar que los guardias franceses le detecten o simplemente esquivar disparos.

Para terminar, estoy usando el mappeador MMC3

Imagen



Actualización 29/08/2025
Ahora he añadido la función de ataque, tanto de la navaja como de la escopeta. Por ahora, pulsando SELECT alternamos entre ambas.

Imagen



Actualización 30/08/2025

Seguimos añadiendo cositas.

Ahora, si pulsamos en la cruceta del mando de control hacia arriba, nuestro player podrá esconderse tras una columna previamente establecida.

La columna (o lo que sea) está formada por metatiles con colisión propia. Si no se detecta esta colisión, aunque pulsemos en la cruceta hacia arriba, el player no haría nada.

Lo más difícil de programar esto ha sido conseguir que el sprite del player se posicione escondido siempre en la misma posición, pegada al borde del objeto. Es modificable, por tanto, podría hacer otro tipo de colisiones para esconderse donde el player pudiese posicionarse de otras maneras.

En serio, estuve a punto de abandonar la idea hasta que di con la tecla. Es este tipo de problemas de programación lo que hace que muchas veces abandone al final proyectos tras días y días sin conseguir resultados satisfactorios. Pero parece que estamos de suerte. Funciona correctamente y seguimos adelante.

Imagen



Actualización 02/09/2025

Como comenté la última vez, ahora mismo estaba inmerso en el tema de scroll arriba-abajo.

Por ahora funciona, pero el verdadero reto es implementar la física del player, y que la cámara se mueva al compás de este. Espero que no me de mucho quebradero de cabeza, por que es de esas cosas que hacen que uno acabe cansándose de proyectos como este, o descarte este tipo niveles y se centre en un scroll derecha-izquierda.

Podéis comprobar en que punto estoy con este gif (el emulador puesto a cámara rápida, ojo):

Imagen



Actualización 05/09/2025

Aún no está terminado, pero parece que ya voy obteniendo algo de luz.

Por ahora solo he implementado el scroll hacia arriba con bastantes complicaciones y con un resultado que no me deja del todo satisfecho, pero bueno: hay progreso.

Imagen



Actualización 09/09/2025

Bueno, pues vamos con una prueba en escenario real. Esta demo es más que nada para ver que tipo de gráficos soy capaz de crear, colores a elegir, etc... Una simple prueba visual para ver como podría quedar todo.

El aspecto de antigua cárcel española de principios del siglo XIX (que no eran más que viejas cárceles medievales), creo que queda bastante patente.

Los colores, obviamente, no parecen la mejor elección y quizá tenga que enredar con las opciones de énfasis de color para darle otro aspecto.

Hay unos cuantos metatiles ya creados, como podéis observar, pero faltan cosas, detalles, etc... y animaciones. Me gustaría poner cajas, barriles, antorchas que iluminan y con fuego animado, etc...

Lo de las grandes barras negras... aun estoy con la duda si aprovechar todo el alto de la pantalla y poner un mini menú a base de sprites flotantes en lo más alto, o crear un HUB propiamente dicho en la parte baja. Aun así, me gustaría aprovechar un poco más de espacio.

Lo de la ocultación en las columnas, es todo un detalle. Pero he hecho una pequeña cagada de posicionamiento en los metatiles, y voy a tener que ajustar unas cuantas cosas.

Recordad que solo es una prueba visual.

Imagen



En el origen de todo

Este es un proyecto personal, ha estado dando bandadas a lo largo de varios años. Empecé con un primer planteamiento en 2018, diseñando lo que iba a ser un videojuego de plataformas al uso, con scroll simple direccional de derecha e izquierda. Al ser un scroll simple, solo se movía entre dos pantallas, dado que todavía no sabía hacer scroll progresivo.

Os dejo dos imágenes para que os hagáis a la idea lo que iba a ser.

Imagen Imagen
Pinta bien y me encanta el nombre 😅
El personaje y sus animaciones tienen muy buena pinta.
Mucho ánimo.
@Diskover si tienes pensado vender en el mercado internacional, piensa en cambia el nombre a algo que no les resulte tan sobado (bandolero, matador, conquitador).

El diseño del personaje es genial, muy bien definido todo.

Como sugerencia, se supone que corre a zancada limpia, y esa animación se realiza en, ¿2 a 3 frames?.

No añadas "blur" en el dibujo, pero si te diría que los 2 a 3 frames de la animación de correr impliquen la pierna ya "recolocándose" para pisar. ¿Recuerdas la demo de la amazona?, también sucede con pocos pies, pero no parece que sea a trompicones por que no aparece ningún cuadro de animación donde la pierna parece que se está moviendo demasiado rápido.

Con los mismos frames de animación la diferencia es parecer fluído, o parecer "a trompicones".


¿Que te parece?.


Edit: Dale mucha caña, queremos verte vender juegos.
Actualización 29/08/2025

Ahora he añadido la función de ataque, tanto de la navaja como de la escopeta. Por ahora, pulsando SELECT alternamos entre ambas.

Imagen


Señor Ventura escribió:@Diskover si tienes pensado vender en el mercado internacional, piensa en cambia el nombre a algo que no les resulte tan sobado (bandolero, matador, conquitador).

El diseño del personaje es genial, muy bien definido todo.

Como sugerencia, se supone que corre a zancada limpia, y esa animación se realiza en, ¿2 a 3 frames?.

No añadas "blur" en el dibujo, pero si te diría que los 2 a 3 frames de la animación de correr impliquen la pierna ya "recolocándose" para pisar. ¿Recuerdas la demo de la amazona?, también sucede con pocos pies, pero no parece que sea a trompicones por que no aparece ningún cuadro de animación donde la pierna parece que se está moviendo demasiado rápido.

Con los mismos frames de animación la diferencia es parecer fluído, o parecer "a trompicones".

¿Que te parece?

Edit: Dale mucha caña, queremos verte vender juegos.


Varias cosas.

No deja de ser un videojuego de 8 bits, con sus pros y sus contras. La animación de correr se realiza en seis frames, realmente. Quizá el gif no está recogiendo todos los frames correctamente.

Sería ideal llevar a buen puerto este trabajo y poder llegar a vender. Ojalá.

El nombre "Bandolero" es como lo estoy llamando por ahora porque el protagonista es un bandolero, pero quizá acabe poniéndole otro nombre más llamativo y dejando lo de "Bandolero" como sobrenombre.

Muchas cosas que hacer. Ahora mismo me estaba dando cuenta de que las ocho distintas animaciones del player, estan realizadas en tiles de 8x8 pixeles, y quizá lo mejor hubiese sido haber empezado por tiles de 8x16 pixeles para ahorrar espacio para otros sprites. El problema es a ver como organizo luego los bancos de memoria CHR para no volverme loco ante tanta animación. Estoy usando el mapper MMC3.
@Diskover me ha encantado el gesto de mirar hacia atrás, ¿es un movimiento que controla el jugador antes de realizar una acción?, ¿mira hacia atrás antes de darse la vuelta?, o es una snimación autónoma.


Mira, esto es lo que te decía. El movimiento de correr son 8 frames, pero se supone que mueve las piernas rápido, así que no ves ningún cuadro de animación con ninguna clase de transición, con la pierna en el centro, porque entonces la animación quedaría a trompicones (miento, hay uno).

Los brazos si reciben varios cuadros de animación para el braceo (obvio), y de esta forma la animación se vuelve fluída con pocos cuadros de animación.

El secreto está en otorgarle al muñeco movimientos "nerviosos".


Imagen
Pinta muy chulo. Mucho animo!!.
Mola. [beer]

A ver si alguien se atreve con un juego de Hernan Cortés en el que haya que robarles el oro a indios disfrazados de Batman. [carcajad]
@Diskover pinta brutal, mucho ánimo y suerte con el proyecto.

Si como dices lo de Bandolero no es definitivo, si finalmente te animas a cambiarle el nombre al juego quizás no estaría de más alguna referencia/guiño al bueno de Curro Jiménez y lo que rodea al personaje o
su inspiración histórica :p
Seguimos añadiendo cositas.

Ahora, si pulsamos en la cruceta del mando de control hacia arriba, nuestro player podrá esconderse tras una columna previamente establecida.

La columna (o lo que sea) está formada por metatiles con colisión propia. Si no se detecta esta colisión, aunque pulsemos en la cruceta hacia arriba, el player no haría nada.

Lo más difícil de programar esto ha sido conseguir que el sprite del player se posicione escondido siempre en la misma posición, pegada al borde del objeto. Es modificable, por tanto, podría hacer otro tipo de colisiones para esconderse donde el player pudiese posicionarse de otras maneras.

En serio, estuve a punto de abandonar la idea hasta que di con la tecla. Es este tipo de problemas de programación lo que hace que muchas veces abandone al final proyectos tras días y días sin conseguir resultados satisfactorios. Pero parece que estamos de suerte. Funciona correctamente y seguimos adelante.

Imagen


Y ahora, vamos con las preguntas.

Señor Ventura escribió:@Diskover me ha encantado el gesto de mirar hacia atrás, ¿es un movimiento que controla el jugador antes de realizar una acción?, ¿mira hacia atrás antes de darse la vuelta?, o es una snimación autónoma.

Mira, esto es lo que te decía. El movimiento de correr son 8 frames, pero se supone que mueve las piernas rápido, así que no ves ningún cuadro de animación con ninguna clase de transición, con la pierna en el centro, porque entonces la animación quedaría a trompicones (miento, hay uno).

Los brazos si reciben varios cuadros de animación para el braceo (obvio), y de esta forma la animación se vuelve fluída con pocos cuadros de animación.

El secreto está en otorgarle al muñeco movimientos "nerviosos".

Imagen


Por orden:

- El gesto de mirar a un lado y a otro, es aleatorio, teniendo en cuenta un contador de tiempo que está siempre funcionando, y la animación del player en el momento en el que actuaba antes de quedarse en estado STOP. Este gesto funciona tanto de pies como cuando estamos agachados.

- El movimiento del player Bandolero cuando corre, está compuesto por 6 sprites y 6 frames. Voy a estudiarlo, pero a priori ya te digo que si previamente no haces el diseño teniendo en cuenta esto, luego es muy complicado aplicarlo y que quede bien.

Ayer sábado, a fin de ahorrar espacio para sprites dado que hay que contar con los enemigos, me he dedicado a pasar todos los tiles del sprite a formato 8x16. Me ha llevado todo el día, dado que hay que montar de nuevo todos los sprites de movimiento.

Ha habido problemas: Por delante me he llevado el color de los pantalones marrones. No había manera de mantenerlos a no ser que ocupase demasiado espacio en los bancos de memoria CHR. Si hacía eso, nos quedábamos con poco espacio para otros sprites (enemigos, de nuevo). Ya lo explicaré con imágenes el problema. Además, he tenido que recortar un sprite del salto, dado que antes estaba compuesto por 4 sprites y ahora son 3 sprites. Si no, no encajaba en el banco de memoria.

Os mantendré informados.
@Diskover ¿que tal responde la ocultación en paredes a media altura? (como la que aparece a la derecha en tu ultimo gif).

Imagino que no propone el mismo tipo de colisiones que las paredes en las que si se oculta, ¿eso significa que puedes añadir otras colisiones con otras reglas para que se oculte agachado automáticamente?, ¿me ha parecido entender que ya no tienes espacio para añadir mas tipos de animaciones?.

Esperemos que no desistas de este proyecto.


¿Que tienes pensado?, ¿mas plataformeo con muchos niveles de altura?, o algo mas tipo ninja warriors again.
Señor Ventura escribió:@Diskover ¿que tal responde la ocultación en paredes a media altura? (como la que aparece a la derecha en tu ultimo gif).

Imagino que no propone el mismo tipo de colisiones que las paredes en las que si se oculta, ¿eso significa que puedes añadir otras colisiones con otras reglas para que se oculte agachado automáticamente?, ¿me ha parecido entender que ya no tienes espacio para añadir mas tipos de animaciones?.

Esperemos que no desistas de este proyecto.


¿Que tienes pensado?, ¿mas plataformeo con muchos niveles de altura?, o algo mas tipo ninja warriors again.

Lo de ocultarse tras una caja del fondo lo he pensado, y quizá lo consiga hacer.

La pared se detecta aplicando la colisión hacia el lado que se camina (collision_R o collision L), más alto y bajo del player (collision_U más colission_D). Quizá si solo hago esto último omitiendo collision_U, podría decirle que se oculte pero mostrando un sprite del player agazapado.

Si tengo espacio para otras animaciones, pero lo tengo configurado para que abarque 64 tiles de los 256 tiles destinados a CHR. Gracias al MMC3, hago cambio de banco al vuelo para según qué animaciones. Resulta que como estoy trabajando ahora con 8x16, los atributos de color también se acogen a esta norma, y claro, si pinto los pantalones de marrón, la tripa del player en vez de morado, saldría marrón también.

Es un poco complejo de explicar si no se muestra visualmente, pero si muevo los tiles del player 8 píxeles hacia abajo, comenzando desde la cabeza, si podríamos volver a tener el color marrón del player, pero los 8 píxeles por encima de la cabeza, estarían vacíos, y en según que animaciones, voy muy justo con los 64 tiles como para desperdiciar espacio.
Se ve interesante, a ver si acaba terminando el título y lo veo en plataformas modernas para su compra
@Diskover Mucha suerte en tu proyecto, pinta muy bien.
@Diskover ¿que tal tonos de gris y marrón, como una fotografía antigua con tonos sepia?, así evitas esa especie de "pseudo clashing".

Imagen

Imagen



P.D: En su defecto, mantienes los gráficos a color, y que pantalones y torso tengan el mismo color como parte del mismo diseño. Volviendo al amazon's running diet, nunca le achacarías que eso sea un defecto.

Seria un crimen hacer los gráficos mas chaparros, así es como los has deseado diseñar.
Señor Ventura escribió:@Diskover ¿que tal tonos de gris y marrón, como una fotografía antigua con tonos sepia?, así evitas esa especie de "pseudo clashing".



¿Qué es el pseudo clashing?

Por otro lado ¿sugieres que haga los gráficos en blanco y negro?
Diskover escribió:¿Qué es el pseudo clashing?


Lo he entrecomillado, es la limitación de tener que compartir colores de una paleta.

Diskover escribió:Por otro lado ¿sugieres que haga los gráficos en blanco y negro?


No es lo ideal con una paleta tan justa, pero si te duele que te pase eso con los colores, no hay demasiadas opciones.

¿Invertir colores de la subpaleta del sprite inferior al sprite superior?.

¿Que tal un ropaje que, efectivamente, esté compuesto solo de dos colores?. Ropa, camisa, y pañuelo del mismo color, y los otros dos colores para los detalles y el color de la piel.


¿Va a ser mas orientado al combate?, o al plataformeo.
Señor Ventura escribió:
Diskover escribió:¿Qué es el pseudo clashing?


Lo he entrecomillado, es la limitación de tener que compartir colores de una paleta.

Diskover escribió:Por otro lado ¿sugieres que haga los gráficos en blanco y negro?


No es lo ideal con una paleta tan justa, pero si te duele que te pase eso con los colores, no hay demasiadas opciones.

¿Invertir colores de la subpaleta del sprite inferior al sprite superior?.

¿Que tal un ropaje que, efectivamente, esté compuesto solo de dos colores?. Ropa, camisa, y pañuelo del mismo color, y los otros dos colores para los detalles y el color de la piel.

¿Va a ser mas orientado al combate?, o al plataformeo.


No es un problema de paleta de colores, sino de la propia estructura de los tiles 8x16 píxeles. Los tiles no guardan información de color. El color va por una capa por encima, y si estructuras a 8x16, el color se va a comportar igual.

Hay que tener muy claro desde el principio como quieres diseñar los sprites, y como hagas cambios de 8x8 a 8x16, muy probablemente acabes cagándola, como me ha pasado a mí.

Al final he tenido que volver a rehacer sprites, y bueno, parece que he conseguido recuperar el color marrón de los pantalones, pero dejando algunos tiles vacíos a la contra. Me ha llevado un tiempo reestructurar los CHRs.

Antes, cuando estaba a tiles de 8x8 píxeles, tenía esto: 17 sprites formando el player, consumidos de los 64 disponibles. Parece que todavía queda espacio, pero a nada que empieces a poner enemigos y otras cosas, te acabas quedando sin espacio rápido.

Imagen


Así que opté por la configuración de tiles 8x16, obteniendo esto otro: 12 sprites formando el player, ahorrando espacio, que luego a la larga se va a notar. Nótese que ahora hay tile vacío por encima de la cabeza del player. Tuve que reestructurarlo para que el color respetase el marrón del pantalón, tanto estando quieto como en otras animaciones. Si no, el pantalón compartiría color con la capa y los brazos. En ese caso, cogería el color carne de los brazos, perdiendo el marrón.

Imagen





Espero que se entienda ahora mejor el problema que he tenido.
A los que preguntáis si será plataformeo o acción:

El planteamiento del videojuego es que sea un videojuego de acción con plataformas, con sprites grandes al estilo Batman: Return of the Joker (1991), programado por Sunsoft para NES.

Las fases, que como he dicho antes, serán seis, estarán compuestas en principio por tres subfases. Estas se desarrollarán en scroll direccional de derecha-izquierda, y otras con scroll arriba-abajo. Cada fase terminará con un combate con un boss.

Además, en algún momento quiero poner acción montando a caballo, pero convirtiéndolo en un juego de disparo, moviendo la mira con la cruceta.


Tomalo con calma @Diskover lo de que no salgan cosas y mandes todo al carajo es muy común. Yo he formateado mi servidor casero porque ayer dejaron de funcionar cosas y tras horas no arreglé, restauré la imagen de seguridad del 13 de agosto y tampoco fue y mandé todo tomar por culo. Seguramente vuelva en el futuro, pero vamos que me pasó lo que dices tú. [+risas]
@SuperPadLand lo había pasado por alto... así que mitad batan return of the joker (acción lateral), mitad wild guns (shooting gallery).

@Diskover si, que parte del pantalón estaba dibujado en el sprite del torso, a eso me refería con lo de "pseudo clashing".

¿Cual va a ser tu siguiente paso?, ¿tienes pensado como van a ser los escenarios?, ¿algún detalle de diseño/estilo gráfico que puedas ir adelantando?.
Veo que estás gastando 3 paletas de sprites para el personaje principal (seguramente compartirás algunas con los enemigos). No se si te saldría a cuenta gastar una menos (por ejemplo, hacer que la camiseta sea de color negro con detalles en gris, o a la inversa, para así aprovechar la del brazo) para que los enemigos puedan tener más opciones de color (seguramente serán soldados franceses con uniformes de color vivo, ya que es un juego sobre bandoleros).

Lo que también haría es intentar eliminar los sprites de alrededor de la cabeza. Están casi vacíos y te van a ocupar dos espacios en el banco de gráficos. Yo pondría el nudo del pañuelo en el mismo sprite de la cabeza y desplazaría ligeramente este con respecto a los demás para que quede esta en la misma posición. El que muestra el cañón del fusil lo eliminaría directamente, es un detalle que casi nadie se va a dar cuenta y su gasto tanto en espacio, cómo sprites, cómo cálculo de posiciones de este no creo que los valga.

Genial trabajo por eso.
Está quedando muy bien. Lo seguiré de cerca.
Señor Ventura escribió:¿Cual va a ser tu siguiente paso?, ¿tienes pensado como van a ser los escenarios?, ¿algún detalle de diseño/estilo gráfico que puedas ir adelantando?.

Bueno, ahora mismo estoy tratando de hacer el scroll arriba-abajo. Se me esta complicando y me imagino que me lleve días, como siempre.

El estilo gráfico, trataré que sea (dentro de las limitaciones de la NES) lo más realista posible. Será complicado, pero seguro que algo se puede hacer.

El creador de la herramienta NEXXT, que sirve para hacer gráficos para NES, FrankenGFX, tiene un gusto formidable a la hora de crear gráficos pixelart con estas limitaciones, y sus trabajos son sorprendentes. Ojalá pueda llegar a hacer para este juego, cosas como las que él hace.

Imagen
Imagen


MasterDan escribió:Veo que estás gastando 3 paletas de sprites para el personaje principal (seguramente compartirás algunas con los enemigos). No se si te saldría a cuenta gastar una menos (por ejemplo, hacer que la camiseta sea de color negro con detalles en gris, o a la inversa, para así aprovechar la del brazo) para que los enemigos puedan tener más opciones de color (seguramente serán soldados franceses con uniformes de color vivo, ya que es un juego sobre bandoleros).


Lo tengo en cuenta. Me tendré que amoldar con lo que vaya haciendo.

No obstante, las paletas, por lo general, se comparten entre todos los sprites.
@Diskover esa primera imagen... antes de leer creia que ya tenías eso hecho...

No estaría mal ambientado en invierno, quedaria limitado al maximo número de colores posibles de tonalidades frias... vaho en la boca de diferentes formas aleatorias, que le da dramatismo... y posibilidad de contrastes muy fuertes con tonos cálidos de hogueras (en los momentos en que simplificas el escenario para meter esas tonalidades para rojos y naranjas).

Lo bueno de las atmósferas extremas es que no tienes que compartir variedad cromática con todos los rangos de color de una atmósfera "normal". Jugar con los extremos de un escenario, en este caso nevado, te permite usar todos los azules, turquesas, violetas/morados, porque dejas a un lado los rojos, amarillos, naranjas, verdes, y todos los demas, y eso te permite mas oportunidad de degradados.

O una lluvia tan intensa que te permite hacer el escenario con muy pocos colores, y centrarte en animar el fondo deformado por la refracción... no se, oportunidades hay muchas...

Un paisaje veraniego con bosque y mar, mas otros detalles todos juntos, ya te obligaría a simplificar con extensos colores planos (a menos que lo segmentaras y no apareciese todo a la vez en pantalla, pero ya me entiendes).


Edit: yo hablo sin parar, si eso te inspira algo, mejor. No quiero que pienses que son sugerencias, o algo así.
Como comenté la última vez, ahora mismo estaba inmerso en el tema de scroll arriba-abajo.

Por ahora funciona, pero el verdadero reto es implementar la física del player, y que la cámara se mueva al compás de este. Espero que no me de mucho quebradero de cabeza, por que es de esas cosas que hacen que uno acabe cansándose de proyectos como este, o descarte este tipo niveles y se centre en un scroll derecha-izquierda.

Podéis comprobar en que punto estoy con este gif (el emulador puesto a cámara rápida, ojo):

Imagen



Señor Ventura escribió:@Diskover esa primera imagen... antes de leer creia que ya tenías eso hecho...

No estaría mal ambientado en invierno, quedaria limitado al maximo número de colores posibles de tonalidades frias... vaho en la boca de diferentes formas aleatorias, que le da dramatismo... y posibilidad de contrastes muy fuertes con tonos cálidos de hogueras (en los momentos en que simplificas el escenario para meter esas tonalidades para rojos y naranjas).

Lo bueno de las atmósferas extremas es que no tienes que compartir variedad cromática con todos los rangos de color de una atmósfera "normal". Jugar con los extremos de un escenario, en este caso nevado, te permite usar todos los azules, turquesas, violetas/morados, porque dejas a un lado los rojos, amarillos, naranjas, verdes, y todos los demas, y eso te permite mas oportunidad de degradados.

O una lluvia tan intensa que te permite hacer el escenario con muy pocos colores, y centrarte en animar el fondo deformado por la refracción... no se, oportunidades hay muchas...

Un paisaje veraniego con bosque y mar, mas otros detalles todos juntos, ya te obligaría a simplificar con extensos colores planos (a menos que lo segmentaras y no apareciese todo a la vez en pantalla, pero ya me entiendes).

Edit: yo hablo sin parar, si eso te inspira algo, mejor. No quiero que pienses que son sugerencias, o algo así.


Todo se estudiará, pero bueno, como he comentado más arriba: ojalá, los escenarios llegaran a ese nivel.
¡Muy buena pinta @Diskover!! ¡Ánimos con el proyecto!
Como molan esos escenarios es increíble la capacidad que tiene alguna gente.
Pintaza.
Guapisimo el personaje y la pinta que tiene el juego. Si lo terminas sera el personaje de nes mas realista que tiene la consola.
Por un poco las mecanicas parece un metal gear
@Diskover Una pregunta por curiosidad ¿Estas usando ensamblador del 6502 o lo estás programando en C? En caso de que sea esto último ¿Que tal va de rendimiento el lenguaje? En sus tiempos era impensable, pero he leído por ahí que los compiladores actuales de este son muy buenos.
MasterDan escribió:@Diskover Una pregunta por curiosidad ¿Estas usando ensamblador del 6502 o lo estás programando en C? En caso de que sea esto último ¿Que tal va de rendimiento el lenguaje? En sus tiempos era impensable, pero he leído por ahí que los compiladores actuales de este son muy buenos.


Estoy programando en C, y compilando en CC65, que viene siendo uno de los estándares actuales del homebrew.

En su época, si no se programaba en lenguaje C para NES, era porque aún no era un lenguaje estandarizado (aunque salió en 1972, no tenía normativa ISO hasta 1989), y sobre todo, porque no existía ni compilador.

Gracias al compilador CC65, que tiene compatibilidad con NES desde 2009, más o menos, es relativamente sencillo programar cualquier cosa para esta consola. Si a esto le sumas la ayuda de librerías como NESlib y NESdoug, ya tienes funciones básicas que te ayudan bastante a lidiar con cualquier cosa del hardware de la NES.

¿Su rendimiento? Bastante bueno. No va a alcanzar nunca el rendimiento que puedes hacer en ensamblador, pero tampoco te creas que se queda mucho más atrás.

Muy pocos programan en ensamblador 6502 para NES, pero los hay. Yo no lo hago porque entre que aprendo y aplico, me llevaría tantísimo tiempo que acabaría pasando del tema.

Existen otras alternativas, como NESmaker, etc... que te lo dan casi todo masticado; pero no tiene gracia y tampoco me he metido mucho en el tema porque siento como que no es del todo mío lo que hago.

Karaculo escribió:Guapisimo el personaje y la pinta que tiene el juego. Si lo terminas sera el personaje de nes mas realista que tiene la consola.


Bueno, tampoco creo que sea eso.

Ya en su época había juegos en NES que sorprendían. Y ojo, que los gráficos que he puesto no son del juego, si no trabjos pixelart para NES realizados por FrankenGFX
Vaya pinta más chula. Ánimo con el proyecto.
Diskover escribió:Existen otras alternativas, como NESmaker, etc... que te lo dan casi todo masticado; pero no tiene gracia y tampoco me he metido mucho en el tema porque siento como que no es del todo mío lo que hago.


Y que tendrá su licencia y sus condiciones si pretendes publicar, además que seguramente estarás obligado a mencionar el motor al iniciar el juego, lo cual te señala un poco como programador...
@Diskover
Yo voto por que lo llames Curro Jimenez
Imagen
o el templanillo
Imagen
https://citaconlahistoriajm.blogspot.co ... a-del.html
@Karaculo
Ya había un juego de Curro Jimenez para 8 bits, jejeje

Imagen


Diskover escribió:
En su época, si no se programaba en lenguaje C para NES, era porque aún no era un lenguaje estandarizado (aunque salió en 1972, no tenía normativa ISO hasta 1989), y sobre todo, porque no existía ni compilador.


Haberlo, lo había, habñia compiladores de C en el Apple II con el 6502, y luego más tarde los sistemas PDS tenían compiladores de C cruzado que podían compilar para 6502. Algún juego de C64 está hecho en C, de Nes no me suena ninguno, pero no sería descabellado que hubiera más de uno.
Aún no está terminado, pero parece que ya voy obteniendo algo de luz.

Por ahora solo he implementado el scroll hacia arriba con bastantes complicaciones y con un resultado que no me deja del todo satisfecho, pero bueno: hay progreso.

Imagen


Señor Ventura escribió:Y que tendrá su licencia y sus condiciones si pretendes publicar, además que seguramente estarás obligado a mencionar el motor al iniciar el juego, lo cual te señala un poco como programador...

De hecho, NESmaker automáticamente te añade en el inicio de la rom que compilas, una pantalla informativa señalando que ese software se ha realizado con esa herramienta.

Por otro lado, @Karaculo, @kusfo79, es obvio que mucha documentación que obtengo, aparte de libros históricos, tiene apoyo en la serie de Curro Jiménez.
Diskover escribió:De hecho, NESmaker automáticamente te añade en el inicio de la rom que compilas, una pantalla informativa señalando que ese software se ha realizado con esa herramienta.


En ese sentido, si eres brillante como diseñador, y has creado algo que sienta precedentes jugablemente, se diferencia bien y no resulta un estigma.
Bueno, pues vamos con una prueba en escenario real. Esta demo es más que nada para ver que tipo de gráficos soy capaz de crear, colores a elegir, etc... Una simple prueba visual para ver como podría quedar todo.

El aspecto de antigua cárcel española de principios del siglo XIX (que no eran más que viejas cárceles medievales), creo que queda bastante patente.

Los colores, obviamente, no parecen la mejor elección y quizá tenga que enredar con las opciones de énfasis de color para darle otro aspecto.

Hay unos cuantos metatiles ya creados, como podéis observar, pero faltan cosas, detalles, etc... y animaciones. Me gustaría poner cajas, barriles, antorchas que iluminan y con fuego animado, etc...

Lo de las grandes barras negras... aun estoy con la duda si aprovechar todo el alto de la pantalla y poner un mini menú a base de sprites flotantes en lo más alto, o crear un HUB propiamente dicho en la parte baja. Aun así, me gustaría aprovechar un poco más de espacio.

Lo de la ocultación en las columnas, es todo un detalle. Pero he hecho una pequeña cagada de posicionamiento en los metatiles, y voy a tener que ajustar unas cuantas cosas.

Recordad que solo es una prueba visual.

Imagen



Señor Ventura escribió:En ese sentido, si eres brillante como diseñador, y has creado algo que sienta precedentes jugablemente, se diferencia bien y no resulta un estigma.

No me refiero a que sea un estigma, si no ha que buena parte del juego que creas con NESmaker, parte de conceptos ya establecidos y no se hasta qué punto modificables, y me da la sensación como que quedas más que nada como mero diseñador limitado.
Muy buena tronco. [tadoramo]
Prosigo con Bandolero.

Ahora surge un dilema: Animación de luces para este fondo ¿SI o NO?

Imagen
Tiene buena pinta, te puedes inspirar en edificios de Alcalá de Henares o Cáceres para los escenarios
@Diskover Me gustá más sin.

Muy chulo cuando el personaje se esconde en la columna y queda en las sombras.
Diskover escribió:Ahora surge un dilema: Animación de luces para este fondo ¿SI o NO?

Yo la dejaría unicamente cerca de los candiles. De todas todas, enhorabuena que tiene muy buena pinta el proyecto [beer]
Diskover escribió:Prosigo con Bandolero.

Ahora surge un dilema: Animación de luces para este fondo ¿SI o NO?

Imagen


Lo que falla es que como luz difusa hay demasiada interacción con el entorno ahí, y de ser lo suficientemente luminoso como para que suceda toda esa amplitud, lo que detectas es que no está generando sombras. Por último, otra cosa que tu cerebro también detecta es que la luz es uniforme y perfectamente repetitiva todo el tiempo, cuando el comportamiento del fuego, y su iluminación, es cuasi cuántico xD... ¿que tal una animación que reproduce el frame iluminado aleatoriamente en lugar de secuencialmente?.

Sobre el escenario, a mi lo que me chirría es que tras las columnas hay una pared, ¿que tal una galería con varios pasillos paralelos de arcos, y mas al fondo, ya si, una pared?. Eso te permitiría que la luz fuese mas localizada en la propia columna (porque es mas coherente con los espacios muy abiertos), la animación de la iluminación podría ser mas compleja, y el propio escenario daría impresiones de no ser tan claustrofóbico.


¿Estarías dispuesto a emplear la mitificación de la historia española en lugar del rigor?.


Imagen
Señor Ventura escribió:
Diskover escribió:Prosigo con Bandolero.

Ahora surge un dilema: Animación de luces para este fondo ¿SI o NO?

Imagen


Lo que falla es que como luz difusa hay demasiada interacción con el entorno ahí, y de ser lo suficientemente luminoso como para que suceda toda esa amplitud, lo que detectas es que no está generando sombras. Por último, otra cosa que tu cerebro también detecta es que la luz es uniforme y perfectamente repetitiva todo el tiempo, cuando el comportamiento del fuego, y su iluminación, es cuasi cuántico xD... ¿que tal una animación que reproduce el frame iluminado aleatoriamente en lugar de secuencialmente?.

Sobre el escenario, a mi lo que me chirría es que tras las columnas hay una pared, ¿que tal una galería con varios pasillos paralelos de arcos, y mas al fondo, ya si, una pared?. Eso te permitiría que la luz fuese mas localizada en la propia columna (porque es mas coherente con los espacios muy abiertos), la animación de la iluminación podría ser mas compleja, y el propio escenario daría impresiones de no ser tan claustrofóbico.


¿Estarías dispuesto a emplear la mitificación de la historia española en lugar del rigor?.


Imagen


Al final lo voy a dejar así:

Imagen


Lo de poner más detalles al fondo, lo estudiaré.

Ojo, ya he puesto una galería contigua si te fijas en el anterior gif
Diskover escribió:Ojo, ya he puesto una galería contigua si te fijas en el anterior gif


Exacto, exacto, que el cerebro del jugador trabaje en segundo plano sin darse cuenta. Si tiene que ser con bucles, que sea con bucles, pero que el orden de su diseño no sea previsible.

Cuando ya lo tengas todo bastante pulido mira a ver si puedes echarle un vistazo a esas animaciones. Sigo pensando que da unas zancadas demasiado largas para lo mucho que se aprecia la pierna en transición hacia el avance.

Date cuenta de como el diet amazon las piernas solo tienen dos frames diferentes, toda la animación es braceo porque se supone que mueve las piernas muy deprisa, y queda muy orgánico.


edit: ¡¡Vamos!!.
Curro Jimenez, el azote uruguayo con el Fn Fal automático mas rapido de Warzone, el terror de todo bandeirante que ose pisar los mapas deathmatch de Call of Duty Modern Warfare,
@Diskover El primer efecto de las luces lo veo muy exagerado, y el segundo no me acaba de convencer personalmente. Yo apostaría a algo más similar al primer efecto pero reduciendo el alcance al trozo de columna de alrededor de la luz.
@Diskover Y si el protagonista pasa por detrás de las columnas ? desconozco si técnicamente seria factible. pero daria una profundidad a la escena muy interesante.
Diskover escribió:
Señor Ventura escribió:
Diskover escribió:Prosigo con Bandolero.

Ahora surge un dilema: Animación de luces para este fondo ¿SI o NO?

Imagen


Lo que falla es que como luz difusa hay demasiada interacción con el entorno ahí, y de ser lo suficientemente luminoso como para que suceda toda esa amplitud, lo que detectas es que no está generando sombras. Por último, otra cosa que tu cerebro también detecta es que la luz es uniforme y perfectamente repetitiva todo el tiempo, cuando el comportamiento del fuego, y su iluminación, es cuasi cuántico xD... ¿que tal una animación que reproduce el frame iluminado aleatoriamente en lugar de secuencialmente?.

Sobre el escenario, a mi lo que me chirría es que tras las columnas hay una pared, ¿que tal una galería con varios pasillos paralelos de arcos, y mas al fondo, ya si, una pared?. Eso te permitiría que la luz fuese mas localizada en la propia columna (porque es mas coherente con los espacios muy abiertos), la animación de la iluminación podría ser mas compleja, y el propio escenario daría impresiones de no ser tan claustrofóbico.


¿Estarías dispuesto a emplear la mitificación de la historia española en lugar del rigor?.


Imagen


Al final lo voy a dejar así:

Imagen


Lo de poner más detalles al fondo, lo estudiaré.

Ojo, ya he puesto una galería contigua si te fijas en el anterior gif


A mi me gusta más tu elección, la otra no parece que simule bien una iluminación de esos focos.
58 respuestas
Responder
1, 2
Volver a Consolas clásicas