jueves, 26 de febrero de 2015

Futuros Creadores: Entrevista a Virginia Calvo Mangas, estudiante de ESNE

Después de un par de Masters de desarrollo de juegos de los que pudimos saber algo más mediante entrevistas, en la sección Futuros Creadores, a algunos de los estudiantes que actualmente los están cursando, hoy voy a pasar al Grado de Diseño y Desarrollo de Videojuegos de ESNE.

Sobre Virginia Calvo Mangas:

La estudiante que presento hoy se llama Virginia y está en el tercer curso de este Grado. Ha publicado junto con su grupo Kinoko Studios un total de 8 juegos y dos aplicaciones en Android (Algunos también en Windows Store), lo que demuestra que no para de trabajar. Su pasión es el diseño de juegos, aunque también le encanta dibujar y ha realizado un curso en GNOMON School of Visual Effects sobre Concept Art para Videojuegos, lo que le permite participar activamente en la parte artística de los proyectos e ilustrar sus documentos de diseño de juego.

Además, Virginia ha dado alguna que otra conferencia, por ejemplo sobre “El futuro de los Videojuegos” en un evento celebrado por la Universidad Complutense de Madrid, y actualmente se encuentra desarrollando su proyecto final de grado junto con sus compañeros/as.

Sobre el Grado en Diseño y Desarrollo de Videojuegos de ESNE

El Grado en Diseño y Desarrollo de Videojuegos de ESNE ofrece 4 años completos de estudios para el desarrollo de videojuegos, siendo los dos primeros con temas generales y los restantes a elegir entre 3 especializaciones: Diseño, arte o programación. Es pionero en España y ha sido el primer Grado Universitario Oficial bajo el amparo de Bolonia y dentro del Espacio Europeo de Educación Superior.

Durante el curso, los alumnos trabajan y se forman junto a algunas de las empresas tecnológicas multinacionales más importantes. Aprenderán a diseñar la aplicación o el juego, diseñar sus escenarios, crear personajes, programar, producir, aplicar códigos de arte y estrategias de juego que disfrutaran los usuarios en sus dispositivos.

Entrevista:


¿Cuándo y por qué empezaste a querer dedicarte a los videojuegos?

Creo que con el primer Theme Park que instaló mi padre en aquel ordenador, decidí que, o quería hacer parques de atracciones, o montañas rusas. Aunque, cuando conocí ESNE fue cuando realmente me decidí a emprender este camino. Yo estaba en AULA, en IFEMA, buscando alguna información para estudiar veterinaria, cuando vi el stand de ESNE, y me enamoré.

¿Qué dicen en tu entorno de que quieras dedicarte a esto?

Desde el primer momento mi madre me apoyó. Sus palabras fueron “Yo a esto, le veo futuro, es innovación, es creatividad, eres tú.” Aunque, todo hay que decirlo, parte de mi familia piensa que “Me paso el día jugando”.

¿Por qué elegiste estudiar en ESNE?

Como ya comenté anteriormente, lo vi en AULA, fue como un flechazo. Yo allí estaba toda decidida, cogiendo mis panfletos para veterinaria, cuando se cruzó un chaval en mi camino y me dijo “Llevas una camiseta del WOW, ¿No te gustan los videojuegos?”. Me acerqué a ver el stand, me contaron el temario, las asignaturas… Aunque, ya no era tanto ver el temario como ver a los propios alumnos que estaban ahí, que estaban tan motivados, tan felices…

Después de conocer ESNE, comparé con otras escuelas, pero ninguna me ofrecía lo mismo.

¿Se necesita tener conocimientos o experiencia para empezar la formación que has elegido?

¿Conocimientos? No lo creo. No mucho más de lo que te da “Jugar”. Eso es lo que tienes que hacer, ser un “Jugón” y haber jugado mucho. Ese es el requisito previo que yo pediría para esta carrera. Y por supuesto, saber inglés. Que a día de hoy, creo que debería ser algo obligatorio.

¿Crees que cuando termines el curso estarás preparada para trabajar en la industria? ¿Planeas continuar tu formación?

Preparada para trabajar sí. Pero como todo, especializarte, hacer un máster… Son cosas que hay que plantearse. En mi caso, estoy pensando irme a hacer un máster a California, a una Escuela llamada GNOMON. Estuve este verano haciendo unos cursos allí, y me gustaría realizar mi máster en este lugar.

Los críticos con estos estudios dicen que son demasiado generalistas y no permiten la especialización ¿En tu opinión, es cierto?

Sí que es verdad que son generalistas, pero, porque hay que serlo. Al igual que un médico tiene que hacer una especialización en cirugía plástica, nosotros también deberíamos. Intentan especializarnos lo más que pueden, pero no pierden el objetivo de que sepamos “Un poco de todo”. Hoy en día los equipos de trabajo ya no son solo como Blizzard, ahora hay muchísimos más equipos pequeños, en los que se trabaja mano a mano. Es difícil que un juego salga bien, sin saber cómo es el trabajo de tu compañero, cómo necesita que le pases los archivos… Por eso en ESNE nos motivan a crear un videojuego cada año, y cada año, con un equipo de 4 o 5 personas, solemos montar uno. Es una realidad de hoy en día en una empresa pequeña. ¿Te imaginas esto si cada uno solo hiciera “su parte”? Sería totalmente imposible.

¿Qué contenido es tu favorito del Grado que te encuentras estudiando?

A mí, me gusta el diseño. Me gusta crear, inventar. Y desde el minuto que puse el pie en ESNE, mis profesores me han ayudado a ello.

Aunque la parte artística siempre me llamó la atención, he de decir que el diseño me cautivó.

¿Es compatible con un trabajo o exige dedicación plena?

Es compatible. De hecho trabajo desde mucho antes de entrar en ESNE en una imprenta. Los profesores siempre intentan darte facilidades para estas cosas. Siempre tienes esas tutorías, esas clases de refuerzo… Sin duda puedes tener trabajo y estudiar en ESNE.

¿Qué crees que ha cambiado en ti como profesional respecto a cómo eras antes de empezar en ESNE hasta hoy que estás en tercero?

Creo que la experiencia en ESNE es toda una aventura. Entras en primero, pensando que sabes “la repera” de cosas sobre videojuegos, y te das cuenta de que no tienes “ni idea”. A medida que avanzas vas viendo un cambio MONUMENTAL.

Desde el primer juego que sacas en primero, con sus mil y un fallos, con sus gráficos cutres (Que para ti eran “la leche”), hasta tercero, que ya estás viendo el proyecto de fin de grado a la vuelta de la esquina… Hay un mundo.

Cada vez soy muchísimo más profesional con mis trabajos. Y se nota día a día.

¿Según tu criterio que habilidades debería tener un/a buen/a diseñador/a de Juegos?

Para mí un buen diseñador, tiene que saber “un poco de todo”. Tiene que saber sobre actualidad, sobre cómo está el mundo de las consolas y dispositivos, sobre qué géneros están de moda actualmente, cuáles son las tendencias… Y además, tener conocimientos mínimos de programación y de arte. Debe poseer unas buenas habilidades de comunicación verbal y escrita, ser creativo, tener una gran imaginación visual… Y sobre todo, lo más importante, saber trabajar en equipo.

¿Cuál es tu juego preferido o que más te ha influido?

¿Por dónde empezar? Podría hablar de las cientos de horas que pasé frente a juegos como Crash Bandicoot, Spyro, o Medievil. O de las miles de horas frente a juegos como World Of Warcraft, Spore, o los Sims… Pero la realidad es que yo diría que el Age Of Empires o Caesar III. Jamás se me olvidarán las muchimiles de horas que pasamos mi padre y yo, codo con codo, montando ciudades. Ordenadores juntos, refresco en mano, y teníamos todo un fin de semana por delante de vicio. Jamás olvidaré todas esas horas. Y jamás olvidaré lo que venía después. Frases como: “Papá, ¿Quién era Atila el Huno?”, y su explicación posterior sobre su historia, me enseñaron muchísimo. Era un aprendizaje doble.

¿Qué parte de un videojuego te atrae más cómo creadora? ¿Y cómo jugadora?

Como creadora, podríamos decir que me gusta mucho la investigación. Puedo pasarme horas y horas investigando cositas de aquí y de allá. Me encanta encontrar juegos nuevos, nuevas maneras de jugar, nuevas mecánicas…

Como jugadora, a mi me gusta construir. Siempre me ha gustado. Yo quiero mi ciudad, y mis ovejas, y mis soldados. Quiero un castillo enorme. Y casas. Quiero arqueros, guerreros, tanques. Quiero una ardilla mutante al frente de mi ejército.

¿Qué personas de dentro o fuera de la industria son tus referentes para crear juegos?

Dentro de la Industria, o mejor dicho, dentro de ESNE, tengo preferencia por un profesor. Es mi referente más cercano. Juan Pablo Ordoñez, mi profesor de Diseño, escritor, consultor y diseñador de videojuegos. Le conocí en primero, de casualidad, colándome en una de sus clases, y desde entonces siempre encabeza mi lista de referentes. Fue la primera persona que me hablo del Diseño. Hasta entonces, solo pensaba que los diseñadores hacían “papeleo”. No se me olvidará, que después de conocer su historia, él nos preguntó, “¿Qué queréis hacer el día de mañana?” y yo le dije “Yo quiero ser como tú.

Referente importante fuera de ESNE, Ted Price, presidente y director ejecutivo de Insomniac Games, y presidente de la Academia de Ciencias y Artes Interactivas. Creo que desde que conocí Spyro, me interesé por Insomniac, y, de ser posible, me gustaría montar una desarrolladora como esa.

¿Crees que hay oportunidades laborales para los estudiantes de videojuegos que vayan finalizando su formación en España?

Sí, sí las hay. Cada año más. Aproximadamente cada hora, podemos encontrar por Facebook, Twitter y demás, un montón de ofertas de trabajo. Es un sector en plena expansión, tanto aquí en España como fuera de ella.

¿Crees que el sector del videojuego está empezando a cambiar y dejando de ser tan predominantemente masculino?

Si bien cierto es que hoy en día juegan muchas más mujeres a videojuegos, la masa de chicas se reúne en juegos mas “casuales”. Los chicos y sus gustos siguen predominando en la industria. Se ve muy claro en los “estándar”. Mujeres con armaduras “de tela” que muestren sus “enormes atributos”, hombres súper armados… Todavía falta mucho camino por recorrer. Hoy en día ya somos muchas chicas las que trabajamos en esta industria, y pasito a pasito, vamos cambiando el sector.

¿Qué opinas de salir al extranjero para seguir aprendiendo o adquirir experiencia? ¿Si eliges esta opción crees que volverás después a España?

Personalmente creo que es una experiencia muy enriquecedora, y que todos deberíamos hacerlo. Salir del “nido” y ver lo que hay fuera es una parte importante para desarrollarnos y aprender. En mi caso, sin ninguna duda voy a ir a “explorar” y cumplir algunas misiones en el exterior, aunque, sin duda volveré. Lo importante es aprender y volver para transmitir lo aprendido.

Dices que te gusta dibujar y participar activamente en la parte artística de un proyecto ¿De qué forma lo haces, concept art, trabajo para incluir en el propio juego...?

Cierto es que siempre me ha atraído muchísimo el arte. Y me gusta mucho hacer documentos de diseño “visuales”. Una imagen siempre dice más que mil palabras, y trato de explicarlo así. Garabateo, pinto y escribo en cada servilleta que encuentro. No es raro encontrarse hojas de cuaderno escaneadas, fotos de pizarras o dibujos en cualquiera de mis documentos. A parte de eso, me encanta hacer Concept Art para mis videojuegos, y cualquier tipo de gráfico 2D. No recuerdo ningún juego en el que no haya participado en la parte artística, y por supuesto, pienso seguir haciéndolo.

¿En qué puestos te gustaría trabajar a lo largo de tu trayectoria profesional?

Esto es algo que me he replanteado durante mucho tiempo. Me gustaría ser demasiadas cosas. Tengo curiosidad por todo. Me gustaría trabajar de Diseñadora, eso lo primero. Aunque creo que ramas como el Storyboarding, el Concept Art, o la Producción me atraen mucho. La variedad de puestos de trabajo me vuelve loca. ¡Quiero hacer de todo!

¿El desarrollo de cuál de los proyectos en los que has participado recuerdas con más cariño?

Sin duda el último en el que he trabajado: Evil Cubes. Nervios por las fechas de entrega, bugs por todas partes… Ir contrarreloj… Estrés, lágrimas y noches sin dormir. Fue toda una experiencia. Debíamos de ir a la Madrid Games Week con el juego terminado, a dos semanas, el juego con fallos, la gráfica que no se integraba bien, las skin que no funcionaban, la publicidad sin terminar… No recuerdo tanta tensión en mi vida. Después, todo salió bien, y la verdad es que no se me olvidará. Todo mi grupo se compenetró muchísimo, todos pasamos noches sin dormir, todos estábamos nerviosos… Y al final… Todo salió genial, el juego gustó muchísimo y nos lo pasamos súper bien. Fue algo muy bonito.




Para poder verlo, Evil Cubes está disponible para Android en este enlace: https://play.google.com/store/apps/details?id=com.kinokostudios.com

¿En qué proyecto estás trabajando ahora? ¿Puedes contarnos algo de él?

Ahora mismo estamos trabajando en el Proyecto de Fin de Grado, que sacaremos en cuarto. Todavía estamos diseñando y estableciendo la producción, y ¡Aún no puedo contar nada! No sabemos si será el juego del siglo, pero una cosa tenemos clara… ¡Vamos a darlo todo! Tenemos muchísimas ganas de empezar.

Por otra parte, también estamos haciendo una aplicación gamificada para ESNE llamada ROGUE (ROl Gamification University Esne) . Queremos hacer un “ESNE virtual”. Una aplicación donde tienes tu “avatar”. Ese avatar va realizando “misiones” (Las tareas de clase) y va subiendo niveles, consiguiendo armaduras mejores, armas más potentes… La idea es llevar ese concepto de “mejorar día a día” a una aplicación. Ver tus progresos ya no solo en tus notas, sino en tu personaje. Ver como cada día eres más grande, más fuerte, tienes cosas mejores. Y todo eso se consigue con esfuerzo y dedicación. Creemos que puede motivar muchísimo, y que además es una forma de llevar tu agenda y tus cosas “Al momento”. Con notificaciones automáticas, mensajes directos… Es una herramienta que te acerca mucho más a los profesores.


Gracias por todo, para terminar tienes tu espacio para saludos, dedicatorias y aquello que quieras decir o aconsejar a los lectores. Total libertad para ti.

Bueno, ante todo deciros que el mundo del videojuego no es solo “Jugar”. Que hay que haber jugado mucho, pero que también hay que estudiar. Que hay un mundo de cosas que no sabemos, y que tenemos que aprender. Hay que informarse y estar al día. Si de verdad os gustaría trabajar en esta industria, al igual que en medicina, hay que estudiar SIEMPRE. Hay que estar siempre aprendiendo cosas nuevas, programas nuevos, formas nuevas de hacer las cosas… Es una industria que se basa en el constante cambio. Intenta mejorar poco a poco. No quieras ser Miyamoto el primer año. Haz videojuegos, elige un buen equipo, ve despacio, pero con decisión, y confía en ti mismo. Pide mucho feedback, y aprende de ello. Esas son las claves. No las olvides, no pierdas el foco. El mundo del videojuego es un mundo que sirve para hacer a la gente feliz. Esa es la meta. Hacer feliz a la gente. Hacer que la gente olvide sus problemas, que disfrute con sus avatares y sus innumerables historias.

Dar las gracias, podría tirarme la vida dándolas, pero sobretodo, nombrar a personas que día a día me han apoyado y han confiado en mí, tales como Daniel Parente por su incondicional ayuda en todo; David Alonso por su paciencia con mi grupo; Rubén Burén por todos esos consejos que me hacen ser mejor cada día; Luis Manuel Tolmos por ser ese profesor que cree más en ti que tú mismo; Juan Pablo Ordoñez por sus miles de tutorías eternas; A mi grupo, Kinoko Studios, por darlo todo y estar ahí siempre; y en general a toda la universidad de ESNE, por todas las ayudas que nos han ofrecido, por todas las oportunidades, por todos los buenos momentos…

Gracias a todos mis compañeros, a Jeff, a Salva, a Edu, a Fran, a Daniel, a Camil, a Jorge, a Julio, a Jhon y a todos los demás de ESNE. Gracias por el feedback constante. Gracias por las horas en la biblioteca. Gracias por ofrecer ayuda sin pedir nada a cambio. Gracias por ser fantásticos, y sobre todo, gracias por JUGAR.

La web del grupo de Virginia es: www.kinokostudios.com, donde también tienen un Blog, en el que hacen análisis de algunos juegos, ponen datos interesantes sobre el desarrollo de videojuegos, o simplemente comentan cosas del sector.

También disponen de twitter http://twitter.com/kinokostudios y Facebook http://facebook.com/KinokoStudios

lunes, 23 de febrero de 2015

Webs Recomendadas: models-resource.com

Para aquellos amantes del modelado para videojuegos, y no solo del que se hace en las últimas y super-avanzadas tecnológicamente hablando, producciones actuales, sino también de 3D de que vimos en máquinas pasadas, vengo a recomendar una Web (www.models-resource.com) donde podremos encontrar arte extraído directamente de nuestros títulos favoritos.

Tener a nuestro alcance modelos 3D con sus texturas que podemos descargar, para aprender de ellos, es todo un lujazo. Podremos observar su topología, el número de polys, el estilo del creador, como se colocaron las texturas y se mapeó el objeto, vehículo, personaje o lo que sea. Es por ello que recomiendo a todos los aspirantes a crear arte para juegos 3D que visiten la página en busca de su personaje o juego favorito, aunque por desgracia también hay que decir, que el archivo del que disponen aun es relativamente pequeño en comparación con la cantidad de juegos que a todos nos gustaría ver ahí.

Realmente este tipo de páginas, y también cierto software que fue desarrollado precisamente para extraer gráficos de juegos originales, siempre han causado cierta polémica. El material que podemos encontrarnos tiene unos autores que seguramente en muchos casos no ha dado su consentimiento para que se expongan sus modelos y es posible que algunos usuarios hagan un uso no debido de lo que estén descargando para crear su propio fan-game y tratar de obtener beneficios de él. Por otro lado sin embargo, un archivo como este puede servir a muchos desarrolladores para aprender de la mismísima industria y a fans honestos, para crear fan-games con el objetivo, no de lucrarse de ellos, si no de rendir homenaje a los creadores originales ampliando la vida del producto de cara a la comunidad que se haya creado en torno al mismo. En la propia Web cuentan que algunos desarrolladores han apoyado la iniciativa y colaborado con ella, mientras que otros pidieron la retirada de sus obras. Además, los propios usuarios han hecho crecer esta comunidad aportando creaciones propias inspiradas en sus juegos favoritos.

Sin entrar en sí debería ser legal o no y con nuestras mejores intenciones como aspirantes a desarrolladores necesitados de conocimiento, seguiremos disfrutando de la sabiduría que podemos encontrar en esta página y sus hermanas, ya que también hay otras similares centradas en arte 2D y sonido de videojuegos. (Juntas forman “The VG Resource”)

jueves, 19 de febrero de 2015

One Man Army

Ser “todoterreno” es lo contrario de la especialización y forma parte de una forma de ser que se acerca bastante a lo Independiente y, en parte, viene también de la necesidad. ¿Qué pasa cuando un apasionado de los videojuegos empieza un proyecto con cuatro amigos? Que tiene que dedicarse a muchas y variadas tareas, por lo que debe aprender a defenderse en todas ellas.

Un paso más allá de ser todo terreno es ser “One man army”, es decir, currarse un juego uno mismo sin ayuda, lo cual implica hacer sonido, música, programación, arte… Una locura en la que aun hay desarrolladores que se meten. En este caso es más una elección, ya que siempre se puede buscar algún tipo de apoyo, pero es una consecuencia de lo anterior, el haber aprendido un poco de todo y sentirse capaz de convertir una idea en realidad con habilidades propias.

En mi caso, ha habido varios motivos por los que comencé a aprender de todo. Uno de ellos, es simplemente que soy una persona apasionada y curiosa de este medio (los videojuegos) y no podía quedarme sin saber cómo se hacían cada una de las tareas necesarias para terminar un proyecto. Es una fuerza que me supera y que siempre me ha impedido centrarme a pesar de que alguna vez lo he intentado. El segundo motivo es la necesidad de cubrir varios puestos en un equipo pequeño que ya comenté en el primer párrafo, y hay un último motivo más relacionado con esto, que tiene que ver con la seguridad. Y es que en los grupos de desarrollo que se trabaja por afición y sin dinero, en nuestro tiempo libre, las obligaciones hacen que abandonen miembros del equipo y entren nuevos sin parar, provocando el riesgo de que muchas veces grandes ideas queden sin terminar por falta de personal. Fue después de unos cuantos fracasos de proyectos por abandono general, cuando pensé que en el caso al menos de juegos que iban a nacer de ideas mías, tenía que ser capaz de seguir adelante aunque hubiese otros que tuvieran que dejar su parte del trabajo sin terminar.



Aun así, siempre se ha dicho que no es bueno elegir esta filosofía de trabajo y que lo realmente útil es especializarse, por motivos obvios: Será mejor pixel artist (por ejemplo), una persona que se dedica 8 horas al día solo a practicar y mejorar eso, que yo, que pueda dedicar una a la semana por que el resto lo dedique a programar, modelar en 3D, etc. Sin embargo después de mis experiencias prefiero un término medio, porque por muy bueno que sea uno en una cosa, dependerá de los demás para sacar rendimiento a su trabajo, y es posible que no siempre haya un hueco para él/ella, especialmente si está excesivamente especializado y el proyecto requiere otro tipo de habilidades, que aunque se parezcan, no son su fuerte. (Por ejemplo ser el mejor modelador 3D y que solo se necesite arte 2D).

Con este post no quiero decir que no me guste trabajar en equipo. De hecho es mi opción preferida y la que creo óptima para acabar juegos. Pero si alguno o alguna se siente identificado con lo que estoy contando ya verá como pasa por etapas o proyectos en los que sentirá que tiene la energía y habilidades para terminarlos por completo y otros en los que prefiera un poco de ayuda, compañía, e intercambio de información para seguir mejorando. De hecho no recomendaría a nadie que se quedara sin saber al menos una mínima parte de lo que hace el resto de miembros de su equipo, para ser capaz de entenderlos y ponerse en su piel al evaluar la dificultad de su trabajo. Pero tampoco aconsejaría a un desarrollador que hiciera todos los proyectos de su vida en solitario, porque, entre otras cosas, estaría perdiendo la oportunidad de aprender de los demás (y de enseñar a los demás).

lunes, 16 de febrero de 2015

Juegos que me influyeron como desarrollador: Portal

Alguno/a estará pensando que si he descubierto este juego ahora. Evidentemente no, pero en esta sección siempre suelo hablar de juegos a los que jugué en el pasado, reflexionando sobre ese momento de inspiración o influencia que tuve el día que los jugué. En este caso, recuerdo que este título amado por muchos, fue como recibir un “bofetón de influencia” de los que cambian completamente tu forma de pensar.

Para aquellos despistadillos que no han jugado a ese estupendo título, Portal es un juego de puzles en primera persona, cuya mecánica principal se basa en la apertura de portales con los que trasladarnos de un punto a otro de la habitación. Estos portales, se controlan mediante una pistola (Aperture Science Handheld Portal Device) que dispara un portal de entrada y otro de salida, los cuales además nos permiten jugar con las físicas. Así por ejemplo, si nos lanzamos desde muy alto hacia uno de estos agujeros dimensionales, teniendo la salida colocada en el suelo, gracias a la inercia de estar cayendo, saldremos hacia arriba disparados desde el otro portal.


Además de su excelente Gameplay, la historia, que gira en torno a una IA (GLaDOS), es impresionante y está contada de una manera muy inmersiva, de manera que nos hace vivirla a cada segundo del juego, con la sensación de que nos estamos moviendo dentro de algún experimento de laboratorio y estamos siendo observados en todas las decisiones que tomamos.

Con el tiempo apareció una secuela que nos traería nuevos personajes y mecánicas diferentes, basadas esta vez en unos “geles” de colores que nos proporcionan propiedades físicas como resbalar por el suelo a toda velocidad o a rebotar con paredes, techos o suelos.



¿Pero que hace de Portal un grandísimo ejemplo a seguir por un desarrollador?

Especialmente en el caso de la primera entrega, se trata de un juego que puede clasificarse como AAA realizado con recursos que podría asumir un equipo de desarrollo pequeño. Los enemigos son escasos y se repiten, teniendo una Inteligencia Artificial muy limitada; las texturas, el ambiente en los escenarios, los ítems y el arma principal, todo es muy similar a lo largo del juego, pero nos convence y enamora por que forma parte de su increíble historia. Lo mismo ocurre con la mecánica de creación de portales que nos da el único “arma”, solo hay una forma de usarla (disparo portal de entrada y disparo portal de salida), pero tiene un enorme número de casos de uso que nos da mil posibilidades a la hora de resolver cada puzle que se nos plantea.


Respecto a los “ítems” puede considerarse como tal la aparición del “Companion Cube”, un sencillo cubo con un dibujo de corazón en él, que incluso nos plantea algún que otro dilema psicológico. ¡Es brillante como han conseguido que un cubo te haga sentir cosas!


Los enemigos, por otro lado, son unas torretas mecánicas que simplemente están paradas esperando que aparezcamos y que nos disparan en cuanto entramos en su campo de visión, y a las que debemos derrotar con un poco de ingenio en el uso de los portales. (Del enemigo final no hablo por no destripar nada, pero es de los mejores personajes de la historia del videojuego). 

Es por todo lo que comento aquí, por lo que digo que Portal supuso un “bofetón de inspiración”, porque fue como si me golpearan y me despertaran de una forma de pensar errónea: ¿Puede un equipo pequeño hacer uno de los mejores juegos de la historia de los videojuegos? ¿Puede ese equipo pequeño hacer un juego que compita con los grandes de la industria? Antes de Portal siempre habría contestado que no, pero después, digo que puede, si se sirve de la creatividad para convertir sus debilidades en ventajas. Creatividad para diseñar unas mecánicas interesantes que permitan al jugador descubrir muchas formas de usarlas, adaptadas a una buena historia bien contada, y acompañar todo de un trabajo brillante y apasionado por parte de sus creadores. (Aunque eso sí, sigue sin ser algo sencillo o alcance de cualquiera, no nos vayamos a emocionar demasiado :P)

Para saber un poco mas de Portal recomiendo jugarlo y después, ya sin peligro de que nos cuenten nada antes de descubrirlo por nosotros mismos, ver el documental del que ya hablé en un post anterior. (Documental que se titula Portal: Más allá de las paredes)

jueves, 12 de febrero de 2015

Proyectos y tiempos límite

A pesar de dedicarme al Blog y a otras ideas relacionadas en las que estoy trabajando que revelaré llegado su momento (y de mis obligaciones como ciudadano de buscar que hacer con mi vida en esta interminable crisis), aun saco algo de tiempo para invertirlo en proyectos de videojuegos, y para este año quiero hacer más que el año pasado. (Aunque siempre digo lo mismo).

Recientemente leí por ahí en alguna parte (lo siento pero no soy bueno guardando enlaces de internet y siempre me olvido de donde leí algo), un postmortem de alguien que dijo que se había propuesto el reto de hacer un juego en un mes. Evidentemente no es algo imposible, ni tan siquiera difícil si hay gente en una Game Jam que los hace en un fin de semana. Pero no parece mala idea. ¿Por qué no proponerse un reto para acabar un producto terminado y listo para publicar, aunque sea un desarrollo corto y sencillo cada X tiempo? Esto puede servir para agudizar el ingenio como diseñador de juegos hacia ideas simples pero efectivas y además me sirve para otros asuntos:

En mis recientes entrevistas de la sección futuros creadores (Para la que sigo buscando nuevos candidatos) he visto como una de las cosas que más se valora de estudiar desarrollo de videojuegos en un centro de formación es el hecho de que hay que trabajar en tareas con fechas de entrega, como ocurrirá después en el trabajo “real”. Se suele decir que en el mundillo autodidacta no se tiene eso y se adquieren malos hábitos, lo cual puede ser bastante cierto en la mayoría de los casos. Pero ¿Y no se puede entrenar esto también desde el autoestudio? ¡Pues para esto sirve ponerse estos retos!

Respecto al desarrollo, tener una fecha de finalización puede ayudarnos a trabajar en serio en nuestro proyecto (pero hay que ser realistas con el tamaño de lo que vayamos a hacer), pero ¿y en otras cosas? Es habitual por ejemplo, en el trabajo de profesionales del modelado 3D, que las personas más experimentadas sepan calcular con más o menos precisión el tiempo que les va a llevar realizar las tareas que se les encarguen. Esta habilidad, que se adquiere con la práctica, ayuda a la persona que dirige el equipo a planificar todo el proceso a seguir hasta terminar todo a tiempo. Bien pues si no trabajamos en un estudio profesional también podemos aplicar esto al mundillo autodidacta y cronometrar nuestras tareas: Modelado de tal objeto -> 2 horas, mapeado -> 1 hora, texturizado… Con la experiencia veremos cómo, no solo aprendemos a predecir aproximadamente lo que tardaremos en cumplir con nuestro trabajo, si no que reduciremos el tiempo empleado en hacerlo sin darnos cuenta y terminaremos muchas más cosas. Pues creo que voy a ver si yo me aplico esta idea y tal…


Cumpleaños, Bautizos, cenas familiares y demás eventos sociales y obligaciones pueden ser respetados en esta idea, aunque es bueno ponerse unos horarios y cumplirlos, de manera que si se pierde una hora un día puede recuperarse en otro día libre.

En algún futuro post del Blog ya contaré los planes de mis dos nuevos proyectos, que tal me están saliendo y los tiempos que me he propuesto cuando inicie esta aventurilla en serio. De momento estamos en “preproducción”.

lunes, 9 de febrero de 2015

9 Edición de los premios 20Blogs

Otro año más me he decidido a inscribir mi humilde Blog en este concurso del periódico 20 Minutos, con la novedad de que, como ya gané el año pasado en la categoría de Videojuegos, esta vez me toca elegir otra categoría (por qué no se puede participar en la que ganaste una vez), así que he optado por competir con otros Blogs Personales, ya que este también ha sido desde hace ya casi 5 años mi Bitácora personal en la que poder contar mi historia de (de momento) eterno aspirante a desarrollador.

La participación de años anteriores fue bastante positiva, especialmente con esa pequeña victoria de la última edición que disparó las visitas al Blog e hizo que me conociera más gente interesada en aprender más sobre este mundillo que tanto me apasiona. Con el tiempo, eso sí, estas visitas volvieron más o menos a la normalidad, quitándome la ilusión de obtener unos ingresos mínimos desde esta página para financiar mis proyectos. ¡Pero lo seguiremos intentado!

Animo por tanto a otros Blogueros y Blogueras a presentarse a este tipo de concursos para dar mayor difusión a sus intereses. Con suerte pueden ganar también algo de pasta si su página resulta elegida como la mejor de todas las categorías (pagan 5000 Euros).

Las votaciones para elegir a los mejores Blogs de cada categoría son, como siempre, entre los propios participantes en una primera fase, por lo que si estáis interesados en votar, también tendréis que tener un Blog inscrito y mucha suerte para que os encuentren entre los más de 7200 participantes de esta edición. (El mío está en este enlace: http://lablogoteca.20minutos.es/quiero-ser-creador-de-videojuegos-28145/0/)

Con los ánimos recibidos a través de votos y comentarios vamos a ver si saco fuerza para tener nuevos post de una forma regular, sin dejar de lado los proyectos que me traigo entre manos como siempre, tratando de ser útil a quien pueda aprender de mi y aprendiendo de los demás y de mis propios errores y experiencias. Y es que como se suele decir, enseñar es otra forma de aprender, y luego está también eso de práctica, práctica y práctica. 

martes, 3 de febrero de 2015

Aprendiendo videojuegos con la historia de las consolas: Atari (Parte IV)

En la anterior parte de este tutorial nos quedamos pendientes de que nuestro portero de madera colisionase con la pelota, así que ha llegado el momento de configurarlo para que esto sea posible y, como ya aprendimos anteriormente, esto será posible gracias a un Box Collider 2D y un RigidBody 2D. Vamos a añadirlos a nuestro muñeco de madera. (Si no recordáis como se hace volved al capítulo anterior) y a configurarlos con los valores que vemos en la imagen. Con esto tendremos un portero fuerte que no será desplazado dentro de la portería cuando la pelota le golpee.


En este caso vamos a tener (cuando lo programemos) un portero que estará en movimiento, por lo que marcaremos la casilla de verificación is Kinematic, de nuestro RigidBody 2D, ayudando así a Unity a realizar mejor los cálculos físicos necesarios y consiguiendo que solo exista colisión con otros objetos en desplazamiento, como la pelota, y que no se pueda chocar con el poste de la portería que tiene un Collider estático (Sin RigidBody). Si probamos a pulsar play y durante el juego, lanzar la pelota contra nuestro muñequito de madera veremos cómo sale rebotada, por lo que con esto ya podemos avanzar al siguiente paso.

Queremos hacer que nuestro portero de prácticas se mueva constantemente para tratar de dificultarnos un poco el meter el balón dentro de la portería. Para ello crearemos un nuevo Script en C# al que vamos a llamar GoalKeeperControl, lo arrastraremos sobre nuestro muñeco de madera, y después lo editaremos escribiendo el siguiente código:

using UnityEngine;
using System.Collections;

public class GoalKeeperControl : MonoBehaviour 
{
 public float speed;       // velocidad de movimiento
 public float limits;      // Limites del movimiento

 private Transform thisTransform;   // Referencia al transform del portero
 private int direction;        // Direccion de movimiento
 private float timePassed;     // Tiempo pasado desde el ultimo cambio de direccion
 private float changeTime;     // Tiempo para cambiar de direccion

 // Use this for initialization
 void Start () 
 {
  thisTransform = transform;
  ChangeDirection();   // damos una direccion inicial aleatoria de movimiento
 }
 
 // Update is called once per frame
 void Update () 
 {
  
  if(Time.timeSinceLevelLoad < timePassed + changeTime){   
   MoveWoodenKeeper(); // mueve el portero
  } else {
   ChangeDirection();  // mover hacia un sitio aleatorio ()
  }
 }

 /*-----------------------------------------------------------------------
  *  - ChangeDirection() -
  * 
  *  Cambia la direccion de movimiento del portero
  * ----------------------------------------------------------------------*/
 
 void ChangeDirection()
 {
  timePassed = Time.timeSinceLevelLoad;   // tiempo de juego
  direction = Random.Range(1,3);          // Numero entre 1 y 2
  changeTime = Random.Range (0.3f,0.7f);  // Rango de tiempo aleatorio para el cambio
  MoveWoodenKeeper();                     // controla el movimiento
 }

 /*-----------------------------------------------------------------------
  *  - MoveWoodenKeeper() -
  * 
  *  Mueve el portero en una direccion  despendiendo de la variable direction
  * ----------------------------------------------------------------------*/
 
 void MoveWoodenKeeper()
 {
  switch (direction)
  {
  case 1: // moving right
   
   if (thisTransform.position.x > limits)
   {
    ChangeDirection(); // si se mueve a la derecha debe ir a la izquierda
   }
   else
   {
    thisTransform.Translate(thisTransform.right * speed * Time.deltaTime);
   }
   break;
  case 2: // moving left
   if (thisTransform.position.x < -limits)
   {
    ChangeDirection(); // si se mueve a la izquierda debe ir a la derecha
   }
   else
   {
    thisTransform.Translate(thisTransform.right * -speed * Time.deltaTime);
   }
   break;
  default:
   break;
  }
 }
}

Como se puede leer en el código tenemos dos variables públicas de tipo float que posteriormente ajustaremos desde el Inspector en Unity y que se llaman speed y limits. Estas se encargarán de definir la velocidad a la que se moverá nuestro muñeco de prácticas y que limites de movimiento tiene, que no van a ser más que una distancia desde el centro donde se sitúa inicialmente hasta los palos de la portería.

Después, tenemos varias variables privadas. Por ejemplo thisTransform lo hemos usado muchas otras veces y en esta ocasión tiene el mismo objetivo, servir de referencia al transform del objeto que contiene este script (el portero) para poder usarla y acceder a dicho transform consumiendo menos recursos por tener que buscarlo cada vez. Por otro lado, la variable entera direction, se encargará de decidir si el muñeco se mueve hacia la derecha o hacia la izquierda de forma aleatoria. Nos encontraremos también timePassed, que almacenará el tiempo que llevamos de juego en cada momento que el movimiento del portero cambia de dirección y changeTime, encargada esta última de recoger un numero de segundos al azar para hacer el próximo cambio en el sentido del movimiento y que así no cambie de forma constante y repetitiva.

En Update() vamos a mover nuestro muñeco mediante MoveWoodenKeeper() si el tiempo desde que el nivel se inició (Time.timeSinceLevelLoad es menor que la suma de timePassed + changeTime. Es decir, si no ha pasado bastante tiempo desde que el portero hizo un cambio de dirección sumado al tiempo en el que tiene que cambiar de nuevo. En caso contrario, cambiaremos de dirección con ChangeDirection(), iniciando de nuevo el proceso.

La función ChangeDirection() se va a encargar de inicializar timePassed igualándolo al tiempo desde que el nivel se inició (Time.timeSinceLevelLoad) cada vez que se ejecute esta función. Además, recogerá un valor aleatorio entre 1 y 2 (uno derecha y dos izquierda) y lo almacenará en direction. Para hacer esto, usamos Random.Range(), en este caso entre 1 y 3 por que al ser enteros busca la aleatoriedad entre el número mínimo y el máximo-1 (es decir no incluye el 3, solo elige entre 1 y 2). Con esta misma operación obtenemos también un número entre 0.3 y 0.7 (a los que añadimos una f para indicar que son float, es decir, decimales) para decidir el tiempo en segundos que tardará en volver a cambiar la dirección del movimiento (volviendo a llamarse a esta función). Por último llamamos a MoveWoodeKeeper() para que el muñeco ejecute el movimiento en la nueva dirección elegida.

MoveWoodenKeeper() es una función encargada de mover el portero dependiendo hacia donde le indique la variable direction, que como ya dijimos cambiará cada changeTime segundos. Usamos pues, un condicional de tipo switch para hacer que se mueva a la derecha si direction vale 1 o a la izquierda si vale 2. Sin embargo, también tenemos que tener en cuenta si la posición x del portero de madera ha alcanzado su límite por la derecha (limits) o por la izquierda (-limits) recurriendo a condicionales if que comprueben si la posición del transform es mayor que limits o menor que -limits. Por otro lado el movimiento en sí, lo conseguiremos con thisTransform.Translate(), una función que varía la posición de un objeto cuando le indiquemos mediante sus parámetros. En este caso para ir a la derecha usamos thisTransform.right * speed * Time.deltaTime, indicando así que se mueva a la derecha a velocidad speed y teniendo en cuenta Time.deltaTime para que la velocidad de movimiento no dependa de la del dispositivo en el que se dibuje. (Esto ya se explicó un poco en anteriores capítulos).

Por cierto, en el inspector de Unity he configurado speed a 1.5 y limits a 0.5

Si observamos que el portero se dibuja por detrás de la portería podemos corregir su eje Z del transform.position desde el inspector. Yo finalmente lo he tenido que poner con un valor de -0.6.

Como vemos, el movimiento del muñeco no supone un reto para el jugador, que puede practicar el tiro a portería libremente, pero sí que molesta y le obliga a estar atento y hacer cálculos, por lo que creo que es el entrenamiento perfecto de cara al lanzamiento real en el modo de juego normal. Podemos pasar entonces a lo siguiente: Reinicio del nivel.

Resulta un poco molesto tener que parar y reiniciar nuestro juego después de cada tiro, así que vamos a crear una solución temporal para que podamos tirar penaltis infinitos hasta que decidamos detener la partida. Para conseguir esto, recurriremos a Application.LoadLevel(“NombreDeEscena”) para cargar la misma escena en la que estamos actualmente. Para esto tendremos que pensar en un evento para lanzar la acción de reiniciar el nivel, así que pudiendo elegir factores como el fin del movimiento de la pelota, pulsar una tecla u otros muchos, nos vamos a decidir por el factor tiempo, es decir, esperaremos un tiempo desde la pulsación de la tecla de disparo, o si lo preferís, desde el lanzamiento a portería, dejaremos que el usuario vea un rato como rebota la pelota o se pierde por el fondo, y restauraremos la escena actual con el ya citado Application.LoadLevel(). Descrita la explicación, veamos el código que introduciremos en el Script PlayerControl.

Primero necesitamos incluir dos variables privadas y una pública. En este caso timeAfterShoot será pública para poder decidir desde el Inspector de Unity el tiempo que queremos que pase para reiniciar el nivel después de tirar a puerta (yo he elegido 3 segundos). Las privadas serán timeSinceShoot, para guardar el tiempo que pasa desde que se tira a puerta, y un booleano llamado shooted, que nos avisará de que ya se ha efectuado el lanzamiento. Además timeSinceShoot será inicializado a 0 y shooted a false en la función Start(), ya que al inicio de juego estamos seguros de que no se ha hecho ningún disparo a puerta y necesitamos un punto de partida.

private float timeSinceShoot; // Tiempo desde que se tira a puerta
private bool shooted;
public float timeAfterShoot; // Timepo necesario para reiniciar

// Use this for initialization
void Start () 
{
        timeSinceShoot = 0;
 shooted = false;
...
}

Para evitar que el nivel se reinicie constantemente usaremos en Update() el booleano shooted, que comprobará el tiempo desde que se tiró a portería únicamente después de que se haya efectuado el tiro y lo hará mediante la función CheckLevelRestart()

if(shooted) // El jugador tira a puerta, contemos el tiempo hasta reiniciar
 CheckLevelRestart();

Pero antes, para saber cuándo se tira a puerta e iniciar el tiempo desde allí hasta el reinicio del nivel, nos vamos a la función Shoot() y añadimos las siguientes líneas al final:

timeSinceShoot = Time.timeSinceLevelLoad;
shooted = true;

Indicamos con timeSinceShoot, que tome como referencia el tiempo desde que empezó el nivel para ir contando segundos desde allí y con shooted = true, que acabamos de efectuar un tiro a portería.

Finalmente la función CheckLevelRestart() comprobará si el tiempo pasado desde el inicio del nivel es mayor que el tiempo pasado desde el inicio del nivel al tiro a puerta (timeSinceShoot) más timeSinceShoot, que es el tiempo que debe pasar hasta el reinicio del nivel después del ya mencionado disparo a puerta. (Cargamos el nivel con Application.LoadLevel(“GameScene”);)

/*-----------------------------------------------------------------------
 *  - CheckLevelRestart() -
 * 
 * Funcion que comprueba si ha pasado tiempo para reiniciar el nivel
 * --------------------------------------------------------------------*/

void CheckLevelRestart()
{
 if(Time.timeSinceLevelLoad > timeSinceShoot + timeAfterShoot)
 {
  Application.LoadLevel("GameScene");
 }
}

Si ejecutáramos ahora el juego cargaría el nivel porque es el único que tenemos, pero para hacer bien las cosas necesitamos un poco de trabajo fuera de código con Unity. Iremos a file/Build Settings y donde pone Scenes in Build, tendremos que cargar nuestra escena actual GameScene arrastrándola desde la ventana Project.


Como vemos, el juego sigue un poco después del tiro y no hay una pausa, por lo que el portero sigue moviéndose y saca el balón de la portería. Solucionaremos esto creando un nuevo script muy sencillo llamado GameManager que no vamos a asociar a ningún objeto. En este script añadiremos una variable de tipo Static para manejar estados del juego que permanecerá en la memoria durante toda la ejecución y conservará su valor. ¿Y es este el mejor método para hacer esto? No, pero es el más sencillo y rápido para nuestro pequeño proyecto, aunque los expertos programadores pueden recurrir a otro modo de hacer las cosas. Veamos el contenido de GameManager.

using UnityEngine;
using System.Collections;

public class GameManager : MonoBehaviour 
{

 public enum States { inGame, Waiting}; 
 // En juego, En espera
 public static States gameState; // Estado del juego

}

Hemos utilizado el tipo enum de C# para aclarar los estados de juego. Así decidimos que haya dos estados: “en juego” y “esperando” (inGame y Waiting), usando estos para bloquear los controles y el movimiento del portero cuando estemos en espera y para permitir continuar la partida cuando estemos en juego.

¿Cuándo vamos a poner el juego en espera? Pues en mi caso he decidido hacerlo cuando la pelota esté en una posición Y determinada. Con esto, cuando haya lanzado el jugador a puerta y el balón este subiendo hacia meta, se bloqueará en cierto momento el juego impidiendo que el muñeco de madera se siga moviendo y que el usuario continúe teniendo el control del personaje. Para hacer esto vamos a necesitar otro Script que llamaremos BallScript y que enlazaremos con la pelota (ya veremos que en un futuro próximo nos va a venir muy bien). En este script escribiremos el siguiente código.

using UnityEngine;
using System.Collections;

public class BallScript : MonoBehaviour 
{

 Transform thisTransform;

 // Use this for initialization
 void Start () 
 {
  thisTransform = transform;
 }
 
 // Update is called once per frame
 void Update () 
 {
  if(thisTransform.position.y > 0.2f)
  {
   GameManager.gameState = GameManager.States.Waiting;
  }
 }
} 

Por supuesto, para contrarrestar la activación del juego en espera, vamos a poner el estado de en juego nada más comience el juego, para ello dentro del script PlayerControl, dentro y al final de la función Start(), añadiremos la siguiente línea:

GameManager.gameState = GameManager.States.inGame;

Con esto cada vez que se reinicie el nivel y se invoque a esta función, el estado de juego se colocara como inGame.


Como último paso para bloquear el juego cuando el estado sea Waiting tendremos que colocar condicionales en PlayerControl y GoalKeeperControl antes de ejecutar las acciones encargadas del movimiento y el control. Así, solo se ejecutará esa parte del código cuando el estado de juego sea inGame, parándose durante el resto de la ejecución. (Pongo un ejemplo pero esto se pondría tanto en Update y FixedUpdate de PlayerControl, como en Update de GoalKeeperControl, dejando BallScript sin código de este tipo por que queremos ver a la bola rebotar)

if(GameManager.gameState == GameManager.States.inGame)
{
        horAxis = Input.GetAxis...
} 

Lo siguiente para acabar el capítulo de hoy va a ser comprobar si hemos marcado gol. Pero para conseguir esto tendremos que añadir un Collider (en este caso a un objeto vacío porque queremos que sea invisible) que más que Collider tal como hemos visto hasta ahora, hará de Trigger o interruptor, para chivarnos cuando el balón ha entrado en una zona concreta de juego. Este tipo de objetos no visibles se usan en juegos para activar puertas, interruptores lanzar eventos de animación y mil cosas más.

Creamos por tanto un objeto vacio y le añadimos un Box Collider 2D de una medida x = 1, y = 0.17. Con estas dimensiones podemos centrar nuestro Trigger dentro de la portería, cuando ya se ha cruzado la línea blanca de gol y sin acercarnos mucho a los postes, para evitar un falso tanto si los cálculos físicos de Unity son poco precisos y señalan gol cuando la pelota ha rebotado en uno de los postes. Por cierto, llamaremos a este objeto GoalZone y es importante marcar la casilla isTrigger del Collider, para hacer que Unity deje atravesarlo con la pelota y lo utilice como Trigger.




Una vez lo tenemos listo, en BallScript tendremos que introducir el código que detecte que la pelota está entrando en esta zona de gol e indicar de alguna forma (temporal por ahora) al jugador que ha marcado, pero para poder lograrlo también tenemos que aprender algunos conocimientos nuevos sobre nuestro motor de juegos favorito, las etiquetas.

Las Etiquetas nos permiten marcar varios objetos bajo un nombre común y realizar acciones con ellos, como comprobar colisiones. Gracias a las etiquetas podemos elegir que un personaje realice una acción o emita un sonido cuando choca con un tipo concreto de objeto y otras acciones distintas si choca con otro objeto distinto. (Por ejemplo que la lava nos quite energía y por la hierba podamos caminar libremente).

Para añadir una etiqueta seleccionaremos nuestro objeto GoalZone y desplegaremos en el Inspector, al lado de Tag, hasta seleccionar Add Tag… Después, en la casilla Element 0, introduciremos el nombre de nuestra etiqueta (en este caso también GoalZone) y pulsaremos Enter. Ahora podemos ir de nuevo al inspector, seleccionando el objeto GoalZone y elegir la etiqueta que acabamos de añadir volviendo a desplegar al lado de Tag y escogiendo esa nueva etiqueta que habrá aparecido.


Como ya tenemos una etiqueta para saber cuando el balón entre en una zona de gol, y así nos avise, vamos a editar el script BallScript y a añadir el siguiente código (una función aparte al final pero dentro de la clase.

void OnTriggerEnter2D(Collider2D col)
{
 if(col.tag == "GoalZone")
 {
  Debug.Log ("Goal!!");
 }
}

Básicamente OnTriggerEnter2D() es una función predefinida de Unity que responde cuando un objeto entra en la zona del Trigger que hicimos hace un momento. Recibe como parámetro un Collider2D que hemos llamado col y con el podemos comprobar si el objeto que ha “colisionado” cuando la bola entra en la zona tiene la etiqueta “GoalZone”. En caso de que la bola esté dentro de GoalZone significará que el jugador ha marcado, por lo que usamos Debug.Log para escribir en la consola de Unity el texto correspondiente (Que se pone entre comillas).

Con esto, veremos como cuando el balón entre en la portería aparecerá en la consola de Unity el mensaje “Goal!!” indicando que el jugador ha anotado.

En el futuro ya tendremos tiempo de hacer esto de forma mucho más bonita, pero de momento lo vamos a dejar así. :)