[HO] A que huelen las nubes, desvarios varios, eso si siempre dentro del tema clasicas.

¿Pero han enseñado algo de gameplay aparte de los dos segundos de toñas que aparecen en los trailers? Verse se ve de coña, pero eso también le pasaba al Pier Solar y luego como RPG era muy muy normalito.

GaoGaiGar escribió:¿Pero han enseñado algo de gameplay aparte de los dos segundos de toñas que aparecen en los trailers? Verse se ve de coña, pero eso también le pasaba al Pier Solar y luego como RPG era muy muy normalito.

Un RPG es más complejo a nivel jugable (como experiencia, contenido y esas cosas digo, no por el control y demás) o narrativo que un simple brawler. Lo poco que se ha visto creo sirve de momento para hacerse una idea de lo que puede dar de sí. No se.. tendría que tener fallos muy gordos ocultos como para que fuera decepcionante.

gynion escribió:

GaoGaiGar escribió:¿Pero han enseñado algo de gameplay aparte de los dos segundos de toñas que aparecen en los trailers? Verse se ve de coña, pero eso también le pasaba al Pier Solar y luego como RPG era muy muy normalito.

Un RPG es más complejo a nivel jugable o narrativo que un simple brawler. Lo poco que se ha visto creo sirve de momento para hacerse una idea de lo que puede dar de si. No se.. tendría que tener fallos muy gordos ocultos como para que fuera decepcionante.

This. Venía a decir lo mismo, esto es andar y repatir estopa. Lo único que puede que se haga repetitivo o tenga un nivel de dificultad absurdo...pero lo visto sirve bien para hacerse a la idea de como puede ser.

Lo que más puede joder un brawler son las colisiones; no hay más que jugar a las tortugas ninja de Mega Drive, todo contundencia y precisión de impactos, y e Turtles in Time de la SNES; en donde muchos enemigos parecen de papel, y en otros los golpes no se sienten como deberían.

Y que esté mal calibrada la cadencia del combo, como por ejemplo en el FF de Mega CD.

Veo que esperáis poco de un beat'em up. Yo aún no sé cómo son sus físicas, cómo se puede combear, cuántos movimientos trae cada personaje, qué variedad tienen los enemigos entre sí, si los protas son más o menos clones entre sí, etc. Hasta ahora es como ver un tráiler de un videojuego donde sólo se muestra un trozo del vídeo de la intro. Me recuerda un poco a los FIFA, donde te ponían un trozo de un vídeo y todo dios flipando jeje.

@Sexy MotherFucker

Y el sistema de agarres de Hyperstone Heist Mega Drive es mas jodido que el de SNES te obliga a estar a un X frame de distancia, ni mas lejos ni mas cerca porqué sino no engancha, y eso en medio de un combate en juego como las tortugas....nose nose para mi lo hace menos preciso y lo saca de la estrategia de combate.

Hablando de PAPRIUM y viendo que tendrá toques RPG y lo megas que usa ... tendrá una longitud bastante considerable ( y mas para producir background a tutiplen) y esto a los puristas de no muy corto pero tampoco muy largo ( estilo Arcade no muy largo) puede echarle para atrás.

Es la cosa, que si la jugabilidad no es profunda y satisfactoria, un juego largo se hace muuuy largo. Si es un machacabotones hasta para ser un beat'em up se hará muy pesado, y es algo que no sabemos.

Por lo que se ve en pantalla, jugando, un brawler es más complejo de programar que un RPG (excluyo a los ActionRPG de esta definición) que son, en teoría, algo más pausados la mayoría del tiempo, y en el que a veces sólo tienes que calcular el movimiento del sprite protagonista paseando en escenarios que, por muy bonitos y complejos que nos parezcan, son pantallas completamente estáticas en muchos de los casos o con poco movimiento.

El tema de la detección de golpes, el límite/tamaño de sprites en pantalla en constante movimiento (de tantos personajes a la vez), las IA's y el comportamiento de los enemigos, sus rutinas de ataque y huida, las caídas y sus formas de levantarse sin petarlo todo, lo que viene siendo el manejar las múltiples animaciones de cada uno y un largo etcétera.
Calculando que es gerundio.

Yo lo que tengo miedo en Paprium es a lo que no hemos visto aún, al gameplay en sí, que se haga corto/largo, el saber el número de golpes especiales/combos de cada personaje y esas cositas que lo harán más o menos jugable y son una incógnita.

Sí, pero en lo que respecta a contenido, historia, narrativa, música, profundidad jugable y esas cosas, para mí que un gran RPG es más difícil de crear que un gran brawler.

Sin saberlo, casi que estoy seguro que el equipo de desarrollo de Chrono Trigger era considerablemente mayor en recursos y personal que el de la saga Streets of Rage, por poner un ejemplo de dos grandes en sus respectivos géneros.

Lo decía más que nada por el compañero que decía que Pier Solar le parecía muy normalito.

GaoGaiGar escribió:¿Pero han enseñado algo de gameplay aparte de los dos segundos de toñas que aparecen en los trailers? Verse se ve de coña, pero eso también le pasaba al Pier Solar y luego como RPG era muy muy normalito.

Un cagarro, ahi lo tengo abandonado

Normalmente un jrpg de la época es sencillo de programar. No suele haber enemigos moviéndose por el escenario y cuando los hay siguen una ruta simple, y los combates son por turnos bastante sencillos. Un beat'em up es un quebradero de cabeza porque mueve muchas cosas y hay que optimizar el tema sprites, escritura de tiles, VRAM, etc. Además hay que acoplar varias IAs más o menos complejas para que no hagan cosas raras

Un jrpg en ningún momento debe exigir demasiado a la consola quitando efectos gráficos puntuales tipo efecto axelay en el Pier Solar. El desafío en un jrpg es más artistico que en tema programación. La complejidad de un jrpg es crear unos escenarios increíbles, una gran historia y buenos personajes, cosa que en esa época tampoco es que se matasen demasiado por limitación hardware (espacio en rom, colores...) o por lo que sea.

gynion escribió:Sí, pero en lo que respecta a contenido, historia, narrativa, música, profundidad jugable y esas cosas, para mí que un gran RPG es más difícil de crear que un gran brawler.

Sin saberlo, casi que estoy seguro que el equipo de desarrollo de Chrono Trigger era considerablemente mayor en recursos y personal que el de la saga Streets of Rage, por poner un ejemplo de dos grandes en sus respectivos géneros.

Lo decía más que nada por el compañero que decía que Pier Solar le parecía muy normalito.

Cierto, de hecho 'Ancient', la compañía de Yuzo Koshiro era muy reducida, se puede decir que era una pequeña familia, literalmente.

Pero solamente en plantear la historia, crear los 'storyboard' y demás... Es más tardío.
Como proyecto , un RPG, es más lento de hacer.
Estoy de acuerdo en eso @gynion.

@Manveru Ainu @Paprium
Sí, justo a eso me refería, a lo artístico principalmente. Supongo que en lo que respecta a lo técnico, a pelearse con la maquina, un brawler como Paprium tendrá mayor complejidad.

Pues un VS yo pienso que es más sencillo que un brawler o un Rpg, y mirad del Unholy Nights...

robert kendo escribió:¿Cuando mostrarán un video con el juego en movimiento?
Esos gifts que han mostrado no saben a nada,me gustaría ver como responde el juego en aspectos clave como fisicas, movimientos,respuesta al pad etc antes de pagar por dicho juego.

Mucha gente ya compro sin ver prácticamente nada,yo hasta que no vea realmente algo no suelto un duro.

robert kendo escribió:Yo no llamaria game play a eso, son gifts.
Serviran para ver el tamaño de los personajes, coloridos etc

Pero para ver bien que físicas, movimientos, inpactos etc tiene el juego en mi opinión esos gifs no sirven para nada.

De hecho en uno d esos gifts se ve un fallo.en una cadena que se ve por delante del personaje y que no dudo sera pulido.

Yo también voy a esperar a que salga alguna demo real corriendo alguna parte del juego, ya que de momento sólo parece GAS, aunque pinte muy bien.

Total sólo son unos meses... ¿2018?

aranya escribió:Pues un VS yo pienso que es más sencillo que un brawler o un Rpg, y mirad del Unholy Nights...

Un VS es muchísimo más complicado de hacer "bien" que un RPG o incluso un brawler. Las lógicas de colisiones, IA, etc, son infernales.

Dudo que respeten la fecha del 16/09/2017, su trayectoria de retrasos avala perfectamente un principios 2018

Ojala me equivoque, pero las sensaciones son estas, ademas, en ventas PAPRIUM ha superado todos sus anteriores lanzamientos por goleada, así que la logística de envíos, que ya era caótica antes, para este PAPRIUM puede ser mortal.

También debo decir, que siempre han cumplido, y ante problemas, siempre responden.

En fin, veremos

SoNi escribió:Dudo que respeten la fecha del 16/09/2017, su trayectoria de retrasos avala perfectamente un principios 2018

Ojala me equivoque, pero las sensaciones son estas, ademas, en ventas PAPRIUM ha superado todos sus anteriores lanzamientos por goleada, así que la logística de envíos, que ya era caótica antes, para este PAPRIUM puede ser mortal.

También debo decir, que siempre han cumplido, y ante problemas, siempre responden.

En fin, veremos

Mientras sea principios de 2018 y no principios de 2019 no me importa demasiado xD

kusfo79 escribió:
Un VS es muchísimo más complicado de hacer "bien" que un RPG o incluso un brawler. Las lógicas de colisiones, IA, etc, son infernales.

Bueno, un brawler viene siendo un VS...con más personajes, IA's simultáneas, físicas, detección de colisiones, ect.

Por esa misma regla de tres un brawler será más complicado de programar que un juego de lucha 1 vs.1.

Paprium escribió:

kusfo79 escribió:
Un VS es muchísimo más complicado de hacer "bien" que un RPG o incluso un brawler. Las lógicas de colisiones, IA, etc, son infernales.

Bueno, un brawler viene siendo un VS...con más personajes, IA's simultáneas, físicas, detección de colisiones, ect.

Por esa misma regla de tres un brawler será más complicado de programar que un juego de lucha 1 vs.1.

Normalmente, tanto la I.A como las colisiones son mas simples en un brawler. Por caso concreto, Streets Of Rage tiene una implementación de colisiones mucho mas simple que el Street Fighter II.

kusfo79 escribió:
Normalmente, tanto la I.A como las colisiones son mas simples en un brawler. Por caso concreto, Streets Of Rage tiene una implementación de colisiones mucho mas simple que el Street Fighter II.

En eso de las IA's discrepo contigo, no creo que en los Streets of Rage de Master System, por ejemplo, las IA's de los enemigos sean mucho más simples que en juegos VS como Master of Combat o Pit-Fighter.

Y luego hay que tener en cuenta el número de ellas que se procesa a la vez, que evidentemente también influye y es de valorar.

Aparte estos son juegos multi-direccionales, dónde se desplazan por todo el escenario, con la de variantes que eso puede ocasionar y eso también habrá que calcularlo en condiciones para predecirlo y optimizarlo.
También tenemos que tener en cuenta que un final-boss de fase en un brawler tendrá otra IA's distinta (y más compleja) a un simple 'masilla' y enemigo normal.

Dependerá de la complejidad global que le quieran dar.
Pero ponte el SoR2 de Megadrive en modo Hard y analiza cuántas IA's y el comportamiento de los enemigos en comparación a otros niveles de dificultad.

Hemos visto muchos beat'em'up dónde los enemigos se comportan como pollos sin cabeza pero también juegos de 1 versus 1 súper fáciles de 'romper' y adivinar las rutinas de ataque en la primera partida, dónde simplemente saltando y pegando una patada en el aire vences todos los combates con facilidad pasmosa.

Vaya, interesante lo de cual tipo de juego es mas complicado. Yo lo dije pensando en que un juego VS, son X personajes, con X escenarios y ya. Un RPG es mucho mas complejo, por variedad, argumento, objetos, opciones, posibilidades, etc. Y sobre un Brawler, pues mas de lo mismo.

A ver que conclusión sacamos.

Un saludo.

yo creo que un vs tiene que ser complicao ,ya solo calcular los impactos en varias partes del personaje y de todas los golpes y tecnicas .
la integracion con los escenarios ,aparte ya el diseño artistico .
no se lo veo chungo .

@Paprium

Hombre, en esos casos en concreto, la diferencia no es muy grande, pero si comparas un juego VS tipo street figther para arriba, con un Streets of Rage o un Final Fight, la diferencia es abismal. Tanto en la IA de los enemigos como sobretodo la gestión de las hitboxes con las animaciones. A veces puede haber mas hitboxes en un personaje que en todo lo que hay en pantalla en un brawler!



@aranya
Hablando solo de programación, un RPG es de lo mas sencillo que hay. Un brawler o un juego de lucha son mucho mas complicados

@kusfo79 no se puede ver la imagen que pusiste, cierto es que el Street Fighter II que nombraste es muy top en ese sentido, marcó los parámetros de todos los VS en la época, pero por desgracia no todos están tan bien programados ni son tan complejos como el juego de Capcom, por ejemplo para mal nombraría algunas versiones de Mortal Kombat.
Dónde la detección de colisiones puede ser bastante aleatoria ,no estando del todo pulida y a veces recibes daños en circunstancias 'extrañas'.
Con multitud de bugs que afectan a la jugabilidad.

Por contra también he visto VS bien optimizados que la IA rival varía dependiendo de la pericia del jugador , que detectan cuál es tu forma de peleear contrarrestando que abuses de ciertas mecánicas, utilizando un set de movimientos distintos según contra quién se enfrenten o brawlers dónde los enemigos recogen del suelo distintos ítems caídos por el protagonista para utilizarlos ellos de nuevo (katanas, bates de béisbol, cuchillos, palos, tuberías, ect), o que incluso huyen despavoridos si son minoría y atacan solamente cuándo son mayoría (como los gitanos xd).

Realmente depende del juego,
habrá Brawlers más dificiles de programar que VS y viceversa.
Estoy de acuerdo con ambos @kusfo79 @Paprium .

Pero si me comparas el Double Dragon (brawler viejuno) https://gamefaqs.akamaized.net/screens/ ... 65_2_1.jpg con el Double Dragon (VS, Neo geo) https://i.ytimg.com/vi/_32MNDQAwRc/maxresdefault.jpg pues evidentemente no hay nada que hacer.

kusfo79 escribió: @aranya
Hablando solo de programación, un RPG es de lo mas sencillo que hay. Un brawler o un juego de lucha son mucho mas complicados

Absolutamente discrepo. Un nethack no se hace en dos días (y eso que es un rpg 2d sin amaciones) Y sobre VS... ¿acaso nadie se acuerda del Mugen? Creo que aquí se confude la complejidad del diseño con la complicación de programar.

Un beat'emup lo haces en dos tardes. Un RPG ponte con sistema de menús, inventario, eventos, sistemas de combate....

Naitguolf escribió:

kusfo79 escribió: @aranya
Hablando solo de programación, un RPG es de lo mas sencillo que hay. Un brawler o un juego de lucha son mucho mas complicados

Absolutamente discrepo. Un nethack no se hace en dos días (y eso que es un rpg 2d sin amaciones) Y sobre VS... ¿acaso nadie se acuerda del Mugen? Creo que aquí se confude la complejidad del diseño con la complicación de programar.

Un beat'emup lo haces en dos tardes. Un RPG ponte con sistema de menús, inventario, eventos, sistemas de combate....

RPG Maker...

Paprium escribió:

Naitguolf escribió:

kusfo79 escribió: @aranya
Hablando solo de programación, un RPG es de lo mas sencillo que hay. Un brawler o un juego de lucha son mucho mas complicados

Absolutamente discrepo. Un nethack no se hace en dos días (y eso que es un rpg 2d sin amaciones) Y sobre VS... ¿acaso nadie se acuerda del Mugen? Creo que aquí se confude la complejidad del diseño con la complicación de programar.

Un beat'emup lo haces en dos tardes. Un RPG ponte con sistema de menús, inventario, eventos, sistemas de combate....

RPG Maker...

También está Openbor.

Pero todo eso en realidad son editores bastante prediseñados. Es como comparar comida precocinada con un plato hecho con productos frescos y desde 0.

Naitguolf escribió:

kusfo79 escribió: @aranya
Hablando solo de programación, un RPG es de lo mas sencillo que hay. Un brawler o un juego de lucha son mucho mas complicados

Absolutamente discrepo. Un nethack no se hace en dos días (y eso que es un rpg 2d sin amaciones) Y sobre VS... ¿acaso nadie se acuerda del Mugen? Creo que aquí se confude la complejidad del diseño con la complicación de programar.

Un beat'emup lo haces en dos tardes. Un RPG ponte con sistema de menús, inventario, eventos, sistemas de combate....

Se nota que has programado mucho en tema juegos, eso o debes haber imaginado y comparado un rpg actual con un beat'em up de los 80s, si no no tiene explicación

Una cosa son engines que ayudan en el tema hardware, físicas y tal para hacer videojuegos, y otra cosa programas donde "haces" juegos con drag&drop y rellenando plantillas. Es como decir que acabas de construir una casa cuando lo que has hecho es coger una casa existente y pintarla de otro color...

Un beat'em up de los top de los 16 bits es muy muy jodido si quieres que sea tuyo y no un copypasteo de código de otros. Un rpg de la época es muy sencillo. Los sistemas de menús e inventarios son lo más trivial en cualquier videojuego, es lo que hace uno cuando quiere despejarse un poco.

El sistema de combate en un juego por turnos es una simple máquina de estados + un random de unas poquitas acciones. En uno en tiempo real tipo Zelda no es más que comprobar la colisión del player o su ataque con los enemigos en su columna. Los eventos los lanzas cuando el personaje colisiona con un tile del mapa que lanza una escena/función o cambia el estado del juego, y listo.

Como ya se ha dicho, un rpg es muuucho curro y talento artístico (gráficos, sonidos y de guión si tiene) y tienes que esclavizar a los muerdelápices durante eones, pero programar un engine de un rpg de 8 o 16 bits es lo que debería hacer cualquier programador primerizo de videojuegos tras acabar el típico Pong.

En un beat'em up tienes que sudar tinta con las físicas, colisiones, resolución de conflictos, con la potencia y limitaciones de la consola, con manejar varias IAs interactuando con las otras, con el hardware, con los players y el entorno, etc. Y gráfica-sonoramente no se queda corto precisamente...

No tengo nada más que añadir a lo que ha comentado mi compi @Manveru Ainu jejeje. un RPG es de lo mas sencillo de programar que existe, después de las cosas tipo galaxian, pongs, etcs


@Dimitar Berbatin
Obviamente, un Streets of Rage II es mas complejo que un Masters of Combat (aunque este no está nada mal). Y un Mortal Kombat no es lo mismo que un Street Fighter. Pero por ejemplo, un Eternal Champions mismo, aunque no está muy apreciado, tiene una programación muy compleja detrás.

Manveru Ainu escribió:

Naitguolf escribió:

kusfo79 escribió: @aranya
Hablando solo de programación, un RPG es de lo mas sencillo que hay. Un brawler o un juego de lucha son mucho mas complicados

Absolutamente discrepo. Un nethack no se hace en dos días (y eso que es un rpg 2d sin amaciones) Y sobre VS... ¿acaso nadie se acuerda del Mugen? Creo que aquí se confude la complejidad del diseño con la complicación de programar.

Un beat'emup lo haces en dos tardes. Un RPG ponte con sistema de menús, inventario, eventos, sistemas de combate....

Se nota que has programado mucho en tema juegos, eso o debes haber imaginado y comparado un rpg actual con un beat'em up de los 80s, si no no tiene explicación

Pues sí, justamente hablo con conocimiento de causa. Un Bet'em up lo he hecho en dos días. En los foros de Gemix puedes encontrar por ejemplo el Kings of Moe que lo hice en un par de días. Sin embargo, un remake que estuve haciendo (y ahí lo tengo aún a medias) el del Hydlide 3, tela con cada menu, inventarios, habilidades, condiciones de estado, eventos, IA, gestión de inventario, conversaciones, tablas, etc, etc. Un beat'em up tiene su complejidad en su diseño para hacerlo lo más diferente posible y que no sea aburrido, más que código (más allá de las limitaciones que tenga la máquina y tengas que apretar lo que tengas que apretar porque no cabe)

Y el que menciona el RPG maker, habrá visto la ingente cantidad de elementos que ya tiene por adelantado VS lo que necesita un muñeco del Mugen...

De hecho, lo PEOR que puedes hacer tras empezar a programar, es ponerte con un RPG (muuucha gente lo ha intentado) y al final terminas dejándolo porque hay tocar demasiados conceptos más allá de mover un muñeco y que al pulsar un botón, haga la animación y saque una caja de colisión y si impacta, haga daño. Pero si esque ya solo con tener que pensar que al final tienes que crear scripts para gestionar las variantes que hay... VS a lo único que tienes que hacer, es ir lanzando enemigos a medida que la pantalla avanza hacia adelante hasta llegar al boss, y poco más.

Un beat'em up en dos días? (aunque sea con gemix). Solo programar todo lo que son las colisiones en una consola de la época es una locura! Olvídate de colisiones pixel perfect ni chequear todas las colisiones posibles. En un juego así es una cosa infernal.

En cambio, un RPG no ya tipo Zelda de 8 o 16 bits (sencillísimo), sino que un Shining Force II mismamente es bastante fácil, mucho más que nada que implique lucha y golpes. Programar un sistema de menus es de lo más sencillo que te puedes encontrar, por eso muchos juegos de ordenadores del inicio de los tiempos son rpg's llenos de menus etc.

Ojo, que otro gallo nos cantaría si me dijeras (ya para no irme a cosas viejunas) un Ultima VII, que creo que es uno de los juegos más complicados de programar de la historia.

kusfo79 escribió:Ojo, que otro gallo nos cantaría si me dijeras (ya para no irme a cosas viejunas) un Ultima VII, que creo que es uno de los juegos más complicados de programar de la historia.

Es un punto de vista interesante. Normalmente creo que los usuarios comunes no solemos plantearnos los juegos según su complejidad de programación, sino según su aparente complejidad o vistosidad.

Siguiendo con el ejemplo de Shining Force II y Ultima VII, podría desgranar sus necesidades así:

- Shining Force II:
* Guardar stats y caracteristicas de los personajes
* Inventario
* Colisiones a nivel de metatile
* En las casillas especiales de cada pantalla, si se ha obtenido el objeto correspondiente o no
* IA en las batallas
* Historia traqueada por unas pocas variables de estado, y lineal

-Ultima VII:
*Mundo entero sin transiciones
* Guardar las posiciones de TODOS los objetos de TODO el mundo, y poder moverlos libremente.
* Mas de 100 combinaciones diferentes entre objectos.
* Historia muy poco lineal
* TODOS los personajes de TODO el mundo, actuan segun la hora, van a comer, duermen, matan a lobos, se pelean, etc

True Gamer Contest #6

Get ready for the new Showtime's underwear name

armageddonG

...... ya tiene nombre la ropita interior de PAPRIUM .......

Ese cuello no es normal xD

Naitguolf escribió:[Pues sí, justamente hablo con conocimiento de causa. Un Bet'em up lo he hecho en dos días. En los foros de Gemix puedes encontrar por ejemplo el Kings of Moe que lo hice en un par de días. Sin embargo, un remake que estuve haciendo (y ahí lo tengo aún a medias) el del Hydlide 3, tela con cada menu, inventarios, habilidades, condiciones de estado, eventos, IA, gestión de inventario, conversaciones, tablas, etc, etc. Un beat'em up tiene su complejidad en su diseño para hacerlo lo más diferente posible y que no sea aburrido, más que código (más allá de las limitaciones que tenga la máquina y tengas que apretar lo que tengas que apretar porque no cabe)

Y el que menciona el RPG maker, habrá visto la ingente cantidad de elementos que ya tiene por adelantado VS lo que necesita un muñeco del Mugen...

De hecho, lo PEOR que puedes hacer tras empezar a programar, es ponerte con un RPG (muuucha gente lo ha intentado) y al final terminas dejándolo porque hay tocar demasiados conceptos más allá de mover un muñeco y que al pulsar un botón, haga la animación y saque una caja de colisión y si impacta, haga daño. Pero si esque ya solo con tener que pensar que al final tienes que crear scripts para gestionar las variantes que hay... VS a lo único que tienes que hacer, es ir lanzando enemigos a medida que la pantalla avanza hacia adelante hasta llegar al boss, y poco más.

Lo que decía antes, cuando hablas de rpg parece que hablas de Skyrim y cuando hablas de beatem up hablas del primer double dragon. Eso es un debate tendencioso sin sentido que no se corresponde a la realidad. Hablamos de lo mejor en 8 y 16 bits, no de juegos simples como los hydlides o los primeros yo contra el barrio. De todas formas los hydlides son muuucho más simples aún que los rpgs que yo tenía en la cabeza de snes y md/mcd,

PD: alguien que sepa algo de programar videojuegos no llamaría dificil a hacer "tela con cada menu, inventarios, habilidades, condiciones de estado, eventos, IA, gestión de inventario, conversaciones, tablas, etc, etc.". Eso es lo más trivial en un videojuego, sobre todo la "IA" de un rpg donde no suele haber más que hacer bucle de un par de patrones.

Y el último párrafo más de lo mismo, algo que no puede ser menos cierto con poco que hayas visto y vivido el mundillo. La gente no suele acabar los rpgs porque hace los engines en poco tiempo y luego es repetición, repetición, repetición... hasta el infinito, y necesitas mucho material gráfico y no siempre es fácil obtenerlo.

"VS a lo único que tienes que hacer, es ir lanzando enemigos a medida que la pantalla avanza hacia adelante hasta llegar al boss, y poco más" Esa frase es para llevarla en la firma como epic fail jejeje, así serán los beat'em ups que has programado...

Quien puede responderos bien es @magno

Señor Ventura escribió:Quien puede responderos bien es @magno

Y añado a @Bomberlink en esta discusiòn, que de programar brawlers entiende 'un poquito'.

Por cierto, qué presencia e influencia que tiene magno en lo que respecta al romhacking de SNES. El otro día estuve buscando info para ver como podía insertar acentos y otros caractéres en un juego de SNES, y me salían unos cuantos documentos que rezaban al comienzo "Este manual se ha podido realizar gracias a Magno, que..."

Si, es un monstruo el tio...

Es como si estuviese carmack por aquí, comentando, como si fuese normal xD

Para sumar dos enteros no es preciso invocar a Einstein o Newton. Basta con trastear un poco con el inicio de un engine para cada modo de juego para darse cuenta del esfuerzo que requiere (hablamos de dificultad de programación, no de complejidad argumental, artística, etc.).

@magno es un crack, tiene una web con sus roms de snes traducidas:
http://magno.romhackhispano.org/

Además no se limita solo a traducir.
Mete mejoras en los juegos y soluciona bugs.
Conoce muy bien la máquina.

Manveru Ainu escribió:Para sumar dos enteros no es preciso invocar a Einstein o Newton. Basta con trastear un poco con el inicio de un engine para cada modo de juego para darse cuenta del esfuerzo que requiere (hablamos de dificultad de programación, no de complejidad argumental, artística, etc.).

+1000

Gracias por lo que comentáis de mi No sé muy bien que de qué va el hilo, pero supongo que @Señor Ventura me ha invocado cual demonio Lich por esto:

Manveru Ainu escribió:Lo que decía antes, cuando hablas de rpg parece que hablas de Skyrim y cuando hablas de beatem up hablas del primer double dragon. Eso es un debate tendencioso sin sentido que no se corresponde a la realidad. Hablamos de lo mejor en 8 y 16 bits, no de juegos simples como los hydlides o los primeros yo contra el barrio. De todas formas los hydlides son muuucho más simples aún que los rpgs que yo tenía en la cabeza de snes y md/mcd,

PD: alguien que sepa algo de programar videojuegos no llamaría dificil a hacer "tela con cada menu, inventarios, habilidades, condiciones de estado, eventos, IA, gestión de inventario, conversaciones, tablas, etc, etc.". Eso es lo más trivial en un videojuego, sobre todo la "IA" de un rpg donde no suele haber más que hacer bucle de un par de patrones.

Y el último párrafo más de lo mismo, algo que no puede ser menos cierto con poco que hayas visto y vivido el mundillo. La gente no suele acabar los rpgs porque hace los engines en poco tiempo y luego es repetición, repetición, repetición... hasta el infinito, y necesitas mucho material gráfico y no siempre es fácil obtenerlo.

"VS a lo único que tienes que hacer, es ir lanzando enemigos a medida que la pantalla avanza hacia adelante hasta llegar al boss, y poco más" Esa frase es para llevarla en la firma como epic fail jejeje, así serán los beat'em ups que has programado...

En mi caso, estoy programando un RPG y he destripado 3 en profundidad: Romancing Saga 3, Treasure Hunter G y Star Ocean... y cuando digo "destripar" me refiero a que he extraído el código fuente que maneja toda la lógica del juego y, en mi experiencia personal, estoy más de acuerdo con @Naitguolf.
La mejor manera de explicarlo es con un ejemplo del Star Ocean para construir una escena mientras se hace una transición en negro entrando a un pueblo del juego:

* La lógica del juego detecta dónde ha pisado el personaje para leer el ID de la escena donde se cambia
* Se accede a unas tablas que envían todas el tileset (las tiles comprimidas con el S-DD1) a VRAM y el tilemap (comprimido LZ) a RAM para formar el escenario completo del pruelbo; esto incluye las tiles de 4BPP para BG1 y BG2 y el efecto de sombreado que se hace con matemática de color. Esto se haría también en un beat'em up.
* Se descomprime con LZ el mapa de la zona que compone el tilemap completo del pueblo, no solo lo que se ve en pantalla, de modo que se pueda hacer scroll libremente. Esto no lo tienen por qué tener los beat'em up, ya que normalmente son lineales o al menos, mucho más limitados en libertad de movimiento.
* Se configuran las variables de cámara y márgenes de scroll y se crea el mapa de eventos, que permite saber, según las coordenadas del personaje dentro del mapa completo del pueblo si una tile se puede atravesar, dónde están las entradas y salidas de las casas, del propio pueblo, etc. Esto tampoco lo suelen tener los beat'em up, al menos no con tanta complejidad, ya que un pueblo del StarOcean está lleno de casas y paredes y un beat'em up no suele.
* Se descomprime con LZ el script de comandos, que es el que se ejecuta para decir qué personaje hace qué acciones en el pueblo en concreto. Por ejemplo, el script de comandos crea un personaje en las coordenadas (600, 1100) del pueblo y un evento asociado a él que hace que cuando hables con ese personaje, se ejecute una cut-scene. Este script suele ser bastante complejo y dependiendo del juego, el script lo hace todo (como en Romancing Saga 3) o bien hay un script principal que configura todo lo explicado en los puntos anteriores y luego apunta a un script separado para los eventos concretos del pueblo donde estás ahora (como hace THG, que tiene un script principal que configura VRAM y RAM con el mapa, un script que inserta los eventos y donde cada evento llama a otro script con el texto y las acciones concretas a ejecutar).
* Según las acciones clave que va ejecutando el personaje, se van marcando unos flags en un array que indica si el personaje ha hablado con tal o cual persona, si ha realizado tal misión, o si lleva a tal personaje en el grupo. Esto también es muy complejo porque implica un árbol de decisiones según las acciones realizadas con anterioridad (en el código fuente de Romancing Saga 3 que liberé se puede ver claramente cómo se comprueba cada flag) y no suele existir en los beat'em up.
* Según el equipo que lleve el personaje, también se lanzan acciones (como la Ocarina en Star Ocean) y además, modifica los status del personaje, lo cual en batalla complica el cálculo del daño inflingido y recibido por cada personaje. Esto además complica los menús sobremanera. En el Star Ocean, todo el banco $CA se dedica a la gestión de los menús y de cada sub-menú, y ahora que tengo extraído casi el 70% del mismo, os digo que es muy complejo. Existe una rutina por cada status del personaje que se llama cuando se quiere saber algo tan básico como el HP máximo que tiene: esta rutina comprueba el equipo que lleva y si hay algún item modificador del HP, se accede a unas tablas para saber cuánto es éste. Así que crear un inventario de objetos es complicado porque has de meter en unas tablas qué modifica cada uno, y luego en otra tabla, cuánto es este modificador. Así, en Star Ocean se almacena 1 byte con el ID del objeto y otro byte con los flags modificadores.
* Luego, los RPG suelen tener pijadillas como en el caso del Star Ocean los talentos o habilidades, que tienen una serie de rutinas con su propia lógica de funcionamiento. No es que sea complicado programarlas, pero es un trabajo extra enorme, ya que influye en las batallas (por ejemplo, según el nivel de "Golpe Fuerte", el modificador del crítico es diferente cuando golpeas)
* Y la diferencia más evidente es que las batallas son un motor completamente diferente que ocupa 2 bancos de ROM de código: las animaciones son diferentes, hay que programar los efectos mágicos y añadir IA para cada personaje jugable y, si se hace bien, IA para cada tipo de enemigo, unos má agresivos, otro menos, etc... Esto tampoco lo tiene un beat'em up.

Yo personalmente creo que un RPG es mucho más complicado de programar, y uno de los ejemplos claros son los bugs en el sistema de batalla que tiene FF6, que "olvidan" comprobar ciertos modificadores en algunos objetos, o ciertos contadores y llevan años resolviéndolos gente anónima.

@magno Todo lo que has puesto son llamadas a funciones de hardware o a las librerías de descompresión, o carga de templates de datos o comprobaciones/máquinas de estados. Sobre las IAs, los rpgs no llevan IAs, llevan preprogramados 3 o 4 movimientos que suelen hacer de manera aleatoria. Sobre la carga de una escena, no es más que llamar a la función de fade previa carga de la plantilla de escena, con unos cuantos flags a comprobar y a actuar en consecuencia (básicamente una secuencia de ifs/ands).

Se agradece que comentes tu experiencia, pero todo lo que has escrito parece más una descripción de cómo funcionan las cosas pero no sobre la complejidad de programación de cada cosa. Muchas de las cosas que has puesto (por no decir todas) son triviales programadorilmente hablando.

Buenas @magno un honor! :-D

Todo esto que comentas realmente no me parece muy complicado desde el punto de vista de programador. Mismamente en Antarex, mucho de los primeros pasos que comentas ya los estamos realizando (cargar todo el tilemap e irlo actualizando a medida que te mueves, por que es más grande que la pantalla virtual), luego los eventos de generación de bichejos y eventos también estarían presentes en beat'em up ( y los usamos en antarex). Si que existe la complejidad añadida de los arboles de decisión argumentales, etc, pero no me parece algo muy complicado de gestionar. Yo mismo en los 90 hice un reimplementación del Shining Force en DIV 2, con los gráficos ripeados directamente, y aunque no era fiel al 100%, no me llevo mucho trabajo (Algún dia tengo que recuperar eso).

En cambio, en un brawler un poco currado (No un Double Dragon, ni tan solo un Golden Axe) como Streets Of Rage 2, tienes que generar decenas de hitboxes por cada frame de animación de tu personaje y de cada uno de tus enemigos, hacerlo de forma eficiente, y encima también tienes todo un árbol de posibilidades a la hora de gestionar como reaccionan dos personajes cuando chocan, dependiendo de que hitboxes se han tocado. Aparte de ello, por supuesto, que en una megadrive no puedes simplemente chequear todas las colisiones posibles, y has de tener políticas inteligentes sobre como gestionar las colisiones (no intentes hacer un pseudo quad tree).

Esto mismo que decimos de Streets of Rage, aún se hace más complicado en un Street Fighter 2, donde la IA del enemigo es una puta locura en si misma, y encima el número de hitboxes se dispara.

Eso si, para no desmerecer a los RPG's, hacer esto en la época en ensamblador y no C o DIV o GEMIX era un trabajo solo para valientes!

kusfo79 escribió:En cambio, en un brawler un poco currado (No un Double Dragon, ni tan solo un Golden Axe) como Streets Of Rage 2, tienes que generar decenas de hitboxes por cada frame de animación de tu personaje y de cada uno de tus enemigos, hacerlo de forma eficiente, y encima también tienes todo un árbol de posibilidades a la hora de gestionar como reaccionan dos personajes cuando chocan, dependiendo de que hitboxes se han tocado. Aparte de ello, por supuesto, que en una megadrive no puedes simplemente chequear todas las colisiones posibles, y has de tener políticas inteligentes sobre como gestionar las colisiones (no intentes hacer un pseudo quad tree).

Esto es algo que también se hace en los RPG: dependiendo del tipo de golpe que des y dónde impactes en el enemigo, actúa una defensa u otra, por ejemplo pasa en el Treasure Hunter G. Así que las cajas de colisión también se tienen en cuenta, pero incluso se tienen en cuenta cuando caminas por dentro de un pueblo.

Manveru Ainu escribió:@magno Todo lo que has puesto son llamadas a funciones de hardware o a las librerías de descompresión, o carga de templates de datos o comprobaciones/máquinas de estados.

Que va, nada de librerías, son rutinas programadas a pelo; ten en cuenta que Nintendo no daba librerías para programar en SNES (al menos que se tenga constancia) y muchas compañías de juegos (véase Squaresoft) programaban todo desde cero. Si hubieran llamadas a librerías estaría todo más ordenado y no sería una locura desensamblarlo. Un ejemplo son las 4 rutinas de texto VWF diferente que implementa Romancing Saga 3: si hubiera una librería, se llamaría a ella para presentar el texto, pero no, programaron 4 diferentes para 4 partes diferentes: una para los diálogos, otra para los menús, otra para las batallas militares y otra para el mini-juego de las empresas.

Manveru Ainu escribió:Sobre las IAs, los rpgs no llevan IAs, llevan preprogramados 3 o 4 movimientos que suelen hacer de manera aleatoria.

No, depende del juego. Ni en THG ni en SO ni en RS3 los ataques de los enemigos se hacen de forma aleatoria, sino que según la cercanía del personaje (en THG y SO) realizan unos ataques u otros, e incluso dependiendo del ataque que realices tú, te contraatacan con otro diferente. En RS3 la IA está mucho más evolucionanda en los monstruos "finales", ya que intentan cambiar el balance mágico de la batalla para regenerarse o hacer que te reste poder de ataque. Un ejemplo claro es un dragón de agua que, si tienes equipado un traje que absorbe magia de agua, te ataque cno ataques físicos y si no, te lanza ataques mágicos muti-target.

Manveru Ainu escribió:Sobre la carga de una escena, no es más que llamar a la función de fade previa carga de la plantilla de escena, con unos cuantos flags a comprobar y a actuar en consecuencia (básicamente una secuencia de ifs/ands).

¿Unos cuantos flags? Creo que trivializas algo que es complejo y entiendo que es porque ni has programado un RPG ni has desensamblado uno. Solo RS3 tiene un array de 1024 flags y a parte otro de interacciones entre los personajes, ya que dependiendo de quién lleves se ejecutan aciones diferentes en según qué pueblo.

Manveru Ainu escribió:Muchas de las cosas que has puesto (por no decir todas) son triviales programadorilmente hablando.

Creo que este comentario demuestra lo que decía antes: hablas desde el desconocimiento, nadie con un mínimo de experiencia diría que son triviales. Todas las cosas que he puesto antes van "montadas" sobre un sistema de tasking muy primitivo (estamos hablando de 1995/1996 y de programación principalmente en ensamblador): por ejemplo THG tiene un sistema de tareas que se van insertando en una cola y ejecutándose en orden en cada frame, más otra cola de eventos que se ejecuta solo cuando salta el correspondiente.
Además, tiene un sistema de 2 colas para animación de sprites, una de alta prioridad y otra de baja prioridad, de modo que hay personajes cuya animación se actualiza cada frame y otros que solo se actualizan si sobra tiempo en el NMI. Para gestionar esto mismo, StarOcean tiene una lista ligada simple con structs con todos los datos de animación de cada sprite, de modo que al llegar el NMI recorre la lista para ir actualizando la tabla OAM. La lista se liga según la prioridad de cada sprite.

Todas estas cosas no son triviales para nada, pero la ignorancia es muy atrevida. Y si de verdad sabes de lo que hablas, no despreciarías el esfuerzo que supone programar estas cosas. Y cuando he dicho antes:

magno escribió:Yo personalmente creo que un RPG es mucho más complicado de programar

me refería a que tiene más complejidad que un beat'em up, lo cual no quiere decir que sea EXTREMADAMENTE difícil de programar. La dificultad es relativa: a mi no me parece difícil desensamblar un juego, pero a otros le puede parecer imposible o no tener ni idea de por dónde empezar. Y de hecho, creo que la complejidad de un RPG en cuanto a CANTIDAD de código respecto de un beat'em up es evidente: el código fuente de BOB está disponible en internet, compáralo solo con las rutinas que liberé de Romancing Saga 3 y compara; ahí te quedará claro, todo lo demás entra dentro del campo de la opinión.

Ah, y todo esto sin entrar en el driver de sonido porque no domino tanto esa parte y nunca hablo de lo que no sé; además, tampoco podría poner ejemplo y a mi me gusta demostrar lo que digo con ejemplos para que cualquiera contraste, pero lo poco que he visto del Star Ocean en cuanto al sonido ya es de una complejidad elevada: durante las batallas los personajes hablan con una intensidad u otra dependiendo de si tienene poco HP, de si han matado a un personaje con el que tienen un vínculo (Fear y Cius, Ronixis y IRia, Ratix y Milly...). Esto tampoco lo he visto en un beat'em up, pero claro, tampoco me conozco TODOS los beat'em up ni TODOS los RPGs, así que comparo con lo que conozco, que básicamente son Double Dragons, Final Fights, Street of Rage y Battletoads.

Sigo pensando que casi todo esto es más complicado en un brawler, aparte de que el 90% de los RPG's de 16 bits son mucho más simples que los ejemplos que pones. Que haya 1024 flags para controlar eventos de decisión tiene la misma dificultad programadoril que si fueran 10. Lo que tiene es una complejidad de diseño, en lo que lo programadoril no interviene para nada.

Ojo, que entiendo que por lo que dices, seguramente Star Ocean de Super es más complicado que el Golden Axe de mega, pero sigo diciendo, todos los que programamos cosas homebrew (como @Manveru Ainu y yo) hemos empezado haciendo pseudo RPG's, es de lo más fácil para empezar.

Quizá la cosa está en que hacer un RPG sencillo (un Zelda, por ejemplo) es mucho más sencillo que hacer un Brawler Sencillo (Un Double Dragon), y en cambio quizá un Star Ocean es más complicado que un Streets of Rage 2.