Template:PatchDiff/March 6, 2026 Patch/hl2/resource/closecaption latam.txt

From Team Fortress Wiki
Jump to: navigation, search
39153915"wood.scraperough" " "
39163916"plastic_box.scraperough" " "
39173917 
N/A3918"#commentary\cn_001_physics_sound.mp3" "[ Jay Stelly ] Para que la física fuera creíble, los sonidos producidos por el sistema de física también debían ser adecuados. Como seres humanos, estamos acostumbrados al sonido que producen los objetos y los materiales en diversas interacciones, incluso si no lo percibimos de forma consciente. Aunque sabíamos que no podíamos abarcarlo todo, queríamos centrarnos en los detalles que más contribuyeran a que nuestra física sonara realista. Empezamos con sonidos por objeto para colisiones e impactos. Esto permitía que un objeto, como una caja de madera, tuviera sonidos personalizados cuando colisionaba con otros objetos o clases de objetos. Luego, comenzamos a modificar dinámicamente estos sonidos dependiendo de las características del evento físico, como los cuerpos involucrados y la fuerza de la colisión. Esto funcionó muy bien para las colisiones, pero no tanto en otras interacciones, como los objetos que se rozaban entre sí. En la realidad, una caja de madera produce un sonido diferente cuando se raspa contra una pared que cuando se lanza contra esa misma pared. De verdad que nadie ha investigado más que nosotros los matices de las propiedades físicas de una caja de madera. Para conseguir lo que queríamos de estas interacciones, implementamos sonidos de colisión por material: metal contra madera, metal contra metal, etc. Estos sonidos también se modificaban dinámicamente en función de detalles como la dureza del material o el tipo de metal. Para que el sistema sonara bien, fue necesario realizar varios ajustes pequeños, que solo pudimos identificar cuando el sistema se puso en marcha. También experimentamos con sonidos personalizados para objetos rodantes, pero finalmente eliminamos la función porque no nos gustaron los resultados."
N/A3919"#commentary\cn_002_ramming_with_the_buggy.mp3" "[ Jay Stelly ] Nuestro sistema de física se basa en cuerpos rígidos, lo que significa que no admite ninguna deformación ni destrucción de objetos. Si un objeto físico recibe un impacto, puede moverse si se le permite, pero, de lo contrario, no ocurre nada más. Por lo tanto, cuando conduces el buggy a través de una ventana, debemos emplear algunos trucos para que todo funcione como se espera. Como la ventana está fija en su lugar, la simulación física hará que el buggy rebote contra la ventana, pero notificará a nuestro sistema de juego que se produjo una colisión. El sistema de juego se encarga de la destrucción, por lo que rompe la ventana en fragmentos de vidrio y le indica al sistema de física que comience a simularlos. Lo más importante es que el sistema de juego también le dice al sistema físico que restaure el buggy a su estado previo a la colisión, lo que garantiza que la próxima vez que se simule la física, el buggy pueda pasar libremente a través de la ventana ya destruida. Este proceso genera un salto de un fotograma en la física del buggy, ya que se detiene brevemente y se teletransporta al momento previo al impacto. Lo sentimos si saber esto hizo que Half-Life 2 fuera totalmente injugable. Pero después de ver las pruebas de juego en aquel momento, decidimos que nos gustaba la interrupción momentánea, ya que aumentaba la sensación de impacto."
N/A3920"#commentary\cn_003_ramming_zombies_with_the_buggy.mp3" "[ Jay Stelly ] Como ya mencionamos varias veces en estos comentarios, los seres humanos tenemos ciertas expectativas del mundo físico. Una de ellas es que, si atropellas a un zombi con tu auto, este salga volando. Pero conseguir este efecto en el juego no es tan sencillo como en el mundo real. Por motivos de rendimiento, los enemigos como los zombis utilizan una caja de colisión simplificada durante el juego. Es una caja que se ajusta perfectamente al zombi, sin que sobresalga ninguna parte del modelo. Pero cuando el zombi muere, se convierte en una marioneta con cajas de colisión más precisas para cada extremidad, aunque esto es más costoso de simular. Este cambio en la representación de la colisión añade más complejidad cuando atropellas a un zombi con el buggy, más allá del simple choque del chasis. Cuando el buggy choca por primera vez con el zombi, toca la caja de colisión simplificada del zombi. Después, el juego mata al zombi y lo convierte en una marioneta que el sistema de física comienza a simular. Ahora, con una colisión más precisa por extremidad, la parte más cercana del zombi puede estar a varios centímetros del buggy. Como resultado, cuando el sistema de física retoma la simulación del zombi, este comienza a caer por la gravedad, porque el buggy ya no lo empuja. Aunque solo pasa un instante antes de que el buggy vuelva a alcanzar al zombi, esta pequeña discrepancia hacía que embestir a los zombis fuera insatisfactorio, porque se caían cuando el jugador no los podía ver. Para solucionarlo, guardamos la fuerza recibida por la caja de colisión del zombi al momento del impacto y la replicamos en la marioneta tras la conversión. También añadimos una ligera fuerza ascendente a la marioneta, lanzándola un poco. Con estos ajustes, los zombis ahora rodaban sobre la parte delantera del buggy al recibir el impacto, lo que se ajustaba mejor a las expectativas de los jugadores."
N/A3921"#commentary\cn_004_buggy_sound_engine.mp3" "[ Kelly Bailey ] El audio del buggy fue todo un reto, porque queríamos que sonara como un vehículo muy potente a gran gran velocidad, pero los mapas no son tan grandes como para reflejarlo y el buggy no pasaba de primera. Además, su velocidad máxima era de unos 56 km/h. En nuestra defensa, 56 km/h sigue siendo bastante rápido, sobre todo para 2004. Además de la velocidad, los controles de conducción son muy sencillos. Con el teclado como dispositivo de entrada, los controles son binarios, es decir, el buggy o acelera o no acelera, gira completamente o no lo hace. Así que, teníamos que crear audios muy complejos para una simulación que no refleja esa complejidad. Por lo tanto, creamos un motor falso para el sonido del buggy. Tiene su propia transmisión y combina los controles del jugador con los datos de la simulación física. Medimos el par motor de cada rueda simulada, tanto si gira como si está en contacto con algo, y creamos un conjunto de sonidos en bucle, mezclándolos cuidadosamente para ajustarlos con respecto al cambio de marcha del motor falso y los datos de las ruedas. Y luego, seguimos probando cosas diferentes; añadimos más complejidad. Hicimos ajustes hasta que manejar el buggy fue más divertido y, de alguna manera, recompensaba por esa sensación de ir rápido. La mayoría de los jugadores no hacen comentarios al respecto, salvo decir que el buggy suena bien, y para nosotros eso es un éxito, dada la locura que había bajo el capó."
N/A3922"#commentary\cn_005_buggy_sound_design.mp3" "[ Kelly Bailey ] El diseño de sonido del buggy se basó en muestras de un viejo Camaro de 1968. Elegimos ese auto porque tiene un motor V8 increíble con pistones enormes. Y es que, realmente no hay nada que suene igual, con ese sonido visceral y potente que buscábamos. La transmisión también tiene un maravilloso chirrido mecánico cuando deja de acelerar, y esa combinación nos pareció muy receptiva para el sistema binario con el que teníamos que trabajar. Por eso, la transmisión del motor falso no se basó en un auto real. En cambio, se diseñó como un sistema sencillo para recompensar al jugador por mantener pisado el acelerador. Es como una escalera mecánica en bucle que produce un tono ascendente, creando tensión constantemente y cambiando de marcha cada vez que el tono necesita reiniciarse. Como el jugador se quedaría rápidamente sin espacio en nuestros mapas relativamente pequeños, el objetivo era simplemente hacer que acelerar fuera divertido durante un breve periodo de tiempo."
N/A3923"#commentary\cn_006_automating_dsp.mp3" "[ Kelly Bailey ] Todos los sonidos que escucha el jugador se procesan a través de nuestro sistema de procesamiento de señales digitales o DSP. Es lo que altera el audio para reflejar el entorno en el que se encuentra el jugador. Por ejemplo, un mismo sonido será diferente cuando se escuche en un estacionamiento, en una habitación pequeña o al aire libre. En Half-Life 1, colocamos manualmente nodos invisibles por todo el mundo para definir los ajustes del DSP para cada espacio. Para Half-Life 2, sabíamos que hacerlo de forma manual tomaría demasiado tiempo, sobre todo porque queríamos un juego más grande y solo teníamos una persona encargada del audio. Así que creamos un sistema que determina automáticamente los ajustes del DSP alrededor del jugador en tiempo real. Para hacerlo, analiza el espacio que rodea al jugador, evalúa el volumen en el que se encuentra y examina los materiales que componen el entorno. Luego, el sistema compara ese espacio con uno de los 25 tipos básicos de DSP creados manualmente, ajustamos algunos parámetros y creamos el DSP totalmente detallado que modifica los sonidos que oye el jugador."
N/A3924"#commentary\cn_007_dynamic_mixing.mp3" "[ Kelly Bailey ] Durante el juego, se reproducen muchos sonidos al mismo tiempo, pero algunos son naturalmente más importantes que otros y necesitamos ajustar los volúmenes de los sonidos para garantizar que los importantes destaquen. En una película, esta mezcla de sonido se realiza como un proceso posterior. Pero, en un juego, se produce en tiempo real, en respuesta a las acciones del jugador, por lo que no podemos predecir de antemano qué sonidos se reproducirán simultáneamente. Para solucionar esto, todos los sonidos se agrupan por tipos y se etiquetan con prioridades. Durante el juego, el sistema de audio supervisa todos los sonidos activos y baja el volumen de los sonidos de un grupo si se reproduce un sonido de mayor prioridad. Esta mezcla es ajustable: si los disparos deben ser fuertes en una escena, podemos darles prioridad. Si es necesario que se escuche claramente una línea de diálogo específica, se puede forzar la reducción del volumen de todos los demás sonidos. Y hacemos lo mismo con la música. Es un sistema sutil pero muy importante, que evita que el entorno sonoro se vuelva demasiado confuso."
N/A3925"#commentary\cn_008_soundscapes.mp3" "[ Kelly Bailey ] En Half-Life 1, los sonidos ambientales se colocaban a mano y luego se ajustaban individualmente. Para Half-Life 2, queríamos más sonidos ambientales en nuestros entornos, con mayor calidad y menos esfuerzo manual para su colocación, por lo que creamos el sistema que llamamos sistema de paisaje sonoro. Un paisaje sonoro es un pequeño programa que controla qué sonidos ambientales se reproducen, de dónde provienen y cómo se comportan en un entorno específico. Por ejemplo, el zumbido de las moscas, el soplar del viento, los pájaros, un tren lejano, un combate distante. El sistema de paisajes sonoros podía seleccionar y reproducir estos sonidos de forma aleatoria y, lo que es muy importante, gestionar la transición fluida a medida que el jugador se movía por los entornos. Los paisajes sonoros también pueden contener otros paisajes sonoros, lo que nos permite crear colecciones de sonidos reutilizables. Por ejemplo, un combate distante podría ser el fuego de armas pequeñas, explosiones lejanas o un helicóptero que pasa. Estos paisajes sonoros se ensamblarían y reproducirían dinámicamente a partir de muchos sonidos individuales, lo que nos ayuda a evitar la sensación artificial de una sola pista en bucle. En general, el sistema de paisajes sonoros fue un verdadero caballo de batalla para el audio en Half-Life 2 y es responsable de prácticamente todos los sonidos que se escuchan y que no están directamente relacionados con el juego."
N/A3926"#commentary\cn_009_audio_over_distance.mp3" "[ Kelly Bailey ] Los amplios espacios de los mapas de Coast nos llevaron a buscar una solución de audio que reflejara cómo cambia el sonido con la distancia. Por ejemplo, en estos mapas, un enemigo puede estar a más de 100 metros de distancia, y su arma debería sonar diferente a esa distancia y cuando está cerca. Decidimos almacenar nuestros sonidos en un único archivo estéreo, con el sonido cercano en el canal izquierdo y el sonido lejano en el canal derecho. Luego, durante la reproducción, se hace un fundido cruzado, es decir, se cambia la proporción del sonido que se escucha, entre esos dos canales según la distancia del jugador con respecto al sonido. Fue una solución sencilla que funcionó bien y nos ayudó con las limitaciones de memoria. Se puede escuchar fácilmente en acción: solo hay que escuchar cómo cambian los disparos de un soldado de la Alianza al acercarse a ellos."
N/A3927"#commentary\cn_010_flying_vehicle_audio.mp3" "[ Kelly Bailey ] Los grandes enemigos voladores del juego presentan un reto sonoro único. Durante el combate, son mucho más móviles que otros enemigos y se alejan considerablemente del jugador. Además, son muy peligrosos si tienen línea de visión. Estos factores nos llevaron a centrarnos en una solución sonora específica para la oclusión; en otras palabras, cuando puedes ver al enemigo y cuando el enemigo puede verte a ti. Queríamos crear una distinción clara en el audio cuando tienen esa línea de visión y cuando no. Los sonidos del motor de los vehículos voladores se componen de múltiples sonidos en bucle que reproducimos simultáneamente. Algunos de esos bucles se procesan por el sistema DSP dependiendo del espacio en el que te encuentres, mientras que otros se reproducen directamente sin procesar. El sistema DSP añade un mayor efecto de eco ambiental cuando pasamos el sonido por ese sistema. Cuando el objeto volador queda oculto detrás de algo y no puede verte, aumentamos el porcentaje de bucles que pasan por el procesamiento DSP, y suena como si ese objeto estuviera un poco más lejos. Luego, cuando ese enemigo emerge detrás de un objeto y puede verte, reproducimos más el sonido directo. En general, eso te da la sensación de que el sonido es lejano y sin dirección o más directo en tu línea de visión. Puedes oírlo cuando el helicóptero emerge detrás de un edificio; lo ideal es que realmente puedas oír esa diferencia."
N/A3928"#commentary\cn_011_bullet_audio.mp3" "[ Kelly Bailey ] Si hay algo de lo que estamos seguros es de que a lo largo del juego volarán muchas balas cerca del jugador, por lo que dedicamos mucho tiempo a perfeccionar su tratamiento de audio. Desafortunadamente, las balas en el juego son instantáneas, por lo que no podemos simplemente asignarles un sonido y basarnos en el movimiento para posicionarlas. Después de algunos experimentos, llegamos a esta solución: al determinar el punto más cercano de la trayectoria de la bala al oído del jugador, calculamos el momento exacto y la posición en la que la bala pasaría conceptualmente por él. Luego, reproducimos dos sonidos diferentes en ese punto para simular un efecto Doppler: uno para la aproximación de la bala y otro para su partida. Retrasamos el sonido de partida en función del tiempo calculado en el que la bala pasó por ahí."
N/A3929"#commentary\cn_012_staircase.mp3" "[ Aaron Seeler ] A lo largo del juego hay situaciones que se derivan de objetivos de diseño sencillos y bastante directos, y esta escalera presenta dos de ellos. El primero era enmarcar la Ciudadela mientras despertaba, mostrando al jugador que había despertado la colmena. El segundo era mostrar nuestro sistema de marioneta. Aunque ahora es algo habitual, en 2004 todavía era una novedad ver cómo los cuerpos caían de forma realista, y las escaleras proporcionaban un escenario perfecto."
N/A3930"#commentary\cn_013_alyx_and_mossman.mp3" "[ Bill Fletcher ] En nuestros primeros planes para la narrativa de Half-Life 2, queríamos asumir el reto de hacer algo menos centrado explícitamente en el juego. No solo una historia sobre el jugador obviamente bueno que derrota a los enemigos obviamente malvados. En vez de eso, nuestro objetivo era centrarnos en los personajes y sus relaciones. Pensamos que sería interesante explorar la familia como la unidad dinámica central de Half-Life 2. La tensión entre Alyx y Mossman surgió de esa idea y nos gustó porque nos parecía identificable, algo que los jugadores podían entender y con lo que podían empatizar."
N/A3931"#commentary\cn_014_exposition_board.mp3" "[ Danika Rogers ] Queríamos incluir aquí esta parte densa de la historia visual, porque es donde más explícitamente se invita a los jugadores a explroar el espacio. Aunque su función principal es la construcción del mundo, nos esforzamos por destacar la relación entre Eli y Breen, dando contexto al conflicto central del mundo."
N/A3932"#commentary\cn_015_city_17_awakens.mp3" "[ David Sawyer ] La sección inicial de la estación de tren se diseñó para que la ciudad se mostrara indiferente hacia el jugador, como si Gordon fuera un ciudadano más, sin nombre ni rostro, listo para ser sometido. Pero durante la redada en el edificio y la persecución por los tejados, la ciudad identifica al jugador como una anomalía y comienza a agitarse. Ahora, con el jugador como agresor, la ciudad centra toda su atención en él. El sistema de megáfonos de Vigilancia, que se escucha por primera vez durante la redada, desempeñó un rol clave en la transmisión de este mensaje. Si los jugadores escuchan con atención, encontrarán mucha información sobre la conciencia de la ciudad. Pero, incluso cuando los jugadores no prestaban atención, el tratamiento del audio seguía transmitiendo el mensaje emotivo que buscábamos."
N/A3933"#commentary\cn_016_elis_lab.mp3" "[ Dhabih Eng ] El laboratorio de Eli vino después del laboratorio del Dr. Kleiner, lo que nos permitió comprender mejor cómo configurar y diseñar escenas coreográficas efectivas. Como resultado, creamos un escenario más complejo con más oportunidades de interacción con el jugador. Al tener a varios personajes haciendo lo suyo en el mismo espacio, se complicaba la puesta en escena, y fueron necesarias varias iteraciones y pruebas de juego para un funcionamiento adecuado. Nuestras pruebas revelaron que, en general, los jugadores querían ser parte de la escena, solo que necesitaban pistas sutiles para saber dónde tenían que interactuar. Por otro lado, si se distraían en otra cosa, la escena pausaba de manera sutil para esperar a que retomaran el hilo."
N/A3934"#commentary\cn_017_feel_free_to_look_around.mp3" "[Dhabih Eng] Equilibrar el deseo del jugador por explorar con los objetivos narrativos de la escena siempre fue un reto. Queríamos que la habitación estuviera llena de cosas interesantes que ver, pero muchos jugadores no exploraban hasta estar seguros de que no se perderían ninguna de las interacciones de los personajes. Por eso era importante que Eli le dijera al jugador que mirara a su alrededor a mitad de la escena, porque eso indicaba que era seguro explorar. Desde ahí podíamos activar una variedad de miniescenas personalizadas basadas en lo que llamaba la atención del jugador."
N/A3935"#commentary\cn_018_interstitial_scenes.mp3" "[ Eric Kirchmer ] A medida que avanzaban las pruebas del juego, encontrábamos áreas en las que los jugadores perdían de vista su objetivo, lo cual no es raro en un juego como Half-Life. Para solucionarlo, añadimos escenas intermedias más breves para ayudar a guiar a los jugadores en su camino y reforzar su objetivo. Después de terminar la mayor parte del desarrollo de nuestras escenas coreografiadas más grandes, como el laboratorio de Kleiner, montar estas escenas más breves resultó relativamente sencillo. Descubrimos que utilizar personajes en estos momentos funcionaba mucho mejor que recurrir a una narración pasiva o incluso a algún tipo de recordatorio integrado en un menú de pausa."
N/A3936"#commentary\cn_019_overwatch.mp3" "[ Josh Weier ] Durante el desarrollo, generamos la voz de Vigilancia con una herramienta gratuita de conversión de texto a voz. Pero, cuando se acercaba el lanzamiento, nos dimos cuenta de que no teníamos los derechos para utilizarla, así que hicimos audiciones con actores de doblaje para encontrar a alguien que pudiera igualar las cualidades que nos gustaban de las líneas generadas. No tardamos mucho en encontrar a Ellen McClain, cuya interpretación era exactamente lo que buscábamos. En sus sesiones, le reproducíamos las líneas generadas para que las imitara, aunque con su propio estilo. Al principio se mostró un poco sarcástica, dado que se le pedía que replicara una interpretación tan robótica. Pero años más tarde, cuando regresó para interpretar su icónico papel de GLaDOS en Portal, había encontrado la manera de integrar creativamente ese tono en su interpretación."
N/A3937"#commentary\cn_020_box_car_joe.mp3" "[Laura Dubuk ] Esta pequeña escena originalmente contaba con dos personajes humanos, pero más adelante en el desarrollo, sustituimos a uno de ellos por un vortigaunt. Queríamos mostrar que los vortigaunts coexistían con los humanos y también se resistían a la Alianza. También introdujimos su capacidad para curar al jugador, aunque no aprovechamos al máximo esa característica a lo largo del juego. Los vortigaunts se convirtieron en una herramienta narrativa útil para mantener los diálogos breves, ya que su mente de colmena justificaba su pleno conocimiento del mundo y de los objetivos del jugador. Esto significaba que no debían hacer preguntas, lo que evitaba el reto de escribir diálogos para un protagonista silencioso."
N/A3938"#commentary\cn_021_mossman.mp3" "[Marc Laidlaw ] Judith Mossman se basaba originalmente en un personaje que habíamos planeado para una sección de Half-Life 1. Esa sección se eliminó del juego base y se reutilizó en Uplink, pero sin el personaje. La consideramos el personaje más complejo de Half-Life 2. Sabíamos que íbamos a estar en una cuerda floja respecto a lo que el jugador sintiera por ella, incluso antes de Nova Prospekt, porque las fuentes en las que confía el jugador no están de acuerdo: a Eli le cae bien, pero a Alyx no. Reconocimos que había un límite de complejidad que podíamos lograr en las relaciones, pero sentimos que la dinámica entre madrastra e hija era algo que los jugadores entenderían. Estés de acuerdo o no con Mossman, ella está haciendo algo heroico. Se arriesga a ser una doble agente para obtener la información que necesita para proteger a Eli y Alyx. Simplemente no contaba con Gordon."
N/A3939"#commentary\cn_022_hands_free.mp3" "[ Matt Wright ] Cuando salió Half-Life 2, la mayoría de los juegos de disparos en primera persona daban al jugador un arma de fuego o un arma cuerpo a cuerpo desde el principio, pero nosotros optamos por que empezaran con las manos vacías. Sin armas, era más fácil enseñar al jugador las formas más novedosas de interactuar con el mundo y presentarle nuestra historia. Queríamos que el jugador pasara de ser un fugitivo a convertirse en el agresor, y armarlo en el momento adecuado creaba ese momento de forma natural. Cuando por fin consigue un arma, ya deja de huir. Dicen que a veces la mejor manera de ganar es alejarse, pero todos sabemos que eso no es cierto. La mejor manera es correr hacia algo mientras se le dispara."
N/A3940"#commentary\cn_023_metrocop_scene.mp3" "[Mike Dussault] Esta es otra escena diseñada para dejar claro que los de Protección Civil son los malos, excepto que esta vez el jugador tiene un arma y por fin puede hacer algo al respecto. Ese \"algo\" sale del cañón de un arma. Sabíamos que necesitábamos que el jugador se sintiera en lo cierto y este momento formaba parte de ello. La Protección Civil sigue siendo humana, a diferencia del resto de la Alianza del juego, por lo que sentimos que teníamos que hacer un esfuerzo adicional para asegurarnos de que las acciones del jugador se percibieran como justicia y no solo como un asunto de ira."
N/A3941"#commentary\cn_024_moving_the_gravity_gun.mp3" "[ Ted Backman ] Cuando se creó el primer prototipo de la pistola de gravedad, pensábamos dársela al jugador a mitad del juego. Pero a medida que avanzaban las pruebas, nos dimos cuenta de la potencia de su diseño y comprendimos que la pistola de gravedad y, lo más importante, la capacidad de lanzar hojas de sierra a las caras de los zombies, tenían que aparecer antes. Eso significaba que el laboratorio de Eli también tenía que aparecer antes. Fue un cambio significativo, pero crucial para el éxito de Half-Life 2. Es un buen recordatorio de que la narrativa y la jugabilidad están entrelazadas, y que ninguna de las dos puede tener prioridad; tienen que funcionar juntas."
N/A3942"#commentary\cn_025_buggy_birds.mp3" "[Adrian Finol] En una memorable prueba de juego de la Costa, un jugador regresó a su vehículo después de explorar una casa y vio por casualidad un pájaro volando. Le gritó al pájaro, diciéndole que se alejara de su buggy, quejándose de que los pájaros ensuciaban su auto en la vida real. Después de la prueba de juego, nos dimos cuenta de que era la primera vez que teníamos objetos separados del jugador que realmente le importaban. Lo vimos como una oportunidad para explorar, así que creamos un sistema para reproducir el momento que temía el jugador. Cuando el jugador deja su buggy solo durante un rato y está fuera de su vista, hacemos aparecer una gaviota en un lugar aleatorio del chasis del auto. Pasa el tiempo y la gaviota deja excrementos en la carrocería, y continúa hasta que el jugador regresa, momento en el que se va volando. Naturalmente, los testers querían limpiar su auto, así que añadimos la posibilidad de lavarlo al conducir por aguas poco profundas. El desarrollo ya iba muy avanzado, así que ya teníamos la tecnología necesaria y la función se implementó rápidamente. Es uno de esos casos en los que sabemos que solo un pequeño porcentaje de jugadores lo descubrirá, pero si podemos implementar este tipo de detalles de manera eficiente y tenemos suficientes, la mayoría de los jugadores se encontrarán con al menos uno."
N/A3943"#commentary\cn_026_bridge_gunship.mp3" "[Adrian Finol] Nos gustó mucho la pelea con la nave de guerra, a pesar de que fue complicado configurarla debido a la geometría del nivel. Al estar debajo del puente, la nave podía moverse libremente alrededor del jugador, utilizando las tres dimensiones para situarse por encima y por debajo en diferentes momentos. Las vigas proporcionaban mucha cobertura de alta frecuencia, lo que permitía que el fuego de la nave produjera un espectáculo visual y sonoro divertido y dinámico."
N/A3944"#commentary\cn_027_floor_is_lava.mp3" "[Adrian Finol] Crear una jugabilidad con conceptos ampliamente conocidos, como el suelo es lava, facilitó el entrenamiento. Nos gustó que nuestro sistema de física permitía mucha libertad creativa dependiendo de cómo los jugadores decidían abordarlo. Algunos construyeron pasarelas con muchos objetos, mientras que otros prefirieron usar solo sus dos láminas de metal favoritas. Algunos siguieron cuidadosamente el camino entre las rocas, preocupados por caerse, y otros se dirigieron directamente hacia la salida, posándose en objetos justo encima de la arena. Los estilos de juego variaban: algunos jugadores consideraban un fracaso si invocaban hormigas león y recargaban inmediatamente, mientras que otros disfrutaban trepando de nuevo las rocas para recuperarse. También nos gustó que fuera como un rompecabezas de navegación, pero que pudiera convertirse en una arena si los jugadores lo preferían; otros simplemente saltaban a la arena y luchaban hasta el final."
N/A3945"#commentary\cn_028_opportunistic_moments.mp3" "Algunos momentos memorables del juego provienen de la interacción entre múltiples sistemas, pero a veces nos damos cuenta de que estos momentos ocurren rara vez. Cuando eso sucede, deseamos que más jugadores los experimenten. Aquí hay una tensión: cuanto más sabemos que los jugadores se encontrarán con algo, más esfuerzo podemos dedicarle. Pero si parece demasiado artificial, el momento puede parecer forzado y es posible que los jugadores no respondan tan positivamente. La caída cinematográfica de la nave de guerra es un ejemplo en el que dimos un empujón, tratando de aumentar las posibilidades de que se produzca un momento memorable sin que sea demasiado obvio. El diseño de esta zona y las rutas de vuelo de la nave hacen que sea probable que el jugador y la nave estén en los lugares adecuados cuando esta cae. Si es así, activamos el choque de la nave contra los autos. Si no, cae de la forma habitual. Es totalmente lúdico, pero a los testers no pareció importarles cuando el momento se desarrolló bien."
N/A3946"#commentary\cn_029_assault_on_nova_prospekt.mp3" "[ Ariel Díaz ] Con un ejército de hormigas león que reaparecía infinitamente en la costa y atacaba una base fortificada de la Alianza, era difícil no intentar crear un nivel inspirado en Normandía. Nuestro prototipo inicial incluía trincheras que conducían a Nova Prospekt, con ametralladoras letales que obligaban al jugador y a sus hormigas león a permanecer dentro de las trincheras para sobrevivir. Era emocionante tener ametralladora y hormigas león saltando constantemente por encima de las trincheras. Pero, no pudimos hacer que funcionara dentro de nuestro presupuesto de rendimiento y, al final, tuvimos que omitirlo en favor de un diseño completamente diferente. Pero, las ametralladoras montadas se mantuvieron, ya que su letalidad resultó útil para animar a los jugadores a confiar en sus hormigas león."
N/A3947"#commentary\cn_030_buggy_physics.mp3" "[Charlie Brown] La física del buggy requirió mucho ensayo y error. Queríamos que se sintiera rápido, aunque su velocidad máxima era de solo unos 56 km/h, así que tuvimos que hacer algunos trucos para que funcionara. Añadimos fuerza vertical adicional al salto turbo y un poco de empuje hacia atrás al usar el freno de mano para derrapar. Sin eso, la baja velocidad hacía que el buggy no fuera divertido de conducir. Además, el mundo estaba lleno de caos impredecible gracias a los sistemas de física: los jugadores estaban destinados a chocar el buggy de todas las formas posibles, así que tuvimos que asegurarnos de que siempre pudieran salir. Esto requirió mucha experimentación y pruebas de juego. Al final, nos decidimos por una simulación bastante ridícula y poco realista que hacía que el buggy fuera más tolerante y más difícil de volcar. Su centro de gravedad es muy bajo y las ruedas, aunque parecen girar mucho, en realidad no lo hacen. Fue nuestro primer intento de simular físicamente un auto y aprendimos mucho de él. Gracias a eso, pudimos hacer que el muscle car del episodio 2 fuera mucho más fácil de conducir."
N/A3948"#commentary\cn_031_the_bridge.mp3" "[Charlie Brown] Esta sección del puente se inspiró en el puente de Deception Pass, muy cerca de la oficina de Valve. Inicialmente, construimos la sección como un rompecabezas de navegación, pero poco a poco fuimos añadiéndole más elementos de juego. También se convirtió en el principal caso de prueba para la fricción del borde del jugador. En nuestro sistema de movimiento, aumentamos sutilmente la fricción en la desaceleración del jugador conforme se acerca al borde de una superficie. Los jugadores nunca lo han notado, probablemente porque se alinea de forma natural con su objetivo de detenerse en el borde para mirar hacia abajo, lo que coincide con la tendencia humana de moverse más despacio y con más cuidado cerca de un precipicio. Pero es una característica fundamental para esta parte del juego. Lo sabemos porque, en un momento durante el desarrollo, lo rompimos accidentalmente y, de repente, todos nuestros testers comenzaron a caer y morir."
N/A3949"#commentary\cn_032_coast.mp3" "[ Chris Green ] Queríamos una sección amplia y abierta del juego para el buggy, pero aún necesitábamos una forma de limitar el movimiento del jugador. Elegir una costa nos proporcionó un límite natural a lo largo de un lado del mapa, sin dejar de transmitir una sensación de amplitud y apertura. También ayudó a visualizar los efectos de la extracción de los recursos de la Tierra por parte de la Alianza. Los testers seguían intentando nadar hacia el mar, así que añadimos sanguijuelas para disuadirlos. Las sanguijuelas no podían ser un enemigo real y evitable contra el que los jugadores sintieran que podían luchar, así que son un tanto mágicas. Los jugadores entendieron en general que estaban traspasando los límites del juego, así que no las desarrollamos en exceso."
N/A3950"#commentary\cn_033_grenade_house.mp3" "[Dave Riller] Gran parte de Half-Life consiste en ofrecer a los jugadores experiencias de combate más o menos novedosas en cada esquina, aunque solo sean pequeños ajustes respecto a las anteriores. No todas tienen que ser desafíos de habilidad; a veces pueden ser simplemente momentos divertidos en los que el jugador puede disfrutar. Esta casa de granadas es uno de esos momentos, con la particularidad de que hemos invertido la configuración habitual. En lugar de dejar que el jugador lance granadas a los enemigos que están abajo, hemos colocado a los enemigos arriba. La caja de granadas ilimitadas es una forma un poco torpe de animar a los jugadores a participar en el escenario, pero su invulnerabilidad también garantiza que el jugador pueda seguir subiendo al piso de arriba, incluso si ha volado todo lo demás."
N/A3951"#commentary\cn_034_buggy_training_course.mp3" "[David Sawyer] Esta sección de entrenamiento se diseñó para que el jugador pudiera practicar con su buggy. Cuando se lanzó Half-Life 2, este nivel de simulación física en un vehículo era novedoso, por lo que queríamos dar a los jugadores amplias oportunidades para experimentar con él. Además, el jugador acababa de salir de los estrechos confines de Ravenholm, y nos gustaba darle la recompensa contrastante de poder moverse rápidamente por un gran espacio, sintiendo seguridad dentro de un auto. Nos aseguramos de que fuera necesario un salto turbo para salir de esta zona, lo que servía también como prueba para comprobar que habían alcanzado un nivel de comodidad en la conducción y que no dejaban atrás su buggy."
N/A3952"#commentary\cn_035_ambush.mp3" "[ David Sawyer ] Uno de los retos generales de un FPS al estilo Half-Life es que el jugador avanza constantemente hacia espacios que no conoce. Esto significa que, cuando está en combate, está en zonas desconocidas y no sabe cómo abordar la lucha. Utilizamos muchos métodos diferentes para ayudar al jugador con este problema, y esta emboscada es un ejemplo. Al llegar, el jugador lucha contra un grupo de la Alianza entre estas casas. Durante la lucha y la exploración posterior, el jugador tiene la oportunidad de aprender la distribución del escenario. Luego, cuando el jugador explora el ático, generamos una segunda oleada de la Alianza. En esa segunda lucha, el jugador tiene ahora la ventaja de conocer la distribución, lo que le permite tomar decisiones más tácticas para defenderse de los emboscadores."
N/A3953"#commentary\cn_036_bugbait_training.mp3" "[ David Sawyer ] Terminamos con este torpe entrenamiento con cebos para insectos porque se nos acabó el tiempo, pero los jugadores tenían que entender la herramienta para que el diseño de Nova Prospekt funcionara. Siempre intentamos añadir suficiente sabor y contexto al entrenamiento para que no se sienta como tal, sino como una parte natural de un nuevo descubrimiento. Pero, en este caso no lo conseguimos del todo. Por obvio que parezca, los jugadores no captaban intuitivamente el concepto de cebo para insectos. Aquí, el juego ya está muy avanzado y los jugadores tienen experiencia lidiando con enemigos. Antes de añadir algún entrenamiento, los primeros testers que recogieron cebo para insectos pasaron al siguiente nivel y dispararon instintivamente a la primera hormiga león que vieron, porque eso les había funcionado antes. Half-Life tiende a fomentar el disparar primero, preguntar después, y cuando los jugadores llegaban a Nova Prospekt, no se les ocurría lanzar el cebo a los soldados de la Alianza, sino que confiaban en sus armas. Por lo tanto, necesitábamos este entrenamiento no solo para mostrar cómo funciona el cebo, sino para que vieran que las hormigas león no los iban a atacar."
N/A3954"#commentary\cn_037_vortigaunt_extraction.mp3" "[ Dhabih Eng ] Esta arena presentó algunos problemas de diseño complicados por un par de razones. Primero, el guardia es un enemigo que solo lucha cuerpo a cuerpo, por lo que no podíamos permitir que el jugador llegara a zonas a las que el guardia no pudiera seguirle. Probamos con algunos ataques a distancia, pero no nos gustaron los resultados: su ataque de escupir sustancia viscosa, por ejemplo, terminó siendo ridículo. El único ataque que no era cuerpo a cuerpo que sobrevivió fue su habilidad para lanzar objetos físicos al jugador, pero esto requiere que los objetos estén al alcance, lo que no siempre se puede garantizar. El segundo reto era garantizar que, independientemente de dónde muriera el guardia, el vortigaunt pudiera llegar hasta su cadáver. Esto era esencial, ya que el juego no puede continuar si el vortigaunt no puede extraer el cebo para insectos."
N/A3955"#commentary\cn_038_dropship_deployment.mp3" "[Doug Wood] Desplegar soldados desde las naves era complicado, porque requería que los PNJ aparecieran dentro de otro objeto sólido. Para que salieran al exterior, donde podían empezar a moverse con normalidad, se reproducía inmediatamente una animación en la que saltaban del contenedor en el momento en que aparecían. Cuando eso funcionó, nos encontramos con otro problema: los jugadores más sagaces se limitaban a esperar fuera del contenedor y disparaban a los soldados durante la animación de salida. Para contrarrestarlo, añadimos una torreta al contenedor para defender a los soldados mientras salían. No impide por completo que un jugador se aproveche, especialmente si utiliza un arma indirecta como una granada o algo similar, pero nos pareció realista y una contramedida fiel a la vida real, que alguien que piensa estratégicamente podría tomar."
N/A3956"#commentary\cn_039_laser_guided_rpg.mp3" "[Eric Smith] La función de guía láser del RPG nos dio muchos dolores de cabeza porque era difícil de enseñar. Muchos testers disparaban el RPG y luego se cubrían inmediatamente, lo que significaba que no veían la trayectoria del cohete. Y lo que es peor, no se daban cuenta de que el cohete daba la vuelta para volver hacia ellos. Probamos varios elementos del HUD e indicadores de puntos láser para ayudar, pero descubrimos que la mayoría de los jugadores los pasaban por alto y se centraban en el enemigo. Hicimos todas las mejoras que pudimos, como enfatizar la función en el discurso de Odessa y mejorar el audio y las imágenes relacionadas con la forma en que la nave derriba los disparos directos del RPG. Aunque con esto algunos jugadores sí comprendieron la función, nunca llegamos al punto en el que la mayoría lo entendiera. Incluso consideramos eliminar la función por completo, pero el combate con la nave sin ella era mucho menos interesante. La guía láser obligaba al jugador a mantener la nave a la vista mientras el cohete estaba en vuelo, pero eso también significaba que la nave tenía línea de visión hacia atrás, lo que creaba una tensión que nos encantaba."
N/A3957"#commentary\cn_040_performance_constraints.mp3" "[Eric Smith] Para la última arena de la Costa, imaginamos un gran final en el que el jugador y un escuadrón de ciudadanos resistirían contra oleadas de soldados de la Alianza, culminando en una batalla con naves. Lamentablemente, el costo computacional de tener soldados y aliados amigables moviéndose por el terreno significaba que la batalla se reducía continuamente para ajustarse a nuestro presupuesto de rendimiento. Cuando llegamos al punto de presentar un único escuadrón de soldados en cada momento, ya íbamos retrasados en el desarrollo. Era demasiado tarde para realizar cambios a gran escala en la arena para recibir a más enemigos, así que tuvimos que rediseñar la lucha para mantener el número de soldados al mínimo."
N/A3958"#commentary\cn_041_lighthouse_gunship.mp3" "[ Ido Magal ] El escenario de la nave nos costó bastante trabajo desarrollarlo tal y como lo habíamos imaginado: queríamos que fuera como en una película. En la versión cinematográfica, una nave disparaba a través de las ventanas mientras el protagonista ascendía por el faro, anticipándose a sus movimientos. Para simular esa anticipación en el juego, configuramos una compleja serie de volúmenes de activación a lo largo de la escalera. Al detectar que el jugador sube, le indican a la nave que elija una nueva trayectoria de vuelo que coincida con la altitud del jugador. Los gatillantes también activan blancos en las ventanas más cercanas al jugador, que son objetos invisibles del juego que la IA enemiga percibe inmediatamente como hostiles, y hacen que la nave dispare contra las ventanas. Esta combinación de IA y secuencias de comandos es fundamental para los escenarios de combate de Half-Life. La IA gestiona el comportamiento general y adaptativo de los PNJ, mientras que los scripts personalizan los requisitos únicos de cada escenario."
N/A3959"#commentary\cn_042_crane.mp3" "[Jakob Jungels] La grúa requirió muchos ajustes para que funcionara bien. Algo que necesitaba generar tanta fuerza física siempre era arriesgado, dadas las limitaciones de nuestra física de cuerpos rígidos y nuestra tecnología de destrucción. Por ejemplo, el imán nunca iba a satisfacer plenamente las expectativas de los jugadores para algo tan pesado. Pero como la grúa era fija, pudimos elegir cuidadosamente todo lo que había dentro de su alcance y ajustarlo según fuera necesario. Afortunadamente, la mayoría de los jugadores no parecieron notar sus imperfecciones, probablemente debido a la novedad de interactuar con algo así en un entorno físico vagamente realista."
N/A3960"#commentary\cn_043_flashlight_power.mp3" "[ Jeff Lane ] La decisión de que tanto el esprint como la linterna compartieran la energía del traje HEV fue muy controversial en Half-Life 2. Inicialmente, solo el esprint utilizaba la energía del traje, y tenía sentido, pues se trataba de un breve aumento de velocidad. La linterna, por otro lado, se podía utilizar de forma indefinida. Pero las pruebas revelaron un problema: los jugadores abandonaban las zonas oscuras sin darse cuenta de que la linterna seguía encendida. En zonas abiertas y bien iluminadas, como la Costa, nuestro presupuesto de rendimiento no soportaba que la linterna estuviera encendida continuamente, y necesitábamos una forma de apagarla sin la intervención del jugador. Limitar su potencia era una solución sencilla, con la ventaja de añadir tensión en la oscuridad. El reto entonces era: ¿qué recurso debía utilizar? Ya teníamos la energía del traje y no queríamos saturar la interfaz de usuario con un nuevo recurso solo para la linterna. Jugamos con la idea de que otras habilidades de los jugadores utilizaran la energía del traje, pensando que sería interesante que los jugadores tuvieran que elegir entre ellas. Este es un buen ejemplo de que el diseño de juegos consiste en elegir entre soluciones imperfectas. No queríamos que el esprint y la linterna compartieran recursos, pero tampoco que múltiples recursos saturaran la interfaz. En el episodio 2, al no haber planes de añadir nada más que consumiera energía, decidimos darle a la linterna su propio recurso independiente."
N/A3961"#commentary\cn_044_open_world_loot.mp3" "[ Jeff Lane ] La amplitud de la Costa nos planteó un nuevo problema para distribuir las recompensas. En Half-Life, solemos recompensar a los jugadores por explorar. Si ves el camino a seguir, pero te fijas en algo a un lado, probablemente haya algo útil si te tomas el tiempo de buscarlo. Cuando empezamos a probar nuestros mapas de la Costa, escondimos las recompensas en los rincones de las zonas exteriores. Pero, esto empeoró la experiencia con el buggy. Los espacios abiertos significaban que siempre había muchas áreas pequeñas que parecían contener algo, y los jugadores se detenían constantemente y salían del buggy para buscar. Se volvió tedioso e interrumpía la diversión del nivel, así que eliminamos esas recompensas dispersas. Pero esto planteó un nuevo problema: ¿cómo le decimos al jugador cuándo vale la pena salir del buggy? Después de pensarlo, establecimos una regla: cualquier tipo de construcción humana siempre vendría acompañada de contenido de juego y recompensas por exploración, mientras que las áreas puramente naturales se dejarían vacías. No podíamos decirles esto directamente a los jugadores, pero coincidía con sus suposiciones naturales, y lo reforzamos de manera consistente con áreas como esta."
N/A3962"#commentary\cn_045_gas_station.mp3" "[ Jeff Lane ] Teníamos grandes planes para este encuentro. Imaginamos construir una gasolinera en la que el jugador lucharía, probablemente encendiendo los tanques de gasolina y prendiendo fuego a todo. Imaginamos al jugador alejándose en su auto de un incendio devastador. Pero el presupuesto y el rendimiento eran limitaciones muy estrictas en 2003, y la gasolinera tuvo que hacerse cada vez más pequeña y sencilla para encajar en los grandes niveles de la Costa. Nuestros planes para un sistema de fuego dinámico no se materializaron, y construirlo ya no tenía sentido: siempre hay un límite en cuanto al trabajo que podemos justificar para un solo encuentro. Al final, lo único que queda de nuestra visión original son los tanques de gasolina explosivos."
N/A3963"#commentary\cn_046_buggy_introduction.mp3" "[ John Cook ] Queríamos algo más atractivo para la presentación del buggy que simplemente hacer que el jugador se subiera y se marchara conduciendo. La grúa nos ayudó a conseguirlo. Era fundamental que los jugadores aprendieran a recuperar el buggy cuando volcaba, y esta secuencia los obligaba a enfrentarse a esa situación. Entrenar bajo presión siempre es complicado, pero queríamos enfatizar la infestación de hormigas león como la razón para permanecer dentro del buggy. Por eso, mantuvimos activa la amenaza de las hormigas león y pusimos un par de ciudadanos con armas montadas para dar apoyo. Una pequeña ventaja: los jugadores también tienen la experiencia de ser levantados por la grúa, justo antes de poder manejar una."
N/A3964"#commentary\cn_047_crossbow.mp3" "[ John Cook ] Esta es la primera oportunidad que tiene el jugador de obtener la ballesta en el juego y, en retrospectiva, es un tanto sorprendente que no la hayamos bloqueado. Es muy posible que el jugador pase de largo sin darse cuenta. Para que eso sea menos probable, colocamos la barricada y el mirador para animar a los jugadores a salir del buggy, momento en el que verán la ballesta y la caja de objetos. Las pruebas de juego demostraron que casi todos los jugadores se detuvieron y recogieron el arma, pero este es un caso en el que la diferencia entre las pruebas de juego y el juego real puede ser importante. Es posible que un tester que lleva jugando desde el inicio de la Costa no esté tan cansado de explorar como alguien que lleva jugando desde el principio del juego. Por lo tanto, colocamos otra ballesta unos niveles más adelante, directamente en el camino del jugador en Nova Prospekt."
N/A3965"#commentary\cn_048_rollermines.mp3" "[ Josh Weier ] Las minas rodantes se crearon para satisfacer la necesidad de un enemigo que pudiera amenazar a los jugadores mientras conducían el buggy. Como el jugador en el buggy era esencialmente una entidad simulada físicamente, pensamos que sería interesante tener también un enemigo simulado físicamente. La robosierra ya nos había mostrado que este enfoque podía dar lugar a un enemigo con muchas interacciones interesantes con el mundo, por lo que creamos la mina rodante, una bola cuyo movimiento se basa completamente en la generación de torque sobre sí misma, y repetimos su comportamiento hasta que fue divertido conducir contra ella. Las minas rodantes no son peligrosas para el buggy, pero si se acumulan, pueden convertirse en un problema, especialmente cerca de un acantilado. También nos aseguramos de que funcionaran bien cuando el jugador está a pie, lo que permite a los diseñadores de niveles sacarles un poco más de partido."
N/A3966"#commentary\cn_049_sandtrap_thumper.mp3" "[ Laura Dubuk ] Los barriles explosivos se proporcionan a los jugadores para que los usen contra las hormigas león mientras permanecen a salvo bajo la protección del Thumper. Pero también se utilizan como pista para el próximo encuentro con la hormiga leónn guardia, en el que los jugadores suelen emplear tácticas similares para ganar la batalla. Las acciones opcionales de los jugadores, como lanzar explosivos con la pistola de gravedad, pueden olvidarse si no se utilizan con regularidad. Con la amplia gama de opciones ofensivas que ofrecemos, no hay garantía de que hayan utilizado esta habilidad recientemente. Por eso, aquí les sugerimos sutilmente que la vuelvan a incluir en su arsenal antes de enfrentarse al guardia."
N/A3967"#commentary\cn_050_coast_kickoff.mp3" "[ Marc Laidlaw ] Esta escena intersticial se incorporó en una fase avanzada del desarrollo para conectar Ravenholm con la Costa. ¿Notas una tendencia? Gran parte del tejido conectivo de nuestros juegos se crea en una fase tardía. En este caso, eso significó recortar gastos siempre que fue posible; ni siquiera tuvimos tiempo de animar a Alyx en el monitor. Este tipo de escenas siempre suponen un reto a la hora de hacerlas interesantes, y en este caso no lo conseguimos. Es un buen ejemplo de lo que ocurre cuando se trata a los PNJ como meros indicadores, sin añadirles carácter ni a ellos ni a la escena. El resultado es un momento olvidable en el que se ven las costuras del juego. Pero así es el desarrollo: tienes el tiempo limitado y debes decidir en qué invertirlo. El laboratorio de Kleiner y el de Eli eran mucho más importantes, así que ahí es donde centramos nuestros esfuerzos."
N/A3968"#commentary\cn_051_odessa_cubbage.mp3" "[ Marc Laidlaw ] Odessa Cubbage es un ejemplo del tipo de personaje secundario que nos funciona bien. Es un sujeto divertido con detalles entretenidos, que vive en su propia burbuja. Como no sale de su escenario, tiene libertad para ser lo suficientemente exagerado como para destacar. Empezamos con su modelo, que fue reutilizado de una sección eliminada del juego, y le pusimos el nombre del título de un correo basura que recibimos. El modelo era originalmente un pescador noruego, y no encajaba del todo como inglés, así que le pusimos un bigote, y en ese momento nació el personaje de Odessa. Definitivamente, es un charlatán, y todo en él es falso: su acento, su bigote, todo. Nunca se pondría en peligro, lo que lo convierte en la persona perfecta para entregarle a Gordon el lanzagranadas y explicarle exactamente cómo usarlo."
N/A3969"#commentary\cn_052_28_transitions_later.mp3" "[ Marc Laidlaw ] Después de encadenar varios niveles con túneles oscuros como espacios de transición, nos dimos cuenta de que podíamos subvertir las expectativas de los jugadores construyendo otro que pareciera una transición, pero que en realidad contuviera algo más. Como todo el mundo, vimos Exterminio en 2002, nos encantó e inmediatamente quisimos crear un encuentro con zombies cada vez más intenso en uno de nuestros túneles oscuros. Lo conseguimos rápidamente y quedamos muy satisfechos con el resultado. Años más tarde, conocimos a Alex Garland, el guionista de la película. Había jugado y disfrutado de Half-Life 2 y le confesamos que su película había inspirado esta sección."
N/A3970"#commentary\cn_053_finest_mind_of_his_generation.mp3" "[ Marc Laidlaw ] Aquí hay otra pequeña escena intersticial que terminó funcionando bien. El único requisito para este momento era enseñar al jugador a mantenerse alejado de la arena. En las escenas anteriores, todavía nos centrábamos simplemente en hacerlas funcionales, pero cuando llegamos a esta, ya nos sentíamos más cómodos y empezamos a disfrutar del proceso de dedicar más atención a estos momentos. Al hacerlo, llevamos a los personajes más allá de ser meros indicadores, creando algo más interesante y entretenido. Tras el lanzamiento, Lazlo consiguió un gran número de seguidores, lo que nos recordó lo difícil que es predecir qué es lo que va a gustar a los jugadores."
N/A3971"#commentary\cn_054_bridge_playtesting.mp3" "[ Matt Boone ] La sección del puente siempre fue uno de los puntos álgidos de las pruebas, y los testers siempre reaccionaban con mucha intensidad. La tensión que sentían al avanzar lentamente por las vigas se reflejaba en sus movimientos. Con el tiempo, añadimos más desafíos al recorrido y las pruebas se volvieron aún más entretenidas de ver. Desde el tren que traqueteaba al cruzar el puente y sacudía al jugador, hasta un cangrejo sorpresa en una cabaña que parecía un refugio seguro a mitad de camino. Nos dio un poco de culpa disfrutar del evidente estrés de los testers, pero tampoco somos unos monstruos: una vez que los jugadores cruzaban el puente, por fin podían respirar aliviados, desactivaban el escudo de la Alianza y entonces se daban cuenta de que tenían que volver por debajo. Nos preocupaba que se aburrieran en el segundo viaje, así que añadimos una nave para que les hiciera compañía en las vigas."
N/A3972"#commentary\cn_055_thumper_final_stage.mp3" "[ Matt Boone ] Nos gustó la fase final de los thumpers, donde se invierte su propósito. Aquí, en vez de ser una herramienta de seguridad, actúan como bloqueadores del ejército de hormigas león del jugador. Quiza debimos haber incorporado un entrenamiento más exhaustivo con los thumpers antes de llegar a este punto. Si bien era aceptable que los jugadores solo entendieran parcialmente los thumpers en los primeros niveles de la Costa, ahora hay mucho más en juego, ya que los jugadores también están probando el cebo por primera vez. Los jugadores que no se dan cuenta de que este primer thumper impide que sus hormigas león avancen, pueden malinterpretar cómo funciona el cebo para insectos. Si lanzan el cebo a los soldados del primer búnker y no llegan hormigas león, pueden llegar a la conclusión de que el cebo no es fiable o no funciona como se esperaba, y volver a utilizar sus armas."
N/A3973"#commentary\cn_056_buggy_tools.mp3" "Queríamos que el buggy fuera más que un simple medio de transporte, así que decidimos equiparlo con un arma. Elegimos el cañón Tau, un arma de Half-Life 1 que nos gustaba, pero a la que no le habíamos encontrado lugar en Half-Life 2. El cañón Tau puede disparar a través de las paredes, lo que complica el diseño de los niveles, por lo que lo limitamos a la sección de la Costa. Cuando se introducen armas que atraviesan paredes, el diseño de los niveles se vuelve mucho más complicado. Además, montamos una caja de municiones en la parte trasera del buggy, lo que proporciona al jugador munición ilimitada para el subfusil en toda la sección de la Costa. Esto resultó especialmente útil para los testers que tenían dificultades con las infinitas hormigas león que aparecían en la arena."
N/A3974"#commentary\cn_057_antlion_guard.mp3" "[ Matt Wright ] En casos excepcionales, los jugadores podían estar en la situación de no poder matar a la hormiga león guardia en esta arena. Esto podía pasar si se quedaban sin munición, si malgastaban todos los objetos físicos disponibles y no tenían nada que lanzar con el cañón de gravedad. Para solucionarlo, añadimos un ciudadano en la torreta montada sobre la puerta como medida de seguridad, para que el jugador atascado pudiera apoyarse en él para matar al guardia."
N/A3975"#commentary\cn_058_terrain_and_performance.mp3" "[ Mike Dussault ] Nuestro presupuesto de rendimiento solía ser una limitación importante en el diseño del combate, y más aún en terrenos irregulares. Cuando los PNJ se mueven, ejecutan varias pruebas espaciales para determinar si pueden recorrer con seguridad la ruta elegida. Para hacernos una idea, es como si no pudieran ver y estuvieran moviendo un bastón constantemente para comprobar si el camino está despejado. El costo de rendimiento de estas comprobaciones aumenta con la complejidad de la geometría del mundo. Nuestro sistema de desplazamiento del terreno crea superficies irregulares utilizando muchos polígonos, muchos más que los suelos perfectamente planos que se encuentran en otros lugares. Esto significa que los PNJ consumían más recursos en la Costa que en otras zonas, y esa limitación dictó la escala de muchos encuentros en esta sección del juego."
N/A3976"#commentary\cn_059_area_portals.mp3" "[ Mike Dussault ] Uno de los retos de rendimiento a los que nos enfrentamos en la Costa fue el manejo de espacios abiertos que incluían edificios con interiores muy detallados, o al menos detallados según los estándares de 2003. Cuando el jugador estaba fuera, queríamos destinar la mayor parte posible de nuestro presupuesto al renderizado de ese espacio, sin perder recursos en los interiores de los edificios. Pero, a menos que estuviéramos dispuestos a tapar todas las ventanas y puertas, el jugador aún podía ver el interior. Para resolverlo, creamos una función llamada portales de área y colocamos uno en cada ventana y puerta abierta. Un portal de área calcula previamente una imagen plana del interior del edificio. Durante el juego, cuando el jugador se encuentra a cierta distancia, el portal de área muestra esta imagen precalculada sobre la ventana o la puerta, lo que nos permite omitir el renderizado del interior real. A medida que el jugador se acerca, realizamos un suave fundido entre la imagen del portal de área y el contenido real del edificio. Con un uso cuidadoso, los portales de área nos ayudaron a cumplir nuestros objetivos de rendimiento en la Costa, junto con alguna que otra puerta que se cerraba al cruzarla."
N/A3977"#commentary\cn_060_buggy_removal.mp3" "[ Miles Estes ] Cuando llegamos al punto en el que el jugador tenía que dejar atrás el buggy, tuvimos que ser muy explícitos. Durante la Costa, los jugadores dejaban el buggy y luego volvían por él, por lo que los testers intentaban traérselo si veían que había la mínima posibilidad. Esta escena del garaje tenía como objetivo indicarle claramente al jugador ha terminado de conducir y que seguirá a pie."
N/A3978"#commentary\cn_061_d2_coast_04.mp3" "[ Randy Lundeen ] Este mapa fue, en realidad, la primera zona de la Costa que construimos, antes de que existieran la grúa y otros elementos. El lecho marino drenado y los barcos oxidados fueron algunas de las primeras piezas de dirección artística que desarrollamos. Años más tarde, mostramos el mapa en nuestra demostración del E3 de 2003, aunque en ese momento aún se estaba definiendo gran parte de la jugabilidad. Como resultado, cuando comenzamos a construir toda la sección de la Costa, esa demostración se convirtió en una visión útil para nuestro trabajo."
N/A3979"#commentary\cn_062_transition_tunnels.mp3" "[ Randy Lundeen ] Para crear la Costa, tuvimos que desarrollar una forma de gestionar las transiciones entre niveles. Para pasar de un nivel a otro, necesitamos guardar todo lo que hay en el espacio de transición cuando el jugador abandona el primer nivel y restaurarlo en el siguiente nivel después de cargarlo. Es fundamental que también guardemos y restauremos todo lo que el jugador puede ver en el área de transición, incluso si se encuentra fuera del espacio en sí. Por este motivo, nuestro objetivo es que los espacios de transición sean lo más pequeños y cerrados posible. En la mayor parte del juego, una habitación pequeña funciona bien para este propósito, pero no en la Costa. Tras varios experimentos, nos decidimos por túneles oscuros. Además de poder reutilizarlos de forma creíble, podíamos añadir una luz brillante al final para ocultar el hecho de que no podemos renderizar lo que hay delante del jugador, porque forma parte de un nivel completamente diferente."
N/A3980"#commentary\cn_063_sniper_alley.mp3" "[ Robin Walker ] Esta sección del juego se añadió en una fase avanzada del desarrollo, después de que trasladáramos el laboratorio de Eli y Ravenholm para que precedieran a la Costa. Aunque se podría pensar que creamos el juego de forma lineal, en realidad nos dividimos en tres grupos diferentes y trabajamos en paralelo en distintas secciones, empezando por la parte central del juego. La primera fase de cada grupo se centró en definir el núcleo de su sección antes de pasar a la siguiente. Luego, cuando tuvimos una versión preliminar de todo el juego, volvimos a revisar cada sección para pulirla, añadiendo elementos exitosos de otras áreas y eliminando lo que no funcionaba. En algunos casos, como en Ravenholm, se movieron secciones enteras. Luego, después de reubicar Ravenholm, necesitábamos una nueva pieza para conectarla con la Costa, que es el área a la que estás entrando ahora. Dadas las limitaciones de tiempo, esta breve sección se construyó utilizando elementos de juego existentes y probados, como francotiradores y soldados de la Alianza."
N/A3981"#commentary\cn_064_battery_finding.mp3" "Con el aumento de la densidad de objetos en los espacios de juego de Half-Life 2, pensamos que sería interesante que los jugadores buscaran un objeto específico, especialmente si había alguna lógica en cuanto al lugar donde se podía encontrar. De esta manera, los jugadores podían localizar el objeto mediante una observación cuidadosa y deducción, o simplemente buscando por fuerza bruta en la zona. Como ya teníamos modelos de autos y baterías, lo más natural era crear un pequeño depósito de chatarra para que los jugadores lo exploraran. También escondimos un par de baterías adicionales en lugares inesperados, para los jugadores que optaran por el método de la fuerza bruta. Al igual que con otros acertijos de objetos, este necesitaba un sistema de seguridad por si los jugadores perdían las baterías. Puedes intentar tirarlas por el acantilado si quieres ver qué pasa."
N/A3982"#commentary\cn_065_boathouse.mp3" "[ Scott Dalton ] En Half-Life 1, descubrimos que podíamos sacar mucho provecho de los escenarios en los que diferentes enemigos controlados por IA luchaban entre sí. A los jugadores les divierte verlos enfrentarse, y es mucho más fácil observar el comportamiento del enemigo cuando no te está atacando a ti. Este primer encuentro entre las hormigas león y los soldados de la Alianza está diseñado para ser una oportunidad divertida de embestir con el buggy, pero también sirve para destacar el thumper. Al ver a los soldados usar el thumper contra las hormigas león, esperábamos que más jugadores comprendieran su propósito. Nos gustó cómo los soldados demostraron la importancia de permanecer cerca del thumper mientras luchaban contra las hormigas león."
N/A3983"#commentary\cn_066_buggy_theft.mp3" "[ Scott Dalton ] Cuando creamos el final de la Costa, decidimos que la Alianza robara el buggy del jugador. No tiene sentido desde el punto de vista lógico, pero después de ver tantas pruebas de juego en las que los jugadores desarrollaban un fuerte apego por su buggy, quisimos jugar con esa conexión emocional. Cuando implementamos el robo, los testers se pusieron a gritarles a los de la Alianza por robarles su vehículo, lo cual tomamos como señal de éxito. El soldado que dispara desde lo alto del acantilado solo está ahí para atraer la mirada del jugador hacia arriba, lo que activa el detector de mirada, generando la nave que se lleva el buggy. Al verlo ahora, 20 años después, nos damos cuenta de lo ridículo que resulta."
N/A3984"#commentary\cn_067_snipers.mp3" "[ Ted Backman ] El equipo de Half-Life 2 nunca fue muy grande, por lo que siempre buscábamos formas de crear nuevas mecánicas de juego sin incurrir en altos costos de producción de recursos. El francotirador es un buen ejemplo. No tiene un modelo real, solo un rayo láser, por lo que no requirió apoyo artístico ni de animación. Cuando muere, simplemente genera un soldado de la Alianza marioneta y lo lanza por la ventana. A pesar de su simplicidad, conseguimos muchas mecánicas de juego únicas gracias a él. Nos gustó especialmente cómo interactuaba con los objetos físicos del mundo del juego. Los jugadores están acostumbrados a hacer explotar objetos cerca de los enemigos, por lo que nos pareció adecuado tener un enemigo que invirtiera esa dinámica cuando el jugador estaba a cubierto."
N/A3985"#commentary\cn_068_buggy_model.mp3" "[ Ted Backman ] El modelo del buggy pasó por muchas iteraciones antes de llegar a su versión final. Probamos varios diseños que satisfacían tanto nuestras necesidades artísticas como de simulación física, pero entonces nos encontramos con un problema inesperado: muchos testers, incluso jugadores experimentados de FPS, se mareaban al conducirlo. Además de algunos ajustes en la simulación, descubrimos que alterar el modelo del buggy ayudaba: cuanto más ocultaba el modelo el mundo, peor era el mareo, así que empezamos a eliminar partes del modelo, quitando cada vez más elementos de la carrocería hasta que los jugadores dejaron de marearse. En concreto, poder ver el suelo a través del chasis ausente supuso una diferencia notable."
N/A3986"#commentary\cn_069_antlion_design.mp3" "[ Ted Backman ] En algunos de los primeros diseños del juego, teníamos planes para varias razas alienígenas principales, siendo la Alianza solo una de ellas. Otra de las razas era una especie religiosa de insectoides, de la que formaban parte las hormigas león. Más tarde, al desarrollar la Costa, empezamos a verlos más como plagas que llegaban a través de los portales de Xen, junto con los cangrejos y otras criaturas. Aunque en realidad no son de Xen, infestan todos los rincones del mundo al que llegan, muy parecidos a las cucarachas."
N/A3987"#commentary\cn_070_explosive_barrels.mp3" "[ Brian Jacobson ] Aquí presentamos los barriles explosivos, un elemento básico de los juegos de disparos en primera persona, pero con un nuevo giro: el segundo disparo de pistola prende fuego al barril, lo que inicia una detonación temporizada. Un tercer disparo detonará el barril inmediatamente. De esta manera, los jugadores pueden retrasar la explosión o activarla de inmediato, dependiendo de la situación. Por ejemplo, tal vez quieran darle un barril explosivo a una lapa y luego dispararle dos veces como una forma práctica de eliminarlas en grupo. La explosión retardada también provocaba reacciones en cadena más interesantes entre varios barriles. Los barriles explosivos eran los favoritos de los fans de la serie, pero también de los diseñadores de niveles, para quienes un barril extra nunca está de más."
N/A3988"#commentary\cn_071_ragdoll_magnets.mp3" "[ Dario Casali ] La física de Half-Life 2 nos dio una serie de herramientas para lograr que el combate fuera más emocionante. Por ejemplo, cuando los enemigos fallan al disparar al jugador, redirigimos sutilmente sus disparos hacia objetos rompibles cercanos, lo que añade caos y crea esa sensación de película de acción. También empleamos la física para añadir pistas. Creamos lo que llamamos marionetas imanes a lo largo del juego para hacer que los cadáveres de los enemigos cayeran de formas interesantes y dramáticas, como desde cornisas o sobre las vías del tren."
N/A3989"#commentary\cn_072_helicopter_peekaboo.mp3" "[ Dave Riller ] Queríamos que el helicóptero de ataque de la Alianza fuera el antagonista a lo largo del capítulo. El implacable helicóptero se convirtió en un personaje por derecho propio. Aquí, si escuchas y miras hacia arriba, puedes oír su motor y verlo volar a lo largo de las vías del tren y alejarse en la distancia. Esta primera visión es un pequeño presagio, y su presencia se hace más pronunciada con el tiempo, hasta que, finalmente, te enfrentas a él."
N/A3990"#commentary\cn_073_iterative_passes.mp3" "[ David Speyrer ] Algunos capítulos del juego, como las secciones a pie de los canales y Ravenholm, se desarrollaron en varias etapas por diferentes equipos. Repartir los mapas de esta manera daba lugar a una mayor variedad de experiencias y densidad de momentos interesantes, ya que cada equipo añadía sus toques únicos a los mapas. En la parte a pie de los canales, la primera pasada estableció la dirección artística y la ruta del jugador, junto con las líneas generales de la experiencia y algunos momentos importantes. Sin embargo, la prueba de juego alfa realizada por todo el equipo identificó una tensión insuficiente y una experiencia algo monótona en esta parte. En nuestra segunda pasada, volvimos al mapa centrándonos exclusivamente en crear esa tensión y aumentamos considerablemente la densidad de los escenarios momento a momento."
N/A3991"#commentary\cn_075_pistol_design.mp3" "[ Josh Weier ] La pistola estándar es el caballo de batalla del juego, ya que no solo es la primera arma a distancia que aprendes a usar, sino que también te permite interactuar con la física y los objetos destructibles a una distancia segura durante todo el juego. Para que resulte más sensible y divertida de usar, la pistola emplea una mecánica de recarga única. El arma disparará tan rápido como el jugador pueda pulsar el botón, lo que significa que sentirá una respuesta instantánea a su acción y que, cuanto más rápido pulse, más rápido podrá disparar."
N/A3992"#commentary\cn_076_shatterglass.mp3" "[ Josh Weier ] Al diseñar los primeros niveles, en los que el jugador dispone de menos mecánicas, descubrimos que resulta igual de atractivo destacar nuevas características técnicas, como hicimos aquí con el vidrio rompible. Para el efecto de rotura, dividimos el vidrio en una cuadrícula con pequeños cuadrados rastrear cuáles estaban intactos o rotos, y hacer estallar secciones más grandes cuando ya no quedaban suficientes cuadrados conectados. Cada cuadrado se renderizó con una textura única basada en el estado de los cuadrados vecinos, creando bordes afilados y dentados entre el vidrio roto y el intacto. Aunque ahora romper vidrios es muy común en los juegos, era algo inusual cuando creamos Half-Life 2 y nos encantó el nivel de fidelidad y dinamismo que aportaba al juego."
N/A3993"#commentary\cn_077_lambda_caches.mp3" "[ Laura Dubuk ] Técnicamente, la primera caché lambda está en el laboratorio de Kleiner, pero esta es la primera que el jugador encuentra por su cuenta. Añadimos cachés lambda para fomentar la exploración y dar pistas a los jugadores sobre dónde podían encontrar recursos ocultos, con la ficción de que habían sido colocadas por la Resistencia como parte de su rebelión clandestina. En Half-Life, el contenido de las cajas de suministros estaba predeterminado por el diseño del nivel. En HL2, introdujimos cajas de objetos adaptables que proporcionan al jugador lo que le falta en ese momento, basándose en los objetivos de recursos establecidos por el diseñador de niveles."
N/A3994"#commentary\cn_078_scanners.mp3" "[ Kerry Davis ] Los escáneres planteaban un reto complicado en cuanto al diseño del juego. Aunque nos gustaba cómo su presencia distópica ayudaba a transmitir la ocupación de la Alianza como un estado opresivo y vigilante, en realidad no queríamos que dispararan al jugador. Apuntar al cielo para darle a un enemigo pequeño en movimiento que siempre tiene ventaja de elevación, era algo que no podíamos volver divertido. Como nos encantaba su papel en la historia, decidimos que, en combate, los escáneres servirían principalmente como ojos, alertando a los enemigos cercanos de la presencia del jugador, una característica que reforzamos con efectos de sonido de los soldados. Más allá de eso, solo podrían incomodar al jugador con luces brillantes y, ocasionalmente, lanzarse en picado después de recibir suficiente daño."
N/A3995"#commentary\cn_079_surface_properties.mp3" "[ Ariel Díaz ] Reproducimos sonidos de pasos personalizados cuando el jugador camina sobre barro resbaladizo. Se trataba de un sistema denominado propiedades de la superficie que utilizaba el tipo de material para determinar los sonidos y otros efectos que debían producirse al caminar o disparar sobre él. En una fase previa del desarrollo, teníamos un efecto que ralentizaba el movimiento de los jugadores al caminar sobre superficies de barro, pero se eliminó en la versión final, porque era un castigo muy severo."
N/A3996"#commentary\cn_080_combat_entrances.mp3" "[ Dario Casali ] Siempre es incómodo cuando vas corriendo y al doblar la esquina te encuentras con enemigos, porque hace que el mundo se sienta menos vivo y más como una galería de tiro. Esto nos motivó a buscar formas más interesantes de incluir enemigos en los espacios de combate, junto con dinámicas que transmitieran planificación e intencionalidad de su parte, como si los soldados ya tuvieran un plan para Gordon incluso antes de que él apareciera. Los de Protección Civil de esta escena saltan al espacio con secuencias programadas y, más adelante, utilizamos el rapel de forma similar. En realidad, no importa de dónde vengan, porque los jugadores terminan contándose esa historia a sí mismos. Descubrimos que, al final, el combate debe tener una historia implícita en su configuración: una emboscada, una sorpresa, una oleada, un asalto... Todos estos escenarios usan la misma IA enemiga, pero a los testers les parecían diferentes."
N/A3997"#commentary\cn_081_mounted_gun_gallery.mp3" "[ Dave Riller ] En esta escena suceden varias cosas: la torreta que dispara a las cajas rompibles que hay detrás enseña a los jugadores a no enfrentarse directamente a la amenaza y a utilizar la ruta del alcantarillado para derrotarla. Cuando llegan a la torreta, disfrutan utilizándola en una galería de tiro contra una oleada de soldados de la Alianza y escáneres que bombardean. También comenzamos a introducir el APC lanzamisiles de la Alianza, que impulsa a los jugadores y aparece de nuevo más adelante en el capítulo."
N/A3998"#commentary\cn_082_barnacle_bowling.mp3" "[ Josh Weier ] Este es un ejemplo satisfactorio de cómo un conjunto de elementos de diseño pueden combinarse en una matriz de interacciones para crear un escenario memorable para el jugador. Tenemos lapas, la simulación de física, las propiedades resbaladizas de la superficie de barro y, por último, pero no menos importante, barriles explosivos. Todos estos elementos ya aparecieron por separado, pero al combinarlos se crea un momento que denominamos bolos con lapas."
N/A3999"#commentary\cn_083_barnacle_introduction.mp3" "[ Mike Dussault ] Como las lapas pueden confundir un poco al verlas por primera vez, queríamos presentarlas de forma que los jugadores pudieran observar su comportamiento desde una distancia segura. Decidimos hacerlo mediante una escena de depredador/presa al estilo de un programa de naturaleza. Pero, como siempre, escenas como esta requirieron muchas iteraciones para que los jugadores pudieran verlas con claridad."
N/A4000"#commentary\cn_084_physics_in_puzzles.mp3" "[ Eric Smith ] A menudo, las mecánicas más sencillas que se encuentran al principio del juego se toman de otras más complejas para servir como entrenamiento. El rompecabezas del balancín, el primer reto basado en la física del juego, viene del de la lavadora de los canales, que es más complejo. El balancín utiliza los mismos principios de masa y rampas, pero de una forma más sencilla con la que los jugadores pueden interactuar directamente, lo que les ayuda a comprender la física del juego y facilita la resolución de los rompecabezas posteriores. Este rompecabezas también destaca la naturaleza analógica del sistema de física, ya que tanto la colocación de los bloques de cemento como el propio peso del jugador influyen en la solución."
N/A4001"#commentary\cn_085_combine_attack_helicopter.mp3" "[ Brian Jacobson ] Los jugadores ya lo han visto antes, pero aquí es donde presentamos al jefe principal del capítulo de los Canales: el helicóptero de ataque de la Alianza. Este helicóptero destruye sin piedad la cobertura del jugador, obligándolo a avanzar o ser abatido. Queríamos que esta secuencia fuera tensa y amenazante, y que el helicóptero pareciera demasiado poderoso como para enfrentarlo directamente, y mantener esa intensidad a lo largo de los Canales hasta el enfrentamiento final en el embalse. Para lograrlo, limitamos en gran medida el movimiento del helicóptero en función de objetivos específicos del juego. En este mapa, diseñado como una carrera de cobertura en cobertura bajo el fuego del helicóptero, creamos una ruta circular en el cielo sobre la arena. El helicóptero siempre se desplaza hasta el punto más alejado de ese círculo con respecto al jugador, manteniéndose visible y facilitándonos la colocación de coberturas en los lugares adecuados."
N/A4002"#commentary\cn_087_explosive_barrel_factory.mp3" "[ David Speyrer ] Esta sala, llena de una cantidad absurda de barriles explosivos, inspiró un debate amistoso dentro del equipo sobre hasta dónde llevar la verosimilitud de nuestro mundo. Francamente, un solo barril explosivo es probablemente demasiado en lo que respecta al realismo: en el mundo real, los barriles no deberían explotar, ni siquiera si les dispararas."
N/A4003"#commentary\cn_088_rising_water.mp3" "[ Dhabih Eng ] El puente flotante y los carretes de madera introducen aquí el concepto de flotabilidad como herramienta para el jugador. En este caso no se trata realmente de un rompecabezas, sino simplemente de una diversión para el jugador que interactúa con el sistema de física, pero más adelante retomamos este elemento del juego en los canales para levantar una rampa para la lancha neumática."
N/A4004"#commentary\cn_089_manhack_matt.mp3" "[ John Morello ] A este tipo lo llamábamos Matt Robosierra. Queríamos dar a los jugadores la sensación de que cientos de ciudadanos habitaban los rincones y recovecos ocultos de Ciudad 17. En ese momento del juego, hacía tiempo que los jugadores no veían a ningún ciudadano, y queríamos explicar la importancia de las robosierras, que fueron los primeros enemigos basados en la física que creamos. En el concepto original, había una sala de videojuegos en la ciudad, donde los jugadores podían volar con las robosierras para atacar ciudadanos virtuales. Con el tiempo, los jugadores descubrirían que las robosierras eran reales, al igual que los ciudadanos. A medida que la ocupación de la Alianza se fue concretando, esta idea de una sala de videojuegos dejó de encajar y finalmente se descartó."
N/A4005"#commentary\cn_090_fighting_motion_sickness.mp3" "[ David Speyrer ] En las primeras pruebas, muchos jugadores sufrieron mareos mientras conducían el hidrodeslizador. Al intentar solucionarlo, descubrimos varios factores que contribuían a ello. Reducir la intrusión del hidrodeslizador en la vista ayudaba, así que hicimos varios ajustes en el modelo para reducirlo. Mantener una velocidad de fotogramas constante también ayudó, por lo que era importante vigilar el rendimiento en estas secciones. Sin embargo, el factor más importante fue eliminar el movimiento de la vista para mantener un horizonte más estable, independientemente de lo que hiciera el hidrodeslizador. Uno de los programadores del equipo era muy propenso al mareo y se ofreció valientemente a probar el juego varias veces para evaluar nuestro progreso hacia una solución. Estoy muy seguro de que vomitó por lo menos una vez, y su noble sacrificio fue muy apreciado."
N/A4006"#commentary\cn_091_headcrab_canisters.mp3" "[ Jeff Lane ] Los botes de cangrejo usados se ven más adelante en Ravenholm, así que decidimos mostrarlos aquí para enseñar cómo los utiliza la Alianza. La historia es que la Alianza convirtió la fauna de Xen en armas para utilizarlas contra los humanos. Se añadieron cangrejos enterrados como nueva característica de esta sección, que se amplió para mostrar un barrio marginal de ciudadanos que fue arrasado por el ataque de los cangrejos."
N/A4007"#commentary\cn_092_airboat_intro.mp3" "[ John Morello ] Aquí es donde el jugador obtiene el primer vehículo del juego, el hidrodeslizador. Queríamos crear un espacio seguro para que los jugadores practicaran la conducción todo el tiempo que quisieran antes de seguir adelante. La arena está llena de oportunidades para realizar saltos y trucos, y le pusimos limo tóxico para que los jugadores permanecieran más tiempo en el hidrodeslizador, en vez de abandonar el vehículo y seguir a pie."
N/A4008"#commentary\cn_093_zombie_surprise.mp3" "[ Jeff Lane ] En esta tubería de alcantarillado hay un elemento de susto. Los jugadores entran aquí, concentrados y curiosos, y entonces aparece un zombie submarino que casi siempre les da un susto de muerte. Un tester se cayó de la silla y a nosotros nos pareció un momento de éxito rotundo."
N/A4009"#commentary\cn_094_airboat_time.mp3" "[ Dave Riller ] Encontrar el equilibrio adecuado entre el tiempo en vehículo y el tiempo a pie nos llevó bastante trabajo. Conducir a toda velocidad hace que los jugadores recorran el mundo muy pronto y, en las primeras pruebas, nos pareció que se estaban perdiendo la exploración y los detalles del juego, que son fundamentales en Half-Life, y no queríamos que el auto eliminara eso. Para solucionarlo, añadimos puntos periódicos en los que los jugadores podían salir y explorar pequeñas zonas repletas de detalles. Además, a medida que el sistema de física evolucionaba, aprendíamos nuevas formas de utilizarlo. Estos puntos fuera del hidrodeslizador nos permitieron introducir un elemento de descubrimiento en torno a la física, como tirar cajas al agua o combinar barriles para levantar una rampa. Esto dio a los jugadores la oportunidad de interactuar con el agua y la física de diferentes maneras."
N/A4010"#commentary\cn_095_floating_supplies.mp3" "[ Josh Weier ] En la prueba alfa, los canales tenían algunas cajas de suministros flotantes que los jugadores podían romper con el hidrodeslizador para recoger lo que había dentro. La mecánica era algo lúdica, pero ayudaba a mantener el ritmo del juego al permitir el reabastecimiento sobre la marcha. Para que la premisa resultara más plausible, queríamos contar la historia de cómo las cajas flotantes acabaron en lugares tan convenientes a lo largo del camino. Esta escena en la que los ciudadanos lanzan cajas de suministros ayuda a vender esa ficción y, al mismo tiempo, hace que los canales parezcan más vivos. También hacía que los jugadores se sintieran más heroicos e importantes al recibir la ayuda de tantos personajes secundarios."
N/A4011"#commentary\cn_096_grenade_intro.mp3" "[ Brian Jacobson ] Creamos esta base de Combine como un área de entrenamiento y un campo de pruebas para granadas, colocándolas aquí en cajas de suministro infinito para indicar que los jugadores pueden usarlas libremente sin temor a quedarse sin ellas. Diviértanse. El combate aquí utiliza un marcado extenso para dirigir a la IA de los soldados hacia la cobertura y proporcionar buenas oportunidades para que los jugadores usen las granadas. Al final de la zona, la misma técnica de granadas infinitas ayuda a los jugadores a resolver la colocación de las torretas, ya que un asalto directo es mucho más difícil si no lo hacen. Añadimos una luz roja brillante y un rastro de partículas a las granadas, lo que facilita considerablemente a los jugadores seguir su trayectoria, tanto si las lanzan como si las esquivan de un soldado Combine."
N/A4012"#commentary\cn_097_puzzle_layers.mp3" "[ Dave Riller ] Como los jugadores no conocen del todo la intención del diseñador, lo cual creemos que es positivo, tienden a responder de formas muy sorprendentes a nuestros acertijos. Incluso los que parecerían más sencillos, pueden causar innumerables fracasos antes de alcanzar el éxito. Ese fue el caso de este acertijo para abrir las compuertas del canal, que requirió muchas capas de pistas y sugerencias. La rueda chispeante indica que ahí es donde normalmente se abriría la compuerta, pero se necesita otro método. Unos cuervos atraen la atención del jugador hacia la solución, en este caso un conjunto de vigas en un péndulo. Como ya se habían introducido las granadas, al principio queríamos que los jugadores lanzaran una para romper la estructura de soporte de madera, pero no era lo suficientemente obvio. Añadimos barriles explosivos como pista mucho más clara. Pero incluso después de resolver el rompecabezas, algunos jugadores no se dieron cuenta de que las compuertas ya estaban abiertas, lo que les llevó a explorar sin cesar el interior de la base en busca de otra salida. Por ello, tuvimos que recordarles su problema original, la compuerta rota. Añadimos humo, la sirena de alarma y una luz giratoria, y hasta entonces empezamos a notar resultados favorables en las pruebas de juego."
N/A4013"#commentary\cn_098_metrocop_strafing.mp3" "[ Doug Wood ] El diseño inicial de los niveles del hidrodeslizador tenía como objetivo desafiar a los jugadores con maniobras precisas bajo la presión de Protección Civil. Su patrón de fuego estaba pensado para que los jugadores tuvieran que esquivar los disparos mientras avanzaban a toda velocidad. Pero, durante el proceso de revisión, que internamente llamamos \"Vigilancia\", algunos testers se sintieron frustrados por no poder responder ante los disparos. Querían que el hidrodeslizador fuera poderoso e imparable. Basándonos en esos comentarios, reorientamos los niveles para enfatizar el empoderamiento por encima del desafío, pasando de esquivar ataques a combates trepidantes, velocidad y romper barreras."
N/A4014"#commentary\cn_100_mounted_gun.mp3" "[ Jeff Lane ] Las armas montadas se añadieron aquí para ayudar a entrenar al jugador en la eficacia del arma contra el helicóptero de ataque para la batalla final en el embalse. Esto era necesario porque, hasta ese momento, el helicóptero no era vulnerable a las armas del jugador y teníamos que dar alguna indicación de que podía recibir daño con armamento más pesado. Esto solo fue efectivo en las pruebas de juego debido a la presión a la que estaba sometido el jugador en ese momento, lo que nos llevó a desarrollar los efectos de partículas y los sonidos que convencieran a los jugadores de que realmente estaban causando daño."
N/A4015"#commentary\cn_101_357_intro.mp3" "[ Josh Weier ] A diferencia de la pistola básica, con su cadencia de tiro más lenta, la magnum está pensada para dispararse de forma más mesurada y calculada, infligiendo daño catastrófico al objetivo. Las versiones anteriores de la magnum tenían una dispersión un tanto aleatoria, adecuada para el peso y el gatillo menos sensible de una pistola más grande. Sin embargo, esto provocaba momentos anticlimáticos en los que los jugadores alineaban cuidadosamente un disparo, pero fallaban debido a la penalización de precisión. Para solucionarlo, hicimos que la primera bala tuviera una precisión perfecta, pero que cada disparo subsecuente perdiera precisión en una ráfaga."
N/A4016"#commentary\cn_102_helicopter_bombing_run.mp3" "[ Brian Jacobson ] Este es otro ejemplo de cómo creamos peligros de movimiento mientras conducimos el hidrodeslizador. El helicóptero intenta mantenerse delante del jugador cuando lanza bombas, y si el jugador retrocede, mantiene la posición y se gira para atacar al jugador. En una prueba de juego, una bomba cayó justo entre las juntas de las tuberías, creando un momento muy cinematográfico. El tester tuvo una reacción positiva, por lo que el equipo decidió programarlo para que ocurriera siempre. Este proceso se ha convertido en parte de nuestra metodología de diseño orgánico: de vez en cuando, ocurre algo inesperado e interesante en una prueba de juego, y buscamos la manera de que vuelva a ocurrir de forma consistente."
N/A4017"#commentary\cn_103_smokestack_collapse.mp3" "[ Doug Wood ] Al crear un juego de acción cinematográfico como el primer Half-Life, siempre quisimos incluir secuencias de destrucción espectaculares, pero nunca logramos hacer nada parecido. La física de Half-Life 2 introdujo un sistema para romper en pedazos objetos pequeños como cajas, lo que nos dio la idea de hacer algo mucho más grande. Nos aventuramos y probamos romper una chimenea en pedazos mientras caía. Fuimos experimentando con las masas, refinamos el modelo y añadimos mucho humo y audio para vender el efecto, y ahí estaba: nuestro gran y espectacular momento de destrucción. Nuestro sistema de física apenas soportaba la secuencia, y para los estándares modernos, ya se ve anticuada, pero en ese momento nos pareció realmente impresionante. Como la simulación era única cada vez que la ejecutábamos, tuvimos que tomar medidas para evitar bloquear completamente el camino del jugador con los grandes trozos de escombros. El éxito de esta secuencia nos dio paso a los efectos de destrucción cinemáticos de mucha mayor fidelidad que se ven a continuación en el Episode Two."
N/A4018"#commentary\cn_104_washing_machine_puzzle.mp3" "[ David Speyrer ] Creamos el rompecabezas físico de la lavadora en una fase avanzada del desarrollo, después de que las pruebas de juego indicaran que los jugadores necesitaban un descanso de la presión implacable del helicóptero. Los contrastes de ritmo como este pueden acentuar los momentos álgidos al restablecer el estado emocional del jugador y evitar el agotamiento o incluso el aburrimiento. Fue una señal positiva que los jugadores reaccionaran con tanta intensidad a todo el trabajo realizado para que el helicóptero resultara realmente amenazador, pero si no gestionábamos el estrés que generaba, la fatiga se apoderaba de ellos y rápidamente empezaban a sentir monotonía en lugar de emoción. En un principio, los jugadores atravesaban rápidamente esta zona, pero debido a la agradable luz del sol y a la composición del canal, decidimos que era un buen lugar para hacer una pausa en la acción y que el jugador pasara un rato tranquilo resolviendo un rompecabezas. Este rompecabezas fue el primero en utilizar masas y poleas, y acabó dando lugar a otros rompecabezas de navegación física en otras partes del juego."
N/A4019"#commentary\cn_105_airboat_changeup.mp3" "[ Jeff Lane ] Los testers nos comentaron que querían una jugabilidad más variada con el hidrodeslizador. Hasta ese momento, el jugador no tenía ninguna forma real de defenderse del helicóptero y otros enemigos, por lo que nos pareció adecuado introducir una nueva arma y, a su vez, cambiar el ritmo y preparar el terreno para lo que vendría después. En las siguientes áreas, añadimos prácticas de tiro para que la gente se familiarizara con su nueva arma. La fuerza física adicional de los proyectiles de la pistola de aire comprimido hacía que los objetivos salieran volando y daba la sensación de que era mucho más potente que cualquier otra arma del arsenal del jugador. Aun así, cuando llegó el momento de probar el combate contra el helicóptero, muchos testers seguían pensando que era invencible. No notaron nuestros intentos por demostrar que las armas fijas de la Alianza le hacían daño. Para resolverlo, recurrimos a lo más evidente: colocamos el helicóptero directamente fuera del túnel en el que se obtiene el arma y dejamos muy claro que puedes y debes dispararle. Y funcionó."
N/A4020"#commentary\cn_106_donkey_kong_barrel_ramp.mp3" "[ Eric Smith ] Esta zona en concreto, la rampa de drenaje, al principio solo era un elemento arquitectónico curioso. Pero, durante las pruebas de juego, pronto nos dimos cuenta de lo divertido que era llevar el hidrodeslizador por la pendiente, así que añadimos más elementos para mejorar esa experiencia. Entre ellos, los de Protección Civil le lanzan barriles al jugador, como guiño a un grande del arcade: Donkey Kong."
N/A4021"#commentary\cn_107_lambda_cache_interlude.mp3" "[ Danika Rogers ] Un juego de Half-Life es una experiencia lineal en última instancia, pero siempre buscamos formas de romper la trayectoria del jugador y crear no linealidad a escala de nivel. Esta caché lambda, sustituida por una emboscada de zombies y cangrejos, era totalmente opcional y se creó únicamente para añadir algo de esa no linealidad a esta sección del recorrido por los canales."
N/A4022"#commentary\cn_108_skybox_time_of_day.mp3" "[ Eric Kirchmer ] El color del cielo y la niebla cambia gradualmente a lo largo de este capítulo. El objetivo es representar visualmente el paso del tiempo mientras el jugador recorre los canales y avanza por el capítulo. Dos valores de color niebla en direcciones opuestas ayudan a crear la ilusión del ángulo oblicuo del sol. En este punto, se puede ver que se acerca el atardecer. Esto culmina en la arena de combate del helicóptero, con la puesta de sol y Ravenholm visible en el cielo."
N/A4023"#commentary\cn_109_helicopter_megabomb_origin.mp3" "[ Brian Jacobson ] El ataque con helicópteros megabomba se basó en un error donde un programador eliminó accidentalmente el tiempo de recarga de las bombas, lo que provocó que el helicóptero lanzara cientos de bombas a la vez. Quedó tan bien que decidimos mantenerlo para el ataque final con bombardeos."
N/A4024"#commentary\cn_110_helicopter_final_battle.mp3" "[ Dave Riller ] Diseñamos esta zona como el escenario del enfrentamiento final entre el jugador y el helicóptero de ataque de la Alianza. Es la oportunidad del jugador para eliminar por fin al implacable enemigo que lo ha estado persiguiendo desde que huyó bajo tierra tras abandonar el laboratorio de Kleiner. Esta zona pasó por muchas iteraciones hasta quedar perfecta. Necesitaba un espacio amplio para combates rápidos con vehículos, buen flujo de movimiento con opciones de ruta claras y rendimiento fiable. También buscábamos claridad visual para el combate, impactante pero sin excesos, al tiempo que nos asegurábamos de que fuera una vista memorable una vez destruido el helicóptero."
N/A4025"#commentary\cn_111_airboat_wreckage.mp3" "[ David Speyrer ] Originalmente, destruimos el hidrodeslizador al saltar por encima de la presa, por lo que este nivel comenzaba con el jugador en medio de los restos. En una prueba de juego con todo el equipo, la gente se sintió decepcionada por perder el vehículo en el que habían pasado tanto tiempo. Hubo mucho debate interno sobre si esa sensación de pérdida era una experiencia valiosa o no. Al final, decidimos que el hidrodeslizador quedara intacto, dejando abierta la posibilidad de que el jugador regrese por él algún día. Se dice que el hidrodeslizador sigue esperando."
N/A4026"#commentary\cn_112_arena_exit_gate.mp3" "[ Quintin Doroquez ] El mecanismo de ruedas para levantar la puerta de salida se añadió específicamente para obligar al jugador a derrotar al helicóptero antes de poder avanzar. A menudo nos referimos a elementos como este como bloquear al jugador, es decir, utilizar elementos de diseño para impedir que avance hasta que haya completado una tarea necesaria. En este caso, se trata literalmente de una puerta."
N/A4027"#commentary\cn_113_blocking_tutorials.mp3" "[ Adrian Finol ] A veces, necesitamos asegurarnos de que el jugador aprendió algo, y el método estándar, al menos en el desarrollo de videojuegos, no en la vida real, es atraparlo tras una especie de puerta, donde debe demostrar sus conocimientos para poder continuar. Intentamos disimular estas puertas como algo natural, para que no parezca que el juego se detuvo. Por supuesto, el tiempo, los recursos o el propio contexto ambiental pueden complicar las cosas. En este caso, necesitábamos enseñar a los jugadores cómo mover objetos, por lo que un sencillo rompecabezas de apilamiento nos pareció la mejor solución. Probamos diseños más complejos, pero resultaron menos eficaces para enseñar lo que se necesitaba."
N/A4028"#commentary\cn_114_natural_storytelling.mp3" "[ Bill Van Buren ] Para lograr nuestros objetivos de construcción del mundo y narración en la estación de trenes, necesitábamos una forma natural de presentar los diálogos sin que parecieran demasiado artificiales ni requirieran tutoriales. Nos dimos cuenta de que los jugadores se acercaban a los PNJ para verlos mejor, así que aprovechamos la oportunidad para que los PNJ notaran al jugador y le hablaran. Esto mantuvo las interacciones en un tono discreto, lo cual era esencial, ya que los ciudadanos no son precisamente muy alegres ni animados. La simplicidad de este enfoque también se alineaba con uno de los objetivos narrativos fundamentales de Half-Life: hacer que la narrativa respondiera al interés del jugador. Algunos jugadores quieren profundizar en cada detalle, mientras que otros solo quieren saber qué hacer a continuación. Dar a los jugadores control sobre la cantidad de historia con la que se involucran, sin que ello bloquee el progreso, es un objetivo que siempre intentamos mantener en un juego de Half-Life. Además, cuanto menos complicada sea la implementación de una función, más podremos incluirla."
N/A4029"#commentary\cn_115_trainstation.mp3" "[ Charlie Brown ] El comienzo de un juego de Half-Life tiene una gran tarea: debemos presentar a los jugadores un nuevo mundo y enseñarles cómo interactuar con él. Los jugadores deben comprender rápidamente qué está sucediendo, quiénes son los personajes clave, a qué amenazas se enfrentarán y cómo encajan en todo ello. Y, sobre todo, debe ser divertido y lo más interactivo posible. Para lograrlo, se necesitan muchas iteraciones y pruebas de juego, especialmente en los pequeños detalles que conforman el panorama general del juego. En esta sección, destacaremos algunos momentos clave, problemas de diseño del juego y algunas pruebas en las que las cosas no salieron según lo previsto."
N/A4030"#commentary\cn_116_physics_objects.mp3" "[ David Sawyer ] Quizás ahora sea difícil de recordar, pero cuando salió Half-Life 2, los objetos pequeños de los juegos, como estos trozos de basura, solían ser estáticos, es decir, no se movían o, si lo hacían, era de una forma muy simple. Con suerte, si los golpeabas, se rompían en varios fragmentos. Uno de los objetivos de esta sección inicial de la estación de tren era dejar claro a los jugadores que este tipo de objetos tenían buena simulación física en Half-Life 2. Se podían recoger, soltar, lanzar, romper, mover con otras fuerzas, lo que se quisiera. Aquí empezamos con algo pequeño, mostrando que la basura se mueve por el aire de la llegada del tren, o más concretamente, por un volumen invisible que se activa cuando el jugador sale del tren."
N/A4031"#commentary\cn_117_blocking_tutorials_3.mp3" "[ Eric Smith ] El segundo error en este espacio tutorial es un caso de enseñanza errónea, en el que accidentalmente enseñamos al jugador algo que no era nuestra intención. Esto puede ser difícil de evitar sin realizar pruebas exhaustivas, ya que el juego siempre está enseñando, incluso cuando no es a propósito. Más adelante, en la estación de tren, veremos un ejemplo más extremo. Algunos casos son críticos y deben corregirse, como cuando el jugador aprende a usar mal un arma o a interactuar con un elemento común del juego. Pero este caso era más sutil. Al enseñar a los jugadores a mover objetos, también les enseñamos a apilar objetos físicos para escapar de un espacio. Normalmente, eso está bien, excepto que no utilizamos ese rompecabezas más adelante en el juego, y enseñar algo irrelevante solo satura su conjunto de herramientas mental y hace que sea más difícil recordar lo más útil. Peor aún, apilar objetos para escapar del espacio de juego se convirtió en un problema más adelante, y tuvimos que contrarrestarlo activamente en varias áreas. Con tantos objetos basados en la física, bloquear este comportamiento sin poner techos por todas partes no era una opción. Al final, esperábamos que los jugadores no le dieran demasiadas vueltas a esta lección inicial y, cuando las pruebas de juego mostraron que los jugadores se atascaban más adelante, nos aseguramos de no recordárselas."
N/A4032"#commentary\cn_118_welcome.mp3" "[ Gabe Newell ] Soy Gabe Newell. Bienvenidos de nuevo a Half-Life 2. Han pasado veinte largos años desde su lanzamiento. En esta actualización de aniversario, intentamos responder a tantas peticiones de la comunidad como nos ha sido posible. Y aunque puede que esta no sea la petición número uno de los fans, a menudo escucho lo mucho que a la gente le gustaría tener un modo de comentarios, así que estamos muy emocionados de poder hacerlo realidad. No solo fue un reto recordar muchos de los detalles del desarrollo de Half-Life 2, sino que tampoco es fácil descifrar código informático de hace una década y preguntarse qué demonios se estaba pensando en aquel entonces. Junto con los comentarios de los desarrolladores, corregimos un montón de errores antiguos y hemos intentado dejar las cosas en mejor estado de lo que las encontramos. Y al menos esta vez tenemos el lujo de saber cómo acabaron las cosas al final. Para escuchar un nodo de comentarios, coloca el cursor sobre el símbolo de comentarios flotante y pulsa la tecla Usar. Para detener un nodo de comentarios, coloca el cursor sobre el nodo giratorio y vuelve a pulsar la tecla Usar. Y, por favor, cuéntanos qué te parece. Puedes ponerte en contacto conmigo en gaben@valvesoftware.com. ¡Gracias y diviértete!"
N/A4033"#commentary\cn_119_metrocop_shoving_citizens.mp3" "[ Josh Weier ] Solo caminamos unos metros y ya tenemos problemas que resolver. Presentamos a Protección Civil, un enemigo que los jugadores tendrán que matar más adelante, y les ofrecemos un adelanto del mundo en el que se adentran. Es un momento sencillo y claro que muestra la relación entre Protección Civil y los ciudadanos y, por extensión, el jugador. Al mismo tiempo, decidimos reforzar la existencia de la simulación física básica, mostrando la forma en que los PNJ pueden interactuar de manera casual con los objetos del mundo. Ver cómo una maleta chocaba con otra y se desplazaba era algo bastante novedoso en aquella época. Estos momentos en la estación de tren, en los que combinamos múltiples objetivos, fueron los más exitosos: se sentían naturales, como si el juego no se detuviera solo para enseñarte una lección."
N/A4034"#commentary\cn_120_fall_damage.mp3" "[ Kerry Davis ] Enseñar a los jugadores cómo hacer las cosas es una de las tareas esenciales del juego. Pero, para que puedan tomar decisiones con confianza, también necesitan comprender reglas más sutiles. Este pequeño momento engloba dos de ellas: primero, muestra qué tan lejos puede caer el jugador sin recibir daño. Segundo, introduce un poco del “lenguaje” del juego, es decir, la forma en que se comunicará con ellos. A los jugadores les preocupa recibir daño por caídas, pero también dar un paso que no puedan deshacer. Por eso, aquí, una caja colocada estratégicamente les indica que saltar es seguro y que ese es el camino a seguir. Cuando la caja se rompe, se refuerza la simulación de físicas y, probablemente, es la primera vez que ven que los objetos grandes pueden romperse."
N/A4035"#commentary\cn_121_sweeping_vortigaunt.mp3" "[ Laura Dubuk ] Otro momento clave de narrativa y otro guiño al sistema de física: aquí mostramos cómo encajan los vortigaunts en este nuevo mundo, a diferencia de su papel en Half-Life 1 como enemigos. Como en muchos momentos de la estación de tren, el vortigaunt barriendo surgió de nuestra constante búsqueda de mostrar una interacción natural de los personajes con el sistema de física. ¿Por qué solo decirles a los jugadores que ahora los vortigaunts son amistosos, cuando podemos poner a uno moviendo objetos simulados y barriendo tranquilamente? Nada dice más \"Ahora vengo en son de paz\", que alguien dispuesto a limpiar."
N/A4036"#commentary\cn_122_blocking_tutorials_2.mp3" "[ Robin Walker ] Hay dos fallos importantes en este tutorial. Primero, los jugadores pueden romperlo si tiran todas las cajas por la ventana, lo cual obviamente no es ideal. Con esto quedan atrapados y sin poder avanzar, lo que consideramos un error crítico que debe corregirse. Una solución limpia habría sido ajustar el tamaño de la ventana o de las cajas para que el jugador pudiera pasar, pero las cajas no. El problema es que lo descubrimos muy tarde, y hacer incluso un cambio tan simple puede tener consecuencias impredecibles que rompan el juego… y encima justo antes del lanzamiento. Además, este problema era puramente teórico: en realidad, nunca vimos que los testers lo hicieran. Nuestras pruebas de juego en este espacio habían ido bien; los jugadores aprendían lo necesario y seguían adelante. Cambiar el diseño de la habitación tan tarde podría haber arruinado algo ya exitoso de formas que no podíamos prever. Por eso, optamos por una solución más conservadora en lugar de algo elegante. Si te da curiosidad, prueba a tirar todas las cajas por la ventana y ver qué pasa."
N/A4037"#commentary\cn_123_playground.mp3" "[ Brian Jacobson ] Cuando discutíamos formas de resaltar nuestra simulación de físicas en el entorno urbano, un parque infantil nos pareció una elección natural. Y, para los jugadores que prestan atención al Dr. Breen, también sirve como recordatorio del costo de la rendición de la humanidad ante la Alianza. Elegimos algunas estructuras del parque con potencial interesante para las físicas y comenzamos a ajustarlas. Incluso con la avanzada simulación de físicas que teníamos en ese momento, configuraciones como esta siempre requerían ajustes manuales, ya que teníamos objetos completamente simulados interactuando con otros no simulados o parcialmente simulados, como el jugador o la geometría estática del mundo. Podría parecer fácil suponer que la simulación puede hacerse cargo de gran parte de la implementación, pero incluso ahora, veinte años después, rara vez es así. Cuando trabajábamos en el parque, ya tarde en el desarrollo del juego, no conseguíamos que la fricción del tobogán se sintiera bien, así que decidimos romper la escalera para que los jugadores no pudieran subir. Sin embargo, se puede subir de todas formas con solo caminar por el frente. Como suele pasar, es el jugador quien termina riéndose de nosotros al final."
N/A4038"#commentary\cn_124_pick_up_that_can.mp3" "[ Charlie Brown ] Contextualizar los tutoriales (crear una situación dentro de la historia en la que ocurren) nos permite hacer más que simplemente detener el juego para enseñarle algo al jugador. Podemos darle un valor narrativo al momento. Aquí, enseñar a lanzar objetos se combina con una situación narrativa que le da la opción de decidir cómo responder. Los de Protección Civil maltratan a los ciudadanos como si nada, así que nos pareció adecuado poner al jugador en una posición similar. Si tenía alguna opinión sobre cómo deberían haber reaccionado los ciudadanos, ahora puede expresarla. Las pruebas de juego mostraron que la mayoría de los jugadores cumplían con la orden o se negaban a recoger la lata, pero algunos intentaban evitar la confrontación por completo. Otros cumplían al principio, pero luego se vengaban tras sentirse humillados. Al mantener el momento relativamente controlado, tanto en términos de las acciones del jugador como del propio espacio, podíamos reaccionar de forma adecuada a casi cualquier decisión que tomaran."
N/A4039"#commentary\cn_125_promises.mp3" "[ Danika Rogers ] Al comienzo de un juego de Half-Life, uno de nuestros objetivos es hacerle promesas al jugador y darle una idea de lo que puede esperar más adelante. Cine, televisión y libros, todo gran entretenimiento hace lo mismo de alguna manera, y los videojuegos no son la excepción. Las promesas en un juego de Half-Life pueden tomar distintas formas. Algunas son simples, como ofrecer solo un vistazo de algo intrigante. Otras son más complejas, como las interacciones con Protección Civil. Al poner al jugador en una posición indefensa frente a ellos, preparamos el terreno para ese futuro momento en el que finalmente podrá vengarse."
N/A4040"#commentary\cn_126_exploration.mp3" "[ David Sawyer ] Después de que los de Protección Civil te pasearan por la estación de tren, queríamos darles a los jugadores la oportunidad de explorar. Esta plaza ofrecía varias formas de interactuar con los ciudadanos, los policías, los escáneres y la infraestructura de la ciudad. Nuestro objetivo era que estas interacciones siguieran construyendo el mundo sin necesidad de tutoriales explícitos, y las perfeccionamos hasta que funcionaran de forma natural, sin requerir ningún entrenamiento real."
N/A4041"#commentary\cn_127_early_game_exploration.mp3" "[ David Speyrer ] Hasta llegar a esta plaza, probablemente el jugador no había tenido que pensar en su ruta, ya que había sido clara y directa. Pero aquí queríamos fomentar la exploración, haciendo el camino menos obvio, lo que puede generar una sensación de estar perdido o, peor, de confusión, como era de esperar. Estos cambios pueden ser complicados, especialmente al inicio del juego, cuando el jugador todavía está aprendiendo las señales de orientación del propio juego. Aquí, la situación se complica aún más por los puntos de control con campos de fuerza, que permiten que los PNJ ciudadanos pasen, pero bloquean al jugador. Muchos testers creyeron que había alguna forma de sortearlos. Al final, gracias a las pruebas exhaustivas encontramos la visibilidad adecuada para el callejón que permite avanzar, usando la iluminación, la disposición del escenario y una caja de madera, que los jugadores ya habían aprendido a interpretar como señal de que van en la dirección correcta. Así los guiamos sutilmente."
N/A4042"#commentary\cn_128_strider.mp3" "[ Doug Wood ] Este momento sencillo es una promesa de que más adelante en el juego te encontrarás con esa enorme criatura. Incluso una escena tan simple como esta requiere muchas pruebas de juego y varias iteraciones, debido al objetivo de Half-Life de no quitarle el control al jugador. Como podrás imaginar, se necesitan muchos pequeños ajustes para asegurarse de que la mayor cantidad posible de jugadores miren en el lugar correcto y en el momento adecuado. La disposición de la calle y la escena con el policía están diseñadas para guiar la mirada del jugador y enmarcar perfectamente al zancudo cuando aparece."
N/A4043"#commentary\cn_129_physics_simulation.mp3" "[ Jay Stelly ] Aunque comenzamos Half-Life 2 con una simulación de física funcional desarrollada por un tercero, aún nos llevó años de trabajo adicional, tanto en la propia simulación como en su integración en el juego, hasta sentir que podíamos cumplir con las ambiciones de nuestros diseñadores. Mantener un nivel de calidad y rendimiento adecuado para el producto final era un desafío que sabíamos que enfrentaríamos desde el inicio, pero el problema más sutil fue, en realidad, decidir qué debíamos simular y hasta qué punto. No podemos simularlo todo, y aunque pudiéramos, hay razones de diseño que hacen que la experiencia sea mejor cuando no lo hacemos. En muchos casos, manipulamos deliberadamente las reglas de la simulación para mejorar la experiencia del jugador. Estos ajustes suelen pasar desapercibidos porque coinciden con las intenciones de quien juega. Por ejemplo, deshabilitamos las colisiones entre el jugador y los objetos grandes para permitirle girar en espacios estrechos. O ajustamos el disparo alternativo del fusil de la Alianza para guiar suavemente la esfera hacia los enemigos, lo que la hace más efectiva."
N/A4044"#commentary\cn_130_physics_simulation_2.mp3" "[ Jeff Lane ] Las áreas en las que el diseño del juego u otras limitaciones afectaban la simulación física requerían ajustes adicionales para que la simulación no se descontrolara. Como ejemplo, al principio experimentamos con aumentar la simulación en la entidad del jugador, es decir, hacer que el movimiento del jugador se involucrase más con la simulación física del mundo. Sabíamos que con esto, el movimiento podría sentirse menos preciso, pero a cambio podríamos ofrecer experiencias novedosas. Sin embargo, tras ajustar el movimiento para coincidir con la versión menos simulada, nos encontramos con un problema importante: la fuerza física necesaria para que el jugador se moviera a su velocidad habitual era tan alta que simplemente chocar contra otros objetos simulados podía dar lugar a que muriese por el impacto. Repetimos pruebas, pero no encontramos una solución convincente y volvimos al movimiento menos simulado. No fue el camino más fácil, porque aparecieron nuevos desafíos en la forma en que el jugador, con menos simulación, interactuaba con los objetos más simulados del juego. Pero sí nos permitió ofrecer la experiencia de movimiento preciso que buscábamos."
N/A4045"#commentary\cn_131_playtesting.mp3" "[ John Morello ] Las pruebas de juego son una parte fundamental de cómo hacemos nuestros juegos: nunca podemos predecir completamente cómo responderán los jugadores o qué interpretarán de lo que hemos creado. Por eso probamos, para aprender y, con suerte, mejorar. Durante una prueba de juego, no guiamos ni hablamos con quienes juegan, incluso si se atascan, porque difícilmente estaremos sentados a su lado cuando se publique. El objetivo es que los testers olviden que están en una prueba y jueguen como si estuvieran en casa. Cualquier interrupción corre el riesgo de distorsionar los datos, así que solo intervenimos si hay un error que bloquea el progreso o, en casos más raros, si su comportamiento es tan raro que necesitamos entender qué están pensando."
N/A4046"#commentary\cn_132_playtesting_anecdote_1.mp3" "[ Matt Boone ] Una prueba de juego memorable nos recordó que nunca podemos estar completamente seguros de lo que piensan los jugadores ni de qué lección aprenden de la experiencia. En esa ocasión, un tester que jugó desde el principio y se atoró intentando abrir una puerta, pasó varios minutos alternando entre el juego y la configuración del teclado. Cuando le preguntamos qué estaba buscando, dijo que estaba buscando los controles del inventario, porque pensaba que podía usar un objeto que había recogido antes para desbloquear la puerta. Aunque lo habíamos visto recoger y soltar varios objetos físicos, había malinterpretado lo que ocurría. El tester creía que, al presionar la tecla Usar mientras sostenía un objeto, este se movía a un inventario, porque el objeto caía directamente. Nosotros sabíamos que era solo la gravedad, pero su suposición no era descabellada: algunos juegos de aventuras de esa época sí enviaban los objetos a un inventario invisible así. Le explicamos que no había inventario y la prueba continuó. Más tarde, evaluamos si debíamos abordar este problema o no, pero como ningún otro tester tuvo la misma confusión y nuestras posibles soluciones eran muy invasivas, decidimos dejarlo pasar como un caso aislado. Aun así, fue un buen recordatorio de cómo incluso los detalles más sutiles y fáciles de pasar por alto pueden crear confusión."
N/A4047"#commentary\cn_133_cratebaby.mp3" "[ Scott Dalton ] Esta muñequita tiene una larga historia. Durante los largos meses de pruebas internas, parte del equipo la convirtió en un desafío: una forma de hacer que la partida número 47 del juego fuera un poco más divertida. Ponían la muñeca dentro de una caja azul y veían hasta dónde podían llevarla a lo largo del juego. Después del lanzamiento de Half-Life 2, la comunidad también empezó a llevar al muñeco de la caja, y crearon así sus propias historias y reglas. Unos años más tarde, mientras trabajábamos en Episodio 2, esto sirvió de inspiración para el logro Enanonauta, en que los jugadores llevan un gnomo de jardín, apodado Gnomo Chompski, durante todo el episodio. Chompski incluso regresó en Left 4 Dead 2, en el logro No sin mi gnomo, en el que los jugadores tenían que cargarlo durante la campaña Feria Siniestra. Este tipo de interacciones con los jugadores son algunas de las partes más gratificantes del desarrollo de videojuegos. Diseñamos juegos con ciertas teorías en mente, pero nunca sabes realmente hacia dónde irán las cosas hasta que los jugadores ponen las manos en el control."
N/A4048"#commentary\cn_134_the_citadel.mp3" "[ Eric Kirchmer ] Queríamos que la primera vista del jugador de Ciudad 17 destacara la Ciudadela y su dominio sobre la ciudad, lo que representa el control absoluto de la Alianza sobre la humanidad. También necesitábamos que funcionara como un objetivo claro: incluso al inicio, puedes ver dónde termina tu viaje. Pero, a pesar de lo grande que era, muchos testers no la notaban. La percepción de profundidad y escala de un jugador puede ser complicada en un monitor. Si jugaste algún título en VR, probablemente habrás notado que la escala se percibe más natural. En este caso, además, la posición de la Ciudadela por encima del jugador tampoco ayudaba, quizá porque los juegos en primera persona entrenan a los jugadores a mirar hacia adelante o hacia sus pies. Para aumentar las probabilidades de que notaran la Ciudadela, añadimos pájaros volando hacia la estructura, un truco sutil que hemos descubierto que ayuda a guiar la mirada del jugador."
N/A4049"#commentary\cn_135_close_captions.mp3" "[ Yahn Bernier ] Durante el desarrollo de Half-Life 2, nos contactaron personas interesadas en la accesibilidad y nos animaron a ir más allá del sistema de subtítulos creado para Half-Life 1. Nos pidieron un sistema de subtítulos descriptivos mucho más completo, que capturara todos los sonidos del juego, no solo los diálogos. Esto resultó ser un desafío mucho más complejo de lo esperado. Half-Life 2 producía una gran variedad de sonidos, y categorizarlos para los subtítulos era crucial. La priorización también era clave: los diálogos debían destacarse y tenía que quedar claro quién hablaba. Los sonidos ambientales, como combates lejanos, eran importantes para generar atmósfera en ciertos niveles, pero no tanto si un enemigo estaba disparando cerca. Nuestros diseñadores de niveles también reutilizaban sonidos en diferentes contextos, así que un mismo sonido podía requerir subtitulado en un área, pero no en otra. Al final, cada sonido del juego tuvo sus propios datos de subtitulado, con un formato casi como HTML, lo que permitía controlar el estilo visual de cada subtítulo. Al igual que con los archivos de audio, los datos de subtitulado eran muy grandes para mantenerlos en memoria, así que construimos un sistema de caché asíncrono para gestionarlos de forma eficiente."
N/A4050"#commentary\cn_136_the_raid.mp3" "[ David Sawyer ] La sección que viene, cuando los policías de Protección Civil irrumpen en el apartamento mientras el jugador está dentro, requirió muchas iteraciones para que funcionara correctamente. En general, diseñamos Half-Life para permitir que los jugadores marquen su propio ritmo, ya que cada persona avanza por el juego de forma diferente. Algunos jugadores corren, ignorando todo lo que no parece una amenaza, mientras que otros examinan cada detalle minuciosamente. Por eso, cada vez que necesitamos forzar un ritmo específico, siempre es un desafío asegurarnos de que los jugadores perciban ese ritmo y lo sigan de forma natural. Como esta fue la primera vez que lo hicimos, tuvimos que trabajar mucho para dejar claro que había que moverse rápido, sin tiempo para explorar."
N/A4051"#commentary\cn_137_materials_and_shaders.mp3" "[ Gary McTaggart ] Half-Life 2 salió en medio de un cambio importante en los gráficos 3D, cuando la industria pasó de usar texturas a trabajar con materiales y shaders. En Half-Life 1, cada superficie tenía una textura: una imagen aplicada sobre los polígonos de la superficie. Pero para Half-Life 2, solo cinco años después, cada superficie tenía tanto un material como un shader. El shader era un bloque de código que personalizaba cómo se renderizaba la superficie. El material definía las propiedades del comportamiento físico de la superficie y su respuesta a distintas características de la jugabilidad. Además, tenía referencias a texturas y otros parámetros que el shader usaba para el renderizado. Con esto, los artistas y diseñadores tenían mucho más control sobre el aspecto y el comportamiento de los elementos. Sin embargo, había una desventaja importante: Half-Life 1 podía ejecutarse en una computadora con solo una CPU, pero Half-Life 2 requería una GPU, por los cálculos necesarios para materiales y shaders diseñados específicamente para el hardware de la GPU. Esta puerta de vidrio refractante es un ejemplo claro de un shader personalizado, pero en realidad todas las superficies de la escena están ejecutando algún tipo de shader."
N/A4052"#commentary\cn_138_the_raid_2.mp3" "[ Miles Estes ] Además de asegurarnos de que el jugador sintiera presión para avanzar, también teníamos que garantizar que la redada en sí fuera infalible. No podía haber forma de evitarla ni de retroceder más allá de los policías. El verdadero desafío no era que los jugadores intentaran romper la escena, sino que muchos entraban en pánico y corrían en direcciones aleatorias al darse cuenta, por primera vez, de que estaban bajo amenaza. Este momento requiere un equilibrio delicado: queríamos una escena de escape intensa, con sensación de peligro real, pero también queríamos que los jugadores pudieran superarla en su primer intento y sintieran que habían escapado por un pelo. Para lograrlo, mantuvimos el camino despejado y lo hicimos similar al que acababan de recorrer en el piso anterior. Hay activadores cuidadosamente ubicados que controlan las amenazas que aparecen delante y detrás, lo que mantiene la presión mientras les da a los jugadores el tiempo suficiente para sacarles distancia a los perseguidores."
N/A4053"#commentary\cn_139_health_and_no_hud.mp3" "[ Dave Riller ] La secuencia de persecución en los techos presentó un desafío de diseño único. No queríamos que fuera un obstáculo real de jugabilidad, pues idealmente los jugadores debían superarla en su primer intento. Aun así, queríamos una sensación de peligro y que los jugadores se sintieran amenzados si no seguían moviéndose. El problema era que, sin el traje HEV, los jugadores no tienen una interfaz de información, así que no hay forma de mostrar el daño ni la salud restante. Tras algunas pruebas, creamos un sistema de salud especial para esta sección, usando un resplandor rojo alrededor de la pantalla para indicar daño. Los jugadores reaccionaron como esperábamos y lo tomaron como una señal de que debían seguir avanzando, y la persecución se desarrolló tal como habíamos planeado. Para reforzarlo, hicimos que la salud se regenerara rápidamente, de modo que el resplandor no permaneciera mucho tiempo, lo que confirmaba que correr era la elección correcta y aseguraba que los jugadores no murieran por una bala perdida al final solo por haberse detenido o dudado antes."
N/A4054"#commentary\cn_140_playtesting_anecdote_2.mp3" "[ Jakob Jungels ] En la próxima sección, necesitábamos que derribaran al jugador para que Alyx pudiera salvarlo. Con tiempo y recursos limitados, simplificamos el encuentro lo más posible: reutilizamos sistemas existentes y dejamos que se desarrollara como una secuencia de combate normal, con un evento personalizado que se activaba cuando el jugador “moría”. Ajustamos el tiempo y seguimos adelante. Pero, cerca del lanzamiento, encontramos un problema con un tester que usaba el guardado rápido constantemente y presionaba la tecla de cargar partida de inmediato cada vez que pensaba que había fallado. Cuando un policía lo golpeaba, cargaba la partida antes de que Alyx pudiera intervenir. Repitió esto más de diez veces hasta que le pedimos que se detuviera. En esta fase del desarrollo, durante la etapa final de corrección de bugs, solo se pueden corregir los errores críticos, porque hasta un cambio mínimo puede romper algo más importante. Sabiendo que se trataba de un caso raro, porque la mayoría de los testers no tenía problemas, hicimos algunos cambios conservadores: acortamos la demora entre el derribo y la primera línea de diálogo de Alyx, y cambiamos el color del fundido de negro a blanco, lo que en realidad no ayudó demasiado, ya que los jugadores aún no habían muerto lo suficiente como para asociar el negro con la muerte. Consideramos deshabilitar la opción de cargar partida durante los pocos segundos que dura la escena, pero nos preocupaba crear un bug donde la función quedara deshabilitada permanentemente."
N/A4055"#commentary\cn_141_character_reactions.mp3" "[ Ariel Diaz ] Decidir a qué debían reaccionar los personajes, y cómo, fue un desafío constante. Siempre queremos que el juego responda a las acciones del jugador, pero el jugador puede interpretar cualquier respuesta del juego como una recompensa, así que las reacciones de los personajes le enseñan qué tipo de interacción espera el juego. Nos aseguramos de responder a los comportamientos positivos, como experimentar con los dispositivos en el laboratorio, e ignoramos lo que había que desalentar, como golpear sin parar a Kleiner con una caja. En serio: un tester lo hizo durante cinco minutos."
N/A4056"#commentary\cn_142_choreography.mp3" "[ Bill Fletcher ] El sistema que construimos y fuimos iterando para dar forma a la narrativa de Half-Life 2 se llamó internamente Choreo, abreviatura de coreografía en inglés. Desde el principio, nos resultó útil imaginar que estábamos escribiendo una obra de teatro en la que uno de los actores no conocía el guion. Necesitábamos un sistema que pudiera controlar a todos los demás actores, moverlos por el escenario, dirigir sus actuaciones y coordinar sus diálogos. Para manejarlo, los otros actores tenían que combinar sin problemas nuestras instrucciones de dirección con respuestas dinámicas basadas en la posición y el comportamiento del jugador. El tiempo iba a ser, claramente, un gran desafío, ya que cualquier parte de la escena podía necesitar extenderse, acortarse o incluso pausarse, dependiendo de lo que hiciera el jugador."
N/A4057"#commentary\cn_143_phoneme_extraction.mp3" "[ Bill Fletcher ] Otra herramienta fundamental que incorporamos en FacePoser fue Phoneme Editor, que procesaba las líneas de diálogo de los actores de voz y extraía los fonemas para generar animaciones básicas de sincronización labial. Para los personajes principales, nuestros animadores lo usaban como punto de partida de animaciones personalizadas de alta calidad en cada línea de diálogo, lo que sumaba animación facial completa. Sin embargo, en una escena dinámica de Choreo, no podían saber con exactitud qué estaría haciendo el resto del cuerpo del personaje. Esto significaba que había que superponer cuidadosamente los comandos y las sincronizaciones de Choreo en FacePoser, para que el actor pudiera responder dinámicamente a las acciones del jugador."
N/A4058"#commentary\cn_144_delivery.mp3" "[ Ken Birdwell ] Se necesitaron muchas iteraciones y pruebas para dar con el equilibrio entre brindar información y generar conexión emocional en las principales escenas de Choreo. Cada escena contenía muchos datos que debíamos transmitir al jugador, pero los personajes no debían soltarlos así nada más, porque los jugadores los verían más como fuentes de información que como personas. Necesitábamos tomarnos el tiempo para dejar que los personajes interactuaran entre sí, dándole al jugador la oportunidad de observar sus relaciones. Al mismo tiempo, debíamos ampliar la construcción del mundo y que pudieran ver todo lo que sucedió en su ausencia. Todo tenía que hacerse con cuidado y sin mucha demora, ya que queríamos que el juego también fluyera para quienes no se interesan mucho en la narrativa. La animación se convirtió en una gran herramienta para comunicar las conexiones emocionales entre personajes: transmitíamos la profundidad de un momento rápidamente y sin exagerar. El humor también se usó mucho, ya que ayudaba a romper la tensión y bajarle la guardia al jugador cuando las cosas se ponían intensas."
N/A4059"#commentary\cn_145_alyxs_kiss.mp3" "[ Ken Birdwell ] Es un momento breve, pero el beso de Alyx en la mejilla de Eli era importante. Más adelante se le pedirá al jugador que salve a Eli, y queríamos que se preocupara por él. Para construir esa conexión emocional, necesitábamos mostrar la calidez y el afecto entre Alyx y Eli. No queríamos sobrecargarlo con diálogos ni convertirlo en un gran evento: debía sentirse genuino, no forzado. Pudimos iterar las sutilezas de este momento hasta encontrar el tono perfecto."
N/A4060"#commentary\cn_146_storytelling.mp3" "[ Bill Van Buren ] Crear una sensación de inmersión fue un principio fundamental en nuestro enfoque para la narrativa de Half-Life 1, y eso nos llevó a imponernos dos restricciones clave: nunca (o muy rara vez) quitarle el control al jugador y mantener siempre en silencio al personaje jugable. Estas limitaciones dificultaron contar la historia en algunos momentos, pero sentimos que era importante mantenerlas también para Half-Life 2. Nuestra esperanza era que estas limitaciónes nos obligaran a explorar una narrativa más profunda e interactiva."
N/A4061"#commentary\cn_147_archetypes.mp3" "[ Bill Van Buren ] Queríamos crear vínculos narrativos entre Half-Life 1 y Half-Life 2 a través de nuestros personajes. La idea era diseñar individuos que se sintieran como representaciones de los arquetipos de Half-Life 1, de modo que a los jugadores les resultaran familiares, casi como si los hubieran conocido en algún momento del primer juego, aunque no pudieran recordarlo con exactitud. El Dr. Kleiner se basa en el modelo de científico que considerábamos más icónico, y su personalidad estuvo muy influenciada por Hal Robins, cuya voz y actuaciones definieron a los científicos de Half-Life 1. Un día, cuando estábamos en pleno proceso de dar forma al personaje, el rostro del Dr. Kleiner apareció con claridad ante nosotros: íbamos en el ascensor con un contador de otra oficina del edificio, y al mirarlo fue evidente: ese era el rostro del Dr. Kleiner. Por suerte, aceptó que le tomáramos una foto para un personaje de un videojuego."
N/A4062"#commentary\cn_148_tone.mp3" "[ Bill Van Buren ] Definir el tono adecuado para nuestros personajes y sus diálogos era fundamental. Buscábamos interacciones respetuosas y hasta agradables con el jugador, sin llegar a ser serviles. Este equilibrio fue especialmente difícil con Alyx, quien debía apoyar al jugador sin comprometer la fuerza de su personalidad, algo que considerábamos esencial para que los jugadores la respetaran. Su relación con Eli era una de las principales motivaciones de los jugadores, por lo que era importante que la apreciaran y quisieran ayudarla. También queríamos contrastar la calidez y camaradería entre los aliados con la hostilidad de Breen y la Alianza, y que en los jugadores naciera un sentimiento de indignación justificada para las batallas que vendrían."
N/A4063"#commentary\cn_149_voice-actors.mp3" "[ Bill Van Buren ] Para crear personajes más receptivos y multidimensionales en Half-Life 2, necesitábamos evolucionar nuestro enfoque con los actores de voz. En Half-Life 1, la mayoría de los diálogos de los PNJ solo requirieron la lectura de un guion con instrucciones mínimas. Para Half-Life 2, quisimos que los actores tuvieran más libertad para construir y darles vida a los personajes. Les dimos mucho más contexto, les mostramos el mundo y los entornos que habitaban tanto sus personajes, como aquellos con los que interactuaban. Buscábamos actores que pudieran tomar toda esa información y usarla en sus interpretaciones para elevar a los personajes más allá de lo que hubiéramos imaginado. Tuvimos múltiples sesiones con los actores principales, lo que les permitió asimilar y desarrollar a sus personajes. En las escenas con interacciones entre varios personajes, les mostrábamos las interpretaciones de los otros actores de la escena para mejorar la conexión y la fluidez. Aunque durante las sesiones de grabación teníamos un guion y plan definidos, nos asegurábamos de que los actores se sintieran con la libertad de aportar sus propias ideas sobre los personajes y las interpretaciones. Contar con la presencia de los animadores durante las sesiones de grabación también resultó crucial, ya que eran los responsables de integrar los diálogos con acciones físicas y expresiones para dar forma a la escena de Choreo. Muchas veces, después de trabajar con los actores de voz, los animadores terminaban cambiando los planes que tenían para una escena."
N/A4064"#commentary\cn_150_citizens.mp3" "[ Bill Van Buren ] Cuando diseñamos a los ciudadanos humanos de Ciudad 17 y del mundo fuera de la ciudad, decidimos incluir una variedad de etnias, edades y géneros. Esto no solo aportaba contexto narrativo sobre cómo La Alianza oprimía a toda la humanidad, sino que también era importante para nosotros que cualquier persona que jugara se sintiera representada por la Resistencia: el mundo unido contra la Alianza. Si bien nuestras experiencias cotidianas y nuestros contactos personales nos dieron varios candidatos para usar como referencia en la creación de los ciudadanos, al final tuvimos que recurrir a publicar anuncios en el Seattle Times para encontrar la variedad de rostros que buscábamos."
N/A4065"#commentary\cn_151_alyx.mp3" "[ Dhabih Eng ] Dar en el clavo con el diseño de Alyx fue un gran desafío: queríamos que el jugador la respetara y también se preocupara por ella. Salvar a Eli era uno de los objetivos principales del jugador hacia la mitad del juego, y sabíamos que lograr el interés por esa meta sería más sencillo si también les importaban Alyx y la relación con su padre. El diseño, diálogos y la elección de la actriz de voz fueron muy intencionales para que el personaje resultara inteligente, capaz y cercano en un mundo controlado por la Alianza, y que al mismo tiempo fuera atractiva y carismática. Queríamos evitar la objetificación, la exageración y la hipersexualización de muchos videojuegos de los 2000, porque afectarían nuestros objetivos para el personaje."
N/A4066"#commentary\cn_152_lab_interactivity.mp3" "[ Dhabih Eng ] En las escenas de Choreo retuvimos al jugador por un momento para poder centrarnos en los personajes y la narrativa. Para adaptarnos a diferentes tipos de jugadores (algunos se interesan mucho en la historia y otros no pueden quedarse quietos), necesitábamos que en pantalla aparecieran detalles interesantes constantemente. Dispersamos elementos narrativos por todo el entorno y algunos eran interactivos; básicamente, eran “juguetes” con los que el jugador podía experimentar. En algunos casos, insertamos más narrativa dentro de estos elementos, como el cactus miniteletransportador, que insinuaba la futura falla del teletransportador. Fue un equilibrio delicado: muchos estímulos visuales pueden distraer a los jugadores de lo importante de la escena. Al final, al ser la primer gran escena de Choreo, limitamos la interactividad en el laboratorio de Kleiner. Pero, más adelante, exploramos la interactividad más a fondo en el laboratorio de Eli, y nos aseguramos de que los propios personajes reaccionaran a todo aquello con lo que los jugadores interactuaran."
N/A4067"#commentary\cn_153_gestures.mp3" "[ Doug Wood ] Cada uno de nuestros personajes tenía una biblioteca de animaciones simples llamadas Gestos, que podíamos superponer fácilmente sobre otros movimientos del cuerpo. Aunque originalmente estaban pensadas como un ahorro para producción, y reutilizar animaciones a lo largo del juego, descubrimos que podían servir para algo más. Los humanos suelen repetir ciertos movimientos, y estos pueden convertirse en marcadores de su personalidad. Como resultado, nuestra biblioteca de Gestos terminó capturando la esencia de cada personaje y ayudó a unificar la comprensión de nuestro equipo de animación sobre quiénes eran esos personajes. Esto también les facilitó dividir la carga de trabajo de cualquier personaje, algo que producción solicita constantemente."
N/A4068"#commentary\cn_154_interactive_storytelling.mp3" "[ Erik Johnson ] Cuando comenzamos a trabajar en Half-Life 2, la narrativa en los videojuegos solía dividirse entre dos enfoques: alta fidelidad pero lineal o baja fidelidad pero interactiva. Los jugadores ya habían experimentado historias de alta calidad en otros juegos, pero nunca habían estado en el centro de la experiencia, es decir, poder verla desarrollarse a su alrededor, interactuar con ella y examinar cualquier detalle de cerca. Aunque esa meta nos entusiasmaba, todavía no sabíamos cómo funcionaría ni qué tipo de tecnología necesitaríamos para hacerlo posible. Ya habíamos creado varias herramientas narrativas en Half-Life 1, pero en su mayoría estaban presentadas frente al jugador y carecían de la interactividad y la fidelidad que buscábamos. Por eso, el laboratorio de Kleiner se convirtió en el campo de pruebas para descubrir cómo funcionaría nuestra narrativa interactiva."
N/A4069"#commentary\cn_155_monitors.mp3" "[ Ido Magal ] Usamos monitores constantemente para la narrativa en Half-Life 2 y en los episodios, tanto que hasta nos burlamos de nosotros mismos, ¡pero es que son muy útiles! Son fantásticos para expandir el mundo, ya que muestran eventos que suceden en otros lugares, y permiten de manera sencilla que los personajes hablen sin tener que explicar cómo todos llegaron a donde está el jugador. Cualquiera que haya escrito una historia, especialmente con un elenco coral, entiende la frustración de justificar de forma natural que todos los personajes se reúnan en un mismo lugar. En este caso, nos gustó mucho cómo el monitor permitió que Alyx se teletransportara y luego apareciera rápidamente en el laboratorio de Eli, pues todo se sintió real y conectado."
N/A4070"#commentary\cn_156_scene_interactivity.mp3" "[ Jeff Lane ] En ciertos momentos de las escenas de Choreo, necesitamos que los jugadores realicen una acción. Más allá de darles algo que hacer y mantenerlos involucrados, estos momentos cumplen varios propósitos clave. Primero, permitían que el jugador se pusiera al día si se había distraído con algo en el entorno. La escena podía “pausarse” de forma segura hasta que el jugador completara la tarea, con lo que volvía a estar atento y presente. Al mismo tiempo, podíamos ubicarlo donde se necesitaba para enmarcar la escena y asegurarnos de que viera algo importante. A veces, incluso podíamos sacarles el doble de provecho a estos momentos, porque también sirven para enseñar: aquí, por ejemplo, los jugadores aprenden a interactuar con enchufes y tomas, una habilidad que necesitarán más adelante para resolver rompecabezas."
N/A4071"#commentary\cn_157_kleiners_lab.mp3" "[ Marc Laidlaw ] El laboratorio de Kleiner fue la primera pieza narrativa en la que trabajamos y también la que más nos costó definir. Además de servir como intro para el jugador, también se convirtió en la visión unificadora para el equipo de desarrollo en términos de narrativa. Conforme fuimos diseñando a nuestros personajes y la historia en torno al jugador, surgieron muchas preguntas, y todas representaban grandes riesgos para el juego. ¿Los jugadores podrían extraer la información importante de la escena? ¿Lograríamos que les importaran estos personajes? ¿Cómo podríamos acompañar a jugadores con niveles distintos de interés en la historia? ¿Cuánto costaría producir una escena así? ¿Y cuántas más necesitaríamos? Estas, y muchas otras, eran preguntas que no podíamos responder hasta haber desarrollado suficiente contenido de la escena y probado todo con muchos testers. Para nuestra frustración, a diferencia de otros problemas, estas preguntas no se podían responder con confianza hasta lograr un trabajo significativo. Normalmente podemos probar ideas de jugabilidad con prototipos de baja fidelidad, pero si un jugador no se interesa por la narrativa cuando los personajes apenas son bloques grises, ¿cómo sabremos si le importará cuando estén totalmente desarrollados?"
N/A4072"#commentary\cn_158_characters.mp3" "[ Marc Laidlaw ] En Half-Life 1, los guardias de seguridad y los científicos eran más arquetipos que individuos, abstracciones de personajes que se ajustaban a la fidelidad visual que podíamos lograr en ese momento. Pero, a medida que nuestra tecnología mejoró con Half-Life 2, vimos la oportunidad de ir más allá de esas abstracciones. El aumento en la fidelidad visual de los modelos, junto con las mejoras en la animación, nos permitieron crear personajes individuales: personas que realmente conectan con los jugadores. Nos permitimos escribir diálogos reales que los personajes interpretaran de forma tan natural, que para los jugadores no fueran simples peones en un videojuego y, con suerte, hicieran avanzar nuestra narrativa. En 2001, un par de años después de comenzar el desarrollo, encontramos inspiración en Ico, de Japan Studio. Dirigido por un animador, nos impresionó por su enfoque en los personajes como vínculo principal con el jugador, lo que nos dio el coraje para seguir avanzando."
N/A4073"#commentary\cn_159_writing.mp3" "[ Marc Laidlaw ] En la época de Half-Life 1, el objetivo de los juegos FPS era, principalmente, luchar y derrotar a un enemigo evidentemente malvado. Que los jugadores se preocuparan por los personajes era complicado con una fidelidad visual tan limitada como la de Half-Life 1, pero con los planes de mejora en la fidelidad para Half-Life 2, buscamos que los personajes se convirtieran en la fuerza que impulsaba la narrativa. El objetivo era que las motivaciones del jugador se alinearan con las de nuestros personajes: que el jugador se preocupara por estas personas, por sus esperanzas y temores, y que quisiera que tuvieran éxito. Con esto en mente, logramos definir nuestro enfoque para los personajes y los diálogos. Queríamos un grupo de personajes que se apreciaran y se cuidaran entre sí, con la esperanza de que el jugador compartiera el sentimiento. Los personajes tenían que interactuar de forma cercana e inclusiva, como si se tratara de un viejo grupo de amigos del que el jugador forma parte, y que simplemente se ausentó por un tiempo. Si los personajes demostraban conexiones emocionales realistas entre sí, creíamos que también se podía construir una conexión emocional con el jugador."
N/A4074"#commentary\cn_160_animation.mp3" "[ Miles Estes ] Crear movimientos humanos creíbles para nuestros personajes, a partir de muchas capas discretas de animación, requirió mucha iteración tecnológica. Incluso acciones simples, como girar para mirar algo o caminar hacia un punto, se volvían más complejas cuando se combinaban con la necesidad de responder dinámicamente al jugador y de cumplir con los comandos de Choreo. Por ejemplo, la acción de girar para mirar algo debía desarmarse por completo para que un personaje usara cualquier combinación de ojos, cabeza, hombros, torso superior o todo el cuerpo para orientarse hacia un objetivo. En Half-Life 1, los personajes humanos tenían los cuerpos divididos en mitad superior e inferior, lo que les permitía caminar en una dirección mientras miraban en otra, pero este enfoque era muy abstracto para los de Half-Life 2. En su lugar, nuestros animadores crearon animaciones de caminata en las ocho direcciones de una brújula, que podían combinarse sin problemas en tiempo real."
N/A4075"#commentary\cn_161_faceposer.mp3" "[ Yahn Bernier ] La herramienta principal que desarrollamos para correr el sistema de Choreo se llamaba FacePoser, un programa con un nombre no tan adecuado, que permitía a nuestros animadores diseñar la estructura completa de las escenas de una línea de tiempo; esa línea de tiempo contenía una serie de comandos de Choreo para los actores, más toda la información necesaria para que los ejecutaran. Al superponer los comandos en la línea de tiempo, los animadores podían definir fácilmente situaciones en las que un actor debía mirar hacia un lado, hablar hacia otro y caminar a una ubicación distinta, todo al mismo tiempo. Sin embargo, la línea de tiempo no era una secuencia fija ni completamente lineal. Los actores seguían sus instrucciones, pero tenían que responder dinámicamente al mundo que los rodeaba. Un actor podía tardar más en llegar a una ubicación si el jugador bloqueaba el paso, o tenía que esperar más para decir su línea si el jugador había retrasado a otro actor. FacePoser nos permitió iterar rápidamente sobre las escenas, probando diferentes disposiciones, formas de interpretar los diálogos y sincronizaciones. Esta capacidad de experimentar y ajustar con rapidez fue crucial para conseguir las interpretaciones adecuadas, así como nuestros objetivos narrativos y de caracterización."
N/A4076"#commentary\cn_162_choreo_commands.mp3" "[ Yahn Bernier ] Esta visualización de depuración muestra los dos comandos de Choreo más comunes que los actores reciben en una escena, conocidos internamente como “mirar a” y “moverse a”. A los actores se les asignan objetivos para mirar, a veces más de uno al mismo tiempo, y luego intentan enfocarse en el que tenga más sentido según el momento. Al mismo tiempo, pueden recibir comandos de “moverse a”, que les indican trasladarse a una ubicación específica y orientarse hacia un objeto o dirección concretos. Incluso estos comandos que parecían simples implicaban mucha complejidad. Por ejemplo, una escena podía requerir que un actor hablara mientras escribía en un teclado y miraba un objeto en la mano del jugador. Como no podíamos predecir dónde estaría el jugador durante la escena, crear secuencias como esta nos obligaba a dividir cada elemento de la escena en piezas y capas independientes. Luego, estas podían reensamblarse dinámicamente durante la reproducción de la escena, según las acciones del jugador e interrumpirse si era necesario."
N/A4077"#commentary\cn_163_antlions.mp3" "[ Kerry Davis ] Con el jugador conduciendo el arenero a lo largo de La Costa, necesitábamos un enemigo omnipresente que pudiera aparecer de forma justificada en cualquier lugar, como una amenaza constante, para mantener al jugador dentro o cerca del arenero. Las hormigas león que emergían de la arena fueron la solución perfecta. Con alta movilidad, podían alcanzar al arenero durante cortos periodos de tiempo, algo que nuestros enemigos humanoides no podían hacer. Además, aplastarlas se sentía muy bien."
N/A4078"#commentary\cn_164_thumpers.mp3" "[ Adrian Finol ] Siempre que sea posible, tiene mucho valor que los jugadores sientan que descubrieron cosas por su cuenta. El mundo se siente más vivo y no solo parece una serie de acciones de jugabilidad. Si aceptamos el riesgo de que tal vez un porcentaje de jugadores pase por alto algún elemento, podemos optar por un enfoque más sutil, como el que aplicamos con los restrictores. Diseñamos situaciones con las que los jugadores probablemente se encuentren, pero sin obligarlos a interactuar. Hay muchas pistas visuales y sonoras, así como reacciones de las hormigas león, que ayudan a entender lo que está ocurriendo. No garantiza que todos los jugadores lo descubran, pero las pruebas de juego mostraron que la mayoría sí lo hizo."
N/A4079"#commentary\cn_165_d2_coast_09.mp3" "[ Aaron Seeler ] Hacia el final del desarrollo de La Costa, llegamos al punto en que el código de juego estaba tan adelantado con respecto al diseño de niveles, que los programadores de jugabilidad empezaron a buscar nuevas tareas y más código que escribir para ayudar a que Half-Life 2 pudiera lanzarse. La exigencia de los niveles de La Costa generaba mucha carga de trabajo por la enorme escala y al uso extensivo de terrenos. Por ello, los programadores de jugabilidad comenzaron a diseñar encuentros más pequeños. Cuando los diseñadores de niveles lograron ponerse al día, crearon este nivel combinando tres encuentros separados diseñados por los programadores y pulieron lo necesario de cara al lanzamiento."
N/A4080"#commentary\cn_166_final_scene.mp3" "[ Bill Van Buren ] Encerrar al jugador en una cápsula para la confrontación final en la oficina de Breen fue una especie de concesión, pero nos permitió enfocarnos en los personajes de una forma que no se podía lograr en otras partes del juego. Todas las tramas alcanzan su conclusión en esta escena, y restringir el punto de vista del jugador crea la oportunidad de una recompensa emocional real: una escena culminante impulsada por la combinación de diálogos, actuaciones de voz y animaciones. La escena representó un gran desafío desde el punto de vista de la producción: configurar la puesta en escena y los movimientos correctos, lograr la sincronización precisa y la conexión emocional, y coordinarlo con todas las animaciones individuales y las actuaciones de voz grabadas por separado. Requirió muchos ajustes hasta alcanzar una sinergia dramática en la que los personajes tuvieran una verdadera conexión."
N/A4081"#commentary\cn_167_end_game_scramble.mp3" "[ Dave Riller ] Originalmente, estaba prevista una escena coreográfica mucho más grande para el final del juego, pero el equipo de Choreo no se daba abasto con la enorme cantidad de trabajo narrativo que faltaba por completar en el juego. Para aliviar parte de su carga, se le pidió al equipo de diseño de jugabilidad de la Ciudadela que, en su lugar, creara un desafío jugable para cerrar el juego. Podía ser un rompecabezas, un combate… cualquier cosa. El resultado fue la batalla final contra Breen, que aprovechó las mecánicas existentes de la pistola de gravedad y un poco de coreografía personalizada, lo que permitió crear el producto final en muy poco tiempo."
N/A4082"#commentary\cn_168_combine_portal_effects.mp3" "[ Gary McTaggart ] Una pieza clave de nuestro proceso de desarrollo es que cualquier miembro del equipo puede aportar sus habilidades en cualquier parte del juego. Una vez que la jugabilidad de la batalla final estuvo definida, los artistas y los programadores de efectos visuales ayudaron a elevar la presentación del portal al mundo de la Alianza y del efecto del tiempo detenido al final del juego. Para el efecto del portal de la Alianza se utilizó un shader refractivo similar al que usamos para el agua."
N/A4083"#commentary\cn_169_citadel_entrance.mp3" "[ Jeff Lane ] Armamos la ruta hacia La Ciudadela en sentido inverso: la geometría interior se creó primero como un prototipo artístico para perfeccionar su aspecto. Sabíamos que el jugador venía desde el alcantarillado en el mapa Streetwar, y tuvimos que diseñar una sección con deslizamientos y saltos hasta la entrada de La Ciudadela a modo de conexión."
N/A4084"#commentary\cn_170_citadel_steep_landing.mp3" "[ Randy Lundeen ] La Ciudadela se construyó muy tarde en el desarrollo y al principio no teníamos una visión clara para su jugabilidad. Esto no es raro: aunque el diseño de juego suele guiar nuestro proceso, las grandes decisiones creativas que tomamos al inicio (como la existencia de la Ciudadela de la Alianza) requieren un trabajo de diseño específico para encajar en el producto final. Tras la batalla culminante del capítulo anterior, pensamos que un tono distinto para el final en la Ciudadela resultaría más gratificante. Incluso si hubiéramos querido subir la apuesta, crear nuevas mecánicas y PNJ era demasiado arriesgado a esa altura. Nuestro primer plan fue hacer de esta sección un espectáculo narrativo pasivo: un viaje en tren a través del corazón de la maquinaria bélica de la Alianza que termina en la oficina de Breen. Pero después de desarrollar ese plan, pasamos unos días prototipando mecánicas de la superpistola de gravedad, pensando que al final del juego podríamos cumplir el deseo de los jugadores, haciéndolos sentir todopoderosos, sin alterar el equilibrio general del diseño. Los resultados fueron prometedores de inmediato, lo que llevó a un rápido rediseño para incorporar la superpistola de gravedad. En lugar de los desafíos tradicionales de fin de juego, queríamos que el jugador se sintiera como un dios: que atrapara enemigos a voluntad y arrancara consolas de las paredes. Al final, la Ciudadela combina ambos conceptos, y alterna entre espectáculo y poder desatado."
N/A4085"#commentary\cn_172_lightmap_pass.mp3" "[ Mike Dussault ] El interior de la Ciudadela es relativamente simple en términos geométricos, pero el material metálico de la Alianza y la iluminación dramática ayudan a transmitir la inmensidad de la estructura. La resolución de los mapas de luces se aumentó en las superficies importantes e interesantes y se redujo en aquellas que estaban totalmente en sombra o más distantes. Además, debido al gran tamaño de los espacios, las superficies de mapas de luces innecesariamente grandes tenían un costo significativo de rendimiento. Hacia el final del desarrollo se hizo una revisión extensa en todos los niveles para optimizar estos valores, y se equilibró atractivo visual y rendimiento. Esto fue más sencillo gracias a una nueva función añadida al editor de niveles Hammer, que permitía mostrar las superficies con su densidad de píxeles de luz."
N/A4086"#commentary\cn_173_super_gravity_origins.mp3" "[ Brian Jacobson ] Para este punto del desarrollo, ya estábamos seguros del diseño de la pistola de gravedad. Queríamos darle al jugador una probadita de sentirse omnipotente y nos pusimos a trabajar en una versión sobrecargada. No llevó mucho tiempo (de verdad, quizá un día de prototipos) para que tuviéramos algo que nos gustara y se convirtiera en el núcleo de la jugabilidad de la Ciudadela. Con nuestro motor de física terminado, podíamos encontrar formas nuevas y emocionantes de llevarlo más allá de sus límites anteriores y obtener los resultados divertidos que surgieran. Nuestro objeto de prueba, una sandía ultrapesada en nuestro simulador de física, terminó convirtiéndose en las esferas de la Alianza con las que interactúas en el juego."
N/A4087"#commentary\cn_174_combine_energy.mp3" "[ Brian Jacobson ] Lo que empezó siendo una sandía en forma de prototipo terminó convirtiéndose en una esfera de energía, después de que los sonidos creados para su impacto y explosión sonaran menos a fruta y más a lo que tenemos aquí en el juego. Una vez que empezamos a iterar en niveles que no estaban basados en sandías, vimos que podíamos usar la esfera de energía no solo como una forma divertida de eliminar soldados, sino también como un elemento de rompecabezas para encender y apagar distintos equipos. Mucho más adelante en el desarrollo, no estábamos conformes con el disparo alternativo del fusil AR2 y, como al equipo le gustaba la esfera de la Alianza, terminamos incorporándola directamente al disparo alternativo del arma. Siempre miramos atrás y nos sorprende cómo las cosas que funcionan de manera independiente dentro del juego acaban uniéndose al final para resolver problemas."
N/A4088"#commentary\cn_175_combine_wall_and_balls_training.mp3" "[ Ido Magal ] En las pruebas, los jugadores no notaban que las esferas de la Alianza disolvían a los soldados ni entendían por qué desaparecían. Al principio intentamos resolverlo haciendo que las esferas rebotaran con preferencia hacia los enemigos, para aumentar la probabilidad de que los mataran disolviéndolos. Con el tiempo, entendimos que no se daban cuenta porque el efecto siempre ocurría en medio de un combate intenso, y que la gente tiene una capacidad muy limitada para aprender cosas nuevas bajo estrés. Como solución de último momento, añadimos una sala de entrenamiento de baja presión con un campo de fuerza que solo puede abrirse agarrando la esfera de la Alianza. Este diseño se agregó específicamente para enseñar cómo funcionan estas esferas para desactivar campos de fuerza, y que al lanzarlas contra los soldados, los disolverían. Aun así, en las pruebas no tuvo tanto éxito. Pese a nuestros esfuerzos, algunos jugadores seguían teniendo dificultades para percibir los efectos de disolución de los proyectiles. Se nos acabó el tiempo y decidimos que, dado que los jugadores seguían diciéndonos que se sentían poderosos, estaba bien si no todos comprendían por qué estaban teniendo éxito."
N/A4089"#commentary\cn_176_weapon_strip.mp3" "[ Josh Weier ] Una vez que introdujimos la superpistola de gravedad, no queríamos que los jugadores volvieran a sus armas convencionales, así que hicimos lo único que tenía sentido: las desintegramos. Ayuda mucho tener enemigos sobrenaturales e inescrutables como los de la Alianza, porque obviamente lo más normal es que tengan un desintegrador. ¿Por qué no? Y si por alguna razón hubiéramos necesitado que recuperaras tu equipo en medio del nivel, qué coincidencia, también tenían un reintegrador."
N/A4090"#commentary\cn_177_breen_monologue.mp3" "[ Marc Laidlaw ] El trabajo creativo nunca se hace sin contexto, ya que todos nos inspiramos en otras cosas. El monólogo de Breen que aparece en los monitores de la Ciudadela se inspiró en parte en un juego anterior que todos amábamos: Thief 2, en el que el antagonista se burla del jugador mientras este se esconde. La ejecución es muy diferente, pero la inspiración central está ahí. Sin embargo, lo que realmente lleva este momento al siguiente nivel proviene de la actuación del fallecido Robert Culp. Su interpretación fue impecable. Dio a cada línea de Breen una sutileza y un estilo que transformaron al personaje en algo verdaderamente especial. Una sesión de grabación con Robert Culp era de lo más sencillo: tenía el guion, el ingeniero presionaba “grabar” y eso era todo. La lección que se refuerza con esto es trabajar con personas cuyo talento supera al tuyo, personas de las que estás seguro de que aprenderás. No hay que ir con una idea fija de cómo debe decirse una línea o cómo debe desarrollarse un momento en particular, sino que es mejor colaborar con gente talentosa y confiar en que lo harán incluso mejor."
N/A4091"#commentary\cn_178_dissolved_weapons.mp3" "[ Quintin Doroquez ] Todas las armas de la Alianza se configuraron para desintegrarse después de que los soldados quedaran en ragdoll con la pistola de gravedad por dos razones. Primero, para que los jugadores no las recogieran y usaran; segundo, para mejorar el rendimiento en esos mapas. Además, se añadió un gestor de ragdolls que eliminaba los cadáveres de soldados caídos a medida que el jugador avanzaba."
N/A4092"#commentary\cn_179_elevator_fight.mp3" "[ Brian Jacobson ] Aunque queríamos que el jugador se sintiera todopoderoso, no pudimos resistir la tentación de añadir una pelea difícil en el ascensor. La batalla mientras se espera la llegada del ascensor terminó siendo un poco más complicada de lo que habíamos pensado originalmente para esta parte. Durante las pruebas se volvió más sencilla, pero no hubo suficiente tiempo de testeo para equilibrarla al nivel que debería haber tenido. Aunque el jugador nunca estuvo en un peligro tan grande, es la cantidad de soldados que aparecen lo que hace que se sienta como una batalla más climática de lo que en realidad es."
N/A4093"#commentary\cn_180_replacing_the_prefabs.mp3" "[ Jeff Lane ] Las esferas de energía de la Alianza eran un diseño relativamente simple, con un campo de fuerza que contenía a estos objetos que rebotaban sin parar. Sin embargo, durante las pruebas hubo errores recurrentes: las esferas rebotaban sin control y \"escapaban\" del campo de fuerza que habíamos configurado para contenerlas. Debido a las limitaciones de nuestra tecnología de prefabricados en ese momento, esto obligaba a reconstruirlas manualmente varias veces, en cada una de sus ubicaciones, en todos los niveles de la Ciudadela que las incluían."
N/A4094"#commentary\cn_181_strider_fight.mp3" "[ Ted Backman ] Uno de los prototipos originales de la Ciudadela incluía la posibilidad de agarrar al zancudo con la superpistola de gravedad. Durante mucho tiempo en el desarrollo, la pelea con el zancudo giraba en torno a acercarse lo suficiente para atraparlo con el arma. En las etapas finales, decidimos que capturarlo lo hacía sentir demasiado débil, especialmente después de todo el combate contra ellos durante Batalla Urbana, así que reemplazamos el encuentro por uno en el que lo matas con esferas de la Alianza. Se añadieron piezas de modelo para que el zancudo pudiera ser desmembrado y volado en pedazos, en lugar de arrastrar su cuerpo. Esta es la única vez en el juego en la que un zancudo tiene este efecto."
N/A4095"#commentary\cn_182_getting_in_the_pod.mp3" "[ Dhabih Eng ] La secuencia de ascenso en la cápsula que comienza aquí requirió tomar control total de la escena y de la vista del jugador. Esto va en contra de nuestro deseo habitual de que el jugador conserve la mayor cantidad de control posible. Para este paso final, sentimos que el sacrificio valía la pena. El jugador es tan poderoso en este punto que resultaba difícil controlarlo. Así que tuvimos que deshabilitarlo. Aun así, todos los personajes de la escena siguen conversando, manteniendo al jugador en el centro de la atención. También pudimos aportar algo de narración a través del entorno en el camino. El viaje en tren por la Ciudadela que comienza aquí incluye varios adversarios para los que teníamos contenido artístico, pero que fueron recortados de la parte principal del juego. Desde tu segura y cómoda cápsula, puedes ver el procesamiento de los acechadores y un vistazo rápido al cangrejo synth."
N/A4096"#commentary\cn_183_turrets.mp3" "[ Mike Dussault ] Las torretas fueron una herramienta de diseño útil cuando el jugador llevaba ferópodos, ya que podían impedir por completo que las hormigas león se acercaran de frente. Esto nos permitió crear situaciones en las que al jugador no le bastaba con solo lanzar los ferópodos para avanzar: necesitaba rodear y eliminar las torretas para que las hormigas león pudieran ser las siguientes. Y no estaba de más verlas siendo acribilladas por los disparos de las torretas; resultaba un gran espectáculo visual."
N/A4097"#commentary\cn_184_grenade_puzzle.mp3" "[ Aaron Seeler ] Este pequeño rompecabezas detenía a los jugadores durante las pruebas, porque la caja de granadas ilimitadas no estaba colocada tan a la vista durante su recorrido. Para este punto del juego, los jugadores ya habían aprendido a asociar las cajas de munición ilimitada con soluciones para rompecabezas, así que si hubiera una caja de granadas aquí, sabrían de inmediato que necesitaban una granada para resolverlo. Queríamos que primero tuvieran que pensar un poco. Finalmente, añadimos una pista sutil: mostramos granadas visibles sobre un escritorio a través de una ventana, solo para recordarles que estaban disponibles. Esto también ayudó a descubrir un error en una prueba cuando un jugador se acercó para mirar más de cerca y terminó recogiendo las granadas a través del vidrio."
N/A4098"#commentary\cn_185_allied_turrets_balancing.mp3" "[ Adrian Finol ] Equilibrar esta pelea en torno a las torretas aliadas fue un reto. Las torretas son el elemento novedoso aquí, así que si los jugadores las ignoraban, la jugabilidad se sentía redundante porque gran parte era similar a lo que ya había aparecido antes. Queríamos que el uso de las torretas fuera necesario y que se recompensara su colocación estratégica, pero era algo binario: una colocación perfecta hacía que la pelea fuera fácil, mientras que una mala colocación la volvía muy difícil. El ajuste y la lógica personalizada de la IA de los soldados ayudaron: se volvieron mejores en derribar torretas lanzando granadas o flanqueando para tumbarlas. Estos cambios hicieron que la pelea no se tratara de preparar la disposición perfecta, sino de mantener activas las torretas, ya que cualquier configuración sería interrumpida en algún momento. Las pruebas variaron mucho: algunos jugadores la encontraron demasiado difícil y otros la consideraron su pelea favorita. Con el tiempo encima, finalmente la hicimos un poco más fácil y la lanzamos, aunque no quedamos del todo satisfechos con el equilibrio final."
N/A4099"#commentary\cn_186_meeting_mossman.mp3" "[ Ariel Diaz ] Reunir al jugador y a Alyx con Mossman después de la escena de la traición fue complicado, porque muchos jugadores sentían que deberían dispararle a Mossman en cuanto la vieran. No podíamos permitirlo, ya que no teníamos tiempo de desarrollar ramas alternativas de la historia. Sin embargo, tampoco queríamos que notaran que estábamos bloqueando esa elección, así que buscamos reducir la probabilidad de que los jugadores lo intentaran. El vidrio antibalas aquí da tiempo para el diálogo entre Alyx y Mossman, durante el cual queda claro que Alyx no cree que dispararle a Mossman sea lo correcto."
N/A4100"#commentary\cn_187_eli_in_pod_choreography.mp3" "[ Ken Birdwell ] Escribimos y grabamos el diálogo para esta escena mientras todavía estábamos construyendo Nova Prospekt. En ese momento sabíamos que Alyx y Gordon se teletransportarían fuera de la prisión, pero no habíamos definido ninguno de los detalles, así que el diálogo tenía que ser lo bastante amplio como para encajar con lo que finalmente construyéramos. Esto nos llevó a enfocarnos menos en las acciones del jugador y más en la vulnerabilidad de Alyx y su conexión con su padre. Esperábamos que la emoción sostuviera la escena más que la narrativa en sí misma. En última instancia, lo que buscamos es que el jugador se preocupe por estos personajes, que quiera priorizar lo que es importante para Alyx."
N/A4101"#commentary\cn_188_mossman_and_eli.mp3" "[ Bill Van Buren ] Esta escena coreografiada requirió una iteración considerable. Queríamos introducir un giro de la trama en medio de la escena sin restringir el control del jugador. Fue necesario un equilibrio delicado para que ese giro quedara claro y, al mismo tiempo, asegurarnos de que no pudiera interrumpirse. Si los jugadores seguían a Alyx hasta la consola, necesitaban entender lo que pasaba cuando se daban vuelta. Si se quedaban atrás observando a Mossman, también debían comprender lo que ocurría sin sentir que era algo que debían intentar impedir. Hicieron falta muchos ajustes y pruebas para lograr el ritmo adecuado, pero finalmente usamos una combinación de distracción, presentamos el momento crucial con rapidez y, al final, ofrecimos una explicación después de que sucediera."
N/A4102"#commentary\cn_189_nova_prospekt_entry.mp3" "[ Danika Rogers ] El jugador acababa de completar dos niveles cargados de combate, así que queríamos calmar un poco las cosas una vez que entrara. Estos primeros niveles se diseñaron como un cambio de ritmo, y permitían a los jugadores explorar la disposición de los interiores de Nova Prospekt. En el camino empezamos a introducir la jugabilidad con torretas: primero como un enemigo para el jugador y más adelante como una herramienta que podían usar. Gran parte de este nivel se armó reutilizando prototipos y espacios artísticos creados antes en el proyecto, cuando estábamos enfocados en definir la apariencia de Nova Prospekt."
N/A4103"#commentary\cn_190_turret_training_exit.mp3" "[ Doug Wood ] Este montón de basura, junto con el descenso abarrotado por las escaleras, está diseñado para desanimar a los jugadores de llevarse una torreta. Aunque no pasaría nada grave si lo hicieran, queríamos que fuera menos probable. Hacer que quedarse con la torreta resultara incómodo no es una estrategia de diseño ideal, pero era mejor que nada. Muchos de los jugadores de prueba finalmente se rendían y tiraban la torreta cuando sentían que el juego intentaba decirles algo."
N/A4104"#commentary\cn_191_allied_antlions.mp3" "[Eric Kirchmer ] Tener un ejército interminable de hormigas león reapareciendo sin parar para atacar torretas y soldados significaba que debíamos dedicar tiempo a definir el rol de los jugadores en el combate de Nova Prospekt. Ya se habían enfrentado a muchos soldados de la Alianza, así que decidimos que el combate aquí se sintiera más como un rompecabezas y un espectáculo que como un desafío de batalla. Con eso en mente, creamos situaciones que se mantenían en un estado estable hasta que el jugador intervenía. Al eliminar enemigos directamente, el jugador podía inclinar la balanza a favor de las hormigas león, pero queríamos que usar ferópodos resultara especialmente gratificante. En muchos escenarios, cuando el jugador arrojaba ferópodos sobre los enemigos, activábamos generadores adicionales de hormigas león, lo que activaba una oleada rápida de nuevas criaturas en la pelea. La masacre que se generaba era la recompensa que hacía que usar ferópodos fuera tan satisfactorio."
N/A4105"#commentary\cn_192_laser_mines.mp3" "[ Erik Johnson ] Disfrutamos mucho incorporar estas minas láser de proximidad en Nova Prospekt. Eran un arma de Half-Life 1 que no habíamos logrado incluir en Half-Life 2, pero al menos encontraron su lugar como elemento de rompecabezas. Nos gustaba cómo servían como una especie de prueba personal de moralidad cuando el jugador tenía un ejército de hormigas león. Algunos jugadores lanzaban los ferópodos inmediatamente a las minas de proximidad y usaban a las hormigas león como carne de cañón; otros retenían su pequeña colmena hasta haber eliminado con seguridad las minas con otras herramientas. Aquí no se juzga."
N/A4106"#commentary\cn_193_final_turret_arena.mp3" "[ Erik Johnson ] Al desarrollar el arco de un elemento de jugabilidad, como el uso de torretas aliadas, solemos armar primero un prototipo que represente el punto final de ese arco. Iteramos sobre ese prototipo hasta que las pruebas de juego muestran que funciona. Luego trabajamos a la inversa y añadimos escenarios previos para introducir el elemento y desarrollar la habilidad del jugador. Este enfoque asegura que el arco final sea atractivo sin invertir demasiado tiempo. También significa que, para cuando creamos los escenarios de entrenamiento, ya hemos observado suficientes pruebas como para saber qué habilidades necesitan guía y cuáles los jugadores asimilan de forma natural. Este escenario final con torretas era nuestro objetivo, ya que enfatiza la defensa del jugador contra enemigos que llegan desde múltiples direcciones y exige colocación y recuperación dinámicas de las torretas."
N/A4107"#commentary\cn_194_one_way_drops.mp3" "[ Jakob Jungels ] Los jugadores nunca saben qué tienen por delante, pero sí están familiarizados con lo que queda atrás, así que es común que retrocedan a terreno conocido cuando se encuentran con un enemigo. Si hemos construido un área en la que queremos que el jugador se enfrente (especialmente contra un enemigo con requisitos geométricos específicos, como el guardia hormiga león), necesitamos una manera de impedir que retroceda. Una solución común es hacer que el jugador entre al área por una caída sin retorno, algo que probablemente ya habrás notado varias veces."
N/A4108"#commentary\cn_195_npcs_on_elevators.mp3" "[ Jay Stelly ] A menudo dedicamos una cantidad considerable de tiempo a resolver problemas que los jugadores quizá ni siquiera noten. Muchos de estos son desafíos de diseño sutiles, mientras que otros provienen de la interacción entre múltiples sistemas. Por ejemplo, lograr que los personajes no jugables viajaran en ascensores resultó ser un problema complejo, porque involucraba varios sistemas: la toma de decisiones de la IA de los PNJ, la planificación de navegación y la simulación de movimiento, por nombrar algunos. Además, el propio ascensor tenía sus propios requisitos de simulación, independientes de los PNJ. Uno de los desafíos más sutiles surgía del hecho de que simulamos a los PNJ a una velocidad más lenta de la que simulamos los ascensores. Esto significaba que los PNJ en un ascensor descendente se simulaban (para asegurarnos de que estaban de pie correctamente sobre la plataforma) y luego el ascensor se simulaba varias veces, cada vez más abajo por el hueco, lo que dejaba al PNJ un poco atrás. Poco después, el PNJ se simulaba de nuevo y se colocaba otra vez sobre el piso del ascensor. Puedes imaginar lo difícil que era tomar en serio a Alyx cuando estaba cayéndose a pequeños saltos mientras hablaba contigo."
N/A4109"#commentary\cn_196_looktargets.mp3" "[ John Cook ] Una de las herramientas clave en nuestro repertorio de diseño es el Looktarget: un punto invisible en el espacio que se activa cuando el jugador lo mira. Los diseñadores pueden especificar con qué precisión el jugador debe mirarlo, la duración de la mirada y otras condiciones. Una vez activado, el Looktarget activa distintos eventos en el juego. Por ejemplo, Alyx puede esperar a que el jugador la mire antes de decir una línea de diálogo, un espectáculo puede comenzar solo cuando está dentro del campo de visión, o una nave de transporte de la Alianza puede sobrevolar cuando el jugador está mirando en su dirección. Una vez que implementamos los Looktargets, los diseñadores encontraron infinitas formas de usarlos para que la jugabilidad se sintiera más confiable para los jugadores, especialmente dado que algunos elementos se mueven a velocidades muy distintas o de maneras difíciles de predecir."
N/A4110"#commentary\cn_197_nova_prospekt_yard.mp3" "[ John Morello ] El combate a lo largo del patio de Nova Prospekt estuvo inspirado en gran medida por nuestras primeras observaciones de las hormigas león luchando contra los soldados de la Alianza. La alta movilidad y los ataques cuerpo a cuerpo de dichas hormigas se complementaban bien con la letalidad a distancia de los soldados y su vulnerabilidad en el combate cercano. Las hormigas león se ven geniales cuando están incendiadas, con efectos de partículas que vuelan por todas partes, y cuando finalmente alcanzan a un soldado, el efecto ragdoll que ocurre es sumamente satisfactorio."
N/A4111"#commentary\cn_198_vent.mp3" "[ John Morello ] Seguramente ya lo sabes, pero si hay un conducto de ventilación, tiene que haber un cangrejo dentro. Nosotros no inventamos estas reglas; vienen de arriba, igual que los propios conductos."
N/A4112"#commentary\cn_199_kitchen.mp3" "[ Kerry Davis ] Es una costumbre bien conocida entre los desarrolladores de videojuegos que en todas las cocinas en los juegos debe suceder una explosión de gas."
N/A4113"#commentary\cn_200_alyxs_tool.mp3" "[ Laura Dubuk ] La multiherramienta de Alyx fue increíblemente útil para usarla como una especie de llave. A menudo necesitábamos impedir que el jugador avanzara hasta que estuviéramos listos, y la multiherramienta le permitía iniciar una conversación mientras se abría camino. Tal vez abusamos de su uso, pero era difícil resistirse. Siempre hay un sacrificio: usar a Alyx para bloquear una sala, en lugar de crear una solución personalizada, ahorraba tiempo que podíamos dedicar a otras partes del juego más críticas."
N/A4114"#commentary\cn_201_mossmans_betrayal.mp3" "[ Marc Laidlaw ] Nuestro plan original para el arco de Judith Mossman era que traicionara al jugador en este punto. Pero cuando llegamos a esta escena, después de haber desarrollado otras partes del juego, sentimos que era más probable que solo intentara proteger a Eli. Imaginábamos que reconsideraba, dándose cuenta de que en realidad no podía traicionar a Gordon. Teníamos ideas para aclarar este cambio más adelante, pero al final nunca terminamos su arco. Nos gustaba la ambigüedad de Mossman, pero a los jugadores no parecía gustarles: casi todos la odiaban. Aunque quizá eso fue un éxito; trabajamos duro para construir la afinidad del jugador con Alyx, y Alyx no era precisamente fan de Judith tampoco."
N/A4115"#commentary\cn_202_d2_prison_05_start.mp3" "[ Yahn Bernier ] El jugador podía mover una gran cantidad de objetos, y dadas las limitaciones de las CPU de 2003, esto presentaba desafíos constantes. Una de esas limitaciones era que nuestro sistema de navegación de IA no detectaba objetos físicos dinámicos, como estas camas de metal. Aunque nuestro sistema de movimiento de PNJ sí podía detectar y esquivar objetos físicos mientras se desplazaba, estos eran básicamente invisibles durante las consultas de navegación para la planificación estratégica previa al movimiento. Esto se debía principalmente a limitaciones de rendimiento: no podíamos permitirnos algo más complejo. También afrontamos desafíos de diseño sin soluciones claras, como qué debía hacer un soldado si un jugador bloqueaba por completo un pasillo con objetos físicos grandes. Para resolverlo, les dimos a los PNJ fuerza adicional para empujar esos objetos. Luego mitigamos el problema mediante diseño de niveles, al ensanchar pasillos y asegurarnos de que hubiera suficiente espacio para maniobrar cualquier objeto que pudiera estar ahí. Estos ajustes son de alto riesgo: la combinación de soldados escondiéndose detrás de camas y las hormigas león iniciando combates cuerpo a cuerpo crea una alta probabilidad de interacciones incómodas entre el sistema de movimiento de los PNJ y las camas."
N/A4116"#commentary\cn_203_alyx_as_companion.mp3" "[ Miles Estes ] Esta sección se convirtió en un prototipo involuntario de lo que se mostraría en el Episodio 1, con Alyx como compañera, moviéndose con fluidez a lo largo de un recorrido que combina combate dinámico con coreografía predefinida. Aún no teníamos un modelo claro de cómo encajaría junto al jugador en estos escenarios, pero incluso este breve tramo nos enseñó mucho, a pesar de no haber tenido tiempo suficiente para iterarlo."
N/A4117"#commentary\cn_204_laundry.mp3" "[ Mike Dussault ] Para cuando los jugadores llegan a este nivel, conocido como Lavandería, estamos seguros de que ya se sienten cómodos usando ferópodos para superar escenarios de combate, por lo que quisimos subir la apuesta y creamos una situación que los animara a involucrarse aún más y combinaran el ferópodo con todo el arsenal de armas."
N/A4118"#commentary\cn_205_side_zombie.mp3" "[ Quintin Doroquez ] Este zombie venenoso siempre fue un punto destacado en las pruebas de juego. Los jugadores, tan concentrados en los soldados de la Alianza, las hormigas león y las torretas, ya tenían tiempo sin ver un zombie venenoso, así que su aparición repentina en la oscuridad era un factor sorpresa."
N/A4119"#commentary\cn_206_flares.mp3" "[ Quintin Doroquez ] Esta sección es un buen contrapunto al segmento anterior de torretas en términos de costo de producción e iteración. Se construyó muy tarde y tomó forma rápidamente, ya que la IA de Alyx y de los soldados de la Alianza ya estaba bien desarrollada. Nos gustaban la oscuridad y las bengalas, y la sección se guardó para explorarse a fondo más adelante. Más tarde la retomamos al planificar las secciones oscuras en Episodio 1."
N/A4120"#commentary\cn_207_magic_wall.mp3" "[ Robin Walker ] Como en muchas de nuestras áreas de combate, necesitábamos una especie de puerta para impedir que los jugadores avanzaran antes de terminar esta pelea. Lamentablemente, se nos acabó el tiempo y teníamos que pasar a la estación de tren, así que terminamos con esta tontería mágica: un muro que simplemente explota después de que derrotan a la segunda nave y revela el camino. Nos consolamos pensando que la mayoría de los jugadores no lo notarían, ya que estarían ocupados luchando contra las naves, y nuestras pruebas habían mostrado que en general todos terminaban la pelea antes de llegar a este punto. Con tantas explosiones en toda el área, el muro destruido y en llamas se sentía bastante natural, así que añadimos un par de rompecabezas simples de gas del otro lado para justificarlo. Pero no, no es algo de lo que estemos particularmente orgullosos."
N/A4121"#commentary\cn_208_ragdoll_vortigaunt.mp3" "[ Scott Dalton ] Este vortigaunt muerto representa un gran dolor: el de nuestros diseñadores de niveles. En ese entonces, nuestras herramientas de desarrollo no permitían que fijáramos la pose ragdoll, o sea, que cuando un PNJ moría, no teníamos control alguno sobre la pose en la que quedaba. De haber tenido más tiempo, nuestros animadores podrían haber generado un cuadro de animación con una pose más o menos como la que buscábamos, pero íbamos tarde y el equipo ya estaba saturado. Por lo tanto, un diseñador tuvo que hacer las siguientes pruebas: colocar al vortigaunt encima de esta silla, matarlo al cargar el nivel y esperar a ver la posición en la que quedaba. Después, ajustar un poco y volver a intentar. No sabemos bien cuántos intentos se necesitaron, pero fueron muchos más de los que se podrían imaginar."
N/A4122"#commentary\cn_209_nova_prospekt_process.mp3" "Al igual que Ravenholm, Nova Prospekt fue diseñada inicialmente con una jugabilidad muy diferente a la que finalmente se publicó. La primera versión se centraba en el combate jugador contra soldados de la Alianza, sin participación de hormigas león. A diferencia de otras áreas del juego, donde la jugabilidad y el arte evolucionaban juntas, Nova Prospekt recibió un fuerte impulso artístico desde el principio. Esto produjo un conjunto de secciones reutilizables y pulidas de geometría de nivel ya con arte aplicado. Ensamblar Nova Prospekt a partir de estas piezas funcionó bien, ya que la disposición de la prisión era naturalmente repetitiva. Más tarde, cuando regresamos con las hormigas león y los ferópodos, tuvimos que reutilizar la geometría para adaptarla a la nueva jugabilidad."
N/A4123"#commentary\cn_210_d2_prison_04.mp3" "[ Eric Kirchmer ] Durante el desarrollo, nuestros artistas crearon pequeños segmentos verticales de entornos, a los que llamábamos zoológicos artísticos. Estos zoológicos mostraban cómo usar texturas y accesorios para crear espacios de juego que cumplieran con nuestros objetivos visuales. Sin embargo, al desarrollar el recorrido jugable de la prisión, la disposición repetitiva nos permitió usar el arte de forma más directa. Este mapa se creó inicialmente como el zoológico artístico principal de Nova Prospekt, pero después de usarse para probar varios prototipos de jugabilidad, incluidos los que eventualmente dieron lugar a los ferópodos, pasó a formar parte de la arquitectura real del nivel."
N/A4124"#commentary\cn_211_autosave_dangerous.mp3" "[ Dave Riller ] En Half-Life 1 teníamos un set de autoguardados preestablecidos en el juego, que los diseñadores de nivel colocaron manualmente y se activaban cuando el jugador llegaba a un momento o posición determinada. Así, el juego se guardaba automáticamente mientras tú recorrías los pasillos de Black Mesa con tranquilidad. Sin embargo, para Half-Life 2 fue necesaria otra herramienta, porque algunas de las arenas más complejas presentaban problemas. Algunos encuentros duraban mucho e incluían un gran número de enemigos, mientras que otros tenían una larga combinación de exploración más combate, sin una clara separación. El problema es que si el juego se guarda automáticamente en un momento en el que el jugador corre el riesgo de morir justo al cargar la partida, puede quedar atrapado en un bucle de muerte (si jugaste muchos juegos de aquella época, seguro te pasó al menos una vez). Así que, a menos que diseñáramos pausas deliberadas en el flujo de cada área, no siempre había un lugar seguro para poner un autoguardado. Después de algunas pruebas, implementamos una función llamada Autosave Dangerous, una herramienta para diseñadores de niveles que combinaba un autoguardado con un lapso de tiempo asociado. Cuando el diseñador la activaba, el juego se guardaba de inmediato, pero ese guardado quedaba apartado, no disponible como archivo desde el que cargar la partida. Si el jugador sobrevivía durante el tiempo especificado, entonces el guardado se confirmaba y se usaba como el autoguardado más reciente. Esto permitía a los diseñadores colocar un autoguardado en un punto o momento razonable dentro de un área, especificar un tiempo (por ejemplo, 30 segundos), y si el jugador seguía vivo pasado ese lapso, ese autoguardado se aplicaba."
N/A4125"#commentary\cn_212_we_dont_go_to_ravenholm.mp3" "[ Dario Casali ] Al terminar el trabajo en Ravenholm, no podíamos quitarnos la sensación de que la transición desde el laboratorio de Eli no estaba funcionando. Era demasiado abrupta: el laboratorio conectaba directamente con las calles de la ciudad, a donde llegarías en breve, y la sección en la que estabas no existiría. Acabábamos de hacer esta promesa al final del laboratorio de Eli: “Ya no volveremos ahí”, y nos gustaba la tensión que habíamos creado. Pero cuando el jugador llegaba a Ravenholm, lo lanzábamos de inmediato al combate con zombies sin ningún espacio para generar tensión, así que armamos esta sección y los estrechos pasillos que siguen para resolverlo de una forma que nos dejara conformes. Bajamos el ritmo, nos enfocamos en el arte y la iluminación, y los preparamos para experimentar por qué ya no regresaríamos a Ravenholm."
N/A4126"#commentary\cn_213_lever_shenanigans.mp3" "[ Dario Casali ] Aun con todo el trabajo que hicimos para intentar que los jugadores asociaran esta palanca con la cerca eléctrica exterior, algunos testers igual la accionaban sin darse cuenta de lo que habían hecho. Incluso llegaban a deambular, volver a activar la palanca y seguir dando vueltas. Como no teníamos mucho tiempo para hacer más clara la conexión, optamos por hacer que la palanca se rompiera. Esto evitaba que los jugadores deshicieran su progreso. Además, sumaba a la sensación de que Ravenholm era un entorno poco confiable y en decadencia."
N/A4127"#commentary\cn_214_town_arenas.mp3" "[ Dario Casali ] En este punto de Ravenholm, el jugador ya aprendió todos los elementos de jugabilidad disponibles y puede predecir sus interacciones. Esto nos permite crear situaciones más complejas, y ofrecer un mayor nivel de amenaza y más libertad en cómo el jugador puede abordar cada escenario. Esta área es un espacio deliberadamente entrelazado que el jugador deberá explorar, y usamos ese tiempo de exploración para aumentar gradualmente la intensidad del combate. Cuanto más rápido explora el jugador, más rápido subimos la dificultad. La naturaleza libre de este diseño hizo que fuera un desafío equilibrarlo, dado el amplio rango dinámico en la manera en que los jugadores lo jugaban."
N/A4128"#commentary\cn_215_mines.mp3" "[ Dario Casali ] La compleja ruta que el jugador recorre para avanzar con seguridad por esta mina le da mucho tiempo para ver qué le espera al final. Y sorpresa: son cangrejos. Honestamente, casi siempre son cangrejos. Pero en este caso son cangrejos venenosos, que ya son divertidos por sí solos, pero se vuelven un verdadero caos cuando los combinas con cangrejos rápidos. Estos dos son una gran combinación: ninguno es particularmente peligroso por sí mismo, pero juntos son increíblemente letales. Una vez que lo envenenan, un solo golpe de un cangrejo rápido es suficiente para eliminar al jugador. Y eso es lo que los biólogos llaman simbiosis. O al menos, eso creemos."
N/A4129"#commentary\cn_216_poison_headcrabs.mp3" "[ David Speyrer ] Esta sala introduce de manera involuntaria a los cangrejos venenosos. Habíamos dedicado mucho tiempo a diseñar la introducción adecuada más adelante en el nivel, pero cuando vimos lo bien que funcionaban en las pruebas, la emoción nos ganó y, antes de darnos cuenta, los habíamos esparcido por todo el nivel. Para cuando notamos que aparecían antes de su introducción oficial, ya era demasiado tarde para rehacerlo. Afortunadamente, una sala cerrada llena de cangrejos venenosos funciona como un entrenamiento decente, ya que su diseño evita un problema común en el entrenamiento de combate. Normalmente, los jugadores se estresan y pueden frustrarse si mueren repetidamente sin entender por qué. Como era de esperar, nos topamos con ese problema cuando intentamos entrenar al jugador con los cangrejos venenosos y su origen, el zombie venenoso. Sin embargo, los cangrejos venenosos no pueden matar al jugador por sí solos, así que, aunque sea estresante, una sala llena de ellos al menos evita esa frustración."
N/A4130"#commentary\cn_217_poison_zombie_introduction.mp3" "[ David Speyrer ] Restringir al jugador en un espacio reducido mientras se le da una vista hacia el exterior es una forma útil de aumentar las probabilidades de que note algo que queremos que vea. Aquí llamamos la atención del jugador con el sonido de un lamento antes de que el zombie venenoso se haga visible. Originalmente, este encuentro también era la primera vez que los jugadores se enfrentaban a los cangrejos venenosos, pero, como mencionamos en una nota anterior, nos entusiasmamos demasiado esparciéndolos por todo el nivel y terminamos arruinando la introducción de ambos en este momento. Al final, sin embargo, estos primeros encuentros funcionaron mejor como instancias separadas."
N/A4131"#commentary\cn_218_final_arena.mp3" "[ Eric Smith ] Cuando terminamos la primera pasada de Ravenholm, esta azotea estaba pensada como la pelea culminante. Como otros espacios de Ravenholm, había nacido siendo un lugar diseñado únicamente para ser visualmente interesante. Sentíamos que era importante que, al dejar Ravenholm, el jugador tuviera un momento para mirar atrás hacia la ciudad que acababa de sobrevivir y vislumbrar adónde se dirigía después. Varios equipos de jugabilidad intentaron diseñar un combate aquí, pero la geometría reducida y las limitaciones de rendimiento hicieron que nunca lográramos un final con el que estuviéramos satisfechos. Al igual que en la propia saga de Half-Life, parecía que Ravenholm estaba destinado a no tener un final de verdad."
N/A4132"#commentary\cn_219_tables_and_bodies.mp3" "[ Ido Magal ] Hacia el final de la producción de Ravenholm, con todas las piezas principales en su lugar, repasamos el nivel intentando llenar cada hueco con algo interesante. Al hacerlo, teníamos que ser cuidadosos y usar solo lo que ya teníamos, sin crear nada nuevo, porque no podíamos arriesgarnos a sumar más errores. A menudo, como en esta sala, tratábamos de añadir nuevos momentos de jugabilidad y al mismo tiempo más detalle y narrativa al área. Escenas pequeñas como esta permiten que un jugador atento reflexione sobre lo que está viendo y lo que podría significar para lo que encontrará después."
N/A4133"#commentary\cn_220_physics_object_consistency.mp3" "[ Kerry Davis ] Todos los objetos con física tienen una variedad de parámetros que definen su comportamiento: su masa, la cantidad de daño que soportan antes de romperse, en qué se rompen, y así sucesivamente. Durante el desarrollo, estos parámetros eran especificados por los diseñadores de niveles para cada objeto, que era como funcionaba la mayoría de las cosas en el juego. Pero más adelante nos dimos cuenta de que nos habíamos creado un problema: había miles de objetos con física en el juego y ningún método para garantizar la coherencia entre ellos. Es decir, una caja de cartón podía romperse con un solo disparo de pistola en un nivel y ser completamente invulnerable en otro. Internamente, solíamos referirnos a estas inconsistencias como crímenes de los diseñadores de niveles. Para solucionarlo, y hacer justicia, desarrollamos un sistema que aplicaba consistencia a todos los objetos con física en función de su modelo visual. Dado que la mayor parte del juego ya estaba desarrollada, nos vimos obligados a permitir que los diseñadores de niveles quedaran explícitamente fuera de este sistema en casos extremos en los que necesitaban hacer algo \"criminal\" para preservar lo que habían diseñado. Internamente, nos referimos a estos diseñadores como reincidentes, algunos de los cuales siguen cometiendo crímenes en Valve hasta el día de hoy."
N/A4134"#commentary\cn_222_fast_zombie_introduction.mp3" "[ Randy Lundeen ] Este espacio fue otra área desarrollada originalmente para el E3 2003, donde se mostraba al jugador luchando contra un escuadrón de soldados de la Alianza. Cuando lo reutilizamos para presentar al zombie rápido, intentamos conservar la mayor parte posible del trabajo previo. Queríamos una toma icónica a la luz de la luna, con zombies saltando frente a ella como hombres lobo para atraer la mirada del jugador. Una vez concluido ese momento, introdujimos al primer zombie rápido en el espacio del jugador y se lo aventamos. Nos tomó muchas iteraciones encontrar el equilibrio adecuado de iluminación, de modo que la escena luciera bien y al mismo tiempo cumpliera con los objetivos de jugabilidad."
N/A4135"#commentary\cn_223_ravenholm_gameplay_focus.mp3" "[ Mike Dussault ] Tras observar muchas pruebas de Ravenholm, supimos que la jugabilidad central del nivel giraba en torno a la pistola de gravedad y la física. Una vez con ese conocimiento, sentimos que podíamos desarrollar adecuadamente la transición hacia Ravenholm y ayudar al jugador a aprender y comprender un poco lo que sería la experiencia más adelante. Esto ocurre a menudo: armamos el recorrido del nivel, descubrimos qué está funcionando y luego diseñamos su prólogo. Con esa idea de preparar la zona, construimos las siguientes salas. La brutalidad de las herramientas que le damos al jugador parecía contribuir a marcar el tono que buscábamos, y ayudaba a pasar de la seguridad del Laboratorio de Eli a algo más oscuro y aterrador."
N/A4136"#commentary\cn_224_player_tools.mp3" "[ Steve Bond ] A estas alturas del juego, los jugadores ya tienen mucha experiencia con la física de Half-Life 2, pero acaban de recibir la pistola de gravedad, que ofrece una nueva forma de interactuar con los objetos con física del juego. Iteramos una variedad de estos objetos con los que el jugador podía experimentar: sierras circulares, catapultas, bidones explosivos, trampas, lanzas, entre otros, y nos enfocamos en los que funcionaban bien con la pistola de gravedad y eliminamos los que no encajaban. Después, quitamos los objetos de munición de los niveles, de modo que el jugador tuviera que depender de estos objetos para sobrevivir."
N/A4137"#commentary\cn_225_contrived_setups.mp3" "[ Kerry Davis ] Hay una artimaña bastante obvia en varias de las secciones de entrenamiento de la pistola de gravedad y los objetos con física. El jugador arranca una sierra circular de la pared con la pistola y, justo en ese momento, un zombie aparece tambaleándose en la esquina, prácticamente pidiendo que le lancen la sierra. Luego, el jugador se arrastra bajo una trampa de cuchillas giratorias para apagarla, y de pronto aparecen tres zombies, lo que invita a volver a encender la trampa. No tuvimos mucho tiempo para iterar esta sección, así que necesitábamos planteamientos que funcionaran para todos los jugadores, no opciones más abiertas que dependieran de que hicieran la \"jugada correcta\". Aunque este tipo de diseño puede limitar la creatividad del jugador, en este caso descubrimos que no les importaba demasiado que los forzáramos un poco."
N/A4138"#commentary\cn_226_misteaching_flinches.mp3" "[ Kerry Davis ] Otra prueba de juego memorable, y ejemplo del peligro de enseñar mal a los jugadores, ocurrió en Ravenholm. Uno de nuestros principios de diseño es que el juego responda al jugador tanto como sea posible. Así que, al diseñar la pistola de gravedad, parecía obvio que si el jugador la apuntaba a un zombie y apretaba el gatillo, algo debería pasar. Era sencillo hacer que le diera una descarga al zombie con una pequeña cantidad de daño, lo que provocaba que ejecutara su animación de sobresalto, y eso se sentía bien y responsivo. Más tarde vimos una prueba de juego en la que el tester descubrió esta interacción inmediatamente al llegar a Ravenholm, e interpretó que era una señal de que la pistola de gravedad estaba hiriendo al zombie… lo cual era cierto, pero muy poco. Entonces lo volvió a electrocutar una y otra vez hasta matarlo. Esta era una forma de luchar contra zombies lenta, poco divertida e inhumana, especialmente en un lugar rodeado de sierras circulares y bidones explosivos. Tras aprender la lección, eliminamos esa animación de sobresalto, aunque eso significara perder esa interacción entre el zombie y la pistola de gravedad. En este caso, era mejor no tener esa interacción sencilla que dar la falsa impresión de que esta arma era un método eficaz para luchar contra zombies. Incluso los principios más simples pueden requerir sacrificios cuando se entra en detalles."
N/A4139"#commentary\cn_227_fire_trap.mp3" "[ Steve Bond ] Esta trampa de fuego fue concebida originalmente como una demostración visual del sistema de fuego, antes de que un diseñador de niveles la reutilizara como elemento jugable para Ravenholm. Estuvo a punto de ser eliminada varias veces durante el desarrollo debido al impacto en el rendimiento de las PC de gama baja, causado por la sobrecarga de detalle en todos los sprites transparentes. Al final, hubo un programador que consideró que era lo bastante importante para la jugabilidad, y valía la pena hacer el trabajo para resolver los problemas de rendimiento y asegurarse de que pudiéramos incluirla en el juego."
N/A4140"#commentary\cn_228_hallway_cupboards.mp3" "[ Yahn Bernier ] Estos pasillos llenos de chatarra fueron una solución sencilla a nuestra necesidad de ralentizar al jugador. Con la restricción de preservar tanta geometría existente como fuera posible, y teniendo a los zombies lentos como enemigos principales, era complicado evitar que los jugadores simplemente corrieran a toda velocidad por aquí. Por suerte, contar con Grigori como el lugareño demente de Ravenholm hizo que estos planteamientos fueran fáciles de justificar: tenía mucho sentido que él bloqueara la escalera para mantenerse a salvo en los tejados. Al final, la solución de Grigori y la nuestra eran la misma: amontonar muebles en el camino, porque si detenía a los zombies, probablemente también ralentizaría al jugador."
N/A4141"#commentary\cn_229_pacing_switch.mp3" "[ Steve Bond ] Ahora que los jugadores pasaron la sección de entrenamiento, podemos empezar a cambiar el ritmo: de espacios lúgubres y claustrofóbicos hacia arenas de acción más centradas en el combate. Con el jugador ya familiarizado con las distintas herramientas físicas del entorno, podemos comenzar a integrarlas en espacios abiertos y simplemente darle la libertad de elegir su propio enfoque."
N/A4142"#commentary\cn_230_car_crushers.mp3" "[ Steve Bond ] Estas prensas para autos requirieron varios ajustes y bastante trabajo en nuestro sistema de daño por física. Siempre hay un desafío cuando los objetos físicos grandes interactúan con los PNJ. Por ejemplo, si la física puede empujar al PNJ, podría arrastrarlo a un lugar donde no debería estar y dejarlo incapaz de recuperarse. Esto no es un gran problema para algo como un cangrejo, que puede saltar fuera de una situación complicada, pero para un zombie podría significar quedar atrapado e indefenso, agitándose en cualquier hueco en el que lograra atascarse. Y eso, en cierto modo, arruina el ambiente de survival horror que buscamos aquí."
N/A4143"#commentary\cn_231_car_crusher_lifts.mp3" "[ Eric Smith ] Lograr que las prensas para autos levantaran al jugador también fue complicado. O sea, el jugador siempre está siendo simulado tanto por el sistema de física como por el sistema de movimiento del juego. Cada vez que actualizamos el estado del jugador, comparamos los resultados de ambos sistemas y decidimos cuál es el \"correcto\", luego los sincronizamos y repetimos. Esto permite que los dos sistemas se influyan mutuamente: por ejemplo, cuando el jugador se para sobre un balancín, la física deja que la tabla ceda; o cuando se para en la prensa para autos, esta lo eleva. Aunque es más complejo, este enfoque de doble sistema resultó más fácil de ajustar que intentar manejar la física y el movimiento del jugador en un único sistema. Al mantenerlos separados, podíamos afinar el sistema de movimiento para que se sintiera bien por sí mismo, y solo reconciliarlos cuando la física afectaba al jugador."
N/A4144"#commentary\cn_232_paint_cans.mp3" "[ Steve Bond ] Una vez que empezamos a tener éxito en convertir la pistola de gravedad y la jugabilidad basada en la física en el núcleo de la experiencia de Ravenholm, comenzamos a revisar los niveles en busca de objetos que quizá hubiéramos pasado por alto, ya que estábamos ocupados trabajando con los más agresivos, como las sierras circulares y los bidones explosivos. Uno de los objetos que encontramos fue la lata de pintura. Resultó lo bastante simple reforzar las expectativas del jugador haciendo que, al arrojarlas contra los zombies, las latas los salpicaran con pintura."
N/A4145"#commentary\cn_233_bringing_physics_to_the_enemies.mp3" "[ Tom Leonard ] Las trampas físicas en Ravenholm fueron de los primeros elementos jugables del nivel con los que realmente quedamos satisfechos, pero carecían de agencia para el jugador. Fueron las sierras circulares las que nos ayudaron a descubrir de qué trataba realmente Ravenholm. Con las sierras, el jugador podía llevar la física a los zombies, en lugar de tener que atraer a los zombies hacia la física. Una vez que comprendimos esto, Ravenholm evolucionó rápidamente. Continuamos revisando el mapa en busca de cualquier cosa, sobre todo algo inusual, que pudiera convertirse en una herramienta o un arma para el jugador."
N/A4146"#commentary\cn_234_ravenholm_development.mp3" "[ Tom Leonard ] Comenzamos a desarrollar Ravenholm al inicio de la producción de Half-Life 2, así que pasó por más de una fase completa de desarrollo. La primera versión era anterior a la pistola de gravedad, con una jugabilidad centrada en el combate tradicional contra zombis con armas de fuego y algunas de las trampas físicas. Incluso planeamos mostrar Ravenholm en el E3 de 2002, pero el juego se reveló finalmente un año después, en 2003. Para ese momento, ya habíamos invertido mucho en el arte de Ravenholm, algo que generalmente evitamos hasta que la jugabilidad está totalmente testeada. Así que, cuando volvimos a trabajar en Ravenholm pensando en la mecánica de la pistola de gravedad, lo hicimos con mucha geometría de nivel preexistente, diseñada con un objetivo de jugabilidad muy diferente en mente."
N/A4147"#commentary\cn_235_grigori_plaza.mp3" "[ Steve Bond ] Esta plaza abierta es una de las áreas que fue detallada por completo en nuestra primera fase de desarrollo, y cuando volvimos a ella, quisimos preservar tanto como fuera posible del arte existente, mientras diseñábamos un nuevo recorrido para el jugador que usara las tres dimensiones. Mover al jugador hacia arriba y abajo, a través de ventanas, por los tejados, entre edificios. No era un espacio grande, así que tuvimos que exprimir al máximo el recorrido. Y como había comenzado siendo un área enfocada en el arte, estaba pobre en jugabilidad, lo que hacía que los testers pasaran de largo demasiado rápido. Para colmo, ya estaba llevando al límite nuestro presupuesto de rendimiento gráfico, con poco margen para añadir nada nuevo. El desafío pasó a ser encontrar pequeñas adiciones que ralentizaran al jugador, agregando amenazas en las esquinas y en cada rincón del nivel."
N/A4148"#commentary\cn_236_ravenholm_development_2.mp3" "[ Tom Leonard ] Cuando los fans nos hablan de Half-Life 2, Ravenholm suele ser la sección más recordada. Gracias a sus múltiples fases de desarrollo y a la densidad del material que contiene, en Ravenholm están representados más miembros del equipo que en cualquier otra parte. Fue ahí donde descubrimos cómo aplicar nuestro flujo de trabajo artístico a las escenas y la atmósfera que queríamos, cómo la física y la jugabilidad se combinaban con la pistola de gravedad, cómo los cangrejos y los zombies necesitaban evolucionar para Half-Life 2 y mucho más. Al mirar atrás, esto refuerza nuestra convicción en el poder del aporte individual por sobre el diseño centralizado. Ravenholm es denso, muy eficiente en su jugabilidad y ejecución artística, y la suma de muchas pequeñas contribuciones de individuos que entendieron cómo podían llevarlo un poco más allá con sus propias capacidades únicas."
N/A4149"#commentary\cn_237_playtester_archetypes.mp3" "[ Tom Leonard ] La iteración y las pruebas de juego regulares fueron el motor de la producción de Half-Life 2. Cada semana, observábamos en silencio y discretamente a un jugador que recorría la sección en la que estábamos trabajando y tomábamos notas sobre lo que funcionaba y lo que no. Era importante para nosotros probar con una amplia variedad de niveles de habilidad, para asegurarnos de que no estuviéramos tomando decisiones que solo funcionaran para algunos. Con el tiempo, aprendimos a elegir tipos específicos de testers según la etapa de desarrollo en la que estuviéramos. Al inicio, usábamos jugadores experimentados, normalmente compañeros de equipo, que podían afrontar áreas toscas e inacabadas y eran buenos para explicar su proceso de pensamiento. Para las pruebas de combate, buscábamos jugadores de todos los niveles de habilidad, en especial aquellos creativos en el uso de las herramientas. Finalmente, a medida que las secciones se pulían más, nos enfocábamos en principiantes: personas que no jugaban mucho o que no estaban familiarizadas con los shooters en primera persona. Incluso si no eran gente que pudiera comprar el juego, aprendíamos algo valioso al observarlos."
N/A4150"#commentary\cn_238_the_real_final_arena.mp3" "[ Tom Leonard ] Muy tarde en el desarrollo de Half-Life 2, cuando estábamos revisando todo el juego en busca de oportunidades de mejora final, decidimos que, en efecto, queríamos un verdadero final para Ravenholm. La pelea en los tejados no era suficiente. Tras debatirlo, optamos por agregar esta pelea final en el cementerio, con Gregori junto al jugador. Fue un riesgo a nivel de desarrollo, pero sentimos que el juego lo necesitaba. Como ya estábamos cerca del final de la producción, teníamos un conjunto maduro de herramientas de jugabilidad con las que trabajar, pero aún más importante: a esas alturas ya entendíamos nuestro propio juego. Hacer un juego suele ser un proceso de descubrir qué es lo que realmente estás creando. ¿Por qué es divertido nuestro juego? ¿En qué se diferencia? ¿Cuáles son los elementos más importantes? Al construir el juego y observar a los testers recorrerlo, fuimos aprendiendo las respuestas a esas preguntas, y con ello nos volvimos mejores para hacerlo. Así, el cementerio tomó forma rápidamente y requirió mucho menos iteración que muchas áreas anteriores del juego."
N/A4151"#commentary\cn_239_cities.mp3" "[ Eric Kirchmer ] Uno de los desafíos más complicados en esta sección fue encontrar la manera de darle al jugador la sensación de estar en una ciudad extensa, cuando nuestros presupuestos de rendimiento no nos permitían renderizar algo así. Esto nos llevó a enfocarnos en edificios de departamentos muy juntos, garajes subterráneos, túneles de metro, alcantarillas y similares. Lugares que se encuentran en las ciudades, pero que en general impiden ver hasta el horizonte. Luego complementamos ese estilo de diseño de niveles con ubicaciones de tipo vista, en las que todo el espacio estaba dedicado a ofrecer al jugador una perspectiva amplia. En esos casos podíamos destinar todo el presupuesto de rendimiento a la vista, sin tener que reservar nada de él para la IA enemiga o el combate."
N/A4152"#commentary\cn_240_strider_4.mp3" "[Eric Smith ] Aunque este mapa era el mapa de producción creado para el zancudo, aún contábamos con un mapa de desarrollo original para probar su IA. Siempre hemos encontrado mucho valor en tener un mapa de prueba sólido para una IA, ya que permite probar rápidamente nuevas ideas de jugabilidad y ajustarlas con facilidad. Si hay bugs o problemas de diseño, podemos aislarlos e iterar sobre ellos más rápido. Una vez que las características de la IA funcionan bien, las trasplantamos a los mapas de producción, con los que trabajan los diseñadores de niveles. El mapa de prueba del zancudo incluía esquemas rudimentarios de edificios en ruinas, con generadores infinitos de ciudadanos en distintas ubicaciones y alturas para proporcionar un flujo constante de objetivos. Esta configuración nos permitió refinar la IA del zancudo y sus cambios de postura, de modo que resultara interesante y atractivo, incluso para simplemente sentarse y verlo en acción."
N/A4153"#commentary\cn_241_perf_arena.mp3" "[ Aaron Seeler ] Esta área presentó un gran desafío: el rendimiento. Su tamaño y la combinación de la IA de los zancudos y los ciudadanos llevaron nuestros límites al máximo. Cuando hicimos el port de Half-Life 2 a Xbox, esta área no podía incluirse sin ciertos ajustes de diseño. Mantener la intención original y ofrecer la misma experiencia al jugador con menos herramientas y espacio fue un equilibrio complicado."
N/A4154"#commentary\cn_242_space_re-use.mp3" "[ Chris Green ] Volver a este espacio trajo múltiples ventajas. Primero, la obvia: los costos de producción de nuevas áreas siempre son altos, así que si podemos agregar más jugabilidad a un área existente, es un triunfo. Pero en una pelea difícil como esta, en la que el jugador se enfrenta a múltiples zancudos, la reutilización tiene beneficios adicionales. Como los jugadores ya han pasado por aquí antes, ya tienen una noción del diseño del área. Esta vez avanzan de atrás hacia adelante, pero el camino sigue en gran medida su ruta original. Esa familiaridad es útil cuando los jugadores necesitan avanzar para recoger recursos para la pelea. El estado devastado de Ciudad 17 por la guerra también nos dio la flexibilidad para ajustar coberturas y añadir obstáculos más pequeños en el recorrido, manteniendo el entorno dinámico y sorprendente."
N/A4155"#commentary\cn_243_tenements_and_courtyards.mp3" "[ Danika Rogers ] Usamos muchos pequeños trucos y construimos varias funcionalidades para dar a los jugadores la impresión de una ciudad en guerra, con gran parte del trabajo orientado a mostrar vistazos de escaramuzas o sonidos de combates lejanos. Los looktargets ayudaban a que siempre sucediera algo cada vez que un jugador miraba por una ventana, mientras que herramientas como los Tracer Makers permitían a los diseñadores crear fuego de trazado falso entre dos puntos. Combinado con las herramientas de audio, esto hacía que pareciera que dos grupos de enemigos se estaban tiroteando, sin necesidad de ejecutar ninguna IA. También desarrollamos pequeñas historias para grupos de ciudadanos que el jugador vería varias veces a lo largo del nivel. Todos estos momentos fueron ajustados con pruebas de juego para asegurar que la mayor cantidad posible de jugadores los experimentara."
N/A4156"#commentary\cn_244_hopper_mine_training.mp3" "[ Dario Casali ] Este panel de metal corrugado fue colocado deliberadamente sobre el agujero para animar a los jugadores a equipar la pistola de gravedad y retirar la obstrucción. Es un poco de manipulación de nuestra parte, porque descubrimos que entrenar a los jugadores con las minas de proximidad funcionaba mucho mejor si intentaban de inmediato usar la pistola de gravedad contra ellas, y el panel metálico aumentaba significativamente las probabilidades de que la tuvieran lista. Colocamos múltiples minas en el agujero para que los jugadores tuvieran varias oportunidades de interactuar con ellas, incrementando las posibilidades de que descubrieran maneras alternativas de deshacerse de ellas. Además, esta es la primera vez que hacemos un entrenamiento mientras el jugador está junto a todo un escuadrón de ciudadanos, así que aprovechamos esa oportunidad para incluir algunas líneas de diálogo relacionadas con las minas de proximidad."
N/A4157"#commentary\cn_245_dog_combat.mp3" "[ Eric Kirchmer ] Dog es un personaje muy divertido, y siempre buscábamos maneras de incluirlo en el combate junto al jugador. Sin embargo, lograr la escala adecuada de combate para él (es decir, un entorno apropiado, una IA enemiga nueva e incluso enemigos distintos) rápidamente quedó fuera del alcance del proyecto. Crear un escenario de combate que le hiciera justicia a Dog y pudiera estar a la altura del resto del juego casi se sentía como si estuviéramos desarrollando un juego nuevo dentro del que ya teníamos. Sabíamos que no podía simplemente correr hacia un soldado y darle un puñetazo: se vería menos impresionante, sin provocar asombro. Necesitaba amenazas más grandes que correspondieran a su escala, junto con formas interesantes de interactuar con ellas. Al final, optamos por crear una gran escena coreografiada, cumpliendo con los objetivos cinematográficos de Dog en combate, sin necesidad de incorporar un diseño jugable extenso."
N/A4158"#commentary\cn_246_strider_2.mp3" "[ Eric Kirchmer ] Iterar con el zancudo aquí finalmente nos dio una experiencia con la que quedamos satisfechos, ya que los jugadores necesitaban correr de cobertura en cobertura, y evitar el fuego mientras buscaban cohetes. Queríamos que los jugadores sintieran que se lanzaban a cubierto en el último segundo, así que ajustamos el patrón de ráfagas de la ametralladora del zancudo para señalar el peligro inminente. También construimos un sistema de rutas para que el zancudo las siguiera, lo que le permitía cambiar dinámicamente entre ellas para perseguir al jugador o establecer línea de visión. Esta configuración permitió a los diseñadores de niveles alinear cuidadosamente las rutas del zancudo con las coberturas del jugador para una experiencia equilibrada. La posición de las patas estaba controlada por código en su totalidad, y sus movimientos impredecibles indicaban que teníamos que ajustar con precisión para asegurarnos de que pateara un auto o un contenedor militar cuando era necesario."
N/A4159"#commentary\cn_247_manhack_tunnels.mp3" "[ Eric Smith ] Al desarrollar el comportamiento de IA de un PNJ, descubrimos que era útil que el programador de IA tuviera un mapa de prueba en el que pudiera experimentar. Ese mapa a menudo evolucionaba en un entorno diseñado específicamente para mostrar las capacidades únicas del PNJ. Más adelante, cuando la IA estaba lista para que los diseñadores de niveles la usaran, el mapa de prueba servía como un valioso punto de referencia: sin él, los diseñadores podían crear accidentalmente escenarios que hacían que una IA interesante resultara menos atractiva. En algunos casos, logramos incorporar directamente estos mapas de prueba al juego. Esta pequeña sección, por ejemplo, empezó como los túneles usados para desarrollar la IA del robosierra."
N/A4160"#commentary\cn_248_sniper_streets_2.mp3" "[ Erik Johnson ] En Half-Life 2, las balas en realidad no siguen una trayectoria de vuelo: llegan instantáneamente a su objetivo. Pero en el caso del francotirador, con su baja cadencia de fuego y la atención del jugador en cada disparo, quisimos simular el recorrido de la bala. Este enfoque también funcionaba mejor con la mira láser, donde la luz se apaga y la bala impacta poco después, dependiendo de la distancia al francotirador. Sin embargo, este cambio introdujo un nuevo problema: no queríamos que los jugadores simplemente corrieran calle abajo para esquivar los disparos, así que el francotirador tenía que anticipar a un objetivo en movimiento y predecir dónde debía impactar la bala. Adelantarse a la posición futura del jugador fue complicado, ya que los jugadores pueden cambiar de dirección mucho más rápido de lo que sería posible en el mundo real. Por eso añadimos controles adicionales para detectar comportamientos como cuando los jugadores tecleaban rápidamente izquierda y derecha mientras corrían."
N/A4161"#commentary\cn_249_triangle_plaza.mp3" "[ Ido Magal ] Esta batalla en la plaza fue compleja de armar y utilizaba el comportamiento de Asalto, con dos líneas de combate convergentes, una para cada campo de fuerza. A medida que los soldados entran desde detrás de los campos, sus líneas de batalla evitan que se lancen individualmente a la plaza. Conforme la pelea se intensifica y los soldados se acumulan, las líneas de batalla comienzan a avanzar hacia el centro de la plaza, lo que hará que los soldados abrumen al jugador si no se les pone un freno."
N/A4162"#commentary\cn_250_sniper_streets_3.mp3" "[ Jakob Jungels ] Una de las características que probamos en estas calles fue el fuego de supresión. Muchos jugadores, atrincherados al final de la calle, disparaban una ráfaga hacia la ventana del francotirador para ver si tenía efecto. Así que experimentamos haciendo que la mira láser parpadeara brevemente, lo que daba a los jugadores un momento para reubicarse. Pero tras varias sesiones de prueba, nos encontramos con dos problemas: primero, interrumpía la jugabilidad tensa de moverse y esconderse que queríamos crear con el francotirador. Correr mientras se disparaba no era muy distinto de otras acciones que ya pedimos al jugador en Ciudad 17. El segundo problema, más sutil, era que los jugadores que descubrían primero el fuego de supresión asumían que era obligatorio y gastaban munición muy rápido. Si se quedaban sin ella a mitad de camino, a menudo abandonaban pensando que habían fallado; y si lo lograban, a menudo se quedaban sin munición. En cambio, los jugadores que completaban el escenario con sigilo casi no gastaban munición. Esta brecha de recursos entre enfoques hacía casi imposible equilibrar la munición para las secciones siguientes, así que no lo incluimos en el juego final."
N/A4163"#commentary\cn_251_assault_behavior.mp3" "[ John Cook ] El comportamiento más complejo que construimos para Half-Life 2 fue el de asalto, que se utiliza a lo largo de esta sección del juego. Este permitía a los diseñadores de niveles configurar escenarios de combate con soldados de la Alianza y ciudadanos, y establecer líneas de batalla entre ellos y controlar cómo se desarrollaban esas batallas según las acciones del jugador. Los PNJ involucrados en un asalto intentaban encontrar posiciones de disparo inteligentes y usar la cobertura según la ubicación de la línea de batalla. A medida que el jugador avanzaba por una calle, podía hacer también que avanzara la línea de batalla, lo que hacía que los ciudadanos aliados avanzaran mientras los soldados enemigos retrocedían. Alternativamente, el jugador podía necesitar derribar algunas torretas de la Alianza o eliminar a un soldado tras una barricada para avanzar la línea de batalla."
N/A4164"#commentary\cn_252_bank_roof_mortar.mp3" "[ John Morello ] Para cuando habíamos construido el recorrido del nivel hasta este punto, era obvio que sería divertido para el jugador poder usar el mortero. Supongo que eso es el tipo de cosa que deberíamos haber pensado antes. \"¿Crees que alguien querrá lanzar explosivos al cielo y que caigan sobre los enemigos? Sí, yo también lo creo\". De todos modos, los jugadores habían pasado todo este tiempo siendo el blanco del mortero, así que habría sido una buena recompensa hacer que la Alianza probara de su propia medicina. Pero en cuanto empezamos a pensarlo, nos dimos cuenta de cuánto trabajo implicaría, lo cual, siendo justos, es un pensamiento que tienes todos los días cuando te propones hacer un videojuego. El mortero necesitaría animaciones y efectos ahora que el jugador estaría junto a él, y habría que trabajar bastante para implementar una buena escalada de enemigos en la plaza sobre los que usarlo. Pero, más fundamental aún, no teníamos interfaz para un arma tan única. ¿Cómo apuntarían y dispararían los jugadores? Es difícil sentirse bien invirtiendo mucho tiempo en un único momento del juego, así que decidimos que nuestros esfuerzos estarían mejor empleados en otra parte y seguimos adelante. ¡Lo siento! Quizás resolvamos el dilema de diseño del mortero en una futura entrega de la serie Half-Life."
N/A4165"#commentary\cn_253_strider.mp3" "[ Kerry Davis ] Esta área frente al banco fue donde descubrimos cómo funcionaría el zancudo. Cuando vimos por primera vez el arte conceptual, supimos que queríamos incluirlo en el juego, pero había muchísimas preguntas sobre cómo funcionaría en la práctica. Nunca habíamos movido algo de ese tamaño a través del mundo de juego, y a esa escala debía ser peligroso, pero ¿cómo lucharían realmente los jugadores contra él? Como con todos nuestros enemigos, siempre estaba la pregunta de cómo lo involucraríamos en la jugabilidad. ¿Qué tipo de herramientas necesitarían los diseñadores de niveles para construir escenarios con él? Estas eran las preguntas que nos propusimos responder en nuestros experimentos en este mapa."
N/A4166"#commentary\cn_254_sniper_streets.mp3" "[ Eric Kirchmer ] Estas calles llenas de francotiradores son donde desarrollamos tanto al enemigo como el núcleo de la experiencia que esperábamos que los jugadores tuvieran. Sabíamos que queríamos que el francotirador disparara a cosas cerca del jugador, así que primero nos enfocamos en encontrar una variedad de objetivos interesantes para que los atacara. Descubrimos que funcionaba bien si usábamos la vista del jugador como factor para seleccionar objetos. La mira láser siempre activa del francotirador significaba que los jugadores tenían un indicador constante de su atención, por lo que hacer que se desviara hacia un objetivo en el que el jugador estaba mirando se sentía muy responsivo y creaba grandes momentos de tensión."
N/A4167"#commentary\cn_255_citizen_squad_details.mp3" "[ Matt Wright ] Una vez que establecimos el escuadrón ciudadano del jugador y empezamos a construir escenarios en torno a él, descubrimos que esto creaba otras oportunidades interesantes. Los testers empezaron a interesarse por miembros específicos del escuadrón, así que añadimos más elementos a su diseño. Los miembros podían recoger armas mejores si las encontraban, darle munición al jugador cuando la necesitaba, y los médicos lo curaban según fuera necesario. También tuvimos que asegurarnos de que el escuadrón pudiera seguirle el ritmo a ese tipo de jugador que a menudo tomaba caminos impredecibles. Fuera de cámara, el escuadrón hacía \"trampa\" de varias maneras: regeneraba salud entre combates, se movía rápidamente para alcanzarlo e incluso se teletransportaba cuando era necesario."
N/A4168"#commentary\cn_256_citizen_squads.mp3" "[ Ken Birdwell ] Nuestras pruebas iniciales con las peleas callejeras entre la Alianza y los ciudadanos revelaron un problema: sin límites, la IA de combate podía alejarse significativamente del jugador. Los soldados podían retroceder para recargar o cubrirse, y la IA de los ciudadanos los perseguía. Necesitábamos una manera de alinear las acciones de los ciudadanos más estrechamente con los objetivos del jugador, y mantenerlos conscientes de hacia dónde se dirigía y de qué enemigos quería enfrentar. Esto llevó a la creación del escuadrón ciudadano del jugador. La IA de los ciudadanos usaba este escuadrón para moverse junto al jugador, enfrentar a los mismos enemigos y proporcionar una interfaz básica para los comandos del jugador. Inicialmente, teníamos un sistema de comandos más complejo, pero rápidamente se volvió poco manejable, así que lo simplificamos."
N/A4169"#commentary\cn_257_ai_behaviors.mp3" "[ Mike Dussault ] Una de las tecnologías de IA que desarrollamos para Half-Life 2 fue el sistema de comportamientos, que eran bloques de código de jugabilidad de IA que guiaban a los PNJ en situaciones específicas. Por ejemplo, teníamos un comportamiento de guía que permitía a un PNJ guiar al jugador, y un comportamiento de seguimiento que le permitía seguir al jugador u otro PNJ. Estos comportamientos funcionaban junto con las acciones básicas del PNJ, de modo que un compañero médico usando el comportamiento de seguimiento para mantenerse al lado del jugador aún sabría disparar a los enemigos, esquivar granadas u ofrecer un botiquín."
N/A4170"#commentary\cn_258_occlusion.mp3" "[ Brian Jacobson ] En Half-Life 1 y en gran parte de Half-Life 2, el mundo consistía principalmente en túneles y pasillos cerrados, lo cual funcionaba bien con un árbol de partición binaria del espacio. En esencia, esta tecnología nos permitía ordenar rápidamente la geometría y determinar qué podía ser visible para el jugador. Pero las áreas abiertas en la costa y otras secciones exteriores no se adaptaban a ese enfoque, así que necesitábamos nueva tecnología. Una fueron los portales de área, que nos permitían dividir el mundo en fragmentos discretos separados por portales (me refiero a puertas y ventanas, no a los de Aperture Science). También desarrollamos un sistema adicional de oclusión, que básicamente decía: \"si el jugador no puede ver a través, por encima o alrededor de un objeto grande, no renderices lo que hay del otro lado\". Puede parecer obvio no hacerlo, pero requiere trabajo asegurarse de que calcular lo que hay del otro lado de un objeto grande no sea más lento que renderizarlo todo. Para hacer ese cálculo rápido, los diseñadores de niveles colocaban grandes volúmenes de oclusión dentro de las formas principales del terreno y de los grandes objetos que bloqueaban la vista, como edificios. Durante el renderizado, entonces podíamos probar los límites de las entidades contra estos volúmenes y evitar renderizar lo que el jugador no podía ver."
N/A4171"#commentary\cn_259_detail_objects.mp3" "[ Brian Jacobson ] Una vez que tuvimos las secciones al aire libre en funcionamiento, quedó claro que necesitaban algún tipo de detalle de alta frecuencia, así que añadimos pequeños elementos de follaje, como césped y arbustos, en todo el terreno de desplazamiento. Pero sabíamos que no podíamos permitirnos colocarlos todos a mano, es decir, no teníamos tiempo. Por eso construimos el sistema de objetos de detalle que genera automáticamente pequeños elementos de follaje en función del material de desplazamiento. Cada material especifica el tipo de follaje a colocar, junto con un conjunto de parámetros. En el momento de compilar el mapa, el sistema calcula puntos aleatorios en la superficie y selecciona el follaje para colocarlos allí. Dadas las restricciones de rendimiento, aún había un proceso manual bastante complejo para las hojas de texturas de follaje, lo que nos permitía renderizarlos todos en una sola pasada."
N/A4172"#commentary\cn_260_displacements_1.mp3" "[Charlie Brown ] Después de lanzar Half-Life 1, nuestros diseñadores de niveles y artistas querían una mejor solución para los entornos al aire libre, así que construimos la primera versión de nuestro sistema de terrenos. Estaba basado en cuadriláteros subdivididos. Para visualizarlo, imagina un cuadrado plano dividido en una cuadrícula, donde cada punto de la cuadrícula puede moverse hacia arriba o hacia abajo. Los diseñadores de niveles podían disponer múltiples cuadrados y luego usar una herramienta de pincel para dar forma a colinas y valles ajustando los puntos de la cuadrícula. Para el renderizado, utilizamos una textura especial combinada, que mezclaba dos texturas diferentes. Cada punto de la cuadrícula especificaba cuánto de cada textura usar, lo que daba lugar a transiciones suaves entre superficies como arena, pasto, tierra y grava. Este tipo de sistema de terrenos no era inusual en los motores de juego de la época. Ingenuamente, pensamos que sería suficiente para nuestros diseñadores."
N/A4173"#commentary\cn_261_displacements_2.mp3" "[ Charlie Brown ] Una vez que el sistema inicial de terrenos estuvo en marcha, esperábamos que los diseñadores de niveles lo usaran para los espacios al aire libre. En cambio, comenzaron a experimentar y añadieron detalles en lugares inesperados. Usaron los cuadriláteros subdivididos sobre las paredes para crear bordes en ruinas, bordear las aceras e incluso intentaron hacer tuberías. Esto tuvo resultados dispares, ya que el sistema de terrenos estaba diseñado para paisajes, no para detalle arquitectónico. Así que volvimos al código y transformamos el sistema de terrenos basado en altura en un sistema de desplazamiento totalmente 3D. Ahora, en lugar de mover los puntos de la cuadrícula solo hacia arriba o hacia abajo, los diseñadores podían moverlos en cualquier dirección. Esto les permitía añadir detalle extra a todo tipo de superficies, usando texturas combinadas para suavizar las transiciones entre los cuadriláteros de desplazamiento y la geometría de partición binaria del espacio. Sin embargo, esto requirió trabajo técnico adicional para garantizar una iluminación consistente entre los dos renderizadores, o de lo contrario esos bordes habrían quedado notablemente desajustados. Pero con todo esto hecho, los diseñadores de niveles parecían satisfechos y, con ingenuidad, pensamos que esta vez sí sería suficiente."
N/A4174"#commentary\cn_262_displacements_3.mp3" "[ Charlie Brown ] Con el sistema general de desplazamiento en mano, los diseñadores de niveles no se conformaron con añadir detalle al mundo y volvieron a sus objetivos originales de construir secciones al aire libre a gran escala. Esto llevó a otra ronda de actualizaciones para equilibrar el rendimiento y asegurarnos de que el sistema pudiera manejar tanto el detalle fino como el terreno amplio del suelo. El texturizado también tuvo que mejorar, especialmente para admitir estructuras complejas como acantilados sobresalientes, que no eran posibles con el sistema original basado en altura. Los diseñadores, que no saben quedarse quietos, también empezaron a usar desplazamientos para crear cuevas y túneles. Aunque estas adiciones se veían muy bien, exigieron aún más ajustes técnicos. Finalmente, logramos dominar los requisitos que competían de todas las formas en que se estaban usando los desplazamientos, y terminaron en grandes secciones de nuestro mundo de juego. Mirando atrás, los desplazamientos son un claro ejemplo de cómo la tecnología y el diseño de juegos evolucionan juntos. Es un problema del huevo y la gallina: no podemos prever todas las formas en que una pieza tecnológica impactará el juego, pero tampoco podemos construir la tecnología sin saber lo que debe lograr. Así que, como siempre, tenemos que construir algo. Empezamos con una suposición sólida y vemos a dónde nos lleva."
N/A4175"#commentary\cn_263_particles.mp3" "[ Chris Green ] Para el motor Source, invertimos en expandir la tecnología de partículas y efectos especiales. Esto permitió un movimiento de partículas más realista y complejo, así como formas más elaboradas y efectos de sombreadores más intrincados. En particular, añadir mapeado topológico a nuestras partículas marcó una gran diferencia en su apariencia volumétrica. Si bien las iteraciones posteriores del motor Source incluyeron un editor de sistemas de partículas muy potente, la versión original usada en Half-Life 2 dependía de efectos hechos a mano, cada uno de los cuales requería que un programador construyera meticulosamente el efecto de forma manual, lo que implicaba un proceso bastante intensivo en trabajo."
N/A4176"#commentary\cn_264_cubemaps.mp3" "[ Chris Green ] Con la incorporación de materiales y sombreadores, necesitábamos una solución para las superficies reflectantes como el vidrio y el acero. Estas superficies debían saber qué reflejar, pero en 2003 no podíamos hacer ese renderizado en tiempo real, así que desarrollamos el sistema de mapeo de cubos para reflejos precomputados. Un mapeo de cubos es un conjunto de seis imágenes en el interior de un cubo, que capturan el entorno en todas las direcciones, como una foto panorámica que te rodea por todos los lados. Los diseñadores de niveles colocaban entidades invisibles de marcador a lo largo de los niveles y, durante la compilación del mapa, generábamos un mapeo de cubos en cada marcador. Luego, durante la jugabilidad, al renderizar una superficie reflectante, localizábamos el mapeo de cubos precomputado más cercano para crear el reflejo."
N/A4177"#commentary\cn_265_water_shader.mp3" "[ Gary McTaggart ] El sombreador más complejo que hicimos para el juego fue el del agua, que aprovechaba por completo las tarjetas gráficas programables, recién disponibles en ese momento. Cuando había agua, la escena se renderizaba tres veces: primero, el mundo bajo el agua para la refracción; segundo, una vista reflejada; y tercero, las partes por encima del agua. Al renderizar la superficie del agua, combinábamos las vistas refractiva y reflectante, y mostrábamos más reflexión en ángulos rasantes mediante la ecuación de Fresnel. También registrábamos la profundidad del suelo bajo la superficie del agua, para hacerla más transparente y menos refractiva en áreas poco profundas. Además, tuvimos que crear dos técnicas alternativas de renderizado de agua para tarjetas gráficas de gama baja: las tarjetas de gama media mostraban una reflexión de menor detalle sin refracción ni transparencia, mientras que las tarjetas de gama baja solo renderizaban una superficie parcialmente transparente."
N/A4178"#commentary\cn_266_normal_maps.mp3" "[ Gary McTaggart ] Half-Life 2 se desarrolló en una época emocionante para los gráficos, cuando las primeras tarjetas gráficas programables con soporte para sombreadores llegaban al mercado. Gracias a esta tecnología, fuimos uno de los primeros juegos en implementar el mapeo normal, una técnica que mejoraba la iluminación sobre la geometría de las superficies. Esta técnica describía la rugosidad de la superficie, lo que permitía que cada píxel de un polígono se iluminara de una manera que hacía que las superficies parecieran más irregulares y detalladas de lo que jamás había sido posible en Half-Life 1."
N/A4179"#commentary\cn_267_rendering_systems.mp3" "[Gary McTaggart ] A comienzos de los años 2000, no podíamos permitirnos un renderizador de propósito general con las amplias capacidades de un motor moderno. En su lugar, las limitaciones de CPU, GPU y memoria exigían soluciones muy específicas a los desafíos de renderizado, para exprimir al máximo el hardware de los jugadores. Por ende, Half-Life 2 en realidad tiene tres motores de renderizado distintos: uno para la geometría del mundo, otro para el terreno exterior, y un tercero para las entidades dinámicas como personajes y objetos. Estos tres renderizadores debían soportar una compleja matriz de funciones: colisiones, trazado de rayos, pegatinas, iluminación offline, cálculos de visibilidad, y más. Además, cada renderizador tenía que ser compatible con DirectX 7, 8 y 9. Las diferencias entre estas versiones de DirectX eran significativas, a menudo requerían almacenamiento de datos y enfoques de renderizado diferentes; ¡incluso usaban lenguajes de programación distintos! En conjunto, básicamente teníamos nueve renderizadores diferentes y cada uno necesitaba soluciones únicas. Lograr que todos se vieran consistentes fue uno de los problemas técnicos más desafiantes que enfrentamos durante el desarrollo."
N/A4180"#commentary\cn_268_dynamic_shadows.mp3" "[ Gary McTaggart ] Al enfocarnos en los personajes y objetos físicos, sentimos que era necesario un sistema de sombras dinámicas para renderizarlos en todo su esplendor. En 2003, las GPU no tenían ninguna de las capacidades dedicadas a sombras que tienen hoy, así que el rendimiento era un problema. Nuestra solución funcionaba más o menos así y se ejecutaba en cada fotograma: primero, encontrábamos todos los objetos que podían proyectar sombras en pantalla. Esto implicaba identificar cuáles estaban en el campo de visión o ligeramente detrás, para incluir las entidades fuera de cámara cuya sombra podía aparecer en pantalla. Luego, renderizábamos una versión negra en sombra de cada uno de esos objetos en una única textura de sombras, usando el modelo con el nivel de detalle más bajo, para más rapidez. Finalmente, utilizábamos la textura de sombras para dibujar cada sombra en la vista del jugador, lo que oscurecía los píxeles ya renderizados. Recortábamos cuidadosamente cada sombra dentro de esa textura para que se superpusieran correctamente en donde coincidían. En retrospectiva, es interesante ver cómo hacíamos estas cosas, pero hoy en día estamos mucho más contentos con el hardware de GPU que facilita todo."
N/A4181"#commentary\cn_269_combinatorial_shader_explosion.mp3" "Gary McTaggart ] El renderizado se volvió mucho más complejo durante el desarrollo de Half-Life 2 con la incorporación de los sombreadores por hardware: pequeños fragmentos de código que controlaban cómo debía renderizarse cada píxel de una superficie. En 2003, los sombreadores eran mucho más limitados: los de la época de Half-Life 2 carecían de condicionales y tenían restricciones severas de tamaño de código, por lo que no había lógica de ramificación con sentencia condicional para ajustarse a diferentes condiciones ni sombreadores grandes con conjuntos de funciones amplios. Además, compilar sombreadores según se necesitara era demasiado lento para ser útil, por lo que tuvimos que precompilarlos. Para trabajar dentro de estos límites, tuvimos que calcular todas las combinaciones posibles de sombreadores y almacenar cada una individualmente. Por ejemplo, si un sombreador afectaba una superficie basada en una sola fuente de luz, necesitábamos otra versión para dos luces, otra para tres, y así sucesivamente. Y era combinatorio: si ese sombreador también admitía un mapeo normal, necesitábamos dos versiones por cada luz, una con el mapeo normal y otra sin él. Con funciones como mezcla de texturas, coloración de grafos, resaltado especular, pruebas alfa y varios tipos de luces (direccionales, puntuales, focos), nuestro conteo de sombreadores se disparó. Para el lanzamiento, teníamos miles. Poco después, lanzamos Lost Coast y añadimos soporte para HDR, lo que duplicó nuevamente la cantidad de sombreadores. Cuando la compilación de sombreadores empezó a consumir demasiado en las computadoras, cambiamos a distribuir en toda la red usando VMPi. También teníamos un modo de compilación dinámica que permitía una iteración rápida, aunque con el costo de tirones en la tasa de cuadros cuando había que compilarlos."
N/A4182"#commentary\cn_270_gpu_wild_west.mp3" "[ Jay Stelly ] Durante el desarrollo, nos enfrentamos a numerosas decisiones influenciadas por nuestra elección de especificaciones mínimas: la combinación de CPU y GPU menos potente que aún pudiera ofrecer una buena experiencia a los clientes. A comienzos de los 2000, había mucha más variedad de GPU que hoy, con grandes diferencias no solo en velocidad, sino en los enfoques fundamentales de renderizado. Pero en ese momento no teníamos datos reales sobre el hardware que usaban nuestros clientes. ¿Qué CPU y GPU tenían? ¿Cuánta RAM? ¿Qué versión de Windows? Contactamos a Microsoft, con la esperanza de que pudieran responder preguntas como: \"¿Cuántas tarjetas DX7 hay en uso? ¿O DX8?\". Lamentablemente, ellos tampoco tenían los datos. Al darnos cuenta de que corríamos el riesgo de tomar malas decisiones sin esa información, desarrollamos una herramienta de análisis que permitía a los jugadores enviarnos las especificaciones de su hardware, y la integramos en la versión temprana de Steam. Los datos resultaron tan útiles que decidimos hacerlos públicos y lanzamos la encuesta de hardware de Steam en abril de 2003. Desde entonces, nos ha ayudado a nosotros (y esperamos que también a otros desarrolladores) a tomar decisiones informadas."
N/A4183"#commentary\cn_271_3d_skybox.mp3" "[Jay Stelly ] Siempre hemos necesitado renderizar un mundo que se sintiera más grande de lo que permitían nuestras limitaciones de mapa. En Half-Life 1, usamos una textura de mapeo de cubos para que los jugadores pudieran ver más allá del área jugable. Pero en Half-Life 2 queríamos que esa vista hacia el mundo más amplio fuera dinámica, no solo una textura estática. Nuestra limitación de tamaño de mapa era de aproximadamente media milla en cada dimensión, pero podíamos crear un mundo exterior mucho más grande si lo almacenábamos a escala reducida. Así nació lo que llamamos el Skybox 3D. Se trata de una pequeña caja oculta dentro del mapa real, que contiene geometría a 1/16 de escala. Dentro de ella, un punto de referencia corresponde a un origen coincidente en el mapa principal. Luego, al renderizar el espacio más allá del área jugable, usamos la geometría del Skybox 3D, posicionada por ese punto de referencia y ampliada 16 veces. Se daban desafíos complejos al intentar lograr que la iluminación y la niebla se mezclaran sin interrupciones en la transición del mapa principal al skybox, pero funcionó. El resultado hizo que el mundo se sintiera significativamente más grande e inmersivo que en Half-Life 1."
N/A4184"#commentary\cn_272_missing_material.mp3" "[ Jay Stelly ] Al principio del desarrollo de nuestro código gráfico de bajo nivel, nos dimos cuenta de que sería difícil detectar los polígonos que no se renderizaban debido a la falta de textura. Cuando esto ocurría, normalmente solo se veía negro donde debería estar el polígono, lo que podía pasar fácilmente desapercibido en escenas más oscuras. Para detectar este error de forma más fiable, creamos una textura de error que fuera visualmente inconfundible y se generara automáticamente cada vez que fallara la carga de una textura. Así surgió la ahora icónica textura de tablero de ajedrez morado y negro, que desde entonces ha cobrado vida propia mucho más allá de Half-Life 2."
N/A4185"#commentary\cn_273_air_resistance.mp3" "[ Jay Stelly ] Una característica importante que tuvimos que añadir a nuestro motor físico para Half-Life 2 fue la resistencia del aire. En aquel momento, los motores físicos solían implementar una función de amortiguación general para ralentizar los objetos a medida que se movían. Pero esto solo elimina la energía de forma simétrica. Para crear un movimiento más creíble, decidimos simular la resistencia del aire. Esto nos permitió obtener un comportamiento asimétrico, en el que la cantidad de desaceleración del objeto al moverse a través del aire variaba en función de la superficie del objeto que se enfrentaba a la dirección del movimiento o la rotación. Esta característica fue clave para que las explosiones y los objetos lanzados por la pistola de gravedad parecieran creíbles. Los objetos que se mueven y giran rápidamente se encuentran entre los más costosos de simular en el motor físico de Half-Life 2, por lo que la resistencia del aire también mejora el rendimiento de la CPU en casos como las explosiones. También es clave para presentar diferentes materiales y masas de objetos. Los objetos más densos pueden apartar el aire más fácilmente, y esto es visible. Tener este efecto en la simulación ayuda a que la diferencia de densidad entre las cajas de cartón y las tablas de madera sea más evidente y realmente ayuda a que los objetos del mundo de Half-Life 2 sean mucho más convincentes."
N/A4186"#commentary\cn_274_early_tech_planning.mp3" "[ Ken Birdwell ] Lanzar un juego siempre nos enseña mucho: al fin podemos descubrir qué decisiones tomamos bien y cuáles deberíamos tomar de otra manera la próxima vez. Así que, después de Half-Life 1, cuando nos sentamos a pensar en qué tipo de secuela podríamos crear, teníamos todo tipo de comentarios de los jugadores que analizar. A partir de ahí, intentamos crear una lista maestra de cosas en las que Half-Life 2 se iba a centrar. No intentamos diseñar una experiencia específica para el jugador, sino que nos pareció más útil abordar la cuestión desde un punto de vista tecnológico. Los guardias de seguridad y los científicos de Black Mesa habían funcionado bien. ¿Qué podríamos hacer si nos esforzábamos al máximo con los personajes? Nos gustaba nuestra narrativa interactiva. ¿Qué podríamos crear que nos permitiera hacer aún más y con mayor variedad? La exploración y la interacción dentro de Black Mesa resultaban atractivas para los jugadores. ¿Quizás un sistema físico nos permitiría llevarlo más allá? En todas estas áreas, intentamos imaginar cómo sería la mejor versión posible, años en el futuro, y a partir de ahí, resolvimos hacia atrás una serie de pasos tecnológicos que podrían llevarnos hasta ahí."
N/A4187"#commentary\cn_275_character_lighting.mp3" "[ Ken Birdwell ] Durante el primer año de desarrollo, nos costó mucho conseguir que nuestros personajes tuvieran el aspecto realista que queríamos. Había diferentes problemas que requirieron mejoras tecnológicas y artísticas específicas. El primer problema importante fue la iluminación. En aquel momento, la tecnología de iluminación en los videojuegos tomaba muchos atajos, algunos debido al rendimiento, pero muchos otros a malentendidos sobre cómo funcionaba todo. Para que los personajes tuvieran un buen aspecto, los modelos y las texturas tenían que crearse con gran parte de su solución de iluminación integrada, como las sombras y el brillo. Se veían bien, pero muy de videojuego. Empezamos a crear a Alyx con este enfoque, porque así era como se hacía. Utilizamos las soluciones integradas y la iluminamos como a una actriz de cine, es decir, como si tuviera un equipo de iluminación personalizado que la seguía a todos lados para que siempre se viera bien. Pero en realidad no funcionó. La variedad de entornos de iluminación y la naturaleza dinámica de los videojuegos hacían que se viera muy bien en algunos entornos y nada realista en otros. Intentamos iterar su equipo de iluminación, aumentando sus capacidades, pero al final nos dimos cuenta de que estábamos en un callejón sin salida. Volvimos a la mesa de dibujo y decidimos probar un enfoque diferente. La rehicimos a ella, la iluminación y las texturas desde cero, desechando todo lo anterior. Nos centramos no en cómo queríamos que se viera bajo una iluminación ideal, sino en cómo se suponía que debían funcionar las cosas en el mundo real. Puede parecer obvio, pero no era así como se hacía, al menos no en los videojuegos. Fuera del renderizador del juego, estos modelos y texturas se veían peor que las versiones anteriores. Sin embargo, logramos eliminar metódicamente todos los atajos y conceptos erróneos sobre cómo funcionaban la luz, las texturas y las tarjetas gráficas, y lo volvimos a montar todo. Cuando al fin pudimos ver a Alyx en el juego, con sus nuevos modelos y texturas, en un entorno dinámico que la mantenía visualmente coherente en todo momento, bueno, se veía genial. Totalmente integrada y parte del mundo de Half-Life 2."
N/A4188"#commentary\cn_276_gamma_correction.mp3" "[ John Morello ] Nuestro motor de juego tiene un sistema de renderización que se encarga de tomar todo el estado del juego y calcular un valor de color para cada píxel de la pantalla que represente ese estado. Pero en el proceso de cálculo de esos píxeles también intervienen códigos y software de otras personas. Por ejemplo, el software y el hardware de la GPU y el monitor. En un momento dado durante el desarrollo, no estábamos contentos con el aspecto de nuestros personajes. En concreto, pensábamos que tenían un aspecto ceroso o enfermizo. Su piel no era la adecuada. Dedicamos algún tiempo a ajustar la iluminación, pero no conseguíamos que tanto los personajes como el mundo tuvieran el aspecto adecuado. Por suerte, todavía teníamos un renderizador de software con todas las funciones, lo que nos permitía ejecutar el juego sin una GPU, ya que era una época en la que muchos jugadores aún no tenían una. Al ver el juego en ese renderizador, nos dimos cuenta de que nuestra iluminación no tenía el mismo problema. Así que revisamos nuestro código con lupa, tratando de averiguar dónde estaba fallando nuestro código de renderización cuando trabajaba con una GPU. Al no conseguirlo, intentamos hablar con los fabricantes de GPU y les pedimos que comprobaran que no estaban haciendo nada mal con los valores de píxeles que les pasábamos. Ese fue el comienzo de un largo viaje y, en resumen, fue un viaje de casi dos años de comunicaciones con los fabricantes de GPU antes de que pudiéramos convencerlos de que estaban haciendo la corrección gamma de forma incorrecta en las matemáticas de bajo nivel de sus tarjetas. Durante este proceso, incluso tuvimos que crear un sistema que validara los valores de color de cada píxel a lo largo de todo nuestro proceso de renderización. Pero, al final, conseguimos que nos proporcionaran nuevos controladores y nuestros personajes volvieron a tener el aspecto que debían tener, igual que en el renderizador de software."
N/A4189"#commentary\cn_277_facial_technology.mp3" "[ Ken Birdwell ] Queríamos que los jugadores se encariñaran con nuestros personajes, y para que fuera posible, sabíamos que teníamos que invertir mucho en tecnología para sus rostros. Está demostrado que los humanos estamos programados para responder a los rostros, interpretando todo tipo de información que vemos de forma inconsciente en ellos. La vara estaba muy alta, y si no estábamos a la altura, probablemente alejaríamos a los jugadores de nuestros personajes, en lugar de acercarlos. Empezamos haciendo mucha investigación y los resultados no fueron alentadores. Los mejores ejemplos que pudimos encontrar no se acercaban ni remotamente a poder ejecutarse en tiempo real, mientras que los mejores en tiempo real no se acercaban a la calidad que queríamos. Queríamos que las caras fueran tan expresivas como las de una película animada, pero ahí tardaban horas en renderizar los fotogramas, eran totalmente lineales y contaban con un ejército de animadores; nosotros teníamos un equipo reducido y necesitábamos que las caras fueran dinámicas, porque un personaje debía reproducir un diálogo dependiendo de las acciones del jugador. Estos requisitos nos llevaron finalmente al Sistema de Codificación de Acciones Faciales del Dr. Paul Ekman, un sistema de los años 70 para clasificar los movimientos faciales humanos. Nos proporcionó un vocabulario para describir los movimientos faciales en todas nuestras herramientas y código, más un objetivo al que aspirar al diseñar los rostros de nuestros personajes. Con ese marco de referencia, iniciamos un proceso de varios años de iteración para construir los rostros y cabezas de nuestros personajes. Otros habían tomado partes del trabajo de Ekman, pero nosotros queríamos utilizarlo todo, lo cual implicó mucho tiempo para averiguar cómo hacer cada pieza dentro de las estrictas limitaciones de rendimiento. Pero también dedicamos mucho tiempo a observar a las personas y sus rostros, tratando de encontrar los rasgos que aportarían más valor, como la elasticidad de la piel o las sombras de los dientes. Al final, aunque no pudimos hacer todo lo que queríamos, logramos un nivel de expresión facial convincente."
N/A4190"#commentary\cn_278_eye_shader.mp3" "[ Ken Birdwell ] Otra parte fundamental para que los rostros resultaran convincentes eran los ojos. Los seres humanos somos muy buenos interpretando la mirada. Hay una parte del cerebro dedicada a ello, que llega incluso a saber dónde mira alguien basándose en los reflejos de los globos oculares, pero hay todo tipo de matices importantes. Los ojos no son realmente esferas, los párpados se distorsionan por el movimiento de la córnea, el movimiento de los ojos puede aumentar las probabilidades de parpadear, los ojos no están alineados directamente detrás de la pupila, sino que están ligeramente desplazados. Todos estos detalles pueden parecer insignificantes o imperceptibles, pero su ausencia perjudica la credibilidad del personaje. Trabajamos en los ojos durante mucho tiempo, iterando poco a poco nuestro modelo de globo ocular y nuestro conjunto de características. Algunas cosas requerían interfaces externas, como qué elementos del entorno eran interesantes de mirar, mientras que otras eran automáticas, a nivel subconsciente en la IA, como el parpadeo, un requisito obvio, pero que resulta confuso si no se hace bien. Los reflejos de los ojos tuvieron un impacto especialmente grande: en última instancia, ocupan una pequeña parte de la pantalla, pero la diferencia que marcaron fue enorme. Supimos que por fin habíamos terminado cuando llegamos al punto en el que, con nuestro sombreador ocular desactivado, un personaje parecía una muñeca, similar a un humano, pero poco convincente, y cuando lo activamos, de repente, sentimos como si un humano nos estuviera mirando."
N/A4191"#commentary\cn_279_combine_gunship.mp3" "[ Ken Birdwell ] La nave planteaba un problema interesante. Ya teníamos un modelo de vuelo para helicópteros y no teníamos tiempo para crear uno completamente nuevo. Así que ajustamos el modelo de vuelo del helicóptero hasta que nos pareció lo suficientemente diferente y, a partir de los valores obtenidos en esa simulación, derivamos el estado de animación orgánica de la nave. También intentamos que fuera lo más realista posible. Por ejemplo, hay un límite en cuanto al ángulo que puede girar la cabeza para apuntar con su cañón, y si necesita apuntar más allá, tiene que alterar su trayectoria de vuelo para poder apuntar con el cañón; no se le permite hacer trampa. La otra característica clave era el sonido de su motor. Contamos con espacialización del sonido, por lo que el jugador puede saber aproximadamente dónde se encuentra. Sin embargo, la nave es un objeto que se mueve rápidamente y está en el aire, lejos de cualquier punto de referencia cercano. Como resultado, puede ser difícil saber exactamente a qué distancia se encuentra y a qué velocidad se mueve. Para solucionarlo, añadimos un efecto Doppler al sonido del motor, cambiando el tono en función de la velocidad del helicóptero en relación con el jugador. Es un efecto sutil, pero extremadamente eficaz para ayudarte a percibir inconscientemente la ubicación y la dirección de la nave. Información crítica que te permite saber que te está persiguiendo."
N/A4192"#commentary\cn_280_risk.mp3" "[ Ken Birdwell ] Al recordar Half-Life 2 ahora, 20 años después, tenemos que reflexionar sobre lo aterrador que fue durante gran parte del desarrollo. El desarrollo de videojuegos es difícil. Nunca consigues realmente lo que te gustaría, que es poder validar el riesgo antes de empezar a acumular más. Por ejemplo, nuestra tecnología de animación facial. Nos llevó probablemente entre tres y cuatro años de trabajo antes de estar seguros de que realmente iba a funcionar. Pero no podíamos esperar hasta entonces. En ese primer año, empezamos inmediatamente a tomar todo tipo de decisiones sobre el diseño del juego, la producción de activos y otras tecnologías, basándonos en la suposición de que nuestra tecnología de animación facial iba a funcionar al final, desde el punto de vista de la calidad y el rendimiento. Si no hubiera sido así, muchas de esas otras decisiones tampoco habrían funcionado. Y el mismo perfil de riesgo se aplica a otras decisiones importantes que tomamos al principio. No podemos esperar, solo tenemos que construir y confiar en que nuestras suposiciones sean ciertas dentro de unos años. Da miedo."
N/A4193"#commentary\cn_281_hugs_and_pickups.mp3" "[ Ken Birdwell ] A veces, incluso las cosas más pequeñas pueden convertirse en una pesadilla cuando las haces funcionar. Por ejemplo, hacer que un personaje abrace a otro, o incluso algo tan sencillo como recoger un objeto de una mesa, puede causar muchos problemas. Y lo que es peor, en nuestro entorno dinámico, donde los personajes y los objetos no se encuentran en posiciones preestablecidas y el jugador corre de un lado a otro entorpeciendo el proceso, se requiere un nivel de sincronización que puede resultar bastante complicado. Se complican aún más porque los humanos los manejamos sin pensar. Cuando te acercas a la mesa para recoger una taza, estás haciendo todo tipo de preparativos con tu cuerpo para colocar los pies y las manos en la posición adecuada que te permita hacerlo cómodamente. Todo está listo justo cuando llegas allí. Si te acercas para abrazar a alguien, ambos lo hacen al mismo tiempo, ajustándose constantemente en función de los movimientos del otro. Para que estas características funcionaran en el juego, fue necesario realizar un gran trabajo de sincronización, haciendo que los personajes fueran conscientes unos de otros y del mundo. Y, al mismo tiempo, haciendo que supieran más sobre sus planes futuros. Es tentador querer dividir el ejemplo de tomar una taza en pasos discretos (caminar hacia la mesa, mirar la taza, tomar la taza), porque así es mucho más sencillo y los pasos se pueden reutilizar fácilmente. Pero así es como funcionan los robots, no los humanos. Nuestros personajes tenían que saber que se dirigían a una mesa con la intención de levantar una taza, para poder trabajar en varias partes simultáneamente y asegurarse de que su mano agarrara la taza justo cuando llegaban allí. Con dos personajes, la negociación es aún mayor. Ambos deben ponerse de acuerdo sobre dónde y cuándo va a suceder y todo debe ocurrir en su lugar de forma fluida. Aunque estos momentos de simple interacción entre nuestros personajes en el mundo suelen ser breves, eran fundamentales para que parecieran personas creíbles."
N/A4194"#commentary\cn_282_ropes.mp3" "[ Mike Dussault ] Una de las cosas que observamos en todas las imágenes de referencia que recopilamos para City 17 fue que había cables y alambres por todas partes, y que constituían una gran parte de los detalles de alta frecuencia que se veían. Nos encantaba el aspecto de estas antiguas ciudades europeas enredadas en la caótica red de la vida moderna. Sentimos que necesitábamos una solución para los cables, cuerdas y elementos similares, y queríamos que fueran dinámicos. Nuestros diseñadores de niveles estaban ansiosos por crear rompecabezas de enchufes, y conectar un cable a cada enchufe ayudaba a los jugadores a comprender mejor la mecánica. Al principio de la producción, creamos un sistema de cuerdas y lo fuimos perfeccionando a lo largo del desarrollo. En realidad, cada cuerda está formada por varios segmentos tensados entre dos extremos y que pueden moverse de forma independiente. Cada segmento actúa como un resorte y responde a las fuerzas del juego, como una brisa suave o el paso de una nave de la Alianza por encima. Al renderizarse, cada segmento se muestra frente a la cámara y se le aplica un mapa de relieve, lo cual es fundamental para dar a las cuerdas un aspecto realista y redondeado."
N/A4195"#commentary\cn_283_vmpi.mp3" "[ Mike Dussault ] Durante el desarrollo, nos sentíamos cada vez más frustrados por la lentitud de la iteración del juego, principalmente porque la compilación de mapas, necesaria para precalcular la iluminación y la visibilidad, llevaba horas. Las computadoras en el año 2000 eran mucho más lentas que las actuales y solo tenían un núcleo de CPU cada una. Inspirados por SETI@Home, un programa distribuido que utilizaba computadoras personales de todo el mundo para analizar ondas de radio en busca de señales de vida extraterrestre, creamos VMPi, nuestro propio sistema distribuido que repartía el proceso de compilación de mapas entre muchas computadoras de la oficina. Hoy en día, este tipo de sistemas distribuidos se ejecutan en gigantescos clústeres de GPU, pero en aquel momento solo lo ejecutábamos en todas las computadoras de nuestra oficina. Para hacer frente a la rápida evolución de nuestro código de iluminación, al igual que nuestros mapas, VMPi también distribuía nuevos archivos .exe a las computadoras de todos. En retrospectiva, era un concepto de seguridad bastante aterrador, terriblemente malo, como una pesadilla para los informáticos. Porque simplemente enviábamos un ejecutable arbitrario a todas nuestras computadoras de trabajo y estas lo ejecutaban sin más. Era una locura absoluta. Pero nos funcionó y aumentó significativamente nuestra velocidad de iteración de mapas, por lo que acabó siendo una herramienta crucial."
N/A4196"#commentary\cn_284_field_of_view.mp3" "[ Kerry Davis ] En Half-Life 1, utilizamos un campo de visión de 90 grados, que era bastante habitual en los juegos de disparos en primera persona de la época. Pero durante el desarrollo de Half-Life 2, ya no nos sentíamos conformes con él. Como nuestro juego se centraba en los personajes, dedicamos mucho esfuerzo a crear animaciones faciales y corporales detalladas, pero el campo de visión de 90 grados no permitía a los jugadores acercarse lo suficiente como para apreciar plenamente esos detalles. Así que empezamos a experimentar con un CDV más reducido y finalmente nos decidimos por 75 grados. Nos llevó algún tiempo adaptarnos, tanto a nosotros como a los jugadores, y requirió un campo de visión adicional para los modelos de visión, que son las armas de los jugadores, situadas en la parte inferior de la pantalla. Sus modelos se crearon originalmente pensando en 90 grados, por lo que se veían distorsionados a 75. Pero este cambio logró lo que queríamos: poner a nuestros personajes en primer plano en el juego."
N/A4197"#commentary\cn_285_reference_maps.mp3" "[ Randy Lundeen ] A medida que nuestros personajes se volvían más realistas entre Half-Life 1 y Half-Life 2, queríamos que el mundo del juego fuera igualmente realista. En Half-Life 1, las limitaciones de los juegos en primera persona a menudo facilitaban el uso de entornos estilizados o abstractos. Pero con Half-Life 2, nos propusimos crear un escenario que se sintiera basado en la realidad, lo que significaba centrarnos en muchos pequeños detalles en los que no habíamos pensado antes. Uno de nuestros principales pasos fue crear mapas de referencia para estandarizar la forma en que plasmaríamos las proporciones del mundo real en el juego. Estos mapas establecían detalles como las dimensiones de las paredes y las puertas, la altura de los pomos, la iluminación interior, la escala de los muebles y la escala general de los objetos comunes. Creamos texturas estandarizadas para los diseñadores de niveles, con valores de escala e iluminación, para que los diseños fueran coherentes desde el principio. Además de configurar el mundo físico, estos mapas de referencia definían cómo se movería el jugador por él: la altura a la que podía saltar, la profundidad a la que podía agacharse y el tamaño de espacios como los conductos de ventilación. Utilizando estos mapas como base, pudimos mantener la coherencia de la geometría de nuestro mundo y garantizar que los espacios del juego tuvieran un tamaño realista."
N/A4198"#commentary\cn_286_response_rules.mp3" "[ Scott Dalton ] Desde el principio sabíamos que queríamos incluir muchos diálogos dinámicos en el juego, por lo que necesitábamos un sistema que los gestionara de forma eficaz. Nuestro objetivo era crear un sistema que permitiera a los diseñadores de sonido añadir y modificar líneas sin necesidad de involucrar a los programadores, que hiciera que los diálogos respondieran con precisión al estado del juego y que minimizara las repeticiones. Con estos requisitos, creamos el sistema Response Rules. Cada vez que un personaje habla fuera de una escena coreografiada, este sistema determina qué línea debe pronunciar. En vez de seleccionar las líneas directamente, la IA del personaje marca constantemente las oportunidades para hablar cada vez que ocurre un evento relevante: ver al jugador, resultar herido, disparar la última bala de un arma, encontrarse con enemigos abrumadores, etc. Con cada oportunidad, envía al sistema de reglas de respuesta un paquete de datos sobre el estado actual del juego, y el sistema devuelve la línea de diálogo más adecuada, si la hay. Esta configuración permitió a nuestros diseñadores de sonido crear una matriz de decisiones detallada para los diálogos. Por ejemplo, un personaje puede tener un conjunto de frases diferente para anunciar una recarga mientras está bajo fuego, en comparación con después del final de una pelea, o si solo queda un aliado en pie, o si hay un Strider a la vista. Cuando lanzamos Half-Life 2, sentimos que solo habíamos arañado la superficie del potencial de este sistema. Se convirtió en una característica fundamental de Alyx, del Episodio 1, y pasó a impulsar el diálogo dinámico en nuestros juegos posteriores, incluidas las clases de TF2 y el reparto de Left 4 Dead."
N/A4199"#commentary\cn_287_audio_caching.mp3" "[ Yahn Bernier ] Otro problema con el que nos topamos fue la gran cantidad de audio que había en el juego. Entre todos los sonidos del juego, la música y los diálogos, teníamos demasiado audio como para poder almacenarlo todo en la memoria, que en 2003 era muy limitada. Pero, como se pueden imaginar, necesitábamos poder reproducir los sonidos de inmediato, sobre todo si estaban relacionados con el juego. Así que creamos un caché de audio, que almacenaba solo los primeros 125 ms de cada archivo de audio y los guardaba en la memoria. Esos 125 ms eran nuestra mejor estimación del tiempo que tardaríamos en reproducir un archivo de audio desde el disco. Luego, cada vez que se reproducía un sonido en el juego, reproducíamos el inicio desde nuestra caché de audio y, al mismo tiempo, iniciábamos la carga del archivo de audio completo desde el disco. Para cuando terminaba la parte almacenada en caché, ya teníamos el archivo cargado y podíamos seguir reproduciendo el resto del sonido. Había otras características menores, como mantener los sonidos recientes completamente en la memoria para que los de mayor tráfico no tuvieran que cargarse constantemente. En los motores actuales, todo tipo de recursos, más allá de los sonidos, suelen utilizar el mismo tipo de estrategia."
N/A4200 
39184201}
39194202}