Teoría y Fundamento de Ampliación de Informátic

Pasados los exámenes doy comienzo a la segunda temporada de entradas relacionadas con el proyecto que tengo entre manos desde hace un tiempo. Recuerdo que se trata de crear un juego, al estilo mmorpg pero utilizando los recursos disponibles para un estudiante.

Esta entrada describe uno de los nuevos avances que he incluido, implementar un cliente telnet para conectarnos al MUD y jugar con la mayor comodidad posible.

Antes de nada, os recuerdo que el mundo se basaba en un sistema GIS de varias capas. La capa geográfica tenía un aspecto como este:

Lógicamente no podía utilizar un mapa tan cutre para crear mi mundo. Me puse manos a la obra con Photoshop CS3 y conseguí algo que ya tiene mejor pinta. El resultado es el siguiente:

En cuanto al cliente, con .NET es muy fácil crear un cliente telnet, y existen multitud de ejemplos por internet que te enseñan cómo hacerlo en menos de cinco minutos. Le he puesto infinidad de utilidades que los clientes integrados en el sistema operativo no tienen: macros, alias, triggers, historial de comandos, loggeador… Sin embargo, he pensado que no es suficiente.

Si bien es cierto que este juego tendría gran número de jugadores con discapacidad visual (las personas invidentes no pueden jugar a World of Warcraft, pero un lector de pantalla les permite leer lo que el MUD envía), el resto de jugadores si agradecerían poder visualizar de un vistazo en qué punto del mapa se encuentran en cada momento, y utilizar un gestor de mapa que les permita ver el continente entero y saber donde están. Esto es relativamente sencillo, así que lo he implementado y este es el resultado:

Los jugadores se mueven por el mundo y el cliente captura las coordenadas en las que se encuentra el jugador. Dependiendo de las coordenadas, dibuja un círculo en el mapa y centra su visualización en ese punto.

¿Qué podría ser lo siguiente? ¿Que los jugadores puedan visualizar la posición de sus compañeros de grupo? ¿Que el jugador pueda seleccionar el punto del mapa al que quiere ir y vaya automáticamente?

Continuará…

En este capítulo (quizá el último de la temporada) os voy a introducir en una de las tecnologías más importantes que he incluido en el proyecto. Intentaré reducirlo lo máximo posible.

Actualmente si queremos modificar nuestro juego (añadir una nueva capa a nuestro sistema GIS o queremos agregar un comando a los usuarios) tenemos que añadir el código oportuno a la aplicación, compilar de nuevo el MUD, parar la actual ejecución y lanzar el nuevo MUD compilado, haciendo reconectar a los jugadores. Si tenemos a un centenar de usuarios y todos los días se añade contenido al juego al final acabarán quemados de tener que salir y entrar cada media hora a causa de los reinicios del MUD.

Partiendo de ese problema sería ideal que nuestro MUD fuese capaz de interpretar el nuevo código que queramos añadirle sin necesidad de ser recompilado. De esta forma, si quisiéramos añadirle una espada nueva, sólo tendríamos que añadirle el código necesario (txt, xml, cs, …) y el MUD lo añadiría sin reiniciarse. Para eso se inventaron los lenguajes de scripts, para programar las aplicaciones una vez ya han sido publicadas. Ejemplos de aplicaciones que aceptan nuevo código sin ser recompiladas: Mozilla Firefox con sus plugins, Word of Warcraft con sus addons…

¿Y cuál es el mejor lenguaje de script para una aplicación escrita en C#? Pues ni Ruby, ni Lua; el mejor lenguaje de script es C#. Efectivamente, tú desde una aplicación escrita en .NET puedes llamar al compilador de .NET, pedirle que te compile un código fuente y que te devuelva el ensamblado para instanciar de ahí objetos, todo eso en tiempo de ejecución.

Llegar a ese punto ha sido un hito impensable para el proyecto. Los usuarios ahora pueden conectarse al MUD, crear archivos de texto y decirles al propio juego que los compile y los ejecute. He creado un juego donde los usuarios pueden desarrollarlo. Las posibilidades son infinitas. El mundo ya no es cerrado y discreto, sino que adopta la forma que el usuario cree.

Como si de 2001: Odisea del espacio se tratase, la aplicación supone el monolito, la herramienta necesaria para que la vida comience a evolucionar dentro de ese mundo. Podría lanzar la chispa vital al universo y no me puedo imaginar la de formas de vida diferentes que podrían adoptar.

Cada planeta estaría formado por los cientos de archivos que lo definen, pero mi programa en esencia sería ahora más que nunca unas pocas líneas de código. Podríamos tener cientos de juegos diferentes, y sólo habría que colocar junto al ejecutable los archivos de código que lo modifican para tener un juego u otro.

Si tuvieseis en vuestras manos un entorno sobre el que vuestros amigos pueden conectarse y desarrollarlo entre todos, ¿Qué harías en primer lugar? ¿Y si programásemos, en primer lugar, una interfaz que facilitase al resto de programadores desarrollar el mundo? ¿Implementarías los mapas densos? ¿Y si, en un futuro, permitiésemos que los jugadores pudiesen programar sus propias casas, objetos, profesiones ofreciéndoles la posibilidad de llamar al compilador de .NET…? ¿Estaríamos preparados para ello?

Continuará la próxima temporada…

En mi quinto artículo sobre este cautivador proyecto voy a volver a hablaros sobre el diseño del mundo. Días atrás apenas esbocé un concepto que va a dar, como vereis, muchísimo de qué hablar. Hoy vamos a ver como nuestra idea de “mapa denso” nos va a permitir crear un Sistema de Información Geográfica.

Para recordar un poco lo que escribí en el artículo anterior y de paso introduciros en el nuevo concepto que nos concierne hoy voy a utilizar una imagen de un supuesto mundo. El MUD se encargaría de leer pixel a pixel y generar, dependiendo del color del pixel, una sala de un tipo u otro. En este caso hemos utilizado una imagen de 500×500; por tanto tenemos 250 000 salas diferentes.

Este concepto es revolucionario, pero tiene sus limitaciones. Imaginemos que un jugador está visitando un bosque del norte del continente, y al mismo tiempo otro jugador recorre los bosques del sur. Ambos recorren bosques, con el mismo clima; aparentemente son iguales, y si un tercer jugador fuese capaz de ver a través de los ojos de los dos jugadores no sabría en que parte del continente están.

Por suerte, allá en el norte llueve mucho y los pinos son todos de la familia de los pinus halepensis, y en el sur crece el almeriense pinus pinea. Mostrarle al jugador el tipo de árbol que crece junto a él le permitiría conocer en qué zona del continente está. Pero, ¿cómo debería el MUD saber que está instanciando una sala de tipo bosque que se encuentra en una zona donde crece un determinado tipo de pino?

Existen varias posibilidades, entre las que destaca utilizar las coordenadas del pixel para decidir en qué zona del continente está. Podríamos, por ejemplo, dividir el continente en cuadrantes. Sin embargo, esa alternativa no nos permitiría hacer una zona irregular, flexible, y todas serían cuadradas. Esta alternativa no nos vale.

¿Y si quisiéramos además que el clima cambiase en nuestro entorno? Queremos que llueva; pero con consistencia. No queremos helarnos, movernos al sur, freírnos al sol, movernos de nuevo al sur y que esté lloviendo. Necesitamos un método que nos permita cambiar el clima en zonas completas del mapa. Pero de nuevo, no podemos dividir el mapa en cuadrados, ni círculos ni todo lo que se parezca a un polígono.

Pues de estos dos problemas surge la idea del GIS. Podemos utilizar varias imágenes superpuestas para dar mayor profundidad a la información de cada sala.

Esto que veis a continuación es el un mapa climatológico que podría utilizarse superponiéndolo sobre el mapa geográfico.

Este es el resultado de superponer ambos mapas. Parece el mapa del tiempo del telediario

Y ahora, ¿y si ampliamos esa idea a más capas de información? ¿Cuántas podemos añadir? Las que queramos. Y a continuación os pongo un ejemplo de un futurible sistema GIS para un mundo donde las diferentes facciones pueden conquistar terrenos enemigos.

Las posibilidades son enormes y sólo hay que dejar volar un poco la imaginación para darse cuenta de la cantidad de cosas que podrían crearse de esta manera.

Continuará…

Hoy me gustaría hablaros sobre el mundo que he creado, el planeta donde los seres viven e interactúan entre ellos.

Actualmente los MUDs utilizan un sistema bastante sencillo. El mundo está formado por salas, que se caracterizan por ser únicas, tener un nombre, una descripción y una serie de salidas que apuntan a otras salas. En una sala puede haber objetos y seres vivos. Cada sala se programa con un archivo de texto o con código que es compilado junto al servidor. El aspecto que puede tener el mapa de un MUD bastante desarrollado puede ser como este:

Ahí podéis ver una ciudad (caracterizada por su muralla) y varios caminos que recorren el exterior de la fortaleza. Ese sistema es sencillo de desarrollar, pero muy difícil de mantener. Si cada sala es un archivo, ¿cómo harías para que todos los bosques se pudiesen talar? ¿Y si quieres cambiarle el nombre a un grupo de salas? ¿Y si decidieseis añadir una zona nueva? Tendríamos que estar jugando con un sistema de archivos. ¿Cuántas salas seríamos capaces de crear a largo plazo, 5000?

¿Por qué no aprovechar el potencial de la orientación a objetos y utilizar una imagen para generar instancias de salas en tiempo de ejecución?

Pues esa idea la he implementado, y este es un ejemplo de un mapa de una zona del MUD.

Ahora el mundo es denso, y todos los movimientos están permitidos. Ahora los accidentes geográficos son reales; y los ríos deben ser cruzados por puentes. Existen bosques, playas, desiertos y cumbres cubiertas de nieve. Las salas tienen unas coordenadas y por tanto podemos utilizarlas para calcular cosas impresionantes como la climatología. El mantenimiento es instantáneo, pues sólo hay que tocar el generador de salas para que todas queden actualizadas. Sólo existe un archivo de sala, y se instancian de él todas las salas.

En esa imagen se pueden ver aproximadamente 100 filas de salas por 100 columnas de salas. Estamos hablando de 10.000 salas en solo un trozo de mapa. Pero… ¿y si os enseño todo el mapa del continente?

Ese continente tiene unas dimensiones de 600×600, lo que suponen 360.000 salas. Los datos son espeluznantes. El mundo lo ha generado una imagen de 600×600 que no creo supere los 200kBs de espacio en memoria.

Pero… ¿y si creamos varios continentes?

¿Sois capaces de imaginar la inmensidad del mundo que he creado? A mi aun me cuesta…

Continuará…

Como si fuese un Dios, he creado un mundo donde la vida abunda y el tiempo pasa. El sol se sale por el este y se pone por el oeste. Las criaturas pastan por los campos y los depredadores esperan su oportunidad.

Ahora varios usuarios pueden adentrarse en el mundo, moverse e interactuar entre ellos, mirarse, hablarse… también pueden interactuar con los otros seres que pueblan el mundo de Inlumine (así lo he llamado). La inmensidad crece ante los jugadores.

Lobos, ciervos, ardillas… ¿cuál será el siguiente pasó?

Continuara…