[GL08] Conf. Enric Álvarez (MercurySteam)

Enric Álvarez, co-fundador de Mercury Steam, estudio creador de juegos como Clive Barker’s Jericho, nos habla de los retos a los que se enfrenta un equipo de desarrollo de videojuegos.


Por ahora, la conferencia que más me ha gustado de este Gamelab, ha sido didáctica y entretenida, a la par que interesante por todo lo que ha contado basado en su experiencia dentro de Mercury Steam. Podéis leer más sobre la conferencia en el post completo.

Guia de supervivencia para desarrolladores de videojuegos next-gen

Primer Reto: lograr que un publisher te preste atención

El principal reto es lograr que un publisher haga caso al estudio para publicar un juego para ps3 o xbox360. Es quizá el mayor reto y el más dificil. Para lograr tener cierta relevancia, lo principal es no obsesionarse en que el publisher preste atención.

El tiempo pasa distinto para el publisher y para el developer. Para los publisher, no arriesgan nada ya que tienen sus puestos asegurados, y eso hace que aumente el tiempo de negociación. Para el developer, el tiempo es oro, ya que le interesa empezar cuanto antes porque de su trabajo depende su salario, y por cada segundo que pasa, más se alejan sus objetivos.

Otro problema es enseñar partes del juego al publisher. Es quizá el problema que más destruye al developer. Es recomendable no hacer un prototipo, y mucho menos un prototipo jugable. Normalmente a un publisher no tiene porque interesarle tu trabajo, pero tras meses de negociación, pueden ofrecerte un proyecto que les interese. Sabiendo esto, tenemos que tener claro lo siguiente: no estamos vendiendo nuestro juego, estamos vendiendo nuestro talento como desarrolladores de videojuegos, y el principal motivo de crear un prototipo es sencillo: es muy costoso tanto economicamente como en tiempo invertido, y realmente, cuando comience el desarrollo del juego en si, no se aprovecha nada y se empieza de cero. Ademas, a la hora de desarrollar podemos encontrarnos con nuevas especificaciones y restricciones que hagan saltar por los aires el planteamiento.

Siguiendo con el problema del prototipo, este nunca va a mostrar algo acabado, siempre van a quedar flecos, y eso hará que el publisher se haga una idea irreal del proyecto, ya que no podemos controlar la percepción que tengan.

Conclusión: un prototipo solo lleva a la eternidad o a la chapuza.

La solución a todo esto: centrarnos en lo verdaderamente importante del juego, y mostradlo de manera que les impresione en 1 minuto, utilizando la tecnología que se vaya a utilizar en el juego, pensad como publisher en lugar de como developer, y entregadles un teaser que pueda ser colgado en internet al día siguiente. Hay que olvidarse del videojuego como tal.

Ventajas de la solucion: es barato, reorienta las negociaciones haciendo que se llegue antes a acuerdo, y hace que el equipo de desarrollo no se queme.

Segundo reto: desarrollo.

Es un autentico tsunami. Se pueden cometer errores en cualquier parte del desarrollo y la creación, al elegir el equipo, al elegir a los responsables, en cualquier fase del desarrollo.

No existe la preproducción en un videojuego a nivel organizativo. Los costes pueden ser tan brutales que no se puede diferenciar entre preproduccion y produccion.

La plataforma next-gen no acepta todo lo que le demos, lo que lleva a que hay que ser astuto al añadir elementos al juego, y hacerlo lo antes posible.

Todos estos puntos llevan a la siguiente conclusión: vas a necesitar mucha más gente de la cuenta en la preproducción.

Consejos:

  • Principal: La capa de gestión y control del desarrollo debe ser lo mas fina posible: cuantos menos jefes, mejor.
  • Primero: mantener el equipo lo más pequeño posible.
  • Segundo: mejor perfiles técnicos y artísticos que gestores.
  • Tercero: el equipo debe estar en contacto directo y real con lo que pase en el estudio.
  • Cuarto: un buen equipo debe ejercer dos funciones para que vaya bien:
    • Garantizar la calidad técnica del material que se mueve en el departamento.
      • Recordar las limitaciones día a día
    • Ejercer de vigías. Es la función de más alto nivel, ya que la persona que tenga que hacerlo debe comprender todo el trabajo, y ser capaz de ir tres o cuatro pasos por delante y avisar que algo va mal.

La influencia del publisher sobre el desarrollo rara vez que el juego sea mejor. Las necesidades del publisher van en contra de la calidad del juego. Si el publisher cree tener una visión del juego, todo llevará a un descenso en la calidad del juego, ya que sus necesidades no tienen nada que ver con el desarrollo dia a día del juego.

Las soluciones son dificiles. No se debe excluir al publisher del desarrollo, no es recomendable. Si en el lado del publisher tienes gente capaz de aguantar la presión y sabe lo que hace, no generará demasiado problema. Se debe tener una actitud abierta con el publisher, tener una relación abierta con ellos, de manera que alivie el stress que puede suponer el trabajo del publisher, y ganar confianza con ellos, lo cual beneficia al desarrollo.

Tercer reto: afrontar el reto artistico y tecnologico de un desarrollo next- gen.

Desde un punto de vista artistico y tecnologico, la fuerza bruta no tiene ningún sentido, hay que ir solo a por lo que el juego necesita, por lo que hay que identificarlo con claridad. El juego debe lucir alli donde se nota.

Consejos:

  • Primero: es mejor disponer de tecnología propia antes que financiar un motor.
  • Segundo: esta tecnología debe ser adaptada al juego. Hay que evitar la idea de hacer un engine definitivo.

Sigue las respuesta a esta entrada a través de RSS 2.0 RSS. Puedes escribir un comentario, o enlazar un trackback desde tu propio sitio o blog.

Comentar esta entrada