Índice
Os dejo un artículo bastante interesante, aunque viene a decir lo que todos sabemos y Nintendo y los usuarios se pasan por el fooro porque viven en su burbuja.
En resumen: Consola pequeña como Wii para que la madre de turno la deje en el salón, difícil de programar, Nintendo suda de los problemas que tienen las thirds, online de mierda porque no tienen ni idea de como son Live y PSN, thirds sudando de Nintendo para centrarse en la next gen, PS4 abofeteando a Nintendo desde su anuncio, Nintendo no tiene ni puta idea de programar en HD y se come todos los problemas que pasaron los japos cuando salieron PS3-360.
Lo pongo en secreto porque es bastante largo.
En resumen: Consola pequeña como Wii para que la madre de turno la deje en el salón, difícil de programar, Nintendo suda de los problemas que tienen las thirds, online de mierda porque no tienen ni idea de como son Live y PSN, thirds sudando de Nintendo para centrarse en la next gen, PS4 abofeteando a Nintendo desde su anuncio, Nintendo no tiene ni puta idea de programar en HD y se come todos los problemas que pasaron los japos cuando salieron PS3-360.
Lo pongo en secreto porque es bastante largo.
Los Desarrolladores Secretos: Wii U - La historia desde adentro
- Spoiler:
creadores de juegos vienen a hablar con nosotros - y contigo - sobre temas que les
apasionan, o en el caso de este artículo, para dar a conocer la historia interna sobre
un tema particularmente controvertido. Dado que el futuro de Wii U parece incierto
viendo los lanzamientos exitosos de Xbox One y PlayStation 4, este relato "al desnudo"
de un respetado creador third-party te puede dar alguna idea de cómo Nintendo manejó la
transición a la era del juego en alta definición, y los desafíos que los desarrolladores
enfrentaron para llevar sus juegos a la plataforma Wii U.
Yo estaba allí cuando Nintendo mostró por primera vez la Wii U a los desarrolladores,
trabajé con el hardware extensamente y ayudé a producir uno de los mejores títulos third-
party. Ahora, como el destino del hardware parece incierto tras unas segundas navidades
de ventas decepcionantes, quise contar la historia de lo que era realmente trabajar con
la consola, y con Nintendo, y tal vez darle un contexto a la situación de la máquina y
los juegos third-party.
Pero primero, volvamos al principio. El nacimiento de una nueva videoconsola generalmente
sigue un patrón estándar. Al principio hay un prolongado proceso de investigación y
desarrollo internamente por parte del fabricante donde las metas y el diseño del hardware
son bosquejadas. Luego pasan por un proceso de refinamiento con los fabricantes de las
partes de hardware, basado en su tecnología y, obviamente, en su costo.
Una vez que el diseño básico del hardware ha sido decidido, los equipos de software
interno (SDK) comienzan a escribir los primeros códigos/drivers y pruebas que son
necesarias para hacer funcionar el hardware. Una vez que los equipos estan contentos con
el hardware, costos y plazos, las compañias van y hablan con los desarrolladores sobre el
nuevo hardware.
Para empezar se recopilan opiniones de desarrolladores first-party que pueden, o no,
afectar al diseño del hardware. EN este punto el diseño del hardware puede ser cambiado,
pero el márgen de maniobra se va haciendo más pequeño. Los fabricantes de las partes de
hardware tienen que montar sus líneas de producción para fabricar el silicio, lo cual
lleva tiempo.
Después de los diálogos iniciales, el estudio comienza a hacer "tours", hablando con
selectos editores third party, los Ubisoft, Take-Two y EAs del mundo, a los que los dueños
de la plataforma tienen que convencer para desarrollar juegos en sus consolas. Sin juegos,
y los ingresos que generan, la consola pronto empieza a perder dinero, convirtiéndose en
un lazo sobre el cuello del fabricante.
Grandes cambios son raros en este punto, a menos que sean cosas que se puedan cambiar
mediante software (frecuencias de reloj, mejoras en el sistema operativo, etc.) o que
puedan ser "fácilmente" añadidos al diseño del hardware, por ejemplo cambiar los módulos
de memoria por otros de mayor capacidad.
Aquí es donde yo entro.
Wii U comenzó su vida como Project Cafe, una máquina mostrada a los desarrolladores como
una máquina con un consumo eficiente que se podía colocar discretamente en el salón de
estar.
El revuelo del anuncio y lo que sigue
Cuando me dijeron que Nintendo había venido a la oficina para una reunión yo ya tenía una
idea de lo que iban a decir. Habían rumores circulando sobre un nuevo hardware, pero no se
había dicho nada concreto. Después de firmar varios NDAs nos reunimos en un cuarto para
escuchar la presentación.
Empezó de la manera usual con una retrospectiva sobre el éxito de Wii y sus intenciones
para el nuevo hardware. Querían una consola que fuese del mismo tamaño que Wii y que no
hiciese mucho ruido, para que "mamá no pusiese pegas para dejarla en el salón de estar".
Fue durante esta afirmación que unas campanas de alarma tenues comenzaron a tintinear en mi
cabeza, pero las ignoré y seguí viendo la presentación. La dirección cambió al ya conocido
"necesitamos ayuda para que Wii U sea un éxito y vosotros podéis ayudarnos en este
proyecto". Estas palabras terminaron teniendo un significado mayor del que nosotros o los
presentadores podíamos haber imaginado.
Luego el nuevo controlador fue mostrado en forma de maqueta, junto con un video mostrando
como podía ser usado en juegos mediante mock-ups, los cuales parecían interesantes. En este
punto todos estábamos imaginando cómo podríamos utlizar el controlador en nuestros juegos.
Pero entonces revelaron los detalles internos de la consola y y me dí cuenta del por qué
habían sonado mis camapanas de alarma al principio. Si Nintendo quería que el hardware
tuviese un tamaño pequeño y fuese silencioso, necesitaban minimizar el ruido de los
ventiladores, lo cual implica que la refrigeración es limitada, lo cual a su vez significa
que la CPU tiene que producir cantidades mínimas de calor, lo cual significa que la
frecuencia de reloj tiene que ser baja. Aunque no puedo confirmar detalles específicos, la
opinión colectiva de Internet está presentada en Wikipedia como referencia.
Un básico cálculo/comparación hace que Wii U parezca, al menos sobre el papel,
significativamente más lenta que una Xbox 360 en términos de procesamiento de CPU. Este
punto fue señalado en la reunión, pero los representantes de Nintendo los desestimaron
diciendo que "el bajo consumo de energía era más importante para los objetivos del diseño"
y que "otras características de la CPU podrían mejorar el rendimiento por encima de los
números puros".
"Casi inmediatamente después del anuncio los correos electrónicos comenzaron a volar
preguntando sobre la opinión de la gente con respecto al diseño y especificaciones de la
nueva consola. La respuesta casi universal fue, 'me gusta el nuevo controlador, pero la
CPU tiene poca potencia.'"
Al pasar las semanas la gente comenzó a hacer otros cálculos tratando de adivinar el
rendimiento que tendría la máquina - no olvides que esto es mucho antes que los dev-kits
estuviesen disponibles para hacer pruebas reales. Algunos incluso construían cajas de PC
con procesadores rebajados para probar y medir el rendimiento de su código en esas
máquinas. De nuevo,la respuesta casi universal fue que no iba a tener suficiente potencia
para correr los motores next-gen y podría incluso tener problemas con juegos de actual
generación (PS3 y X360). Pero a pesar de estas pruebas la administración tomó la decisión,
por varias razones de negocios, desarrollar un juego para Wii U. Así que tuvimos que
plegarnos a ello y tratar de hacer un juego.
Y así, a trabajar
Poco después que la decisión fue tomada los kits de desarrollo comenzaron a llegar. Como
es común en hardware preliminar su tamaño era más grande que el diseño final con
conectores y puertos usados especifícamente para desarrollo. Así que los conectamos e instalamos
el último código de sistema, tratamos de hacer correr un simple juego del tipo "hello world",
lo cual resultó ser más difícil de lo que podíamos imaginar.
Habiendo trabajado con otras consolas, supongo que estábamos "malacostumbrados" a tener
herramientas maduras que se integraban perfectamente con nuesto entorno de desarrollo. Wii U
en cambio parecía estar tratando de hacer mas difícil cada vez el compilar y correr
cualquier código. Nintendo ha integrado sus herramientas de desarrollo en Visual Studio
- el estándar de facto para el desarrollo - pero no era funcional, ni de lejos. Entonces
tuvimos que gastar tiempo en arreglar esto, mientras reportábamos el problema a Nintendo.
Eventualmente recibimos una solución de Nintendo por medio de otra compañía third-party
que tambien estaba tratando de arreglar este problema desde hace algún tiempo.
Ahora podíamos visualizar el código en Visual Studio y compilarlo, lo cual es bueno, pero
el proceso de compilación era realmente lento, incluso para cambios menores. Luego tuvimos
que hacer el proceso de enlace, durante el cual podías alegremente levantarte, prepararte
un café, charlar un rato y volver a tu escritorio antes que el enlace estuviese completo.
Calculamos el tiempo para el enlace en varios (cuatro o más) minutos en Wii U comparados
con alrededor de un minuto en otras plataformas.
Esto no suena mal, pero cuando estás depurando y haciendo montones de cambios, estos
tiempos adicionales se añaden. Si haces 10 cambios a un archivo una mañana, podrías
pasarte más de 50 minutos esperando a que el enlazador termine, lo cual es un montón de
tiempo perdido.
Finalmente, cuando ya tenías el código, lo enviabas a la consola y arrancabas el
depurador, el cual era parte de las herramientas que Nintendo había licenciado de Green
Hills Software. Como desarrolador veterano estoy acostumbrado a usar todo tipo de
depuradores, pero este me sorprendió incluso a mí. SU interfaz era torpe, era muy lento de
usar y si cometías el error de clickear en algún código, se paraba y buscaba todos los
valores para las variables que habías clickeado, lo cual podía tomar un minuto o más para
volver a ser manejable.
Todas estas cosas hicieron el desarrollo del código más difícil de lo que debería haber
sido y consumía el tiempo de desarrollo del juego. Como equipo, perdimos días de tiempo en
compilar/enlazar/depurar y esto impactó negativamente en muchas funcionalidades que
podríamos haber puesto en nuestro juego antes de la fecha de salida.
Otro detalle curioso a destacar en este punto fue que en el transcurso de seis meses
recibimos múltiples kits de desarrollo distintos en una variedad de colores, ninguno de
los cuales mostraba en qué eran diferentes de los anteriores. Sabíamos que habían algunos
bugs de hardware que estaban siendo arreglados, pero las notas informativas rara vez
decían lo que se había cambiado - teníamos que coger los nuevos y hacerlos funcionar con
nuestro código otra vez, consumiendo valioso tiempo de desarrollo. Hubieron algunos
rumores interesantes circulando acerca de cajas de desarrollo estilo PC, e incluso de
tarjetas gráficas Radeon HD 4850 (con reducciones en la frecuencia de reloj) utilizadas
como sustitutos para la GPU de Wii U. Nosotros trabajamos con Wii U desde los primeros
días y nunca vimos equipos como ese, nuestros kits siempre tenían la forma de hardware
personalizado que imagino estaba basado en el modelo casi final.
Trabajando con Wii U
Ahora que teníamos el juego corriendo en la consola podíamos comenzar a desarrollar
características que podrían utilizar el nuevo controlador y hacer sobresalir a nuestro
juego en la plataforma. Pero pronto surgieron algunos problemas que la (mínima)
documentación no cubría, por lo que consultamos a nuestro equipo de soporte local de
Nintendo . Ellos no conocían la respuesta así que nos dijeron que preguntarían a los
desarrolladores en Japón y que esperásemos la respuesta. Y esperamos. Y esperamos.
Tras una semana de idas y venidas el equipo de soporte nos dijo que habían recibido una
respuesta de Japón, la cual nos enviaron. La respuesta estaba en forma de unas oraciones
en un inglés pésimo que no respondían la pregunta que habíamos hecho en primer lugar. Así
que volvimos para pedir una aclaración, la cual se tardó otra semana en ser respondida.
Después del segundo retraso preguntamos por qué se tardaban tanto para responder desde
Japón, ¿estaban muy ocupados? El equipo de soporte local dijo que no, es sólo que las
preguntas tenían que ser enviadas a otro lugar para ser traducidas al japonés, luego se
enviaban a los desarrolladores, quienes respondían y entonces las respuestas eran
traducidas de nuevo al inglés y envíadas de vuelta a nosotros. Con las diferencias en la
zona horaria y el retraso por la traducción, esto usualmente tomaba ¡una semana!
Conseguir que el juego corra a su frame rate planeado fue la parte del proceso de
desarrollo menos intereante en este contexto ya que sigue los patrones estándar. Hacer
funcionar el juego, optimizar el código (CPU y GPU) y si aún no rinde bien, recortar hasta
que encaje.
Por el lado de las optimizaciones de CPU, tuvimos que recortar algunas cosas debido a que
la CPU no era suficientemente potente. Como temíamos al principio, tratar de ejecutar un
juego detallado corriendo en HD exigía mucho a las CPUs y no pudimos hacer tanto como nos
habría gustado. Recortar algunas características era la manera fácil, pero repercutía en
todo el conjunto del juego. El código optimizado para los procesadores Power PC de Xbox
360 y PlayStation 3 no era siempre adecuado para la CPU de Wii U, y aunque el chip tenía
algunas características interesantes que le permitían golpear por encima de su peso, no
podíamos aprovecharlas completamente. Sin embargo, algunos procesos podían ver mejoras
sustanciales - un incremento cercano a 4x debido a la ausencia de Load-Hit-Stores, y mayor
IPC (instrucciones por ciclo) gracias a la ejecución out-of-order.
Por el lado de la GPU, ocurría lo contrario. La GPU demostró ser muy capaz y terminamos
añadiendo detalles adicionales ya que la GPU tenía capacidad para manejarlo. Incluso se
discutió la posibilidad de usar la GPU via compute shaders (GPGPU) para liberar de trabajo
a la CPU - exactamente la manera que yo esperaba que funcionasen las consolas next-gen -
pero con un tiempo de desarrollo muy limitado y sin ejemplos ni ayuda por parte de
Nintendo, no nos arriesgamos a hacerlo. Si hubiésemos tenido un equipo de desarrollo más
grande o plazos más flexibles, tal vez lo hubiésemos intentado, aunque viéndolo ahora
quizás habria sido demasiado para esa GPU. La GPU es mejor que las de PS3 o Xbox 360, pero
jugaba en una liga muy inferior con respecto al hardware gráfico de PS4 o Xbox One.
Tambien hemos visto algo de preocupación acerca del uso de la RAM DDR3 en Wii U, y su
deficiencia en ancho de banda con respecto a PS3 y Xbox 360. Esto no fue realmente un
problema para nosotros. La GPU podía recibir datos rápidamente con caídas mínimas (via EDRAM)
y podíamos precargar eficientemente permitiendo a la GPU funcionar a su máxima capacidad.
Nintendo vs. juego en línea
Ahora que el juego va tomando forma y los problemas de hardware están siendo resueltos
nuestra atención pasó al lado de la conectividad de nuestro juego y su interfaz para la
recientemente anunciada Nintendo Network. Descubrimos pronto lo que parecían ser vacíos en
la documentación, y el código, en el tema de redes, así que pedimos una aclaración. Tras
el usual retraso por la traducción nos respondieron que aún estaban trabajando en el
código, pero que no nos preocupásemos ya que nos lo iban a enviar pronto.
Las campanas de alarma comenzaron a sonar de nuevo en mi cabeza, pero las ignoré por el
momento. Esta es la nueva infraestructura de red de Nintendo en la que va a estar basada
su nueva consola, tienen que asegurarse de que esté completa y completamente probada antes
de compartirla, así que se les podía perdonar un poco de retraso. Teníamos lo básico así
que al menos podíamos hacer algunas pruebas e interconectar varios kits, pero faltaba
mucho del contenido relacionado con los Mii y amigos y no había manera de probar cómo se
comportaría nustro código en un "entorno final" ya que no había "firmware" final para los
kits de desarrollo. Teníamos que hacer nuestro código a ciegas y esperar que funcionase.
Por este tiempo tuvimos la oportunidad de charlar con un personaje importante de Nintendo,
via conferencia telefónica, ya que estaban recopilando opiniones sobre nuestras
experiencias con el desarrollo y sus herramientas. Esta conversación nos permitió conocer
más a Nintendo y la manera en que parece operar.
La discusión comenzó bien y hablábamos sobre nuestras experiencias y las (lentas)
herramientas, entonces preguntamos sobre cuándo podrían estar disponibles las funciones
online. Nos dijeron que esas funcionalidades, y las actualizaciones en el SO para
soportarlas, estarían disponibles antes del lanzamiento de la consola, pero apenas.
Aparentemente habían problemas para montar una gran infraestructura de red a la altura de
Sony y Microsoft que ellos no habían previsto.
Nos sorprendió escuchar esto, ya que pensábamos que habían tenido mucho tiempo para
trabajar en estas funcionalidades ya que habían sido anunciadas varios meses antes, así
que fuimos un poco más allá y preguntamos acerca de la manera en que ciertos escenarios
podrían funcionar con los Mii amigos y el entorno de red, todo el tiempo utilizando
referencias sobre cómo Xbox Live y PSN hacían lo mismo. En algún punto de esta
conversación nos informaron que no era conveniente utilizar referencias sobre Live y PSN
ya que nadie en sus equipos de desarrollo había probado estos sistemas (!) y que les
explicásemos con más detalle nuestras consultas. Mi único pensamiento tras esta llamada
era que ellos estaban en un aprieto - serio - con el tema de la conectividad mucho más
complicado de lo que esperaban. Estaban tratando de alcanzar a los sistemas rivales, pero
sin los años de experiencia en que apoyarse.
Como prometieron, (apenas) antes del lanzamiento mundial recibimos las funciones de red
finales que pedimos para nuestro juego junto con una actualización del SO para los kits de
desarrollo que nos permitirían probarlo. Así que parchamos nuestro código y tratamos de
comenzar a probar nuestro juego.
Primero tuvimos que flashear los kits en modo "retail" que tenían las funciones de red y
de los Mii. Esto se hacía por medio de un proceso manual muy complicado que dejaba a las
consolas en un estado intermedio. En el modo retail podíamos probar nuestras
funcionalidades y asegurarnos que funcionasen como debían, lo cual es un requisito para
cumplir con la certificación de Nintendo, pero en este modo las capacidades de depuración
estaban limitadas. Por lo que podíamos ver cuando las cosas estaban mal, pero no podíamos
depurar completamente para encontrar el por qué. Como desarrolladores, tuvimos que hacer
una elección y esperar que los problemas que encontrabas fueran debido al código (sin
finalizar) del SO y no ocurriría en las consolas finales. Lo que deberían haber sido
tareas sencillas se hacáin lentas y propensas a errores. Cosas simples como enviar una
solicitud de amistad a otro usuario no estaban soportadas por el SO, por lo que tenáis que
iniciar un programa separado en la consola manualmente, a través de un menú de depuración,
para poder enviarla. Pero si ocurría un error no había manera de depurar por qué había
fallado, simplemente fallaba.
Comenzamos a preguntarnos cómo podrían lanzar la consola -faltaban unas pocas semanas- con
un SO parcialmente desarrollado. ¿Como iban a poner el SO en todas las consolas que habían
sido fabricadas hasta el momento? ¿Nosotros lo habíamos recibido tarde, pero ellos ya lo
tenían en su línea de producción desde antes?
El día de lanzamiento llegó y la respuesta se hizo clara: Nintendo estaba retrasada - muy
retrasada - con sus sistemas de red. De hecho, la única manera de acceder a sus sistemas
completamente era descargar un gran parche en el primer día que añadía todos estos
componentes faltantes. Sin ese parche muchos juegos de lanzamiento solamente funcionarían
a medias.
¿Qué ocurrió luego?
Bueno, eventualmente lanzamos nuestro juego y fue en general bien recibido, así que la
administración esperó las proyecciones de ventas que podríamos conseguir por todos
nuestros esfuerzos. Sin entrar en detalles digamos que los números que obtuvimos no eran
impresionantes. De hecho podíamos considerarnos afortunados por recuperar el dinero que
invertimos en la creación del juego en primer lugar, y aunque la administración apoyaba
públicamente la plataforma Wii U, era poco probable que hiciésemos otro juego para Wii U.
¿Pero qué hay del resto del mundo? ¿Cómo les fue a otros estudios de desarrollo? La historia
de lo que ocurrió a continuación está bien documentada en la prensa del sector, pero me
gustaría resaltar algunos puntos interesantes que estuve pensando recientemente. Primero,
el apoyo third-party. ¿Recuerdas toda la expectación sobre el lanzamiento de Wii U? ¿Todas
esas third parties mostrando videos de juegos que iban a llevar a Wii U? ¿Qué ocurrió con
muchos de esos juegos?
Después de la avalancha inicial de juegos muchos de los estudios retiraron silenciosamente
sus declaraciones iniciales y anunciaron, con poca cobertura de la prensa, que no iban a
hacer versiones para Wii U. Las razones tras un particular juego que no sale en Wii U son
pura especulación, pero personalmente creo que es una combinación de:
Previa experiencia de desarrollo con las herramientas y el hardware desanimaron a los
equipos de desarrollo para hacer otro título en Wii U.
El soporte técnico y de funcionalidades por parte de Nintendo era escasio para los
estudios third party. Había la sensación de que si no eras un estudio first-party, serías
ignorado por Nintendo, como si fuésemos superficiales para sus beneficios. Los juegos
desarrollados internamente salvarían a Nintendo y nosotros estábamos ahí sólo para añadir
profundidad al catálogo.
Las proyecciones de ventas para Wii U no se veían muy bien poco después del lanzamiento.
Había mucha confusión entre el público general en el lanzamiento ya que mucha gente
pensaba que Wii U era algún tipo de accesorio para Wii, no sabían que era una nueva
consola. Esta falta de conocimiento probablemente contribuyó a que la consola no tuviese
el arranque que Nintendo esperaba y alejó a los estudios para desarrollar en ese hardware.
Nintendo tambien fue afectada por un mal cálculo. Pocos meses después del lanzamiento las
expectativas por la next-gen comenzaron cuando Sony anunció su PlayStation 4, con
Microsoft uniéndose a la lucha pocos meses después. No olvidemos que muchos de los
estudios más grandes ya sabían del hardware meses antes de que fuera anunciado,
incluso antes del lanzamiento de Wii U.
Así, estos estudios grandes tenían que elegir. ¿Harían un port de un juego existente a una
consola con capacidades limitadas y limitada penetración en el mercado? ¿O pondrían a sus
equipos a trabajar en desarrollar nuevas funcionalidades y conceptos para las "verdaderas"
consolas next-gen que serían lanzadas ese año? Cuando lo ves de esta manera la elección no
es difícil.
Desde una perspectiva first-party, parece que para la propia Nintendo las cosas no fueron
fáciles. Esto es pura especulación, pero de nuestra interacción con los equipos de
desarrollo parece que los propios equipos de Nintendo tenían auténticos problemas para
adaptarse a la nueva consola - la principal razón fue el paso a la HD y la capacidad del
hardware para soportarlo. No olvidar que hasta la salida de Wii U, ninguno de los juegos
first-party estaban en HD y el cambio de SD a HD no es tan fácil como se podría pensar.
Los desarrolladores de PS3 y Xbox 360 pasaron por estas dificultades al principio del
ciclo de las anteriores consolas y les costó mucho tiempo y dinero tratar de adaptarse,
con algunos estudios fallando estrepitosamente.
Los equipos internos de Nintendo ahora enfrentan este reto en una nueva consola con
limitado tiempo de desarrollo y mucha presión para producir títulos atractivos.
Con esta presión sobre ellos era inevitable que algunos de los títulos de alto perfil
se retrasasen, pero sorprende lo escueto que ha sido el catálogo first-party el año
pasado.
