udev 3

U • DEVNº 3

00PORTADA CONTRAPORTADA & STAFF_Páginas maqueta 26/07/2011 16:47 Página 1

UDEV


CONTENIDO

UDEV

UPMusic Review ..............................................................String con Unity ...............................................................Maximizando la realidad aumentada .............................. Entrevista CUPRA STUDIOS ..............................................

¿Está Unity preparado para el desarrollo en consolas? .Entrevista Recoil Studios ..................................................Enmascaramiento ............................................................Tutorial Lanzallamas ........................................................

EDITORIAL

Aquí estamos, un número más. La revista que tenéis delanteha supuesto meses de trabajo, de ocupar nuestro tiempolibre en sacar adelante este proyecto. No sé si puedo auto-denominar este número como el mejor, pero ha sido conmucho el más complejo de sacar adelante hasta ahora.

Este es el primer número “dual”: lleno de contenidos crea-dos en inglés y español que luego han sido traducidos paraambas ediciones de la revista. Este número también su-pone el primer número en inglés completamente gratis.

Espero que disfrutéis con este número y tengáis en cuenta elesfuerzo que todos hacemos para sacar esta revista adelante.

Espero que para el siguiente número más gente se animea participar. Para colaborar, enviad un mail a webmas-

[email protected]

Cargo: EditorNombre: Ángela Espeltae-mail: [email protected]

Cargo: MaquetadorNombre: Eduardo Echevarríae-mail: [email protected]

Cargo: IlustradorNombre: Javier Morenoe-mail: [email protected]

Cargo: TraductorNombre: Alexander Hodgsone-mail: [email protected]

459

1317192123

Cargo: DirectorNombre: David Colladoe-mail: [email protected]


Esta va a ser la primera review que hacemos en

UDev y espero que resulte interesante a los lec-

tores. En esta primera ocasión voy a analizar el

sistema para reproducir nuestra música en Unity

y que podéis encontrar en gameprefabs.com.

UPMusic se presenta como un prefab profe-

sional cuya intención es facilitarnos la tarea de

reproducir distintas pistas de audio permitien-

donos hacerlo con una sola linea de código.

Este prefab utiliza para “comunicarse” con

el resto de scripts el sistema UPMessenger

que también podéis encontrar en gamepre-

fabs.com completamente gratis.

No es mi intención explicar como funciona

este sistema sino explicar cual ha sido mi

experiencia utilizando.

Actualmente estoy trabajando en un juego y

hace unas dos semanas llego el momento de

integrar el sonido para la demos. Obviamente

decidí utilizar este prefab y me hice con el.

Las primeras sensaciones fueron muy

buenas, UPMusic incluye una ventana

para agregar o eliminar pistas y reprodu-

cirlas, pese a que inicialmente tuve algún

conflicto entre C# y Unityscript, no su-

puso más que una linea de código repro-

ducir la primera pista.

Siguiendo con mis pruebas llegué a uno de los

puntos claves de UPMusic, su fundido automático

al pasar de una pista a otra. Podemos ajustar dis-

tintos valores de este fundido pero para mi lo más

importante es que realmente es automático.

Quizás esta, junto con la posibilidad de ordenar

las pistas visualmente, fue una de las caracterís-

ticas que más llamo mi atención ya que reprodu-

cir una pista de audio es algo que unity es capaz

de hacer sin necesidad de ningún prefab extra

pero fundir suavemente el audio cuando el ritmo

de juego cambia sería más complejo de hacer.

Creo que en ese nivel UPMusic cumple a la

perfección; es decir, si queréis poder pasar

de una pista de audio a otra en cualquier mo-

mento, desde cualquier lugar y con un suave

fundido este prefab es una gran opción.

Como no todo es bueno en este mundo he

de decir que finalmente decidí no usar UP-

Music. ¿Porque? La respuesta es muy fácil,

mis necesidades no encajaban dentro del

perfil perfecto que acabo de describir. Yo no

tengo una sola pista de fondo durante el

juego, tengo dos que además duran desde el

principio hasta el final por lo que en ningún

momento necesito fundir nuevas pistas de

fondo perdiendo uno de los puntos claves.

Cuando me hice con UPMusic mi intención

era tener dos pistas reproduciendo conti-

nuamente y reproducir utilizando el mismo

sistema los efectos propios del personaje,

de los enemigos, de los objetos…

Aquí encontré el mayor problema, UPMusic,

como su propio nombre indica en un sistema

para música, no para efectos y dado que mis

necesidades musicales eran tan “simples” de-

cidí guardar UPMusic para futuros usos.

Es posible que en el juego final, donde si

tendré más pistas de audio recupere UP-

Music del “cajón” virtual.

Puntos positivos:

ⱷ Uso muy sencillo

ⱷ Fundido entre pistas automático

ⱷ Editor visual de pistas

Puntos negativos:

ⱷ Poco personalizable

ⱷ Solo una pista de audio a la vez

www.unityspain.com 5

ARTÍCULO

UPMusic review DAVID COLLADO

UPMusic

01UPMUSIC REVIEW_Páginas maqueta 22/07/2011 10:56 Página 5

La compañía String ha lanzado recientemente

su librería de realidad aumentada para Unity.

Esta librería nos permite de forma realmente

sencilla utilizar la realidad aumentada dentro

de nuestro juego para iOS. Para aquel que

desconozca que es la realidad aumentada

aquí tenéis la definición de Wikipedia:

La realidad aumentada (RA) es el término

que se usa para definir una visión directa o

indirecta de un entorno físico del mundo

real, cuyos elementos se combinan con ele-

mentos virtuales para la creación de una

realidad mixta a tiempo real.

Un claro ejemplo de juego de realidad au-

mentada que ha triunfado bastante y además

ha sido desarrollado en España es Invizimals.

En este juego podemos utilizar unas simples

tarjetas para, a través de la cámara de PSP, ver

monstruos increíbles “salir” de ellas.

La realidad aumentada abre posibilidades en

muchos campos, pero puesto que aquí ha-

blamos de videojuegos, pasaré por alto el

resto de opciones. Este artículo tratará en

concreto de String, aunque existen otras op-

ciones en el mercado e incluso es posible

desarrollar una propia. Hablaremos de String

ya que acerca esta opción a Unity y además

pretende abordar un mercado más indie,

lejos de licencias, quizá excesivas, que solo

dejan la tecnología al alcance de unos pocos.

Antes de entrar en cómo funciona String (y en lo

que más preocupa a un programador, o lo que

es lo mismo, qué tengo que hacer para que fun-

cione) veamos cuáles son las claves que ofrece.

• Versión gratuita: para pruebas o aplicacio-

nes de las que no se obtenga beneficio alguno.

• Preview desde Unity: no es necesario

compilar, podremos usar la cámara de

nuestro Mac para realizar pruebas.

• Increíblemente rápido: funciona in-

cluso en iPhone3G sin consumir apenas

CPU y memoria.

• Estable: aún bajo malas condiciones de

luz String reconoce bien los marcadores.

• Sencillo: uno de los grandes pilares de

Unity es hacer fácil lo difícil, rasgo que

String comparte.

• Nos permite simular las condiciones de

luz reales en nuestro entorno 3D utili-

zando los cambios sobre el marcador.

Bajo esta misma clave voy a explicar las lí-

neas de código necesarias para conseguir

colocar un objeto 3D, el que queráis, sobre

un marcador personalizado.

Empezaremos por crear nuestro marcador,

o sea, la imagen que seguirá la cámara y

que deberá reconocer. Para hacer la ima-

gen solo debéis seguir estas bases:

• Borde de alto contraste (negro/

/blanco). Debe tener un margen blanco

y luego un borde negro, como si de un

marco se tratase.


ARTÍCULO

STRING, REALIDADAUMENTADA EN UNITY

STRING, REALIDAD AUMENTADA EN UNITY DAVID COLLADO

02STRING CON UNITY_Páginas maqueta 26/07/2011 13:08 Página 7

8 www.unityspain.com

• No puede ser simétrica en ambos ejes. Un cuadrado no

vale, por ejemplo.

• Debe tener la suficiente cantidad de imagen diferencia-

ble. Esto se aplica sobre todo cuando queremos utilizar va-

rias imágenes. String es capaz de reconocer hasta 10

imágenes simultáneamente.

Siguiendo esta base, podéis trabajar con cualquier

imagen a vuestra elección: fotos, imágenes sencillas,

figuras, textos...

Con nuestro marcador preparado solo necesitaremos estas

líneas de código:

public GameObject NuestroModelo;

StringWrapper stringWrapper;

void Start ()

{

if (iPhoneSettings.screenOrientation ==

iPhoneScreenOrientation.Landscape ||

iPhoneSettings.screenOrientation ==

iPhoneScreenOrientation.LandscapeLeft ||

iPhoneSettings.screenOrientation ==

iPhoneScreenOrientation.LandscapeRight)

{

camera.rect = new Rect(0.0555f, 0, 0.8888f, 1);

camera.fieldOfView = 36.3f;

}

else

{

camera.rect = new Rect(0, 0.0555f, 1, 0.8888f);

camera.fieldOfView = 47.22f;

}

stringWrapper = new StringWrapper(null,

camera);

stringWrapper.LoadImageMarker(“NombreDe

Marcador, “png”);

}

void Update ()

{

int markerCount = stringWrapper.Update();

for (int i = 0; i < markerCount; i++)

{

StringWrapper.MarkerInfo markerInfo = string

Wrapper.GetDetectedMarkerInfo(i);

NuestroModelo.transform.position =

markerInfo.position;

NuestroModelo.transform.rotation=

markerInfo.rotation;

}

}

Veamos el código por partes para entender como de básico resulta. Este

código está extraído de la escena de demo y modificado para registrar un

solo marcador en lugar de varios, para simplificar aún más el ejemplo.

Artí

culo



public GameObject NuestroModelo;

La primera línea es la variable pública para nuestro modelo.

Simplemente un objeto dentro de Unity.

StringWrapper stringWrapper;

La segunda línea es la variable necesaria para trabajar con la

realidad aumentada. De ella obtendremos toda la informa-

ción de los marcadores.

La primera parte dentro de la función start está dedicada al

formato de la cámara para ajustar la imagen de la cámara al

formato de la pantalla.

stringWrapper = new StringWrapper(null, camera);

stringWrapper.LoadImageMarker(“NombreDeMarcador, “png”);

La parte que nos interesa de la función start es esta. En

ella creamos una instancia del StringWrapper y lo guarda-

mos en la variable que habíamos declarado y cargamos en

el nuestro marcador. En el caso de tener varios marcado-

res los añadiremos todos. El marcador debe estar en la

carpeta StreamingAssets.

int markerCount = stringWrapper.Update();

En esta línea mandamos actualizar al StringWrapper para

obtener nuevos datos. Sencillamente debemos incluirla

cada vez que queramos hacerlo, lo normal es hacerlo den-

tro del Update para que se realice cada fotograma. La fun-

ción nos devuelve el número de marcadores reconocidos

en la imagen procesada.

for (int i = 0; i < markerCount; i++)

Utilizamos este sencillo bucle para recorrer los marcadores

procesados.

StringWrapper.MarkerInfo markerInfo =

stringWrapper.GetDetectedMarkerInfo(i);

Creamos una variable que contendrá la información del

marcador y llamamos a la función GetDetectedMarke-

rInfo(int Index) para obtener el marcador reconocido.

Aunque solo utilicemos un marcador, podemos tener va-

rias copias impresas de la misma imagen por eso es im-

portante recorrerlos con el bucle y no acceder

directamente al índice 0 siempre.

NuestroModelo.transform.position = markerInfo.position;

NuestroModelo.transform.rotation = markerInfo.rotation;

En estas dos líneas son las más importantes. En ellas extrae-

mos la posición y rotación del marcador y podemos utilizarlas

para situar nuestro objeto.

Como hemos visto, trabajar con String es realmente sencillo.

En mi caso, en unos pocos minutos estaba alucinando viendo

un soldado 3D salir de mi televisión.

El proceso tanto para utilizar String dentro de Unity como

para añadir las librerías a xcode estará explicado en la do-

cumentación, pero es realmente sencillo también y solo

tendremos que hacerlo una vez.

Después de varios días probando y jugando con las opcio-

nes que trae String creo que descargaré la versión gratuita

tan pronto como sea posible, con idea de ver que puedo

hacer y como lo acepta el mercado. Los precios de String

ya han sido desvelados, dejando unas licencias cuanto

menos interesantes. Aquí tenéis la tabla que también po-

deis encontrar en su web. Sigo pensando que lo mejor que

han podido hacer es ofrecer una versión gratuita, con usos

desde “vender” la tecnología a un cliente a cacharrear tran-

quilamente en casa pensando en las oportunidades que la

realidad aumentada nos ofrece.

9www.unityspain.com

Artí

culo




ARTÍCULO

MAXIMIZACIÓN DE MÓVIL, REALIDAD AUMENTADA Bob Berkebile

MAXIMIZANDO LA REALIDADAUMENTADA MÓVIL

No se puede detener el progreso.

La Realidad Aumentada Móvil inundara el

paisaje de los consumidores en los próxi-

mos 6 meses, tanto si gusta como si no. Sé

que una gran cantidad de la comunidad de

diseño y desarrollo considera cualquier

forma de realidad aumentada un truco,

pero me temo que se ha olvidado lo que es

sorprenderse ante uno de ellos. No me

malinterpreten, es difícil permanecer ino-

cente cuando se sabe cómo funcionan los

efectos especiales, pero si se descuida la

inocencia de nuestra audiencia nos queda-

remos atrás inevitablemente.

Dicho esto me gustaría ofrecer una breve

lista de lo que he descubierto al trabajar con

la Realidad Aumentada Móvil, así como al-

gunos consejos y algo de vocabulario técnico

para algunas técnicas que he aprendido.

INTEGRACIÓN

He llegado a notar que hay básicamente dos

géneros de realidad aumentada: precisa e

integrada. La realidad aumentada precisa

no es más que la composición de los obje-

tos 3D sobre imágenes en directo y la co-

rrecta manipulación de estos objetos para

hacerlos coincidir con el espacio natural

según las dimensiones que ocupan y reducir

al mínimo el error. La realidad aumentada

integrada tiene la funcionalidad básica de la

realidad aumentada precisa, pero se es-

fuerza por imitar la luz, la reflexión, la som-

bra y las propiedades de otros objetos del

mundo real para lograr una integración per-

fecta cerca de los objetos 3D.

Cuando se utiliza String en Unity usare-

mos una luz direccional en la escena que

podemos enlazar con String a través del

color que se devuelve desde String-

Wrapper para teñir fácilmente la escena

y que coincida con la iluminación en el

mundo real. Además, baja el brillo de la

luz (.15 - 0.2 funciona muy bien para si-

mular una iluminación interior). Si tie-

nes el conocimiento suficiente como

para utilizar un shader personalizado

que tenga propiedades de color asocia-

das a su specular, asegúrate de ajustar

los colores con el valor de color de

StringWrapper, y utilizar un mapa de

normales puede merecer el impacto en

el rendimiento una vez que veamos el

sorprendente resultado.

Nada en el mundo real es perfecto, que es

exactamente la razón por la que realidad au-

mentada siempre parece falsa. Una gran téc-

nica para componer una escena de realidad

aumentada consiste en crear una capa de

ruido (GUITexture en Unity) para añadir im-

perfección a todo (el efecto realmente ayuda

a fusionar todo). Yo uso dos, una de 480 × 320

y otra de 960 × 640 según la resolución del

03MAXIMIZACIÓN MÓVIL..._Páginas maqueta 26/07/2011 13:09 Página 11


iPhone. Tendrás que ajustar la opacidad para que funcione a tu

gusto y de modo que apenas se note. Asegúrate de cambiar “Tex-

ture Type” a GUI para asegurarte de que aparecen lo más limpias

posible. Para configurar fácilmente una capa de ruido inteligente

que cargue correctamente la imagen del tamaño adecuado en

función del iPhone coloca las texturas en la carpeta “Resources”

y añade este script a un GUITexture (C #):

using UnityEngine;

using System.Collections;

public class Noise : MonoBehaviour

{

float opacity = .05f; //Ajusta este valor segun la

cantidad de ruido que quieras

void Start ()

{

GUITexture _guiTexture = guiTexture;

//Guardamos en ache la guiTexture para

acelerar los siguientes pasos

if (Screen.width>320) {

_guiTexture.texture=(Texture2D)Re

sources.Load(“largeNoise”);

}else{

_guiTexture.texture=(Texture2D)Re

sources.Load(“smallNoise”);

}

transform.position = Vector3.zero;

Rect_pixelInset=newRect(0,0,Screen.width,

Screen.height);

_guiTexture.pixelInset = _pixelInset;

_guiTexture.color = new Color(1,1,1,opacity);

}

}

Las cámaras de los móviles ajustan automáticamente la expo-

sición, el brillo y otras propiedades. Esto significa, básicamente,

que el color negro simplemente no existe en la imagen que cap-

turan. Ten esto en cuenta cuando vayas a crear objetos que “de-

berían” ser negros. Acercar las texturas más negras al gris

ayudará a alcanzar los niveles de las cámaras móviles.

Siempre, siempre, siempre añade una sombra usando una

textura transparente en los objetos. Nada incrementa más el

realismo que una sombra. Esa draw call extra, resultado de

la necesidad de tener dos materiales (el transparente y la tex-

tura real) vale la pena el 100% del tiempo. Siempre.

DESPLAZAMIENTO

El hecho de que la realidad aumentada móvil actual requiera

un marcador no quiere decir que tengamos que utilizarlo de

base de operaciones para todo lo que hagamos. A la hora de

crear un escenario para realidad aumentada ten en cuenta la

posibilidad de colocar los objetos más cerca de una superficie

real alejándolos del marcador de seguimiento.

Aunque desplazar objetos requiere hacer algunas mediciones

en bruto y compilar varias veces para asegurar que todo esté

perfecto, el efecto es poco menos que increíble.

INSERCIÓN

El enmascaramiento de la geometría que pasa por el plano

del marcador o cualquier otra superficie predeterminada o

estructura se puede obtener fácilmente con las técnicas de

enmascaramiento que mencioné en mi anterior artículo

sobre el enmascaramiento en Unity. Esta técnica se presta

fuertemente a los efectos y animaciones que necesites para

eliminar o animar los objetos de una manera lógica en la que

algo se adhiere a la realidad. Si se utiliza un plano marcador

se puede crear fácilmente un portal o una puerta para per-

mitir que los objetos entren a través de él.

CREACION DE TÚNELES

Utilizando las técnicas de enmascaramiento que he mencio-

nado en el anterior artículo de este número se pueden crear

máscaras que pueden imitar las depresiones. Aunque este

efecto se puede hacer con un simple contenedor enmasca-

rado para simular profundidad en una superficie, la creación

de la geometría de apoyo en torno a la superficie hundida

ayudará a desvanecer el efecto en la realidad. Cuando se hace

bien, este efecto da muy buen resultado y se presta muy bien

al uso en juegos.

Artí

culo

MAXIMIZACIÓN DE MÓVIL, REALIDAD AUMENTADA Bob Berkebile


MARCADORES ALTERNATIVOS Y MULTIPLES MARCADORES

La peor parte de la realidad aumentada móvil es mostrar a la

gente tu último trabajo cuando no estás preparado. Para evi-

tar tener que decir: “Hemos hecho un gran trabajo de reali-

dad aumentada, pero... bueno... ¿sabes dónde puedo encon-

trar una impresora?” Debemos poner siempre un marcador

adicional en cada aplicación que estemos seguros de tener

con nosotros donde quiera que vayamos (en una tarjeta de

visita, por ejemplo. De esta manera nunca tendremos probl-

mas para mostrar nuestro trabajo.

El seguimiento sin marcadores no está aquí todavía, pero

todos queremos más libertad en nuestro lienzo de realidad

aumentada. ¿Por qué no utilizar varios marcadores? Pode-

mos permitir que varios marcadores hagan referencia a un

mismo objeto y una vez que encontremos un marcador de-

jamos de buscar y calculamos el desplazamiento desde el

“marcador de origen”. De esta forma tener lienzos de 360

grados no es imposible.

13www.unityspain.com

Artí

culo

Bob Berkebile


¿Quien esta detrás de Cupra Studios?

Cupra Studios es una start-up fundada

en 2011 por tres socios, todos por de-

bajo de los 30 :-) Somos unos apasiona-

dos de los videojuegos, de Internet y de

Unity, que es la mejor herramienta de

que disponemos para poner en el mer-

cado títulos atractivos.

¿Porque os metisteis en el mundo de los

videojuegos?

Como suele ocurrir en estos casos, em-

piezas siendo un jugador frecuente y

en algún momento empiezas a sentir la

necesidad de crear tus propios juegos.

En nuestro caso, el primer experimento

fue en 2010: nos presentamos a un

certamen internacional de videojuegos

que organizaba la UPM y ganamos el

primer premio. Eso nos hizo pensar

que quizá había opciones de dedicar-

nos profesionalmente a este competi-

tivo (y no siempre gratificante) sector

del entretenimiento.

¿Porque elegisteis Unity?

Porque uno de los retos del mercado es el

TTM (Time to Market), y Unity nos permite

reducir al mínimo los plazos que propone-

mos a nuestros clientes, lo cual a ellos les

permite ser más competitivos con los pro-

ductos que hacemos con o para ellos.

Por otra parte, hoy en día ser multiplata-

forma es prácticamente imprescindible.

Quienes apuesten por unos ecosistemas y

descarten otros pagarán su error, porque

en el fondo los usuarios lo que valoran es

el contenido, no el soporte del mismo.

¿Os habéis planteado otro motor?

A día de hoy estamos más que satisfe-

chos con Unity. Noticias como la que se

ha publicado recientemente, en la que

anuncian el soporte de los nuevos termi-

nales Blackberry, nos hace pensar que

seguirá siendo nuestra opción preferida.

Sólo esperamos que su éxito no se les

suba a la cabeza.

Si tenéis que elegir una, ¿Cual seria la

mejor característica de Unity?

Como ya hemos comentado, el poder

sacar un producto en varias platafor-

mas sin apenas cambios es la caracte-


ENTREVISTA

ENTREVISTA CUPRA

CUPRA STUDIOS

04ENTREVISTA CUPRA_Páginas maqueta 22/07/2011 10:59 Página 15


rística diferenciadora y el principal motivo por el que

lo usamos.

¿Que lenguaje de programación usáis en Unity?

Utilizamos Javascript, aunque determinadas funcionalidades

sólo están accesibles desde C Sharp, por lo que a veces tam-

bién tenemos que tirar de este lenguaje.

¿Os gustaría crecer hasta ser una empresa de gran tamaño

o os gusta un mercado mas “indie”?

Nuestro objetivo es crear títulos que apasionen a los jugado-

res, el tamaño de la empresa es irrelevante. Las producciones

indie no necesariamente son más atractivas para el jugador,

lo único que importa es la calidad del producto final, y a ese

respecto sólo pueden opinar los jugadores.

¿Cual es vuestro sueño de juego futuro?

Uno al que jueguen millones de personas durante años :-)

¿Que aspectos consideráis antes de comenzar a producir un

Videojuego?

La primera fase es la conceptualización. Pensamos en una idea

que pueda encajar con la marca o empresa que nos contrata,

y le damos forma a través de alguno de los géneros clásicos del

videojuego. Después consideramos el público objetivo, los an-

tecedentes de productos interactivos en torno a dicha marca,

y buscamos algunos elementos que puedan llamar la atención

a los futuros jugadores y, como no, a la prensa (que son quienes

opinarán sobre el juego en primera instancia).

Después se plasman todas las conclusiones en el GDD (Game

Design Document), y se itera sobre dicho documento hasta

que todos estamos conforme. El siguiente paso es diseñar las

pantallas, los flujos de navegación y los parámetros internos

del juego, para estimar plazos de ejecución.

Montamos rápidos prototipos a base de cubos y cápsulas, lo que

nos permite ir depurando los diferentes componentes hasta acer-

carnos a una experiencia de juego similar a la final. A partir de ahí,

sólo nos queda terminar de materializar nuestro concepto. :-)

¿Como coordináis el equipo?

El equipo es pequeño (5 personas), por lo que por ahora re-

quiere poca coordinación. Cada uno de nosotros está espe-

cializado en determinadas áreas, por eso el reparto de las

tareas es también sencillo.

¿Que metodologias utilizais?

Nos basamos en los principios de SCRUMM, que es una me-

todología ágil, que se basa en iterar hasta que el resultado se

parezca a lo que todos esperábamos que fuese el juego. Cual-

quier metodología que teorice demasiado antes de ver los

primeros resultados probablemente no sea adecuada en el

mundo de los videojuegos, donde la conexión emocional con

el jugador no es algo que pueda valorarse desde un docu-

mento o un diagrama, sino sólo con la experiencia hands-on.

¿Que material de apoyo creéis que debe tener un Programador

siempre a mano a parte de la documentación del lenguaje?

Un programador necesita muchos ejemplos y un buen foro al que

acudir. Nosotros encontramos la mayoría de las respuestas en los

foros de Unity, y en muchos casos tiramos de ejemplos creados por

otros programadores para resolver nuestras propias problemáticas.

En ambos casos, lo que subyace es la existencia de una comunidad

fuerte que respalde la tecnología, como es el caso de Unity.

¿Que factores tenéis mas en cuenta a la hora de programar?

La clave para nosotros es no dejarnos influenciar por nuestra

visión de programadores. Muchas veces, durante un proceso

de desarrollo, resulta difícil mantenerse en la piel del consu-

midor, y se tiende a juzgar los resultados desde una perspec-

tiva puramente técnica. Eso es un error grave, porque en ese

momento dejas de programar para otros y lo haces sólo para

ti, lo que obviamente desencadena graves consecuencias en

el grado de acogida que tu producto tendrá finalmente.

¿Que consejo daríais a alguien que empieza en este mundo?

El mejor consejo que podemos dar es que la persona en cuestión

reflexione muy concienzudamente sobre las ganas que tiene de

introducirse en un sector extremadamente competitivo, porque

si no está plenamente convencido, es muy probable que se des-

motive antes de poder hacer realidad su producto.

Para vosotros, que es mejor : ¿Un juego con buenos gráficos

o un juego con buena jugabilidad?

Sin duda lo segundo. Los buenos gráficos son una simple

cuestión de dinero y recursos, la jugabilidad, todavía a

fecha de hoy, no puede comprarse. La jugabilidad es el

En

trevista

ENTREVISTA CUPRA


reflejo del talento creativo de los programadores: si el

resultado no es jugable, el producto sólo servirá para

acumular premios de los certámenes que obvian en sus

valoraciones el criterio más importante: la opinión de

los usuarios.

¿Que herramientas usáis para planificar el trabajo de todos

los integrantes y que no haya tiempos muertos para algunos

de ellos?

Como comentábamos, el equipo es pequeño y no tenemos

esos problemas (todavía). Muchos trabajamos hasta los fines

de semana, así que la expresión “tiempos muertos” todavía

no existe en nuestro diccionario.

¿Dedicáis parte de vuestros esfuerzos desarrollos I+D

propios? (bien creando herramientas internas para

usar con Unity que no existen o queréis desarrollar

vosotros, bien creando programas externos o incluso

un engine propio...)

No, todos los trabajos que hacemos son por petición de

un cliente o para explotar una oportunidad comercial in-

teresante con una marca potente, principalmente del sec-

tor audiovisual.

¿Cómo veis el desarrollo de videojuegos en España? ¿Hay

futuro más allá del boom móvil?

Los desarrolladores están muy focalizados en las grandes

producciones, que es un nicho cada vez más inalcanzable,

y que de hecho atraviesa una fuerte crisis en todo el

mundo. Por eso, la clave reside en producciones que pue-

dan estar en la calle en poco tiempo y con pocos recursos.

En los últimos meses hemos asistido a fracasos estrepito-

sos de grandes producciones como Homefront, mientras

que juegos como Angry Birds, con costes ridículos, hacen

cifras astronómicas de ingresos.

Si tenéis que elegir una plataforma, ¿iPhone o Android?

¿Cual es vuestra experiencia con ambas plataformas?

Si tenemos que decantarnos por una, nos quedamos con iPhone,

Android, Symbian, Windows Phone y Blackberry :-) Como ya hemos

comentado, estar en todos los ecosistemas es imprescindible.

Más personalmente, ¿Que os parece UnitySpain? ¿Y UDev?

Es un medio muy necesario para que todos los programado-

res de Unity puedan trabajar de forma colaborativa, que es

la única forma de que podamos ver grandes productos de jue-

gos con sello nacional. La labor que hacéis es muy provechosa

para los que nos dedicamos profesionalmente a este sector,

y estoy convencido de que con vuestros contenidos invitáis a

mucha gente a que se una a este mundillo, lo cual es también

francamente positivo.


En

tre

vis

ta

ENTREVISTA CUPRA


Durante los dos últimos meses he estado

trasteando con Unity3D en un proyecto

para Luma Arcade, y en su mayor parte ha

sido una experiencia fantástica. Los 5 años

de construcción de sus herramientas y su

gran base de usuarios para probarlo y dar

soporte realmente hacen brillar a Unity.

Obtener conceptos simples es ridícula-

mente fácil (como demuestran desafíos

como la reciente Game.Dev de 48 horas)

gracias a su intuitiva interfaz. Las potentes

herramientas de arte y el scripting en C#

permiten que nuestros primeros esfuerzos

mejoren hasta llegar a productos de pri-

mera categoría.

Unity tiene una reputación en algunos cír-

culos de ser una herramienta limitada a la

web, las plataformas móviles, o juegos re-

lativamente simples para PC y Mac. Su re-

ciente impulso en el mercado tradicional

de la consola, con versiones de su motor

para Xbox 360 y PS3 (ya hay una versión

para Wii) va a cambiar eso. En su mayor

parte, diría que están listos para el salto y

muchos desarrolladores le darán la bienve-

nida como una herramienta más. Sin em-

bargo, existen algunas cuestiones que me

gustaría señalar aquí a las que personal-

mente creo necesario prestar seria aten-

ción antes de que Unity se convierta en la

herramienta ideal para hacer juegos a me-

diana o gran escala en consolas. Hay que

tener en cuenta que estas son mis propias

opiniones y no necesariamente las de

Luma, sus directores o empleados.

Obsoleto e inestable soporte IDE

Unity tiene la capacidad de generar proyec-

tos que permiten a los desarrolladores tra-

bajar con un proyecto de Unity en

Monodevelop (que se incluye con Unity) o

Visual Studio. Estos proyectos pueden ser

completamente depurados como un pro-

yecto nativo. Esta es la teoría al menos y he

visto este sistema de trabajo en otros des-

arrolladores. Mi experiencia personal, sin

embargo (y en base a informes en línea), es

que Monodevelop se cuelga en cuestión de

minutos al intentar depurar un proyecto de

Unity. Los proyectos se generan también en

el antiguo formato de Visual Studio 2008,

y se vuelven a generar cada vez que se

agrega un archivo dentro de Unity, por lo

que actualizar manualmente los proyectos

hasta el formato 2010 no es una opción

práctica. Esto deja a aquellos de nosotros

con un software actualizado en la oscuri-

dad. Teniendo en cuenta la importancia de

ser capaz de depurar correctamente, esto

es un gran problema que hay que enfren-

tar. Dar a los desarrolladores la opción de

trabajar en Visual 2010 debería ser una

mejora bastante trivial, los problemas de

estabilidad en Monodevelop, por supuesto,

supondrán un gran desafío.

C # como ciudadano de segunda clase

Unity soporta JavaScript, C# y Boo. El enfo-

que en la documentación y los ejemplos está

muy enfocado hacia JavaScript, y hay algunas

áreas (como la falta de apoyo adecuado para

espacios de nombres, caprichos intentando

importar código C# y apoyo desfasado de

API´s) que apuntan a C# como un ciudadano

de segunda clase al menos dentro de la pro-


ARTÍCULO

¿ESTÁ UNITY PREPARADO PARA EL DESARROLLO EN CONSOLAS? Matt Benic

"Rochard, el primer juego de Unity3D para ps3"

¿ESTÁ UNITY PREPARADO PARA EL DESARROLLO ENCONSOLAS?

05ESTA PREPARADO UNITY..._Páginas maqueta 26/07/2011 13:11 Página 19


gramación para Unity. Entrando en el espacio de desarrollo de

consola, C# es la elección para la mayoría de los equipos debido

a su similitud con el todavía dominante C+ +. No hay duda de

que la naturaleza flexible de JavaScipt tiene algunas ventajas

sobre C# con su rigidez más tradicional, pero apostaría a que la

familiaridad saldrá ganando en este caso y los equipos de con-

sola optarán por C #. Por esta razón creo que Unity se benefi-

ciaría de un mayor soporte para C#. Parece que esto ya está

sucediendo, ya que la documentación en línea por lo menos

ahora (la mayoría) incluye ejemplos en los dos idiomas.

Prefabs inestables

El excelente sistema de prefabs en Unity permite la creación

de objetos reutilizables llamados prefabs que se pueden agre-

gar fácilmente a una escena y luego ser modificados leve-

mente para cada instancia, pero aún disfrutaran de los ajustes

posteriores realizados sobre el prefab. El problema aquí es

que estos prefabs no se pueden anidar, por lo que por ejem-

plo si creamos un prefab de una rueda, lo agregamos a un

coche y hacemos un prefab con él, la conexión al prefab de

la rueda se pierde y cualquier cambio futuro al prefab de la

rueda no se transmite a las instancias de la rueda en el coche.

Esto disminuye el valor de los prefabs y sería ideal que Unity

agregase soporte para ello.

Formatos de objeto binarios

Las escenas de Unity y los archivos (incluyendo sus prefabs) son

binarios, y como tal no pueden ser fusionados por los típicos sis-

temas de control de versiones. Teniendo en cuenta el modelo

modular de componentes que usa Unity, varios programadores

o artistas a menudo necesitan tener acceso simultáneo a estos

archivos a medida que trabajan en la funcionalidad de partes di-

ferentes sobre el mismo objeto. Esto lleva a casos de bloqueo que

empeorarían con equipos más grandes. Lo ideal sería que los ob-

jetos fuesen un formato de texto fácilmente combinable como el

XML. Existen, por supuesto, ventajas a nivel de rendimiento para

usar un formato binario, pero no hay razón para que estos no se

pueden generar cuando se compila para la plataforma de destino,

conservando XML como formato de trabajo.

Asset server

Siguiendo con el tema de control de versiones, existe un con-

trol de assets integrado en Unity llamado Asset Server (re-

quiere de licencia). Ahora bien, aunque la idea de control de

assets integrado en el entorno de desarrollo es atractiva, la

realidad es que este sistema no es tan amplio como un SVN.

También tiene algunos problemas serios tales como la actua-

lización de los archivos de determinados proyectos (en espe-

cial los archivos .asset que definen un comportamiento en

todo el proyecto) causando que el proyecto quede inutiliza-

ble. Por mi parte, acogería con agrado la sustitución del sis-

tema propietario Asset Server con estándares más comunes,

como SVN, o incluso algo así como Git o Mercurial que apoya

a los equipos distribuidos, un fenómeno cada vez más común

en nuestra industria.

Centrarse en los clientes que no pagan

La licencia libre para desarrolladores independientes ha lle-

vado a Unity muy lejos, y su apoyo admirable por el mercado

independiente ha sido sin duda una parte enorme en conse-

guir que la plataforma esté donde se encuentra hoy. Llega un

momento, sin embargo, en que los clientes que pagan tienen

que tener prioridad y, si Unity busca entrar en el mercado de

las consolas, el cambio de dirección tendrá que venir más

temprano que tarde. El sistema de feedback de Unity en el

que los usuarios votan las mejoras y nuevas características es

un buen ejemplo de un lugar donde es necesario este cambio.

Los usuarios gratuitos tienen el mismo peso en este sistema

que los de pago, y esto da como resultado que características

que no son tan importantes para los desarrolladores profe-

sionales (como el soporte de Linux) terminan ahogando me-

joras que ayudan al desarrollo profesional, como algunos de

los cambios mencionados arriba.

Modelo de Licencia

Otro ejemplo del enfoque de Unity hacia los pequeños des-

arrolladores es su modelo de licencia. Por lo general, cobran

una licencia por puesto y plataforma. Recientemente también

se anunció un acuerdo de licencia con EA que da a todos los

desarrolladores de la editora pleno acceso a las herramientas

de Unity. Lamentablemente, no todos los desarrolladores

profesionales tienen el poder de EA, y esto deja un gran vacío

para medianos y grandes estudios que prefieren comprar una

licencia de grupo. Un sistema de licencias por paquetes es

necesario y, de forma ideal, con descuentos a medida que au-

menta el tamaño del grupo.

Artí

culo

¿ESTÁ UNITY PREPARADO PARA EL DESARROLLO EN CONSOLAS? Matt Benic

05ESTA PREPARADO UNITY..._Páginas maqueta 26/07/2011 13:11 Página 20

¿Cuándo y donde nació vuestra compañía?

Recoil Games fue fundada en noviembre

de 2006 en Helsinki, Finlandia.

¿En que consiste vuestro juego?

Rochard es un juego de acción y plataformas

con una buena cantidad de puzles a lo largo

de su desarrollo. El protagonista el juego es

un minero espacial llamado John Rochard.

John recorre una historia interesante con un

misterio ancestral que debe resolver, múlti-

ples personajes amistosos, algunos tipos

malos, grandes cantidades de humor y algu-

nos momentos trágicos. El juego va a ser pu-

blicado por Sony Online Entertainment y

estará disponible en PSN este verano.

¿Cuáles son para vosotros las claves de

vuestro juego? Las que harán que la gente

realmente disfrute de el.

El jugador obtiene el control sobre la grave-

dad. Esta es una parte fundamental del juego

y uno de los factores que diferencian a Ro-

chard. Otro punto importante es el G-Lifter,

una herramienta de minería usada para levan-

tar objetos pesados sin problemas. El jugador

lo utilizará para mover distintos objetos y in-

cluso a si mismo a o largo del juego, y además

podrá mejorarlo según progrese a través del

juego. La historia del juego es realmente im-

portante para nosotros, el juego incluye una

gran parte de diálogos, bastantes personajes

distintos y varias localizaciones.

¿Qué decidisteis primero, usar Unity como

motor o Ps3 como plataforma?

Decidimos usar Unity mucho antes de de-

cidir a PS3 como plataforma.

¿Por qué decidisteis usar Unity?

Habíamos oído muchas cosas buenas sobre

Unity pero realmente ninguno lo habíamos

usado antes, por lo que decidimos investigar

por nosotros mismos como de bueno era.

Por aquel entonces la versión de Unity era

la 2.6 y solo unos días después de empezar

a trabajar con el el equipo ya era familiar con

el motor y sabíamos como de bien iba a en-

cajar en el proyecto que teníamos en mente.

El flujo de trabajo sin precedentes fue uno

de los mayores elementos al tomar nuestra

decisión.

¿Por qué elegisteis Ps3 y no Xbox360, Wii,

iPhone u otra plataforma arcade?

En nuestra búsqueda de Publisher nos to-

pamos con Sony Online Entertainment. Po-

déis imaginar como establecimos Ps3 como

plataforma después de esto.

En este número tenemos un artículo ha-

blando de porque Unity no esta listo para

el desarrollo en consolas. ¿Cuál ha sido

vuestra experiencia al respecto?

Nuestra experiencia ha sido muy positiva.

Por supuesto, Unity estaba siendo desarro-

llado para Ps3 a la vez que nuestro juego, y

como cualquier tecnología joven encontra-

mos algunos problemas. Los desarrollado-


ENTREVISTA

ENTREVISTA RECOIL STUDIOS

RECOIL STUDIOS

06ENTREVISTA RECOIL_Páginas maqueta 22/07/2011 11:01 Página 21


res de Unity nos dieron un soporte muy activo y arreglaron

todos los problemas que tuvimos por parte del motor.

¿Incluye Unity para Ps3 alguna herramienta mas potente

para el desarrollo en consola?

Unity Ps3 incluye las mismas herramientas que Unity Pro.

¿Qué lenguaje de programación usáis en Unity?

Usamos C# por preferencias totalmente personales.

¿Habéis desarrollado plugins propios para ayudarnos en el

desarrollo?

Desarrollamos muchos plugins para el editor (todos usando

las clases del Editor) pero no plugins nativos.

¿Cómo ha sido vuestra experiencia con Unity?

Ha sido tal que de ahí la respuesta a nuestra siguiente

pregunta.

¿Estáis planeando vuestro próximo juego? ¿Usara Unity?

Si y ¡Si!.

¿Cómo coordináis vuestro equipo? ¿Alguna técnica ágil

como scrum?

Usamos una versión adaptada de scrum, que nos ha fun-

cionado bien hasta ahora. Somos fuertes creyentes de

las metodologías agiles y estamos encantados con los

resultados.

¿Cómo controláis el arte, código, versiones..? ¿Usáis alguna

herramienta como Subversion o Git?

Usamos el Asset Server de Unity,

¿Usáis mac’s o pc’s?

En la oficina solo usamos Pc, pero en algunas ocasiones algu-

nos miembros del equipo han usado sus mac’s.

¿Qué herramientas habéis usado? ¿Monodevelop?

Visual Studio.

Finalmente, ¿Tenéis alguna fecha de lanzamiento?

La fecha de lanzamiento en este momento es verano de

2011.

En

trevista

ENTREVISTA RECOIL STUDIOS

06ENTREVISTA RECOIL_Páginas maqueta 22/07/2011 11:01 Página 22

El enmascaramiento es una técnica

fundamental que tiene cientos de

usos. Basta con echar un vistazo a al-

gunos de mis trabajos de Flash para ver

dónde destaca realmente enmascarar

con respecto a la animación de la intro-

ducción de elementos visuales. Vi-

niendo de un fondo de Flash, quedé

estupefacto cuando me di cuenta de

que Unity no tiene ninguna técnica

para enmascarar geometría e imáge-

nes. Por suerte, encontré la respuesta

en el shader “Depth Mask”.

A pesar de que este shader es la respuesta

de Unity para enmascarar, no deja de tener

problemas si estas buscando una compara-

ción 1:1 con la máscara tradicional 2D. El

shader trabaja de manera que cualquiera

que sea la geometría utilizada, simple-

mente ocultará lo que se encuentre detrás

de él. Y esto quiere decir TODO lo que

quede detrás. La mejor manera de limitar

los efectos de esto es usar cámaras “en

capas” que hacen específicamente escena-

rio enmascarados.

El código para el shader “Depth Mask Sim-

ple” es corto y sencillo:

CODE:

Shader "Depth Mask" {

SubShader{

ColorMask 0

Pass {}

}

}

En una escena compleja con múltiples ma-

teriales se puede recurrir a esta versión si

la anterior no funciona:

CODE:

Shader "Depth Mask Complex"

{

SubShader

{

Tags {"Queue" = "Back-

ground"}

Blend SrcAlpha One-

MinusSrcAlpha

Lighting Off

ZWrite On

ZTest Always

Pass

{

Color(0,0,0,0)

}

}

}

Si se cambia algún aspecto del material del objeto

que está tratando de enmascarar (textura, colo-

res, etc.) ”Depth Mask”no funcionará a menos

que se ejecute el SetPass() del objeto que tenga

el shader en ese momento. Podéis descargar un

ejemplo en http://pixelplacement.com/wp-con-

tent/uploads/2011/02/Masking.zip


TUTORIAL

MÁSCARAS EN UNITY 3D Bob Berkebile

MÁSCARAS ENUNITY 3D

07ENMASCARAMIENTO_Páginas maqueta 22/07/2011 11:02 Página 23

INTRODUCCIÓN:

Bienvenidos a este tutorial de cómo

crear un lanzallamas en Unity3D.

Este tutorial va dirigido a personas

que ya hayan tenido un primer con-

tacto con este motor gráfico, pero sin

haber profundizado demasiado en sus

posibilidades.

Recomiendo tener abierto el Unity e ir

siguiendo paso a paso las diferentes ins-

trucciones ofrecidas aquí. También os

invito a que experimentéis y modifiquéis

lo que creáis conveniente, puesto que al

fin y al cabo, sois vosotros los que vais a

disfrutar creando videojuegos.

CONOCIMIENTOS PREVIOS:

Como este tutorial es bastante ex-

tenso, supondremos que el lector

tiene suficientes conocimientos como

para crear la siguiente escena y los

scripts necesarios para mover un per-

sonaje por el mapa y que una cámara

lo observe.

PLANIFICACIÓN:

Primero de todo, vamos a crear las carpe-

tas necesarias para tener bien organizado

el proyecto. Nos situamos en el Project

Panel y creamos 5 carpetas (click derecho

→ create → folder). Las renombramos con

los siguientes nombres: Escenas, Materia-les, Prefabs, Scripts y Texturas.Vamos a crear el punto de referencia en

donde se lanzarán las llamas.

Creamos un Empty GameObject que lo lla-

maremos Foco, y lo situaremos dentro de

el objeto Jugador en del Hieararchy Panel

(donde el objeto Jugador es el personaje

controlable en el juego) y lo situamos justo

delante de él.

Vamos a crear el script necesario para

activar el lanzallamas.

Nos situamos en la carpeta Scripts que pre-

viamente hemos creado y añadimos un ar-

chivo de código Javascript llamado Arma.


TUTORIAL

CÓMO CREAR UN LANZALLAMAS Marti Nogue

CÓMO CREAR UNLANZALLAMAS

08TUTORIAL LANZALLAMAS_Páginas maqueta 26/07/2011 13:12 Página 25


Dentro de éste añadimos el siguiente código:

var lanzallamas : Transform;

private var llamas;

function Update()

{

if (Input.GetMouseButtonDown(0))

{

var foco = GameObject.Find(“Foco”).transform;

var position = foco.position;

llamas = Instantiate(lanzallamas, position, transform.

rotation);

llamas.transform.parent = foco;

}

else if (Input.GetMouseButtonUp(0))

{

llamas.particleEmitter.emit = false;

llamas.GetComponent(“Lanzallamas”).apagar = true;

}

}

Explicamos brevemente el funcionamiento del script anterior:

En la función Update() comprobamos constantemente si nos

están pulsando el botón izquierdo del ratón. De ser así obte-

nemos la posición del objeto Foco que hemos creado antes e

“instanteamos” (hacemos aparecer) en esa posición el objeto

lanzallamas y lo emparentamos con el Jugador. De esta forma

el lanzallamas expulsará fuego justo enfrente del jugador.

Ahora bien, ¡nos falta el lanzallamas!

En este punto es cuando el asunto se pone interesante. Sea-

mos previsores y pensemos en la que se nos viene encima...

Como muchos de vosotros habréis imaginado, un lanzallamas es bá-

sicamente un sistema de partículas muy bestia. En nuestro caso lan-

zaremos una media de 1500 partículas por unidad de tiempo, aunque

podrían ser muchas mas. ¿Qué problema tiene esto? Ninguno si tie-

nes un superordenador para computar todos los cálculos.

Me explico: Cuando creamos un lanzallamas, normalmente

queremos que éste produzca algún efecto en el entorno, ya

sea dañar a enemigos o quemar algo.

Si lanzamos 1500 partículas, y para cada una de ellas comproba-

mos si colisiona con algún objeto (y de ser así, quemarlo), lo único

que conseguiremos chamuscar es la CPU de nuestro ordenador.

¿Cómo podemos solucionar este problema? ¿Reduciendo el

número de partículas? Podría ser una solución, pero entonces

el lanzallamas se parecería mas un mechero barato.

La solución es muy sencilla: crear 2 sistemas de partículas. El pri-

mero se dedicará exclusivamente a lanzar partículas de 1500 en

1500. El segundo se hará cargo de las colisiones, pero rebajando el

número de partículas expulsadas a unas 5 por unidad de tiempo.

Vamos por partes. Empecemos por crear el lanzallamas principal:

Creamos un sistema de partículas (GameObject → Create Other

→ Particle System) y modificamos los parámetros de forma que

se parezcan mas o menos a los que vienen en la siguiente ima-

gen. Para que funcione correctamente es de vital importancia

que el parámetro autodestruct esté activo. Podemos utilizar el

material Fire que viene por defecto en la colección Standard As-

sets para dotar de mas realismo el fuego del lanzallamas.

Añadimos también un componente Light(Components → Rendering

→ Light) y modificamos el color de la luz para que sea naranja-rojo.

Tuto

rial



Finalmente añade el componente World Particle Collider(Components → Particles) y pon a 0 el parámetro Bounce Fac-

tor, puesto que no queremos que las llamas reboten.

Vamos a por el segundo sistema de partículas. Hacemos un du-

plicado del anterior sin los componentes Light y Particle Rende-rer. Modificamos los valores MinEmission y MaxEmission a 5.

Añadimos este último sistema de partículas dentro del primero.

Ahora creamos un prefab dentro del Project Pane llamado

Lanzallamas y arrastramos y soltamos dentro de éste el sis-

tema de partículas.

Ahora que tenemos el prefab del lanzallamas, podemos arras-

trarlo y añadirlo en el objeto Jugador dentro del script

(Armas.js) que hemos creado.

Si probamos el juego, al mantener pulsado el botón izquierdo

del ratón, el jugador debería encender el lanzallamas.

Vamos a pulir algunos detalles:

Creamos un nuevo script llamado Lanzallamas y añadimos el

siguiente código para que la luz que desprende el fuego se

atenúe al dejar de lanzar las llamas.

private var apagar : boolean = false;

function Update ()

{

if (apagar) light.intensity -= Time.deltaTime;

}

Añadimos este script al prefab Lanzallamas (el objeto principal).

Ahora creamos otro script llamado Dano (o “Daño”, aunque es re-

comendable no utilizar tildes) y lo añadimos al prefab Lanzallamas(el objeto hijo, es decir, el sistema de partículas que lanza 5 partí-

culas por unidad de tiempo). El contenido del script es el siguiente:

var puntos : float = 5.0;

function OnParticleCollision (collision : GameObject)

{

if (collision.gameObject.GetComponent(Enemigo))

{

collision.gameObject.GetComponent(Enemigo).Heri

r(puntos);

}

}

Este script comprueba por cada partícula si el objeto con el que

colisiona tiene un script llamado Enemigo (que crearemos en el

siguiente y último paso). En caso afirmativo, ejecuta la función

Herir del enemigo y le resta una cantidad de puntos de vida.

Vamos a crear el último script que se encargará de recibir el

daño causado por las partículas de fuego del lanzallamas.

Creamos un script llamado Enemigo y le añadimos el si-

guiente código:

var vida : float = 10.0;

function Herir(puntos : float)

{

vida -= puntos;

if (vida <= 0) Destroy(gameObject);

}

Cada vez que una partícula colisiona con un objeto que con-

tenga este script recibirá cierto nivel de daño. En este caso, si

el nivel de vida llega a 0, el objeto es destruido (podríamos

haber implementado algún efecto visualmente mas atractivo,

como una desintegración, pero esta sección mas artística se

deja a cargo del lector).

Añadimos el script Enemigo a las cajas que se encuentran re-

partidas por el escenario y listo! Ya tenemos un lanzallamas!

Ahora ya podemos probar el juego. Si todo funciona correc-

tamente, al lanzar llamas sobre las cajas estas deberían per-

der vida hasta ser destruidas.

Espero que les haya sido de ayuda este tutorial. Hasta pronto!


Tuto

rial



udev 3

Documents