Generador De Mapas A Partir De Un Número

[Zaelsius]

 Ah sólo el terreno.. ok.. entonces creo que la solución que ha propuesto Tamat(la del Perlin Noise) es la más idónea, es decir, usar un valor númerico o cadena como semilla para la generación de la textura de ruido.

[Pogacha]

 Bien, entonses lo que quieres crear es mapa a partir de una semilla, Matizo te proponina esto con pseudo-azar, si usas la misma semilla se generara el mismo mapa en cualquier ordenador y cada vez.
Como generar un mapa con una semilla ... eso depende de las reglas del juego, tienes que usar un sistema como por ejemplo:

Código [Seleccionar] Expand

randomize(Semilla);  // incicializa el generador de numeros pseudo-aleatoreos (no se como se escribe ) !Mars!!!!
for x
 for y
{
   tile[x][y]=(random() % 5); // de 0 a 4 el codigo del textura
   if(x < XMAX-1 && tile[x+1][y]==tile[x][y]) tile[x][y]++; // por ejemplo para que no halla dos casillas continuas iguales.
}
Entonces generas con pseudo-azar y despues corriges en el mismo o en otro bucle o con una funcion rara segun las reglas de mapas validos.

No se me ocurre algo mas rebuscado a tu pregunta.
saludos

[Warchief]

 Saludos, apunto de terminar la fase de diseño sigo con el problema (que por otro lado me parece un poco más cercano a implementación).

Por partes:

Los números de Gödel no me terminan de convencer. Debe de ser que no los entiendo  (nooo) . El caso es que me puse a pensar y resulta que sólo me sirven como transformación de números grandes a pequeños (en el ejemplo de Zaelsius 1451 <-> 3543750). Sin embargo, me he dado cuenta que esto no soluciona el problema, ya que los números generados por las secuencias de 0 a 1450 son exactamente 1451 números. Esto quiere decir que sigo teniendo 1451 mapas, no 3543750 como había yo pensado en un principio.

El tema de las series también me parecía interesante, pero el número de casillas a considerar (grupos de casillas codificadas en series) era demasiado grande respecto al número de combinaciones (series) codificadas.

Finalmente, hacer el documento de diseño mientras trabajaba esta situación de los mapas me ha revelado que 100x100 es una locura! Necesito un juego rápido, que prefieras jugar muchas partidas a jugar 1 partida de 2 días de duración. Joerz que el ajedrez es 8x8 y da un juego increíble (se juega desde hace siglos XDD). El Battle Masters, origen de mi juego, tenía un tablero de 12 x 12 y se hacía eterno! Así que he optado por reducir y reducir y reducir las casillas hasta quedarme con sólo 16x16. (Siempre se puede ampliar y generar los mapas de otra forma, versión 2.0  :rolleyes: ).

El caso es que si codifico los mapas con letras(26) + números(10) + caracteres ,;.:-_@#$% (10) el problema se me queda en:

Código [Seleccionar] Expand


VR 46,n >= VR 5, 256     donde

VR = Variaciones con repetición
n = caracteres necesarios para codificar
46 = letras + nums + cars
5 = tipos de terreno (pensé reducirlos a 4)
256 = 16x16

----->
--> 46^n >= 5^256
--> n log 46 >= 256 log 5
--> n >= 256 (log5/log46) ~= 107.62
--> n = 163 caracteres !!


He desestimado la opción del generador de números aleatorios, ya que la semilla debería ser del tamaño de 5^256, que según windows calc ™ 5^256 = 8,6361685550944446253863518628004e+178. Así que, bueno, sigo estrujándome la cabeza, pero creo que esta característica del juego se va a tener que quedar en el borrador. Aún así, creo que generaré los mapas con esos 163 caracteres. Creo que no es posible hacer que el jugador recuerde eso, ni siquiera inventandome "n"  dibujitos (n >>> 46), uhm, que creo que es la única idea que me queda.
Algún invento se podría hacer como por ejemplo

Código [Seleccionar] Expand


semilla(num1)
semilla(rand*num2)
semilla(rand*num3)
rand...

Creo que desvarío.

Aún no he podido mirarme lo del perlin, ya que la opción de encontrar una función inversa la olvido completamente y el perlin puede serme útil. El problema es que luego no sabré cómo generar un mapa concreto, y tendré que jugar mapas llenos de áreas rarararaarraarararraas XDD

[Pogacha]

 Te juro por dios que no te entiendo!!! (nooo)
Quieres generar un mapa al azar o comprimir un mapa editable?
Hablo de mapa como un Tablero de 16 x 16 con 5 valores posibles o
sea 256 *3 bits (0..8) = 738 bytes comprimidos con suerte seran 30 bytes lo cual es imposible de memorizar.
A no ser que tengas reglas claras de mapas validos y no validos.
Los mejores compresores genericos hacen 4 a 1 los que conocen casi todo y con perdidas logran 10 a 1 así que es casi imposible que lo reduzcas a 8 caracteres que es lo maximo que alguien anotaria en un papel.
Po otro lado:

la semilla debería ser del tamaño de 5^256

Por que? :blink:

El problema es que luego no sabré cómo generar un mapa concreto, y tendré que jugar mapas llenos de áreas rarararaarraarararraas

No  !!, generas al azar y luego arreglas el mapa segun siertas reglas como por ejemplo : nunca dos montañas juntas o cosas así.
Saludos

[rafaware]

 Una sugerencia....

Y por que en vez de memorizar un número, memorizas una serie de caracteres. Con los calculos de Pogacha 30 bytes es un numero muuuuy largo dificil de memorizar. Pero una cadena de 6 caracteres (letras y numeros ) a razon de 5 bytes por caracter (5^2= 32 = 22 letras y 10 numeros) es mucho más comodo. Incluso puedes subir la información guardada a 50 bytes o más...

rafa

[Warchief]

 Jeje, a ver si me explico.
No quiero generar mapas aleatorios. Quiero generar todo el espacio de mapas generables para el tablero de NxM con 5 tipos de terreno por casilla. Es decir, que si las dimensiones fueran de 3x1 con 2 tipos de terreno (A y B), querría los mapas:
AAA AAB ABA BAA ABB BAB BBA BBB
Las combinaciones totales de mapa resultan de la forma: VR j,k donde VR = variaciones con repetición, j és el número de tipos de terreno, k es el número de casillas. Para el ejemplo VR2,3 = 2^3 = 8.

Cuando mis dimensiones son 16x16 = 256 casillas, y 5 tipos de terreno -> VR 5,256 = 5^256. Que no importa si están codificados en bits o como sea, pero es el número de mapas generables.

Sin embargo, es cierto que con este cálculo se numeran los mapas, que me parecía al principio una gran opción.  Al ver la idea de Pogacha de los bits y mezcándola con la idea de sheph de las series , se me ha ocurrido una idea bastante interesante:

Código [Seleccionar] Expand


Para cada casilla:
0 Si no varía con respecto al anterior
1 Si varía
Al encontrar un 1, se pone entonces el código de la variación (2 bits)

De forma que el código de variación depende del tipo actual
Llano Camino Bosque Montaña Agua
  X       00          01         10         11
 00        X          01         10         11
 00      01           X          ... etc.

En el mejor de los casos (cuando todas las casillas son iguales) el número de bits necesarios será de 256 + 2 bits (si no es llano) o 256 (si es llano).

En el peor de los casos (cuando cada casilla es distinta de la anterior) el número de bits necesarios será de 768 (3 bits por casilla).

De esta forma, además, se premia los mapas que tienen filas de casillas del mismo tipo.

Estoy pensando alguna mejora, como que se tenga en cuenta las casillas Norte y Oeste, en vez de sólo la Oeste, pero creo que es quebrarme ya demasiado. Al fin y al cabo, los mapas los voy a querer yo utilizar para entrenar la IA. Creo que voy a tirar por este lugar.

Alguien tiene alguna megaidea o ve problemas a este planteamiento?



Gracias por dedicarle unos minutos a pensar conmigo  (ole)

NOTA:
En el Freecell hay 52 cartas. En este caso el número de combinaciones es de P52 = V52,52 = 52! y sin embargo sólo te deja escoger del 1 al 1 millón. Supongo que se cargaron algunas combinaciones.

[Pogacha]

 Creo que no entiendes el concepto de compresion:

Si hay 5 ^ 256 mapas distintos no hay forma alguna de que ocupes menos de 5 ^ 256 codigos distintos en describirlos ( regla del trabajo y energia, se estudia en fisica pero se aplica de la misma manera aquí :P ), pero lo que puedes hacer es, asignar codigos pequeños a los mapas mas probables y codigos grandes a los menos problables, de esta manera tendras longitud de codigos variables y para mapas sencillos tendras de cadenas de caracteres cortas y para los que no deberian ocurrir serán los mapas de codigos de mayor extension, esto se puede optimizar como hace el huffman, pero se hace dificil encontrar el algoritmo de encriptación, lo que se suele hacer es una euristica como se me puede ocurrir: una biblioteca de tabals de 4x4 con las 256 formas mas comunes para cada lugar y de esta manera reduces la tabla de 16x16 a 16 numeros de 0-255, mas las diferencias que pueda tener con el original, estas diferencias seran comprimidas con run code lenght, de esta manera tendras una compresion aceptable, quisas de 20 o 30 caracteres para los mapas mas comunes y de  10^256 para los mas raros.

Entonces el algoritmo de compresion se vuelve:

Código [Seleccionar] Expand

Para cada fragmento de la entrada
  Salida[0..3][0..3] = buscar el mas parecido()

Por cada casilla
 Diferencia[numero de diferencias++] = Bibliotecas[fragmento,  Salida[0..3][0..3]] - original[Casilla]

Comprimir Diferencia con run code lenght

Encriptar la salida y el diferencias en un numero

y el de descompresion seria

Código [Seleccionar] Expand

Desencriptar el codigo de entrada en tabla de entrada y diferencias;

Expandir diferencias

Crear final con las bibliotecas segun  tabla de entrada.

Agregar diferencias.

Ejemplo de las tablas:

Código [Seleccionar] Expand

0:        
MMMA
AMAA
AAAA
CCCC

1:        
MMMA
AMAA
AMAA
MMMM

2:        
CCCC
CRRR
CRRR
CCCC

3:        
AAAA
AAAA
CCCC
CCCC

[Warchief]

 Que al final se necesitan 5^256 códigos esta claro, de ahí que no fuera capaz de pensar en un generador de números pseudoaletorios con semilla tan grande.

QUOTE ("pogacha")

lo que puedes hacer es, asignar codigos pequeños a los mapas mas probables y codigos grandes a los menos problables, de esta manera tendras longitud de codigos variables y para mapas sencillos tendras de cadenas de caracteres cortas [/quote] Esa era la idea del código que puse en el mensaje anterior. Una mejora un poco menos ambiciosa que lo que me has propuesto. Hoy he estado hablando del tema con mi tutor del proyecto, y al final hemos decido descartar la opción del código. Finalmente la solución pasará por un txt donde se dibuje el mapa en ascii, como siempre (la decisión se puede tomar ahora que hemos decidido 16x16, porque con dimensiones mayores sería un poco costoso :D). Código [Seleccionar] Expand LLLLLLLL LLLBBBLL LLLBBLLL LLLBLLLL etc. Así puedo añadir otra información al mapa como los "centros de mando" colocados en algún lugar concreto, etc. Siempre tendré tiempo de volver a retomar estos cálculos para hacer un editor de mapas que guarde los mapas en un formato comprimido no legible. Gracias por vuestros comentarios, la idea del código recordable no era factible me temo (aunque sigo pensando que la idea de hacer miles de dibujitos cambiando a palabras podría tener futuro, por ejemplo: perro-gato-despertador-mechero-alfombra sería bastante fácil de recordar y da pie a tener miles de palabras). --> Para 10K palabras (sacadas del drae) --> 10000^n >= 5^256 --> n log 10000 >= 256 log 5 --> n >= 256 (log5/log10000) ~= 44.73 --> n = sólo 45 palabras !!  (ole) La otra cuestión es hacer como el Freecell, que sólo ofrece 1M combinaciones de las 52! que hay. Pero bueno, eso es ya otra historia. En fin, olvidemos lo del código. Gracias por las ideas. Imprimir Ir Arriba Páginas 1 2 User actions Foros - Stratos Programadores General Programadores (Moderador: [EX3]) Generador De Mapas A Partir De Un Número User actions Imprimir Ayuda | Ir Arriba ▲ SMF 2.1.4 | SMF © 2013, Simple Machines Síguenos en Aviso legal Tratamiento de datos Seguridad Cookies © 2024 Stratos Stratos es un servicio gratuito, cuyos costes se cubren en parte con la publicidad. Por favor, desactiva el bloqueador de anuncios en esta web para ayudar a que siga adelante. Muchísimas gracias.