MüchiGame

¡Hola!,
veamos como sería un ejemplo sencillo de los scripts que se usan en el interior del motor del juego en Ajax:
Primero se carga el motor Php ,que genera la interfaz en Ajax y realiza peticiones a los scripts en PERL que al mismo tiempo cargan el contenido de Django por medio de llamadas a sus Urls y al escribir los datos necesarios de la “lógica del servidor” como ficheros XML, se cargan en PHP y se completa el ciclo reescribiendo el contenido en JavaScript, ésto ocurre en cuestión de milisegundos….
Script en perl: carga_jugadores.pl
__________________________
#!/usr/bin/perl -w
use LWP::Simple;
use CGI;
#Si queremos mostrar contenido usariamos: print “Content-type:text/html\n\n”;
my $cgi = new CGI;
#Como posibilidad se puede indicar el tipo de información a pedir a django: $fichero= $cgi->param(’enlace’);
$url = ‘http://www.agenciaq4.com/django/jugadores/’.$cgi->param(’idu’).’/';
my $contenido = get($url);
#Recordemos que podemos usar una expresión regular para evitar problemas de seguridad: $fichero =~ s/\//(php|cgi|pl|html|asp)/g;
open (STUFF, “>/datos/jugadores.xml”); #escribimos el contenido de Django a un XML
print STUFF $contenido;
#Ahora podemos movernos a la direccion del motor de la parte del gestor de contenidos en PHP
print “Status: 302 Moved\nLocation: http://www.agenciaq4.com/muchigame/jugar/jugar.php?modulo=jugadores\n\n”;
__________________________

Para implementar el envío de datos y la recogida de la respuesta en Ajax, utilizaremos Prototype, la forma más sencilla que conozco…
En JavaScript:
__________________________
$(’capaDeInterfazDeUsuario’).innerHTML = generarContenidoPreCargaHTML(’tipoX’);

__________________________
donde idu es el identificador del usuario, para más seguridad se debe incluir una “session id” como parámetro, i.e., la sesión del login en PHP que queda almacenada en la base de datos compartida entre los módulos de apache tanto para Python como para PHP…
Podeis ver algunos ejemplos del uso de éste tipo de llamadas en ésta web http://www.senseidav.com/ ,la hice en un mes de verano del 2oo6.
La parte PHP se encarga de procesar el XML y realizar parte de la lógica del juego, no se si se debería ejecutar el algoritmo A* en Python,en PHP o en JavaScript , quizás a estas alturas estoy hablando chino jaja, espero que alguien haya entendido algo de lo que he escrito, ¿qué opinaís?
Antes de hacer las cosas me gusta pensarlas y hacerlas bien

Saludos…

El gestor de contenidos en PHP y el engine de sonido en JSCRIPT para MüchiGame están listos.
Se puede descargar aquí ( https://forja.rediris.es/frs/shownotes.php?release_id=176 )
La demo se ha actualizado, pero ahora usando el motor de gestor de contenidos directamente desde
http://www.agenciaq4.com/muchigame/jugar/
Para crear una web del marco de aplicación “juego” en PHP necesitamos muy pocas líneas para hacer cosas muy potentes:
______ INICIO (index.php) ______
require_once(’config/config.php’); //La configuración del marco para cargar todo lo necesario..
include_once(’clases/clase_juego.php’); //La clase de la aplicacion web del juego
//en el constructor y separado por comas introducimos las clases que vamos a usar
$app = new juego(crearHtml(),crearNoticias()’);
require_once(DIR_IDIOMA.’index.php’);

//Carga las constantes para el idioma actual (seleccionado automáticamente por la clase juego)
$p = new clase_plantilla($app); //Para cargar una plantilla necesitamos la clase de plantillas
$contenido[’arbol’] = TXT_HOME; //indica la situación actual del árbol de la aplicación web
//La constante TXT_HOME viene definida en config/config.php
$contenido[’titulo’] = TXT_TITULO; //constante definida en el fichero de idioma
$p->cargar(’indice.html’); //carga del directorio de plantillas del idioma actual la plantilla para el indice
$noticia = $app->noticias->leerNoticia( //obtiene la noticia con su identificador en concreto
$app->noticias->ultima_noticia(), //Selecciona la ultima noticia
$app->idioma //El idioma establecido al cargar la clase automáticamente
);
$p->pasarAplantilla(array( //Reemplaza las constantes de la plantilla por sus valores correspondientes
‘DIRECTORIO_IDIOMA’ => SITIO_WEB.”idiomas/”.$app->idioma.”/”,
‘titulo_noticia’ => reconstruye_html($noticia[’titulo_’.$app->idioma]),
‘descripcion_noticia’ => substr(reconstruye_html($noticia[’HTML_’.$app->idioma]),0,250).”…”
));
$contenido[’contenido’]= $p->contenido; //El contenido de la pagina viene a ser todo lo guardado en la plantilla $p
$app->html->escribirContenido($contenido);
//Muestra el contenido de la plantilla por defecto con el contenido actual

______ FIN (index.php)______

Otro ejemplo del potencial del gestor de contenidos es el poder utilizarlo para crear PDF’s con información del juego. En el respositorio se encuetra pdf.php que es un generador de PDF’s con las noticias.

El sentido de éste gestor es separar el código [HTML]—[PHP]—[HTML] de ésta forma, es decir, separar lo más posible php de html y xml,javascript,etc, y hacer que se escriba código de aplicación. De ésta forma, en las capas más internas de la jerarquía web se encontrará el lenguaje SQL (la BD es compartida por Django y el CMS PHP,también accesible por PERL), en las externas el HTML ,JSCRIPT y XML,para operar con ellas usamos PHP y está todo muy bien ordenado.

En cuanto al JavaScript y A*
Haciendo remember y flashback de asignaturas como Modelos de la Inteligencia Artificial, he rescado un viejo algoritmo que se usa en laberintos para robot muy famoso: Algoritmo A*, con éste algoritmo se pueden calcular las rutas óptimas de caminos de un punto a otro de un mapa como el de un videojuego.

Pruebas:
Éstas son algunas de las pruebas para crear escenarios, las celdas pueden sustituirse por otras como:

etc , y formar así un pequeño escenario más “animado”

Con el engine en DHTML sería tan fácil como escribir:
—-
var celda = new muchigame.Celda(”id_celda”, “img/suelo.gif”,x,y,z);
escena.anadirCelda( celda );
—-

Desde aquí ,las posibilidades son ilimitadas, como por ejemplo, cargar en Ajax un evento, y hacer que al pisarse una celda por un jugador se escuche un sonido de una puerta,
if (sprite.x==0 && sprite.y==0)muchigame.manejador_sonido.play(’puerta’);
//Sonido creado con muchigame.manejador_sonido.createSound(’puerta’,’sounds/puerta.mp3′);

Del proyecto no tocaré la parte de Django (por ahora), sé que hay cosas que se pueden arreglar y rediseñar para tener un modelo de datos aún mejor sin embargo lo dejaré como está a día de hoy. He subido al directorio SVN todo el directorio de las aplicaciones (blog, portal y juego) para éste lenguaje como un fichero en download/muchigame_django.tgz : https://forja.rediris.es/websvn/wsvn/muchigame/download/

para que comprobeis como funciona django podeis bajar la aplicación y meterla en un proyecto con “django startproject directorio” ,copiar el directorio “juego” y configurar en directorio/settings.py la aplicación como instalada ( INSTALLED_APPS = ‘directorio.juego’… ) , luego,recordar que necesitamos las rutas a Python antes de usar Django
export PYTHONPATH=”/home/vuestro_directorio_de_proyectos_django/”
export DJANGO_SETTINGS_MODULE=”directorio.settings”
y un “django-admin.py syncdb”  y un “python runserver” tenemos funcionando el administrador…

Comentar sólo que el error que tuve que arreglar fue  del tipo
“UnicodeDecodeError ascii……”
y lo hice parcheando el fichero ” /usr/lib/python2.4/site-packages/_xmlplus/sax/saxutils.py ” reemplazando la linea 188 por ” stream.write(escape(text.decode(’utf-8′), entities))  ” para que se mostrara codificado en UTF8 la información de la BD, django sólo trae la opción para hacerlo desde JSON y había que actualizar la versión para usar una nueva función de hace 5 días para realizar la conversión intelgente a unicode (smart_unicode() de utils ).
Los ficheros XML resultantes de los modelos de datos, con la base de datos del juego rellenada por mi y unos amigos está en el directorio SVN del juego, en https://forja.rediris.es/websvn/wsvn/muchigame/trunk/recursos/media/datos/?rev=0&sc=0  ,todo un alarde de imaginación y creatividad ,jeje…Desde aquí agradezco a David y Alberto su colaboración en el desarrollo final de éste videojuego

¿Cómo hace MüchiGame para pasar el modelo de datos (con lógica de programación o no del juego) a un fichero XML?
Necesitamos utilizar métodos inteligentes para recuperar los datos desde Django, para ello utilizaremos JSON, serializándolos por medio del conjunto de utilidades disponible:
_____________
>>> from django.utils import simplejson
>>> datos = {’nombre’: ‘juax’}
>>> simplejson.dumps(datos)
‘{”nombre”: “juax”}’
>>> datos = [{’nombre’: ‘juax’}, {’nombre’:'eva’}, {’nombre’: ‘nieves’}]
‘[{”nombre”: “juax”}, {”nombre”: “eva”}, {”nombre”:”nieves”}]’
_____________
EJEMPLO UTILIZANDO UNA VISTA:
_____________
from django.utils import simplejson
def json_jugador(request, idjugador):
jugador = Jugador.objects.filter(id=idjugador)
json = simplejson.dumps(jugador)
return HttpResponse(json,mimetype=’application/json’)
_____________
Ahora debemos serializar el resultado, debemos definir la URL (muchigame/juego/urls.py) que llamará a la vista del framework de JSON en Django:
URL:
_____________
(’^json/jugador/(\d+)/$’, views.json_jugador)
_____________

VISTA:
_____________
from django.core.serializers import serialize
def json_jugador(request, idjugador):
jugador = Jugador.objects.filter(id=idjugador)
json = serialize(’json’, jugador)
return HttpResponse(json,mimetype=’application/json’)

y quedaría así:
_____________
[{
“pk”: “1”,
“model”: “muchigame.juego.Jugador”,
“fields”: {
“nombre”: “Juax”,
“f_alta”: “20061105”,
“etc”: “etc”}
}]
_____________
Con ésta pequeña introducción habremos comprendido el funcionamiento del framework para usar AJAX y recibir respuestas rápidas. Veamos como se produce ahora la traducción a XML de los datos…
Igual que antes, primero definimos la URL que usaremos para obtener la información (muchigame/juego/urls.py):
_____________
(’^xml/jugador/(\d+)/$’, views.xml_jugador)
_____________
Evidentemente ahora vamos a declarar la vista como antes:
_____________
from django.core.serializers import serialize #carga la libreria para serializar
def xml_jugador(request, idjugador):
jugador = Jugador.objects.filter(id=idjugador)
#id lo pone por defecto django en la tabla
xml = serialize(’xml’, jugador)
return HttpResponse(xml,mimetype=’application/xml’)
_____________
El resultado obtenido en XML es el siguiente:
_____________




_____________
Si queremos ser aún más elegantes podemos utilizar las vistas genéricas pero éstas no siempre nos ofrecen todo lo que necesitamos:
_____________
from django.views.generic import list_detail
# …
(’^/listar_jugadores/$’, list_detail.object_list,{’queryset’: Jugador.objects.all()})
_____________

* Hasta que no arregle el segundo problemilla de mi host dedicado (que para algo lo pago) no podré utilizar en él Django con Apache, así que me veo obligado a usar datos generados para el simulador del juego en DHTML…

Para que el sistema al completo acepte cualquier lenguaje se utiliza la codificación UTF-8 en todos sitios, me explico:

1. Base de datos con MySQL en UTF-8 ( ver GranadaPHP para conseguir una clase en PHP con el “soporte activado”).
2. Utilizar ficheros, a ser posible,codificados y almacenados en UTF-8 (en los editores) para no llevarse sorpresas en diferentes combinaciones de sistemas operativos / lenguajes…
3. Usar el parámetro de configuración de Apache: "AddDefaultCharset UTF-8" en el fichero .htaccess del directorio web principal.

4. Correos en HTML ( ver la clase de correo en PHP disponible en GranadaPHP )
5. Por último pero no menos importante, hacer que los ficheros HTML,XML,etc. estén en dicha codificación con las etiquetas correspondientes,
   HTML con : <meta http-equiv=“Content-Type” content=“text/html; charset=UTF-8″ />
   y XML con :

Así dispondremos de acentos y carácteres especiales tanto en español como en cualquier otro lenguaje…

Es una maravilla ver cómo el modelo de datos de Django hace tan fácil insertar datos de forma lógica y rápida que sin lugar a dudas merece la pena usarlo.
Veamos la siguiente representación de clases:

En Django (con las sintáxis en Python) quedaría algo como ésto.
Y nos genera todas las relaciones y tablas necesarias de forma que apenas tenemos que hacer nada…

Por supuesto, ésto cambia si hemos de cambiar el modelo de datos, un error común que aún no está solucionado y supondría una gran ventaja para el programador es que Django corrigiera las tablas y el diagrama de entidad relación cuando modificáramos el modelo de datos pero no es así por lo que si hacemos algún cambio tendremos que borrar las tablas que se hubieran creado y estén asociadas a las clases modificadas…
Si todo ha ido bien con Django debería quedar una administración sencilla como ésta:

Podéis observar lo sencillo que es editar el Universo de MüchiGame ahora ya que el motor de Django se encargará de crearnos toda la interfaz. Lo único que es un poco más complicado y largo es la asociación de las celdas a una zona de un mapa concreto que pertenece a una colonia de un mundo…
Entonces el orden de creación de contenido debería ser el siguiente:

1. Crear los administradores y usuarios que modificarán y gestionarán el universo.
2. Crear un mundo
3. Crear una colonia y sus especies ,pueden ser compartidas en otros mundos…
4. Crear zonas y sus razas ,cada especie tiene una habilidad propia al igual que cada raza…
5. Establecer las clases de personajes (mago, guerrero,etc) y sus armaduras y otras características
6. Crear algunas habilidades básicas: hablar,nadar,bola de fuego,etc.
7. Añadir personajes a gusto del usuario…
8. Asociar los Mapas a las zonas
9. Colocar las Celdas en dichos Mapas ,el diseño puede realizarse (o debe hacerse) con una pequeña aplicación AJAX que haga más sencillo y rápido crear dichos mapas para el juego,…aunque más complicado para un servidor
10. Crear personajes: jugadores,npcs (los que nos ayudan) y enemigos
11. Probar los ficheros generados en XML por la interfaz Django (que tomarán los scripts en perl para escribirlos en un directorio temporal)

Por fin tengo la base del motor DHTML ,tras varios meses de investigación y desarrollo tengo el motor DHTML definitivo con vista isométrica, gracias a Francisco Javier Nieto por su “Isometric Game Engine for Javascript & HTML” que he modificado, ahora será realmente sencillo realizar todas las tareas de creación de mapas y el engine es realmente rápido! de hecho he dejado de lado el anterior Wednus DHTML puesto que tenía demasiado código y era más difícil de entender, tras algunos cambios éste MuchiGame Engine basado en el Isometric GE de FJ funciona como esperaba, y cumple las espectativas…

Por otro lado mi servidor no es capaz de arreglar los problema de django… http://www.agenciaq4.com/django/ a unos dias de terminar el plazo…así que me veré obligado a usar los modelos de datos fijos como XML…ésto lo explico un poco más abajo…
_______________________

Mod_python error: "PythonHandler django.core.handlers.modpython"

Traceback (most recent call last):

File "/usr/lib64/python2.3/site-packages/mod_python/apache.py", line 287, in HandlerDispatch
log=debug)

File "/usr/lib64/python2.3/site-packages/mod_python/apache.py", line 454, in import_module
f, p, d = imp.find_module(parts[i], path)

ImportError: No module named core

_______________________
Tras arreglarles yo mismo el primer error...y buscando un poco acerca de éste nuevo error parece que mi host dedicado tiene versiones diferentes instaladas de Python...

El modelo multijugador finalizado (teóricamente):

Los modelos de datos y es algo que aún no he explicado ,se construyen en django como modelos de vistas ,clases genéricas que se pueden administrar fácilmente, dichas clases son la base del juego ,por medio de una interfaz XML se reescriben dichas clases en PHP ,esto se hace usando el paradigma del modelo de programación orientada a aspectos, es decir, para todas las clases existe una base en un fichero .PHP y sobre ésta se crea una nueva que contiene métodos nuevos que se toman de ficheros XML, dichos ficheros XML son generador por el motor de Django, que es donde se encuentra la base de datos del juego en todo momento, la lógica de programación es el punto intermedio entre PHP y Django donde se utilizan scripts en PERL.

Para el modelo de un jugador normal sólo se toman los datos de las clases del juego desde django a xml y se esriben los contenidos de las clases en php y usando javascript podemos movernos por el mundo cargando el contenido que nos va haciendo falta por medio de técnicas AJAX de toda la vida.

Podeis probar:
Demo del Engine DHTML (aún sin AJAX)

Captura del engine

En lugar de usar una conexión persistente se utilizan mecanismos de sincronización entre el servidor y el cliente.

Vemos como sería la simulación usando un “proxy”:

Los objetos quedan a generalizar tendrían la siguiente forma:

Ejemplo del diagrama de paquetes de MüchiGame:

Ejemplo del diagrama de secuencia entre
Cliente

(navegador: HTML+JavaScript+DHTML+AJAX) y

Servidor

(Apache con PHP+Django+Python+Perl+MySQL)

Diagrama de la comunicación del engine de MüchiGame:
diagrama de despliegue

Desarrollo del mundo:

Recordar que los müchis son seres que pueden cambiar de realidad, ésto implica cambios
políticos a otra escala, se refleja en la relación de los mundos.
Para ganar experiencia no sólo se “matan monstruos” sino que existen una serie de misiones
que se van realizando desde una lista de posibles encuentros que hacen cambiar el estado
político del personaje además de sus atributos, i.e., los müchis pueden ser entrenados y
ganar suficiente para comprar objetos que lo modifican…

Diagrama de flujo del juego:

El primero documento de diseño del juego se reduce en un orden producción:
En negrita se muestra el progreso actual del proceso…
Inicio->Parámetros->Concepto->Visión->Diseño del Juego->
Diseño Técnico->Implementación->Primera fase jugable->
Fase Alpha-> Fase Beta->Ciclo de candidata final->
versión 1.0 -> paquete finalizado
Componentes del plan de producción:

en realidad,un plan de producción no lleva flechas pero me he permitido
el lujo de agregar unas flechas en el diagrama para mantener un
orden de la Agenda del proyecto, representa el orden de prioridades…