Encontronazos con ActionScript 3: El sistema de dibujo y los Display Objects

Este artículo es la parte 2 de 6 de la serie Encontronazos con ActionScript 3

Oops! - Part II by Kyle May

Hace ya bastante tiempo que salió ActionScript 3 (AS3) y los programas que lo utilizan, como Flash CS3 y Flex 3. Hasta hace poco no había tenido el chance de revisarlos un poco, y experimentar con una técnica que voy a utilizar dentro de poco. Para aquellos que conocen ActionScript 2 (AS2), su versión 3 es un campo de minas totalmente distinto 🙂 .

AS 3 cambia el concepto de dibujar cosas en la pantalla y colocar clips. El sistema de AS3 es más explícito, al crear el concepto de Display List. El Display List es una lista que se recorre cada vez que se dibuja un frame (o fotograma) en la pantalla. El recorrido de esta lista asemeja el recorrido de un árbol, en el que en el tope se encuentra la película principal, también conocido como el Stage. La lista la conforman objetos que se pueden dibujar. Algunos de ellos contienen sus propias listas de dibujo que son recorridas cuando se dibuja un frame.

Por ser una estructura muy similar a la de un árbol, los objetos se agregan y se eliminan en lo que llamaremos contenedores. Entonces, el proceso para crear y agregar MovieClips se simplifica:

  1. Se crea una película con una llamada a new MovieClip(); y se asignan las propiedades que tenga.
  2. Se agrega esta película al contenedor, como otro MovieClip o al Stage si no hay nada más en la pantalla. Esto se hace con la función addChild() en el contenedor, o addChildAt() si se quiere hacer en un lugar específico.

¿Cuál es la ventaja de esta aproximación a los gráficos con respecto a AS2? Que es más fácil de comprender. El concepto de «profundidad» (depth) que había en AS2 no se utiliza aquí: el orden en el que se dibujan los objetos está determinado por el orden en el que están insertados en su respectivo contenedor.

AS 3 tiene un enfoque mucho más estricto que su versión anterior con respecto a la orientación de objetos. La programación en AS 3 es 100% orientada a objetos, cosa que gustará mucho a aquellos que ya programan en lenguajes como Java. Ellos van a encontrar que ActionScript 3 va a tener una forma muy similar de programación. En futuros artículos iremos complementando esta información.

Para saber más acerca de los Display Lists, consultar los Livedocs de Adobe concernientes a los Core Display Classes.

* Foto por Kyle May

Usando bitmaps en Flash

[SWF]/wp-content/uploads/2008/06/test.swf, 400, 200[/SWF]

A partir de estos días estaré aprendiendo a utilizar Bitmaps en Flash. A diferencia de la programación usual en Flash, ej. dibujos vectoriales, la programación con bitmaps tiene sus particularidades. La idea es hacer cosas con un estilo pixel art. Lo retro es bonito. Estoy comenzando a leer, y conseguí una serie de 2 partes extremadamente básica para manipular Bitmaps en Flash, pero necesarias si no se conoce mucho del tema: Jugando con Pixels (I), y Jugando con Pixels (II). Sirve también la documentación Livedocs de Adobe: Las clases Bitmap y BitmapData.

Open Screen Project explicado

Adobe acaba de lanzar el proyecto Open Screen. Aparentemente hay mucha emoción por esta noticia, e incluso salen algunas medias verdades como que Flash Player será abierto, y demás. No ayuda a la comprensión de la noticia el hecho de que esa página esté llena de un montón de palabrería corporativa, en vez de responder ciertas preguntas con un Sí o un No. Me tomo la molestia de explicar algunos puntos de esta noticia, y el alcance que puedan tener para la comunidad que desarrolla con Flash.

La clave del proyecto Open Screen está en las 4 cosas que hará Adobe para apoyar el proyecto (tal como lo especifica en el FAQ del proyecto):

  • Remover las restricciones del uso de las especififcaciones SWF y FLV/F4V.
  • Publicar las APIs de la capa de port de dispositivos de Adobe Flash Player.
  • Publicar el protocolo Adobe Flash Cast y el protocolo AMF para servicio de datos robusto.
  • Remover los cargos de licencia, haciendo gratis los próximos releases para dispositivos de Adobe Flash Player y Adobe AIR.

Las especificaciones SWF y FLV/F4V

Como bien lo dice el FAQ, Adobe está publicando las especificaciones del formato SWF desde 1998. El problema es que esta publicación estaba sujeta a la restricción de que sólo se podían publicar programas que «escribieran» SWF; es decir, no era posible publicar programas que reprodujeran SWF (y que por ende compitieran con Flash Player). Bajo estas restricciones programas como swfmill y mtasc fueron publicados.

Esta restricción a partir de hoy ha sido levantada, por lo que de ahora en adelante será permitido publicar reproductores del formato SWF. Supongo que proyectos como Gnash, un reproducto GNU de SWF, se beneficiarán de esta noticia.

Con respecto al formato FLV, es un formato de archivo para medios como audio y video, el cual soporta H.264 y HE-AAC, y varios tipos de codecs para video. F4V es la versión con protección de derechos de autor de FLV. Aunque no conozco mucho sobre este formato, supongo que a partir de ahora veremos más codificadores para FLV que Sorenson.

Las especificaciones de SWF y de FLV se encuentran en sus respectivas páginas: SWF Technology Center, y FLV/F4V Technology Center.

Device porting layer APIs para Adobe Flash Player y la remoción de los cargos de licencia

El verdadero objetivo de todo este proyecto es entrar en el campo de los dispositivos portátiles, un campo muy competido, y sus contendores principales son las plataformas Java y BREW. El esfuerzo inicial de Macromedia (ahora Adobe) es Flash Player Lite, basado en Flash Player 4.

La publicación de un API para facilitar el port de Adobe Flash Player, junto con su precio gratuito para licencia, facilitará y masificará la implementación de esta plataforma en los celulares. Los fabricantes tendrán la última palabra en este asunto, pero Flash tiene la ventaja de que la barrera de aprendizaje es baja, el público desarrollador principalmente compuesto de diseñadores gráficos, y que SWF es un formato fundamentalmente vectorial (resolviendo el problema de las diferencias de resolución de los dispositivos). Yo creo que veremos más de esta plataforma en el futuro.

Protocolos Adobe Flash Cast y AMF

AMF es el protocolo de Adobe para hacer llamadas remotas (RPC) a servidores web. El proyecto Red5 ya es un esfuerzo maduro en relacionar los objetos en ActionScript y los objetos en Java de un servidor. Adobe recientemente lanzó el proyecto BlazeDS para ocupar este espacio que tenía vacío. BlazeDS es un conjunto de librerías que facilita el intercambio de información entre una aplicación en SWF y un contenedor Java de aplicaciones web (tal como Red5). BlazeDS tiene código abierto, y se puede descargar en su página oficial.

Por su parte, el protocolo AMF como tal ya está publicado en la página correspondiente.

Desconozco si Adobe Flash Cast tiene que ver con RTMP (Real Time Messaging Protocol), el protocolo propietario de Adobe para transmitir streams de audio y video. De ser así, esto será un grandísimo beneficio para Red5, que ha tenido que sobrevivir hasta ahora haciendo ingeniería inversa del protocolo.

El protocolo Adobe Flash Cast todavía no ha sido publicado. Ya habrá tiempo de analizar esta iniciativa cuando publiquen este protocolo. (Y qué demonios querrán decir con todo esto 🙂 )

Conclusiones

En fin, el anuncio del proyecto Open Screen es un gran avance de Adobe en el dominio de Flash en el mercado web, y al mismo tiempo un acercamiento a la comunidad de desarrolladores que ciertamente ha contribuído con este dominio. Es un gran anuncio, eso sí, para aquellos interesados en software libre que utilice estos formatos.

Herramientas para hacer juegos multiplayer en Flash

Si ya has hecho un juego para Flash, este artículo seguramente te interesará. Probablemente ya hiciste un juego para esta plataforma, y tienes curiosidad por incluir a varios jugadores en un mismo juego.

Hacer juegos multiplayer en Flash ciertamente requiere algo más que el editor de Flash, pues los compilados que se publican no poseen las capacidades necesarias para fungir de servidores. En otras palabras, no es posible hacer conexiones y obtener datos utilizando solamente los SWFs que saca Flash, debido a obvias restricciones de seguridad. En términos simples, no quieres estar recibiendo alegremente conexiones de otras partes del mundo mientras usas Flash en una página.

Conexiones a servidores de Flash
Los SWF que publica Flash no pueden conectarse a las computadoras de otras personas. Necesitamos un servidor que haga esta tarea.

Luego, la solución indicada es tener un servidor al que todos los SWFs se puedan conectar y desconectar. Inicialmente, Macromedia (ahora Adobe) lanzó el Flash Communication Server, luego rebautizado como Flash Media Server. Este servidor tiene excelentes características para desarrollar una aplicación multiusuario, ya que utiliza una versión del lenguaje Actionscript para el servidor. Ahora, estamos hablando de que una licencia cuesta varios miles de dólares.

Red5 logo Es entonces cuando podemos ver otras alternativas más económicas e igualmente útiles. La primera y más popular es el proyecto Open Source llamado Red5. Red5 es funcionalmente un clon de Flash Media Server, y está basado en Java. Requiere el ambiente de ejecución de Java (el JDK) para poder correr. Esto tiene varias implicaciones: es necesario saber bastante de Java para poder aprender los conceptos de Red5 y poder programar aplicaciones en este servidor. La otra implicación es que se requiere de una compañía de hosting que ofrezca hospedar aplicaciones en Java, cosa que sabemos no es tan común como los planes con ASP o PHP.

Con respecto al primer punto, sin embargo, Red5 ha resuelto el problema en parte ofreciendo maneras de interpretar varios lenguajes para hacer las aplicaciones. Javascript, Ruby y Python son algunos de estos lenguajes, por lo que se puede aprovechar el conocimiento que ya se tienen de estos y no tener que aprender Java.

Con respecto a la documentación, está todavía en desarrollo, y aunque hay muy buen material que viene con el servidor, hace falta organizarse, leerlo y digerirlo varias veces.

SmartFoxServer Lite logo Otra alternativa, ya comercial, es SmartFoxServer. Esta gente provee un servidor también basado en Java, pero la programación se concentra principalmente en los clientes, de acuerdo a lo leído en la documentación. Tiene también soporte para programar en Actionscript para el servidor. Su versión PRO, que es la que trae la mayor cantidad de características, tiene una licencia ilimitada por un costo mucho menor al Flash Media Server, y además ofrecen las versiones BASIC y LITE, siendo la BASIC mucho más económica y la LITE completamente gratuita. SmartFoxServer se publicita principalmente a través de la página gotoAndPlay(), en donde hay una variedad de juegos creados con su servidor, tutoriales, y un foro de soporte. En fin, no me parece una solución descabellada.

Probablemente hayan otros servidores por allí, pero al menos sé que Red5 está comenzando a formar una comunidad de gente, y es una alternativa totalmente factible para hacer aplicaciones multiusuario.

Unity: Desarrollo de juegos 3D en Macs

Unity Logo

Unity ya ha hecho algo de ruido dentro de la comunidad desarrolladora de juegos, principalmente por ser una herramienta basada en Macs, una plataforma que tradicionalmente ha desfavorecido el desarrollo de juegos.

Unity, sin embargo, ha tomado una aproximación bastante acertada al desarrollo de un juego. Es un editor predominantemente visual, incluyendo librerías físicas (provistas por PhysX), librerías gráficas que soportan modelos 3D de populares paquetes, y scripting basado en Mono, una implementación Open Source de .NET. Lo último, en cristiano, es que se pueden hacer scripts en el lenguaje de tu preferencia, que Unity lo va a entender. Promete también acceso fácil a los shaders.

¿Alguno con Mac le ha dedicado algún tiempo a probar este programa?

¿Cómo aprender un lenguaje de programación? Haciendo un juego

Aprender un nuevo lenguaje de programación es una tarea que constantemente se hace durante la carrera de un programador profesional. Y a pesar de que esto es así, esta tarea nunca es repetitiva. Todos los lenguajes tienen pequeñas diferencias entre sí que pueden representar un reto para el programador, o volverlo loco. Y es que la mayoría de las situaciones en las que uno aprende un lenguaje se deben a una obligación, ya sea académica o laboral, y en etapas donde la urgencia es grande y las posibilidades de tomárselo con calma son pocas.

Sin embargo, les tengo una estrategia para aprender un lenguaje de programación: hacer un juego. Sólo es necesario un poco de tiempo extra. Un juego tiene algunas complicaciones extra que las aplicaciones comunes no tienen, por lo que esta es una estrategia similar a la que haría un deportista: entrenar más allá de lo necesario para poder enfrentar otros retos sin tanto esfuerzo. Y lo que propongo es más divertido que hacer pesas.

Les voy a presentar 3 casos donde he aplicado esta metodología, con un buen grado de éxito y muchísima diversión. Esto, por supuesto, es mi caso particular, es decir, los resultados pueden variar. Comencemos.

Cómo aprendí Java

Cuando terminé mi primer curso universitario directamente relacionado con programación, donde tuve que aprender a utilizar Java, me quedé con las ganas de saber más sobre este lenguaje. Siempre había tenido interés por «hacer juegos», un área que para mí en ese momento era todavía muy difusa. El hecho es que este interés me llevó a hacer mi primer juego hecho «con seriedad». El resultado fue un juego de UNO muy sencillo al que le fui agregando algunas cosas, y terminó con algunas reglas que aplicaba cuando hacía partidas con los amigos.

UNO for Java screenshot
Parte de un screenshot del juego.

Cuando terminé de hacer este juego, había aprendido muchísimo sobre la librería Swing de interfaces gráficas, y comencé a experimentar de primera mano sobre lo que hay que hacer para implementar un juego: estructuras de datos y algoritmos.

Cómo aprendí C

Tiempo después, por una serie de eventos desafortunados, me encontré en una situación en la que no podía ver clases, así que disponía de mucho tiempo libre. A mis manos llegó un excelente tutorial de cómo hacer raycasting, la técnica que utiliza Wolfenstein 3D para hacer sus gráficos. Debido a que pronto en otro curso iba a utilizar el lenguaje C, pues decidí aprenderlo haciendo este tutorial, y escogí la librería Allegro para las rutinas gráficas.

El proceso fue divertidísimo, y el resultado fue haber aprendido a programar en C, sin pensar en orientación a objetos. Concluí que Allegro es una buena librería para implementar juegos. Cuando comencé el curso donde requería usar este lenguaje, ya tenía un dominio relativamente decente de los apuntadores y otras cosas que lo enredan a uno cuando está aprendiéndolo.

Raycaster screenshot
Screenshot del raycast cuando lo estaba trabajando.

Cómo aprendí Python

El cómo estoy aprendiendo Python lo han presenciado ustedes a través de CuteGodChigüire, el juego tipo God que he estado haciendo y del que he hecho una crónica de desarrollo. A diferencia de los otros dos, ustedes tienen la ventraja de que pueden leer cómo se ha implementado el juego paso a paso.

Las Complicaciones

Como dije en un principio, los juegos presentan complicaciones que otras aplicaciones no tienen. Cuando no se sabe cómo implementarlo, un juego puede parecer algo impenetrable. Lo cierto es que un juego comienza como algo sencillo: un conjunto de estructuras de datos y un algoritmo que las actualiza constantemente, un algoritmo que implica un ciclo infinito que chequea al final si la meta del juego se cumplió. Agregar reglas de juego e implementar efectos como animaciones, transiciones y otras cosas van complicando la tarea. Lo bueno de esta metodología es que uno puede parar en el momento que uno siente que ya está en capacidad de poder escribir en el lenguaje.

La otra complicación puede ser ubicar una librería gráfica que facilite la tarea de programación. En la época que aprendí Java no habían muchas opciones de librerías, pero hoy en día sí las hay. En C/C++ están SDL o Allegro, y existen una variedad de bindings de estas librerías a otros lenguajes, por lo que hay excusa para aprender estos lenguajes también.

En este momento les dejo estas preguntas: ¿vale la pena hacer un juego para aprender un lenguaje de programación?, ¿lo has hecho y te ha beneficiado?, ¿ves otras complicaciones que no he cubierto aquí?, ¿estoy diciendo una loquera?. Dejo este espacio abierto para comentar esta propuesta.

Accediendo a los subpixels con Pygame mediante SubPixelSurface

Una de las limitaciones que posee Pygame, una librería para desarrollar juegos con Python, a la hora de dibujar sprites en pantalla es que sólo es posible hacerlo en coordenadas enteras. Esto, para algunos sprites pequeños, ej. partículas, es un salto demasiado grande y se ve feo en la pantalla. Will McGugan, de Where there is a Will, escribió un pequeño paquete que toma una superficie (un Surface) de Python y lo transforma en una superficie capaz de dibujar objetos con coordenadas fraccionales, justo como lo harías con OpenGL u otra librería 3D. Al hacer este procedimiento con el código de Will, el objeto mismo hace el cálculo de los subpíxeles, y combinado con la animación que le des al objeto el resultado es un movimiento muy suave, como lo demuestra un GIF de ejemplo a continuación:

Will McGugan SubPixelSurface DemonstrationWill McGugan SubPixelSurface DemonstrationWill McGugan SubPixelSurface DemonstrationWill McGugan SubPixelSurface DemonstrationWill McGugan SubPixelSurface Demonstration

Las pelotas de encima están dibujadas mediante sub-pixeles, y las pelotas de abajo con coordenadas enteras. La diferencia en la suavidad de movimiento es notable. Requiere el módulo Numpy para poder funcionar. También tiene la desventaja que el precálculo hecho a cada superficie requiere una buena cantidad de memoria, específicamente 9 veces más que una superficie normal para el nivel por defecto de precisión, por lo que es manejable para superficies relativamente pequeñas.