El tiempo es oro

Para que el prototipo sea útil es imprescindible que podamos desarrollarlo rápidamente. Recordemos: su objetivo principal es probar la mecánica de juego cuanto antes.

La clave para optimizar el esfuerzo es utilizar todas las herramientas a nuestro alcance. Nuestro objetivo es programar un prototipo, no reinventar la rueda.

Elección de un motor (engine):

Es fundamental utilizar un motor existente, con él nos ahorramos escribir una parte importante de código. Da igual que al motor le falten algunas características que desearíamos para la versión final, si tiene lo suficiente para fabricar el prototipo, es perfecto.

C4 Engine

En este caso utilizaré el C4 Engine, por estas razones:

• Es un motor 3d y vamos a hacer un prototipo 3d.
• No es solo un motor de renderizado, si no que incluye el resto de librerías necesarias para programar un juego. Lo que se suele denominar Game Engine.
• Tiene varias herramientas internas para editar escenarios, materiales, etc.
• Estoy familiarizado con su uso (importante si lo que buscamos es la rapidez).
• Tengo la licencia (eso ayuda).

Guardar en el cajón todo lo que sobra en un prototipo:

El prototipo no es lo mismo que empezar a programar el juego, hay que dejar fuera los detalles triviales, por ejemplo:

• El sonido (a menos que el juego sea musical, claro).
• Que funcione en cualquier PC (con que funcione en el nuestro y quien queramos que lo pruebe, sobra).
• Menús con opciones (las opciones, si son necesarias, con que se modifiquen en un fichero de texto o que sea mas fácil, listo).
• Hacer gráficos como si fuese la versión final. Normalmente con unas cuantas primitivas 3d, modelos sin texturas de color plano, es más que suficiente.
• Programar código exquisito, que cuide todos los casos. Tampoco se trata de programar mal, pero sí de programar rápido por encima de todo.

En general cualquier detalle cosmético está de más en un prototipo.

prototipo de Crayon Physics

Lo que hagamos con el prototipo prácticamente irá a la basura cuando empecemos el juego, hay que imaginarlo como una hoja donde dibujamos garabatos hasta dar con el dibujo que nos gusta, el cual pasaremos a limpio después.

<<¿Quieres hacer juegos o quieres hacer herramientas?>>

Al hilo del prototipo me gustaría hacer un inciso para hablaros de otra parte importante del diseño: la prueba del concepto.

Imaginemos que estamos pensando en desarrollar un juego con una mecánica peculiar, que sea complicada de imaginar solo con palabras. O de la que no estamos seguros que funcione.

En estos casos se puede hacer un montaje o una aplicación simple que muestre la idea o concepto de forma visual.

Mientras que el prototipo es una versión rudimentaria del juego, que contiene las piezas clave y sirve para probar su funcionalidad de manera general, las pruebas de concepto abarcan una parte concreta del desarrollo y pueden ser simplemente un vídeo.

Para terminar, os dejo con el proof of concept del videojuego Mirror’s Edge. Como veréis, se trata de un vídeo hecho en 3D Max (o similar), con un escenario sin texturas, animaciones y modelos simples, pero que nos permite a todos hacernos una idea de lo que intentaban conseguir:

¿Es factible un plataformas en primera persona?

Tenemos la idea básica de lo que queremos hacer, lo cual está muy bien, pero realmente por mucho que la definamos, nunca dejará de ser una paja mental. Ya sabéis, aunque la paja se vista de seda…

En un mundo ideal, a partir de la idea aparecería un juego completo, entonces solo habría que probarlo y de esta forma decidir si es divertido o no.

El problema es que hacer un juego completo conlleva un trabajo enorme. Puedes pasarte meses o incluso años desarrollando juegos que en una tarde te puedes acabar al jugarlos.

Nosotros tenemos una vida limitada en el tiempo, así que hay que buscar una fase intermedia entre desperdiciar dos años de tu vida haciendo un juego para ver si merece la pena y pretender que solo con la idea ya sabes que es la nueva obra maestra de los videojuegos.

Pues esa fase existe, y se la denomina prototipo. Básicamente consiste en aislar la parte jugable fundamental, esa que hace divertido un videojuego, y tratar de desarrollarla en poco tiempo, eliminando todo lo que sea superfluo (por ejemplo, para probar el arma gravitatoria de Half Life 2 basta con una sala grande con objetos sin texturas, no necesitamos modelar toda la ciudad del juego).

Retrospectiva del Pang 3D

Para ilustrar nada mejor que un ejemplo. Hace tiempo un amigo me convenció para programar un clásico, el pang, en tres dimensiones.

Pang, juego sencillo y adictivo donde los haya

La idea sonaba bien, el pang es divertido, un vicio (sano , sencillo… lo tiene todo.

Parecía que lo teníamos todo a nuestro favor, así que me animé a hacer un prototipo para probar la jugabilidad e investigar como podría jugarse al pang en tres dimensiones.

El resultado fue… bastante descorazonador. Después de probar varios controles, con cámaras en primera persona, tercera, isométricas, etc, comencé a darme cuenta porque no había encontrado ningún pang en 3d… ¡Era un aborto! totalmente injugable, no había forma de acostumbrarse a donde estaban las bolas con respecto al personaje, colocarse bien a tiempo, o poder esquivarlas.

Pang3D o ¡quiero morir!

En el original de 2d, puedes ver todas las bolas a la vez (o al menos, alguien con suficiente visión periférica). Sin embargo en un mundo tridimensional por muchos inventos de cámaras que hagas, siempre habrá pelotas revoltosas que se escondan a la cámara, la perspectiva engaña al jugador y le cuesta colocarse, aun utilizando sombras para identificar su posición respecto al suelo.

Así que gracias al prototipo, en muy poco tiempo pude darme cuenta de que aquella buena idea en la práctica se traducía en un juego lamentable.

Dev In Spain: el prototipo

La prueba de fuego, la mejor forma conocida por el hombre para decidir si esta idea y blog sobreviven.

Este es un juego muy complejo, se comprende de muchas partes y todas ellas se pueden desarrollar hasta el infinito. Es el peor caso para un prototipo, por lo que lo primero que vamos a hacer es diseccionarlo, localizar el núcleo de la jugabilidad, quedarnos con ello y tirar el resto.

Vamos por partes, pues. El juego podríamos dividirlo en:

• Menús de opciones. El día que necesitemos que un usuario final toque las opciones, lo haremos, para el prototipo sobra.
• Mini-mundo. La pantalla donde se muestran las oficinas disponibles y
  elegimos cuales comprar, o de las que ya poseemos, cual pasamos a
  controlar.
• Visita a ferias. Esto es casi un mini-módulo accesorio, se ve a la milla que es prescindible para el prototipo.
• Critica de las revistas. Lo mismo.
• Elección del proyecto, contacto con el publisher y cualquier cosa
  relacionada. Podemos hacer que sea un proyecto predefinido o que se
  elijan unas pocas opciones en una pantalla de menú sencilla. Lo del
  publisher lo obviamos.
• Oficina del desarrollador. Aquí es donde acondicionamos la oficina,
  contratamos el personal, gestionamos el proyecto. Esta claro que es la
  parte fundamental del juego, esto va al prototipo.

La parte de la oficina tiene muchos sub-módulos, hacerla entera sigue siendo imposible, hay que seguir pelando la cebolla:

• Comprar y colocar mobiliario de la oficina. Con la Sims-manía que hay, sospecho que esta parte va a gustar, aunque estaría bien probarla, creo que podemos correr el riesgo y partir de una oficina predefinida.
• Contratación de personal. Esta parte no parece muy complicada, es un
  listado de posibles candidatos, una pantalla en la que saldría la ficha
  del mismo y la opción de contratar o cancelar. Sin embargo no es algo
  fundamental, en la partida nos podrían dar un personal predefinido al
  igual que la oficina.
• Gestión del día a día en la oficina. Esta claro que esto es el juego,
  todas nuestras energías tienen que ir a desarrollar esta parte. Esto es
  lo que nos dirá si la idea merece la pena.

Bueno, con esta disección os dejo hasta el siguiente capítulo de esta aventura, en la que comenzaremos a desarrollar el prototipo. Hasta entonces, sed buenos.

¿Ah, sí?, pues tu prototipas como una vaca.

Al igual que un buen plan de empresa debe tener un análisis de la competencia, un buen diseño de videojuego debe tener en cuenta los juegos similares:

1. Para evitar hacer el mismo juego (aquí no se busca hacer un clon del Sims para venderlo).
2. Podemos aprender mucho de los éxitos o fracasos de los demás.

Dicho esto, comenzamos con nuestro listado de “padrastros”.

Game Tycoon (http://en.wikipedia.org/wiki/Game_Tycoon)

Gracias a Nae descubrí este intento de juego.
Digo bien intento, tras haber probado la demo que tienen colgada en su página web, me di cuenta que el juego es un saco de bugs injugable.

Aún asi, viene bien para demostrar dos puntos:

• Las ideas no son tan únicas como pensamos.
• Una idea por si misma no vale de nada: lo fundamental es su ejecución.

Theme Hospital (http://es.wikipedia.org/wiki/Theme_Hospital)

¿Qué puedo decir de este gran clásico? ¿cuantas horas hemos podido dedicar muchos a este fantástico juego? Sucesor del Theme Park, hablaré del Hospital por ser más similar, en mi opinion, al juego que nos ocupa.

Lo que comparte con “Dev In Spain”:

• El estilo gráfico y ambiente es desenfadado o incluso cómico.
• Gestión económica sencilla.
• La progresión de un local pequeño a otros cada vez mayores.
• El stress de la partida, el factor que crea la adicción al juego.

Detalles e ideas prestadas:

• La visita del VIP a los hospitales se parece al concepto de la visita de los productores al estudio de videojuego.
• Tener contentos y productivos a los médicos y enfermeras se parece al control de los miembros del equipo de desarrollo.

A evitar:

• Theme Hospital se basa en fases con misiones que hay que cumplir de forma lineal. “Dev In Spain” busca un desarrollo sin fin y sin fases lineales, al estilo sandbox.

The Movies (http://en.wikipedia.org/wiki/The_Movies)

Se trata de un juego reciente, lo cual es bueno ya que nos puede dar ideas más actuales.

Lo que comparte con “Dev In Spain”:

• El eje central de la jugabilidad es mantener el estudio y crear proyectos (en este caso películas en vez de videojuegos).

Detalles e ideas prestadas:

• El portal de la comunidad de “The movies”, podria ser interesante tener un portal de estudios de videojuegos creados en “Dev In Spain”. ¿Quizás en plan revista de videojuegos ficticia?

A evitar:

• El estudio que gestionamos es el mismo siempre. Se puede ir mejorando, pero no podemos montar oficinas distintas ni cambiar el emplazamiento.
• El interfaz y el control de personajes es demasiado similar a “Los Sims“, lo cual supongo que es bueno para vender este juego, pero le resta mucha frescura y a veces da la sensación de estar jugando a un “clon de segunda”. Este punto lo recalco porque cuando uno observa a la competencia puede tender a copiar, cosa que debemos evitar a toda costa. La idea de este ejercicio es buscar inspiración, no la simple fotocopia.

Existen muchos otros juegos del género susceptibles de aparecer aquí, pero a grandes rasgos creo que estos títulos son los mayores exponentes de los juegos que creo que comparten desarrollo con “Dev In Spain”.

<< ¿Inspirar es copiar? >>

Este es el listado inicial de empleados que podremos contratar a lo largo de la partida. Al igual que la mecánica de juego, este listado es un esbozo y queda abierto para quitar o añadir puestos según avance el diseño del juego.

Los puestos son:

Diseñador

A partir de la hoja de proyecto que hemos rellenado, los diseñadores deberán escribir la guía de diseño, con la que podemos iniciar el desarrollo del juego. Los diseñadores novatos seguramente crearan guías incompletas o con mecánicas de juego aburridas, mientras que los experimentados lograrán mejores juegos más fácilmente.

Programador

Se encarga de traducir del idioma humano al lenguaje máquina. Cuantos más y mejores sean nuestros programadores, mejor será la tecnología del juego y menor cantidad de errores tendrá.

Grafista

Responsables del apartado visual del juego. El que un juego sea visualmente impactante dependerá de ellos.

Músico

Produce la banda sonora y los efectos de sonido. A los jugadores les gustará escuchar una música digna de cine.

Tester

Se encargan de probar un juego para encontrar todos los bugs(errores) posibles. Tenerlos en el proyecto significa que el juego final estará más pulido, a costa de que el trabajo de programación aumentará.

Conserje

Ocupados del mantenimiento y limpieza del local. Sin ellos la basura invadiría la oficina y los ordenadores rotos nunca se arreglarían.

Productor

Su labor es hacer que el proyecto sea posible, por todos los medios a su alcance. Pueden acelerar el desarrollo, pero cuidado, si no se administran bien pueden generar estrés entre tus empleados e incluso provocar el efecto inverso al deseado.

Divo

Cualquiera de tus empleados puede llegar al estatus de “divo”, también puedes contratar a un empleado que ya tenga rango de divo.
Un divo tiene una fama asociada, lo que te facilitará la tarea de contactar con las productoras (publishers) y los proyectos en los que se vean involucrados generarán expectación entre los jugadores.

La parte negativa es que tienden a desarrollar un grado de excentricidad, por lo que no es aconsejable tener muchos divos o dejarles hacer sin control, de lo contrario pueden llegar a hacer peticiones imposibles o incluso cargarse un proyecto.

Ejemplos de Divo:

Pedro Molinillo

Vieja leyenda de la programación, famoso por realizar gran cantidad de juegos exitosos, Pedro siempre apuesta por los juegos originales.

Le gusta mucho las bebidas tropicales por lo que si quieres contratarle, más te vale tener una máquina de zumos.

Juanra Al Mero

Ha sido diseñador de una docena de FPS, sus diseños siempre son sinónimo de éxito. Al menos hasta su último juego, que fue un fracaso total.

Si quieres a Juanra en tu equipo, deberás estar dispuesto a atender un gran número de peticiones, ya que es bastante excéntrico.

Anexo 1. Personaje extra:

VIP

Al contrario que el resto, el VIP ni se contrata ni es controlado por el jugador. Son enviados por las productoras (publishers) para evaluar el estudio y el proyecto de videojuego. Suelen darse un paseo por el local antes de ver la demo.

<< Hagamos un mmorpg con toques de fps… ¡Y que tenga magias! >>

La mecánica general del juego (muy mal explicada en la Wikipedia, lo siento) consiste en lo siguiente:

-Aparece el menú general, en el que seleccionamos “Nueva partida”.

-Avanzamos a la pantalla de creación del estudio de videojuegos, en el que elegiremos un nombre y logo (y cualquier otra opción que se nos ocurra para personalizar la compañía).

-Una vez elegidas todas las opciones, llegamos al menú del mapa mundi. En él podemos pulsar con el ratón en cualquier parte del mundo y al instante aparecerá un listado de locales a alquilar en esa zona, tendremos que elegir aquel que se ajuste al presupuesto inicial.

-Con un local alquilado, se activa el modo vista del local, en la que el jugador pasará la mayor parte del tiempo.

-Desde esta vista, es posible editar el local para añadir mobiliario, realizar reformas y controlar al equipo de desarrollo.

-Un estudio recien creado, sin empleados, sin fama, sin contrato, no va a durar mucho. En este punto debe comenzar las contrataciones de personal.

-Existen muchos tipos de puestos, pero lo básico para el ejemplo son: un programador, un grafista, un diseñador y un músico.

-Enviamos las oferta de empleo y cuando lleguen los candidatos elegiremos a uno para cada puesto.

-Ahora podemos crear un proyecto. Podemos elegir entre realizar el juego al completo, o hacer un prototipo/demo. Los juegos al completo podremos hacerlos cuando dispongamos de todo el dinero necesario. Normalmente para hacer proyectos grandes no tendremos suficiente, por lo que necesitaremos a una productora (publisher) que nos ayude, para conseguirlas es necesario presentarlas antes un prototipo/demo.

-Un proyecto es una plantilla en la que definimos el género, la complejidad, tamaño y otras características del juego.

-Una vez rellenada esta plantilla, debe ser entregada a nuestro equipo de diseñadores (en nuestro caso al unico diseñador), el cual comenzará a escribir la guia de diseño, necesaria para poder poner a trabajar al resto del equipo.

-Según la calidad del diseñador, la guia de diseño sera mejor o peor (ello afecta a la probabilidad de que el juego desarrollado sea bueno).

-Con el diseño terminado, podemos asignar al equipo que sea necesario para realizarlo.

-En el ejemplo, el juego completo para moviles arcade de naves, necesita de un programador, un grafista y un musico, justo con lo que contamos.

-Ahora hay que controlar que nuestro equipo cumple con las fechas, que trabajan y no se distraen, que no se estresen hasta el punto de dejar de trabajar, o cualquier otro contratiempo que tenga lugar…

-Supongamos que todo ha ido bien y hemos logrado terminar el juego. ¡Felicidades! Ya tenemos el primer juego de nuestro recien creado estudio listo para venderse.

-Ahora hay que venderlo, para ello tendremos que ir al menú del listado de productoras/distribuidoras (publishers), y pedir una cita.

-En base a la fama de tu estudio, decidiran si merece la pena ir a tu estudio a ver tu juego. Las que acepten concretaran una fecha para enviar a un hombre (VIP).

-En el dia acordado, el VIP se dará un paseo por el estudio, comprobando la calidad del mismo, se generará una puntuacion en base a la limpieza, el tamaño, el estado del mobiliario y de los empleados, etc. Cuando el VIP termine el paseo, vera el prototipo o juego completo que tengas que presentarle.

-Con la nota tanto del juego como la del estudio, el VIP realizará un informe, que a los pocos días te llegará y podrás leer. Este informe tendrá que tener una serie de puntos y frases tipo, que abarquen las posibilidades del juego. Un ejemplo de informe:

Caso producir un juego a partir de un prototipo/demo:

Caso distribuir un juego completo:

-Suponiendo que el juego de naves es aceptado y comienza a venderse, al estudio le llegaran los ingresos que vaya obteniendo, con el que podremos mantenernos y continuar el ciclo, mejorando las instalaciones y acometiendo mayores proyectos.

<< Llegar es fácil, lo difícil es mantenerse >>

Aunque parezca mentira todo juego que se precie comienza siendo una simple idea.

Y no digo simple por desprestigiar a las ideas, realmente lo es. Un esbozo, un concepto, muy, muy general, casi una intuición, de algo que sospechamos que podría llegar a ser un buen juego.

Eso, si encontramos una jugabilidad (y conseguimos terminarlo).

Hechas las aclaraciones, os presento a… mi idea:

<< “Dev in Spain” es un videojuego de simulación en el cual el jugador crea y gestiona un estudio de videojuegos. La simulación y estilo gráfico no pretenden ser realistas, más bien al contrario, se busca un punto cómico y de parodia. >>

En este punto, muchos seréis los que borrareis esta página de vuestra mente/computadora y nunca más volveréis a pisar el blog, otros tantos fliparan en colores con la idea y unos pocos seguireis leyendo…

¿El porqué de todas estas reacciones a un simple párrafo?

Muy simple, cada uno de nosotros nos hemos imaginado en unas fracciones de segundo un juego a partir de esa idea. Lo hemos desarrollado y lo hemos jugado.

¿El problema?

Tanto si el juego que tienes ahora en la cabeza te ha gustado, como si lo odias, es solo una paja mental. Cualquier parecido con la realidad es futurible.

Esto ya nos da una pista del problema de las ideas (simples), según abarquemos el proyecto, una buena idea puede llegar a desembocar en un juego horrible, o viceversa.

Por ello Dios inventó la fase de diseño. Esta importante etapa que no debemos confundir con el diseño gráfico, consiste en dar forma a esa simplista idea de un juego feliz, definirla en la medida de lo posible, para que tanto el vecino del quinto como el equipo de desarrollo puedan llegar a las mismas conclusiones y “jugar” en su cabeza al mismo juego.

Y llegar a la conclusión de si ese juego, y no el que inventarón, es el que debe hacerse.

<< The Right Game to Do, The Smart Game to Do >>

Este blog nace como un experimento al que llevo dando vueltas de un tiempo a esta parte.

Siempre me han gustado los post-mortem de videojuegos, en los que el desarrollador comenta todo el proceso de creación del mismo.

El “problema” es que todo está contado desde la perspectiva del final, lo cual es bueno como resumen, pero siempre me ha dejado con la inquietud de pensar si no sería mucho más interesante un diario de desarrollo narrado desde el presente y en el día a día.

Los devblog que he podido ver hasta ahora, siempre parten de un juego bastante definido, digamos que la parte de pre-producción y análisis previo ya han tenido lugar desde la primera entrada del diario.

Por ello he decidido comenzar un proyecto casero (léase amateur) en el que considero tan importante el propio juego como el análisis del mismo que iré haciendo en este blog.

Mi idea consiste en exponer todos los pasos, dudas y por supuesto las soluciones que vaya encontrando en esta pequeña aventura personal.

Por supuesto os invito a todos a participar, tanto aportando soluciones a los problemas que surjan, como dando ideas, o de la forma que consideréis oportuna.

Veamos que sale de todo esto. Hasta el siguiente mensaje

<< Un comienzo es un tiempo muy delicado >>