Esta serie de artículos están dedicados al desarrollo de videojuegos además de entrevistas con diferentes profesionales de la industria del videojuego.
El motor gráfico Unreal Engine lleva varios años siendo una de las referencias para todos los desarrolladores y jugadores con juegos como Gears of Wars, Shadow Complex, Fornite y muchos otros entre su catálogo.
Desde que volví de Londres, se suponía que iba a volver a reactivar la sección Desarróllame, pero en dos meses sólo he escrito un artículo. Como explico en mi recién migrado blog (y de paso me doy un poco de publicidad xDDD), tampoco he estado parado. Aún así pido disculpas, y aprovecho para hablaros de un tema del que escribí hace casi un añó pero que aún no he subido aquí, y que creo que es muy interesante: cómo ejercitar nuestra creatividad.
Ahí va. Agarraos que vienen curvas :P.
Antes que nada, me gustaría dedicar el artículo al discurso inspirador de Pablo Medina, mi profesor de guión en la Universidad Europea de Madrid, al gran creativo e incombustible Valentín Fernández-Tubau, también profesor de guión durante el III Encierro en las Cumbres, y a la vida misma, mi maestra suprema, y que me ha mostrado cosas que en ocasiones no he visto claramente hasta que Pablo o Valentín no me lo pusieron delante de los ojos peor que, aún así, siempre estuvieron ahí. Así que no voy a dejar de nombrarles a lo largo de todo el artículo, porque me sabe mal que gran parte de lo que diga aquí no sea más que las conclusiones a las que he llegado en ocasiones gracias a ellos.
Lo primero que voy a hacer es contaros qué es el Encierro en las Cumbres. Pues, como su nombre indica, es una concentración de guionistas en las Hoces del Duratón, dirigida por Valentín Fernández-Tubau y organizada por su pareja, Anuska Gil. A lo largo de la semana que duró el evento, bajo la batuta de nuestro «profe», combinamos actividades en contacto con la naturaleza (caminatas, bicicleta, piraguismo, etc.) con el aprendizaje de una serie de pautas creativas para ayudarnos a dar forma a nuestro guión. En mi caso, y tras muchas deliberaciones entre todas mis ideas, finalmente elegí el guión de un corto sencillo: «12 frases de amor«, que terminaré en cuanto esté un poco libre de mis obligaciones «videojueguiles». Pero ese será otro tema…
Así, nos juntamos más de una decena de creativos aprendiendo juntos, trabajando juntos y respirando juntos el aire del Duratón. Una experiencia maravillosa, con una gente fantástica, unos organizadores increíbles y un lugar mágico es todo lo que se necesita para que la creatividad eche horas extras.
Todo lo que voy a hablar de la creatividad a partir de ahora, va a ser una mezcla de lo que aprendí con Pablo Medina, con Valentín Fernández-Tubau y algo de mi propia cosecha.
Antes de que os creáis todo lo que os diga, aprovecho para preveniros de esos autores (en muchos casos no dudo que de gran prestigio), que predican sus métodos y estructuras como únicas e infalibes. Probablemente a ellos les funcionen, e incluso a vosotros en bastantes casos (o quizás en todos), pero no exisite ni uno sólo que le funcione siempre y a todo el mundo. Ayudaros de sus sugerencias y consejos, pero no os encorsetéis en ellos. En estructura de guión no he querido meterme en este artículo porque también tienen su miga, pero ya haré un artículo sobre ello.
¡Muy buenas a todos! Ya he vuelto de Londres (estuve fuera desde octubre), y vuelvo a la carga con los tutoriales sobre diseño y programación de videojuegos. Para retomarlo, empiezo con algo suave, y creo que bastante interesante que escribí el jueves tras la charla de Daniel González en la Universidad Politécnica de Madrid con motivo de la II Edición del Game Spirit.
Si hay una materia que, en mi humilde opinión, se quedó algo flojita en el Máster en Diseño y Programación de Videojuegos de la Universidad Europea de Madrid que cursé el año pasado, desde luego ha sido Diseño de Niveles. Y no es precisamente un tema baladí, pues va a ser sobre los niveles donde se desarrollarán nuestros videojuegos. Para que veamos lo importante que puede llegar a ser un buen diseño de niveles, voy a poner un par de vídeos que hablan por sí mismos:
Por eso no he querido perderme la conferencia que ha ofrecido hoy en la Universidad Politécnica de Madrid Daniel González, autor del libro Diseño de Videojuegos de la editorial Ra-Ma, profesor en Gametopía, creador de la revista digital Vive la Live y autor de Advertainmen, un blog con información jugosa sobre desarrollo de videojuegos.
Así que con su libro en una mano, y el bloc donde he tomado apuntes esta tarde en la otra, me dispongo a dar una serie de pautas y recomendaciones sobre diseño de niveles.
Pero me va a ser imposible porque no me quedan manos para escribir, así que antes voy a dejarlos sobre el escritorio.
Ya está.
Bueno, humor absurdo aparte, lo primero que hay que saber es quién diseña los niveles. Obviando el tema de que estamos en el país en el que contratan a una persona para hacer lo que deberían hacer dos o tres (para que luego digan que no somos productivos), la tarea del diseño de niveles recae sobre dos profesionales muy distintos: el guionista y el mapeador. Aunque lo más probable es que en un estudio pequeño el game designer, el guionista y el mapeador sean la misma persona, es importante saber distinguir el rol que vamos a tener cada momento, aunque sólo sea para estructurar nuestras tareas.
¿Qué hace el guionista?
El guionista debe describir cómo debe ser el escenario que debe crear el mapeador, pero, como siempre, tiene algunos límites no muy bien definidos para no hacer lo que no le corresponde. A groso modo, sería:
¿Qué hace el mapeador?
Pues el mapeador hace, precisamente, todo lo demás. Que no es poco.
El trabajo del diseño de niveles es especialmente importante, ya que nos va a definir una serie de elementos clave que marcarán el trabajo del resto del equipo:
Recordemos que el diseño de niveles forma parte de la acción, del guión, y de la jugabilidad, pero sobre todo de la DIVERSIÓN. Si nuestro nivel no es divertido, da igual lo bien marcados que estén los ritmos, lo perfecto que encaje en nuestra historia, o lo distintiva que sea su jugabilidad.
Un nivel siempre debe ser divertido.
Espero que estas pautas básicas os hayan servido tanto a vosotros como a mí.
Tras el éxito de la primera edición de GameSpirit en Junio de 2011, Gametopia junto con la Universidad Politécnica de Madrid, vuelven a organizar otro ciclo de seminarios gratuitos de videojuegos en Febrero.
Una de las principales novedades, es que la UPM va a ofrecer créditos de libre elección a los alumnos universitarios que asistan a todos los seminarios y que realicen un trabajo.
Los Seminarios se impartirán todos los jueves de Febrero a las 19:00h en la Sala de Grados de la UPM de Madrid. A los seminarios puede asistir cualquier persona y no hace falta inscripción previa.
El primer seminario será Diseño de Niveles de un videojuego, impartido por Daniel González, donde se mostrará todo el proceso creativo para crear un nivel jugable, incluyendo la creación del escenario y las mecánicas de juego.
Para más información sobre el seminario y cómo llegar en www.gametopia.es/
Hace más de dos semanas, antes de largarme al III Encierro en las Cumbres (una concentración de guionistas en las Hoces del Duratón dirigida por Valentín Fernández-Tubau) y las posteriores fiestas de mi pueblo, escribí un artículo que no me dio tiempo a colgar aquí.
Después también he tenido algo de lío y no he podido hacerlo hasta hoy. Espero que la espera haya merecido la pena:
Muchos de vosotros os preguntaréis para qué os sirve un cuadro de selección si los juegos de estrategia os importan un pimiento. Pues antes de que dejéis de leer os aviso de que, aunque vuestro juego no incluya este elemento, a lo largo del tutorial veremos cosas tan básicas e imprescindibles como tirar «rayos» desde la cámara para ver qué tenemos delante de nuestro puntero (la base de cualquier shooter) o cómo pasar coordenadas de mundo a coordenadas de pantalla.Así, en este tutorial vamos a aprender a:
– Enfrentarnos a un proyecto real, utilizando las distintas herramientas que nos ofrece Unity 3D.
– Construir un código ordenado que responda a nuestros requerimientos.
– Crear GameObjects desde el código a partir de Prefabs.
– Utilizar los valiosos «Raycast» para detectar elementos de nuestra escena presentes en un determinado vector.
– Pasar coordenadas de mundo a coordenadas de pantalla.
– ¡Ah, sí! Y a crear un cuadro de selección :P.
Aunque voy a reutilizar algo del código de Bellum, para no liaros he decidido crear un nuevo proyecto.
En un alarde de originalidad, lo he llamado «Tutorial_SelectionBox».
¡Volví de vacaciones!
Y lo hago con un tutorial que considero básico e imprescindible: cómo funciona un videojuego. A la hora de enfrentarnos a cualquier cosa, lo más complicado suele ser saber cómo empezar, cuál es el origen de todo lo que vamos a hacer después. Y creo que esta preocupación ocurre tanto a la hora de programar, como de enfrentarse a una hoja en blanco o al pedir nuestra primera subida de sueldo.
Con los videojuegos algunos motores nos darán esta base, y a partir de ahí podemos mirar un montón de tutoriales para seguir haciendo cosas, pero si no sabemos qué es lo que hace funcionar a nuestro juego, o en qué parte actúa el API que estemos utilizando, muchas veces iremos a ciegas. Y como todos ya nos conocemos el refrán «ojos que no ven, ostiazo que te pegas» vamos a intentar arrojar un poco de luz sobre todo esto.
Pues bien, un juego no es más que un bucle continuo llamado game loop:
Todo juego tiene una estructura similar, pero tenemos que tener en cuenta el API sobre el que estamos trabajando.
ReadInput()
Aquí comprobamos el estado de los distintos dispositivos de entrada (ratón y teclado sobre todo, pero podría ser un joystick o un joypad, una pantalla táctil en el caso de un smartphone, o incluso un micrófono). Es altamente recomendable separar la lógica del ReadInput de la del Update(), y utilizar flags que indiquen el estado del input para que el Update actúe en consecuencia.
También es ideal que almacenemos las teclas en variables, de este modo podremos cambiar fácilmente el mando del juego.
No recomendado:
Recomendado:
De este modo, separaremos de forma lógica ambas funciones y tendremos un código más ordenado, lo que nos ayudará enormemente cuando tengamos un Update complejo en el que tengamos que tener en cuenta un montón de variables.
Update()
Aquí desarrollaremos toda la lógica de juego, pero no os abruméis. Un juego no es más que unos cuantos objetos con una serie de estados, que realizan funciones. Así, en función de su estado, cambiaremos su posición en la pantalla, pero también deberemos de acordarnos de controlar la vida, la munición, los puntos o el resto de variables que estemos utilizando.
Dentro del Update deberíamos tener en cuenta también la física, pero por lo general nos la manejará automáticamente nuestro motor, por lo que no tendremos que preocuparnos. Si no lo hace, hoy en día existen motores físicos para absolutamente todas las plataformas que seguro podremos utilizar. Unity 3D, por ejemplo, tiene su propio manejador de físicas, por lo que sólo nos tendremos que preocupar de establecer en nuestro objeto una serie de propiedades físicas.
Los cálculos físicos suelen ser los últimos que se realizan en el Update
Render()
Cuando trabajamos con un motor gráfico, lo que hace básicamente es manejarnos automáticamente la función Render() (aunque luego pueda resolvernos más cosas, como la física), ya que es la que trabaja directamente sobre las librerías gráficas (DirectX u OpenGL), y muchas veces en nuestros juegos nos bastará con añadir nuestros elementos a un Graphic Layer (una capa que se encarga de dibujar todo lo que haya en ella), o heredar nuestros objetos de alguna clase que contenga toda la lógica de renderizado.
¿Dónde encaja todo esto en Unity 3D?
Efectivamente, en Unity 3D nosotros no vemos este bucle por ningún lado.
Antes que nada, hay que comprender que Unity 3D sigue una arquitectura basada en componentes, que es ligeramente distinta a la más familiar POO (Programación Orientada a Objetos). La diferencia entre un objeto y un componente es que los primeros necesitan ser instanciados, es decir, partimos de una clase que define un tipo de objeto que nos servirá de molde para crear objetos similares (por ejemplo, la claseEnemy nos podría servir para crear multitud de enemigos). Mientras tanto, los componentes se asemejan más a scripts, trozos de código que dan una funcionalidad determinada al objeto al que se anexan, y cuando uitilicemos la palabra clave «this«, no referenciaremos al componente, sino al objeto sobre el que está alojado.
De este modo, si en Unity creas un GameObject (que es cualquier cosa que actúe en el juego), tendrá toda la funcionalidad básica de un objeto del juego, pero si además le añades, por ejemplo, un componente RigidBody, el GameObject tendrá física, y si también le pones un componente Player, en el que defines la lógica del jugador, esteGameObject ahora responderá a las acciones del jugador.
Ambas arquitecturas pueden combinarse, y de hecho lo hacen. Tú, por ejemplo, puedes crear un componente cuya lógica utilice instancias de clases, y después agregarlo como componente a un GameObject.
Muy bonito todo este inciso, pero seguimos sin ver el game loop del que os he hablado al principio. La razón de esto es que Unity lo está manejando de forma transparente, sin que nosotros nos demos cuenta. Cada vez que Unity da una vuelta al bucle, llama a una serie de funciones contenidas en el MonoBehaviour. Por eso, cuando creamos un script en C# (el lenguaje recomendado), veremos que hereda de esta clase. Así, lo único que tenemos que hacer cuando creamos un script es definir estas funciones. Por defecto Unity nos creará Start() y Update().
Unity 3D nos ofrece la documentación de las funciones que utiliza en esta web: http://unity3d.com/support/documentation/Manual/Execution%20Order.html
Es imprescindible que tengáis en cuenta que cada vuelta al loop puede tomar un tiempo distinto en función de la carga del procesador, por lo que tendréis que utilizar este espacio de tiempo en vuestros cálculos. Para ello, Unity pone a vuestra disposición la variable Time.deltaTime, que no es más que los segundos que ha tardado el juego en completar el último frame.
La excepción es FixedUpdate(), que tiene un tiempo de llamada específicado en la variable global Application.targetFrameRate.
Aunque para trabajar con físicas FixedUpdate() es la función recomendada, debemos tener mucho cuidado al utilizarla, ya que procesos muy cargantes o frameratesdemasiado pequeños pueden hacer que nuestro juego haga cosas raras o nos vaya a saltos.
Ahora que comprendemos el game loop de un juego y sabemos cómo interactuar con él en Unity 3D, podemos empezar a hacer nuestros primeros scripts sin cortocircuitarnos en el intento ;).
Como Neowedge no está seré yo el encargado de hacer esta semana este episodio de Desarróllame, ya conocemos un poco el entorno de trabajo así que ahora vamos a trabajar de verdad, para ello hoy trataremos de hacer que un cilindro se mueva sobre un plano en 3 dimensiones, añadir físicas y que la luz siga a nuestro personaje.
Tras abrir Unity 3D vamos a File -> New Project…
Entonces nos pedirá la localización del proyecto donde pondremos lo que queramos, lo que si es importante es Importar el paquete de Scripts.
Tras seleccionar Scripts.unity le damos a Create, bueno después de unos instantes nos saldrá el editor para que empecemos a jugar.
Primero vamos a crear lo que sería nuestro suelo para ello vamos a crear un plano, esto se hace así GameObject -> Create Other -> Plane y luego haremos lo mismo pero creando un Cilindro (Cylinder).
Luego en Hierarchy vamos al Plano (Plane) y en el inspector le pondremos en el componente Transform lo siguiente: Posición X = 0, Y = 0, Z = 0.
Con el Cilindro pondremos de posición X = 0, Y = 0.5 y Z = 0 y en Scale X = 0.5, Y = 0.5, Z = 0.5, el cilindro quedará como en la foto.
Tras estos primeros retoques la escena quedará ya realizada, pero sin luz por lo que al tocar «Play» no veremos sino algo oscuro, así que vamos a crear una luz para poder ver algo, como siempre vamos a GameObject -> Create Other -> SpotLight y finalmente la pondremos en el X=0, Y = 6, Z = -5, en la rotación (Rotation) con X=45, Y=0, Z=0 y en el componente de Light le aumentaremos la intesidad a 3.
Ahora le pondremos a la cámara un script de los que Unity trae por defecto se trata en la Zona de Project abrir Standard Assets -> Scripts -> Camera Scripts y arrastrar ahí el script SmoothFollow a Main Camera del Hierarchy, miramos que en Main Camera tenemos un componente llamado Smooth Follow y en Target le arrastramos el Cylinder desde el Hierarchy, ese script lo que hace es seguir a un target (Objetivo) en nuestro caso ha sido el cilindro podríamos haber puesto cualquier otro elemento, pero nuestro «personaje» hoy será el cilindro.
Con esta cámara tenemos un efecto de juego en 2.5D como las cámaras de NewSuper Mario o Donkey Kong, evidentemente salvado las distancias, aunque con los parámetros que nos dejan modificar desde el Inspector podemos acercar o alejar la camara y algunas cosas más que hacen que merezca la pena usar un script creado antes que crearlo nosotros para este ejemplo.
El siguiente paso será que nuestro cilindro se mueva para ello tendremos que crear un nuevo script, en Project-> Create -> C Sharp Script, le cambiamos el nombre haciendo click a la derecha del nombre tras seleccionarlo y lo llamamos Controller, puede ser cualquier nombre pero nosotros vamos a usar ese, ahora lo abrimos haciendo doble click.
Ahora borramos todo lo que hay en el código y ponemos esto:
using UnityEngine;
using System.Collections;public class Controller : MonoBehaviour {
// Constructor
void Start () {}
// En cada frame se llama a esta función
void Update () {//Al pulsar el botón A cambiamos la posición de nuestro personaje hacia la izquierda
if(Input.GetKey(KeyCode.A))
transform.position -= Vector3.right * Time.deltaTime;
//Al pulsar el botón D cambiamos la posición de nuestro personaje hacia la izquierda
if(Input.GetKey(KeyCode.D))
transform.position += Vector3.right * Time.deltaTime;
//Al pulsar el boton S iremos hacia adelante
if(Input.GetKey(KeyCode.S))
transform.position -= Vector3.forward * Time.deltaTime;
//Al pulsar el boton W iremos hacia atrás
if(Input.GetKey(KeyCode.W))
transform.position += Vector3.forward * Time.deltaTime;}
}
Este código es bastante sencillo lo único que hace es que al pulsar una de las teclas A,S,D,W mueve el cilindro cambiando la posición en el eje X o Z, en una unidad por el tiempo que ha pasado entre frames, esto se hace para que si una CPU calcula mucho frames y otra pocos al final el espacio recorrido en 3 segundos sea el mismo.
Ahora vamos a hacer que al cilindro le afecten las físicas, gracias a Physix de NVIDA que viene con Unity esto se hace con un par de clicks, con el cilindro seleccionado vamos a añadir un nuevo componente, este está en Components -> Physics -> RigidBody si ahora le damos a PLAY el cilindro se caerá, ¿por qué? porque el plano no tiene una superficie con la que chocar es invisible para las físicas así que seleccionamos el plano y en el Inspector le damos en el componente Mesh Collider a Smooth Sphere Collision a Convex.
Si le damos a Play ahora el cilindro se caerá así que tenemos que cambiar en la componente de RigidBody las Constantes (Constraints) y poner en la rotación Freeze Rotation en todos los ejes.
En el código después de hacer que se mueva hacia atrás ponemos la siguiente línea:
//Al pulsar el boton espacio saltaremos
if(Input.GetKeyDown(KeyCode.Space))
rigidbody.AddForce(Vector3.up * 200);
Como el código es tan simple si tocamos varias veces espacio haremos dobles saltos y hasta N saltos en el aire.
Ahora vamos a crear un nuevo script llamado Follow para que la luz siga a nuestro personaje
using UnityEngine;
using System.Collections;public class Follow : MonoBehaviour {
//El objetivo que vamos a seguir
public GameObject objetivo;void Update () {
//La posición de la luz será la misma que la que habíamos dicho antes, pero ahora estará vinculada con la posición del personaje para que lo siga.
transform.position = new Vector3 (objetivo.transform.position.x, objetivo.transform.position.y + 5, objetivo.transform.position.z – 5);
}
}
Se lo añadimos a nuestra SpotLight y luego en objetivo le ponemos el cilindro y con esto ya tenemos que la luz siga al personaje.
Si te has quedado sin entender algo puedes preguntarnos en los comentarios, además de descargar el proyecto del tutorial aquí
Familiarizándonos con la Interfaz
Primeros pasos
Vamos a empezar a utilizar Unity. Si aún no lo has abierto, puedes hacerlo desde «Inicio -> Programas -> Unity» en Windows o «Aplicaciones -> Unity» en Mac. Nos aparecerá el editor de Unity. Tómate tu tiempo para echarle un vistazo a la interfaz del Editor de Unity y familiarizarte con ella. El Main Editor Window está formado por varios cuadros llamados Views. Hay varios tipos de Views en Unity, cada uno con un propósito distinto.
Project View
Todos los proyectos de Unity tienen una carpeta «Assets«. El contenido de esta carpeta es mostrado en el Project View. Ahí es donde guardaremos todos los recursos que formarán nuestro juego, como escenas, scripts, modelos 3D, texturas, archivos audio y Prefabs (objetos prefabricados). Si haces click con el botón derecho del ratón en cualquier recurso del Project View, puedes elegir «Show in Explorer» («Reveal in Finder» en Mac) para abrirlo desde el sistema de archivos de tu ordenador.
Nota importante: Nunca muevas tus archivos desde el Sistema Operativo porque podría romper los metadatos asociados. Utiliza siempre el Project View para organizar tus recursos.
Para añadir recursos a tu proyecto, puedes arrastrarlos desde el sistema de archivos en el Project View, o utilizar la opción «Assets -> Import New Asset…«. Tu recurso estará disponible para que puedas utilizarlo en tu juego.
Las Scenes también se guardan en el Project View. Éstas son niveles individuales. Por ejemplo, puedes tener una pantalla de menú inicial, varios niveles de juego, etc. y cada uno de ellos será un Scene distinto. Para crear una Scene, pulsaCtrl+N (Command+N en Mac). Para guardar la escena actual, pulsa Ctrl+S(Command+S en Mac).
Algunos recursos del juego son creados desde Unity. Para ello, haz utiliza la lista desplegable de Create o haz click con el botón derecho del ratón y selecciona Create.
1. Lo primero que haremos va a ser bajarnos la última versión completamente gratis desde aquí: http://unity3d.com/unity/download/.
Con este artículo estrenamos Desarróllame, una nueva sección de n3dsworld donde iremos publicando artículos sobre el desarrollo de videojuegos y entrevistas con profesionales del sector.
Si quieres hacer un videojuego, ya has dado el primer paso de un largo camino, que es precisamente querer hacerlo. Puede que parezca una perogrullada, pero no lo es. Eso sí, debes estar muy seguro de que realmente quieres hacerlo.
Si es tu primer juego, el recorrido probablemente será largo y duro, y no puedes dudar en ningún momento. Ármate de paciencia y de motivación, y sé sincero contigo mismo: no va a ser fácil, puede que tengas que dar muchos rodeos antes de alcanzar tu objetivo, y existen muchas posibilidades de que en algún momento decidas que el esfuerzo no merece la pena.
Si llegados a este punto sigues leyendo, puede ser por dos cosas: te pica la curiosidad o realmente estás dispuesto a sacrificar tiempo y paciencia para hacer tu juego.
Un recurso que puede ayudarte a enfocar tus esfuerzos y a sincerarte contigo mismo, y que debería hacerse incluso antes de plantear tu idea, es un análisis DAFO (Debilidades, Amenazas, Fortalezas, Oportunidades), seguido de la estrategia a seguir basándose en este, y una conclusión. Este concepto que parece tan empresarial, no tiene por qué ocuparos más de una página (aunque podría extenderse todo lo que se quiera), y es una forma de ser realmente consciente de nuestras capacidades.
Este es el DAFO a partir del cual decidimos desarrollar Bellum (mi proyecto de fin de curso):
