Registrarse

¿Por dónde se empieza realmente un hackrom?

Pixwart

Usuario mítico
A estas alturas ya estoy más cerca de los 40 que de los 20, y nunca he hecho un hackrom completo.

Tengo un GBC y un GBA modificados, con cartuchos flasheables para jugar en físico, además de una Anbernic para los ROM hacks que no corre el hardware real. He estado en esto desde que Pokémon Quartz era la novedad; ahora más que nada lurkeo por aquí y en PokéCommunity.

En cuanto a crear, a veces hacía dos o tres cosas sueltas: algún gráfico, alguna corrección o algo sencillo, pero nunca un proyecto entero. Y esa es mi duda: ¿cómo suelen asumir un proyecto de este tipo?

Tengo entendido que se empieza por la idea, luego se diseña la historia, después la estética, se detallan las mecánicas y finalmente se arma un Game Design Document (ya tengo el de mi hack hecho xd), donde queda más o menos “la receta” para hacer el juego.

O al menos eso creo que es hacer un juego. Pero ustedes, ¿en qué orden le entran? ¿Alguien aquí ya terminó algún proyecto? ¿Están trabajando en algo actualmente? ¿Qué flujo de trabajo les ha funcionado?

Lo pregunto porque vengo de una experiencia un poco distinta. Soy muy fan de la saga S.T.A.L.K.E.R., y notaba que había muchos mods buenos en ruso, inglés o ucraniano, pero muy poca gente traduciéndolos al español. A una sola persona podía tomarle meses trabajar en un proyecto mediano.

Así que hice una herramienta para traducir mods: Zonetraductor (juro que no estoy haciendo spam).

La cuestión es que ese proyecto nació de detectar un problema concreto, buscar una solución y crear un flujo de trabajo intuitivo para quienes ya traducían. Y funcionó.

Los fans hispanos empezaron a usarlo y entenderlo. El manual de usuario siempre estuvo disponible, y después fui agregando funciones como traducción asistida por IA, API de DeepL, marcado de frases ya traducidas, guardado de proyectos, resaltado de variables, etc.

A lo que voy: ese proyecto se me hizo relativamente fácil porque sabía qué le faltaba a la comunidad: una herramienta.

Pero con un hackrom siento que es distinto. No necesariamente “falta” algo. La información ya existe, o se aprende sobre la marcha, y el costo de aprender ya está asumido.

Entonces mi pregunta es: cuando crean un hackrom en solitario, ¿por dónde empiezan?

¿Crean primero los gráficos? ¿Van bocetando el mapeado? ¿Usan recursos default mientras implementan mecánicas y luego los reemplazan? ¿Primero hacen una versión jugable básica? ¿En qué orden les ha funcionado trabajar?

No pregunto por proyectos en equipo, porque ahí hay especializaciones y muchas cosas pueden hacerse en paralelo.

Y ya para cerrar: también estoy trabajando en una herramienta para traducir hackroms, tomando como base una herramienta que ya existe y que extrae las cadenas de texto en un CSV.

Gracias por leer, y perdón si me extendí un poco.
 

Micolo

Autista de creatividad ilimitada
Miembro del equipo
Moderador/a
Yo creo que la mayoría empieza decidiendo que base usar para el hackrom, si binario o decompilación, actualmente se usa más la segunda y con la duda de si usar Rojo Fuego o Esmeralda como juego de base
 

liovy

Usuario de oro
A estas alturas ya estoy más cerca de los 40 que de los 20, y nunca he hecho un hackrom completo.

Tengo un GBC y un GBA modificados, con cartuchos flasheables para jugar en físico, además de una Anbernic para los ROM hacks que no corre el hardware real. He estado en esto desde que Pokémon Quartz era la novedad; ahora más que nada lurkeo por aquí y en PokéCommunity.

En cuanto a crear, a veces hacía dos o tres cosas sueltas: algún gráfico, alguna corrección o algo sencillo, pero nunca un proyecto entero. Y esa es mi duda: ¿cómo suelen asumir un proyecto de este tipo?

Tengo entendido que se empieza por la idea, luego se diseña la historia, después la estética, se detallan las mecánicas y finalmente se arma un Game Design Document (ya tengo el de mi hack hecho xd), donde queda más o menos “la receta” para hacer el juego.

O al menos eso creo que es hacer un juego. Pero ustedes, ¿en qué orden le entran? ¿Alguien aquí ya terminó algún proyecto? ¿Están trabajando en algo actualmente? ¿Qué flujo de trabajo les ha funcionado?

Lo pregunto porque vengo de una experiencia un poco distinta. Soy muy fan de la saga S.T.A.L.K.E.R., y notaba que había muchos mods buenos en ruso, inglés o ucraniano, pero muy poca gente traduciéndolos al español. A una sola persona podía tomarle meses trabajar en un proyecto mediano.

Así que hice una herramienta para traducir mods: Zonetraductor (juro que no estoy haciendo spam).

La cuestión es que ese proyecto nació de detectar un problema concreto, buscar una solución y crear un flujo de trabajo intuitivo para quienes ya traducían. Y funcionó.

Los fans hispanos empezaron a usarlo y entenderlo. El manual de usuario siempre estuvo disponible, y después fui agregando funciones como traducción asistida por IA, API de DeepL, marcado de frases ya traducidas, guardado de proyectos, resaltado de variables, etc.

A lo que voy: ese proyecto se me hizo relativamente fácil porque sabía qué le faltaba a la comunidad: una herramienta.

Pero con un hackrom siento que es distinto. No necesariamente “falta” algo. La información ya existe, o se aprende sobre la marcha, y el costo de aprender ya está asumido.

Entonces mi pregunta es: cuando crean un hackrom en solitario, ¿por dónde empiezan?

¿Crean primero los gráficos? ¿Van bocetando el mapeado? ¿Usan recursos default mientras implementan mecánicas y luego los reemplazan? ¿Primero hacen una versión jugable básica? ¿En qué orden les ha funcionado trabajar?

No pregunto por proyectos en equipo, porque ahí hay especializaciones y muchas cosas pueden hacerse en paralelo.

Y ya para cerrar: también estoy trabajando en una herramienta para traducir hackroms, tomando como base una herramienta que ya existe y que extrae las cadenas de texto en un CSV.

Gracias por leer, y perdón si me extendí un poco.
Quizás no sea el más indicado para aconsejarte porque no he sacado nada jugable pero igual quería dar mi opinión.

- Lo primero es la idea, una vez tengas claro lo que quieras hacer eliges la plataforma en la que sea viable tú idea o en la que más cómodo te sientas. Aquí te dejo un post que te ayudará en eso Link

Ahora sí vas a hacer un juego con la fórmula clásica de 8 medallas + ligas y tal como en los juegos oficiales puedes saltarte la parte en la que pruebas si tú "fórmula" es divertida.
En el caso de que decidas innovar, recomiendo que pruebes la mecánica principal o eso que hace diferente a tu juego, una vez satisfecho pasa a otros apartados.

Antes de empezar a mapear te recomiendo cambiar los tiles (en caso de que no quieras usar los tileset por defecto) te digo esto porque si haces mapas primero y luego insertar los tiles es muy probable que termines re haciendo todos los mapas y pases el doble de trabajo pero esto hazlo sin caer en el perfeccionismo de el tileset"definitivo" o perfecto.

Después haces los eventos (ojo no quiere decir que sean menos importantes solo que es recomendable por lo menos tener una noción de cómo serán los mapas para que los eventos queden acorde a este)

Y al final te pones a afinar detalles , cambiar gráficos de interfaces y todas esas cosas.

Un consejo muy importante que hasta ahora no aplicaba pero he visto en varios post y me resultó muy útil es que seas constante y dedicar el 80% de tu tiempo dedicado al proyecto en avanzar y el otro 20% a mejorar cosas ya hechas. Quizás esté consejo no te diga cómo hacer el hack/fangame pero si te puede enseñar a no abandonarlo, porque la parte difícil no es saber cómo, si no hacerlo.

Espero haberte ayudado y suerte en tu proyecto!!
 
Última edición:

gameboy_cl

Usuario desconocido
yo creo que no existe una fórmula para empezar un proyecto, pero sí hay varias cosas que al menos he aprendido durante este tiempo.

el desarrollo de un juego nunca es lineal, así que creo que no vale la pena matarse definiendo gráficos o tiles desde el principio. todo eso se puede ir arreglando y modificando sobre la marcha.

para mí, lo más importante es tener bien definido el proyecto, cuáles son sus objetivos, sus límites y qué quieres lograr con él. entendiendo que el tiempo y los recursos son limitados, es importante que el proyecto sea abordable. incluso creo que ayuda mucho tener todo eso escrito, porque en esos momentos de desmotivación o desconcentración puedes volver a leerlo, recordar por qué empezaste y encontrar motivación para seguir.

lo otro que también recomiendo mucho es no trabajar solo ni en el anonimato. compartir el proyecto, conversar sobre él, ya sea en el foro o por rrss con amigxs de la comunidad, ayuda muchísimo a mantenerse inspiradx y a no agobiarse. a veces lo que queda por delante parece una montaña enorme, pero cuando vas compartiendo el proceso y celebrando los pequeños avances, el camino se hace mucho más llevadero.
 

M_Alighieri

Dirigente Total del Imperio Kaktiácero
Miembro del equipo
Redactor/a
Miembro de honor
Puedo hacerme una idea aproximada sobre el tema, con aquel programa estabas cubriendo una necesidad muy concreta, así que encontraste un objetivo sólido y una motivación clara.

Además, el propio desarrollo te mantenía siempre vinculado al software, pero al mismo tiempo te permitía descubrir una faceta nueva de él prácticamente cada día. Todo aquello era un proceso incremental en el que aprender, crear y probar iban de la mano y eso hacía que el interés se retroalimentara constantemente.

En cambio, el desarrollo de ROM hacks y fangames de Pokémon, tal y como lo conocemos hoy en día, en cualquiera de sus plataformas, suele ser un proceso mucho más lineal y multidisciplinar. Hay que tocar un poco de todo: mapas, eventos, gráficos, balance, narrativa, música, programación, y además, normalmente no responde a una necesidad concreta que nadie más esté cubriendo.

Por estos motivos puedo entender perfectamente que no encuentres un gancho tan potente como el que tenías antes y que te resulte más difícil sentarte a trabajar con constancia.

También creo que no existe una fórmula mágica para desarrollar un proyecto de este tipo, sino que depende mucho de qué quieres hacer, de qué es lo que te motiva a ti personalmente e incluso de cómo eres. Y aun con esas, el proceso cambia completamente según la naturaleza del proyecto: no se afronta igual un hack clásico que una experiencia experimental, un proyecto corto que uno enorme, o una historia que una mecánica nueva.

Por ejemplo, en mi caso, intenté hacer varios hacks más tradicionales y lineales, pero como sabía que existían muchos proyectos con esa misma filosofía, acababa perdiendo la motivación. En el fondo, sentía que aunque el resultado pudiera estar bien, no estaba aportando nada que realmente encendiera esa chispa en mi cabeza.

En otras ocasiones, se me ocurrieron ideas para proyectos más pequeños, pero seguía habiendo algo que no terminaba de parecerme lo suficientemente especial o trascendente como para dedicarle meses o años.

Sin embargo, un día, cuando había dejado el foro por última vez y no tenía ninguna intención de hacer otro hack, empecé a jugar con una idea muy sencilla: modificar una mecánica de Pokémon Blue y jugar partidas con ella.

Aquello parecía una tontería sobre el papel, de hecho, todavía me cuesta creer que algo así fuera mi primer proyecto completo, pero cuanto más experimentaba con él, más jugaba, más tiempo me enganchaba y más pequeñas mejoras le agregaba.

Pasé varios años dándole vueltas, probando cosas, apuntando partidas y refinando el concepto. Y así, casi sin darme cuenta, aquella idea, esa "aberración" como la llamo en tono de broma, terminó convirtiéndose en un hack completo que acabé publicando, y la broma no fue para menos... ¡ganó miles de descargas y dos premios!

Por eso te diría que el primer paso no es pensar en un proyecto enorme, sino experimentar. Yo te animaría a probar cosas sin presión, jugar con ideas, romper mecánicas y explorar conceptos que te despierten curiosidad.

Muchas veces el proyecto que realmente consigue engancharte no aparece porque te sientes un día a planificarlo, sino porque una pequeña idea acaba creciendo casi por accidente. Cuando encuentras esa chispa, deja de sentirse como una obligación y empiezas a tener la sensación de que quieres descubrir hasta dónde puede llegar.

Por cierto, la mención a tu herramienta no se siente como publicidad en absoluto, de hecho, te animo a crear un tema y mostrarla cuando quieras.

¡Espero que tengas mucha suerte y consigas alcanzar tu objetivo!
 

Pixwart

Usuario mítico
Yo creo que la mayoría empieza decidiendo que base usar para el hackrom, si binario o decompilación, actualmente se usa más la segunda y con la duda de si usar Rojo Fuego o Esmeralda como juego de base
Si hacer un hackrom fuera como hacer una pizza, elegir la base sería algo tan pequeño pero importante como escoger el tipo y la marca de la harina.

Quizás me equivoco al verlo así, pero es la impresión que me da.

Quizás no sea el más indicado para aconsejarte porque no he sacado nada jugable pero igual quería dar mi opinión.

- Lo primero es la idea, una vez tengas claro lo que quieras hacer eliges la plataforma en la que sea viable tú idea o en la que más cómodo te sientas. Aquí te dejo un post que te ayudará en eso Link

Ahora sí vas a hacer un juego con la fórmula clásica de 8 medallas + ligas y tal como en los juegos oficiales puedes saltarte la parte en la que pruebas si tú "fórmula" es divertida.
En el caso de que decidas innovar, recomiendo que pruebes la mecánica principal o eso que hace diferente a tu juego, una vez satisfecho pasa a otros apartados.

Antes de empezar a mapear te recomiendo cambiar los tiles (en caso de que no quieras usar los tileset por defecto) te digo esto porque si haces mapas primero y luego insertar los tiles es muy probable que termines re haciendo todos los mapas y pases el doble de trabajo pero esto hazlo sin caer en el perfeccionismo de el tileset"definitivo" o perfecto.

Después haces los eventos (ojo no quiere decir que sean menos importantes solo que es recomendable por lo menos tener una noción de cómo serán los mapas para que los eventos queden acorde a este)

Y al final te pones a afinar detalles , cambiar gráficos de interfaces y todas esas cosas.

Un consejo muy importante que hasta ahora no aplicaba pero he visto en varios post y me resultó muy útil es que seas constante y dedicar el 80% de tu tiempo dedicado al proyecto en avanzar y el otro 20% a mejorar cosas ya hechas. Quizás esté consejo no te diga cómo hacer el hack/fangame pero si te puede enseñar a no abandonarlo, porque la parte difícil no es saber cómo, si no hacerlo.

Espero haberte ayudado y suerte en tu proyecto!!
Ándale, justo eso.

Primero implementar la mecánica principal y probarla. Ese consejo del 80/20 me parece muy útil.
Un plan. La clave es tener un plan. Si no tienes una dirección y un plan relativamente factible no llegarás a nada. El plan mutará sobre el tiempo, pero la estructura seguirá ahí. Si no tienes una visión, algo que seguir, no llegará a nada
Qué onda, Jaizu, qué bueno verte por aquí.

Me pesa muchísimo haber perdido aquel sprite de entrenador que me hiciste hace muchos años.

Y a las demás personas que no cité: ya veo que hay muchísimas formas de trabajar, y que sin importar el orden que uno decida seguir, lo importante es la constancia y la disciplina.

O al menos eso es lo que entendí del hilo, hahaha.
 

Corbitto

espantaviejas
te voy a compartir mi método que me ayudo a concretar una beta después de años de proyectos que no llegaban a nada.

1.- hacer una biblia.
básicamente es ya sea en un cuaderno o un archivo de word, escribir todas tus ideas. y cuando digo todas es todas, como va a ser la región, que historia tiene detrás?, que personajes vas a usar?, como es su personalidad?, cual es su pasado?, que pokemon van a tener?, como lucen? todo lo que parezca importante hay que aterrizarlo aquí, y ojo también pon imágenes y dibujos, que no sea solo texto.

2.-hacer una escaleta.
"Una escaleta es una lista de las escenas y secuencias de una historia. Es decir, es algo así como el índice de la película. Un esqueleto o esquema. "
una vez que ya tengas una idea de lo que va a pasar en la historia, haz una lista de los eventos en orden cronológico que van a pasar en tu historia, lo que el jugador va a vivir.
ejemplo.
1: el jugador aparece en su cuarto.
2: el jugador recibe un mensaje de su amigo de la infancia, para que vaya al parque.
3: el jugador sale de su cuarto y su mama le pregunta ¿a donde va?
4: el jugador se dirige al parque donde esta su amigo.
5: el jugador se encuentra con su amigo y este le regala un Pokémon.

esto no solamente te sirve como ayuda en la escritura del guion, si no también como una checklist de lo que has hecho hasta el momento y que será lo próximo que vas a hacer.

3.-guion preliminar.
aquí vas a escribir los textos de los personajes y posiblemente algunas acciones, yo le llamo guion preliminar ya que el guion definitivo son los scripts dentro del código del juego, pero el guion preliminar tiene que estar bien hecho para que funcione de guía para cuando hagas los scripts.

4.- empezar a trabajar en el rom.
lo que recomiendo primero, es hacer un tileset completo, o al menos lo suficiente para empezar a trabajar, luego que lo tengas listo, comenzar a hacer un mapa con ese tileset, y una vez terminado puedes empezar a realizar los scripts.

y eso seria todo mi proceso.
antes de adentrarte recomiendo encarecidamente que aprendas lo básico del método que piensas usar, ya sea decompilado o binario, yo recomendaría mas decompilado, y aprender lo básico, insertar gráficos, hacer tilesets, mapear, hacer scripts, y entender como funciona el código de pokemerald para personalizar tu aventura, cambiar nombres, entrenadores, etc.
 
Arriba