introducciÓn a libgdx1

21
INTRODUCCIÓN A LIBGDX Android/ iOS/ HTML5/ desktop game development framework 1.INTRODUCCIÓN LibGDX es un framework multiplataforma de desarrollo de juegos para Windows, Linux y Android. Está escrito en Java con una mezcla de C/C++ para dar soporte y rendimiento a tareas relacionadas con el uso de la física y procesamiento de audio. LibGDX permite generar una aplicación en su PC y utilizar el mismo código en Android, de esta manera el proceso de pruebas y depuración se realiza de forma más rápida y cómoda ya que el PC es mucho más rápido que el dispositivo Android. Con LibGDX nos aseguramos de que la misma aplicación puede funcionar correctamente en diferentes dispositivos. LibGDX está compuesto por una serie de componentes o módulos que serán comunes a todas las aplicaciones. Marco de Aplicación, que manejará el bucle principal y además estará encargado del clico de vida, es decir, los eventos de creación,destrucción, pausa y resume de la misma.

Upload: carmen-julve-tiestos

Post on 20-Oct-2015

16 views

Category:

Documents


0 download

TRANSCRIPT

INTRODUCCIÓN A LIBGDX

Android/ iOS/HTML5/desktop game

development framework

1.

INTRODUCCIÓN

LibGDX es un framework multiplataforma de desarrollo de juegos para Windows, Linux y Android. Está escrito en Java con una mezcla de C/C++ para dar soporte y rendimiento a tareas relacionadas con el uso de la física y procesamiento de audio.

LibGDX permite generar una aplicación en su PC y utilizar el mismo código en Android, de esta manera el proceso de pruebas y depuración se realiza de forma más rápida y cómoda ya que el PC es mucho más rápido que el dispositivo Android.Con LibGDX nos aseguramos de que la misma aplicación puede funcionar correctamente en diferentes dispositivos.

LibGDX está compuesto por una serie de componentes o módulos que serán comunes a todas las aplicaciones.

Marco de Aplicación, que manejará el bucle principal y además estará encargado del clico de vida, es decir, los eventos de creación,destrucción, pausa y resume de la misma.

Un componente de Gráficos que nos permitirá gestionar la representación de imágenes y objetos gráficos en la pantalla.

Un componente de Audio, que nos facilitará el acceso a los sonidos y música de la aplicación.

Un componente de de Entrada y Salida para leer y escribir los diferentes ficheros de datos como por ejemplo, imágenes, archivos de configuración, sonidos, música, texturas,...

Un componente de Entrada que gestionara la entrada a través del teclado, pantalla tácil o acelerómetro.

Adicionalmente podríamos ampliar la gama de módulos con otros dos más.

Math, permite la gestión rápida de cálculos matemáticos orientados al desarrollo de videojuegos.

Physics, que básicamente es un wrapper de Box2D y permite controlar la gestión de colisiones.

1.1 MODULES

At its core, libgdx consists of five interfaces that provide means to interact with the operating system. Each backend implements these interfaces.

Application : runs the application and informs an API client about application level events, such as window resizing. Provides logging facilities and querying methods for e.g. memory usage.

Files : exposes the underlying file system(s) of the platform. Provides an abstraction over different types of file locations on top of a custom file handle system (which does not interoperate with Java's File class).

Input : informs the API client of user input such as mouse, keyboard, touch or accelerometer events. Both polling and event driven processing are supported.

Audio : provides means to playback sound effects and streaming music as well as directly accessing audio devices for PCM audio input/output.

Graphics : exposes OpenGL ES 1.x and 2.0 (where available) and allows querying/setting video modes and similar things.

Este gráfico muestra en mayor detalle el sistema de módulos de LibGDX

Realmente, estos módulos son sólo interfaces públicas que ofrece la librería.La propia aplicación será la encargada de la gestión de los diferentes módulos.

Ventajas:● Soporte 2d full (bajo y alto nivel)● Mucha documentación, tutoriales, ejemplos de código.● Releases en forma periódica la ultima fue en setiembre y anterior en Mayo.● Se puede probar en desktop (antes de subir a mobile) ● Maneja Audio, input (usuario), física, matemática,archivos.● Mas poderoso que Andengine● Soporta 3D● LibGDX te da un acceso más fácil a Bajo nivel.● Posibiledad de tomar un juego hecho en java jar 2d o 3d y adaptarlo a libgdx para

qur funcione nativo en android,eso hicieron con el juego Droid Invaders 3d.Desventaja:

● El soporte de alto nivel en 3d está en construcción actualmente

1.2 LINKS DE REFERENCIA:● Pagina Oficial ● Wiki del proyecto ● Blog ● Foro ● Juego en 3d ya realizado: Droid Invaders ● Listado de Ejemplos ● Video Tutoriales ● Documentación

2. DESCARGA E INSTALACIÓN DE LA LIBRERÍA

2.1 DESCARGAR LA LIBRERÍA

Para descargar la librería debemos ir a la web de la misma: http://libgdx.badlogicgames.com/

A la derecha pulsamos en download y de las dos versiones de la librería que nos aparecen, seleccionamos la versión Nightly Build.

Tras pulsar en Download ya sólo nos queda descargar la última versión de la librería. En definitiva, descargaremos el archivo libgdx-nightly-latest.zip y lo descomprimiremos.

2.2 INTEGRACIÓN ECLIPSE Y LIBGDX

La integración de este nivel puede realizarse a nivel de librerías, vamos a ver los pasos necesarios para crear un juego para PC y Android a la vez. También se podría realizar para Linux, iOS y Web.

Note: Java 1.7 is currently problematic in combination with Android. Please make sure your project uses Java 1.6

This page describes how to configure Eclipse to develop and run libgdx applications on both the desktop and Android.

2.2.1 Main project setup

1. Create a new Java project in Eclipse: File -> New -> Project -> Java Project. Give it a name and click Finish.

2. Go to the project folder on the file system and create a subfolder named libs. Download the nightly zip and place gdx.jar and gdx-sources.jar in the libs folder.

3. In Eclipse, right click the project -> Refresh. Right click again -> Properties -> Java Build Path -> Libraries -> Add JARs, select gdx.jar and click OK.

4. Under the gdx.jar file, double click "Source attachment", click Workspace, select the gdx-sources.jar and click OK.

5. Click the Order and Export tab, check the gdx.jar and click OK.

Note: Step 5 makes gdx.jar a transitive dependency. That means that projects that depend on the main project will also have gdx.jar on their classpath. However, this doesn't work for Android projects.

2.2.2 Desktop project setup

1. Create a new Java project in Eclipse: File -> New -> Project -> Java Project. Name it appropriately (eg, "gamename-desktop") and click Finish.

2. Go to the project folder on the file system and create a subfolder named libs. From the nightly zip, place gdx-natives.jar, gdx-backend-lwjgl.jar and gdx-backend-lwjgl-natives.jar in the libs folder.

3. In Eclipse, right click the project -> Refresh. Right click again -> Properties -> Java Build Path -> Libraries -> Add JARs, select the three JARs and click OK.

4. Click the Projects tab, click Add, check the main project and click OK.

2.2.3 Android project setup

Before doing these steps, the Android SDK must first be installed.

1. Create a new Android project in Eclipse: File -> New -> Project -> Android Project. Name it appropriately (eg, "gamename-android"). For build target, check "Android 4.03". Specify a package name (eg, "com.gamename" like principal project). Next to "Create Activity" enter "AndroidGame". Click Finish.

2. Go to the project folder on the file system and create a subfolder named libs. From the nightly zip, place gdx-backend-android.jar and the armeabi and armeabi-v7a folders in the libs folder.

3. In Eclipse, right click the project -> Refresh. Right click again -> Properties -> Java Build Path -> Libraries -> Add JARs, select gdx-backend-android.jar and click OK.

4. Click Add JARs again, select gdx.jar under the main project and click OK.

5. Click the Projects tab, click Add, check the main project and click OK twice.

6. Click the Order and Export tab, check the main project.

Note: The folder really must be called "libs", a naming convention forced on us by the Android Eclipse plugin.

2.2.4 Asset folder setup

The Android project has a subfolder named assets, which was created automatically. Files available to the Android application must be placed here. This is problematic, because these same files must be available to the desktop application. Rather than maintain two copies of all the files, the desktop project can be configured to find the assets in the Android project:

1. On the desktop project, Properties>Java Built Path Click the Source tab, click Link Source, Browse, select the "assets" folder from your Android project and click OK.

2. Specify "assets" for the folder name and click Finish then OK.

2.2.5 Creating a game

In your main project, create a new class: right click the project -> New -> Class. Name it "Game" and specify a package ("com.gamename" the name of the package must be like the android project). Next to Interfaces, click Add, choose ApplicationListener, and click OK.

It

will look like this:

import com.badlogic.gdx.ApplicationListener;

public class Game implements ApplicationListener { public void create () { }

public void render () { }

public void resize (int width, int height) { }

public void pause () { }

public void resume () { }

public void dispose () { }}

These methods allow you to setup and render your game. Since they are empty, this particular game is simply a blank screen. We will first get this simple game running before doing something more interesting.

2.2.6 Running the game on the desktop

Right click the desktop project -> New -> Class. Name it DesktopGame and specify a package ("com.gamename" like principal project). Click public static void main. Click OK. Make the class look like this:

import com.badlogic.gdx.backends.lwjgl.LwjglApplication;

public class DesktopGame { public static void main (String[] args) { new LwjglApplication(new Game(), "Game", 480, 320, false); }}

This code creates an LwjglApplication, gives it an instance of your game, a title, and size. The "false" means we aren't using OpenGL ES 2.0 (we will use 1.0/1.1).

To run the game on the desktop, right click the project -> Debug As -> Java Application. You should get a black window titled "Game".

2.2.7 Running the game on Android

Open the AndroidGame class in the Android project that was automatically created and make it look like this:

import com.badlogic.gdx.backends.android.AndroidApplication;

public class AndroidGame extends AndroidApplication { public void onCreate (android.os.Bundle savedInstanceState) { super.onCreate(savedInstanceState); initialize(new Game(), false); }}

This code is an Android activity that calls initialize, passing an instance of your game. Again, the "false" means we aren't using OpenGL ES 2.0.

To run the game on Android, right click the project -> Debug As -> Android Application. The screen will turn black, since the game doesn't yet do anything. If any errors occur running the application, they show up in the Logcat view, which can be seen by clicking Window -> Show View -> Other -> Android -> Logcat.

Si da problemas al ejecutar el emulador, crea un emulador con el mismo target que la aplicación, 2.3 o pruébalo en un dispositivo real. Comprueba también que el orden exacto de las entradas en la pestaña Order and Export tal y como aparece en la imagen

2.2.8 Updating libgdx

At some point you may want to update libgdx to the latest. To do this, download the nightly zip again and update these files in your projects:

Project Files

main libs/gdx.jarlibs/gdx-sources.jar

Android libs/gdx-backend-android.jarlibs/armeabi (directory)libs/armeabi-v7a (directory)

desktop libs/gdx-natives.jarlibs/gdx-backend-lwjgl.jarlibs/gdx-backend-lwjgl-natives.jar

Para consultar la API de LibGdxhttp://libgdx.badlogicgames.com/nightlies/docs/api/

3. THE APPLICATION FRAMEWORK

Libgdx allows you to target multiple platforms, like desktop operating systems, Android or the browser. Each platform has different mechanisms when it comes to setting up the application's window, processing user input, interacting with the file system, audio playback and so on.

3.1 BACKENDS

Libgdx trata de abstraer las diferencias a través de un conjunto de interfaces que ocultan los detalles de la plataforma. Para cada plataforma, hay un backend implementando estas interfaces. Un desarrollador de aplicaciones no se refiere a los backends directamente, sino que se desarrolla contra estas interfaces.

Libgdx currently supports 4 backends:

Lwjgl : builds upon the Lightweight Java Gaming Library, which is a JNI wrapper around the platform specific windowing toolkit, OpenGL and OpenAL among other things. This backend runs on Windows, Linux and Mac OS X, provided a Java runtime is available, and a graphics card supporting at least OpenGL 1.5 is installed.

Jogl: builds upon Jogl 1.1, another wrapper JNI wrapper around OpenGL and Swing as well as the OpenAL bindings of LWJGL. It also aims at Windows, Linux and Mac OS X. The Lwjgl backend is now preferred, as it is more stable, especially when it comes to fullscreen applications.

Android: builds upon the Android APIs.

HTML5: builds upon GWT, SoundManager 2 and the updated GWT WebGL and Local Storage bindings of the Quake 2 GWT port. This backend will compile the Java code to pure Javascript code. The end-product will run in Chrome, Safari, Firefox and the latest Opera release and any other browser that supports WebGL. Due to the nature of GWT and Javascript, there are a few limitations when using this backend, see https://github.com/libgdx/libgdx/tree/master/backends/gdx-backends-gwt/issues.txt

3.2 MODULES

At its core, libgdx consists of five interfaces that provide means to interact with the operating system. Each backend implements these interfaces.

Marco de Aplicación, que manejará el bucle principal y además estará encargado del clico de vida, es decir, los eventos de creación,destrucción, pausa y resume de la misma.

Un componente de Gráficos que nos permitirá gestionar la representación de imágenes y objetos gráficos en la pantalla.

Un componente de Audio, que nos facilitará el acceso a los sonidos y música de la aplicación.

Un componente de de Entrada y Salida para leer y escribir los diferentes ficheros de datos como por ejemplo, imágenes, archivos de configuración, sonidos, música, texturas,...

Un componente de Entrada que gestionara la entrada a través del teclado, pantalla tácil o acelerómetro.

3.3 STARTER CLASSES

The only platform specific code that needs to be written, are so called starter classes. For the desktop this might look something like this, using the Lwjgl backend:

El único código específico para cada plataforma que es necesario escribir, son las llamadas clases de incio, starter clases.

public class DesktopStarter { public static void main(String[] argv) { LwjglApplicationConfiguration config = new LwjglApplicationConfiguration(); new LwjglApplication(new MyGame(), config); }}

For Android, the corresponding starter class might look like this:

public class AndroidStarter extends AndroidApplication { public void onCreate(Bundle bundle) { super.onCreate(bundle); AndroidApplicationConfiguration config = new AndroidApplicationConfiguration(); initialize(new MyGame(), config); }}

These two classes usually live in separate projects, e.g. a desktop and an Android project.

The actual code of the application is located in a class that implements the ApplicationListener interface (MyGame in the above example). An instance of this class is passed to the respective initialization methods of each backend's Application implementation (see above). The application will then call into the methods of the ApplicationListener at appropriate times (see The Life-Cycle).

El código principal del juego, está implementado en una clase que implementa la interfaz applicationListener. Una instancia de esta clase, se pasa a los respectivos métodos de inicialización, es decir a las starter clases.

3.4 ACCESSING MODULES

The modules described earlier can be accessed via static fields of the Gdx class. This is essentially a set of global variables that allows easy access to any module of libgdx. To access e.g. the audio module one can simply write the following:

// creates a new AudioDevice to which 16-bit PCM samples can be writtenAudioDevice audioDevice = Gdx.audio.newAudioDevice(44100, false);

Gdx.audio is a reference to the backend implementation that has been instantiated on application startup by the Application instance. Other modules are accessed in the same fashion, e.g. Gdx.app to get the Application, Gdx.files to access the Files implementation and so on.

4. CICLO DE VIDA DE UNA APLICACIÓN LIBGDX

Este apartado describe cómo se estructura una aplicación libgdx.

4.1 LA APLICACION

Es el principal punto de entrada para cualquier aplicación libgdx. La interfaz Application determina la plataforma y los graficos de fondo que serán utilizados por la aplicación. La interfaz también proporciona los métodos para acceder a gráficos, audio, archivos de entrada y módulos de E/S. También da acceso a un módulo de Logging el cual funciona en todas las plataformas.

LibGDX es compatible actualmente con dos back-ends de aplicaciones de escritorio (lwjgl y JOGL) y otra para Android.

Para crear una aplicación libGDX, se ha de implementar la interfaz ApplicationListener primero.

4.2 APPLICATION LISTENER

ApplicationListener es el responsable de la inicialización de la aplicación, la actualización del estado del juego (es decir, la lógica del juego), renderización de la imagen, pausado del juego, guardar el estado y la liberación de los recursos al salir de la aplicación.

Es también el lugar donde los eventos del ciclo de vida son manejados. Cada aplicación / juego, sin importar el back-end y / o plataforma de destino tendrá que implementar la interfaz ApplicationListener. La implementación es exactamente la misma para todas las plataformas.

Por tanto, Application es responsable del circuito de juego y ApplicationListener es el lugar donde se implementa la lógica del juego.

La implementación de la interfaz ApplicationListener

Los eventos que son tal como se describe:

create (): Se llama una vez cuando se crea la aplicación.

resize(int width, int height): Se llama a este método cada vez que la pantalla del juego cambia su tamaño y el juego no está en el estado de pausa. También se le llama sólo una vez justo después del método create (). Los parámetros son la nueva anchura y altura de la pantalla.

render (): Método llamado por el bucle del juego de la aplicación cada vez que se renderiza. La actualización del juego también tiene lugar aquí antes de la representación real.

La palabra renderización es una adaptación al castellano del vocablo inglés "rendering" y que define un proceso de cálculo complejo desarrollado por un ordenador destinado a generar una imagen o secuencia de imágenes.

Habitualmente se utiliza esta nomenclatura para definir el proceso por el cual se pretende imitar un entorno tridimensional, formado por estructuras poligonales, luces, texturas y materiales, simulando ambientes y estructuras físicas verosímiles. También se suele utilizar para procesos 2D que requieren cálculos complejos como la edición de vídeo, la animación o el desarrollo de efectos visuales.

pause (): El método de pausa se llama justo antes que se destruya la aplicación. En Android se llama cuando el botón de inicio se presiona o haya una llamada entrante. En el escritorio se llama justo antes de dispose () al salir de la aplicación. Es un buen lugar para guardar el estado del juego en Android, ya que no se garantiza que sea reanudado.

resume(): Este método es llamado sólo en Android, cuando la aplicación recibe el foco. En el escritorio este método no será llamado nunca.

dispose (): Se le llama cuando la aplicación se destruye. Es precedido por una pausa ().

4.3 CICLO DE VIDA DE UNA APLICACION

Los métodos antes mencionados son invocados por la aplicación durante su ciclo de vida.

El siguiente diagrama muestra las diferentes fases por las que pasa una aplicación libGDX:

4.4 WHERE IS THE MAIN LOOP?

Libgdx is event driven by nature, mostly due to the way Android and Javascript work. An explicit main loop does not exist, however, the ApplicationListener.render() method can be regarded as the body of such a main loop.

El bucle principal en Libgdx no existe como tal, pero el método ApplicationListener.render() puede ser visto como el bucle principal.