Home » Guías » Guía de Playground (II): prototipos de apps y juegos
Playground II, Prototipos de Apps y Juegos

Guía de Playground (II): prototipos de apps y juegos

Ya hemos aprendido cómo funciona un playground para hacer prototipos de código y probar su correcta funcionalidad, tanto si usamos una versión anterior de Xcode 6, como a través del nuevo y práctico formato en Xcode 6.3. Pero solo sabemos hacer prototipos de código, ¿qué pasa si queremos probar una app o un juego completo? ¿Puede hacerse?

Se puede a través de una librería propia llamada XCPlayground que nos permite una salida estándar como si de una pantalla se tratara, para ver los resultados en tiempo real y ver nuestro juego o interfaz de app funcionando.

Consideraciones previas

Hemos de tener en cuenta varias cosas, la primera de ellas la estabilidad. En la actual versión 6.3.1, los playground, cuando se les fuerza mucho como vamos a hacer ahora empiezan a tener problemas de estabilidad y puede que nos encontremos cosas raras como errores fantasmas donde se nos indica error en un línea sin más explicación (aunque luego funcione) o que de pronto te diga que el archivo ha sido grabado por otra fuente. Así que hemos de tener paciencia porque lo que vamos a hacer es “forzar la máquina” aunque el resultado que podemos obtener de ello puede ser sumamente productivo.

Cuando trabajemos en prototipar, podemos hacerlo tanto en OS X como en iOS. La diferencia es que en OS X tendremos una ventana real en el editor asistente con el resultado en tiempo real pero habrá determinadas funciones como todas las que pertenecen a UIKit que no podremos usar.

Por ejemplo, si queremos cambiar el color de un elemento no podremos usar UIColor si no su equivalente para OS X que es NSColor. Porque de hecho, UIKit no existe en OS X (todavía). Si trabajamos con OS X el primer import es Cocoa y no UIKit que es exclusivo de iOS. Eso implica que hay determinadas funciones, elementos y constructores que no son los mismos. En SpriteKit sí tenemos paridad de elementos, pero en cuanto a crear apps, no.

Si prototipamos en iOS pasará algo muy curioso. El resultado se mostrará en el editor asistente pero el sistema abrirá el simulador de iOS como puente para interpretar el código y hacer una especie de espejo entre el playground y el simulador. Conectará la salida de imagen del simulador al playground, básicamente. Ahora, si abrimos este, veremos que muestra imágenes sin sentido, flickeos y un comportamiento que nos podría hacer pensar que algo va mal. Nada de lo que preocuparse. Lo mejor es minimizar el simulador y listo.

Prototipo de un juego

Vamos a crear un nuevo playground, le decimos que sea para iOS y lo llamamos como queramos. Ahora vamos a configurarlo. Pulsamos CMD+1 para que nos muestre el navegador de archivos para poder incorporar los recursos que queramos y luego mostramos el editor asistente en el menú View -> Assistant Editor -> Show Assistant Editor.

Run in Full Simulator

Por último tenemos que mostrar el editor de objetos para poder acceder a la propiedad que permita al playground funcionar con el simulador. Vamos a View -> Utilities -> Show Utilities. Una vez ahí, pulsamos en el pequeño folio del File Inspector arriba y veremos un indicador que dice: Playground Settings. Debajo en Platform está seleccionado iOS y debajo hemos de marcar Run in Full Simulator. Nada más.

Ahora volvemos al código y borramos las líneas convencionales que siempre tenemos y lo primero que tenemos que hacer es importar SpriteKit y XCPlayground que es la librería a través de la cual crearemos la ventana que nos permitirá ver los resultados.

Ahora tenemos que crear una vista de SpriteKit, una SKView de un tamaño estándar como 1024×768 (si lo queremos en modo vertical, 768×1024) y tras esto hemos de asociar dicha vista al proceso de XCPlayground para que nos muestre los resultados, uniendo ambas vistas.

El nombre Live es simplemente a título de referencia por si queremos referirnos a esta vista en otro momento y view es el nombre de la vista **SKView que hemos creado.

Ahora, al igual que haríamos en un proyecto de SpriteKit real, tenemos que crear una escena con el mismo tamaño de la vista SKView que hemos creado y asociado al playground, establecer su modo de escalado y si queremos, incluso el color de fondo que tengo la costumbre de dejar en blanco.

Creamos la escena con el tamaño (propiedad size) de la propia vista SKView llamada view a través de su propiedad bounds. Establecemos el color con SKColor y su método whiteColor que nos devuelve directamente el color blanco y establecemos el modo de escalado en .AspectFit para que respete el tamaño y proporciones de lo que dibujemos. Por último, presentamos la escena en la vista.

Ya estaría preparado. Este código es el mismo siempre para todos los prototipos de juego que queramos hacer donde lo único que necesitaremos cambiar es el tamaño o el color. Todo lo demás es aplicable a todos los juegos que queramos probar.

A partir de aquí podemos trabajar libremente con SpriteKit: añadir sprites, moverlos, añadir físicas… lo que queráis. Toda la acción se compilará y podremos verla corriendo en la ventana correspondiente.

Lo que tenéis que tener en cuenta es que los playground no tienen interacción de usuario, por lo que no podréis tocar la interfaz para que haga cosas, solo usar escenas que corran de manera automática.

Lo único que has de tener en cuenta es que el clásico self.addChild debe ser sustituido por scene.addChild ya que en este caso scene es el contenedor de todos los elementos.

Prototipo de una app

Los prototipos de app también son posibles, principalmente cuando queremos crear una interfaz de manera programada y no a través de alguno de los constructores. De nuevo hemos de tener en cuenta que si ponemos un botón con su acción esta será ignorada porque no podremos pulsarlo en manera alguna. Lo primero que hemos de hacer es importar la librería de las interfaces.

Prototipo de AppAhora ya podemos crear interfaces y, esto también es muy interesante, probar cualquier animación de Core Animation y ver el resultado. Para ello, hemos de crear la vista UIView y añadir los elementos a esta además de pasarla a XCPShowView.

Así de simple y sin necesidad de nada más. Ahora podemos crear botones, etiquetas o lo que queramos y simplemente hacer una instrucción view.addSubview para añadir la vista del elemento a la padre principal. Por ejemplo, podemos usar view.addSubview(label) si queremos añadir una etiqueta que se llame label, por ejemplo.

También podemos evaluar la vista poniendo su nombre y dándole al +, con lo que podremos ver la interfaz dibujada en pequeño en la parte inferior. Otra forma de verificar que esta se dibuja bien aunque en este caso las animaciones no funcionarán.

Conclusiones

Lo más importante de todo, si trabajamos con iOS, es que esté marcado Run in Full Simulator. Esto garantizará que las animaciones que podamos incorporar funcionen. Y además, podremos mover en el deslizador de la parte inferior para comprobar la progresión que ha tenido la animación o movimiento.

Usar el prototipado nos ayudará mucho a probar cualquier implementación de una manera rápida y, sobre todo, a ajustarla. Y por cierto, tened paciencia porque os daréis cuenta que los playground aun necesitan afinarse más y si se os cuelga el Xcode o hace cosas raras no os extrañéis. El problema no es vuestro.

Como siempre os decimos, probad y jugad, y veréis el enorme potencial que tiene. Hasta la próxima y Good Apple Coding.

Acerca de Julio César Fernández

Analista, consultor y periodista tecnológico, desarrollador, empresario, productor audiovisual, actor de doblaje e ingeniero de vídeo y audio.

Otras recomendaciones

Prototipos Unit Testing TDD

Lecciones por prototipos (II): test unitarios (XCTest y TDD)

Una de las cosas que normalmente se perciben más complejas en el desarrollo en cualquier …