Pokémon Salvajes en un Nuevo Mapa [pokéruby]

Jason · 24 Ene 2019

Hola, no sabía si poner esto en tutoriales o en investigaciones, supongo que como no es un tutorial sino un poco de info a tener en cuenta a la hora de crear un mapa nuevo en pokéruby (no sé si varíe para otros proyectos) y querer poner nuevos pokémon salvajes.

Siguiendo el tuto de @L!no intenté poner pokémon salvajes para un nuevo mapa, creado con mi tutorial para crear nuevos mapas.

El resultado fue que aparecían missignos y pokémon de la struct siguiente (PetalburgCity_WaterMons), por lo que me puse a pensar en posibilidades mientras me duchaba y se me ocurrió que quizás eran arrays con un largo esperado y el randomizador se pasaba del largo y llegaba al siguiente. Y era correcto. A continuación los hallazgos:

Para pokémon en tierra:

Se espera que el array tenga 12 elementos y el propio randomizador maneja en orden las siguientes ponderaciones:
20%, 20%, 10%, 10%, 10%, 10%, 5%, 5%, 4%, 4%, 1%, 1%.
Por lo que dentro del array, el primero que definan tendrá un 20% de probabilidades de aparecer, el segundo un 20, el tercero un 10 y así.

Para pokémon en agua (surf):

Se espera que el array tenga 5 elementos y el propio randomizador maneja en orden las siguientes ponderaciones:
60%, 30%, 5%, 4%, 1%.

Para pokémon en agua (caña):

Para la caña vieja:
Se espera que el array tenga 2 elementos y maneja las siguientes ponderaciones:
70%, 30%.

Para la caña buena:
Se espera que el array tenga 3 elementos y maneja las siguientes ponderaciones:
60%, 20%, 20%.

Para la súpercaña:
Se espera que el array tenga 5 elementos y maneja las siguientes ponderaciones:
40%, 40%, 15%, 4%, 1%.

Para los pokémon que salen en tierra y agua (surf), los arrays se crean sin mayor inconveniente, mientras que para para los pokémon que se obtienen pescando, los arrays deben seguir la siguiente estructura:
- los primeros dos corresponden a la caña vieja
- los siguientes tres corresponden a la caña buena
- los últimos 5 corresponden a la súpercaña
Sumando un total de 9 elementos al array.

Ahora, cambiando el sistema:
(para cambiar el sistema no se necesita revoluciones -ba dum tss- (lo siento))

Planeo cambiar este sistema y al menos para los pokémon terrestres y acuáticos (surf) no tener que rellenar con el mismo pokémon para evitar esto.
Una idea que tengo es a la estructura de los pokémon salvajes añadirle un atributo que sea "recurrencia" o algo así.
Y para determinar el pokémon salvaje que vaya a aparecer se sume la recurrencia de todos los pokémon de la ruta, y la probabilidad de que aparezca un pokémon en concreto sea poke.recurrencia / recurrencia_total.
Por lo que si quisiéramos tener que poochyena salga con 5 veces más frecuencia que un wurmple, basta con:

Código:

const struct WildPokemon PoochyRuta_LandMons [] =
{
    {2, 3, SPECIES_POOCHYENA, 5},
    {1, 4, SPECIES_WURMPLE, 1},
};

recurrencia_total = 6
prob_poochy = 5/6
prob_wurm = 1/6

¿Qué les parece este sistema?
¿Se les ocurre alguno mejor?

Podría usar la función de C sizeof para evitar pasarme en el largo del arreglo al iterar sobre este.

Kaktus · 24 Ene 2019

Sinceramente el sistema que planteas me parece cuanto menos acertado. Es algo que todos siempre hemos querido implementar en nuestros hacks (o eso creo, al menos por mi parte sí), aunque lo lastimoso es que se perderá la gracia de la poca probabilidad a la hora de conseguir X Pokémon.

Respecto a la información, es genial saber que ya contamos con la capacidad de crear nuevos mapas y además poder añadirles Pokémon de hierba alta, agua, etc. Seguro que resulta útil para proyectos futuros.

¡Buena investigación, espero seguir viendo cosas del estilo!

Jason · 25 Ene 2019

InmortalKaktus dijo:
Aunque lo lastimoso es que se perderá la gracia de la poca probabilidad a la hora de conseguir X Pokémon.

Código:

const struct WildPokemon CampoDeMinas_LandMons [] =
{
    {24, 30, SPECIES_GRAVELER, 30},
    {24, 30, SPECIES_GEODUDE, 30},
    {26, 30, SPECIES_VOLTORB, 30},
    {36, 30, SPECIES_ELECTRODE, 30},
    {23, 28, SPECIES_KOFFING, 30},
    {23, 28, SPECIES_WEEZING, 30},
    {100, 100, SPECIES_DITTO, 1},
};

Con lo que digo, tendrías un 1/180 = 0.000056% de probabilidades de que salga un ditto, y todo el resto de los casos serás víctima de autodestrucción.

Kaktus · 25 Ene 2019

Jasón dijo:
Código:

const struct WildPokemon CampoDeMinas_LandMons [] = { {24, 30, SPECIES_GRAVELER, 30}, {24, 30, SPECIES_GEODUDE, 30}, {26, 30, SPECIES_VOLTORB, 30}, {36, 30, SPECIES_ELECTRODE, 30}, {23, 28, SPECIES_KOFFING, 30}, {23, 28, SPECIES_WEEZING, 30}, {100, 100, SPECIES_DITTO, 1}, };

Con lo que digo, tendrías un 1/180 = 0.000056% de probabilidades de que salga un ditto, y todo el resto de los casos serás víctima de autodestrucción.

Entonces se trata de una excelente investigación. Se me ocurren cosas divertidas, como reemplazar el actual sistema y crear ciertos hábitos, como “bosque”, “ruta corriente”, “ciudad”, entre otros. Y que estos cuenten con Pokémon que se adecuen a dicho hábitat, así haciendo que aparezcan de manera más realista. O quizas, mediante el propio sistema que acabo de decir, coger Y cantidad de Pokes del hábitat para generar el array, y que se randomice con los del respectico hábitat cada cierta cantidad de Pokémon aparecida. Sin duda sería una mecánica que le daría una jugabilidad enorme a los juegos de Pokémon.

L!no · 25 Ene 2019

Debes usar sizeof. La gba trabaja con structs alineados y lo que a ti te parece que deberia medir no es lo que mide realmente. Cito a TONC:

Código:
Tenemos al struct FOO:

Código:

struct FOO { u8 b; u32 w; u16 h; };

Esos son un byte, un half-word ( 2 bytes ) y un word ( 4 bytes ). 1 + 2 + 4 = 7, entonces ocupara 7 bytes, ¿verdad?. Probemos:

Código:

struct FOO foos[4]= { { 0x10, 0x14131211, 0x1615 }, { 0x20, 0x24232221, 0x2625 }, { 0x30, 0x34333231, 0x3635 }, { 0x40, 0x44434241, 0x4645 }, };

Y en memoria:

Código:

10 00 00 00 | 11 12 13 14 | 15 16 00 00 20 00 00 00 | 21 22 23 24 | 25 26 00 00 30 00 00 00 | 31 32 33 34 | 35 36 00 00 40 00 00 00 | 41 42 43 44 | 45 46 00 00

Ummmm... Esos son 12 bytes. No solo es casi el doble, pero si intentas copiarlo usando un 7 en lugar de sizeof, estarias en problemas.

¿Por que sucede esto?
Eso es porque como el struct no esta alineado, C añade bits de relleno para alinear los structs y que las siguientes entradas del array no esten en problemas.

Enviado desde mi SM-G531M mediante Tapatalk

Kaiser de Emperana · 25 Ene 2019

Jasón dijo:
Podría usar la función de C sizeof para evitar pasarme en el largo del arreglo al iterar sobre este.

Eso no va a funcionar, sizeof es distinto de el atributo length de Java/JavaScript/C# o la función len de python.
sizeof funciona en tiempo de compilación, no de ejecución, por lo que no va a funcionar con vectores de largo variable.

Esta código mostraría por pantalla el número 3, porque el tamaño del vector es de 3 bytes:

Código:

void funcionDePrueba() {
    u8 vector [] = {1,2,3};
    printf("%d\n", sizeof(vector));
};

Pero esto mostraría el número 4, porque sizeof no sabe el tamaño del vector que es pasado por parámetro, por lo que da como resultado el tamaño del puntero del vector:

Código:

void subfuncion(u8 vector []) {
    printf("%d\n", sizeof(vector));
}
void funcionDePrueba() {
    u8 vector [] = {1,2,3};
    subfuncion(vector);
};

Para implementar este sistema, deberías guardar el largo de cada uno de los vectores en algún lugar o usar una bandera al final del vector para indicar que el mismo termino (ejemplo, poner siempre al final del vector una entranda con MissingNo.)

-----------------------
Sobre la idea en sí, la verdad la veo un poco innecesaria, me parece mucho trabajo para poco beneficio, pero cada uno tiene su opición xD.

Jason · 26 Ene 2019

Emperor Zell dijo:
Eso no va a funcionar, sizeof es distinto de el atributo length de Java/JavaScript/C# o la función len de python.
sizeof funciona en tiempo de compilación, no de ejecución, por lo que no va a funcionar con vectores de largo variable.

Esta código mostraría por pantalla el número 3, porque el tamaño del vector es de 3 bytes:

Código:

void funcionDePrueba() { u8 vector [] = {1,2,3}; printf("%d\n", sizeof(vector)); };

Pero esto mostraría el número 4, porque sizeof no sabe el tamaño del vector que es pasado por parámetro, por lo que da como resultado el tamaño del puntero del vector:

Código:

void subfuncion(u8 vector []) { printf("%d\n", sizeof(vector)); } void funcionDePrueba() { u8 vector [] = {1,2,3}; subfuncion(vector); };

Para implementar este sistema, deberías guardar el largo de cada uno de los vectores en algún lugar o usar una bandera al final del vector para indicar que el mismo termino (ejemplo, poner siempre al final del vector una entranda con MissingNo.)

-----------------------
Sobre la idea en sí, la verdad la veo un poco innecesaria, me parece mucho trabajo para poco beneficio, pero cada uno tiene su opición xD.

No tenía idea de que sizeof funcionaba de esa forma, muchas gracias!
Voy a hacerlo con el missigno yo creo, es lo que me tiene más sentido.
Muchas gracias, estoy en proceso de aprender C la verdad jaja

Buscar

Pokémon Salvajes en un Nuevo Mapa [pokéruby]

Jason

PkPower déjame poner tildes en mi nick ¬¬

Kaktus

Miembro insignia

Jason

PkPower déjame poner tildes en mi nick ¬¬

Kaktus

Miembro insignia

L!no

GBA Developer

Kaiser de Emperana

Called in hand

Jason

PkPower déjame poner tildes en mi nick ¬¬