Destripando la industria, vol. 2

De igual forma que hice hace un año, voy a dedicar esta sección a recopilar dudas y sugerencias en los comentarios de los posts del programa y en el foro de Eurogamer.

Grimbergen_Beer nos comentaba: “cuanto más realista es un juego, menos me gusta. Del último de Quantic Dream [Heavy Rain] me desagradan las caras muchísimo”.

Eso que le ocurre a nuestro amigo no es cosa suya o cuestión de gustos. Hay un concepto en robótica (que también se aplica para 3D) llamado Uncanney Valley (o Valle Inquietante).

Cuando un robot no parece para nada humano - por ejemplo, Wall-E -, nuestro cerebro encuentra los parecidos más humanos y nos parece adorable. En cambio, cuando un modelo 3D es muy humano pero sin llegar a serlo, como en Heavy Rain, lo que percibimos son los defectos. Nuestro cerebro se da cuenta que algo no está bien y, por tanto, lo rechaza. En la mayoría de juegos modernos los problemas están en la animación o las expresiones faciales.

En el artículo sobre el multijugador, Topo_13 comentaba: “No has hablado de los casos contrarios: aquellos juegos únicamente orientados al multiplayer, pero que las editoras les obligan a incluir campaña de un jugador. Por ejemplo, Battlefield 3”.

Los juegos 100% multijugador, por mucho que nos gusten y que en PC existan casos de éxito, en consola todavía no han conseguido introducirse del todo. No es tanto que las editoras “obliguen” a incluir una campaña de un jugador, sino que un proyecto exclusivamente multijugador es difícil que consiga alguien que lo financie.

Además, tener una campaña para un jugador tiene ciertas ventajas para el desarrollo. Por ejemplo: como normalmente se pueden introducir situaciones más espectaculares es un buen recurso para el departamento de marketing, que puede sacar del single player muy buenas screenshots y trailers. Además, es un modo que facilita muchísimo enseñar el juego, ya que no necesitas organizar un grupo de gente “que rellene”.

Don_Kik0n pedía una sección sobre los contratos de confidencialidad y los devkits.

Los contratos de confidencialidad son una norma en la industria: básicamente, los desarrolladores se comprometen a no revelar nada sobre su trabajo. Este tipo de acuerdos es especialmente importante cuando la empresa trabaja con hardware o software de terceros. En estos casos el propietario del hardware no te lo cede a menos que estés dispuesto a firmar un NDA (non-disclosure agreement, o acuerdo de confidencialidad) y no revelar nada sobre estos kits/SDKs.

De hecho, algunos motores o librerías (por ejemplo Unity) soportan SDKs de consolas pero, para obtener la versión con el codigo de consola tienes que contactar con ellos. Esto es necesario porque el NDA también cubre las cabeceras de esta librería y no se puede distribuir nada de código a nadie que no esté bajo el NDA. Esto también pasa con los SDK beta de Apple y, por eso, solo puedes preguntar por características nuevas en los foros oficiales.

En cuanto a los devkits, pues no tienen demasiada magia. Suelen ir evolucionando según la consola va madurando. Los primeros devkits suelen ser prototipos que parecen “hechos a mano” y, una vez la consola esta terminada, cada vez se parecen más al modelo comercial. Los que he visto suelen ser iguales a las consolas que tenemos en casa, pero con otro firmware, un disco duro enorme y una conexión red. Lo importante es que tienen la posibilidad de conectar un PC y “depurar” el código del juego. A parte de los devkit, tienes las más conocidas consolas “debug” que son consolas normales con la salvedad que permiten ejecutar código “sin firmar” que se usan para control de calidad o para que los medios puedan hacer reviews antes de la salida del juego.

Reaversword preguntaba: “¿cómo es posible hacer un trabajo sensacional [como Vampire: Bloodlines o Blade] y que quiebre la empresa?”

Aprovecho esta pregunta para recordar que, de cara a quien toma las decisiones en la industria, el éxito de un videojuego no se mide en Metacritic (aunque pueda parecerlo), ni en la cantidad de seguidores que tiene el juego diez años después, sino en rentabilidad.

Aunque los dos títulos que comenta Reaversword tienen un pequeño grupo de fans fieles y, quizás, hasta recibieron buenas críticas, también ha ido a dar con dos desarrollos bastante largos. Si un juego tarda en desarrollarse tantos años necesita vender bastante para recuperar la inversión y en ninguno de estos dos casos, estamos hablando de un juego que fuese superventas.

Relacionado con la anterior, Roldán García (‏@Alcarendor) pregunta cómo se calculan los tiempos de desarrollo y el presupuesto que se necesita para un juego.

Aunque la planificación de un proyecto parece sencilla en teoría, en la práctica calcular los tiempos y los costes es todo un arte. Los tiempos se suelen estimar haciendo uso de los conocimiento o experiencia (lo que los ingleses llaman know-how) del desarrollador o extrapolándolos de anteriores proyectos. Estos últimos suelen ser los más fiables, ya que pueden tener en cuenta no solo lo que estimaste inicialmente, sino también todos los problemas con los que te encontraste.

Una vez tienes una lista de cuánto te cuesta hacer cada característica del juego, se obtiene el coste viendo durante cuántos meses tienes que tener contratado (y cuanto cobra) cada desarrollador y sumarle los extras como el coste de oficina, los ordenadores, las licencias del software, etc.

De todas formas, aunque tengamos un proyecto con una idea inicial consigamos financiar nuestra idea, lo normal es que cuando se elabora un proyecto se vaya recortando la idea inicial para hacerla entrar en el dinero que la editora está dispuesta a pagar. Esto puede significar quitar totalmente características o niveles, o reducir la complejidad del juego. Por ejemplo; en vez de permitir salvar en cualquier momento, podríamos meter un sistema de checkpoints que es más sencillo de implementar y testear.

Hay que tener en cuenta que muchas veces estos presupuestos son “abiertos” y se suele ir recortando y renegociando el alcance y características del proyecto según se va avanzando. La editora no siempre dispone del líquido suficiente como para ir adelantando dinero antes de ver beneficios y, si contaba con empezar a recibir ingresos en seis meses, prefiere cerrar lo que tenga y recuperar el dinero a seguir arriesgando dinero que, quizás, no recupere (a pesar que el juego tenga mejor calidad).

Jorge Garcia (‏@Bitarin) pregunta: ¿a qué viene ese complot por restringir los juegos de PC a las tarjetas gráficas de última hornada? Por ejemplo Crisys 3, que sólo funciona en DirectX 11.

En la mayoría de casos no estamos hablando de una conspiración o de que la gente de NVIDIA o AMD tenga untados a Crytek. Es cierto que Crysis 3 “técnicamente” puede funcionar en DX9 (al menos la versión de consola), pero la gente de Crytek habrá considerado que la gama de tarjetas DX9 capaces de ejecutar Crysis 3 no compensa el coste de soporte.

Imitar los efectos de Crysis 3 en DX9 es factible, pero muy posiblemente requiera bastantes trucos. Hacer que estos trucos funcionen en toda la gama de tarjetas DX9 posiblemente represente más trabajo del que las ventas que pueda sufragar. Si en Crytek no han elaborado un parche a DX9 seguramente es porque ya no les interesa ese mercado. Esta decisión, aunque no sea popular, puede llegar a tener sentido a nivel de negocio si tenemos en cuenta que sus juegos requieren un equipo potente y con casi total seguridad la gráfica de un equipo así va a soportar DX11, que hace bastante tiempo que esta disponible (desde la salida de Windows 7).

Deka Black (‏@TokuDeka) pregunta: ¿cómo ha de adaptarse el guión de un juego a las mecánicas en sí?

Pues esta es una de las quejas de los escritores que han trabajado en videojuegos, como Rhianna Pratchett. En muchas ocasiones se quejan que no tienen una participación directa en el guión del juego, sino que les dicen: “Aquí hay una fábrica, luego hay un jefe de hielo y vas a una nave espacial y acabas en la luna luchando contra un crocopulpo.” Y, claro, luego buscate una forma de justificar todo eso y, además, todas las cosas que tenemos asumidas en un juego como, por ejemplo, que un personaje que era una máquina de matar en el juego anterior tenga que empezar desde cero en esta entrega. Escribir para videojuegos, desde luego, no es una labor fácil y requiere dominar bien tanto la técnica del guión como un amplio conocimiento del medio.

Luego entraríamos en cómo se “adapta” un guión escrito en Final Draft, como si fuera un guión de cine, al videojuego que te llega a la consola. Para hacer eso, el diseñador del juego suele pedirle a los programadores que le implementen las herramientas para introducir narrativas: scripts, conversaciones o cutscenes. Cuando montas el nivel, introduces esos elementos dentro de tu “nivel de fábrica” y haces que los NPC te vayan diciendo cosas o que te salte una cutscene molona y, así, piececita a piececita vas montando todo el juego.

Hecan pregunta: ¿existen IA's estándar que puedan ser adaptadas a juegos parecidos o se deben crear desde cero para cada juego? Y, en caso de que existan, ¿se venden sistemas completos o parciales de IA's?

Como comenté en la sección de la inteligencia artificial, existen middlewares de IA pero, normalmente, no te resuelven toda la IA de un juego sino que te facilitan el trabajo de montarte tu IA como tampoco un motor gráfico te soluciona toda la parte de gráficos 3D del juego. Los productos con más éxito que hay en el mercado son los motores de pathfinding que te solucionan el mover los agentes por el mapa.

También se han llegado a desarrollar middleware para diseñar de forma “visual” máquinas de estado o sistemas de aprendizaje (de estos había uno bastante popular para el reconocimiento de patrones, AiLive, que se usa en temas de Wiimote y Move), pero no han tenido el éxito de los anteriores.

Seguramente porque si una IA se te queda enganchada en el mapa se ve muy cutre y es un problema bastante complejo de resolver, mientras que con una máquina de estado bastante sencillita consigues un resultado la mar de aparente. Y, si no, que se lo expliquen a FEAR, del que había artículos enteros sobre su IA y no le sirvió para vender más.

CucuFaiter pregunta: ¿tan caro le cuesta a una compañía hacer una actualización o sacar ya directamente un juego que soporte todas las resoluciones del mercado?

Los juegos antiguos se programaron pensando en los modos de video VGA o SVGA como estándar. Con la llegada del DirectX, la cantidad de resoluciones se incrementó bastante pero si, es factible pedirle a Windows que resoluciones soporta el monitor/gráfica y exponer todas esas resoluciones. De hecho, la mayoría de los juegos lo hacen así. En muchos casos, especialmente en ports a PC de juegos de consola, como no tienen menú dentro del juego para seleccionar resoluciones lo que hacen es que el juego configura las opciones que solo están en PC “desde fuera” con un pequeño programa externo (esto lo hace, por ejemplo, Skyrim).

El mayor coste para soportar resoluciones es hacer que el juego se adapte sus elementos a múltiples resoluciones. Hay muchas opciones como “estirar” todos los elementos, pero en ese caso tienes el problema de la relación de aspecto (el 4:3, 16:9, 21:9). Si un juego 4:3 lo estiras a 16:9 vas a ver los elementos 2D estirados horizontalmente. Una solución para esto es diseñar todo el interfaz para que no se estire, sino que los elementos se coloquen anclados a puntos de la pantalla (el minimapa en la esquina inferior derecha, el menú en el centro) y, si la resolución es más grande, simplemente dejamos espacio en blanco.

También tienes que tener en cuenta que, además de las resoluciones que asumes como “lnormales”, tienes las configuraciones de múltiples monitores que tienen también sus problemáticas particulares. Si, por ejemplo, tenemos un sistema con 2 monitores, con bastante seguridad el jugador no quiere usar los 2 monitores centrados, sino que querría tener un monitor “principal” con la cámara centrada en ese lado (y el HUD solo en ese) uno secundario donde pueda mover ventanas de la interfaz (o ver las ayudas en un juego de conducción).