El caótico desarrollo de Starcraft y su cambio basado en una gigantesca mentira

Escrito por: Patrick Wyatt
Publicado por: Kotaku.com
Traducido por: IceDragon

Blizzard no es famosa por sus juegos, sino por el largo y considerado desarrollo del que hacen gala. Es uno de los pocos y privilegiados estudios en el mundo que puede decir «lanzaremos el juego cuando esté listo» y realmente cumplirlo. La agonizante espera que los fanáticos de Blizzard tienen que afrontar ante cada nuevo juego es una prueba de esto. No obstante, esa filosofía no vino de la noche a la mañana, sino que algo ocurrió en el medio para convencer a los directivos de Blizzard de que era exactamente eso lo que tenían que hacer. Y esa cosa fue el caótico desarrollo de Starcraft.

En este articulo, el antiguo ejecutivo de Blizzard Patrick Wyatt se atreve a recordar y detallar la auténtica montaña de problemas que la compañía tuvo que afrontar -y resolver, como está implícito- para que el juego fuera incluso jugable (ya ni hablar de un exitoso producto comercial).

El comienzo de Starcraft:

Durante el desarrollo del juego, pasaron dos años de sudar tinta, mas otro de arreglos antes de lanzamiento. El juego tenía mas agujeros que un nido de termitas. Mientras que sus antecesores (Warcraft I y II) fueron mas eficientes y confiables que sus «compañeros», Starcraft crasheaba tanto que era realmente difícil hacerle pruebas de juego, incluso hasta poco antes del lanzamiento... y el juego siguió requiriendo continuos parches hasta después del mismo.

Por qué? hubo muuuuuuuuuuuchas razones.

Orcos en el spacio:

Starcraft fue originalmente concebido como un juego de modestas metas que pudiese caber en tan solo un año de desarrollo, y estar listo para las navidades de 1996.

El liderazgo del proyecto fue comprometido por los mismos tontos que iniciaron Shattered Nations, y el juego de estrategia por turnos X-COM, que Blizzard anunció en mayo del 95, pero canceló algunos meses más tarde.

Los miembros del equipo fueron reagrupados para construir algo que pudiera llegar rápidamente a los anaqueles, de manera que Blizzard no tuviera un largo tiempo de inactividad entre lanzamientos.

Q4 1994 ----; Warcraft
Q4 1995 ----; Warcraft II
Q4 1996 ----; Fecha planeada para StarCraft
Q2 1998 ----; Verdadera fecha de StarCraft

La decisión de apresurar el proceso parece estúpida en retrospectiva, pero Allen Adham, el presidente de la compañía estaba bajo una gran presión para aumentar los ingresos. Mientras que los primeros juegos habían sido mucho mas exitosos de lo esperado, eso solo incrementó las expectativas para crecimiento futuro.

Dotados de un corto periodo de tiempo, y limitado personal, la meta del equipo de Starcraft fue la de implementar un juego simple, que pudiese ser descrito como «Orcos en el espacio». He aquí una imagen cercana a la E3 de 1996, que muestra el camino que el equipo de desarrollo originalmente tomó:

Starcraft como se veía durante la E3 en mayo de 1996. Si, yo tampoco lo jugaría.

Pero un producto de mayor prioridad eclipsó a Starcraft y «robó» a sus desarrolladores uno a uno. Diablo, un juego de rol que venía siendo ensamblado por Condor Studios en Redwood City, California, estaba en necesidad de recibir ayuda adicional. Condor, una compañía formada por Dave Brevik con Max Schaefer y su hermano Erich, recibió un presupuesto de solo $1.2 millones... ridículo incluso en aquellos tiempos.

El equipo de Condor no tenía esperanza alguna de hacer el juego que aspiraron a construir, pero hicieron un gran trabajo desarrollando algo innovador y divertido, lo cual hizo lógica su adquisición por parte de Blizzard, (renombrandola Blizzard North), y empezar a ponerle al juego todo el personal y dinero que merecía.

Inicialmente Collin Murray, (un programador de Starcraft) y yo volamos a Redwood City a ayudar, mientras que los otros desarrolladores en el «Cuartel General» de Blizzard en Irvine, California, trabajaron en proveedores de red para los juegos online a través de Battle.Net, además de las pantallas de interfaz (conocidas como «glue screens») que sirvieran para la creación de personajes, unirse a las partidas en curso, y otras tantas funciones.

Mientras Diablo crecía, eventualmente todo el mundo en el Cuartel General -artistas, programadores, diseñadores, ingenieros de sonido- trabajaron en el juego, hasta que no quedó nadie en Starcraft. Incluso el líder del proyecto fue desplazado para finalizar el instalador del juego, que yo mismo escribí, pero estaba muy ocupado para terminar.

Después del lanzamiento de Diablo, a fines de 1996, el desarrollo de Starcraft fue reiniciado, y todo el mundo tuvo oportunidad de ver hacía donde había sido dirigido el proyecto... y no era lindo. El juego lucía anticuado, y ni remotamente impresionante, particularmente comparado con proyectos como Dominion (de Ion Storm), quien había lucido genial en las demos de E3, seis meses antes.

El masivo éxito de Diablo reinició las expectativas acerca de como debía Blizzard invertir sus esfuerzos: Starcraft se convirtió en el titulo que definió la táctica de «no lanzar juegos hasta que estuviesen listos». Pero mucho dolor tuvo que ocurrir para probar esa estrategia.

Algo que probar:

Con todo mundo mirando críticamente a Starcraft, estaba claro que el proyecto necesitaba ser mucho mas ambicioso que nuestros esfuerzos previos en definir el futuro de los RTS con los dos primeros Warcrafts.

Al tiempo en que se reinició el proyecto, de acuerdo con el editor en jefe de Computer Gaming World -la revista especializada en videojuegos de mayor tirada de ese entonces-, Johnny Wilson, había mas de ochenta (80!) RTS en desarrollo al momento. Con muchos competidores de alto nivel pisando nuestros talones, incluyendo a Westwood Studios, la compañía que originó el estilo de RTS moderno. Necesitábamos algo que patease sus traseros.

Y como ya no eramos un empredimiento de bajo nivel, con los consecutivos éxitos de Diablo y Warcraft llenando las noticias, definitivamente no íbamos a recibir rechazo alguno de parte de los jugadores o la prensa especializada. En el mundo del videojuego, eres tan bueno como tu último juego. Necesitábamos ir mucho mas lejos que nunca, y eso requería tomar riesgos.

Nuevas Caras:

Warcraft II tenía solo seis programadores base y dos de apoyo, eso era demasiado poco para un juego de amplio espectro como Starcraft, así que el equipo de desarrollo creció para incluir una nueva camada de inexpertos programadores que necesitaban aprender como escribir código de videojuegos.

Nuestro liderazgo en esa área fue débil: no habíamos aprendido aún cuan esencial era el proveer guía a los trabajadores menos experimentados desde muy temprano en el proyecto, así que ellos aprendieron lecciones muy necesarias antes de que el juego fuese lanzado. Una gran parte del problema fue que cada programador estaba codeando como loco para alcanzar nuestras metas, pero sin tiempo para revisiones u entrenamiento.

Y no era solamente que hubiese jóvenes e inexperimentados miembros en el equipo, sino que el líder de los programadores nunca había creado un motor de juego tampoco. Bob Fitch había estado programando por varios años con grandes resultados en sus esfuerzos previos, donde trabajó dentro de un motor existente y programó funciones en Warcraft I y II, que no requerían un diseño a gran escala. Y mientras el tenía experiencia por su trabajo en Shattered Nations, ese proyecto fue cancelado, y por lo tanto ninguna validación de sus decisiones arquitectónicas fue posible.

El equipo estaba increíblemente investido en el proyecto, y puso grandes esfuerzos en completarlo, mientras sacrificaba salud personal y familiar. Nunca había visto un proyecto donde cada miembro trabajase tan fieramente. Pero varias decisiones clave de codeo, perseguirían al equipo programador por el resto del mismo.

Algunas cosas han cambiado:

Después de invertir meses trabajando para lanzar Diablo, y aún mas tiempo en ordenar el esfuerzo y parchear errores, retorné a ayudar con la puesta en marcha de Starcraft. No estaba con intenciones de meterme en otro bug-fest, pero fue eso exactamente lo que sucedió.

Pensé que sería fácil volver al proyecto porque conocía muy bien el código de Warcraft -trabajé literalmente en cada componente-. Pero en lugar de eso estaba aterrado de descubrir que muchos componentes habían sido desechados y otros parcialmente reescritos.

Las clases de unidades estaban en progreso de ser escritas desde cero, y el dispensador de las mismas había sido descartado. El dispensador es un mecanismo que creé para asegurar que cada unidad tuviera tiempo de planear lo que quisiese hacer. Cada una preguntaría periódicamente: «¿que debería hacer cuando termine mi actual labor», «¿debería revaluar el camino que estoy tomando?», «¿hay alguna mejor unidad para atacar en lugar de a la que le estoy apuntando?», «¿me diste una nueva orden?», «estoy muerto, ¿que debería hacer ahora?. Y así.

Hay buenas razones para reescribir un código, pero el viejo ya existente observa un riesgo también. Joel Spolsky ya lo dijo de manera mas elocuente en «cosas que no deberías hacer nunca, parte 1»:

"Es importante recordar que cuando empiezas algo desde los bocetos mismos, no hay absolutamente ninguna razón para creer que harás un mejor trabajo ahora del que hiciste la primera vez. Primero que nada, probablemente ni tengas al mismo equipo programador que trabajó en la primera versión, así que no tienes de hecho «mas experiencia». Estas a punto de cometer los mismos viejos errores otra vez, e introducir algunos nuevos que no hubo en la versión original.

El motor del Warcraft requirió meses de esfuerzo para salir bien, y mientas éste necesitó rehacerse para incluir nuevas características de juego, un nuevo -y fresco- equipo de programación iba a gastar una gran cantidad de tiempo en re-aprender la lección de como y porque un motor era arquitectónicamente de la manera en que era en primer lugar".

Arquitectura del motor:

Escribí el engine original del Warcraft para MS-DOS en C usando el Watcom Compiler. Con el cambio para relanzar producto en Windows, Bob eligió usar el Virtual Studio Compliler, y recrear el motor en C++. Ambas eran razonables opciones, pero por el hecho de que -a ese punto- pocos desarrolladores en el equipo tenían experiencia alguna con el lenguaje.

Aunque C++ tenía sus fortalezas, era aún sencillo infrautilizarlo. Como Bjarne Stroustrup, el creador del lenguaje, tan famosamente dijo: «C hace fácil el dispararte en el pie, en C++ es más difícil, pero cuando lo logras, vuela tu pierna entera».

La historia nos cuenta que los programadores se sintieron obligados a probar cada característica de su nuevo lenguaje durante el primer proyecto, de la misma manera que fue un caso inherente con Starcraft. Los programadores experimentados se estremecerían al ver la cadena de herencia que fue designada para las unidades.

Los objetos «CThingy» eran sprites que pudieran aparecer en cualquier lado del mapa, pero sin moverse ni tener comportamiento alguno, mientras que los «CFlingys» funcionaban para la creación de partículas; cuando una explosión ocurriese, muchas de ellas se disiparían en varias direcciones. «Cdoodad» -después de catorce años creo que ese era el nombre que le dimos- fue otra clase de instancia que sin embargo tuvo importantes compartimientos para el funcionamiento apropiado de las clases derivadas. Y las «CUnit» fueron colocadas por encima de ellas. El comportamiento de esas fue desparramado por varios módulos, y requirió un entendimiento completo de todas las clases para ser capaz de lograr algo.

Y mas allá del horror de la jerarquía de clases, la CUnit fue por si misma un abominable lío definido a través de múltiples headers.

{

#include "header_1.h"
#include "header_2.h"
#include "header_3.h"
#include "header_4.h"

};

Cada uno de esos headers estaba compuesto de cientos de lineas, que llevaban a una definición general de la clase misma, lo que podría ser llamado como mucho «divertido».

No fue hasta mucho tiempo después que el mantra «favorecer la composición sobre el resultado» ganó credibilidad entre los programadores, pero aquellos que trabajaron en Starcraft lo aprendieron de la manera difícil mucho antes.

A solo dos meses del lanzamiento:

Con todos los problemas anteriores, después del reinicio el equipo fue apresurado para finalizar como fuera el proyecto, así que los calendarios fueron intercambiados y marcados para que el juego pudiera salir en dos meses.

Dado el número de unidades y el comportamiento que debía serles añadido, los cambios necesarios para cambiar a vista isométrica, un nuevo editor de mapas, y la adición de un sistema multiplayer basado en Battle.net, era inconcebible que el juego pudiera salir en ese tiempo, incluso asumiendo que el equipo artístico, diseñadores, ingenieros de sonido, balanceadores y beta-testers pudieran finalizar su tramo del trabajo a tiempo... pero el equipo programador siguió trabajando para conseguir lanzar Starcraft en dos meses... ¡por los siguientes catorce!

El equipo entero trabajó largas horas, con Bob haciendo diagramas de cuarenta, cuarenta y dos e incluso cuarenta y ocho horas de programación ininterrumpida. Recuerdo que nadie más intentó esa clase de conductas masoquistas, aunque cada uno estaba poniéndole masivas y ridículas horas al proyecto.

Mi experiencia desarrollando Warcraft fue de frecuentes noches de codeo, y luego con Diablo donde trabajé un plus de catorce horas por día, siete días a la semana, y todas las semanas, sufriendo de aprender que no había ningún punto en todas las desveladas. Cualquier codeo hecho después de cierto punto, debía ser re entregado y reescrito a la luz de los siguiente días.

Trabajar todas esas horas hizo a la gente sentirse mareada, y eso es malo cuando tratas de lograr un conocimiento basado en tareas que requieren un exceso de creatividad, así que no debería sorprender a nadie el número de errores, defectos y bugs que cometimos.

Accidentalmente, ese horario demente que afrontamos no era obligatorio -fue algo que hicimos solo porque queríamos hacer grandes juegos. Tonto en retrospectiva-, podríamos haber hecho un mejor trabajo con esfuerzos mas razonables. Una de las hazañas de las que estoy mas orgulloso fue la de lanzar las campañas «Guild Wars» en dos años, sin dejar que el equipo de desarrollo tomase el mismo camino.

El más común de los crasheos:

Aunque implementé algunas características importantes en Starcraft, (incluyendo neblina y chat de voz), mi trabajo primario pasó a ser la eliminación de bugs.

Espera: chat de voz en 1998??!?: Si, lo tenía a punto para diciembre de 1997. Usé un compresor desarrollado externamente, escribí el código para enviar fonemas a través de la red, los descomprimí, y entonces pudieron ser reproducidos simultáneamente en las computadoras de siete jugadores.

Pero cada tarjeta de sonido en nuestras oficinas requirió una actualización del controlador para que funcionase, las placas debían incluso ser capaces de sonido full-duplex (grabación y reproducción simultánea), por lo que lamentablemente hice la recomendación de desechar la idea. La carga de soporte técnico habría sido tan alta que nos hubiéramos gastado más dinero en eso de lo que hubiéramos hecho en vender el juego.

De cualquier manera arreglé un montón de bugs. Algunos míos claro, pero la mayoría escritos por otros cansados programadores. Uno de los mejores cumplidos que he recibido llegó solo unos meses atrás, cuando Brian Fitzgerald, uno de los dos mejores programadores con los que he trabajado, mencionó una revisión del código de Stacraft; estaban impactados acerca de la cantidad de arreglos y cambios que hice en todo el código base. Al menos obtuve algo de crédito por mi trabajo!

Dado el número de fallas contra las que estábamos trabajando, pensarías que fue un trabajo difícil el identificar cada linea de bugs, pero basado en mis experiencias, el mayor problema en Starcraft fue el uso de bases combinadas.

Las listas combinadas fueron extensamente utilizadas en el motor para encontrar unidades con comportamientos compartidos. Con el doble de unidades que su predecesor -Starcraft tuvo un máximo de 1600, contra 800 en Warcraft 2-, se volvió esencial el optimizar la búsqueda de unidades de un tipo especifico para mantenerlas enlazadas en una lista conjunta.

Había listas para las unidades y edificios de cada jugador, su «generación de energía», y muchas muchas cosas mas. Todas esas fueron doblemente unificadas para hacer posible el añadir o remover elementos desde dentro de manera constante, sin que fuera necesario atravesar los listados para buscar el elemento a ser removido.

Desafortunadamente, cada lista era mantenida a mano, por lo que no hubo funciones de uso compartido: los programadores tenían que realizar el mantenimiento linea a linea cada vez que era requerido. Y ese método es mucho mas propenso al error que el simple uso de una rutina que ya se hallase depurada.

Algunos campos se encontraban compartidos entre muchas lineas, por lo que era necesario conocer exactamente que lista y objeto se hallaban ligados -y en que orden- para desenlazarlos de forma segura. Y algunos estaban incluso guardados en «uniones C», con otros tipos de datos para mantener el uso de memoria al mínimo.

Así que el juego iba a estallar todo el tiempo. Todo el tiempo.

Así que... ¿por qué lo hicimos de esa manera?

Trágicamente no había necesitad de que todos esos problemas existiesen. Mike O´Brien, quien junto a Jeff Strain co-fundaron ArenaNet conmigo, escribió una librería llamada Storm.dll, la cual venía con Diablo. Entre sus muchas características, Storm contenía una excelente implementación de las mencionadas listas, usando plantillas en C++.

Durante el desarrollo inicial de Starcraft, esa librería fue utilizada. Pero temprano en el desarrollo, el equipo cortó el código y se enroló en eso de las listas, específicamente para hacer la escritura de saves más simple.

Déjenme hablar de los saves por un segundo, para dejar todo esto más claro.

Muchos títulos que he jugado antes de Warcraft tenían horribles funcionalidades para salvar la partida. Cualquiera que haya jugado algún producto original de Origin recordará cuan laaaaaaaaaaaaargo era el periodo para escribir un save. Digo, claro, eran escritos por lentos procesadores en discos que -para los estándares de hoy- eran tan diferentes entre si como triciclos y autos de carrera. Pero no había razón para que apestasen, estaba determinado a que Warcraft no tuviera esos problemas.

Así que hicimos unos cuantos trucos para ser capaces de escribir largos accesos de memoria en un solo bloque, en lugar de serpentear a través de a misma para escribir un poco aquí y otro allá. La gala entera de unidades (600 veces cada cien bytes) podía ser escrita en un solo bloque. Y así todas las variables podían ser escritas en un solo bloque, sin importar si de terreno o niebla se tratase.

Pero esa habilidad para escribir unidades en un solo bloque de memoria no era esencial para la velocidad de escritura de saves, aunque simplificaba drásticamente el código. Primariamente funcionaba porque las unidades del Warcraft no contaban con «punteros».

Las de Starcraft, que fueron previamente mencionadas, si los contenían. Era una bestia enteramente diferente. Fue necesario arreglar todos los punteros (tomando especiales recaudos con los que estaban enlazados), así que todas las 1600 unidades podían ser escritas de una vez... y entonces desarreglarlos para seguir jugando. Yuck!

Volver a cambiar!

Después de arreglar muchos muchos bugs, discutí vehementemente acerca de que deberíamos volver a usar el sistema de Storm, incluso si eso hacía el sistema de saves mas complicado. Cuando digo que «discutí vehementemente» debería mencionar que ese era mas o menos el único modo de discutir que teníamos en Blizzard -con nuestra mezcla de juventud y arrogancia no había argumento que no fuera vehemente, a menos que se tratase de lo que hubiese para almorzar ese día, lo cual nadie quería decidir-.

No gané la discusión. Como estábamos a «dos meses» del envío, hacer cambios para mejorar al motor era regularmente cambiado por sub-óptimas resoluciones. Lo que invariablemente llevó a muchos meses de sufrimiento, mucho de lo cual afectó mi enfoque para codear (para mejor) desde entonces.

Mas Parches:

Quiero mencionar un ejemplo mas acerca de los bugs: cuando Starcraft cambió a perspectiva isométrica, el motor de renderización (que estaba intacto con el código que escribí en 1993/4), fue dejado tal y como estaba.

Colocar cuadros isométricos en un motor para cuadros planos no es difícil, aunque hay algunas dificultades en conseguir que cosas como los editores de mapas funcionen apropiadamente, porque emplazarlas en el mapa requiere muchos «arreglos de perspectiva», ya que el editor está tratando de colocar imágenes diagonales en espacios planos.

Mientras que la renderización no quedó mal, encontrar las rutas isométricas en espacios cuadrados fue muy difícil. En lugar de hacerlo con espacios largos (32x32 pixels), que eran o transitables o intransitables, el mapa tenía que romperlos en pequeños sectores de 8x8 pixels, multiplicando el monto de búsquedas del motor por 16, creando dificultades artificiales para unidades largas que no podrían pasar por un camino estrecho.

Si Brian Fitzgerald no hubiera sido un programador estelar, el problema de las rutas en el mapa hubieran prevenido que el juego fuese lanzado indefinidamente. Como ese fue uno de los problemas que pudimos depurar solo al finalizar el proyecto, planeé escribir mas acerca del mismo en Starcraft ya que hay muchos datos técnicos y de diseños interesantes.

Como ya hemos visto, el Starcraft que conocemos hoy en día no luce como originalmente fue planeado. Una vez mucho más parecido a Warcraft en diseño, fue solo hasta que Blizzard vio que tan lejos se encontraba la competencia lo que motivó a transformar el juego en el gigante de los RTS que conocemos hoy en día.

Entonces es posible entender los extraños sentimientos que había en el Cuartel General de Blizzard cuando, unos pocos años atrás, descubrimos que uno de los competidores había sido un gran mentiroso.

El juego que mas daño le hizo a Starcraft fue el Dominion de Ion Storm. Mientras que nuestro Starcraft se veía como algo de principios de los noventa, el producto de Ion Storm parecía algo del siguiente milenio.

Hizo a nuestro equipo «lamerse las heridas y mirar hacía el futuro». Quizá eso no haya resultado en grandes cambios en el juego, pero si lo hizo un montón en los métodos de desarrollo de Blizzard.

Imagínense entonces nuestra sorpresa cuando, después del cierre de Ion Storm, algunos de sus antiguos empleados vinieron a trabajar con nosotros, y escupieron la verdad acerca de la demo que mostraron públicamente.

En algún punto, hablé con Mark y Patrick acerca de como Dominion nos dejó de rodillas. Pero entonces estos mismos chicos nos dejaron saber el pequeño secreto sucio de Ion Storm: «La demo entera era una película pre-renderizada, y las personas que la mostraron, ¡solo pretendían estar jugando!». Sería un eufemismo decir que nos sentimos atontados; habíamos reiniciado completamente Starcraft, lo que lo llevó a ser el «juego definitivo del género», ¡basados en una mentira!

Una tonta jugada de Ion Storm que todos debemos agradecer, porque sin esa patada baja, ¿quien sabe donde hubiera terminado Starcraft?.