Montaje de un servidor de PlaneShift

Como paso necesario para la decisión del motor a utilizar, hemos instalado cada uno de los servidores para realizar una serie de pruebas. Quizá el que más facilidades daba en un principio (por incluir un tutorial extenso y bastante información) ha sido el que más problemas ha dado, PlaneShift, debido a que había algunos datos que no estaban incluidos en el tutorial y que si eran necesarios. Por ello, vamos a explicar de forma general lo incluido en el tutorial, indicando qué pasos son recomendables que no figuren ene ste. El tutorial seguido para instalar PlaneShift y sus compentes puede encontrarse en:

http://planeshift.cvs.sourceforge.net/*checkout*/planeshift/planeshift/docs/compiling.html

En primer lugar debemos descargar una serie de herramientas para la construcción y compilación de las librerías. Las herramientas y versiones requeridas son:

Jam – no especifica versión
libcURL – no especifica versión
SVN – no especifica versión
nVidia Toolkit – 1.5
MySQL – 5.0
WordNet – 2.1

Tras esto, tal y como nos indica el tutorial, deberemos descargar los componentes de PlaneShift, poniendo cuidado a las versiones utilizadas. Las versiones estables soportadas actualmente, que no son las indica el tutorial son las siguientes:

Cal3D – 493
CS – 28424
Cel – 3072
PlaneShift – última versión disponible

Si queremos instalar estas versiones directamente sin tener que bajar una anterior y luego actualizarla, empleamos:

svn co -r 493 svn://svn.gna.org/svn/cal3d/trunk/cal3d cal3d
svn co -r 28424 https://crystal.svn.sourceforge.net/svnroot/crystal/CS/branches/release/V1.2 cs
svn co -r 3072 https://cel.svn.sourceforge.net/svnroot/cel/cel/branches/release/V1.2 cel
svn co https://planeshift.svn.sourceforge.net/svnroot/planeshift/stable planeshift

Una vez hecho esto, antes de compilar nada, debemos acceder al archivo «configure.in» en el directorio «/home/sargas/development/cal3d» y comentar la linea 62 que incluye «AM_USE_UNITTESTCPP». Para esto simplemente escribimos delante «dnl», de forma que quedaría:

ANTES
61 # Check for unittest++
62 AM_USE_UNITTESTCPP

DESPUÉS
61 # Check for unittest++
62 dnl AM_USE_UNITTESTCPP

Tras esto podemos proceder a compilar el código siguiendo el tutorial. Es importante señalar que hay que cambiar la ruta de los directorios que sean necesarios sin seguir al pie de la letra el código del tutorial. Por ejemplo, en la orden

/home/user/development/cal3d$ ./configure –prefix=/home/user/development/cal3d

el directorio y la orden cambiarán dependiendo de dónde estemos instalando el motor. Por ejemplo, para el usuario «pepe»:

/home/pepe/development/cal3d$ ./configure –prefix=/home/pepe/development/cal3d

En el último paso de compilación de PlaneShift es muy importante incluir todo lo que vayamos a necesitar. Por ejemplo, para poder poner en funcionamiento el servidor, es necesario incluir también la orden de compilación de la base de datos de esta manera:

/home/user/development/planeshift$ jam -aq dbmysql server

Tras ejecutar todos los comandos para compilar las herramientas y asignar valores a las variables de entorno, copiamos los ficheros de arte de la forma indicada por el tutorial teniendo siempre en cuenta las condiciones de uso de estos.
Después deberemos crear la base de datos del servidor con las órdenes que se indican en el tutorial. Al menos la orden de start de la base de datos requiere acceso como root.

Una vez hecho esto, ya podremos poner en funcionamiento el servidor de PlaneShift. Es importante indicar que las variables antes exportadas no se guardan entre sesiones, por lo que antes de iniciar el servidor deberemos ajustarlas de nuevo:

export LD_LIBRARY_PATH=/home/pepe/development/cal3d/src/cal3d/.libs/:$LD_LIBRARY_PATH
export CRYSTAL=/home/pepe/development/cs
export CEL=/home/pepe/development/cel
./psserver

Motores: PlaneShift

En nuestro proceso de prueba y análisis de motores hemos elegido como segundo motor de pruebas el perteneciente a PlaneShift. Planeshift es un juego online de temática medieval fantástica con un mundo persistente, cuyo motor gráfico, basado en Crystal Space, representa las acciones en 3D con perspectiva de tercera persona. Su perspectiva y temática incluyen una serie de características (interacción con objetos, niveles o clases, soporte para misiones, hechizos, etc) que pueden ser bastante útiles de cara a implementar varias de las características de Gente Guada.

Los códigos fuente del servidor y el cliente del juego están bajo licencia GPL y pueden ser modificados sin problema, sin embargo todo el material audiovisual (arte, musica, diálogos, historias, modelos, etc) está bajo licencia propietaria y no puede ser empleado. Esto, aunque comprensible, podría retrasar el proyecto al tener que modelar todos los objetos y escenarios de nuevo. En cuanto al soporte, la comunidad de desarrolladores parece estar bastante activa y han elaborado tutoriales sobre el montaje de cliente y servidor, además de algunas características internas. Sin embargo, la reticencia de los desarrolladores a la creación de otros servidores de PlaneShift puede acarrear problemas y retrasar alguna parte del proyecto.

Aunque los gráficos y modelos que incluyen no podrán emplearse en nuestro proyecto, si nos sirven para hacernos una idea del potencial del motor. El motor emplea gráficos 3D en perspectiva isométrica con un corte realista. Los modelos reflejan con bastante fidelidad lo que pretenden representar, y aunque algunos detalles son mejorables, en general tienen bastante calidad.
El juego muestra a nuestro personaje en el centro de la pantalla en perspectiva de tercera persona, sin controles que posibiliten cambiar la posición de la cámara. Además, muestra en la zona superior varios botones con los que poder acceder a ventanas de inventario, registro de quest, libros de hechizos… botones que podrían ser eliminados o modificados para ajustarse a las necesidades de la aplicación. También encontramos en la zona inferior derecha la ventana de chat, la cual puede ocultarse si se desea.

En general el motor cumple la mayoría de los requisitos que buscamos para el proyecto Gente Guada: un motor gráfico que pueda mostrar elementos básicos, sistemas de colisiones, clases o grupos de personajes, sistemas de quest… sin embargo, contamos con los problemas de tener que crear todos los modelos, texturas, sonidos, etc desde cero, y los problemas de soporte que puedan surgir con los desarrolladores.

Motores: Second Life

El primero de los motores analizados son en realidad 2 motores: un motor para el lado servidor del juego (OpenSim), y otro para el lado cliente (SecondLife client). Para aquellos que no lo conozcan, SecondLife es un juego online con un mundo persistente donde el usuario puede interactuar de forma completa con su entorno, ya sea creando objetos, edificios o modificando el terreno de juego. Las acciones a las que tiene acceso el jugador y las opciones para los administradores están totalmente enfocadas a hacer de la interacción con otros jugadores el pilar principal del juego. Algo que casa con la idea central del proyecto Gente Guada.

La parte servidor, OpenSim, es un proyecto colaborativo en código abierto que trata de crear un programa servidor para Second Life. Aunque a primera vista parece encontrarse en una fase temprana de desarrollo, un vistazo al listado de actualizaciones y a la comunidad de desarrolladores lo desmienten. Problemas que nos hemos encontrado durante las pruebas han sido solucionado al poco tiempo de descubrirse, y las mejoras y arreglos parecen surgir a pasos agigantados. Este proyecto no intenta crear tan solo una copia del servidor de Second Life, sino modificarlo para darle la posibilidad de adaptar nuevas tecnologías al programa a medida que estas van surgiendo.

Por el lado del cliente nos encontramos con el cliente de Second Life portado a linux por los propios desarrolladores del juego. Actualmente se encuentra en una fase alpha y parece que el proyecto dista de llegar a una fase estable. Sin embargo, el hecho de contar con el equipo de Second Life como desarrolladores hace que el cliente sea más robusto de lo que debería ser una versión de este tipo, además de saber que existe una base sólida de código sobre el que trabajar.
En cuanto a su aspecto, este cliente muestra el mundo de Second Life exactamente igual que el cliente para Windows original. Es decir, un entorno 3D en perspectiva de tercera persona, modelado de forma realista, con un entorno que incluye controles sencillos y trata de ser accesible, buscando la simplicidad y el acceso facil antes que el preciosismo gráfico.

El conjunto de motores cliente y servidor no está tan desarrollado como sería deseable, aunque el hecho de contar con una base de desarrolladores tan fuerte lo compensa en parte. En cuanto a su funcionamiento, como mencioné antes, el juego está orientado en todos sus aspectos a que los jugadores interactuen entre si y formen comunidades, de forma que facilita bastante la creación del tipo de juego que es Gente Guada. En general, se adapta bastante a los requisitos que buscamos para un motor, aunque todavía está por ver si su estado de desarrollo junto con la comunidad que hay detrás supone una ventaja o un problema.

Escogiendo un motor

Una de las primeras tareas en el proceso de creación de un videojuego, y quizá una de las más importantes, es la de elegir un motor sobre el que plasmar las ideas y los contenidos. A menudo surge la duda de qué es mejor: crear un nuevo motor desde cero, ajustándolo a las necesidades del proyecto pero invirtiendo gran cantidad de tiempo, o emplear un motor ya existente, limitando las posibilidades de desarrollo pero eliminando el tiempo de creación, La elección entre uno y otro modelo suele depender del tipo de proyecto a desarrollar y del tiempo disponible y suele limitarse a estas dos opciones, a menos que recurramos a motores de código abierto. Estos permiten una tercera opción: partir de un motor ya creado o en desarrollo y adaptarlo a nuestras necesidades, usando las partes que sean adecuadas y modificando las que no.

Esta tercera opción es precisamente la elegida en el proyecto Gente Guada. Actualmente nos encontramos analizando varios motores, probando sus funcionalidades y anotando qué partes se ajustan más a las necesidades del proyecto y qué partes deberían ser modificadas. Las características de estos motores varían mucho entre si, teniendo motores 2D o 3D, isométricos o en tercera persona, innovadores o consolidados, etc. Dentro de poco os iremos contando nuestras primeras impresiones y las características principales de cada uno de ellos. Estad atentos.