Muchas veces cuando vamos a la tienda, ahí tenemos los juegos. En su caja, con su precio, y una bonita portada que nos indica qué juego es e, incluso, la cantidad de premios que se ha llevado. A veces no hace falta ni ir a la tienda, nos basta con entrar en Internet a nuestras cuentas de Steam, Desura, GOG, Playstation Network, Xbox Live… para tener un producto fresco que llevarnos a nuestros mandos de jugones a precios más o menos altos y bajos. Cuesta creer que esos productos tan pulidos (bueno, casi siempre) han tenido un desarrollo que ha podido llevar años y, lo más importante, un desembolso económico importante.

El proceso

La primera parte que se plantea todo desarrollador o estudio es ¿qué hago? Ahí, en estudios más o menos profesionales se hace un primer boceto que se suele llamar «Concepto de Diseño«. Es algo que tiene que ser muy conciso y concreto, no más de dos páginas, explicando al detalle a qué se juega, sin perder mucho el tiempo en argumentos o narrativa (aunque puede ser mencionado de manera escueta, o un poco más si la jugabilidad realmente dependiera de la historia). Lo más probable es que surjan varios de estos conceptos y haya que decidirse por uno, o varios. Y es aquí donde entra la fase de prototipado.

Un concepto puede parecer muy bueno sobre el papel y, sin embargo, luego no funcionar en la ejecución (creo que muchos habremos visto juegos cuya idea parecía buena pero luego al jugar nos dejó fríos) por lo que en el estudio se empieza por hacer una versión extremadamente simple del juego, con apenas gráficos (muchos juegos empezaron siendo cubos en movimiento), un escenario con el diseño justo y necesario, y una programación que a lo mejor no es del todo libre de bugs. Es importante descubrir en ese momento si lo que tan bien nos parecía en el papel realmente es bueno en la práctica.

Aquí hemos llegado a un punto en el que ya llevamos un tiempo trabajando (lo preferible sería no más de dos meses, aunque esto ya es impresión personal) en el que estamos dedicándonos a nuestro juego sin obtener un beneficio. En caso de grandes empresas, son sueldos de muchos trabajadores pagados, impuestos, temas legales del país de residencia… En el caso de los indies, agradecer tener unos buenos ahorros o poder tener un trabajo aparte, aunque obviamente eso quita tiempo al desarrollo. Por mencionar un caso, Brian Provinciano comenzó su prototipo de Retro City Rampage mientras trabajaba en otra empresa y, una vez tuvo suficientes ahorros para sobrevivir lo que estimaba para el desarrollo, dejó la empresa y fundó VBlank como empresa de él mismo, sin beneficios hasta la salida del juego.

Total, que si nuestro (o nuestros) prototipos no funcionan, a veces hay que tomar la dura, pero sabia, decisión de aparcarlo y buscar otra idea antes de seguir gastando en algo que tal vez no vaya a ninguna parte. Incluso a veces podemos decidir que «no es el momento» y guardar la idea para más adelante. Pero en cuanto detectamos que algo funciona ya podemos decir la frase: «Estamos en producción«.

Planificación y desarrollo

A partir de aquí, toca planificar, contratar gente si hace falta, y ponerse manos a la obra. La primera parte es ampliar aquel sencillo concepto. Ya no nos limitamos a esas dos páginas, ya podemos definir tranquilamente todas las mecánicas y, si es necesario, escribir el guión. La gente encargada de programación puede mejorar el prototipo y los artistas empezar con los conceptos de arte y primeros modelos. Es importante tener una figura que una todas estas partes, alguien que se encargue de planificar y saber qué tiempos debe manejar cada equipo para ir todos juntos hacia la fecha que se haya decidido. Es importante entonces cerrarse una fecha, para que no se nos dispare el gasto, e intentar ajustarse. Para esto se utilizan metodologías ágiles típicas de ingenierías, y se suele usar Scrum, consistente en ir haciendo una lista de tareas a realizar, una estimación de tiempos para cada tarea, e ir revisando cada cierto tiempo (cada semana, cada quincena…) cómo se va avanzando y si se van cumpliendo los plazos. En función de cómo vaya evolucionando el desarrollo, se va ajustando qué tareas requerirán más prioridad y cuáles tal vez habría que descartar.

En videojuegos se puede optar por varias formas de planificar el proyecto. Una de ellas es el Vertical Slice, consistente en ir haciendo trozos pequeños (por ejemplo, nivel a nivel) en calidad final, y a partir de ahí, viendo lo que se ha tardado, estimar cuántos niveles podríamos hacer en el tiempo estimado, e ir avanzando trozo a trozo. En contrapunto al vertical slice tenemos el Horizontal Slice, que consiste en realizar todo el proyecto en la calidad mínima necesaria, e ir haciendo varias pasadas puliendo lo que se vaya encontrando. Cada una de estas planificaciones tiene sus pros y sus contras, dado que el horizontal slice da resultados vistosos muy tardíos, pero en el vertical slice puedes encontrar que al volver a ver la primera parte tal vez quedara un poco «verde» comparado con las últimas (con la experiencia se va mejorando).

Una vez acabado el diseño ampliado (nunca definitivo) los equipos de programación, sonido y arte funcionan a pleno rendimiento, guiados por lo diseñado, pero realizando los ajustes necesarios dadas las limitaciones del sistema (en caso de consolas es más notorio) o de los tiempos y el presupuesto, motivo por el cual el equipo de diseño nunca se aleja del juego, y prácticamente todos los juegos tarde o temprano ven recortada alguna característica que estaba pensada inicialmente. Eso no es del todo malo, si el juego triunfa podemos añadir esas partes eliminadas en una posible secuela.

Ya nos acercamos al final del desarrollo, los plazos aprietan, y el juego va puliendo los bugs que le quedan. En esta fase, el trabajo de los artistas suele estar acabado, y el gran trabajo recae en los programadores arreglando bugs, y en los diseñadores, sobre los que recae una tarea muy complicada, el balanceo del juego. En estas fases hay que tener testers tanto de bugs como gente lo más externa posible al juego que pueda servir de ejemplo dado que los propios desarrolladores están «contaminados» y no pueden ser objetivos.

Y hemos acabado el juego… ¿está todo? No. Queda el marketing. De nada te sirve hacer un buen juego si nadie lo conoce. Hay muchas teorías sobre cuándo es mejor empezar a «vender» tu juego. Lo mejor suele ser con bastante tiempo antes del lanzamiento, pero sin exceso, ya que la expectación se puede diluir con el tiempo a no ser que seas capaz de tener material para mantener el nivel de interés durante tanto tiempo. Y luego habrá que mantener un poco de publicidad durante y tras la salida del juego, e incluso intentar que, pasado el tiempo, vuelva a estar en boca de todos, por temas como una rebaja o los ahora conocidos bundles.

El coste, simplificado

Todo este proceso es más o menos costoso dependiendo del tamaño del equipo y del proyecto. Pero pongamos un equipo «medio» para la industria. O bueno, más bien pequeño, de unas 20 personas. Trabajando dos años en un juego que vaya a los mercados descargables. Con un salario…bueno, ni bajo ni alto, 20.000 euros al año de media en el equipo (en desarrollo es más bien bajo). Ya tenemos 20 empleados x 2 años x 20.000 euros al año…800.000 euros sólo gastados en personal. A eso hay que sumarle los gastos de oficinas, alguna cosa externalizada como el testing o la localización, costes de kits de desarrollo, ordenadores para esas 20 personas… superamos el millón de euros fácilmente. Sacamos el juego a 10€. Para recuperar la inversión habría que vender 100.000 unidades, cosa que no es tarea fácil, y a ese cálculo no se le han quitado impuestos o las tasas a las plataformas de distribución, con lo que necesitamos más ventas. Pero no sólo nos interesa recuperar la inversión… supongo que el interés es obtener la cantidad suficiente como para poder afrontar el próximo proyecto.

Caray, qué complicado es esto…y seguro que hasta me dejo cosas en el tintero. Como se suele decir ¿quién me mandaba meterme en obras?