UDev 2

0 Portada contraportada staff:Pรกginas maqueta 30/12/2010 16:13 Pรกgina 1

U โ ข DEV Nยบ 2

0 Portada contraportada staff:Pรกginas maqueta 30/12/2010 16:13 Pรกgina 3

0 Portada contraportada staff:Páginas maqueta 30/12/2010 16:29 Página 2

UDEV Cargo: Director Nombre: David Collado e‐mail: webmaster@unityspain.com

EDITORIAL Aquí estamos, con un nuevo número de Udev, tres meses después del primero. Me siento orgulloso de compartir con toda la comunidad esta nueva edición cargada de conteni‐ dos; entre ellos, una interesante entrevista a unos persona‐ jes muy conocidos dentro del sector: los TornadoTwins.

Además de con buenos artículos contamos con la partici‐ pación de la comunidad, que ha sido mayor en este número, tendencia que confío se mantenga en próximos números.

Cargo: Editora Nombre: Ángela Espelta e‐mail: wolveskiller.osk@gmail.com

Cargo: Maquetador Nombre: Eduardo Echevarría e‐mail: eduetxbe@gmail.com

Cargo: Ilustrador Nombre: Javier Moreno e‐mail: freemindart@hotmail.com

Tengo que dar las gracias a mucha gente; empezando por nuestro maquetador, que realiza un trabajo más que notable dedicando su tiempo libre a dar forma a la revista; a nuestra editora, siempre revisando y puliendo con paciencia cada detalle, y no puedo tampoco dejar de agradecer el trabajo de nuestro ilustrador cuyo talento no tiene límite, tal y como demuestra día a día.

Sin embargo, el mayor agradecimiento es para los redac‐ tores, que colaboran desinteresadamente en el crecimiento de Udev con sus estupendos artículos, y sobre todo para vosotros, lectores (y quizá futuros colaboradores). Sin vos‐ otros, todo este esfuerzo no tendría sentido.

No quiero alargarme más; como siempre, espero que dis‐ frutéis de este número y que os animéis a participar en el siguiente. ¡Un saludo!

EN ESTE NÚMERO

David Collado, Director

CONTENIDO Artículo: Entrevista Tornado Twins Nombre: Tornado Twins web: www.tornadotwins.com

Artículo: ¿Cómo se hace?

Nombre: Jesús Pancorbo e‐mail: yosoy_chusti@hotmail.com

1. Unite 2010

4

2. Entrevista Tornado Twins

7

3. Eyes Bandegades

11

4. ¿Como se hace? Product Sheet (parte2)

16

5. Tutorial: Streaming con unity

19

6. Introducción a iTween

25

4 Articulo Unite:Páginas maqueta 30/12/2010 15:57 Página 4

REPORTAJE

Unite DAVID COLLADO

UNITE Aunque ya ha pasado un tiempo desde la keynote de Unite 2010, creo que será in‐ teresante hablar de ella y dejar claros al‐ gunos detalles que quizá no quedaron muy claros en un primer momento.

sido el caso. El palabras de Helgason: “Sim‐ plemente ha enriquecido y hecho mejorar la comunidad” ”Estos nuevos usuarios fueron a aprender, enseñar y ser de utilidad para la comunidad”.

En la conferencia inaugural de Unite 2010 en Montreal, el director ejecutivo de Unity, David Helgason anunció algunas mejoras para el motor, además de una nueva inicia‐ tiva llamada Union, que ayudará a los de‐ sarrolladores a llegar a los dispositivos a los que no podían llegar antes.

Unity 3 se puso a la venta hace poco y ya es muy fuerte. El plug‐in para poder jugar a juegos de Unity en la web ha llegado a la cifra de 2.5 millones de instalaciones al mes, 1 por segundo, llegando a un 30% de los jugadores de internet. 40 millones de plug‐ins se han instalado a día de hoy.

En primer lugar, Helgason dió algunas es‐ tadísticas interesantes: la conferencia de Unite, la cuarta, contó con 650 partici‐ pantes, entre ellos personal de Unity. En el último año, desde que la compañía liberó una versión gratuita del motor, su audien‐ cia ha aumentado 20 veces, de 13.000 a 260.000 desarrolladores.

El motor también está presente en 17 de los juegos top 10 de la plataforma iOS y 20 buenos juegos han sido lanzados para Android, 13 de ellos también en iOS. Las ventas del motor para Android han lle‐ gado ya a un tercio del volumen de las ventas de iOS.

Si bien en un principio hubo cierta preocu‐ pación de que esta gran afluencia de nuevos usuarios podría llegar a degradar la comunidad, desde la percepción de Unity y también de usuarios ya asentados, no ha

4

A principios del año próximo aparecerán los primeros juegos para Xbox 360 y PlayStation 3 realizados con Unity y los desarrolladores interesados pueden ac‐ ceder a estas plataformas poniéndose en contacto con el equipo de ventas de

www.unityspain.com

Unity. “Estamos controlando a la gente a un ritmo lento para asegurarnos de que podemos darles buen soporte”, dijo Helgason.

La compañía también está trabajando con Google para que sea posible que juegos de Unity funcionen de forma nativa en Chrome y se expandirá a sus tables y otros dispositivos.

La democratización del Desarrollo de Videojuegos Helgason dijo: “El objetivo que nos mueve es democratizar el desarrollo de videojue‐ gos. Trabajamos de la forma que sabemos, que es coger tecnología realmente avan‐ zada, empaquetarla, simplificarla y hacerla mejor en un modelo de negocio que nos permita seguir vivos. Somos rentables y todo va muy bien, estamos creciendo y lle‐ gando a gente nueva.”

Sin embargo, eso no es suficiente: “Hay prob‐ lemas que permanecen incluso una vez que se haya hecho el desarrollo del juego de forma sencilla” Si bien la compañía todavía

4 Articulo Unite:Páginas maqueta 30/12/2010 15:57 Página 5

DAVID COLLADO

UNITE

Un desarrollo “requiere de artistas, animadores, difer‐ entes tipos de programadores, diseñadores, etc. Tener un equipo estable es un lujo de un gran equipo con un gran presupuesto. Muchos forman parte de grandes empresas pero otros no. Nos dimos cuenta de que la solución es‐ taba en la comunidad ya existente que no solo com‐ partían herramientas, sino también arte, extensiones...”.

Todo esto era controlado fuera de Unity antes, pero ya no será así. Unity cambió esto con el lanzamiento de la Unity Asset Store, “una plataforma para el intercambio y el comer‐ cio entre los usuarios de Unity. Es una pieza bastante salvaje de software”, dijo Helgason.

Muy parecida a la tienda de iTunes o la App Store, la tienda te permite descargar, desde el interior de Unity 3.1, obras de arte y otros datos e importarlos directa‐ mente a Unity permitiéndonos trabajar con ellos casi de inmediato. Otra similitud con la App Store es la partici‐ pación en los ingresos, con un 70% para los desarrol‐ ladores y un 30% para Unity.

Además de incluir la Asset Store, la versión 3.1 de Unity cor‐ rige muchos errores y mejoras, y hay otra novedad impor‐ tarte en Unity 3.1, que “se ha mantenido en secreto porque es complejo y técnico”.

“Habrá muchos más teléfonos inteligentes, televisores con conexión a internet y decodificadores capaces de ejecutar tus juegos” Union Mientras que iOS, los navegadores y muchas otras consolas ofrecen grandes audiencias para los juegos desarrollados con Unity, esto no es todo: “Habrá muchos más teléfonos in‐ teligentes, televisores con conexión a internet y decodifi‐ cadores capaces de ejecutar tus juegos”, dijo Helgason.

con un porcentaje de ingresos 80/20. Brett Seyler dio una ex‐ plicación más completa de qué es Union: “Hoy estamos lan‐ zando Union, y eso significa que tus juegos pueden llegar más lejos que nunca antes. Realmente creo que estamos en la cúspide de algo muy grande. Al actuar juntos podemos estar entre los primeros en cualquier dispositivo”, dijo.

Para unirse solo debes contactar a Union, subir un proyecto completo y listo.

Se anunciaron cuatro relaciones de interés para Union desde el principio. Una de ellas es Nokia, que “el último trimestre envió 110 millones de teléfonos y tienen un 32% del mer‐ cado” dijo Seyler. El siguiente es NDS, un proveedor de soft‐ ware clave para decodificadores y otros dispositivos similares para la sala de estar. No es un nombre muy conocido, pero su software esta en más de 138 millones de dispositivos ac‐ tivos. Splashtom, el tercero, es “una empresa muy intere‐ sante... ofrece un arranque instantáneo del sistema operativo que ya está en más de 40 millones de PCs” de empresas como Lenovo y Dell. Por último, HP Palm, que tiene “cerca del 5% del mercado del espacio del móvil inteligente y en el lado PC, son enormes, casi el 30% del mercado.”

“Estas son sólo algunas de las empresas con las que estamos trabajando y cuando lleguen a estos dispositivos y encuen‐ tren compradores, el 80% de los ingresos netos volverá a los desarrolladores”, prometió Seyler.

Reportaje

está trabajando en la simplificación del profeso de desarrollo del juego, “sigue habiendo problemas. Y uno de esos problemas es que los videojuegos requieren de un equipo”.

Aunque esto fue lo más relevante ocurrido en Unite 2010 de cara al público general, realmente ni anuncios ni datos son el centro del evento. Unite es comunidad, es conocer nuevos desarrolladores y es aprender de manos de los propios tra‐ bajadores de Unity. Personalmente no me ha sido posible asi‐ stir, aunque me gustaría poder hacerlo en próximas ediciones y tener así la posibilidad de ofrecer una visión más cercana de este aspecto fundamental de Unite, la comunidad, tam‐ bién uno de los pilares de su gran motor.

Para los que no pudieron asistir, Unity tendrá varios vídeos disponibles muy pronto en su web, tal y como ya hicieran en anteriores ediciones y, si algún afortunado de entre vosotros tuvo la posibilidad de asistir, que no dude en compartirlo con nosotros.

“Los fabricantes de estos dispositivos saben que los juegos son importantes... pero no saben dónde ir, por lo que recurren a grandes empresas dejando fuera a la comunidad de Unity, algo muy triste. ¿Qué pasaría si todos unimos fuerzas? “ “Nos dimos cuenta de que nuestra comunidad había lanzado muchos grandes juegos en la App Store, mejores que los de grandes editoras. Esta es la razón para lanzar Union, para cap‐ turar esas oportunidades todas juntas”.

Union es un nuevo servicio a cargo de Unity, que permitirá a los desarrolladores llegar a una serie de nuevas plataformas

www.unityspain.com

5

2 Entrevista Tornado Twins:Páginas maqueta 30/12/2010 16:19 Página 7

ENTREVISTA

TORNADO TWINS TORNADO TWINS ¿Quién esta detrás de TornadoTwins?

¿Habéis asistido a Unite 2010? Si es así, ¿Cómo ha sido la experiencia?

Tras TornadoTwins están unos gemelos que han estado ha‐ ciendo juegos desde los 10 años. Hemos trabajado para al‐

No, no ha sido posible. Pero por lo que sabemos ha sido genial.

gunas de las más grandes compañías a nivel mundial y po‐ siblemente también en algunas de las más pequeñas.

¿Cuáles son para vosotros los mejores puntos de Unity?

También estamos encantados de haber iniciado nuestro pro‐

El más importante es el hecho de que la edición de assets es

pio negocio.

muy visual. Eso es para nosotros la parte más importante, no el código. Sin embargo, para nuestros propios juegos hemos des‐

¿Qué relación tenéis con Unity?

arrollado nuestros propias herramientas, por lo que no hacemos

Nos encanta Unity por encima de otros motores. Es un motor muy divertido para hacer juegos, uno de los mejores que hemos

todo dentro del motor. Actualmente utilizamos el motor para desplegar las herramientas, y luego utilizamos las herramientas para dar forma al juego. Es un ciclo curioso.

usado. Por supuesto, elegir un motor depende siempre del cliente o el juego que estemos haciendo.

¿Cómo llegasteis a Unity?

Por curiosidad, ¿habéis viajado alguna vez a España o a otro país hispanohablante? Si es así, ¿Podeis resumirnos vuestra experiencia?

Nos encantó tanto Unity que compramos equipos Mac para

Sólo hubo una vez en mi vida en la que no me gusto España:

poder usarlo, ya que entonces no había versión para Windows.

cuando mi país (Holanda) tuvo que jugar la final de la Copa

No estamos seguros de cuando exactamente empezamos a

del mundo de 2010 y perdió. Aún así España merecía ganar,

usar Unity pero creo que posiblemente fuese en 2006.

¡bien jugado!

www.unityspain.com

7

2 Entrevista Tornado Twins:Páginas maqueta 30/12/2010 16:19 Página 8

TORNADO TWINS Por otro lado he estado en Bolivia un par de veces. Por su‐ puesto no es lo mismo que España, pero también se habla castellano. ¡Me encanta el idioma!

de nuestros prefabs, la posibilidad de configurarlos al gusto. Además intentamos que el código sea sencillo de entender. Queremos que cualquiera pueda usarlos, no solo los programadores.

¿Qué os llevo a crear UnityPrefabs?

Entrevista

Hace un año comenzamos nuestro canal en YouTube para ayudar a la gente a hacer juegos. No sabíamos que llegaría a ser tan popular tan rápidamente. Fue tan popular que tuvimos que cerrar las notificaciones por email porque te‐ nemos mas de 300 mensajes al día (Más preguntas que en los foros de Unity). Para ayudar a las personas con mayor eficacia comenzamos a hacer prefabs, codificando el arte para que la gente pudiera utilizarlo para hacer sus juegos más rápido. Por supuesto, no hicimos todos nosotros mis‐ mos, contratamos a otros programadores. Así es como se convirtió en un negocio.

Para vosotros, ¿El potencial de UnityPrefabs esta en el precio o en la calidad? ¿Qué importa más a la hora de vender prefabs?

Es muy difícil hacer algo que todos pueden usar para su juego. Cada juego es único. Intentamos ayudar a todo el mundo, pero es sencillamente imposible. Así que en lugar de una “talla única para todos” hicimos nuestros prefabs muy configurables. Con sólo algunas variables puedes cambiar todo. Este es el verdadero punto clave

8

UnitySpain vende actualmente dentro de UnityPre‐ fabs, ¿Los vendedores de UnitySpain pueden vender en la asset store? ¿Qué deben hacer?

Efectivamente, UnitySpain se unió a nosotros como un ven‐ dedor oficial, además fue uno de los primeros. Si la gente quiere publicar sus prefabs a través de UnitySpain solo de‐ ben contactar a su webmaster, que sabe exactamente como vender en UnityPrefabs.com. Nosotros nos ocupamos a partir de ahí y publicamos en la asset store siempre y cuando el producto sea “exclusivo”, pues de otra forma no tenemos los derechos para representarlo.

¿Cuáles son vuestras ideas para el futuro de Unity‐ Prefabs? ¡No hemos hecho más que empezar! La siguiente cosa que estamos haciendo es una revolución en el desarrollo de juegos indie. Es un conjunto de soluciones muy inteligentes para los problemas más comunes entre los diseñadores de juegos. No puedo decir exactamente lo que es todavía, pero asegúrate de estar suscrito al newsletter de UnityPre‐ fabs.com para enterarte en el momento del lanzamiento.

www.unityspain.com

2 Entrevista Tornado Twins:Páginas maqueta 30/12/2010 16:19 Página 9

TORNADO TWINS

Acabáis de lanzar un nuevo proyecto. ¿Podríais con‐ tarnos en que consiste?

Durante los últimos 3 años hemos estado dándole vueltas a convertir la Biblia en un videojuego. No puedo creer que nadie haya hecho esto antes ya que las historias de la Biblia son perfectas para un videojuego. Hay muchas guerras y mucho más material.

Empezamos el proyecto mucho antes de que alguien nos conociera y no ha sido fácil, ya que es muy grande. Empe‐ zamos con una sola historia y esa fue la historia de…David.

En el juego jugabas como David desde que eras un pobre pastor hasta llegar a ser un rey (… y matando a Goliat, por supuesto). También tenemos algunos elementos en el juego que nunca se han hecho antes. Tendréis que esperar a la demo para verlo.

“Tenemos algunos elementos en el juego que nunca se han hecho antes” ¿Tenéis mas proyectos para el futuro? ¡Por supuesto! Siempre hacemos varios proyectos a la vez. Te‐ nemos otra historia que estamos convirtiendo en videojuego, es de ciencia ficción futurista. Este proyecto es aún muy se‐ creto.

Os sigo en Twitter y veo que habláis mucho sobre mar‐ keting enfocado a videojuegos. ¿Qué consideráis mas importante sobre ello? ¿ Que consejo daríais a alguien que quiere hacer su juego y no tiene una gran compañía detrás?

La mayoría de los desarrolladores indie ponen su esfuerzo en hacer el juego. Cuando esta terminado, lo prueban y lo envían a la App store y quizás a algún otro sitio, pero no llega a vender realmente nunca. A veces piensan que es por su juego, por lo que cambian a un nuevo proyecto y durante años consiguen los mismos resultados.

Sin embargo, solo por el hecho de que tu juego esté en una red de distribución (como la App store), no quiere decir que el juego esté delante de todo el mundo. De he‐ cho, no lo estará.

Esta es la razón por la que recomiendo a todo el mundo que tenga un plan solido y probado de marketing. Necesitas que

tu juego se conozca. Si no tienes una compañía que lo haga por ti, tú tienes que crear esa compañía. Por eso hablo tanto de ello: anunciar el juego es tan importante como hacerlo.

Esa es también una de las razones por las que estamos desarrollando nuestro juego de forma abierta. En lugar de guardar todo en secreto, dejamos que la gente nos diga qué quiere ver. Aunque técnicamente esto no es marketing, consigue que todo el mundo este emocionado con tu juego y esto es exactamente lo que necesitas.

¿Qué recomendáis a un programador para introducirse en la industria? ¿Y para un artista? ¿Y para el que diseña el juego? ¿Cuál es tu consejo para los nuevos programa‐ dores, artistas…? ¿Qué deben estudiar, leer, ver… ?

Mi consejo para los programadores: después de estar pro‐ gramando un día entero, oblígate a revisar todo de nuevo.

Me he dado cuenta por mí mismo de que después de pro‐ gramar tanto sobre los detalles me olvidaba de que real‐ mente estoy creando un juego. Si no revisas lo que estás haciendo, el resultado puede ser un juego horrible. También es importante fijarse un objetivo diario, completarlo y en‐ tonces detenerse. Es mejor terminar un día resolviendo un problema, que empezando otro que no puedes terminar, consiguiendo que te vayas de la oficina frustrado.

Entrevista

Os puedo asegurar que no os lo querréis perder, es real‐ mente emocionante.

Mi consejo para los artistas: fuerza a tu equipo a que defina un límite de polígonos y tamaño para el juego. No ganas nada hasta que el equipo al completo tiene claro a qué frame‐rate debe funcionar el juego, cuál es la máxima can‐ tidad de polígonos para cada personaje u objeto y el ta‐ maño de las texturas. Cuando todo esto está definido, el resto es realmente sencillo. El libro de Wes McDermott ‘Creating 3D Game Art for the iPhone with Unity’ tiene ca‐ pítulos muy interesantes que hablan de ello.

En el mercado indie no puedes competir con grandes compañías en calidad técnica, IA, etc ¿Dónde deben buscar los desarrolladores indie? ¿Cuál es el camino para conseguir que un juego triunfe en un mercado tan saturado de grandes juegos?

Centrarse en los niños. Es así de simple. Los niños no buscan personajes modelados en z‐brush que hagan movimientos acrobáticos. Un simple sprite divertido puede conseguir mucho más que eso. Creo que los desarrolladores más exi‐ tosos entre los desarrollos indie se están centrando también en juegos para iPhone y el resto de plataformas móviles.

De esta forma se ven forzados a reducir los gráficos y a in‐ novar. Algunas veces verse forzado en esa dirección es

www.unityspain.com

9

2 Entrevista Tornado Twins:Páginas maqueta 30/12/2010 16:19 Página 10

TORNADO TWINS bueno. Necesitamos más creatividad y diversión. Si estas pensando en hacer otro FPS de zombies o de acción segu‐ ramente tengas competencia.

“El riesgo es conseguir que guste a la gente” El hecho es que para mucha gente todos los juegos de ac‐ ción son iguales. La gente no sabe cual escoger, así que se guían por lo que juegan sus amigos y acaban comprando Call of Duty. Jamás mirarán hacia tu juego.

Entrevista

En definitiva, si quieres hacer un juego que venda tienes que llamar la atención, y llamar la atención empieza por escoger el género correcto. Mi consejo es centrarse en los niños y las familias primero.

¿Crees que alguna vez habéis redefinido un genero?

En caso afirmativo, ¿Considerais que es necesario hacerlo?

No es muy necesario. Un género de videojuego tiene que ver con el punto de vista de la cámara. Por ejemplo, cuando la cámara esta en la cabeza del personaje tenemos un shooter en primera persona. La parte “en primera persona” tiene sentido, pero shooter…¡No tiene nada que ver con eso! Por supuesto, se puede hacer un juego en primera persona que no sea un juego de disparos. Sin embargo, ya que la cámara esta en la cabeza del personaje, se relaciona inmediatamente con el genero de acción de disparos. Por tanto, los géneros tienen mucho que ver con los puntos de la cámara, y todos los puntos de cámara ya han sido inventados.

En los juegos actuales, para innovar o redefinir un género, tienes que hacer una combinación de puntos de cámara que estén unidos de forma creativa. Esa es la forma de hacerlo. ¿Lo hemos hecho nosotros? Bueno… estamos trabajando en un juego muy grande que llevara más allá los limites de la creatividad. El riesgo es conseguir que guste a la gente.

Yo confío en este trabajo, pero, obviamente, yo estoy den‐ tro del proyecto. Para contestar a tu pregunta: aún no he‐ mos reinventado un género…¡Pero lo haremos pronto!

trabajando en su propia asset store. Para su sorpresa, nosotros estábamos muy contentos con ello. En lugar de convertirnos en competencia les sugerimos abrir la tienda a otros y vender a través de ella. Un mes más tarde via‐ jamos a San Francisco para mostrarles nuestra tienda, a través de la cual los demás podían vender. La reunión fue genial.

¿Qué prefabs estáis vendiendo en la asset store de Unity?

Todos los que son compatibles con Unity 3, incluyendo aquellos que se venden a través de nuestra tienda, que simplemente consiguen los mismos porcentajes. Un sistema muy sencillo: ellos no tienen que hacer nada de publicidad, nosotros lo hacemos por ellos.

¿Puede ahora cualquier artista o desarrollador vender en la asset store de Unity?

En este momento, creo que la asset store de Unity no está abierta para todo el mundo. Unity ha seleccionado un puñado de desarrolladores con los que trabajar. Quizás en el futuro la tienda se abra a otros vendedores, pero por ahora solo unos pocos tienen acceso. Nosotros esta‐ mos entre ellos.

¿Qué crees que es Union? ¿Sabes como funciona? ¿Po‐ drías decirnos cual es tu opinión?

Union ha sido anunciado en la conferencia de Unite de este año. Parece que Unity recibirá los juegos, y tras revisarlos los publicará en múltiples plataformas. Es una oportunidad muy buena. De momento, no he oído de nadie que se en‐ cuentre en ese proceso, pero estoy ansioso por ver llegar los resultados. Unity tiene muy buenos contactos dentro del negocio de los videojuegos y quién sabe lo que puede ocurrir.

Con esta pregunta terminamos la entrevista, muchas gracias por tu tiempo

Unity acaba de presentar su asset store y UnityPrefabs ha anunciado que está en ella. ¿Cómo ha sido la ex‐ periencia? ¿Contactó Unity con vosotros o fuisteis vos‐ otros los que contactasteis con Unity?

Este verano el director ejecutivo de Unity, David Helgason, contactó con nosotros para comunicarnos que estaban

10

www.unityspain.com

5 Articulo Eyes Bandages:Páginas maqueta 30/12/2010 16:21 Página 11

ARTÍCULO

Eyes Bandegades CRISTIAN GALLEGO

EYES BANDEGADES Eyes Bandegades es un videojuego perte‐ neciente al género de los shooter espacia‐ les que inicialmente fue planeado a finales de 2009 como un pequeño juego de naves 2D por Gilson Herrera (modelador 3D y mi único socio en ese momento) y yo mismo, X4ch1, con la idea de promocionarnos como desarrolladores de videojuegos. En la captura podéis ver un jueguecito de naves que realicé en GameMaker en los inicios de mi perfil como diseñador de videojuegos y que nos sirvió de inspiración para el des‐ arrollo. Algo que tuvimos muy en cuenta fue que este tipo de juegos son más senci‐ llos de desarrollar, y que solo realizaríamos un nivel de muestra.

Impactante, ¿ver‐ dad?

Después de con‐ cretar la idea a la que queríamos llegar, ideamos el nombre del juego

y de los bandos, además de dedicarnos a definir lo primordial antes de empezar un videojuego cualquiera: “la historia”. Así fue como surgieron nuestras ideas ocultas entre explosiones eléctricas de conexiones fre‐ cuentes de millones y millones de neuronas la historia: “Buenos y malos en el espacio se disputan un gran mineral que todo lo hace y todo lo puede”. A esos buenos los deno‐ minamos Bandegades (humanos) a esos malos los denominados Naghut (alieníge‐ nas). Entonces empezamos como almas atormentadas o simplemente como caba‐ llos desbocados a modelar la primera nave y construir la programación de una movili‐ dad vertical y horizontal (como se muestra en la imagen). Después de trabajar la movi‐ lidad y tener un movimiento básico (logrado en una media hora) y una nave principal ya modelada (en el mismo tiempo), el mode‐ lador empezó con más ánimo el diseño de otra nave, mientras yo continuaba con la programación. Entonces, por casualidades de la vida, nos encontramos con un video‐

www.unityspain.com

juego recién salido del horno: el juego de Avatar, la famosa película de James Came‐ ron, y mirando un video en YouTube, vimos una escena en la que aparecía una nave (como la de la imagen).

En ese momento todo dio un giro y nos preguntamos: ¿Por qué no hacerlo así?

Sabíamos que sería más difícil hacerlo de esta forma; pero nuestro juego re‐ sultaría más novedoso sin esa aparien‐ cia clásica, puesto que le añadiríamos un escenario tridimensional (aspecto que llama mucho la atención hoy en día), y además nos exigiría más como desarrolladores, ya que el 2D nos pare‐ cía muy sencillo.

11

5 Articulo Eyes Bandages:Páginas maqueta 30/12/2010 16:21 Página 12

CRISTIAN GALLEGO

EYES BANDEGADES Comenzamos por crear una escena donde ocurriría el juego, y empezó también la ardua labor de mover una nave en ter‐ cera persona. La primera exclamación de mi compañero el modelador al ver la nave moverse fue: ¡Guau, la nave anda!; todo esto mientras él modelaba un terreno en Zbrush para añadir al juego. Este nos lo imaginábamos como un satélite natural muy similar a la luna; al principio era un escenario lleno de cráteres muy bien logrados. Poco a poco fuimos aña‐ diendo cosas como nitro, colisiones, más detalles en el mapa, una base, etc. Según avanzábamos, vimos que a la nave le hacía falta un movimiento más fluido, y probé varias cosas para lograr un movimiento medianamente decente que se asemejara más a una nave en el espacio. Al empezar parecía un colibrí volando, pero después de analizar juegos como Starfox, noté que la nave miraba primero hacia abajo y que hacía continuamente un movimiento como de ola, solo para bajar y subir.

al más puro estilo del mismo avatar, pero en el espacio, y empecé a montar el nuevo escenario a medida que mi com‐ pañero terminaba las islas flotantes donde se supone que las naves nodrizas estarían ancladas para extraer el mineral, tal y como muestra esta imagen:

Artículo

Así fue como logré dar un movimiento más fluido:

Ya podéis ir contando los cambios que se han hecho desde el principio.

Esto da una sensación de “ola”, y por lo tanto crea el efecto de vuelo, el cual se completa con la animación, un buen so‐ nido y buenos efectos de partículas; aunque, lamentable‐ mente, todo eso no es suficiente para “sentir” en tercera persona el vuelo de una nave. Para mejorar el efecto, utilicé una cámara que tuviese un movimiento retardado cuando la nave hiciese el movimiento de ola, para lograr más flui‐ dez, y al fin quede un poco más satisfecho porque el nuevo movimiento estaba listo y era notoriamente más natural que el anterior. Hasta el momento todo iba bien. Teníamos nuestra escena del satélite artificial, una nave con un vuelo más fluido y un escenario con algunos detalles. Al poco tiempo de tener varias torretas enemigas y un escenario planeado, nos dejó de gustar el aspecto de la luna marciana y decidimos hacer otras cosas. Ideamos unas islas flotantes

12

Continuamos entonces con la nueva escena, donde ya no había suelo sino que todo estaría en el espacio, mientras mi compañero terminaba satisfactoriamente las naves y el escenario propuestos en 3D y empezaba a trabajar con una cinemática en 3D Max para hacer un tráiler promocional con una cabecera llamativa. En las primeras escenas, la nave principal aparece en los renders de una forma muy destacada. Los renders estuvieron listos tras una se‐ mana de renderizado con los equipos que estábamos manejando en ese momento. El video, que es el mismo que aparece al eje‐ cutar Eyes Bandegades, tiene una duración de 1’44 minutos. De manera imprevista, tuvimos la necesidad de cambiar la nave prin‐ cipal por otra cuyo diseño nos pareció más apropiado para usarla en el tráiler. Pero, ¡tendríamos que rehacer un render que tardó una semana en estar terminado! Al final valió muchísimo la pena tanto trabajo, pues el cambio fue notable: la nueva nave tenía un aspecto más aerodinámico que la anterior, que modelamos en media hora, y era mucho más llamativa.

Realizamos todos los arreglos correspondientes y empezamos a pre‐ parar el juego para el público, que al fin y al cabo solo sería un nivel.

Comenzamos a desarrollar la interfaz (HUD) y toda la parte de comunicación entre programación y el jugador: contado‐ res de municiones, vida, etc.

www.unityspain.com

5 Articulo Eyes Bandages:Páginas maqueta 30/12/2010 16:21 Página 13

CRISTIAN GALLEGO

EYES BANDEGADES

Trabajando en los últimos detalles, por así decirlo, con el juego aún sin controles definidos, estuve intentando solucio‐ nar errores de rendimiento. Para empezar, el juego no subía de 10 FPS, lo cual no era para nada bueno, y quedaba poco tiempo para el lanzamiento. Revisando todo en general, me di cuenta de que algo que consumía mucho rendimiento en la escena era que las 24 torretas que hay en Eyes Bandegades tenían un sphere collider gigante como trigger y dentro de un script donde la función OnTriggerEnter estaba pendiente de realizar las acciones apenas la nave entrase en el collider; note que eso consumía muchos recursos y me toco reprogramar el reconocimiento de distancia con un sencillo Vector3.Dis‐ tance. Hasta ahí bien.

Se acercaba cada vez más el día de lanzamiento definido hacía 20 días, tiempo que pasó realmente rápido, y cada vez apa‐ recían más detalles que organizar. Se lanzó inicialmente una versión de Webplayer, con la estructura de juego que tenía‐ mos hasta ese momento. Pronto aparecieron las quejas de que el juego era demasiado pesado para Webplayer y el tiempo de carga mayoritario resultó ser ¡media hora, nada menos! Nos dimos cuenta que no había sido buena idea poner el juego en Webplayer, y entonces lo exportamos a una versión ejecutable. A partir de ese momento, empezamos a recibir recomendaciones: los gráficos atraían a los jugadores y los consideraban buenos, pero por ejemplo, a la mayoría los controles les resultaban muy difíciles. Como este, otros tantos ejemplos de otros detalles que había que corregir o mejorar (lo cual era de esperar pues, después de todo, el juego era una versión Beta). Ya con esta información, empe‐ zamos a realizar los arreglos correspondientes de acuerdo a los análisis que nos iban llegando de la gente, que hacía de betatester. Implementamos mejoras de rendimiento, contro‐ les más prácticos, un menú mucho más completo, botones importantes (como el de “reintentar”) y, entre otras cosas, añadimos el sistema de puntuación y la posibilidad de selec‐ cionar el nivel de dificultad.

La motivación de los jugadores hizo que pensáramos en hacer una versión 2D del mismo juego; versión que se realizó en un mes ya que al programador principal de esta versión, que quería unirse al grupo de desarrollo, se le propuso tal tarea

para ello. Utilizó la misma arte que el 3D y las mismas naves, a las que se añadió una más denominada KAMIKAZE debido a que está fabricada con escombros de metal para lanzarse con intención suicida hacia el enemigo.

Tanto la versión 3D como la 2D se pondrían a prueba en el Ani‐ gamesExpo, un congreso latinoamericano de videojuegos y animación (www.anigamesexpo.com), al que IsoftStudios llevó el juego. Los asistentes quedaron muy contentos con su as‐ pecto grafico, y sobre todo, con la sencillez y capacidad de en‐ tretener al jugador con las que cuenta Eyes Bandegades 2D.

Artículo

Después de terminar el tráiler de Eyes Bandegades nos pusi‐ mos a la tarea de anunciarlo en YouTube, proponiendo el 4 de junio como día de lanzamiento.

Durante todo este tiempo desde que se empezó a desarrollar Eyes Bandegades, el trasfondo del juego ha ido creciendo y haciéndose más complejo, y ya casi hay historia para un libro.

Los aspectos de las naves Bandegades y Naghuts están muy bien definidos: de donde salieron, cuál es su objetivo o sus creencias y demás información sobre las civilizaciones que aquí aparecen. Para no extenderme más, diré que pronto verán más de EYES, con secuencias de vídeo incluidas y mucho más entretenidas que nunca.

Sugerencias: ‐Antes de iniciar tu juego, crea la historia y un estudio de per‐ sonajes, todo bien estructurado para que a lo largo del juego no varíe mucho. ‐Es imprescindible crear un documento de diseño en cuyo contenido estrá definido el aspecto de los escenarios y, en ge‐ neral, toda la parte grafica del juego.

“La motivación de los jugadores hizo que pensáramos en hacer una versión 2D del mismo juego”

‐También es muy importante crear un documento técnico donde se especifique tanto la programación en general como las mecánicas y toda la parte técnica en si del videojuego a desarrollar.

Hasta ese momento todo estaba mejorando: el juego era mucho más jugable y entretenido que antes y la diferencia con versiones anteriores, notable. Día a día han ido creciendo las visitas a www.EyesBandegades.com y duplicándose cada mes.

Para Eyes Bandegades no hicimos ninguna de estas cosas, y ya habéis visto todos los problemas que eso nos acarreó, como los muchos cambios que debimos hacer para que el juego mantuviese su identidad y lograse ser medianamente

www.unityspain.com

13

5 Articulo Eyes Bandages:Páginas maqueta 30/12/2010 16:22 Página 14

CRISTIAN GALLEGO

EYES BANDEGADES funcional y jugable; así que si queréis evitar contratiempos innecesarios, no estaría de más tener en cuenta lo anterior.

Seguramente, de nuestro accidentado proceso de desarrollo para este videojuego se pueden extraer más recomendacio‐ nes, pero esas fueron nuestras dificultades principales (que a su vez desencadenaron otros inconvenientes) mientras tra‐ bajábamos en Eyes Bandegades. ¡Sed organizados!

Mantener el ánimo y el entusiasmo al desarrollar vuestro vi‐ deojuego es una de las cosas más importantes a tener en

cuenta para la consecución del proyecto, y más en un des‐ arrollo con escasas posibilidades de proporcionar beneficio económico, tal y como es el caso. www.Eyesbandegades.com, una fiel muestra de un vide‐ ojuego sin planificación que nunca se nos pasó por la ca‐ beza que iría creciendo hasta este nivel en el que está.

Pronto, para todos vosotros, habrá una versión donde se narre esta fascinante historia sobre el videojuego Eyes‐ Bangades.

Artículo

14

www.unityspain.com

1 como se hace 2:Páginas maqueta 30/12/2010 16:08 Página 16

¿Cómo se hace?

Product Sheet DANDO A LUZ (2ª PARTE) Saludos a todos. Con el nacimiento de un nuevo número de Udev, continuaremos desarrollando las ideas descritas en el an‐ terior número y añadiremos otras nuevas.

Esta sección es orientativa, y cabe desta‐ car que esta no es la manera perfecta de trabajar, sino el orden y la importancia que yo le otorgo a los distintos apartados. ¡A trabajar!

Storyline Este apartado, especialmente ligado al in‐ cluido dentro de “Descripción del pro‐ yecto”, deberá extender el resumen ya mostrado a lo largo de 2‐3 hojas aproxi‐ madamente. Deberá mostrar la totalidad del Storyline del juego y no un simple re‐ sumen.

Este apartado deberá incluir como mí‐ nimo la aparición de los personajes más relevantes de la trama; así como sus ac‐ ciones y consecuencias, en caso de pose‐

16

JESUS PANCORBO DÍAZ erlas, sobre el resto de la acción o el mundo que los rodea. Debemos recordar qué es y no caer en la trampa de hacer un relato literario fantástico como a todos nos gustaría. El lector, en su mayoría de veces, será un productor. Si este quiere leer aventuras se entretendrá con sus gus‐ tos personales, no con los nuestros. Ф Decisiones Este apartado es opcional. Nuestro juego puede o no tener decisiones morales que afecten al universo del videojuego. Incluir‐ las en un sub‐apartado es decisión propia.

Personalmente, si el juego contiene nu‐ merosas decisiones y caminos a seguir, mostraría en este apartado 1 hoja com‐ pleta con los más relevantes.

Localizaciones Este apartado reunirá la totalidad de los entornos y localizaciones principales del

www.unityspain.com

videojuego. No es necesario incluir en el listado las Sub‐zonas, o escenarios deri‐ vados de los principales, ya que resulta obvio que un escenario está sub‐dividido en otros muchos y que estos últimos están incluidos dentro de un escenario principal. ⱷ Escenario 1 ⱷ Diferencias respecto al resto de es‐ cenarios. ⱷ Mecánicas de juego incluidas. Breve resumen. ⱷ Entorno. ⱷ Personaje/personajes controlables. ⱷ False Screenshot. (Opcional)

Mecánicas de juego Sin lugar a dudas mi parte favorita. En este apartado, recogeremos todas y cada una de las mecánicas de juego anterior‐ mente expuestas en el apartado “Descrip‐

1 como se hace 2:Páginas maqueta 30/12/2010 16:08 Página 17

DANDO A LUZ (2ª PARTE)

JESUS PANCORBO DÍAZ

Movimiento ⱷ Caminar: En Clippox Exodus el jugador podrá interactuar con el personaje principal y hacerlo caminar por las diferentes localizaciones de tal manera.

Dos pulsadores semi‐invisibles, ambos a cada lado de la pantalla táctil y que ocuparan la práctica totalidad de los laterales permitirán, al pulsarlos de manera individual, mover al personaje en la dirección que pulsa el jugador.

– Pulsador izquierda Permitirá mover al personaje hacia la izquierda.

de uso obligado más tarde, debiendo reestructurar todo de nuevo. Desde mi punto de vista, todas las mecánicas de juego deberán de ser flexibles exceptuando el esque‐ leto principal constituido por el movimiento del personaje, el cual deberá ser fijado lo más pronto posible, evitando así posibles quebraderos de cabeza.

Creo que la extensión de este apartado puede andar entre las 2‐4 páginas. Con el tiempo lograremos comprimir la in‐ formación más y más sin perder un solo detalle en las des‐ cripciones. Una de las reglas de oro que un día me explica‐ ron, y que aplico a todos los aspectos de mi vida es la siguiente: “Si un párrafo puede quedarse en una frase, hazlo. Si esa frase tienes que repetirla más adelante…es que no lo has hecho bien desde el principio”

– Pulsador derecha

En resumidas cuentas, optimicemos el espacio y la calidad de la información.

Permitirá mover al personaje hacia la derecha.

Temática y género

ⱷ Salto En Clippox Exodus existirán dos maneras claramente diferenciadas de hacer saltar a nuestro personaje.

– Salto en parado El jugador deberá de trazar una diagonal, cuyo ta‐ maño y dirección serán determinantes, en cualquier zona de la pantalla para realizar un salto común.

– Salto en movimiento

Aquí deberemos dejar clara nuestra postura respecto al gé‐ nero que queremos para nuestro videojuego. Si su temática es realista, fantástica, o de otras características, también de‐ berá quedar definida. En el momento de la reunión con un posible productor o alguien interesado en el desarrollo del videojuego, deberá ser defendida a capa y espada.

¿Cómo se hace?

ción del proyecto” y las describiremos con todo lujo de de‐ talles. Pongamos un ejemplo adaptado a Clippox Exodus y sus movimientos principales:

Pienso que el espíritu del videojuego está en la mente del creador, y solo en su mente. Defenderlo en su momento y más tarde justificarte con un trabajo excelente y acorde a lo

En caso de necesitar un salto pronunciado, el jugador de‐ berá iniciar un movimiento de caminar hacia la dirección deseada para después, agitar el terminal levemente e ini‐ ciar así el salto. Su longitud siempre será igual y superior a la diagonal más amplia trazada en un salto común.

Esta es una pequeña muestra de lo que deberemos escribir en nuestro Product Sheet, y que marcará profundamente la opinión de nuestro lector.

Como habéis podido comprobar, cada detalle está medido y es así como deberán de ser todas y cada unas de las me‐ cánicas de juego de nuestro título. Para algunas solo serán necesarios un par de renglones y otras requerirán varias páginas completas o más en exclusiva.

“Cada detalle está medido” Su reflexión deberá ser profunda, y nunca escribir por es‐ cribir. Una mecánica perfecta en un momento determi‐ nado, puede entrar en conflicto con otra que puede ser

www.unityspain.com

17

1 como se hace 2:Páginas maqueta 30/12/2010 16:08 Página 18

DANDO A LUZ (2ª PARTE)

JESUS PANCORBO DÍAZ

que pensaste y mostraste en su día es una muestra perfecta de la principal característica del buen diseñador: creer en uno mismo y tener fe en tus propios proyectos hasta el final.

Estudio de mercado Personalmente creo que es un apartado que solo deberán de rellenar aquellos con experiencia en el sector y que pue‐ dan aportar datos estadísticos claros de lo que tengan entre manos. En caso de no ser así, un productor decente aportará estos antes de darte una respuesta. Exigirlos es lícito por parte del diseñador al igual que lícito no darlos por parte del productor. Un tira y afloja divertido y entretenido.

“La originalidad no consiste en decir cosas nuevas, sino en decirlas como si nunca hubiesen sido dichas por otro”

¿Cómo se hace?

Si no tienes los conocimientos necesarios, pero aun así quieres intentarlo (esto muestra interés en aprender) estos son los da‐ tos, a mi parecer, necesarios para completar este apartado. ⱷ Ventas – Plataforma Número de ventas aproximadas de la plataforma se‐ leccionada para el videojuego.

– Género Número de ventas aproximadas del género seleccio‐ nado para el videojuego.

– Último superventas Número de ventas aproximadas del último videojuego superventas y características que lo asemejen con tu producto.

– Estimación de ventas Como la propia palabra indica, cuántas ventas calculas y porqué. ⱷ Público objetivo ⱷ Porqué se debe apostar por tu proyecto Hemos llegado al final de nuestro resumen sobre “Como se hace un Product Sheet”. Todos estos aspectos son orienta‐ tivos, y esta es la formula con la cual yo trabajo a la hora de plasmar mis ideas sobre el papel. Adaptarlos a la formación y estilo de cada uno es imprescindible a la hora de dotar de personalidad al documento.

Si he incluido los puntos citados anteriormente y no otros, es porque considero que es esto lo que un productor espera ver; el resto sobra ya que para ello existe el documento de diseño, que aclarará todo lo que pudiera quedar en el aire.

A trabajar y, ¡Buena suerte a todos!

18

www.unityspain.com

Johann Wolfgang Goethe (1749‐1832)

6 Articulo Streaming Video:Páginas maqueta 30/12/2010 16:10 Página 19

TUTORIAL

Streaming Video STREAMING VIDEO Bienvenidos a este tutorial de cómo crear un re‐ productor de vídeos en streaming para Unity3D. El objetivo es crear un módulo, independiente del contexto en el que se quiera situar, que sea capaz de ofrecer reproducción de vídeos aloja‐ dos en Internet mediante streaming.

CONCEPTOS PREVIOS Dado que es el primer tutorial que os ofrezco, aclararé el modus operandi que utilizo para elaborar los scripts. Todos los tutoriales que yo realice estarán escritos en C#. Podríamos estar horas hablando de ventajas e inconve‐ nientes sobre usar JavaScript o C# pero ese no es el objetivo de los tutoriales, así que simple‐ mente diré que uso este lenguaje porque es con el que me siento más cómodo.

Ya centrados en la programación de los scripts, cabe enumerar una serie de hábitos o normas que suelo usar a la hora de pro‐ gramar, con el objetivo de hacer más fácil la comprensión de los scripts.

Idioma El idioma escogido para programar es el in‐ glés. No hace falta justificar mucho esta de‐

cisión, es más fácil que otros programadores entiendan qué hace una función o que guarda una variable si entiende el nombre de ésta. Lógicamente el nombre de este tipo de cosas tiene relación con su cometido.

Variables miembro vs. variables locales Por norma general, los scripts suelen tener cientos de líneas, por lo que no tendremos visible la declaración de las variables. En estos casos, diferenciar a simple vista las variables que pertenecen a la clase o las que son de ámbito local a la función es de vital importancia.

Hay muchos métodos y prácticas para rea‐ lizar esto. Yo personalmente me declino por la que hace la siguiente diferenciación: ‐ Variables miembro: todas las variables miembro se escribirán empezando por el carácter ‘_’ (underline o barra baja) seguido del nombre de la variable empezando en minúscula. En caso de ser un nombre com‐ puesto por diferentes palabras, lo escribi‐ remos todo junto y capitalizando (poniendo en mayúsculas) la inicial de cada

www.unityspain.com

una de las palabras (excepto la primera, como ya hemos comentado). Ejemplo: int _num; string _num; MovieTexture _movie; ‐ Variables locales: este tipo de variables seguirá las mismas reglas que las variables miembro, a excepción de la barra baja (‘_’) inicial: Ejemplo: int i; float maxDuration; string veryLongNameForAVariable; Funciones Las funciones seguirán una regla básica: todo junto y empezando en mayúscula.

Ejemplo: public void GetPosition(int i) ¡VAMOS AL TAJO! Lo primero que necesitamos es definir los estados en los cuales se podrá encontrar el reproductor y actuar en consecuencia según éstos. Así, tendremos que nuestro

19

6 Articulo Streaming Video:Páginas maqueta 30/12/2010 16:10 Página 20

STREAMING VIDEO reproductor se podrá encontrar en 4 estados diferentes: STOP, PAUSE, PLAY, BUFFERING. public enum VideoState { STOP, PLAY, PAUSE, BUFFERING }

remos. Vamos a pensar que queremos que tenga nuestro reproductor. Queremos que descargue de una URL un vídeo, queremos que se pueda personalizar su tamaño y posición en pantalla y su estilo del contorno. Estas serían las más básicas, pero podéis pensar más aspectos que que‐ ráis contemplar. Yo he pensado, a priori, las siguientes va‐ riables asociadas a su correspondiente comportamiento: Rect

Una vez tenemos claros los estados de nuestro reproductor, viene el momento de definir su comportamiento en cada uno de estos estados.

_pos;

// Posición y tamaño del reproductor

MovieTexture _movie; int

_depth;

GUIStyle

_style;

VideoState _state;

// Película a reproducir

// Profundidad dentro de la interfaz // Estilo del contorno del vídeo // Estado en el que se encuentra

bool

_play;

bool

_wPos;

// ¿Queremos posición personalizada?

bool

_wSize;

// ¿Queremos tamaño personalizado?

int

// ¿Queremos reproducirlo?

_videoBorder; // Borde del contorno del reproductor

Tutorial

Como podéis ver, han aparecido más variables de las que hemos mencionado, pero ya veréis que todas tienen su utilidad. ¿PROFUNDIDAD DE LA INTERFAZ?

¿Y QUÉ VAMOS A REPRODUCIR? Lógicamente, el primer paso que debemos realizar es decirle al reproductor qué vídeo debe reproducir. También necesita‐ mos decirle al reproductor qué parámetros queremos usar por defecto y qué otros queremos usar personalizados. Así entonces, vamos a definir una función que cumpla con estos requisitos.

Pero antes de nada, tenemos que declarar la clase del repro‐ ductor y alguna de sus variables miembros que guardarán toda la información anteriormente descrita.

Así pues, la declaración de la clase sería la siguiente:

Quizá más de uno se ha quedado con cara de póker al hablar de profundidad de la interfaz. ¿Pero la interfaz no es algo plano? Sí, pero igual que en Photoshop, la interfaz trabaja con capas, de tal forma que puedas definir qué se ve por delante y qué queda detrás dentro de la interfaz. Esto es muy útil cuando tienes muchos scripts que tienen que mostrar cosas en la interfaz. Al no saber qué script se ejecuta antes, la única forma de asegurar el orden es situando cada cosa en una capa. No nos gustaría que el texto de consejos que hemos di‐ señado quedara por detrás de las barras de vida y no se pu‐ diera leer, por ejemplo.

Ahora sí, ya podemos definir la función para cargar un vídeo:

[RequireComponent(typeof(AudioSource))] public class Video2D : MonoBehaviour {

{

}

WWW www = new WWW(url);

La declaración de la clase es una declaración estándar de los scripts de Unity, derivando de la clase MonoBehaviour para heredar todo el comportamiento necesario para que se eje‐ cute dentro de nuestra aplicación. Cabe destacar la línea que precede a la declaración de la clase: [RequireComponent(typeof(AudioSource))] Dado que es un reproductor de vídeo, es lógico pensar que éste también tendrá sonido para ser ejecutado, así que con esta línea advertimos al motor que añada el componente de tipo AudioSource al objeto en caso de que no tenga ya uno añadido. Así aseguramos que escucharemos siempre el so‐ nido que emita el reproductor.

Ahora le toca el turno a las variables miembro del repro‐ ductor pero, ¿cuáles necesitamos? Es imposible saber de antemano cuántas necesitaremos y para qué las necesita‐

20

public void LoadMovie(string url, Rect pos, int depth, GUIStyle style, bool wPos, bool wSize, int border)

if ( != null) { Debug.LogError(www.error); } else { _movie = ; audio.clip = _movie.audioClip; if (!_movie.isReadyToPlay) {

www.unityspain.com

_state = VideoState.BUFFERING;

6 Articulo Streaming Video:Páginas maqueta 30/12/2010 16:10 Página 21

STREAMING VIDEO }

Como se trata de un vídeo en streaming, puede ser que necesite unos segundos antes de poder comenzar con la reproducción. Gracias a la propiedad isReadyToPlay po‐ demos controlar este aspecto. A partir de aquí, todas las demás instrucciones son la asignación de los parámetros a las variables miembro de la clase. En caso de querer usar los parámetros por defecto del reproductor, solo ne‐ cesitamos pasar como argumento null o 0 en caso de ser un entero.

else { _state = VideoState.STOP; } _depth = depth; _style = style;

“Las acciones vienen a ser como el mando a distancia del reproductor, según la cantidad de acciones que definamos, nuestro mando tendrá más botones o menos”

_wPos = wPos; _wSize = wSize; _pos = new Rect(‐1,‐1,‐1,‐1); _videoBorder = border; if (_wPos) { _pos.x = pos.x;

¡OJO CON LA CLASE ‘RECT’!

Podrías pensar que si no quieres ni tamaño ni posición per‐ sonalizada, podrías pasar como argumento de la clase Rect el valor null. En la mayoría de casos esto funcionaría, pero en este caso hay un problema: esta clase está definida como no nullable. ¿Qué significa esto? Significa que no puede pasarse en ninguna parte del código un valor null cuando se está es‐ perando un objeto de esta clase. Por esta razón se necesita de los booleanos wPos y wSize para controlar qué queremos en cada caso.

} if (_wSize) { _pos.width = pos.width; _pos.height = pos.height; } } } Vamos a hablar primero de los argumentos de la función: • string url: dirección web donde está alojado el vídeo a reproducir.

• Rect pos: rectángulo con la posición y/o el tamaño del reproductor.

• int depth: capa dentro de la interface en la que se di‐ bujará el reproductor.

• GUIStyle style: estilo a usar en el contorno del reproductor.

• bool wPos: indica si vamos a usar la posición por de‐ fecto o una personalizada.

• bool wSize: indica si vamos a usar el tamaño por de‐ fecto o uno personalizado.

Tutorial

_pos.y = pos.y;

Perfecto, ya tenemos nuestro estructura más básica: tenemos definida una clase que nos permite cargar y buffear un vídeo.

Ahora solo nos falta definir las acciones que puede realizar el reproductor y definir qué debe hacer éste en cada uno de los estados.

Vamos por partes, primero definiremos las acciones. Las ac‐ ciones vienen a ser como el mando a distancia del reproduc‐ tor, según la cantidad de acciones que definamos, nuestro mando tendrá más botones o menos, lógico. En este tutorial vamos a definir las más básicas de cualquier reproductor: play, pause y stop. public void Play() { if (_movie != null) {

• int border: tamaño del borde del contorno del reproductor.

_state = VideoState.BUFFERING; Ahora ya podemos pasar a analizar el cuerpo de la fun‐ ción. En primer lugar, creamos un objeto de tipo WWW para hacer la conexión con la dirección del vídeo. En caso de que haya algún error, avisaremos de este y finalizare‐ mos la función. En caso de una conexión satisfactoria, asignaremos la película a la variable encargada de ello.

Para que se pueda escuchar el sonido, hay que asignar explícitamente a un AudioSource el clip de sonido de la película. Así pues, accedemos al AudioSource del objeto (ya nos hemos asegurado antes de que haya uno) para hacer la asignación. El siguiente paso es controlar si el vídeo ya está cargado o no para poder ser reproducido.

_play = true; }else { Debug.LogError(“No movie loaded. Please, use Lo‐ adMovie() function to load a movie.”); } } public void Pause()

www.unityspain.com

21

6 Articulo Streaming Video:Páginas maqueta 30/12/2010 16:10 Página 22

STREAMING VIDEO {

switch (_state) {

if (_movie != null)

case VideoState.STOP:

{

break;

_movie.Pause();

case VideoState.PLAY:

audio.Pause();

break;

}

case VideoState.PAUSE:

_state = VideoState.PAUSE;

break;

}

case VideoState.BUFFERING:

public void Stop()

if (_movie.isReadyToPlay)

{

{ if (_movie != null)

if (_play)

{

{ _movie.Stop();

_state = VideoState.PLAY;

audio.Stop();

_movie.Play();

}

Tutorial

audio.Play();

_state = VideoState.STOP;

}

}

else {

Como podéis observar, hemos declarado las funciones como públicas para que, desde donde se controle el reproductor, se puedan realizar las acciones. La estructura de todas es muy pa‐ recida, a excepción de la función Play(). ¿Por qué no llamamos a la función _movie.Play(); del vídeo para reproducirlo? Muy fácil, puede ser que el vídeo aún no esté listo para empezar su reproducción, por lo que no veríamos nada y podría derivar en errores inesperados. Pero aún hay más, cuando aún no está listo el vídeo para ser reproducido, el motor aún no sabe qué medi‐ das tendrá y, por consiguiente, define unas por defecto (16x16).

Se podría dar el caso de tener en medio de la pantalla un mi‐ núsculo rectángulo con el estilo definido por el usuario hasta que el vídeo estuviera listo para su reproducción. Definiendo así la función, nos aseguramos de que no empiece a reproducir ningún video hasta que no esté listo.

_state = VideoState.STOP; } if (!_wPos) { if (_wSize) { _pos.x = (Screen.width ‐ _pos.width) * 0.5f; _pos.y = (Screen.height ‐ _pos.height) * 0.5f; } else { _pos.x = (Screen.width ‐ _movie.width) * 0.5f; _pos.y = (Screen.height ‐ _movie.height) * 0.5f; } } if (!_wSize) { _pos.width = _movie.width;

Ahora ya tenemos las acciones que cambian el estado del re‐ productor, ahora vamos a controlar qué pasa en cada uno de estos estados. Como el reproductor hereda de MonoBeha‐ viour, podemos usar las funciones Update() y OnGUI() para definir el comportamiento del reproductor.

_pos.height = _movie.height; } } break;

Comenzamos por la función Update():

default: void Update ()

break;

{

} if (_movie != null) {

22

} }

www.unityspain.com

6 Articulo Streaming Video:Páginas maqueta 30/12/2010 16:10 Página 23

STREAMING VIDEO

Lo primero que debemos verificar, es si el vídeo está prepa‐ rado para ser reproducido. En caso negativo tendremos que esperar un poco más hasta que esté listo. Cuando ya lo esté, tendremos que comprobar si hemos accionado el ‘botón play’ del reproductor para empezar su reproducción o, por el con‐ trario, solo lo hemos cargado y aún no queremos visionarlo.

Cuando ya está listo, también debemos configurar tamaño y posición del reproductor según lo que el usuario haya pedido anteriormente. En caso de usar los valores por defecto del re‐ productor, la película será reproducida con el tamaño nativo de ésta y centrada en pantalla.

GUI.DrawTexture(_pos, _movie); if (_pos.Contains(Input.mousePosition)) { if (GUI.Label(new Rect(_pos.x + (_pos.width ‐ _pauseTexture.width) * 0.5f, _pos.y + (_pos.height ‐ _pau‐ seTexture.height) * 0.5f, _pauseTexture.width, _pauseTex‐ ture.height), “”, _pauseStyle)) { Pause(); } }

Perfecto, ahora ya solo nos falta que se visualice por pantalla, así que hay que definir la interface. Para hacer aún más inde‐ pendiente éste módulo de su contexto, definiremos las accio‐ nes dentro de la misma clase para que no sea necesario controlar desde fuera estas acciones. Para ello definiremos un aspecto parecido a los reproductores de Internet.

Antes de definir la función OnGUI() declararemos las variables necesarias para el diseño de los botones de las acciones.

break; case VideoState.PAUSE: if (_style != null) { GUI.Label(new Rect(_pos.x ‐ _videoBorder, _pos.y ‐ _videoBorder, _pos.width + _videoBorder * 2, _pos.height + _videoBorder * 2), “”);

public Texture

_playTexture;

}

public Texture

_pauseTexture;

GUI.DrawTexture(_pos, _movie);

public Texture

_stopTexture;

public GUIStyle

_playStyle;

public GUIStyle

_pauseStyle;

public GUIStyle

_stopStyle;

Tutorial

Fijaos que tenemos todos los estados contemplados en esta función, aunque no necesariamente tendremos que hacer algo en cada uno de ellos. Es más, para el funcionamiento bá‐ sico del reproductor solo necesitamos controlar el estado Vi‐ deoState.BUFFERING.

if (GUI.Button(new Rect(_pos.x + (_pos.width ‐ _playTexture.width) * 0.5f, _pos.y + (_pos.height ‐ _play‐ Texture.height) * 0.5f, _playTexture.width, _playTexture.height), “”, _playStyle)) {

Hemos declarado las variables como públicas para que sea fácil desde el editor configurarlas. Éstas variables servirán para definir el aspecto visual de los botones que permitirán las acciones en el reproductor.

Play(); } break;

Ahora sí, ya solo nos queda diseñar la parte visual:

case VideoState.BUFFERING:

void OnGUI()

GUI.Label(new Rect(Screen.width * 0.5f ‐ 50, Screen.height * 0.5f ‐ 10, 100, 20), “Loading video”);

{

break;

GUI.depth = _depth;

default:

switch (_state)

break;

{ }

case VideoState.STOP:

}

break; case VideoState.PLAY: if (_style != null) { GUI.Label(new Rect(_pos.x ‐ _videoBorder, _pos.y ‐ _videoBorder, _pos.width + _videoBorder * 2, _pos.height + _videoBorder * 2), “”); }

Igual que en la función Update(), hay que contemplar cada uno de los estados del reproductor, ya que no mos‐ traremos lo mismo cuando está cargando o cuando está reproduciendo, por ejemplo. Lo primero que hay que hacer es asignar la capa de la interface que se ha esco‐ gido al motor para que lo dibuje en el orden deseado. A continuación hay que controlar qué se muestra en cada uno de los estados. Empezaremos por el más sencillo: Vi‐ deoState.BUFFERING. Como aún no podemos mostrar el vídeo, lo único que haremos es mostrar un mensaje al

www.unityspain.com

23

6 Articulo Streaming Video:Páginas maqueta 30/12/2010 16:10 Página 24

STREAMING VIDEO usuario para que sepa que se está cargando el vídeo y que tiene que esperar. VideoState.PLAY: en este estado la instrucción principal es: GUI.DrawTexture(_pos, _movie); Con esta instrucción mostraremos el vídeo en pantalla. El resto de código es para mostrar el borde en caso de que el usuario así lo haya requerido y mostrar el botón de pause en caso de tener el ratón encima de la zona del vídeo, imitando así el aspecto web.

En el caso de VideoState.PAUSE tendremos prácticamente el mismo código pero cambiando la acción en caso de presionar el botón de play, en este caso. ¡LISTO! Pues con esto ya tenemos creado un reproductor básico para Unity donde podremos reproducir cualquier vídeo me‐ diante streaming. A partir de ahora, para cualquier juego donde se requiera reproducir algún tipo de vídeo en inter‐ faz, podréis usar este módulo sin mayores dificultades. Es‐ pero que hayáis disfrutado y aprendido cosas nuevas con este tutorial. ¡Hasta la próxima!

Tutorial

Para colaborar con Udev o anunciarse en sus páginas, mandad un correo a:

webmaster@unityspain.com

24

www.unityspain.com

3 Articulo itween:Páginas maqueta 30/12/2010 16:11 Página 25

ARTÍCULO

iTween DAVID COLLADO

ITWEEN En este artículo hablaremos de una de las me‐ jores librerías gratuitas para Unity, tanto que debería encontrarse integrada dentro de las apis de Unity. iTween, creada por pixelplacement, es una li‐ brería para animaciones basada en la premisa: “input mínimo para output máximo”. La idea es hacer la vida más sencilla cuando queremos agitar, girar, mover, fundir, colorear, controlar audio, hacer fundidos entre cámaras y casi cualquier cosa que te plantees hacer en Unity.

En su núcleo, iTween es un sistema de interpo‐ lación que toma un valor y lo anima hasta otro durante una cantidad de tiempo. Pero donde de verdad brilla iTween es en su sintaxis especí‐ fica para cada acción que nos libra de tener que programar muchas líneas y nos deja más en la posición de un director de cine. Gracias a iTween podremos acelerar nuestro ritmo de trabajo sin sacrificar calidad por el camino.

Antes de entrar a ver cómo usar iTween, vea‐ mos el porqué de su existencia. En Unity,

como en cualquier sistema, todo se puede hacer de muchas formas. Podemos animar fuera de Unity o con el sistema de animación incluido en Unity mediante un timeline; pode‐ mos utilizar JavaScript, C# o Boo y cambiar las cosas a mano con nuestro código. Es posible que nos demos cuenta de que estamos justo en medio de esas dos ramas; que ni somos los mejores programadores para animar siempre por código, ni tenemos lo conocimientos para utilizar una herramienta externa a Unity. Por supuesto, no es necesario encontrarse en ese punto. Podemos ser unos brillantes progra‐ madores y usar iTween por comodidad ya que, en este caso concreto, que su uso sea más sencillo no lo hace más simple. iTween ya ha sido utilizado por grandes y pequeños es‐ tudios, sigue las bases sólidas de las librerías del mundo de Adobe Flash.

¿Por dónde empiezo?

Si ya estas convencido de al menos probar iTween, lo puedes descargar de forma completamente gratuita desde http://itween.pixelplacement.com. iTween es un solo fichero C# que puede ser usado desde cualquier lenguaje soportado por Unity, ade‐ más de todas las versiones de Unity. Si quieres usarlo desde JavaScript o Boo necesitaras crear la carpeta Plugins dentro de tu carpeta Assets. Si lo vas a usar desde C# solo es nece‐ sario que lo sitúes dentro de la carpeta Assets.

Esta es toda la instalación, realmente sencilla, siguiendo la línea de “input mínimo para out‐ put máximo”.

Hola mundo Para empezar con un primer ejemplo práctico,

En general, iTween es rápido, eficiente, senci‐ llo de usar y encaja en cualquier proyecto: desde acciones muy simples a mecánicas de juego complejas.

www.unityspain.com

hay algunas cosas que debemos tener claras: Casi todos los métodos de iTween tienen 2 formas, una simple y otra personalizable.

25

3 Articulo itween:Páginas maqueta 30/12/2010 16:11 Página 26

DAVID COLLADO

ITWEEN Las versiones personalizables usan hashtables para sus propiedades.

Donde realmente las hashtables se vuelven feas es en C#, veamos un ejemplo de cómo componer una hashtable en C#:

Casi todos los métodos de iTween necesitan una referencia a un GameObject.

Hashtable parameters = new Hasthtable();

iTween puede ser utilizado dentro de la función Update de Unity. Hay métodos específicos incluidos en iTween pensados precisamente para acciones repetitivas y que ofrecen un mayor rendimiento.

parameters.Add(“x”,2); parameters.Add(“time”,3); parameters.Add(“looptype”,iTween.LoopType.pingPong); parameters.Add(“delay”,1);

iTween puede hacer cientos de cosas pero, en esta ocasión, ve‐ remos algo sencillo. Quizás en próximos números de UDev vea‐ mos más ejemplos aunque, como siempre, algo de investigación, los ejemplos de pixelplacement en la web y las dudas que podáis resolver en el foro de Unityspain os ayudarán a indagar para vues‐ tros proyectos.

Artículo

El ejemplo que vamos a ver es movernos de una posición a otra. El método de iTween para hacer esto es MoveTo().

Vamos a animar un GameObject desde su posición actual hasta (2,0,0) durante dos segundos usando la versión “sim‐ ple” del método MoveTo(): iTween.MoveTo(gameObject,Vector3(2,0,0),2); Simple y fácil, pero si queremos tener más control sobre la ani‐ mación, debemos usar la versión personalizable del método Mo‐ veTo() y darle las propiedades en una Hashtable: iTween.MoveTo(gameObject,{“x”:2,”time”:3, ”loopType”:”pingPong”,”delay”:1}); Esta llamada animará el GameObject moviéndolo desde su posi‐ ción actual a la posición 2 sobre el eje x durante 3 segundos, pero además retrasará la animación 1 segundo y hará un efecto ping‐ pong para moverse adelante y atrás.

Para liberar todo el poder de iTween, lo mejor es recu‐ rrir a las versiones personalizables de cada método y así poder modificar todos sus parámetros. La documen‐ tación de iTween la podéis encontrar aquí: http://it‐ ween.pixelplacement.com/documentation.php.

iTween.MoveTo(gameObject,parameters); ¡6 líneas de código! En Javascript todo iba en una sola línea. La verdad es que en comparación, las hashtables en Javascript no parecen tan feas, ¿verdad? Esto no sigue mucho la idea base de‐ trás de iTween (recordad, “input mínimo para output máximo”); pero no debemos tener miedo, ya que iTween ofrece una solu‐ ción para evitar esta locura y utilizar las hashtables de una forma más similar a la vista en Javascript: Hash(). Con el método Hash() podemos hacer una hashtable de la siguiente forma: iTween.MoveTo(gameObject, iTween.Hash(“x”,2,”time”,3, ”loopType”,”pingPong”, ”delay”,1)); Personalmente, creo que esta solución es mucho mejor que aña‐ dir todos los parámetros uno a uno utilizando una línea de código para cada uno. Por mis gustos personales prefiero C# pero en este caso es de agradecer que iTween aporte esta opción de compo‐ ner las hashtables que ahorra mucho tiempo.

Conclusión iTween se actualiza con mucha frecuencia, y tiene varios ejemplos en su web, además de toda la documentación. Según pixelpla‐ cement, iTween se ofrece de forma totalmente gratuita como compensación a esa comunidad que tanto le ha ayudado y que le ha hecho llegar al punto en el que se encuentra su carrera ac‐ tualmente. Creo que debemos agradecer todo el trabajo que pi‐ xelplacement ha llevado a cabo, y no hay mejor forma para ello que incluir iTween desde ahora en todos vuestros proyectos.

Pero las hashtables son muy feas Son muchos parámetros que configurar y con los que jugar. De hecho, MoveTo() es capaz de tomar una serie de puntos en el es‐ pacio que pueden ser utilizado como camino a seguir. El único problema es que estas posibilidades son más “feas”, pero se puede vivir con ellas.

26

www.unityspain.com