Comunicación entre tu móvil Android y tu PC con Linux (ADB)

En algunas de mis anteriores entradas hablaba sobre la conexión entre tu dispositivo móvil y el ordenador para poder comprobar en tiempo real todos tus progresos en el desarrollo de tus aplicaciones Android. Hoy intentaré entrar en detalle en los entresijos de este proceso para Linux.

La principal herramienta de comunicación entre ambos dispositivos es ADB (Android Debug Bridge) que permite lanzar comandos y gestionar archivos o aplicaciones en tu móvil. Esta herramienta se encuentra normalmente disponible dentro de los repositorios de las principales distribuciones Linux. Sin embargo, os aconsejo que la descargueis manualmente como parte del sistema de desarrollo de Android (Android SDK) para tener un mayor control y evitar problemas de comunicación con tu dispositivo¹.

1. ¿Cumplimos los requisitos?

Lo primero de todo es asegurarnos de tener instalado en nuestro sistema JDK (Java Development Kit). También puedes probar si funciona OpenJDK, aunque no está soportado oficialmente para el desarrollo de Android.

Para instalar JDK tendrás que asegurarte de que las listas de tus repositorios incluyan los “non-free”. Puedes comprobarlo en tu gestor de paquetes (Synaptic, Aptitude, etc.) o hacerlo mediante consola editando el archivo sources.list. Para Debian:

su
gedit /etc/apt/sources.list

Esto abrirá el archivo "sources.list" con tu editor de texto (en este caso gedit). Ahora, añade esta línea al final:

deb http://http.us.debian.org/debian stable main contrib non-free




Guarda el archivo y ejecuta los siguientes comandos para actualizar la lista de repositorios e instalar JDK:

apt-get update
apt-get install sun-java6-jdk

Más adelante, al ejecutar la herramienta SDK de Android, comprobaremos si existe algún problema de dependencias con las librerías de 32 bits en nuestro sistema. En caso afirmativo, será cuestión de identificarlas e instalarlas con nuestro gestor de paquetes.

2. ¿Cómo instalar la herramienta de desarrollo de Android?

Una vez se haya completado la descarga de Android SDK, procederemos a descomprimir los archivos y almacenarlos en tu directorio de trabajo (o en tu “home” si lo prefieres). Dentro de la carpeta “tools” comprobamos que el archivo “Android” tenga los permisos adecuados para poder ser lanzado (Pulsamos con el botón secundario y en la opción “Permisos” activamos “permitir ejecutar el archivo como un programa”).

Ahora, abre una terminal dentro de la carpeta donde se encuentra el ejecutable y  ejecuta:  

./Android

Al ejecutarlo a través de una terminal podemos comprobar si existe algún fallo o problema de dependencias. Si es así, toma nota de las librerías que te faltan e instálalas.
Una vez abierto, seleccionaremos a la opción “Available Packages” e instalaremos los paquetes que se encuentran seleccionados para actualizar tras aceptar sus correspondientes licencias. Cierra el programa una vez finalicen las actualizaciones.

3. ¿Cómo reconoce el PC a nuestro dispositivo móvil?

A continuación, vamos a establecer unas “reglas” para que el sistema reconozca nuestro dispositivo conectado mediante un cable USB². Para ello, primero crearemos un archivo llamado “51-android.rules” con permisos de superusuario (su o sudo):

su
gedit /etc/udev/rules.d/51-android.rules

Con esto se crearía ese archivo y se abriría el editor de texto Gedit para editarlo. Si utilizáis cualquier otro editor de texto, cambiar “gedit” por el nombre de vuestro editor de texto (nano, vim, kate, etc.). Ahora añade la siguiente línea, aunque no cierres tu editor todavía, ya que toca personalizarla en función de tu modelo de móvil y usuario de sistema:

SUBSYSTEM==”usb”, ENV{DEVTYPE}==”usb_device”, ATTRS{idVendor}==”0bb4″, MODE=”0666″

El atributo “idVendor” es distinto para cada fabricante de móviles, así que debes utilizar el que se corresponda a tu dispositivo según la tabla que aparece al final de esta página. Si el fabricante de tu móvil no se encuentra en ella, puedes averiguarlo mediante el comando “lsusb” que nos proporciona un listado de los dispositivos usb conectados en tu ordenador. Localiza la línea que corresponda a tu dispositivo y en el apartado ID tienes dos cuartetos de números: el primero corresponde al “idVendor” y el segundo al modelo:

lsusb
Bus 003 Device 005: ID 0bb4:0c03 HTC (High Tech Computer Corp.)

En este ejemplo el idVendor es 0bb4 que corresponde a un HTC (o también Jiayu).

En el caso de Debian te tocará configurar dos cositas más:

Duplica el archivo “51-android.rules” y renombra el duplicado por “99-android.rules” (conserva ambos):

su
cp /etc/udev/rules.d/51-android.rules /etc/udev/rules.d/99-android.rules

Además, tendrás que configurar también el siguiente archivo en /lib/udev/rules.d/91-permissions.rules. Para ello:

su
gedit  /lib/udev/rules.d/91-permissions.rules 

Busca la siguiente línea de texto:

# usbfs-like devices 
SUBSYSTEM==”usb”, ENV{DEVTYPE}==”usb_device”, \ MODE=”0664″ 

Cambia el valor MODE a 0666 para que quede como abajo:

# usbfs-like devices 
SUBSYSTEM==”usb”, ENV{DEVTYPE}==”usb_device”, \ MODE=”0666″

Si has terminado de configurar estos archivos, guárdalos, ciérralos y, a continuación, reinicia el gestor de dispositivos (“udev”):

/etc/init.d/udev restart

4. ¿Qué debemos configurar en nuestro móvil?

Para que todo funcione, antes de conectar el móvil al ordenador has de activar la “Depuración USB” en tu dispositivo android. Para ello, entra en Ajustes > Opciones de Desarrollo.

Además, también debes activar la opción “Permitir la instalación de aplicaciones de origen desconocido” dentro del apartado Ajustes > Seguridad. Con esto, permitiremos que nuestra plataforma de desarrollo (Eclipse o JMonkey) cree e instale los archivos necesarios cuando construyamos y ejecutemos nuestra aplicación.

5. ¿Funciona?

Por fin podemos comprobar si nuestro esfuerzo ha valido la pena:
Enchufa tu teléfono móvil a un puerto USB. Localiza la carpeta que descomprimiste con SDK Android e ingresa en el directorio “platform-tools”. Por último, abre un terminal y ejecuta:

su ./adb devices

Recuerda que debes ejecutarlo como superusuario.

Como respuesta debemos obtener algo como esto:

* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached
0123456789ABCDEF device

Si es así, ADB está correctamente configurado y funcionando. Sin embargo, si en lugar de números aparecen interrogantes primero comprueba que estés ejecutando la herramienta ADB como superusuario. Si el problema persiste, algo debe haber ido mal al definir nuestras reglas (dispositivo incorrecto) o falta alguno de los archivos de configuración:

List of devices attached
???????????? no permissions

Revisa la configuración de los archivos del punto 3 y prueba a lanzar de nuevo ADB asegurándote de hacerlo como root:

su
adb kill-server

/etc/init.d/udev restart

adb start-server
adb devices

6. ¿Cómo veo mi aplicación corriendo en el móvil?

Si todo ha ido bien y ya tienes funcionando ADB, abre cualquiera de tus plataformas de desarrollo y ponlo a prueba.

A) Eclipse:
- Haz clic con el botón secundario sobre la carpeta de tu proyecto en la ventana lateral izquierda.
- A continuación, selecciona “Run as > Android Application”.

B) JMonkeyEngine: 
- Haz clic sobre el botón secundario en la carpeta del proyecto en la ventana lateral izquierda y abre “Properties”.
- Desactiva “Compile on Save” dentro de las preferencias de tu proyecto.
- En el apartado “Application>Mobile” habilita la opción “Enable Android Deployment” y selecciona en “Android Target” la versión del dispositivo en la que vas a trabajar.
- En el apartado “Run” selecciona tu dispositivo android (“Android Device”) y ejecuta tu aplicación .

Ahora ya podrías ejecutar la aplicación con el botón “Play” de la barra de herramientas. Para finalizar el testeo, haz clic en el botón “x” que se encuentra al lado de la situación de estado en la parte inferior derecha.

Espero que dentro de lo aparentemente complejo de este tema, hayas conseguido salir indemne y con tu aplicación corriendo en tu móvil.

NOTA 1: Incluyo "su" en cada bloque de comandos para recordar que se han de ejecutar como superusuario. Evidentemente, si lo estás haciendo todo desde una misma ventana del terminal sólo hará falta que accedas como "su" la primera vez.
NOTA 2: Si tu sistema es MacOS, puedes saltarte el punto 3 en el que se configuran los archivos de reglas. Además, la instalación del paquete JDK que se explica en el punto 1 puedes hacerla de manera normal. El resto de comandos para lanzar las aplicaciones (./adb devices) es exactamente igual pero sin ingresar como superusuario. Recuerda que tienes la terminal del sistema en: Aplicaciones > Utilidades > Terminal.
_____________________
1. Un posible error es tener varias instancias de ADB en el sistema y que se encuentre en ejecución la inadecuada. Así, aunque tu dispositivo esté conectado, no será visible para la plataforma desde la que estés desarrollando tu aplicación (Eclipse, JMonkey, etc.). Para evitar problemas, el proceso de ADB que esté ejecutándose debe formar parte del SDK que se encuentra enlazado dentro de estas plataformas.
2. También puedes conectar tu dispositivo a través de Wifi. Para ello, sigue las instrucciones que se explican en DesdeLinux.

Mars Colonial (Videojuego 3D)

Sinopsis:

Tras muchos esfuerzos y años de exploración espacial, finalmente los seres humanos hemos establecido una colonia en Marte para poder explotar sus recursos. Este anhelado sueño también nos ha revelado una inquietante pesadilla: no estamos solos en el Universo. Una sonda Von-Neumann también ha establecido su base en Marte. Este eficiente astillero automatizado es capaz de crear miles de robots ‘arácnidos’ cuya único objetivo es minar el planeta y autoreplicarse, acabando con cualquier obstáculo que se encuentre en su camino.

Marte es sólo el comienzo, todo nuestro Sistema Solar se encuentra en grave riesgo si consigue los recursos necesarios para conseguir su fin…

Descripción del juego:

Desde un punto de vista más prosaico, este juego sigue los esquemas de los clásicos juegos arcade de destruir ‘marcianos’. La mayor diferencia con éstos, es que toda la acción transcurre en un mundo infinito que simula ser Marte con modelos y escenas en 3D. Cuantos más enemigos destruyes, más aumenta tu nivel. Esto implica que pueden aparecer nuevos tipos de adversario (de momento sólo existen dos), además de que éstos irán creciendo en número y velocidad.

Existen una serie de recursos que se consumen conforme avanza la acción: munición, energía y salud. Los dos primeros se guardan automáticamente cuando acabas la partida para que dispongas de ellos al comenzar de nuevo. Estos recursos pueden reponerse en el transcurso del juego recogiendo las distintas cajas que aparecen en cuanto empiezas a carecer de alguno de ellos.

Otro de los valores que se conservan es el nivel alcanzado durante la partida, además de configuraciones como el idioma, sonido y filtros (dof y bloom).

La IA de los enemigos es bastante básica. Algunos te persiguen de manera constante provocando daños mediante el contacto con sus afiladas patas. Otros se sitúan a cierta distancia y disparan a placer. Los primeros pueden ser exterminados de un solo disparo, mientras que los segundos requieren un poco más de esfuerzo para ser derribados (tres disparos).

Algunas capturas de pantalla con el juego en funcionamiento

¿Qué herramientas se han empleado?

Este juego ha sido desarrollado básicamente con JMonkeyEngine (JME), Blender, Gimp e Inkscape.

JMonkeyEngine es un motor de juegos de código abierto y libre diseñado en Java que permite crear juegos 3D mediante ese lenguaje de programación.

Si sois lectores habituales del blog, sobre Blender, Gimp e Inkscape no tengo mucho más que añadir. El primero ha sido utilizado para crear los modelos y sus animaciones, mientras que tanto Gimp como Inkscape, se han empleado para la creación y edición de imágenes (texturas, fondos, interfaz, etc.).

JMonkeyEngine. Unos breves apuntes:

JME tiene un completo entorno de desarrollo (IDE) que utiliza todas las características de programación de la Plataforma NetBeans (autocompletado de código, herramientas de limpieza, integración VCS) y editores visuales que implementan distintas opciones y herramientas para modelos, terrenos, vehículos, etc. Además, cuenta con un completo conjunto de plugins que permiten complementar aspectos tan importantes como por ejemplo la propia interfaz del juego (Nifty GUI / XML) y que son actualizados automáticamente. Sin embargo, en este caso, he decidido no utilizar Nifty GUI y he partido de cero para implementar toda la  interfaz así como los botones y sus controles.

La incorporación de los activos o modelos digitales (Digital Art Assets) en la construcción del juego es realmente sencilla. Por ejemplo, en el caso de las imágenes basta con arrastrar desde el explorador de archivos a la aplicación. Los modelos en 3D se cargan a través de una herramienta de Importación que previsualiza el modelo, comprueba si existe algún problema y los convierte a un formato compatible llamado .j3o. Una vez importados se almacenan en la carpeta “assets” listos para ser cargados en cualquier visor, en el compositor de la escena (“Scene Composer”) o en el juego a través del “AssetManager”. Ahora tenemos todos los activos, pero ¿cómo se organizan dentro de la Escena?.

JMonkeyEngine en funcionamiento

En JME las escenas organizan todos sus datos jerárquicamente como si fueran un árbol: un padre puede tener múltiples hijos pero cada hijo solo un padre. Así, al actuar sobre el padre (mover, rotar, escalar, anexar, separar de la escena, etc.), el hijo recoge cualquiera de estas transformaciones. Por tanto, es importante planificar el esquema de tu escena desde el nodo principal (rootNode), pasando por cada uno de los nodos que vayas creando. En el último nivel se encontraría la geometría que les permite ser visibles al darles una forma, color, textura, etc.

Diagrama con la organización de la Escena

En cuanto al código, toda la programación en JME se realiza en Java, por lo que si te decides a juguetear con este programa es muy aconsejable que antes hayas adquirido unas nociones básicas en este lenguaje.

Este juego está estructurado en distintas Clases para tener más organizado todos sus elementos (jugador, enemigos, hud, sonido, etc.), separar los controles en algunos casos (p.e. la IA de los enemigos) y tener un mejor acceso y control sobre las distintas pantallas (Start, Main y Float Window). Deben existir cientos de métodos o funciones, y ya no digo de atributos o variables, que he intentado optimizar en la medida de lo posible. Sin embargo, en un proyecto tan vasto existen bastantes cosas que se escapan y que pueden derivar en algún posible bug o falta de rendimiento. Por mi parte intentaré ir mejorando estos problemas si el tiempo y las circunstancias no lo impiden.

Requisitos mínimos del juego:

Sistema operativo	Linux, Windows
Memoria (JVM tamaño de almacenamiento dinámico)	> 10 MB + memoria para los activos digitales (modelos, texturas, sonidos, etc.)
CPU	> 1 GHz
Tarjeta gráfica	AMD/ATI Radeon 9500, NVIDIA GeForce 5 FX, Intel GMA 4500, o superior con soporte para OpenGL 2.0 o superior (las bibliotecas nativas se incluyen en la descarga)
Java (Entorno de ejecución)	Java 5 o superior Es necesaria una máquina Virtual Java (JVM) para ejecutar los juegos JME. Normalmente JVM se encuentra preinstalado en la mayoría de equipos, aunque puede obtenerse gratuitamente desde http://www.java.com

Instalación:

El juego puedes descargarlo de manera gratuita desde sourceforge.

•  Linux

Descarga el juego, descomprime la carpeta y ejecuta “MarsColonial.sh”.

Si tienes un sistema basado en Debian, también tienes la opción de instalarlo mediante un paquete “.deb”.

•  Windows

Descarga el juego, descomprime la carpeta y ejecuta “MarsColonial.exe”.

•  MacOSX

Descarga el juego, descomprime la carpeta y ejecuta “MarsColonial.app”.

Controles del juego (Atajos de Teclado):

•  W, S, A, D o teclas de dirección: Movimiento del jugador.

•  Barra espaciadora: Disparo.

•  X: Cambiar la posición de disparo del arma.

•  M: Activar o desactivar el sonido.

•  P: Hacer una pausa o continuar con el juego

•  Esc: Cerrar el juego.

Saludos y espero que paséis algún buen rato con él.

Gamekit: Crea juegos para Android desde Blender

Si en mi anterior entrada abordaba la realización de juegos y aplicaciones para Android con AppInventor, ahora analizaremos otra herramienta que también tiene un gran potencial y que permite desarrollar juegos para Android desde el propio Blender: Gamekit

Gamekit es un motor básico de videojuegos que integra dentro de Blender a Ogre para la construcción de gráficos (también existe una versión para Irrlicht), Bullet para las físicas y Open AL para el sonido. Esta integración con Blender le permite aprovechar muchos de sus elementos como Materiales, Iluminación o incluso los propios ‘logic bricks’ a la hora de desarrollar el juego.

Además, también permite la integración en otras plataformas como Linux, Windows, OSX o el propio Android mediante Eclipse. Tiene una gran versatilidad en el apartado de programación, ya que la lógica del juego puede realizarse, no sólo con los propios ‘logic bricks’ de Blender, sino también, a través de C++ y Lua.

Instalación:

Para probar GameKit no es necesario instalar nada. Sólo has de descargar el archivo que se corresponda a tu sistema operativo y descomprimirlo. Dentro de la carpeta descomprimida podrás observar una serie de archivos:

- ‘momo_ogre.blend’ es el propio juego hecho con Blender (escena y personajes).

- ‘Ogrekit’ es el ejecutable ya compilado.

- ‘OgreKit.log’ y ‘OgreKitStartup.cfg’ son los archivos de configuración del juego.

Una captura con el archivo de demostración momo_ogre.blend en funcionamiento

Para hacerlo funcionar sólo has de lanzar el ejecutable. De hecho, incluso podrías empezar a hacer pruebas con tus propios archivos sustituyendo el archivo ‘momo_ogre.blend’, aunque conservando ese nombre. Eso sí, primero es conveniente ver cómo funciona este motor a nivel de ‘logic bricks’ y materiales, porque no vale todo y existen ciertas reglas a la hora de desarrollar el juego para que GameKit pueda hacerlo funcionar correctamente.

Integración de GameKit en Blender:

Efectivamente, para que podamos comprobar al momento nuestros avances en el desarrollo, lo realmente cómodo es trabajar con este motor desde dentro del propio Blender. Para ello, lo incorporaremos como un 'Addon' dentro del propio programa.
Dentro del archivo comprimido que has descargado anteriormente deberías tener una carpeta llamada ‘BlenderAddon’. Debes copiar esos archivos en la carpeta donde tengas instalados los AddOn de Blender (archivos y carpetas en sus respectivos directorios) o si lo prefieres instalarlo desde el propio Blender:

- File > User Preferences > Addons > Install from File (localizando esos archivos)

Una vez instalado has de habilitar el plugin en esa misma ventana. Además, debes tener la carpeta de archivos temporales apuntando a una ruta correcta:

- File > User Preferences > File > Temp:'ruta de tu carpeta temporal'

Ahora GameKit debería aparecer en la lista desplegable de los motores de Render, así que cambiamos de ‘Blender Render’ a ‘GameKit’.

En la ventana lateral de ‘Render’ deberíamos ver las opciones de Gamekit. Es muy importante indicar la dirección del ejecutable en ‘Runtime’, porque de lo contrario nos dará un error.

Si todo ha ido bien, ya podemos lanzar Gamekit a través del botón ‘Start Game’, el cual abrirá una nueva ventana con nuestra escena empleando ese motor de juegos en lugar del motor de Blender.

Captura con una vista de Gamekit integrado en Blender

Integración con Eclipse:

Bueno, ya has estado un rato trasteando con él y ves que tiene buena pinta. Aunque de momento no hay rastro de Android por ningún lado... vamos con ello:

En primer lugar necesitas volver a la página de descargas del proyecto para conseguir el archivo ‘GameKit-Android-EclipseProject-v7a-r1119.zip’. Una vez descomprimido verás dos carpetas: una con el plugin para Blender y otra llamada ‘gkAndroid’ que es la que contiene los archivos del proyecto. Recuerda dónde guardas la carpeta ‘Gamekit-Android’ porque luego has de apuntar hacia ella para configurar tu proyecto.

Ahora utilizaremos Eclipse como entorno de desarrollo, así que si todavía no lo tienes instalado, es el momento de hacerlo y comprobar que tenga correctamente instaladas las herramientas para Android (ADT Plugin).

Además, como comentaba en mi anterior entrada, si tienes tu propio Tableta puedes conectarla mediante ‘ADB’ (una vez hayas instalado el SDK de Android) para poder ver al momento los resultados de tus modificaciones. También es posible trabajar a través de un emulador de Android o dispositivo virtual, aunque seguramente puede surgir más de un error con algunas librerías y finalmente no cargar tu juego (además de otras carencias como por ejemplo el acelerómetro).

Una vez esté todo listo, necesitarás crear un nuevo proyecto en Eclipse para Android. Para ello:

- Inicia Eclipse

- File > Import > General > Existing Projects into Workspace > Next

- Navega hasta la carpeta ‘gkAndroid’ que has descomprimido antes > Ok

- Selecciona GamekitAndroid > Finish

- Ahora verás en la ventana lateral izquierda una lista con los archivos del proyecto.

Cargando un nuevo proyecto en Eclipse

Para ejecutar el archivo de demostración:

- Haz clic con el botón secundario sobre tu proyecto (en la ventana lateral) > Run as > Android Application.

- Ahora deberías ver a Suzanne saltando en una pequeña escena llena de obstáculos y que puede ser controlada mediante el acelerómetro de tu Tableta.

Para ejecutar tus propios archivos:

- Copia tu archivo ‘.blend’ dentro de la carpeta ‘assets’ y renómbralo como gk_android.blend

- Si lo has hecho desde fuera de Eclipse (el navegador de archivos de tu sistema), tendrás que refrescar los archivos de tu proyecto: clic derecho sobre tu proyecto > Refresh

- Ahora cuando lo ejecutes podrás ver tu propia escena funcionando en la Tableta.

Es bastante aconsejable conservar una copia de todos los archivos originales. Así, podrás observar su estructura y cómo están realizados, ya que dan muchas pistas que pueden ser utilizadas como base para tus propios trabajos.

Conclusiones:

Con todas estas premisas y después de trastear un poco, el resultado ha sido un poco agridulce. En efecto, en los últimos meses parece observarse un descenso en la actividad de desarrollo dentro de ese proyecto. Este parón limita bastante las opciones para realizar algún juego más elaborado, puesto que muchas de las características que ya están reportadas podrían dar un salto cualitativo importante al proyecto. Así las cosas, las limitaciones actuales son un escollo importante si quieres realizar algún juego más elaborado.

Videojuego de prueba desarrollado con Gamekit en Blender para Android

Destacaría algunos inconvenientes detectados durante la realización del juego de prueba (y que deberíais tener en cuenta si os lanzáis a la aventura):

- De momento, no soporta eventos multitáctiles. Problema importante cuando intentas configurar botones de control simultáneos.

- El sonido para  Android no está configurado de serie, ya que existen ciertos problemas de licencia en las librerías OpenAL para Android.

- Las sombras están deshabilitadas en la versión para Android.

- No acaba de soportar de manera correcta las imágenes con mapas de Normales dentro de los Materiales.

Como ventajas destacaría naturalmente la integración con Blender y sus ‘logic bricks’, la posibilidad de utilizar un motor de juegos tan potente como Ogre dentro del propio Blender y, sobretodo, su capacidad multiplataforma a la hora de exportar los juegos.

Algunos enlaces de interés sobre Gamekit:

- Página oficial del proyecto: http://code.google.com/p/gamekit

- Para acceder directamente a todas sus descargas: http://code.google.com/p/gamekit/downloads/list

- Documentos de ayuda en formato .chm

- Foro oficial donde puedes resolver muchas de tus dudas: http://gamekit.org/forum/

_______________________________________________________

ADENDA.
En este apartado iré añadiendo material que ayude a resolver algunas de vuestras dudas que me habéis hecho llegar en vuestros comentarios.

Adenda 1. Sobre eventos de teclado en Blender:
Para simular 'Touch Events' mediante los 'Logic Bricks' de Blender puedes utilizar una combinación de dos sensores tipo 'Mouse':
- 'Left Button' simula el clic.
- 'Mouse Over' determina la posición del cursor sobre el objeto.

Adenda 2. Un modo sencillo de abrir tus modelos de Blender en Android
Desde el siguiente enlace podrás descargar un archivo .apk que permite visualizar tus archivos de Blender en Android (con algunas limitaciones, claro):
http://download.blender.org/demo/android/BlenderPlayer_08_02_12_4.apk

INSTALACIÓN
- Asegúrate que tienes activada la opción de permitir la instalación de aplicaciones de origen desconocido en tu dispositivo Android (Ajustes > Seguridad).
- Copia el archivo .apk que has descargado a tu dispositivo Android e instálalo como una aplicación normal.
- Copia los juegos que quieras ejecutar también en tu dispositivo (Deben tener la extensión .blend).

EJECUTAR JUEGO
- Abre BlenderPlayer (la aplicación que se habrá instalado en tu dispositivo). Selecciona el archivo .blend que contiene tu juego o modelo y haz clic en StartBlenderPlayer.
- También puedes localizar tu archivo .blend con un explorador de archivos > Abrir .blend > Con BlenderPlayer.

Crea aplicaciones y juegos para Android con AppInventor

Esta entrada la voy a dedicar a App Inventor, una herramienta muy interesante desarrollada por el MIT Center que nos permite desarrollar aplicaciones para teléfonos o tabletas con Android.

Tras adquirir hace poco una 'bq Edison', comencé a barajar la posibilidad de realizar alguna aplicación para este sistema, así que me lancé a la búsqueda de información. Tras googlear un poco encontré esta herramienta que te permite desarrollar aplicaciones a través del navegador, en cualquier sistema operativo y sin necesitar conocimientos de programación, ya que se trata de encajar bloques de funciones preprogramadas como si fueran las piezas de un puzzle (en cierto sentido recuerda al sistema de ‘logic bricks’ de Blender) .

Básicamente se trabaja a través de dos herramientas:

- App Inventor Designer, donde se introducen los elementos que componen tu app.

- App Inventor Blocks Editor, donde se componen de un modo visual los bloques de programación. Pero al igual que un puzzle, no todas las piezas pueden encajar las unas con las otras existen limitaciones en función de su naturaleza. Cada uno de los elementos introducidos en el Diseñador tiene sus propios bloques, pero además puedes añadir otras funciones y variables para completar tu aplicación.

Además, puedes visualizar tu trabajo a tiempo real con un emulador Android o conectando tu propio teléfono o tableta al ordenador.

App Inventor Designer	App Inventor Blocks Editor

- Instalación:

Lo primero de todo es que necesitas tener una conexión de Internet y una cuenta de Gmail, ya que todo tu trabajo se encontrará alojado en la nube y asociado a dicha cuenta.

Además deberás tener java instalado e instalar el paquete de la aplicación en función de tu sistema operativo.

Una vez reúnas todos los requisitos, deberás acceder con tu navegador web a la siguiente dirección: http://beta.appinventor.mit.edu/

- Primeros pasos:

La primera vez que accedas, verás una página de proyectos vacía. Para empezar a trabajar, sólo has de añadir un nuevo proyecto haciendo clic en ‘New’.

En cuanto le asignes un nombre, aparecerá el ‘Diseñador’, desde donde podrás añadir, seleccionar o eliminar todos los elementos que componen tu proyecto. Aquí puedes editar su tamaño, posición, imagen, aunque también puedes hacerlo dinámicamente a través del ‘Editor de Bloques’.

Cuando abras este editor, a la izquierda verás tres paletas agrupadas en pestañas (Built-In, My Blocks, Advanced) donde se encuentran los juegos de bloques. Sólo has de ir seleccionandolos y arrastrandolos sobre el espacio de trabajo, para ir componiendo todo como en un gran puzzle.

Como podrás observar, en ‘Built-In’ se encuentran los bloques agrupados por tipo (Texto, Listas, Lógica, etc.) y en ‘My Blocks’, los relacionados con todos los elementos que has incorporado desde el ‘Diseñador’ a tu proyecto y que se irán actualizando automáticamente.

Explicarlo es más difícil que ponerlo en práctica, así que ya puedes jugar con ellos para comprobar la simplicidad de la idea.

- Comprobando tus progresos al momento:

Para ver de una manera interactiva el resultado de tus avances tienes dos opciones: abrir un emulador desde el Editor de Bloques o conectar tu propio dispositivo Android.

Para lo primero, sólo necesitas hacer clic en el botón ‘New Emulator’ que abrirá un dispositivo virtual al que conectarás cuando finalice su arranque pulsando en ‘Connect to Device’.

Para lo segundo, puede que necesites algo más de paciencia, aunque tampoco es excesivamente complicado y ganarás en ‘agilidad’. Existen dos modos: uno mediante wifi y otro a través de un cable usb que conecte tu dispositivo con el ordenador. El primero no lo he probado pero parece bastante sencilla de implementar. Para el segundo te tocará pelear algo más, ya que necesitarás instalar los drivers adecuados para tu sistema operativo y conectar tu tableta mediante ‘ADB’, para lo que necesitarás también instalar el SDK de Android.

PROS:

- Facilidad de uso y bastante intuitiva. La curva de aprendizaje es realmente rápida.

- El sistema de ‘puzzle’ es realmente ingenioso. Si has trabajado con ‘logic bricks’ de Blender podrás observar cierto paralelismo en el flujo de trabajo.

- Permite desarrollar tu aplicación con múltiples ‘Screens’.

- La ‘paleta’ de elementos con los que trabajar es realmente completa y permite tener un control bastante preciso sobre muchos de los componentes.

- Posibilidad de integrar Bases de datos Web con TinyWebDB

CONTRAS:

- Esta aplicación utiliza básicamente Java. Esto es algo a considerar, ya que últimamente este entorno ha sido protagonista de bastantes problemas de seguridad.

- El tamaño final de la aplicación desarrollada (.apk) resulta quizás demasiado grande para lo que suele verse en el Market de Android.

- Si eres poco organizado, la estructura de los bloques del puzzle puede tornarse caótica con los consiguientes quebraderos de cabeza a la hora de localizar determinados elementos.
- Además del caos anterior, el creciente número de bloques ralentiza bastante la aplicación y se pierde bastante fluidez tanto en la edición como, posteriormente, dentro del propio juego.

- Por el momento, no permite la duplicación o introducción dinámica de ‘sprites’: Todos los elementos que componen la app deben encontrarse desde el principio en tu espacio de trabajo y luego has de jugar a habilitarlos o deshabilitarlos a través de los bloques de código.

- Los ajustes automáticos (‘Fill parent’ en ‘Width’ o ‘Height’) de los distintos elementos que permiten adaptar su tamaño a los distintos dispositivos no tienen el resultado esperado: al activar estos ajustes en el Diseñador o ajustando el tamaño a través de bloques, los elementos visuales de tu App adquieren un aspecto borroso o poco definido que resta profesionalidad al resultado final. (La única solución que he encontrado de momento es editar el .apk resultante con alguna herramienta como ApptoMarket y  configurar la resolución en ‘any’ y ‘not resizable’.

De todos modos, algunas de las desventajas que enumero son temporales puesto que estas cuestiones, entre otras muchas, se encuentran ahora mismo en la lista de desarrollo.

Como todo movimiento se demuestra andando, aquí tenéis ‘Arkablocks’, un pequeño juego desarrollado con esta herramienta. Se trata de una versión simplificada del clásico ‘Arkanoid’ para el que también he empleado ‘Inkscape’ en la elaboración de los elementos visuales (‘sprites’, botones, fondos, etc.).

Todo el desarrollo del juego se ha realizado con el apoyo de una tableta 'bq Edison' de 10" y apenas he podido probarlo en un 'Samsung Galaxy Mini 3'. Por ello, si instalas este juego en un teléfono móvil seguramente encontrarás más de un problema con los tamaños de fuente o  la distribución de los contenidos (entre otros muchos 'bugs' derivados del cambio de tamaño).

La ausencia de fluidez en el vídeo (máximo de 3 fps) es debida a las limitaciones de la herramienta de captura que he utilizado (Android Screen Capture). Además, la fluidez con la que corre el juego una vez instalado tampoco es la ideal debido a que App Inventor todavía no está suficientemente optimizado para su uso en tabletas: la edición del .apk para mejorar su aspecto, así como el elevado número de bloques y la cantidad de 'sprites' son factores que restan velocidad al juego.

Con todo, App Inventor es una herramienta más que interesante, a la que habrá que seguir de cerca, puesto que si siguen en la dirección correcta puede ser otro paso más para ‘democratizar’ el software y permitir que gente con pocos conocimientos de programación pueda realizar sus propios programas.

SteamPac 1.0.1

Después de todos los avatares derivados de la actualización del Sistema y sus reajustes, he encontrado el momento para preparar los correspondientes archivos de actualización de SteamPac 3D.

En esta versión 1.0.1 se corrigen dos 'bugs': 

- Si el jugador entraba en el área de nacimiento del enemigo, caía a través del mundo virtual.

- Existía un problema con el cambio de apariencia de los enemigos que confundía sobre su estado real. Este problema se ha solucionado añadiendo nuevos 'estados' en las mallas de reemplazo.

Las actualizaciones se encuentran disponibles para Linux y Windows en 32 y 64 bits:

SteamPac 1.0.1 - Linux 64

SteamPac 1.0.1 - Linux 32

SteamPac 1.0.1 - Linux (all). Paquete .deb

SteamPac 1.0.1 - Win 32

SteamPac 1.0.1 - Win 64

Tras esta actualización, dejo este proyecto momentáneamente en 'standby'  para poder centrarme en el otro juego que tengo en desarrollo: Bartar, el pequeño guerrero.

Bartar, el pequeño guerrero

Nueva entrada para presentar un avance del proyecto en el que me encuentro actualmente inmerso: 'Bartar, el pequeño guerrero'.

Se trata de un videojuego ambientado en el poblado ibérico de la Bastida de las Alcusses (Moixent, Valencia), donde nuestro pequeño guerrero Bartar ha logrado llegar tras escapar del Museo y dar un 'pequeño' salto en el tiempo de 2.300 años. Ahora lleva las riendas del poder, controla ciertas actividades para aumentar la prosperidad de su ciudad y se enfrenta a los peligros que acechan.


Este juego se encuentra todavía en una fase de desarrollo bastante temprana, aunque, si habéis visionado el vídeo, ya tenéis bastantes pistas sobre su temática y modo de funcionamiento. Se mezclan varios géneros: el 'Rol', la simulación de construcción, así como pequeñas dosis de acción (de momento mínimas) en este juego en tercera persona.

Entre las características más avanzadas del proyecto se encuentran:

- Los movimientos principales del personaje principal ya están definidos, aunque todavía queda bastante trabajo en las animaciones, así como en la interacción con otros elementos y personajes que están pendientes de desarrollar.

- Interfaz con tres elementos:

• El 'hud' presenta y contabiliza los distintos elementos a desarrollar: extracción de recursos como madera o piedra, construcción, artesanía, etc.
• En la barra superior podemos encontrar las siguientes opciones: guardar partida (todavía por implementar), abrir un archivo de ayuda, cambiar de idioma (español o inglés), activar o desactivar el audio, cambiar de cámara o perspectiva y aumentar o reducir el zoom.
• También se presenta un pequeño mando para poder controlar al jugador opcionalmente con el ratón.

Todos estos elementos son ocultables en su conjunto mediante un atajo de teclado o individualmente mediante los pequeños botones triangulares situados en sus extremos.

- Las acciones del juego están en pleno desarrollo: por ejemplo la adquisición de objetos para poder acceder a otras habilidades del juego (como por ejemplo la construcción de casas) y así ir incrementando el 'estatus' o nivel de prosperidad de la ciudad.

- La interacción con enemigos apenas está esbozada. De momento, como puede verse en el vídeo, sólo existe un cuervo 'follonero' que nos importuna cuando accedemos a los tejados. Sin embargo la idea es que guerreros de otros clanes compliquen la idílica existencia de nuestro Baltar, ya sea con ataques directos (sobre la salud del jugador) o indirectos (dañando sus posesiones y bajando el nivel general de la ciudad).

Para la producción de este juego estoy utilizando Blender y su motor de juego. Debido a su gran complejidad, a diferencia de 'SteamPac', en su programación estoy empleando toda una serie de 'scripts' realizados en 'python' como complemento de los 'logic bricks'.

Otras herramientas empleadas y ya imprescindibles para mí en este tipo de proyectos son Gimp e Inkscape para la edición de imágenes y el apartado gráfico. La plataforma de producción sigue siendo mi ya veterano equipo (... y lo que le queda) con Linux Mint Debian en sus tripas.

Así que ya sabéis: si $Deity y los hados de la procrastinación me lo permiten, intentaré seguir posteando nuevos avances, cosa nada fácil en un proyecto de esta envergadura y (me temo) de laaargo recorrido. Con un poco de suerte podremos adentrarnos en el mundo de los iberos de la mano de nuestro pequeño guerrero…

Saludos

Artículo sobre Steampac 3D en Blendercat

Hola a todos de nuevo.

Ya se ha publicado el número 4 (octubre) de la revista Blendercat, publicación en español que recopila artículos y tutoriales sobre Blender. En este número firmo uno de los artículos donde explico algunos detalles interesantes sobre la realización del juego "Steampac 3D" y hago algunas reflexiones sobre la realización de juegos con Blender en general mediante "logic bricks".

Así que ya sabéis, podéis descargar el pdf con el siguiente contenido:

• Steampac 3D, un videojuego por Angel Sanchez.
• Modificador Spin por Abraham CastillaHamusuta Man.
• Video Editor por Marçal Mora.
• Software Libre, una cuestión ética por Xavier Gassó.
• LibreWare, la serie por Marçal Mora.

Saludos y pronto espero publicar algún avance sobre mi actual proyecto.

En primer lugar quiero daros las gracias a todos por las muestras de apoyo recibidas. Me alegra que un proyecto Open Source como éste haya tenido una aceptación (para mí) más que notable.

Esta entrada es solo para anunciaros que SteamPac 3D, además de su correspondiente entrada en este blog, ya tiene su propia página en la que se desarrollan los contenidos exclusivos sobre este proyecto.

De todas maneras, en este blog seguiré posteando las novedades sobre ese proyecto y algunas otras "locuras" en las que acabaré embarcado.

STEAMPAC 3D - Videojuego arcade

Tras un tiempo de pausa, estoy de vuelta con vosotros con un juego completamente realizado con Blender y que utiliza su motor de juegos.

Vídeo con SteamPac 3D 1.0 en funcionamiento

Características generales:
Steampac es un juego de laberinto inspirado por el popular Pac-man (también conocido en España como "Comecocos"), aunque con una estética diferente (mezcla de estilo "Toon" y "Steampunk") y con personajes y escenas en 3D.
Este juego está totalmente desarrollado con Blender y utiliza su motor de juego.
Salvo un par de líneas de código en Python, toda la programación se ha llevado a cabo mediante "logic bricks".

Capturas del videojuego en funcionamiento

Características técnicas:
El reproductor autónomo tiene una resolución de 640x480 y utiliza un sombreado GLSL.
El Lenguaje OpenGL Shading (GLSL) necesita una tarjeta gráfica y controladores que lo soporten. Consulta la lista de tarjetas gráficas admitidas en el documento "readme.html" que se incluye en el juego.

Capturas del videojuego en desarrollo

A título personal:
Tras algún tiempo sin tocar el módulo de juegos de Blender (desde su versión 2.49) y con ganas de probar algunas de sus novedades, me adentré en lo que "a priori" parecía un proyecto sencillo: la realización de un videojuego de laberinto que siguiera el esquema de juego del Pac-man, aunque modificando los elementos visuales y dotándolo de un escenario en 3D.

Esto que parece algo relativamente fácil ha ido complicándose por momentos hasta adquirir rasgos de proyecto inalcanzable (No me quiero imaginar a la gente que se embarca en la realización de juegos tipo FPS en solitario).

La preparación del material que lo compone (personajes, texturas, animación, etc.) quizás ha sido la parte menos pesada puesto que estoy más acostumbrado a manejarme con ello. Aunque, claro, siempre surgen ciertas cuestiones: retoques de modelos para bajar la densidad de la malla, ajustar las texturas en las nuevas mallas, etc.

El apartado de programación en Blender ha sido la parte más "entretenida". A partir de unos esquemas en los que se abordaban cuestiones como el propio diseño y los comportamientos de jugador y enemigos, fui construyendo toda la lógica. Pero el reto más importante era que sólo debería emplear "logic bricks". Quería ver si un juego aparentemente sencillo podría construirse sólo mediante los bloques lógicos de Blender, sin utilizar python (o al menos, haciéndolo en su mínima expresión).

La buena noticia es que, efectivamente, es factible hacer un juego de este tipo empleando sólo "logic bricks" (de hecho, al final sólo he incluido dos líneas de código en python para mostrar y ocultar el cursor en determinados momentos). La mala noticia es que, o tienes las ideas muy claras en la organización y desarrollo de tu proyecto o éste "morirá entre terribles sufrimientos". Es vital utilizar distintos "estados" en los personajes para mantener cierta coherencia en la construcción y, sobretodo, tener un mínimo de organización. Además, como suele pasar con este tipo de trabajos, cuando arreglas una cosa aparecen otros problemas que irremediablemente te conducen a otros en una espiral casi infinita de problemas o fallos (en este punto es donde te darás cuenta si has organizado adecuadamente tus elementos, ya que intentar localizar un problema dentro de un caos de objetos y "logic bricks" puede acabar con tu salud mental).

Otra cuestión que me ha dado bastantes quebraderos de cabeza ha sido la optimización del juego. Efectivamente, en mi equipo (no muy potente, pero con una gráfica reciente) no hay mayores problemas a la hora de ejecutarlo: fácilmente alcanza los 60 FPS y se nota fluido. Ahora bien, al realizar las pruebas con otros equipos de menores prestaciones, los FPS pueden llegar a caer a la mitad. El mayor problema está en la utilización de "GLSL" como "shader" en lugar de "Singletexture" o "Multitexture" para poder visualizar materiales complejos realizados con nodos (el efecto "Toon" de los personajes). Además, tuve que crear librerias de materiales y cambiar el formato de las texturas de .jpg y .png a .dds (direct draw surface) puesto que parece que se mejora la carga de imágenes.

Esquemas de trabajo

Descargas:
Ahora que ya sabéis algo más sobre este proyecto, podéis descargarlo desde sourceforge.net, o desde los enlaces que aparecen más abajo, en sus versiones para Linux y Windows (pronto espero tener preparada una versión para Mac OS X).

Steampac 1.0 (Linux 64)
Steampac 1.0 (Linux 32)
Steampac 1.0 (Linux. Paquete .deb cortesía de Luciano Javier Lagassa)
Steampac 1.0 (Windows 32)

Si estáis interesados en más detalles concretos sobre este él, no dudéis en comentar y cuando disponga de tiempo intentaré resolver dudas o postear más material relacionado con este trabajo.

Saludos.

Actualización con bugs conocidos:

• Si el jugador entra en la zona de nacimiento de de los enemigos, caerá hacia abajo a través del mundo virtual y se tendrá que reiniciar el juego (corregido, cambios en la próxima versión).
• Problema en el cambio de apariencia de los enemigos en el momento del parpadeo del "warning" que confunde sobre su verdadero estado. Al añadir nuevos estados en la sustitución de las mallas se soluciona el problema. (corregido, cambios en la próxima versión). 
• Puede suceder que en ocasiones no se contabilice la colisión del "jugador" con el "punto" de modo adecuado. Si esto sucede, no se alcanza el "marcador" necesario para cambiar el nivel y se quedará atrapado en dicho nivel. Ese fallo de colisión puede pasar cuando la "física" del juego trata de interpretar varios "contactos" con apenas diferencia de tiempo y al juego no le da tiempo a contabilizarlos.

Observaciones:

• No se trata de un "bug" sino de una característica no implementada, pero en el cambio de nivel NO se produce un cambio de apariencia del escenario, en realidad acorta el tiempo de caza de los enemigos y los hace algo más activos. Si dispongo de tiempo intentaré añadir algún escenario más en la próxima versión.