lunes, 15 de junio de 2015

Unity3D Scripting: Modificación básica de inspector

Aquí volvemos una vez más a aprender algo, esta vez muy práctico tanto para el programador, como, una vez desarrollada esta herramienta, para el dibujante, músico, diseñador de nivel, guionista...

Vamos a ver como modificar la vista en el inspector de un script que hayamos creado de manera rápida y sencilla.
Visualización de configuración de editor
En primer lugar, analicemos su utilidad, quizás esta sea una de las herramientas de Unity3D que lo hacen realmente una gran alternativa, ya que puede facilitar la edición de los parámetros de entrada sin apenas consumir tiempo de desarrollo, de hecho, todo lo contrario, lo agilizaría.

Unity3D, ha facilitado mucho esta funcionalidad de manera que, en este primer contacto vamos a ver una forma sencilla de editar, valga la redundancia, el editor, es decir, los valores que veremos en el inspector, para verlos de una manera un poco más amigables para quien tenga que tratar con dicho componente más adelante.

Vamos a crear un script sencillo, realmente no es necesaria una utilidad en concreto para este ejemplo, simplemente ver cómo podemos cambiar el aspecto del componente en el inspector:

using UnityEngine;

[DisallowMultipleComponent]
public class InspectorEditExample : MonoBehaviour
{
 [Range(-10, 10)]
 public float Rotation;

 [Header("Escala")]
 [Range(.1f, 1)]
 public float Scale;

 [HideInInspector]
 public Vector3 Position;

 void Start()
 {
  Position = Vector3.one * Random.Range(0f, 1f);
  transform.localPosition = Position;
 }

 void LateUpdate ()
 {
  transform.Rotate(Vector3.up * Rotation);
  transform.localScale = Vector3.one * Scale;
 }
}

Si asociamos este Script podremos ver la imagen mostrada arriba, Si nos fijamos apenas hemos tenido que hacer nada, ahora vamos a ver las posibilidades que tenemos si hacemos este tipo de edición:

[DisallowMultipleComponent]
public class InspectorEditExample : MonoBehaviour

En primer lugar, como podemos ver en el script, al colocar estas etiquetas en las variables, han sido alteradas sus visualizaciones en el editor y a su vez, que tenemos etiquetas que afectan a la clase, como en este caso, que no nos permitirá añadir dos componentes iguales al mismo objeto para que no entren en conflicto entre sí.

[Range(-10, 10)]
public float Rotation;

Pasando a nuestra primera variable pública el parámetro Range podemos ver que pasa de poder insertarse un número, a tener una barra para desplazar entre el mínimo y el máximo que permitamos, siendo el número de la izquierda el mínimo y el número máximo el de la derecha, en caso de poner el número menor a la derecha y el mayor a la izquierda, la barra se usaría de manera invertida, moviéndola hacia la izquierda para los números más grandes y hacia la derecha para los números más pequeños.

[Header("Escala")]
[Range(.1f, 1)]
public float Scale;

En la siguiente variable pública Scale, podemos ver que además podemos acumular estas etiquetas entre sí, siendo esta nueva etiqueta para poner un título encima de esta variable, así podremos dar una definición más concreta.

[HideInInspector]
public Vector3 Position;

Y por último podemos ver en el Script una variable pública que no está en el componente a la hora de visualizarlo en el editor ¿Qué utilidad puede tener esto? Fácil, que sólo queramos que se pueda ver y/o editar a través de otros componentes, y no llenar el componente en el editor de datos que quien vaya a tener que modificarlo en la escena no solo no le interesa, sino que puede inducir a error en caso de creer que hay que rellenarlo.

Aquí tenemos una lista de las posibilidades que tenemos para editar la visualización del componente en el inspector a través de este método, que denominaremos "el método sencillo" ya que hay un método más complejo pero con una infinidad de posibilidades más, que veremos en otra ocasión.
Toda esta lista tiene un enlace a la documentación oficial en la web de Unity para quien quiera investigar un poco al respecto.

Espero que sirva de ayuda, y se entienda, la implementación y uso para estas pequeñas ediciones rápidas dentro de nuestro inspector.

lunes, 8 de junio de 2015

Como crear un documento de diseño de videojuegos (GDD)

Quizás esto debería haber sido lo primero que debería haber puesto en esta web ya que, por aquí sin duda alguna, es por donde debríamos empezar cualquier videojuego, tenerlo por escrito, definirlo desde el principio, de la A a la Z, en que consistirá, que contendrá y como se jugará a nuestro juego, vamos a ver los puntos que al menos yo considero esenciales para nuestro GDD (Game Design Document) o documento de diseño de videojuegos, del cual por supuesto, podemos obviar que, algunos puntos en diversos juegos pueden ser irrelevantes o inexistentes al igual que, en otros pueden faltar diversos puntos.
Game Design Document
¿Como debemos expresar este documento?
En primer lugar debemos tener en cuenta algo muy importante, y es la forma de expresar el documento, un buen consejo que me dieron una vez es expresarlo como si de la contraportada de la caja del videojuego o del trailer se tratase, por ejemplo:

Si queremos especificar que nuestro personaje podrá lanzar una bola de fuego, aunque podamos expresarlo tal que así: "Al pulsar el botón de habilidad, se instanciará unas partículas de fuego y se hará 10 de daño al enemigo", quizás con esta otra forma podríamos dar mas creatividad a la hora de hacerlo contando por supuesto que estamos dando mucha más información para que el artista/programador pueda hacer algo mucho mas parecido a lo que tienes en mente, tal que así:

"¡El protagonista lanzará bolas de fuego que harán arder al enemigo en llamas!", Sí, puede sonar poco serio, pero desde luego la visión no es la misma, de manera que si bien no hemos especificado por ejemplo el daño, hay que recordar que realmente ese daño tendría que equilibrarse a medida que se crea el juego, no es nada recomendable dejar en manos del azar ese dato, azar tal como escribir un número en el documento sin haber probado si eso será mucho daño o por el contrario irrelevante.
Identificar el "Core" del juego
Para quien desconozca que es el "Core" podría decirse que es el núcleo del juego, la esencia, por ejemplo:
  • Sonic the Hedgehog: Llegar al final de cada fase lo antes posible.
  • Pokemon: Coleccionar todos los Pokemon.
  • Street Fighter II: Combatir con tus enemigos hasta derrotarlos.
  • ...
Podríamos definir el núcleo de nuestro juego en una frase muy breve y sencilla aunque por supuesto, al igual que en los juegos anteriores, se podría decir mucho mas de ellos, lo cual nos llevaría a, una vez tengamos claro el núcleo, la base de en qué consistirá nuestro videojuego.

Poder especificar que hará que sea divertido cumplir dicho objetivo del juego, por ejemplo en el caso de Sonic, en las fases podremos encontrar Loops, Saltadores, Cajas que al romperlas nos harán ir mas rápido y no dispondremos de mecánicas como puzzles que harían que la mecánica principal se perdiese ya que tendríamos que parar de correr para resolverlos... en definitiva, los elementos de nuestro juego que hacen en un todo que la mecánica básica sea entretenida y divertida teniendo en cuenta que elementos no podremos añadir para no romper nuestro core.
Crear una lista de características
Definir todas las características de nuestro juego que nos orientarán a todos en lo que tenemos que hacer, algunas de estas características dependerán del tipo de juego, así que aquí van las que al menos yo considero mas importantes:
  • Género: Plataformas, Lucha, FPS, Simulador, Arcade...
  • Ambientación: Western, Cyberpunk, Sci-Fi, Medieval...
  • Público dirigido: Juego para niños, para chicas, para jugadores casuales, para "Hardcore Gamers"...
  • Personajes: ¿Hay personajes? Si hay, protagonistas, antagonistas, "figurantes"
  • Diseños de niveles: Dibujos, esquemas, explicaciones de como serán los niveles
  • Interfaz: Como será la interfaz de usuario, los menús, el flujo de pantallas...
  • Historia: La trama del videojuego y el guión de la misma
  • Estilo: 3D, 2D, PixelArt, Realista, Cartoon...
  • Sonido: Retro, realista, electrónico, clásico...
  • ...
Una vez tengamos todos estos apuntes, lo ideal sería esquematizarlo todo basándonos en un índice creado previamente, aquí dejo un índice de ejemplo para luego rellenar un documento en base al mismo:
  1. Introducción
    • Concepto del juego
    • Características principales
    • Género
    • Publico dirigido
    • Alcance
  2. Mecánicas de juego
    • Jugabilidad
    • Flujo de juego
      • Diagrama de flujo
      • Introducción al juego
      • Jugando
      • Fin de partida
    • Personajes
      • Protagonista
      • Compañero del protagonista
      • Antagonista
      • ...
    • Control de jugador
      • Interacción con el personaje
      • Interacción con el entorno
      • Interacción con la interfaz
    • Interacción del entorno con el jugador
  3. Interfaz
    • Diagrama de flujo de pantallas
    • Menú principal
    • Menú de pausa
    • Menú de guardado/cargar partida
    • Interfaz de usuario durante partida
    • Interfaz de fin de partida
    • Creditos
  4. Arte
    • Estilo
    • Concepts
    • 2D
    • 3D
  5. Sonido
    • Música
    • FX
    • Diálogos
Obviamente este índice no sirve para todos los tipos de juegos ya que si por ejemplo, hacemos un videojuego de naipes (Solitario, Poker, BlackJack...) no tendríamos personajes por ejemplo y esa parte del documento pues sobraría totalmente, así que también es bueno valorar el GDD y decidir por uno mismo de que parte prescindir y en el caso de ser necesario, añadir nuevas categorías.

Para finalizar, dejo aquí un GDD creado por Saltares que puede ser muy buena referencia, en parte yo mismo lo he usado de referencia ya que me ha parecido muy buen GDD y podremos ver de hecho sin ir mas lejos, el videojuego creado a partir del mismo:

GDD de Sion Tower
Videojuego de Sion Tower

jueves, 4 de junio de 2015

¡Mañana DevCon en Sevilla!

Que mejor para volver a darle actividad a esta web que anunciar las jornadas de desarrolladores y videojuegos indies de Sevilla se serán mañana Viernes, 5 de Junio de 10:00 a 20:00 en el Centro cívico las sirenas, La alameda, Sevilla, a todo aquel que esté interesado en este tipo de eventos, aunque un poco tarde, aquí va toda la información al respecto.

Cartel de la DevCon
¡Más vale tarde que nunca!
En este evento vamos a poder ver algunas conferencias muy interesantes, de las cuales, no me gustaría perderme ninguna, aunque en mi caso, por causas de trabajo, no podré asistir hasta la tarde, así que las de la mañana no podré verlas y es una lástima porque realmente me gustarían mucho.

Hoy mísmo han publicado el horario el cual será el siguiente:

Hora Charla Ponente Sala
9:30 a 10:00 Mesa redonda de los invitados (Sólo participantes) ---------- Sala de juntas
10:00 a 11:00 Evento inaugural Alberto Espinal Salón de actos
11:00 a 12:00 Quiero empezar a desarrollar videojuegos Juan Carlos García Salón de actos
12:00 a 13:00 El secreto de la música de los videojuegos David Serrano Salón de actos
13:00 a 14:00 Lo que siempre quisiste saber sobre publicar en steam y nunca te atreviste a preguntar David Erosa Salón de actos
14:00 a 15:00 The last door + V-Art The Game Kitchen y V-Art Salón de actos o Sala sur
17:00 a 18:00 Desarrollo en plataformas móviles Alberto Moreno Sala de juntas
18:00 a 19:00 Diseña y desarrolla para la realidad virtual Fernando M. Sierra Sala de juntas
19:00 a 20:00 Crowdfunding, cómo lograr tu primera inversión Jose María Climent Sala de juntas

La entrada a esta convención es totalmente gratuita, Así que no hay escusa para no asistir, un día de aprendizaje bastante concentrado para desarrollar tus propios videjuegos, no todo lo que necesitas para hacer un videojuego es programar, componer y dibujar, aveces también viene muy bien los consejos de personas que están en el mundillo y que han pasado ya por donde tu vas a pasar.

Web oficial: http://www.devcon.com.es