Documental por el 25.º aniversario de Half-Life [Video]
(youtube.com)- Tras dejar Microsoft en 1996, Mike Harrington y Gabe Newell comenzaron al mismo tiempo el desarrollo de Half-Life y el diseño organizacional de Valve con un equipo que casi no tenía experiencia lanzando juegos
- Con la licencia del motor de Quake, la contratación de creadores de mods y talento de orígenes no convencionales, se creó desde cero la primera IP de Valve
- Half-Life apostó por una inmersión en primera persona sin interrupciones mediante color de 16 bits, animación esquelética, transiciones cortas entre niveles, eventos guionizados, IA reactiva y sonido
- Cuando una revisión interna en 1997 concluyó que el juego no estaba cohesionando, retrasaron el lanzamiento y rediseñaron el flujo de niveles con el proceso cabal, basado en pequeños grupos multidisciplinarios
- En la recta final hubo limitaciones como jornadas de 18 horas, monstruos y niveles recortados, y un Xen terminado a toda prisa, pero la iteración y las pruebas de juego elevaron la calidad final
La salida de Microsoft y la fundación de Valve
- Mike Harrington sentía que Microsoft se había vuelto demasiado grande, y desde alrededor de un año antes ya les decía a sus gerentes que dejaría la empresa para crear una compañía de videojuegos
- Harrington primero habló con Michael Abrash, pero después Abrash se unió a id Software tras ser convencido por John Carmack
- Cuando Harrington dijo que iba a crear una empresa de videojuegos, Gabe Newell respondió que él también quería irse, y así ambos comenzaron Valve
- Newell pensaba que, viendo la situación en ese momento, parecía muy probable que fracasaran, y que alrededor de un año después se daría cuenta del error y volvería con sus amigos de Microsoft para pedir trabajo
- Los dos fundadores tenían experiencia en desarrollo de software e ideas sobre cómo diseñar una empresa, y diseñaron Valve al mismo tiempo que hacían Half-Life
El motor de Quake, la primera IP y el equipo inicial
- Valve arrancó sin un plan claro, pero gracias a la conexión con Michael Abrash visitaron id Software y regresaron con el código fuente de Quake en un CD
- En ese momento todavía no había contrato, pero Valve ya tenía acceso al código fuente de Quake, un activo casi central de id
- John Romero les aconsejó que, si iban a fundar una empresa de videojuegos, debían contratar diseñadores de niveles
- La mayor parte del equipo inicial no tenía experiencia desarrollando juegos, y en toda la empresa solo unas 3 o 4 personas habían lanzado un juego de verdad
- Valve tenía que crear desde cero la IP de su primer juego, y Gabe Newell tomó como referencia la tensión y atmósfera que sintió en «The Mist» de Stephen King
- Al principio Valve tenía dos proyectos
- Quiver: el proyecto que después se convirtió en Half-Life
- Prospero: un proyecto aparte que desapareció cuando Half-Life absorbió sus funciones y recursos
- Un efecto de rayo creado para Prospero terminó en la secuencia del desastre de Half-Life y en los efectos de los Vortigaunt
Creadores de mods y talento poco convencional
- Valve contrató a muchos diseñadores de la comunidad de creadores de mods
- Se unieron jóvenes creadores de mods como Steve Guthrie, Steve Bond y John Guthrie
- Steve Bond, que hacía mods en QuakeC, aportó gran parte de la IA de los soldados de Half-Life
- En el equipo había muchas personas alejadas de la ruta estándar de la industria
- La persona que más código escribió en Half-Life había estudiado química y pensaba convertirse en abogado de propiedad intelectual en Atlanta
- Quien contribuyó enormemente al diseño de IA de criaturas era gerente de un Waffle House
- Marc Laidlaw aportó estructura narrativa e ideas al equipo, y también ayudó a sacar ideas de los demás
- En esa época no existía una ruta formal tipo “doctorado en diseño de videojuegos”, y Valve tenía que encontrar gente talentosa y convencerla de que sería un mejor lugar para trabajar
Las decisiones técnicas que hicieron Half-Life
- Valve desarrolló sobre el motor Quake de id, pero añadió varias tecnologías necesarias para Half-Life
- Las transiciones entre niveles se implementaron usando el sistema de guardar/cargar
- En pasillos o tramos de tren había una breve pausa para cargar el siguiente nivel
- La mayoría de las transiciones de Half-Life 1 duraban entre 1 y 2 segundos
- Las dos grandes inversiones técnicas de Half-Life fueron el color de 16 bits y la animación esquelética para monstruos
- El paso de 8 bits a 16 bits eliminó la necesidad de ajustar las texturas a una paleta de 256 colores
- Los personajes de Quake almacenaban posiciones de vértices por tiempo, pero con esqueletos se podían tener más animaciones, reemplazo de partes, armas acopladas y reutilización de modelos
- La animación esquelética sentó la base para incluir animaciones de 100, 200 o más de 500 cuadros y facilitar la modificación de personajes
Eventos guionizados y un mundo que responde
- El equipo estableció como principio que, si el jugador avanzaba, debía pasar algo cada 3 a 5 segundos
- No tenía que ser una gran pelea; también podían ser letreros, sonidos, pequeñas escenas o secuencias guionizadas
- Si el jugador se quedaba quieto, el mundo podía estar en silencio, pero si actuaba, el mundo debía responder
- Las secuencias guionizadas permitían hacer que personajes corrieran a una posición específica o crear escenas en las que algo volara y chocara sincronizado con una animación
- Los eventos guionizados eran poderosos, pero frágiles
- La escena del headcrab lanzándose sobre un científico funcionaba bien el 90% del tiempo, pero se rompía si algunos jugadores corrían directamente hacia el científico
- Algunas escenas tuvieron que colocarse detrás de vidrio para impedir que el jugador interviniera
- La secuencia del Tentacle quedó como un ejemplo emblemático de mezcla estrecha entre gameplay y eventos guionizados
- Gabe Newell entendía la diversión no tanto como realismo, sino como el grado en que el juego reconoce y responde a las elecciones y acciones del jugador
- Si disparas a la pared, deben quedar marcas de bala
- Si matas a muchos soldados, los soldados deberían huir
- La idea de que el mundo del juego reconozca la presencia y acciones del jugador se convirtió en un refuerzo central de Half-Life
Criaturas, personajes y G-Man
- El diseño de criaturas de Half-Life buscó una dirección naturalista pero alienígena
- Ted Backman creó muchos diseños carnosos y biológicos como headcrab, houndeye y bullsquid
- Chuck Jones, que venía de Duke Nukem, hacía monstruos de otro estilo, y hubo que encontrar armonía entre ambos enfoques
- El Headcrab se convirtió en una de las criaturas emblemáticas de Half-Life, y al colocarlo sobre el modelo de científico se creó el zombi
- Gordon Freeman no tuvo una apariencia claramente definida desde el principio
- El modelo temprano “Ivan the space biker” era un prototipo tosco
- Chuck Jones puso su propio aspecto en un modelo inicial de Gordon, y en el modelo multijugador quedó el rastro de una pequeña cola de caballo
- G-Man fue un personaje creado pensando en el cigarette man de The X-Files
- Al principio era más bien una figura inquietante al fondo de la escena de la oficina inicial
- Después se colocó en distintos lugares inaccesibles y se volvió una presencia misteriosa
- El Vortigaunt se añadió relativamente tarde a mapas más tempranos para reducir la repetición de monstruos al inicio
- El Assassin también llegó tarde como enemigo, y se completó añadiéndole IA a un modelo y animaciones que ya existían, sin animaciones nuevas
- Criaturas como Panthereye, stooka bat y chub toad permanecieron mucho tiempo en el juego o llegaron a la fase de implementación, pero al final fueron eliminadas
El espacio y las texturas de Black Mesa
- Black Mesa partió de elementos como grandes edificios de oficinas comunes cerca de DC, baldosas de linóleo, plafones suspendidos, muros de bloques de concreto y pisos ajedrezados en blanco y negro
- Karen Laur se encargó de la mayor parte del trabajo de texturas del juego, y al principio dibujaba a mano antes de pasar a referencias basadas en fotografías
- Tomó fotos de metal oxidado e imágenes industriales en lugares como Seattle, Harbor Island y Gasworks Park
- Muchas texturas de pasillos en Half-Life usan imágenes como superficies de vagones o trenes
- Imágenes de desiertos y acantilados del este de Washington y de Columbia Gorge también sirvieron como referencia para la atmósfera del suroeste
- Dentro de Black Mesa no solo había instalaciones de investigación, sino también oficinas, cocinas, microondas y escenas cotidianas como una sopa explotando
- La escena del microondas estaba conectada con experiencias reales de sopas explotando en la oficina de Valve
- Las franjas de colores se usaron para ayudar al jugador a orientarse dentro de la compleja instalación de investigación
La crisis de 1997 y el proceso cabal
- El primer año de desarrollo avanzó impulsado por oportunidades, y el equipo todavía estaba buscando dirección
- Unos 3 meses antes de la fecha prevista de lanzamiento en 1997, internamente concluyeron que el juego no estaba encajando bien
- Ingeniería, diseño de niveles y animación estaban desconectados entre sí
- Había monstruos sin plan de uso, y muchos niveles aún no tenían definido qué iba dentro
- Como extensión de la cultura moddera donde cada diseñador hacía su propio mundo, faltaba cohesión general
- La escena en la que Gabe Newell jugó todos los niveles durante dos días y reaccionó con un “vamos a fracasar” quedó muy marcada en el equipo
- Valve decidió que no lanzaría el juego siguiendo el calendario de Sierra, y que seguirían desarrollándolo incluso si Sierra no aportaba más dinero
- Bajo la idea de que “retrasarse es temporal, pero algo mediocre es para siempre”, decidieron no forzar el lanzamiento
- Después se introdujo el proceso cabal
- Pequeños equipos multidisciplinarios con artistas, diseñadores de niveles e ingenieros escribían las especificaciones de cada nivel
- Siguiendo el flujo narrativo escrito por Marc Laidlaw, diseñaban en orden qué mapas se necesitaban y cuál era la siguiente pieza
- Intentaban definir la proporción de combate, exploración y rompecabezas para aplicarla de forma uniforme a todo el juego
- Los bocetos funcionaban como actas visuales de reunión y quedaron como un resultado fuerte del cabal
La apertura, la secuencia del desastre y la inmersión continua
- La escena inicial del tren de Half-Life fue una reacción a las convenciones de los shooters en primera persona de la época
- Muchos juegos daban un arma y enemigos de inmediato sin cinemática, o empezaban a jugarse después de una cinemática
- Half-Life comienza con un científico anónimo entrando a Black Mesa en el tren de camino al trabajo
- Muchos jugadores al principio creían que era una escena grabada, y al mover el mouse se daban cuenta de que era en tiempo real
- Parte de la estructura del tramo previo al desastre sobrevivió desde la versión del primer año, y luego John Guthrie y otros la pulieron hasta la versión final
- La secuencia de la cámara de pruebas fue un punto de inflexión importante
- Una versión que John Guthrie hizo de madrugada quedó casi igual a la que se envió
- Iluminación, sonido, latidos, respiración y puesta en escena se unieron para crear una “experiencia continua que realmente le ocurre al jugador”
- Después de esta secuencia, que conectaba el antes y el después del desastre, el equipo ganó confianza en que el juego podía unirse como un solo producto y no como una colección de contenidos sueltos
La preview filtrada y la reacción externa
- Una de las formas de Valve de financiar el desarrollo fue vender una build preview de Half-Life a empresas de tarjetas de video
- Por contrato debían entregarla en una fecha específica, y el equipo terminó los primeros tres niveles para hacerlo
- Esa build pronto se filtró, y aunque al principio hubo enojo, luego empezaron a circular reacciones de jugadores en línea
- Una revista dijo que normalmente no reseñaba software beta, pero aun así reseñó esa build y la evaluó positivamente
- Esa reacción externa se convirtió en una fuerte validación de la dirección que Valve estaba intentando seguir
Armas, sonido y señales de IA
- Las armas de Half-Life se diseñaron para que sus funciones fueran lo más distintas posible entre sí
- Además del eje básico de shotgun y pistol, se incluyeron rocket launcher, Gauss gun y snark, entre otras
- Snark se concibió como un arma para lidiar con jugadores que campeaban, haciendo que una criatura pequeña se moviera por el área al lanzarla
- La crowbar entró como resultado de querer un mecanismo por el que el mundo respondiera
- Golpear la pared se sentía entonces como una retroalimentación especialmente satisfactoria
- Fue un ejemplo concreto de cómo la idea de que “la diversión es que el mundo reaccione a tus acciones” se convertía en una decisión de diseño
- El sonido se usó como un medio clave para transmitir al jugador el estado interno de la IA
- Los soldados comunicaban por voz heridas, lanzamiento de granadas o cobertura
- Incluso sin notarlo de forma consciente, el jugador terminaba anticipando por el sonido lo que iba a pasar
- Kelly Bailey usó el motor de sonido y también compuso la banda sonora
- No había escrito una banda sonora antes, pero hizo toda la música del juego y recibió premios
- El sonido del Headcrab se creó ralentizando mucho el sonido de una rata y reproduciéndolo al revés
- Los efectos DSP hacían que la reverberación sonara distinta en conductos de ventilación o espacios enormes, reforzando la sensación de espacio
- El movimiento de labios de los personajes se implementó relativamente rápido usando señales de audio
- Como animadores y programadores veían de forma distinta las partes difíciles, tras una conversación en el almuerzo lograron en poco tiempo que los personajes hablaran y movieran la boca
Diseño de niveles y tramos representativos
- El tramo Power Up se diseñó en torno a la criatura Gargantua, por lo que casi se mantuvo en su forma original
- El jugador tiene que encargarse del Gargantua, encender la energía y mover el tren para seguir
- El punto de partida del diseño era cómo impedir que el jugador simplemente saliera por la puerta
- En el segundo año cambiaron de meter IA dentro de mapas ya existentes a crear primero entornos acotados donde la IA luciera bien, para que luego los diseñadores los integraran
- La IA de los soldados evolucionó en mapas de prueba que mostraban situaciones de combate como posiciones elevadas e inferiores, retirada, uso de escaleras y ataques por los flancos
- El tramo del tren fue un intento de dar al jugador un vehículo controlable pero restringido
- Como algo al estilo de los vehículos de Half-Life 2 era imposible, eligieron el tren como la forma más limitada
- Algunos jugadores dejaban el tren y seguían a pie, así que guiaban su regreso electrificando las vías para obligarlos a traerlo
- Surface Tension surgió con fuerte impulso de bocetos que incluían acantilados, tanques, puestos militares, desierto, helicóptero y presa
- El tramo de acantilados se diseñó para aprovechar el vértigo
- La sección de la presa, que recordaba a Hoover Dam, se hizo en pocas horas
- Karen Laur intentó crear cohesión visual nombrando los sets de texturas según el nivel correspondiente para evitar que nuevas texturas se usaran de forma caótica en muchos niveles
Narrativa, nombres y voces
- La narrativa de Half-Life buscó una escritura diegética transmitida dentro del juego, más que explicaciones fuera de él mediante cinemáticas
- Tras las pruebas de juego se añadieron líneas de científicos en lugares donde se consideró que faltaba orientación o explicación de la situación
- Por ejemplo, al final se agregó una escena donde un científico aparece de repente para dar una pista como “ve por allá”
- Parte de la ubicación y el nombre de Black Mesa surgió de puntos y nombres de mapas tempranos
- Un punto marcado en México en el mapa del lobby terminó conectándose luego con la ubicación y el nombre
- Los desarrolladores preferían nombres sugerentes que no explicaran todo, porque eso aumentaba el misterio
- La voz de Barney se decidió de inmediato cuando Hal Robins habló por teléfono y el equipo sintió al instante que “este es el indicado”
- G-Man fue interpretado por Michael Shapiro, y aunque al principio también grabó una actuación más segura y directa, después se adoptó una voz más parecida a la de un “lagarto loco”
- La voz de Nihilanth también se resolvió dentro del propio equipo
La carga laboral al final y las historias personales
- En la etapa final de Half-Life hubo jornadas de trabajo muy largas
- Algunos miembros del equipo dicen haber trabajado 18 horas al día
- Los integrantes más jóvenes a menudo se quedaban en la oficina hasta muy tarde
- Karen Laur recuerda que era la única mujer del equipo y que esa situación no fue buena
- Una foto de Isabel, la hija de un desarrollador, terminó dentro del casillero de Gordon
- Al principio era un easter egg personal escondido en alguna oficina destruida, pero después la movieron al casillero de Gordon
- Isabel nació durante la producción de Half-Life y necesitaba cuidados especiales, así que fue una etapa muy dura para su familia
- Los desarrolladores dicen que incluso justo después del lanzamiento final les costaba tener certeza de que el juego realmente fuera divertido
- Llegaron a decir que, si cualquiera del equipo hubiera desaparecido un mes, no habrían logrado enviar el juego, lo que muestra lo importante que fue cada integrante
Xen y las limitaciones de la parte final
- Xen empezó con la idea de entrar en el interior de una gigantesca criatura alienígena para detener o manipular su funcionamiento
- Querían expresar arquitectura alienígena o estructuras biológicas, pero las herramientas eran adecuadas para crear rectángulos, y poco a poco se redujo a estructuras más tipo pasillo
- Xen llegó al final del juego bajo una fuerte presión de tiempo
- Algunas partes quedaron en un estado cercano al primer borrador
- En un punto incluso consideraron eliminar Xen por completo, pero se mantuvo porque el concepto artístico era muy fuerte
- Las texturas de Xen se inspiraron en imágenes de microscopio electrónico, insectos y escarabajos, entre otras referencias orgánicas
- El editor no era amigable para crear formas orgánicas, y hacer los niveles fue muy difícil
- Cambios como la baja gravedad y un jetpack llegaron tarde y tuvieron que integrarse adicionalmente en espacios ya construidos
- En cierto momento el equipo decidió que ya no podía seguir puliendo y tenía que terminar
- Si el jugador no se había divertido para ese punto, ya habían fracasado de todos modos, así que consideraban más importante cerrar el juego
- Incluso salió la broma de que “siempre existe Half-Life 2”
Reflexiones después de terminarlo
- Los miembros del equipo recuerdan como algo importante la experiencia de colaborar con personas de orígenes profesionales muy diversos durante la creación de Half-Life
- Karen Laur dijo que entró como artista de texturas, pero aun así pudo influir bastante en lo que el juego terminó siendo
- Un buen juego requiere crear material suficiente para dos juegos y desechar lo malo, y Valve pudo hacerlo gracias al apoyo de Mike Harrington
- Gabe Newell dice que le importa más lo que pueden hacer en el futuro que mirar el legado del pasado, y que el trabajo anterior se parece más a un peldaño que les permitió seguir avanzando
1 comentarios
Opiniones de Hacker News
Me pareció realmente interesante cómo Valve se sacó la lotería con sus primeras contrataciones.
Había muchas personas que ni siquiera tenían formación en CS ni en videojuegos, pero una buena parte de ellas resultó ser persistente, ingeniosa, creativa y muy trabajadora.
La persona que escribió la mayor parte del código de Half-Life tampoco era desarrolladora y, si mal no recuerdo, en ese momento estaba estudiando para ser abogada o contadora.
Al final, no queda más que pensar que el timing, los fundadores y simplemente la suerte fueron factores decisivos.
En la práctica, ese primer año lo usaron para ganar experiencia, y lo importante fue que la distribuidora Sierra aceptó eso.
Hoy en día, sobre todo en los juegos AAA, no creo que algo así pase con frecuencia. Los presupuestos crecieron demasiado, y las distribuidoras probablemente presionarían al estudio para que sacara lo que ya tiene, pegándolo como sea con cinta adhesiva, en lugar de darle un plan B.
Total, se puede parchear después, ¿no?
La industria tecnológica parece obsesionada con los desarrolladores 10x como Carmack, pero las personas motivadas también pueden lograr cosas increíbles.
Así que fueron a id, consiguieron el motor de Quake y también recibieron consejos de Romero.
A veces conocer a la persona correcta ayuda muchísimo, y en el éxito siempre hay cierto grado de suerte. También está claro que un gran equipo hizo que ese juego fuera lo que fue.
La forma en que equilibraron realismo y diversión también fue interesante, y el proceso de cómo se crea algo siempre es entretenido.
Me parece que en esa época esto era mucho más común que ahora. Hoy hay que poder hacer trabajos uno o dos niveles por encima de lo estrictamente necesario para lanzar, quizá porque la gestión y los calendarios están tan distorsionados que hay que entregar resultados aun trabajando con prisa y exceso de carga.
Quienes recién empiezan o cambian de carrera casi no reciben este tipo de apoyo, y no les queda más que intentar por su cuenta y esperar estar adquiriendo habilidades que los vuelvan contratables.
A fines de los 90 estuve muy involucrado en la comunidad australiana de Team Fortress (versión de Quake 1), y ‘bro’ (Robin Walker) y John Cook eran como dioses para nosotros.
Participaban constantemente en la cultura LAN de RMIT/Melbourne y en línea, en una época en la que la mayoría usaba módems de 28.8/33.6k y había algunos LPB en las conexiones ISDN de universidades de la costa este.
Quizá el hecho de que sufrieran intentando pasar de qwtf a ‘tf2’ terminó siendo algo bueno. Las lecciones que aprendieron en ese páramo seguramente les sirvieron después cuando entraron a Valve y trabajaron en HL2.
También es bastante divertido que TF2 originalmente iba a ser un shooter militar moderno mucho más realista, pero se vino abajo por la expansión del alcance.
Me emocionó mucho cuando Valve los contrató y terminaron creando TFC y luego HL2.
Después salió Day of Defeat, que cubrió bastante bien ese papel.
Aquí surge una pregunta bastante obvia. ¿Qué tenía de diferente ese equipo? ¿Era talento, liderazgo o enfoque en el producto?
Como alguien que lleva mucho tiempo trabajando como desarrollador de JavaScript, lo que creo sinceramente es que, entre la gente que trabaja principalmente con JavaScript, solo alrededor del 4% sabe realmente lo que está haciendo.
El equipo inicial de Valve parecía tener mucha pasión, pero muy poca experiencia real con ese tipo de código o producto. Consiguieron una enorme plataforma de apoyo en forma del código de Quake, y el resto lo fueron descubriendo por su cuenta.
No se quedaron estancados sobre el código de Quake, sino que lo modificaron a fondo según sus necesidades. La mayoría de los equipos de JavaScript no puede hacer eso. Se quedan en su framework favorito y dan vueltas alrededor del estilo de código y los procesos.
¿Cuál es la diferencia entre el equipo inicial de Valve y distintos equipos de JavaScript? Claramente no es la educación ni la madurez profesional.
Más allá de eso, normalmente no te dan autoridad para hacer grandes cambios a menos que seas bastante sénior y, aunque decidas seguir buscando mejorar por tu cuenta, es poco probable que la empresa recompense ese crecimiento técnico.
Al final, creo que es un ámbito con rendimientos decrecientes bastante fuertes.
Si alguna vez jugaste juegos multijugador competitivos, sabrás que hay personas que, aun después de miles de horas, no mejoran en absoluto.
A veces parece que la gente se topa con un cuello de botella, pero no sabe cómo superarlo.
En ese entonces, crear niveles, modelos, animaciones y demás para videojuegos era drásticamente más simple que ahora.
Una persona hizo todo el trabajo de texturas del juego, otra creó todos los efectos de sonido y la música, e incluso programó un motor DSP que manipulaba el sonido en tiempo real según el entorno.
Unas pocas personas muy talentosas, si tienen la voluntad de liderar a gente inteligente, entusiasta y motivada, pueden lograr muchísimo. Creo que eso fue exactamente lo que ocurrió en Valve.
Sabían lo suficiente para terminar el trabajo, pero no lo suficiente como para concluir que lo que querían hacer “no se podía”.
Un desarrollador con más experiencia tal vez habría descartado muchas de las ideas que el equipo de Half-Life terminó implementando por ser “demasiado tardadas” o “prácticamente imposibles”.
Los desarrolladores de Valve de aquella época no tenían tanta experiencia como para hacer esas suposiciones, así que simplemente se metieron de lleno y encontraron la forma.
Al final, prácticamente volvieron a empezar con el “cabal” y tuvieron que completar el juego reuniendo las buenas piezas que ya habían creado.
Aquí hay un texto más detallado sobre el proceso cabal (empieza en la página 2):
https://web.archive.org/web/20210823181232/https://www.gamas...
Es un artículo de 1999 y tiene mucho más detalle que el video.
El desarrollo de juegos es, por naturaleza, en cascada. Se trabaja durante años y se acumula todo para un gran lanzamiento. Hoy puede haber procesos ágiles dentro de los hitos, pero en el fondo todo apunta a una enorme cascada.
Esto importa. Hoy, lo ágil tiene un aspecto que convierte a desarrolladores autónomos en engranes de una gran máquina. Pero el “cabal” de Valve tenía la libertad de hacer lo que consideraba mejor.
Gabe Newell seguramente tenía la decisión final y sus opiniones, pero en última instancia ese grupo tenía flexibilidad. Los desarrolladores conocían todo el sistema y no se limitaban a tomar tickets de Jira de un tablero, como en la parábola de los ciegos y el elefante[1].
Sabían cómo encajaban las piezas porque eran ellos quienes las habían puesto ahí. Y si las piezas no encajaban, también tenían autoridad para hacer que encajaran.
También es interesante que la historia de Half-Life pueda verse desde la perspectiva de The Mythical Man-Month[2].
Aunque el resultado haya sido un éxito, el crunch deja un recordatorio amargo.
Por esas jornadas laborales dejé el modding y me pasé al aburrido software empresarial.
Además, todavía puedes desarrollar juegos en tu tiempo libre. De hecho, porque tienes tiempo libre.
También vale la pena ver el playthrough de Dario Casali por el 25.º aniversario de Half-Life: https://www.youtube.com/playlist?list=PLk5gaNp4x_AVIJviyHueH...
Jornadas constantes de 12 a 16 horas, discusiones por email y directivos que desmotivaban
Cuando era chico, tenía una imagen casi de cuento de hadas de trabajar en Valve: un entorno genial donde gente inteligente hacía el mejor trabajo. Seguramente siga siendo cierto en cierta medida, pero no creo que yo pudiera hacer los sacrificios que estos desarrolladores asumieron por un videojuego. Increíble
Uno de los videos que me pareció más interesante fue el último, sobre mapas multijugador, porque Dario tenía mucho que decir sobre el diseño de mapas
Lo vi ayer, y el desarrollo de videojuegos es realmente duro e impredecible
Este caso en particular fue casi todo de amateurs, con poca o nula experiencia en programación o videojuegos, pero con mucha pasión
También desmitifica cómo se hizo. Casi ninguno de los buenos elementos de Half-Life, como la introducción, G-Man, Xen, los headcrabs o la música, existía desde el principio; se fueron creando sobre la marcha
El documental estuvo buenísimo. Jugué muchísimo a ese juego en su momento
Ahora Half-Life Deathmatch también parece estar viviendo una breve especie de renacimiento, así que vale la pena probarlo si quieres sentir nostalgia
Valve también publicó algunos modelos de personajes de arte conceptual, ajustes de gameplay y mapas nuevos. Es contenido nuevo para un juego de 25 años
Como dato, Half-Life y HL2 ahora son bastante jugables en VR. Half-Life incluso corre de forma nativa en Quest 2
Pero Valve no reconoció el 17.º aniversario del anuncio de Half-Life 2 Episode 3
“Llegar tarde es algo pasajero, pero ser malo es para siempre” es una buena frase
Me viene a la mente No Man’s Sky, y Cyberpunk 2077 también podría entrar ahí
Fue un documental excelente. Después de ver el documental de aniversario, también recomiendo buscar la primera parte[1] de Black Mesa, el remake del Half-Life original en el motor Source
Los modders hablan mucho sobre los elementos que mencionaron los desarrolladores originales y las dificultades que enfrentaron al recrearlos
[1] https://www.youtube.com/watch?v=G_TcAxAKCAI