Template:PatchDiff/March 6, 2026 Patch/hl2/resource/closecaption ukrainian.txt
39153915"wood.scraperough" " "
39163916"plastic_box.scraperough" " "
39173917
N/A3918"#commentary\cn_001_physics_sound.mp3" "[ Джей Стеллі ] Щоб фізика сприймалася гравцем природно, звуки, які вона породжує, теж мали звучати достовірно. Ми, люди, звикли до того, як об’єкти й матеріали звучать під час різних взаємодій — навіть якщо не усвідомлюємо цього. Ми розуміли, що врахувати абсолютно все неможливо, тож вирішили зосередитися на деталях, які найбільше впливають на відчуття реалістичності фізики. Ми почали зі звуків зіткнень і ударів для кожного об’єкта. Так, наприклад, дерев’яний ящик отримав власні звуки під час зіткнення з іншими предметами чи класами об’єктів. Потім ми почали динамічно змінювати ці звуки відповідно до характеристик фізичної події — наприклад, залежно від мас об’єктів і сили удару. Це чудово працювало для зіткнень, але виявилось малоефективним для інших взаємодій — наприклад, коли предмети труться один об одного. У реальності дерев’яний ящик звучить інакше, коли дряпає стіну, ніж коли його кидають об цю саму стіну. Повірте, ніхто не досліджував нюанси фізичних властивостей дерев’яного ящика так прискіпливо, як ми. Щоб досягти потрібного результату, ми реалізували звуки зіткнень для кожного матеріалу: метал об дерево, метал об метал тощо. Ці звуки також динамічно змінювалися залежно від деталей — наприклад, твердості матеріалу чи типу металу. Щоб домогтися правильного звучання в цій системі, знадобилося безліч дрібних доробок, які ми могли визначити тільки після її запуску. Ми навіть експериментували зі спеціальними звуками для предметів, що котяться, але зрештою відмовилися від цієї ідеї, бо результат нас не задовольнив."
N/A3919"#commentary\cn_002_ramming_with_the_buggy.mp3" "[ Джей Стеллі ] Наша система фізики ґрунтується на твердих тілах, тобто не підтримує деформацію чи руйнування об’єктів. Якщо фізичний об’єкт отримує удар, він може рухатися, якщо це дозволено, а інакше — нічого не відбувається. Тому, коли ви врізаєтесь на баггі у скляне вікно, нам доводиться застосовувати певні хитрощі, щоб усе працювало так, як очікується. Оскільки вікно зафіксоване, симуляція фізики фактично відштовхує баггі від скла, але при цьому повідомляє ігрову систему про зіткнення. Ігрова система обробляє руйнування: вона розбиває вікно на уламки скла й наказує системі фізики почати їхню симуляцію. Важливий нюанс: ігрова система також наказує фізиці відновити стан баггі до того, яким він був до удару. Це гарантує, що під час наступної симуляції фізики баггі безперешкодно проїде крізь тепер уже розбите вікно. Цей процес призводить до однокадрової затримки у фізиці баггі: він на мить зупиняється й телепортується назад у момент перед зіткненням. Нам шкода, якщо після цього Half-Life 2 для вас більше не буде такою як раніше. Але, переглянувши записи ігрових тестів, ми зрозуміли, що нам навіть подобається ця коротка затримка — вона підсилює відчуття удару."
N/A3920"#commentary\cn_003_ramming_zombies_with_the_buggy.mp3" "[ Джей Стеллі ] Ми, люди, маємо певні очікування щодо фізичного світу навколо нас — про це вже не раз згадувалося в цих коментарях. Одне з таких очікувань просте: якщо збити зомбі машиною, він має злетіти в повітря. Але домогтися такого ефекту в грі не так просто, як у реальному світі. З міркувань продуктивності для ворогів на кшталт зомбі під час гри використовується спрощена коробка зіткнень — невидимий бокс, що щільно облягає модель без виступаючих частин. Коли ж зомбі гине, він перетворюється на ragdoll-модель із точними коробками зіткнень для кожної кінцівки, хоча це й суттєво дорожче для симуляції. Ця зміна моделі зіткнень ще більше ускладнює ситуацію під час тарану зомбі на баггі — на додачу до короткої однокадрової затримки фізики. Спершу баггі стикається зі спрощеною коробкою зіткнень зомбі. Потім гра «вбиває» його й перетворює на ragdoll, який починає симулювати система фізики. Але тепер, через точніше відображення кінцівок, найближча частина зомбі може опинитися на кілька сантиметрів далі від баггі. Внаслідок цього під час наступної симуляції фізики зомбі починає падати під дією гравітації, бо баггі вже його не штовхає. Хоча минає лише мить, перш ніж баггі знову наздоганяє зомбі, ця маленька неточність робила таран незадовільним — нерідко зомбі випадали з поля зору гравця. Щоб виправити це, ми зберігали силу, яку отримувала коробка зіткнень зомбі від удару баггі, й застосовували її до ragdoll-моделі після перетворення. Крім того, ми додали невеликий вертикальний імпульс, щоб злегка підкинути модель. Завдяки цим змінам зомбі надійно перекидалися через капот баггі після удару, що краще відповідало очікуванням гравців."
N/A3921"#commentary\cn_004_buggy_sound_engine.mp3" "[ Келлі Бейлі ] Створити звуки для баггі було непростим завданням: ми хотіли, аби він відчувався як справді потужний транспорт, що мчить на шаленій швидкості. Насправді ж карти замалі для цього, а баггі фактично рухається лише на першій передачі. Його максимальна швидкість — близько 35 миль на годину. У наш захист скажу: 35 миль на годину — це все ще досить швидко, особливо у 2004-му. До того ж керування дуже просте. Якщо цільовий пристрій введення — клавіатура, то команди гравця фактично бінарні: баггі або прискорюється, або ні, повністю повертає в один бік — або взагалі не повертає. Тож нам потрібно було створити всю цю звукову складність, щоб передати симуляцію, якої насправді не існувало. Ми побудували фальшивий двигун для звуків баггі. У нього є власна трансмісія і ми комбінуємо дії гравця з даними фізичної симуляції. Ми вимірюємо крутний момент на кожному віртуальному колесі, чи воно прокручується, чи торкається поверхні, створюємо набір циклічних звуків і ретельно змішуємо їх, коли фальшивий двигун перемикає передачі та реагує на дані з коліс. Ми просто експериментували: додавали складності, налаштовували дрібниці — аж поки їзда на баггі не стала відчуватися більш драйвовою та ніби винагороджувала гравця цим відчуттям швидкості. Більшість гравців цього не помічають, окрім того, що «баггі звучить круто» — і для нас це найкращий показник успіху, зважаючи на все божевілля, що відбувалося «під капотом»."
N/A3922"#commentary\cn_005_buggy_sound_design.mp3" "[ Келлі Бейлі ] Звуковий дизайн баггі базувався на семплах старенького Camaro 1968 року. Ми обрали саме цей автомобіль через його неймовірні V- подібні восьмициліндрові двигуни з величезними поршнями. Іншого подібного звучання просто немає — цей звук сирий, пробираючий до кісток, саме те, що ми шукали. Трансмісія також має чудове механічне скиглення, коли машина перестає розганятися. У поєднанні це створювало відчуття миттєвої реакції у нашій фактично бінарній системі керування, з якою доводилося працювати. Тож трансмісія фальшивого двигуна не копіювала жодну реальну модель. Її розробили як просту систему, яка винагороджує гравця за утримання газу. Вона працює, немов зациклений ескалатор: створює наростаючий тон, постійно нагнітає напругу й перемикає передачі щоразу, коли звук треба перезапустити. Оскільки наші карти були відносно невеликі й простір швидко закінчувався, ми прагнули зробити процес розгону максимально захопливим — хай навіть лише на короткий час."
N/A3923"#commentary\cn_006_automating_dsp.mp3" "[ Келлі Бейлі ] Усі звуки, які чує гравець, проходять крізь нашу систему цифрової обробки сигналів (Digital Signal Processing, DSP). Це означає, що аудіо змінюється залежно від середовища, у якому перебуває гравець. Наприклад, той самий звук у паркінгу, маленькій кімнаті чи просто неба звучатиме по-різному. У Half-Life 1 ми вручну розставляли по всьому світу невидимі вузли, щоб визначати налаштування DSP для кожної зони. Для Half-Life 2 ми розуміли: такий підхід забере надто багато часу — особливо з огляду на більший масштаб гри й те, що в команді, як і раніше, був лише один фахівець із аудіо. Тому ми розробили систему, яка автоматично визначає налаштування DSP навколо гравця в режимі реального часу. Вона аналізує простір, оцінює об’єм, у якому перебуває гравець, і фактично перевіряє матеріали, з яких складене оточення. Потім система співвідносить цю зону з одним із 25 базових типів DSP, створених вручну, а ми коригуємо деякі параметри й створюємо повністю деталізовану DSP, яка змінює звуки, що чує гравець."
N/A3924"#commentary\cn_007_dynamic_mixing.mp3" "[ Келлі Бейлі ] Під час гри одночасно відтворюється безліч звуків, але деякі з них природно важливіші за інші. Тому нам потрібно налаштовувати їхню гучність відносно одне одного, щоб ключові ефекти виразно виділялися. У кіно подібне мікшування роблять на етапі постобробки. У грі ж, що реагує на дії гравця, усе відбувається в реальному часі, і ми не можемо заздалегідь передбачити, які саме звуки накладатимуться. Щоб вирішити цю проблему, всі звуки групуються за типами та отримують теги пріоритетності. Під час гри аудіосистема відстежує всі активні ефекти й знижує гучність у групі, якщо з’являється звук із вищим пріоритетом. Це мікшування можна регулювати. Якщо постріли мають бути особливо гучними в певній сцені, ми підвищуємо їхній пріоритет. Якщо важлива репліка діалогу повинна прозвучати чітко, усі інші звуки автоматично приглушуються. Те саме стосується й музики. Ця система непомітна, але критично важлива — вона не дає звуковій палітрі перетворитися на хаос."
N/A3925"#commentary\cn_008_soundscapes.mp3" "[ Келлі Бейлі ] У Half-Life 1 звуки оточення розміщувалися вручну й потім налаштовувалися окремо. У Half-Life 2 ми хотіли зробити їх більше, підвищити якість і зменшити потребу в ручній роботі. Тож ми створили систему, яку назвали системою звукових ландшафтів. Звуковий ландшафт — це, по суті, невелика програма, яка визначає, які саме звуки оточення відтворюються, звідки вони лунають і як поводяться в певному середовищі. Це можуть бути дзижчання мух, подув вітру, спів птахів, далекий потяг чи віддалений бій. Система могла випадково вибирати й відтворювати ці звуки, а найважливіше — забезпечувати плавні переходи, коли гравець переміщується між локаціями. Звукові ландшафти також можуть містити інші ландшафти, що дозволяє створювати багаторазові набори звуків. Наприклад, віддалений бій може складатися з пострілів легкої стрілецької зброї, вибухів у далині та прольоту гелікоптера. Такі ландшафти динамічно збираються й відтворюються з багатьох окремих звуків, що допомагає уникнути враження штучності від одного зацикленого треку. Загалом система звукових ландшафтів стала справжньою робочою конячкою для аудіо в Half-Life 2 та фактично відповідала за всі звуки, не пов’язані безпосередньо з ігровим процесом."
N/A3926"#commentary\cn_009_audio_over_distance.mp3" "[ Келлі Бейлі ] Великі відкриті простори на картах узбережжя змусили нас шукати рішення для моделювання зміни звуку на відстані. Наприклад, на цих картах ворог може бути більш ніж за сто метрів, і його постріли здалеку мають звучати інакше ніж зблизька. Ми вирішили зберігати звуки в одному стереофайлі: близький звук — у лівому каналі, далекий — у правому. Потім, під час відтворення, ми робили кросфейд — змінювали співвідношення між цими двома каналами залежно від відстані гравця до джерела звуку. Це було просте, але ефективне рішення, яке ще й допомогло нам заощадити пам’ять. Ви легко можете почути його в дії — просто зверніть увагу, як змінюються постріли солдата Комбінації, коли ви під’їжджаєте ближче."
N/A3927"#commentary\cn_010_flying_vehicle_audio.mp3" "[ Келлі Бейлі ] Великі літаючі вороги у грі стали унікальним викликом для звукового дизайну. Під час боїв вони значно мобільніші за інших противників і часто віддаляються від гравця на велику дистанцію. До того ж вони надзвичайно небезпечні, якщо мають пряму лінію видимості. Ці фактори змусили нас зосередитися на звуковому рішенні, пов’язаному саме з оклюзією — тобто тим, коли ви бачите ворога і коли він бачить вас. Ми прагнули зробити чітку аудіорізницю між ситуаціями, коли противник має цю лінію видимості. Звук двигунів літаючих апаратів складається з кількох циклічних треків, які ми відтворюємо одночасно. Деякі з цих циклів обробляються системою DSP залежно від місця, де ви перебуваєте, а інші звучать безпосередньо, без обробки. DSP додає більше відлуння навколишнього середовища, коли звук проходить через систему. Якщо літаючий об’єкт закритий перешкодою й не може вас бачити, ми збільшуємо відсоток циклів, що проходять через DSP, щоб він звучав більш віддалено. Коли ж ворог з’являється з-за перешкоди й бачить вас, ми підсилюємо частку прямого, необробленого звуку. Завдяки цьому створюється відчуття, що звук або далекий і розсіяний, або чітко спрямований на вас. Це добре чути, коли, наприклад, гелікоптер вилітає з-за будівлі — у такі моменти ви виразно відчуваєте різницю."
N/A3928"#commentary\cn_011_bullet_audio.mp3" "[ Келлі Бейлі ] Якщо ми в чомусь і впевнені, то в тому, що протягом гри повз гравця пролетить безліч куль. Тому ми витратили чимало часу, намагаючись удосконалити їхнє звучання. На жаль, у грі кулі по суті миттєві, тож ми не можемо просто прикріпити до них звук і покладатися на рух для позиціонування. Після кількох експериментів ми зупинилися на такому рішенні: визначивши найближчу до вуха гравця точку траєкторії кулі, ми розраховуємо точний час і місце, де вона теоретично пролетить повз. Потім у цій точці відтворюємо два різні звуки, щоб створити ефект Доплера: один — для наближення кулі, другий — для віддалення. Звук віддалення затримується на основі розрахованого часу прольоту кулі."
N/A3929"#commentary\cn_012_staircase.mp3" "[ Аарон Сілер ] Упродовж гри трапляються ситуації, які виникли з простих і цілком очевидних дизайнерських цілей, і ці сходи втілюють одразу дві. Перша — вигідно подати в кадрі Цитадель у момент її пробудження, показавши гравцеві, що він розворушив вулик. Друга — продемонструвати нашу систему ragdoll. Зараз це вже стандарт, але у 2004-му реалістичне падіння тіл було новинкою, а сходи стали для цього ідеальною сценою."
N/A3930"#commentary\cn_013_alyx_and_mossman.mp3" "[ Білл Флетчер ] У наших ранніх планах щодо оповіді Half-Life 2 ми хотіли зробити щось менш очевидно ігрове. Не просто історію про очевидно доброго героя, який перемагає беззаперечно злих ворогів. Натомість ми прагнули зосередитися на персонажах та їхніх відносинах. Нам здавалося цікавим дослідити тему сім’ї як центральну рушійну силу Half-Life 2. Саме з цієї ідеї виникла напруга між Алікс і Моссман, і нам вона сподобалася, бо була зрозумілою та близькою — гравці могли легко це відчути й співпереживати."
N/A3931"#commentary\cn_014_exposition_board.mp3" "[ Даніка Роджерс ] Ми хотіли розмістити цю насичену порцію візуальної історії саме тут — у місці, де гра найбільш чітко підказує гравцеві досліджувати простір. І навіть попри те, що головним завданням цього епізоду є світобудова, ми все одно прагнемо підкреслити стосунки між Ілаєм і Бріном, надаючи контекст центральному конфлікту світу."
N/A3932"#commentary\cn_015_city_17_awakens.mp3" "[ Девід Сойєр ] Ранній епізод на вокзалі був розроблений так, щоб місто здавалося байдужим до гравця, немов Ґордон — лише ще один безіменний, безликий громадянин, готовий до поневолення. Але під час облави в багатоквартирному будинку та втечі дахами місто ідентифікує гравця як аномалію й починає оживати. Тепер, коли гравець виступає агресором, місто повністю звертає на нього свою увагу. Система оповіщень Нагляду, яку вперше чути під час облави, відіграє ключову роль у передачі цього меседжу. Якщо гравці прислухаються уважно, вони зможуть почути багато деталей про рівень поінформованості міста. Та навіть якщо вони не звертають увагу, звуковий супровід усе одно передає потрібний емоційний посил."
N/A3933"#commentary\cn_016_elis_lab.mp3" "[ Забі Інґ ] Ми побудували лабораторію Ілая вже після лабораторії доктора Кляйнера, і це дало нам краще розуміння того, як налаштовувати та проєктувати ефективні хореографічні сцени. Завдяки цьому ми змогли створити складніший сценарій із більшою кількістю можливостей реагувати на дії гравця. Наявність кількох персонажів, які займалися своїми справами в кімнаті, ускладнювала постановку, тож знадобилося чимало ітерацій та ігрових тестів, аби все працювало бездоганно. Наш досвід показав, що зазвичай гравці хочуть взаємодіяти зі сценою — їм лише потрібні тонкі підказки, щоб зрозуміти наші наміри. І якщо вони відволікалися, сцена мала м’яко призупинятися й чекати їхнього повернення."
N/A3934"#commentary\cn_017_feel_free_to_look_around.mp3" "[ Забі Інґ ] Знайти баланс між бажанням гравця досліджувати й оповідальними цілями сцени завжди було непросто. Ми хотіли, щоб у кімнаті було безліч цікавих деталей, але багато хто не починав дослідження, поки не був упевнений, що не пропустить жодної репліки персонажів. Саме тому було важливо, щоб Ілай десь посеред сцени сказав гравцеві озирнутися — це сигналізувало, що тепер можна безпечно досліджувати. Після цього ми могли запускати різноманітні міні-сцени залежно від того, що привернуло увагу гравця."
N/A3935"#commentary\cn_018_interstitial_scenes.mp3" "[ Ерік Кіршмер ] Під час ігрового тестування ми часто виявляли зони, де гравці втрачали відчуття своєї мети — для гри на кшталт Half-Life не є рідкістю. Щоб вирішити цю проблему, ми додали невеликі проміжні сцени, які допомагали гравцям рухатися далі й утримували їхню увагу на завданні. Після того як ми завершили основну роботу над більшими хореографічними сценами, як-от лабораторія Кляйнера, збирання цих менших сцен стало відносно простим. Ми з’ясували, що залучення персонажів у таких моментах працює значно краще, ніж пасивна оповідь або якісь стандартні нагадування в меню паузи."
N/A3936"#commentary\cn_019_overwatch.mp3" "[ Джош Вейєр ] Під час розробки ми згенерували голос Нагляду за допомогою безкоштовного інструменту перетворення тексту на мовлення. Але ближче до релізу з’ясувалося, що ми не маємо прав на його використання. Тож ми провели кастинг серед акторів озвучення, щоб знайти голос із тими ж характеристиками, які нам подобалися у згенерованих рядках. Невдовзі ми знайшли Еллен Макклейн, чия подача була саме такою, яку ми шукали. Під час записів ми вмикали їй згенеровані рядки, аби вона могла їх наслідувати, але вже у власному стилі. Спочатку вона поставилася до цього трохи саркастично, адже її просили відтворити настільки роботизовану манеру. Проте роками пізніше вона повернулася для культової ролі GLaDOS у Portal і змогла творчо інтегрувати цей тон у свої репліки."
N/A3937"#commentary\cn_020_box_car_joe.mp3" "[ Лора Дабак ] Спочатку в цій невеликій сцені були два людські персонажі, але пізніше під час розробки ми замінили одного з них на вортіґонта. Ми хотіли показати, що вортіґонти співіснують із людьми та також чинять опір Комбінації. Ми додали також їхню здатність зцілювати гравця, хоча так і не використали цю можливість повною мірою у грі. Вортіґонти стали корисним наративним інструментом, який дозволяв робити діалоги лаконічними, адже завдяки своєму колективному розумові вони знали все про світ і цілі гравця. Це означало, що вони ніколи не ставили ніяких питань, що дозволяло уникнути проблеми написання діалогів для мовчазного протагоніста."
N/A3938"#commentary\cn_021_mossman.mp3" "[ Марк Лейдлоу ] Джудіт Моссман спочатку була заснована на персонажі, якого ми планували для одного епізоду в Half-Life 1. Цей епізод вирізали з основної гри та повторно використали в Uplink, але вже без цього персонажа. Ми вважаємо її найскладнішим персонажем у Half-Life 2. Ми знали, що нам доведеться тонко балансувати зі ставленням гравця до неї ще до подій у Нова Проспект, адже люди, яким гравець довіряє, не згодні між собою: Ілаю вона подобається, а Алікс — ні. Ми розуміли, що існує певна межа, наскільки складними ми можемо зробити стосунки, але відчували, що динаміка «мачуха — дочка» буде зрозумілою для гравців. Згодні ви з Моссман чи ні, вона робить щось героїчне. Вона ризикує стати подвійним агентом, щоб здобути інформацію, необхідну для захисту Ілая та Алікс. Вона просто не врахувала Ґордона."
N/A3939"#commentary\cn_022_hands_free.mp3" "[ Метт Райт ] На момент виходу Half-Life 2 більшість шутерів від першої особи відразу давали гравцеві пістолет або зброю ближнього бою, але ми вирішили почати з порожніми руками. Без зброї було легше навчити гравця новаторським способам взаємодії зі світом і поступово познайомити його з нашою історією. Ми хотіли, щоб гравець пройшов шлях від утікача до нападника, і, озброївши його в потрібний момент, ми зробили цю трансформацію природною. Коли він нарешті отримує зброю, він перестає тікати. Кажуть, іноді найкращий спосіб перемогти — просто піти. Але ми всі знаємо, що це неправда. Найкращий спосіб перемогти — це бігти назустріч і стріляти."
N/A3940"#commentary\cn_023_metrocop_scene.mp3" "[ Майк Дюссо ] Це ще одна сцена, створена для того, щоб чітко дати зрозуміти: комбінанти — погані хлопці. Але цього разу гравець має зброю й нарешті може щось із цим зробити. Під «щось» ми маємо на увазі те, що вилітає з дула пістолета. Нам потрібно було, щоб гравець відчув себе на боці справедливості, і цей момент був частиною створення такого відчуття. Комбінанти все ж люди — на відміну від решти Комбінації в грі, — тому ми вважали за потрібне докласти додаткових зусиль, аби дії гравця сприймалися як правосуддя, а не просто як прояв гніву."
N/A3941"#commentary\cn_024_moving_the_gravity_gun.mp3" "[ Тед Бекман ] Коли ми вперше створили прототип гравітаційної гармати, ми планували дати її гравцеві десь у середині гри. Але під час тестування побачили, наскільки сильним і вдалим вийшов цей інструмент, і зрозуміли, що гравітаційна гармата, а ще важливіше, можливість запускати пильні диски просто в морду зомбі мають з’явитися раніше. Через це лабораторію Ілая теж довелося перенести на більш ранній етап. Це була суттєва зміна, але вона стала вирішальною для успіху Half-Life 2. І це гарне нагадування, що сюжет та ігровий процес тісно пов’язані: жоден із них не може завжди мати пріоритет — вони повинні працювати разом."
N/A3942"#commentary\cn_025_buggy_birds.mp3" "[ Адріан Фінол ] Під час одного пам’ятного ігрового тесту на узбережжі гравець повернувся до свого транспорту після дослідження будинку й випадково побачив птаха, що пролітав повз. Він накричав на нього, наказавши триматися подалі від свого баггі, і поскаржився, що в реальному житті птахи часто бруднять його машину. На обговоренні після ігрового тесту ми зрозуміли: це був перший випадок, коли гравцеві став небайдужим об’єкт, відокремлений від нього самого. Ми побачили в цьому можливість для експериментування й створили систему, щоб реалізувати момент, якого боявся тестувальник. Коли гравець залишає своє баггі на деякий час і зникає з поля зору, на рамі автомобіля у випадковому місці з’являється чайка. Згодом вона лишає плями посліду на кузові під собою й робить це доти, доки гравець не повернеться, після чого відлітає. Звісно, тестувальники захотіли мати змогу помити транспорт, тож ми додали можливість очистити баггі, заїхавши на мілководдя. На той час це вже був пізній етап розробки, і в нас були всі необхідні для цього технології, тож функцію було реалізовано швидко. Це один із тих випадків, коли ми знаємо, що лише невеликий відсоток гравців відкриє цю дрібницю, але якщо ми зможемо ефективно додавати подібні деталі та їх буде достатньо, більшість гравців натрапить принаймні на одну з них."
N/A3943"#commentary\cn_026_bridge_gunship.mp3" "[ Адріан Фінол ] Ми були особливо задоволені боєм зі штурмовиком, попри складність його налаштування через геометрію рівня. Завдяки тому, що гравець перебував під мостом, штурмовик міг вільно переміщатися навколо нього, використовуючи всі три виміри й займаючи позиції то зверху, то знизу в різні моменти. Балки забезпечували безліч укриттів, тож вогонь штурмовика створював захопливу й динамічну комбінацію візуальних і звукових ефектів."
N/A3944"#commentary\cn_027_floor_is_lava.mp3" "[ Адріан Фінол ] Побудова ігрового процесу навколо загальновідомих концепцій, як-от «підлога — це лава», значно спростила навчання. Нам подобалося, що наша система фізики дає гравцям широку творчу свободу у виборі способів подолання виклику. Одні будували містки з багатьох предметів, а інші обходилися лише двома улюбленими листами металу. Одні обережно рухалися стежкою серед скель, боячись упасти, а інші рухалися просто до виходу, балансуючи на предметах просто над піском. Стилі гри відрізнялися: одні гравці вважали провалом те, що вони спровокували появу мурашиних левів, і одразу перезавантажували гру, тоді як інші насолоджувалися процесом, знову видираючись на скелі, щоб урятуватися. Нам також подобалося, що ця сцена працювала як навігаційна головоломка, але за бажанням могла перетворитися на арену: дехто просто стрибав на пісок і пробивався з боєм до кінця."
N/A3945"#commentary\cn_028_opportunistic_moments.mp3" "[ Аріель Діас ] Деякі незабутні моменти у грі виникають завдяки взаємодії кількох ігрових систем, але ми розуміємо, що такі моменти трапляються досить рідко. У таких випадках нам хочеться, аби їх пережили більше гравців. Тут виникає певна напруга: що більше ми впевнені, що гравці зіткнуться з певною ситуацією, то більше зусиль можемо вкласти в її опрацювання. Але якщо момент виглядає надто штучним, він може здаватися нав’язаним, і реакція гравців буде не такою позитивною. Прикладом є кінематографічна загибель штурмовика: ми трохи підкоригували події, щоб збільшити шанси на незабутній момент, не роблячи його надто очевидним. Дизайн цієї зони й траєкторії польоту штурмовика роблять ймовірним те, що гравець і ворог опиняться в потрібних місцях у момент його загибелі. Якщо це так, ми запускаємо сцену зіткнення штурмовика з машинами. Якщо ні — він гине звичайним способом. Це абсолютно ігровий трюк, але тестувальники, схоже, не заперечували, коли момент виглядав видовищно."
N/A3946"#commentary\cn_029_assault_on_nova_prospekt.mp3" "[ Аріель Діас ] Коли ви маєте на береговій лінії нескінченно відроджувану армію мурашиних левів, що штурмує укріплену базу Комбінації, складно не спробувати зробити рівень, натхненний висадкою в Нормандії. У нашому початковому прототипі були траншеї, що вели до Нова Проспект, і смертоносні кулемети змушували гравця та його мурашиних левів залишатися в укритті, щоб вижити. Було захопливо бачити, як над траншеями постійно свистять кулеметні черги й стрибають мурашині леви. На жаль, ми не змогли вкластися в бюджет продуктивності й зрештою відмовилися від цього на користь зовсім іншого компонування рівня. Однак стаціонарні кулемети залишилися, адже їхня смертельна ефективність добре спонукала гравців покладатися на своїх мурашиних левів."
N/A3947"#commentary\cn_030_buggy_physics.mp3" "[ Чарлі Браун ] Фізика баггі потребувала багатьох спроб і помилок. Ми хотіли, щоб він здавався швидким, хоча його максимальна швидкість становила лише 35 миль на годину (близько 56 км/год), тому нам довелося піти на деякі хитрощі, аби це спрацювало. Ми додали вертикальну силу для турбострибка та легкий ривок задньої частини при використанні ручного гальма для дрифту. Без цього низька швидкість робила керування баггі просто нецікавим. Крім того, світ був сповнений непередбачуваного хаосу, створеного фізичними системами, тож гравці на баггі неминуче врізалися в різні об’єкти, і ми мали подбати, щоб вони завжди могли вибратися з таких ситуацій. Це вимагало безлічі експериментів та ігрових тестів. Врешті-решт ми зупинилися на доволі химерній і нереалістичній симуляції, завдяки якій баггі прощав більше помилок і його важче було перевернути. Його центр ваги розташований дуже низько, і хоча здається, ніби колеса активно крутяться, насправді це не так. Це була наша перша спроба створити фізично симульований транспорт, і ми багато чого навчилися. Завдяки цьому ми змогли зробити керування маслкаром в Episode Two набагато легшим."
N/A3948"#commentary\cn_031_the_bridge.mp3" "[ Чарлі Браун ] Ця ділянка з мостом була натхненна мостом Десепшн-Пас, що розташований неподалік від офісу Valve. Спочатку ми створили її як суто навігаційну головоломку, поступово додаючи більше ігрових елементів. Вона також стала головним тестовим сценарієм для перевірки тертя на краю поверхонь. У нашій системі руху ми непомітно збільшуємо тертя під час уповільнення гравця, коли він наближається до краю. Гравці ніколи цього не помічали — ймовірно, тому що це природно узгоджувалося з їхнім бажанням зупинитися на краю й подивитися вниз, що відповідає людській схильності рухатися повільніше та обережніше біля прірви. Але для цієї частини гри ця функція виявилася критично важливою. Ми зрозуміли це тоді, коли під час розробки випадково її зламали, і раптом усі наші тестувальники почали раз за разом падати у прірву."
N/A3949"#commentary\cn_032_coast.mp3" "[ Кріс Ґрін ] Ми хотіли зробити у грі простору локацію для баггі, але водночас потрібно було якось обмежити рух гравця. Вибір берегової лінії дав нам природну межу з одного боку карти, зберігаючи при цьому відчуття відкритості та масштабу. Це також допомогло показати наслідки виснаження ресурсів Землі Комбінацією. Проте тестувальники все одно намагалися запливти в море, тож ми додали п’явок, щоб їх відлякувати. П’явки не задумувалися як справжні вороги, з якими гравці могли би вступити в бій, тому вони дещо «магічні». Загалом гравці розуміли, що намагаються вийти за межі гри, тож ми не стали приділяти п’явкам багато уваги."
N/A3950"#commentary\cn_033_grenade_house.mp3" "[ Дейв Ріллер ] В іграх серії Half-Life головне — давати гравцям трохи нових бойових вражень на кожному кроці, навіть якщо це лише невеликі варіації на попередні ситуації. І не всі вони мають бути випробуваннями, що вимагають особливих навичок; іноді це просто кумедні моменти, коли гравець може отримати задоволення від гри. Цей будинок із гранатами — один із таких моментів, але тут ми перевернули звичну схему. Замість того щоб дозволити гравцеві кидати гранати на ворогів унизу, ми розмістили ворогів нагорі. Ящик із необмеженим запасом гранат — дещо незграбний спосіб підштовхнути гравця до участі в цьому сценарії, але його невразливість також гарантує, що гравець усе одно зможе піднятися на поверх вище, навіть якщо підірве довкола все інше."
N/A3951"#commentary\cn_034_buggy_training_course.mp3" "[ Девід Сойєр ] Цю навчальну ділянку ми розробили так, щоб гравець міг вдосталь погратися зі своїм баггі. На момент виходу Half-Life 2 такий рівень фізичної симуляції транспорту був новинкою, тож ми хотіли дати гравцям достатньо простору для експериментів. До того ж гравець щойно вирвався з тісних меж Рейвенхолма, і нам подобалася ідея контрастної нагороди — можливості швидко мчати великою відкритою територією й почуватися в безпеці за кермом. Ми подбали, щоб для виходу з цієї зони був потрібен турбострибок: це одночасно перевіряло, чи гравець уже впевнено опанував керування, і гарантувало, що він не залишить своє баггі позаду."
N/A3952"#commentary\cn_035_ambush.mp3" "[ Девід Сойєр ] Одна з головних труднощів шутера у стилі Half-Life полягає в тому, що гравець постійно просувається вперед у незнайомі місця. Тож, опинившись у бою, він не знає, як краще діяти на незвіданій території. Ми застосовуємо різні прийоми, щоб допомогти гравцеві впоратися з цим, і ця засідка — один із прикладів. Спершу, прибувши сюди, гравець б’ється з групою солдатів Комбінації серед цих будинків. Під час сутички та подальшого дослідження він встигає запам’ятати планування арени. А коли піднімається на горище, ми запускаємо другу хвилю Комбінації. У цьому другому бою гравець уже має перевагу: знання простору дозволяє йому приймати більш тактичні рішення й ефективніше оборонятися від нападників."
N/A3953"#commentary\cn_036_bugbait_training.mp3" "[ Девід Сойєр ] Ми зупинилися на цьому трохи незграбному навчанні використанню приманки, коли час уже підтискав, але нам було критично важливо, щоб гравці зрозуміли цей інструмент. Інакше дизайн Нова Проспект просто не працював би. Зазвичай ми намагаємося додати достатньо колориту й контексту, щоб навчання не виглядало як урок, а відчувалося як природне відкриття чогось нового. Тут же досягти цього не вдалося. Яким би це очевидним це не здавалося нам, гравці зовсім не сприймали інтуїтивно приманку. На цьому етапі вони вже мали великий досвід у боротьбі з ворогами. І ще до будь-якого навчання перші тестувальники, отримавши приманку, йшли на наступний рівень і автоматично стріляли в першого ж мурашиного лева бо саме так діяли раніше. Half-Life загалом заохочує підхід «спочатку стріляй, потім думай». Так само, дійшовши до Нова Проспект, гравці навіть не здогадувалися кидати приманку в солдатів Комбінації й замість цього покладалися на звичну зброю. Тож це навчання було потрібне нам не лише для того, щоб пояснити принцип роботи приманки, а й щоб показати: мурашині леви можуть бути поруч із гравцем і не нападати."
N/A3954"#commentary\cn_037_vortigaunt_extraction.mp3" "[ Забі Інґ ] Ця арена поставила перед нами кілька складних завдань із точки зору дизайну. По-перше, страж — ворог винятково ближнього бою, тож ми не могли допустити, щоб гравець діставався місць, куди страж не міг піти за ним. Ми пробували додати кілька атак дальнього бою, але результат нас не влаштував — наприклад, плювки слизом виглядали просто смішно. Єдиний не ближньобійний прийом, що лишився, — це здатність стража шпурляти у гравця фізичні об’єкти, але для цього ті ще мали бути в межах досяжності, а це не завжди гарантовано. Друга проблема полягала в тому, щоб незалежно від того, де загине страж, вортіґонт зміг дістатися до його тіла. Це було критично важливо, адже гра не може продовжитися, якщо вортіґонт не зможе витягти приманку (феропод)."
N/A3955"#commentary\cn_038_dropship_deployment.mp3" "[ Даг Вуд ] Висадка солдатів із транспортників виявилася непростим завданням, адже NPC доводилося створювати всередині іншого твердого об’єкта. Щоб одразу вивести їх на відкрите місце, де вони могли почати нормально пересуватися, ми зробили так, що в момент їх появи відразу відтворюється анімація стрибка з контейнера. Коли це запрацювало, виникла інша проблема — кмітливі гравці просто чатували біля контейнера й розстрілювали солдатів під час анімації виходу. Щоб протидіяти цьому, ми додали до контейнера турель, яка прикривала солдатів, поки вони висаджувалися. Це не повністю усувало можливість скористатися перевагою, особливо якщо гравець застосовував непряму зброю, як-от гранати. Але така поведінка здавалася реалістичною й виглядала як справжній контрзахід, який міг би застосувати стратегічно мислячий противник."
N/A3956"#commentary\cn_039_laser_guided_rpg.mp3" "[ Ерік Сміт ] Функція лазерного наведення РПГ стала для нас справжнім головним болем, адже навчити гравців користуватися нею було непросто. Багато тестувальників робили постріл і одразу ховалися за укриттям, тож не бачили траєкторію польоту ракети. Ще гірше, вони не усвідомлювали, що ракета розвертається й летить назад прямо на них. Ми пробували різні елементи інтерфейсу та лазерні мітки, але більшість гравців їх ігнорувала, зосереджуючись винятково на ворогові. Ми внесли стільки дрібних покращень, скільки могли: підкреслили цю особливість у промові Одесси, посилили звукові й візуальні ефекти моменту, коли штурмовик збиває прямий постріл РПГ. Ці зміни допомогли частині гравців, але ми так і не дійшли до того, щоб бути впевненими, що майже всі зрозуміють механіку. Ми навіть думали повністю прибрати цю функцію, але бій із штурмовиком без неї ставав менш цікавим. Лазерне наведення змушувало гравця тримати штурмовик у полі зору під час польоту ракети, але водночас і сам штурмовик отримував лінію прямої видимості на гравця, створюючи напругу, яка нам дуже подобалася."
N/A3957"#commentary\cn_040_performance_constraints.mp3" "[ Ерік Сміт ] Для фінальної арени на узбережжі ми замислювали грандіозний фінал: гравець разом із загоном громадян мав стримувати хвилі солдатів Комбінації, а кульмінацією став би бій із штурмовиком. На жаль, обчислювальні витрати на переміщення солдатів і союзників по рельєфу виявилися надто великими, тож битву доводилося постійно скорочувати, аби вкластися в наш бюджет продуктивності. Коли ж на арені лишався лише один загін солдатів одночасно, ми вже були на пізніх етапах розробки. Часу на масштабні зміни арени, які дозволили б розмістити більше ворогів, не залишалося, тож довелося переробити хід бою так, щоб кількість солдатів залишалася мінімальною."
N/A3958"#commentary\cn_041_lighthouse_gunship.mp3" "[ Ідо Маґал ] Сценарій зі штурмовиком тут вимагав чимало роботи, щоб вийшов так, як ми задумали, — ми хотіли, щоб він розгортався по-кіношному. У фільмі штурмовик стріляв би крізь вікна, випереджаючи рухи головного героя, який підіймається сходами маяка. Щоб відтворити це у грі, ми налаштували складну систему тригерних зон уздовж сходів. Вони фіксують підйом гравця й наказують штурмовику обрати нову траєкторію польоту відповідно до висоти гравця. Тригери також активують у найближчих вікнах спеціальні мішені-приманки — невидимі ігрові об’єкти, які ШІ відразу сприймає як ворожі, — й тим самим підштовхують штурмовика відкривати вогонь. Таке поєднання ШІ та скриптів є основою бойових сценаріїв Half-Life. ШІ керує загальною адаптивною поведінкою NPC, а скрипти задають унікальні умови кожної сцени."
N/A3959"#commentary\cn_042_crane.mp3" "[ Якоб Юнґельс ] Щоб кран працював як слід, знадобилося багато тонкого налаштування. Пристрій, який мав створювати таку значну фізичну силу, завжди був ризикованим через обмеження нашої фізики твердих тіл і технології руйнування. Наприклад, магніт ніколи не міг повністю відповідати очікуванням гравців від предмета з такою масою. Але оскільки кран залишався стаціонарним, ми могли ретельно визначати все, що потрапляло в зону його дії, і підлаштовувати це за потреби. На щастя, більшість гравців, схоже, не звертали уваги на огріхи — ймовірно, через саму новизну взаємодії з таким об’єктом у більш-менш реалістичному фізичному середовищі."
N/A3960"#commentary\cn_043_flashlight_power.mp3" "[ Джефф Лейн ] Рішення використовувати енергію костюма HEV і для бігу, і для ліхтарика було в Half-Life 2 доволі суперечливим. Спочатку енергія витрачалася лише на біг, що мало сенс, адже він задумувався як короткочасний ривок. Ліхтарик же можна було використовувати без обмежень. Але під час тестування виявилася проблема: гравці часто залишали темні ділянки, не усвідомлюючи, що ліхтарик усе ще ввімкнений. У яскраво освітлених відкритих зонах на кшталт Узбережжя наш бюджет продуктивності не дозволяв, щоб ліхтарик світив постійно, тож потрібен був спосіб вимикати його без участі гравця. Обмеження часу роботи здавалося простим рішенням, яке до того ж додавало напруженості у темних місцях. Тоді постало питання: який ресурс має на це витрачатися? Ми вже мали енергію костюма, і не хотіли захаращувати інтерфейс ще одним показником лише для ліхтарика. Ми навіть розглядали ідею зробити так, щоб енергія костюма витрачалася і на інші здібності гравця, змушуючи його йти на компроміси, обираючи між ними. Це гарний приклад того, що ігровий дизайн часто стикається з необхідністю вибору між недосконалими рішеннями. Ідея ділити ресурс між бігом і ліхтариком нам не дуже подобалася, але й кілька ресурсів в інтерфейсі виглядали б ще гірше. В Episode Two, не плануючи додавати нові механіки, які б споживали енергію костюма, ми зрештою вирішили виділити ліхтарику окремий ресурс."
N/A3961"#commentary\cn_044_open_world_loot.mp3" "[ Джефф Лейн ] Відкритість узбережжя створила для нас нову проблему, пов’язану з розподілом предметних нагород. В іграх серії Half-Life ми зазвичай винагороджуємо гравців за дослідження. Якщо ви бачите шлях уперед, але помічаєте щось осторонь — цілком імовірно, що, витративши час на пошук, знайдете там щось корисне. Коли ми вперше почали тестувати карти узбережжя, ми ховали нагороди в кутках відкритих зон. Однак це псувало враження від їзди на баггі. Широкі локації означали, що завжди є безліч дрібних ділянок, які виглядали так, ніби там може бути щось заховане, й гравці постійно зупинялися та виходили з баггі, щоб їх обшукати. Це ставало нудним і переривало задоволення від рівня. Тому ми прибрали ці розкидані нагороди. Але виникла нова проблема: як дати гравцеві зрозуміти, коли справді варто виходити з баггі? Після деяких роздумів ми встановили правило: будь-яка людська споруда завжди міститиме ігровий контент і нагороди за дослідження, тоді як суто природні ділянки залишатимуться порожніми. Ми не могли пояснити це гравцям прямо, але таке правило добре збігалося з їх природними припущеннями, і ми послідовно підкріплювали його в подібних зонах."
N/A3962"#commentary\cn_045_gas_station.mp3" "[ Джефф Лейн ] Ми мали грандіозні плани на цю сутичку. Ми уявляли заправку, де гравець б’ється з ворогами, ймовірно підпалюючи резервуари з бензином і розповсюджуючи полум’я довкола. Ми малювали картину, як гравець від’їжджає від бурхливої пожежі. Але бюджет і продуктивність у 2003 році наклали жорсткі обмеження, тож заправка ставала дедалі меншою й простішою, аби вписатися у великі рівні узбережжя. Наші плани щодо динамічної системи вогню так і не здійснилися, і створювати її вже не мало сенсу — завжди є межа того, скільки роботи можна виконати заради однієї сутички. У результаті єдине, що залишилося від початкового задуму, — це вибухові резервуари з пальним."
N/A3963"#commentary\cn_046_buggy_introduction.mp3" "[ Джон Кук ] Ми хотіли зробити знайомство гравця з баггі більш захопливим, ніж просто «сів і поїхав». У цьому допоміг кран. Вкрай важливо було навчити гравців повертати баггі в нормальне положення, коли він перевертається, і ця сцена змушувала їх пройти через таку ситуацію. Навчання під тиском завжди складне, але ми прагнули підкреслити, що через нашестя мурашиних левів безпечніше лишатися в баггі. Тому ми залишили загрозу від цих тварин активною й додали пару громадян за стаціонарними кулеметами для підтримки. І ще один приємний бонус: гравці також отримують досвід підйому краном — безпосередньо перед тим, як самі зможуть ним керувати."
N/A3964"#commentary\cn_047_crossbow.mp3" "[ Джон Кук ] Це перша можливість гравця отримати арбалет у грі, і, озираючись назад, ми трохи дивуємося, що не зробили для цього ворота. Цілком можливо, що гравець просто проїде повз нього. Щоб знизити ймовірність цього, ми встановили блокпост і спостережний пункт, спонукаючи таким чином гравців вийти з баггі, — і в цей момент вони помічали арбалет і ящик із предметами. Тестування показало, що майже кожен гравець зупинявся й забирав зброю, але це саме той випадок, коли результати тестування можуть відрізнятися від поведінки гравців у реальній грі. Тестувальник, який грає з початку глави «Узбережжя», може бути не таким стомленим від дослідження, як людина, що грає від самого початку гри. Тож ми розмістили ще один арбалет за кілька рівнів, безпосередньо на шляху гравця до Нова Проспект."
N/A3965"#commentary\cn_048_rollermines.mp3" "[ Джош Вейєр ] Електроміни були створені для того, щоб зробити ворога, який становив би загрозу для гравця під час їзди на баггі. Оскільки гравець на баггі був по суті повністю фізично симульованим об’єктом, ми подумали, що цікаво було б мати й ворога з такими ж властивостями. Людорiз уже показав нам, як цей підхід може призвести до появи ворога з безліччю цікавих взаємодій із навколишнім світом. Так ми створили електроміну — кулю, рух якої повністю визначається створенням крутного моменту в ній самій, — і неодноразово вдосконалювали її поведінку, поки боротися з нею за кермом не стало дійсно цікаво. Електроміни не становлять особливої небезпеки для баггі, але якщо дати їм накопичитися, вони можуть стати проблемою, особливо біля урвища. Ми також подбали, щоб вони добре працювали й тоді, коли гравець пересувається пішки, що дало змогу дизайнерам рівнів використати їх ще й у кількох додаткових сутичках."
N/A3966"#commentary\cn_049_sandtrap_thumper.mp3" "[ Лора Дабак ] Вибухові бочки надаються гравцям для використання проти мурашиних левів, коли вони перебувають під захистом трамбівки. Але вони також слугують підказкою для майбутньої сутички зі стражем мурашиних левів, у якій гравці часто застосовують схожу тактику для перемоги. Необов’язкові дії гравця, такі як запуск вибухівки гравітаційною гарматою, можуть забутися, якщо не використовувати їх регулярно. Оскільки ми даємо гравцям широкий вибір атак, немає гарантії, що вони користувалися цією здатністю останнім часом. Тож тут ми ненав’язливо підказуємо повернути її до арсеналу перед битвою зі стражем."
N/A3967"#commentary\cn_050_coast_kickoff.mp3" "[ Марк Лейдлоу ] Ця проміжна сцена з’явилася на пізньому етапі розробки, щоб поєднати Рейвенхолм із узбережжям. Помічаєте закономірність? Досить багато сполучних елементів у наших іграх з’являються пізно. У цьому випадку ми змушені були йти коротким шляхом всюди, де це було можливо, — ми навіть не мали часу анімувати Алікс на моніторі. Такі сцени завжди складно зробити цікавими, і з цією нам не вдалося. Це хороший приклад того, що відбувається, коли до NPC ставляться як до простих дороговказів, через що ні персонаж, ні сцена не мають свого характеру. У результаті виходить момент, де видно шви гри, який швидко забувається. Але така вже природа розробки — часу обмежено, і треба вирішувати, на що його витратити. Лабораторія Кляйнера та лабораторія Ілая були набагато важливішими, тому ми зосередили наші зусилля саме на них."
N/A3968"#commentary\cn_051_odessa_cubbage.mp3" "[ Марк Лейдлоу ] Одесса Кеббедж — приклад того типу епізодичних персонажів, що, як ми з’ясували, працюють дуже добре. Це колоритний чоловік із кількома дотепними деталями, який живе у власному маленькому світі. Оскільки він не виходить за межі свого сценарію, його можна було зобразити достатньо перебільшено, щоб він виділявся. Ми почали з його моделі, взятої з вирізаної частини гри й переробленої для нових цілей, і назвали його на честь заголовка спам-листа, який ми отримали. Спочатку це була модель норвезького рибалки, але вона не зовсім підходила для англійця, тож ми приліпили йому вуса — і саме в цей момент народився персонаж Одесса. Зрештою він шарлатан, і все в ньому фальшиве — акцент, вуса, геть усе. Він ніколи не наражатиме себе на небезпеку, тож ідеально підходить, аби вручити Ґордону РПГ і пояснити, як ним користуватися."
N/A3969"#commentary\cn_052_28_transitions_later.mp3" "[ Марк Лейдлоу ] Після того як ми поєднали кілька рівнів темними тунелями, щоб вони слугували переходами, ми зрозуміли, що можемо обдурити очікування гравців, створивши ще один тунель, який виглядав би як звичайний перехід, але насправді містив щось інше. Як і всі, ми подивилися у 2002 році фільм «28 днів потому», він нам дуже сподобався, і ми відразу ж захотіли зробити напружену сутичку із зомбі в одному з наших темних тунелів. Цю сцену ми зібрали доволі швидко й залишилися задоволені результатом. Через кілька років ми познайомилися з Алексом Ґарлендом, сценаристом фільму. Він грав у Half-Life 2, йому сподобалося, і ми зізналися, що саме його фільм надихнув нас на створення цієї ділянки."
N/A3970"#commentary\cn_053_finest_mind_of_his_generation.mp3" "[ Марк Лейдлоу ] Ось ще одна невелика проміжна сцена, яка в результаті вийшла вдалою. Єдиною вимогою тут було навчити гравця триматися подалі від піску. У попередніх сценах ми все ще зосереджувалися лише на тому, щоб зробити їх функціональними, але коли дійшли до цієї, вже почувалися впевненіше й почали отримувати задоволення від того, що ретельніше продумували такі моменти. Завдяки цьому ми змогли вивести персонажів за рамки простих дороговказів, створивши щось цікавіше й захопливіше. Після релізу Лазло здобув неймовірну популярність, нагадавши нам, як важко передбачити, що саме зачепить гравців."
N/A3971"#commentary\cn_054_bridge_playtesting.mp3" "[ Метт Бун ] Ділянка з мостом завжди була вершиною ігрових тестів: тестувальники незмінно реагували на неї дуже емоційно. Напруження, яке вони відчували, повільно пробираючись по балках, було помітним у їхніх рухах. Із часом ми додавали дедалі більше викликів у цей перехід, і спостерігати за тестами ставало ще цікавіше. То раптом гуркотів потяг, розхитуючи міст разом із гравцем, то в хатинці, яка здавалася безпечною точкою відпочинку на півдорозі, несподівано вискакував хедкраб. Ми відчували себе трохи винними, насолоджуючись видимим стресом тестувальників, але ми ж не абсолютні чудовиська: перетнувши міст, гравці зітхали з полегшенням, вимикали щит Комбінації, і тоді усвідомлювали, що доведеться повертатися вже по нижньому ярусу. Щоб ця дорога назад не здалася нудною, ми вирішили додати їм компанію у вигляді штурмовика, який чатував на них між балками."
N/A3972"#commentary\cn_055_thumper_final_stage.mp3" "[ Метт Бун ] Нам сподобалася фінальна сцена з обмежувачами периметра, де вони виконують зовсім протилежну функцію. Тепер це не засіб безпеки, а перепона для армії мурашиних левів гравця. Утім, мабуть, варто було дати гравцям ґрунтовніше навчання користуванню обмежувачами ще до цього моменту. Якщо раніше на рівнях узбережжя було прийнятно, що гравці лише частково розуміли принцип їхньої дії, то тепер ставки стали вищими, адже саме тут вони вперше випробовують приманку. Гравці, які не усвідомлюють, що перший обмежувач зупиняє їхніх мурашиних левів, можуть неправильно зрозуміти, як працює приманка. Якщо вони кинуть її у солдатів у першому бункері, а мурашині леви не з’являться, то вирішать, що приманка ненадійна або не працює як слід, і повернуться до звичної зброї."
N/A3973"#commentary\cn_056_buggy_tools.mp3" "[ Метт Райт ] Ми хотіли, щоб баггі був не лише засобом пересування, тож вирішили оснастити його зброєю. Ми обрали тау-гармату — зброю з Half-Life 1, яка нам подобалася, але якій не знайшлося місця в Half-Life 2. Оскільки тау-гармата здатна стріляти крізь стіни, що ускладнює дизайн рівнів, ми обмежили її використання ділянкою узбережжя. Коли ви вводите зброю з пробиванням укриттів, розробка рівнів стає значно складнішою. Крім того, ми закріпили на задній частині баггі ящик із необмеженим запасом патронів для пістолета-кулемета, доступних по всьому узбережжю. Це особливо допомагало тестувальникам, яким було важко впоратися з нескінченними мурашиними левами, що з’являлися з піску."
N/A3974"#commentary\cn_057_antlion_guard.mp3" "[ Метт Райт ] У рідкісних випадках гравці опинялися в ситуації, коли не могли вбити стража мурашиних левів на цій арені. Це траплялося, якщо в них закінчувалися боєприпаси й вони також витратили всі доступні фізичні об’єкти, які можна було запускати гравітаційною гарматою. Щоб уникнути цієї проблеми, ми додали громадянина за стаціонарним кулеметом над воротами як запасний варіант. Тож гравець, який застряг, міг покластися на союзника, щоб той добив стража."
N/A3975"#commentary\cn_058_terrain_and_performance.mp3" "[ Майк Дюссо ] Наш бюджет продуктивності часто ставав значним обмеженням у боях, особливо на ділянках рельєфу. Коли NPC рухаються, вони виконують безліч дрібних просторових перевірок, щоб визначити, чи можуть вони безпечно пройти обраним шляхом. Уявіть це так, ніби вони нічого не бачать і постійно махають палицею перед собою, перевіряючи, чи шлях вільний. Витрати ресурсів на такі перевірки зростають зі складністю геометрії світу. Наша система зміщень рельєфу створює нерівні поверхні, використовуючи дуже багато полігонів — значно більше, ніж ідеально рівні підлоги в інших місцях. Через це NPC, які пересувалися по рельєфу на узбережжі, були значно більш ресурсомісткими, ніж в інших зонах, і саме це обмеження диктувало масштаб багатьох сутичок у цій частині гри."
N/A3976"#commentary\cn_059_area_portals.mp3" "[ Майк Дюссо ] Однією з проблем із продуктивністю, з якою ми зіткнулися на узбережжі, була обробка широких просторів із будівлями, що мали дуже деталізовані інтер’єри — принаймні за мірками 2003 року. Коли гравець перебував зовні, ми хотіли виділити якомога більше ресурсів на рендеринг цього простору, не витрачаючи їх на інтер’єри будівель. Але якщо не забити всі вікна та двері дошками, гравець усе одно міг зазирнути всередину. Щоб вирішити цю проблему, ми створили функцію під назвою «портали області» (Area Portals), розміщуючи їх у кожному відкритому вікні та дверях. Портал області заздалегідь обчислює плоске зображення інтер’єру будівлі. Під час гри, коли гравець перебуває на певній відстані, портал відображає це попередньо згенероване зображення поверх вікна чи дверей, дозволяючи уникнути рендерингу справжнього інтер’єру. У міру наближення гравця ми робимо плавний перехід між зображенням порталу й реальним вмістом будівлі. За вмілого використання портали області допомогли нам досягти потрібного рівня продуктивності на узбережжі — разом із дверима, що час від часу закриваються за вами."
N/A3977"#commentary\cn_060_buggy_removal.mp3" "[ Майлз Естес ] Коли ми досягли моменту, коли гравцеві потрібно було залишити баггі, нам довелося зробити це дуже очевидним. Протягом усього узбережжя гравці залишали баггі й поверталися до нього, і ми з’ясували, що тестувальники намагалися взяти його з собою, якщо це здавалося хоч трохи можливим. Ця невелика сцена в гаражі в першу чергу потрібна для того, щоб однозначно позначити: на цьому їзда закінчується, і далі гравець піде пішки."
N/A3978"#commentary\cn_061_d2_coast_04.mp3" "[ Ренді Ландін ] Ця карта була першою ділянкою узбережжя, яку ми побудували, ще до появи крана та інших елементів рівня. Осушене морське дно та іржаві кораблі стали одними з перших елементів художнього оформлення. Через кілька років ми показали цю карту на E3 2003, хоча ігровий процес тоді ще значною мірою перебував у розробці. У результаті, коли ми почали створювати всю область узбережжя, ця демонстрація стала для нас корисним орієнтиром."
N/A3979"#commentary\cn_062_transition_tunnels.mp3" "[ Ренді Ландін ] Створення узбережжя змусило нас розробити спосіб переходу між рівнями. Щоб переміститися з одного рівня на інший, потрібно зберегти все, що є в зоні переходу, коли гравець залишає перший рівень, і відновити це в наступному після завантаження. Особливо важливо зберегти й відновити все, що видно гравцеві в зоні переходу, навіть якщо воно розташоване за її межами. Тому ми намагаємося робити такі зони якомога меншими й закритими. У більшості випадків для цього добре підходить невелика кімната. Але на узбережжі потрібне було інше рішення. Після кількох експериментів ми зупинилися на темних тунелях. Вони не лише правдоподібно повторювалися, а й дозволяли нам додати яскравий спалах світла наприкінці, щоб замаскувати той факт, що ми не можемо відобразити те, що знаходиться попереду гравця, адже воно існує вже на іншому рівні."
N/A3980"#commentary\cn_063_sniper_alley.mp3" "[ Робін Вокер ] Цю ділянку гри було додано на пізньому етапі розробки, після того як ми розмістили лабораторію Ілая та Рейвенхолм перед узбережжям. Хоча може здатися, що ми будуємо гру лінійно, насправді ми розділилися на три групи й паралельно працювали над різними частинами, здебільшого починаючи з середини гри. Спершу кожна група зосереджувалася на відпрацюванні основ своєї частини, а вже потім рухалася далі. Коли ж у нас з’явилася попередня версія всієї гри, ми поверталися до кожної ділянки, щоб відшліфувати її, додаючи вдалі елементи з інших зон і прибираючи те, що не спрацьовувало. У деяких випадках, як у Рейвенхолмі, ми переносили цілі ділянки. І після того як Рейвенхолм було переміщено, нам знадобився новий фрагмент, щоб з’єднати його з узбережжям — тією частиною, куди ви зараз потрапляєте. Через обмеження часу цю коротку ділянку ми зібрали з уже існуючих, перевірених елементів ігрового процесу, таких як снайпери й солдати Комбінації."
N/A3981"#commentary\cn_064_battery_finding.mp3" "[ Робін Вокер ] Коли в ігрових просторах Half-Life 2 з’явилося більше об’єктів, нам здалося цікавим дати гравцям завдання відшукати конкретний предмет, особливо якщо можна було здогадатися, де саме його шукати. Так гравці могли знаходити його або завдяки уважному спостереженню й дедукції, або ж просто обнишпоривши всю територію. Оскільки в нас уже були моделі автомобілів та акумуляторів, логічно було створити невелике звалище, яке гравці могли дослідити. Ми також сховали кілька додаткових акумуляторів у несподіваних місцях — для тих, хто діяв методом повного перебору. Як і в інших головоломках із предметами, тут потрібна була страховка на випадок, якщо гравці загублять акумулятори. Можете навіть спробувати скинути їх із обриву, щоб подивитися, що станеться."
N/A3982"#commentary\cn_065_boathouse.mp3" "[ Скотт Далтон ] У Half-Life 1 ми виявили, що можна отримати багато користі зі сценаріїв, у яких різні вороги під керівництвом ШІ б’ються між собою. Гравцям цікаво спостерігати за їхніми сутичками, і при цьому набагато простіше вивчати поведінку ворогів, коли загроза спрямована не на них. Ця перша сутичка мурашиних левів із солдатами Комбінації задумана як цікава можливість протаранити щось на баггі, але водночас вона допомагає підкреслити важливість обмежувачів периметра. Ми сподівалися, що, побачивши, як солдати використовують обмежувач для стримування мурашиних левів, більше гравців зрозуміють його призначення. Нам сподобалося, як солдати наочно демонстрували користь перебування біля обмежувача під час бою з мурашиними левами."
N/A3983"#commentary\cn_066_buggy_theft.mp3" "[ Скотт Далтон ] Коли ми працювали над фіналом глави «Узбережжя», ми вирішили, що Комбінація украде у гравця баггі. Це насправді не надто логічно, але після численних ігрових тестів, у яких гравці виявляли сильну прив’язаність до свого транспорту, нам захотілося зіграти на цьому емоційному зв’язку. Щойно ми реалізували цей момент, тестувальники почали кричати на Комбінацію за те, що ті поцупили їхнє баггі, — і ми сприйняли це як ознаку успіху. Солдат, який стріляє згори зі скелі, потрібен лише для того, щоб змусити гравця підняти очі: у цей момент спрацьовує тригер і з’являється транспортник із баггі. Спостерігаючи за цим зараз, через 20 років, ми дивуємося, наскільки смішно це все виглядає."
N/A3984"#commentary\cn_067_snipers.mp3" "[ Тед Бекман ] Команда Half-Life 2 ніколи не була великою, тож ми завжди шукали способи створювати новий ігровий досвід без значних витрат на виробництво ресурсів. Снайпер — чудовий приклад. У нього немає власної моделі — лише лазерний промінь, — тож для нього не потрібна була ні робота художників, ні анімаційна підтримка. Коли він гине, з вікна просто вилітає ragdoll солдата Комбінації. Попри таку простоту, ми змогли отримати з нього чимало унікального ігрового процесу. Особливо нам сподобалося, як він взаємодіє з фізичними об’єктами в ігровому світі. Гравці звикли використовувати вибухові предмети поруч із ворогами, тож логічно було зробити ворога, який змінює цю динаміку, коли гравець перебуває в укритті."
N/A3985"#commentary\cn_068_buggy_model.mp3" "[ Тед Бекман ] Модель баггі пройшла через багато ітерацій, перш ніж набула фінального вигляду. Ми випробували різні варіанти, які задовольняли і художні вимоги, і потреби фізичної симуляції, але зіткнулися з несподіваною проблемою: багатьох тестувальників, навіть досвідчених гравців у шутери від першої особи, починало заколисувати під час їзди. Окрім деяких змін у симуляції, ми з’ясували, що допомагає також і модифікація самої моделі: чим більше вона закривала огляд, тим сильнішим був дискомфорт. Тож ми почали прибирати деталі з кузова, поступово знімаючи все більше, аж доки гравці не перестали відчувати нудоту. Особливо помітну різницю дало те, що через прибраний низ кузова стало видно землю."
N/A3986"#commentary\cn_069_antlion_design.mp3" "[ Тед Бекман ] На ранніх етапах розробки гри ми планували кілька основних інопланетних рас, і Комбінація була лише однією з них. Однією з інших рас була релігійна інсектоподібна раса, до якої належали й мурашині леви. Пізніше, під час розробки узбережжя, ми почали сприймати їх радше як паразитів, що проникають через портали Зену разом із хедкрабами та іншими істотами. Насправді вони не родом із Зену, але заполоняють будь-який світ, куди потрапляють, — майже як таргани."
N/A3987"#commentary\cn_070_explosive_barrels.mp3" "[ Брайан Джейкобсон ] Тут ми вводимо вибухові бочки, класичний елемент шутерів від першої особи, але з новим підходом: другий постріл із пістолета підпалює бочку, запускаючи відлік до детонації, а третій миттєво підриває її. Таким чином, гравці можуть або відстрочити вибух, або спровокувати його негайно, залежно від ситуації. Наприклад, можна згодувати вибухову бочку барнаклові, а потім двічі вистрілити в неї, щоб безпечно й зручно розібратися з їхнім скупченням. Відкладений вибух також робив цікавішими ланцюгові реакції між кількома бочками. Вибухові бочки стали улюбленим елементом фанатів серії, та й дизайнери рівнів теж їх обожнювали — їм здавалося, що у грі їх ніколи не буває забагато."
N/A3988"#commentary\cn_071_ragdoll_magnets.mp3" "[ Даріо Касалі ] Фізика в Half-Life 2 дала нам цілий арсенал інструментів, щоб зробити бої більш захопливими. Наприклад, коли вороги промахуються по гравцеві, ми непомітно перенаправляємо їхні постріли на ламкі об’єкти поруч, додаючи хаосу й створюючи атмосферу справжнього бойовика. Ми також використовували фізику для додавання підказок. У грі ми створили так звані «магніти для ragdoll», щоб тіла ворогів падали ефектно й видовищно — наприклад, зривалися з уступів або опинялися на рейках перед потягом."
N/A3989"#commentary\cn_072_helicopter_peekaboo.mp3" "[ Дейв Ріллер ] Ми хотіли зробити бойовий гелікоптер Комбінації головним антагоністом протягом усієї глави. Він став повноцінним персонажем і, якщо прислухатися й подивитися вгору, можна почути звук його двигуна та побачити, як він летить уздовж залізничних колій у далечінь. Це перше знайомство з гелікоптером — тонкий натяк на майбутні події, адже згодом його присутність стає дедалі відчутнішою, поки нарешті ви не зіткнетеся з ним віч-на-віч."
N/A3990"#commentary\cn_073_iterative_passes.mp3" "[ Девід Спейрер ] Деякі глави гри, як-от пішохідні ділянки каналів або Рейвенхолм, розроблялися в кілька етапів різними кабалами — невеликими командами розробників. Ми з’ясували, що такий спосіб передавання карт забезпечує більшу різноманітність досвіду й вищу щільність цікавих моментів, адже кожна команда додавала до карт свої унікальні штрихи. У пішій частині каналів на першому етапі було визначено художній стиль, шлях гравця, а також основний задум і кілька ключових епізодів. Але командне альфа-тестування виявило недостатню напругу й певну одноманітність. На другому етапі ми повернулися до карти вже з єдиною метою — створити напругу, і суттєво збільшили щільність коротких ігрових епізодів."
N/A3991"#commentary\cn_075_pistol_design.mp3" "[ Джош Вейєр ] Стандартний пістолет — це основна робоча зброя гри. Він не лише перша далекобійна зброя, яку ви опановуєте, а й інструмент для взаємодії з фізикою та руйнівними об’єктами на безпечній відстані протягом усього проходження. Щоб зробити його використання відчутнішим і цікавішим, у пістолеті реалізовано унікальну для гри механіку швидкого повторного пострілу. Він стріляє з тією швидкістю, з якою гравець натискає кнопку стрільби, тобто він відчуває миттєвий відгук на дію, і чим швидше ви натискаєте, тим швидше він випускає кулі."
N/A3992"#commentary\cn_076_shatterglass.mp3" "[ Джош Вейєр ] Під час розробки ранніх рівнів, де в арсеналі гравця було менше механік, ми з’ясували, що не менш цікаво можна акцентувати увагу на нових технічних особливостях — як-от на склі, яке можна розбити. Для ефекту розтрощення скло поділили на сітку з маленьких квадратів. Це дозволяло відстежувати, які з них залишаються цілими, а які вже пошкоджені, і вибивати більші секції, коли достатня кількість квадратів втрачала з’єднання. Кожен квадрат рендерився з унікальною текстурою залежно від стану сусідніх, що створювало гострі й нерівні краї між розбитим і цілим склом. Хоча сьогодні розбивання скла стало звичним явищем в іграх, на час розробки Half-Life 2 ми бачили його нечасто й були неймовірно задоволені рівнем деталізації та динаміки, які воно додало грі."
N/A3993"#commentary\cn_077_lambda_caches.mp3" "[ Лора Дабак ] Формально перша лямбда-схованка була в лабораторії Кляйнера, але це перша, яку гравець знаходить самостійно. Ми додали лямбда-схованки, щоб заохотити дослідження та підказати гравцям місця прихованих ресурсів. За сюжетом, їх розміщував Опір у рамках свого підпільного повстання. У Half-Life вміст ящиків із припасами визначався наперед дизайном рівня. У Half-Life 2 ми ввели адаптивні ящики, які видають гравцеві саме ті ресурси, яких йому бракує в цей момент, залежно від цільових показників, установлених дизайнером рівня."
N/A3994"#commentary\cn_078_scanners.mp3" "[ Керрі Девіс ] Сканери стали непростим викликом для ігрового дизайну. Нам подобалося, як їхня присутність передавала антиутопічну атмосферу та підкреслювала, що Комбінація — це гнітюча держава нагляду, але ми не хотіли, щоб вони стріляли в гравця. Ми з’ясували, що стрілянина по маленькій рухливій цілі, яка завжди перебуває вище, зовсім не виглядала цікаво. Оскільки нам подобалася їхня роль у сюжеті, ми вирішили, що в бою сканери виконуватимуть насамперед функцію «очей», сповіщаючи найближчих ворогів про присутність гравця. Цю особливість ми підкріпили звуковими ефектами від солдатів. Окрім цього, сканери могли лише дошкуляти гравцеві яскравим світлом і час від часу кидатися в таран після того, як отримували достатньо шкоди."
N/A3995"#commentary\cn_079_surface_properties.mp3" "[ Аріель Діас ] Ми відтворюємо унікальні звуки кроків, коли гравець іде по слизькому бруду. Для цього було створено систему властивостей матеріалів, яка на основі типу поверхні визначала, які звуки та інші ефекти слід застосовувати під час ходьби чи пострілів по ній. На ранньому етапі розробки існував ефект, який уповільнював рух по бруду, але для релізної версії його прибрали, оскільки він виявився надто незручним для гравців."
N/A3996"#commentary\cn_080_combat_entrances.mp3" "[ Даріо Касалі ] Забігати за ріг у нову зону й одразу наштовхуватися на ворогів завжди незручно — це робить світ неживим і більше схожим на простий тир. Тому ми прагнули вводити ворогів у бойові локації цікавішими й динамічнішими способами, щоб показати, що їхні дії сплановані й осмислені, ніби солдати мали план щодо Ґордона ще до його появи. У цій сцені комбінанти стрибають униз у рамках скриптової послідовності, а далі в грі ми застосували й спуск на мотузках у схожому стилі. Насправді не має значення, звідки вони беруться, адже гравці все одно вибудовують цю історію у своїй уяві. Ми зрозуміли, що бойова сцена має містити натяк на сюжет: засідка, несподіваний напад, натиск, штурм — хоч у всіх цих випадках використовується майже однаковий ШІ, ворогів, для тестувальників вони відчувалися абсолютно по-різному."
N/A3997"#commentary\cn_081_mounted_gun_gallery.mp3" "[ Дейв Ріллер ] У цій сцені відбувається кілька речей: турель, що розстрілює ламкі ящики, показує гравцям, що не варто йти на загрозу в лоб — краще скористатися каналізацією, щоб вийти переможцем. Коли гравці нарешті дістаються до турелі, вони із задоволенням, як у тирі, відстрілюють з неї солдатів Комбінації та сканерів, що кидаються в пікірування. Тут ми також уперше знайомимо гравців із ракетним БТР Комбінації, який підштовхує їх уперед і згодом ще з’явиться в цій главі."
N/A3998"#commentary\cn_082_barnacle_bowling.mp3" "[ Джош Вейєр ] Це вдалий приклад того, як різні елементи дизайну можуть взаємодіяти між собою, створюючи яскравий момент для гравця. Ми маємо барнаклів, фізичну симуляцію, слизький бруд із власними властивостями і — останнє, але не менш важливе — вибухові бочки. Усе це ви вже зустрічали окремо, але разом вони природно поєднуються в сцену, яку ми назвали «боулінгом барнаклів»."
N/A3999"#commentary\cn_083_barnacle_introduction.mp3" "[ Майк Дюссо ] Оскільки барнакли при першій зустрічі можуть дезорієнтувати, ми хотіли показати їхню поведінку з безпечної відстані. Для цього ми зробили сцену в стилі природничого шоу — із демонстрацією хижака та його жертви. Але, як завжди, подібні сцени вимагали численних ітерацій, щоб гравці точно їх побачили."
N/A4000"#commentary\cn_084_physics_in_puzzles.mp3" "[ Ерік Сміт ] Часто простіші механіки, що з’являються у грі на початку, походять від складніших і використовуються як форма навчання. Головоломка з гойдалкою — перший у грі пристрій, заснований на фізиці, — фактично виникла з пізнішої, більш складної головоломки з пральною машиною в каналах. Для гойдалки застосовуються ті самі принципи маси та похилих площин, але у спрощеній формі: гравці можуть безпосередньо взаємодіяти з ними, що допомагає зрозуміти фізику гри та полегшує розв’язання наступних головоломок. Ця головоломка також підкреслює аналоговий характер системи фізики, адже у вирішенні завдання враховується як розташування цементних блоків, так і власна вага гравця."
N/A4001"#commentary\cn_085_combine_attack_helicopter.mp3" "[ Брайан Джейкобсон ] Гравці вже бачили його раніше, але саме тут ми повністю вводимо головного боса глави «Канали» — бойовий гелікоптер Комбінації. Він безжально знищує укриття гравця, змушуючи його постійно рухатися вперед, аби не бути розстріляним. Ми прагнули, щоб ця сцена відчувалася напруженою й загрозливою, щоб гелікоптер виглядав занадто потужним для прямої сутички, а відчуття небезпеки зберігалося протягом усієї подорожі каналами аж до фінальної битви у водосховищі. Щоб цього досягти, ми суттєво обмежили його рух відповідно до конкретних ігрових цілей. На цій карті, спроєктованій як ривок від укриття до укриття під вогнем гелікоптера, ми створили кільцевий маршрут у небі над ареною. Гелікоптер завжди прямує до найвіддаленішої від гравця точки цього кільця, залишаючись у полі зору та дозволяючи нам правильно розташувати укриття."
N/A4002"#commentary\cn_087_explosive_barrel_factory.mp3" "[ Девід Спейрер ] Це приміщення з неймовірною кількістю вибухових бочок, викликало жартівливі суперечки всередині команди про те, як далеко можна заходити в плані правдоподібності нашого світу. Якщо чесно, навіть одна бочка, що вибухає, — це вже занадто з точки зору реалізму, адже в реальному житті бочки не повинні вибухати, навіть якщо по них стріляти."
N/A4003"#commentary\cn_088_rising_water.mp3" "[ Забі Інґ ] Плавучий міст і дерев’яні котушки тут уперше знайомлять гравця з концепцією плавучості як інструментом. Це радше не головоломка, а просто розвага з фізичною системою, але пізніше ми повернемося до цього елемента в каналах, щоб підняти трамплін для аеробота."
N/A4004"#commentary\cn_089_manhack_matt.mp3" "[ Джон Морелло ] Ми назвали цього хлопця «Людорiз Метт». Ми хотіли створити у гравців відчуття, що у прихованих куточках Сіті-17 мешкають сотні громадян. На цьому етапі гри вже минуло чимало часу відтоді, як гравці бачили громадян, і ми прагнули показати важливість людорізів — перших створених нами ворогів із фізичною симуляцією. В оригінальній концепції в місті був зал гральних автоматів, де гравці могли літати на людорізах і атакувати віртуальних громадян. Згодом вони дізнавалися, що людорізи реальні, і громадяни також. Але коли образ окупації Комбінацією поступово набув завершеності, ідея із залом гральних автоматів видалася дивною й зрештою зійшла нанівець."
N/A4005"#commentary\cn_090_fighting_motion_sickness.mp3" "[ Девід Спейрер ] На ранніх ігрових тестах багатьох гравців заколисувало під час керування аероботом. Намагаючись виправити цю проблему, ми виявили кілька факторів, які до неї призводили. Допомагало, якщо аеробот займав менше місця на екрані, тому ми кілька разів переробляли модель. Важливо було також підтримувати стабільну частоту кадрів, тож у цих зонах пильно стежили за продуктивністю. Але найважливішим фактором було прибрати нахил камери, щоб горизонт залишався стабільним незалежно від руху аеробота. Один із програмістів команди був особливо схильний до заколисування й сміливо погодився проходити тест кілька разів, щоб оцінити наш прогрес. Я майже впевнений, що його бодай раз знудило після тестування, тож його шляхетна жертва була надзвичайно цінною."
N/A4006"#commentary\cn_091_headcrab_canisters.mp3" "[ Джефф Лейн ] Використані капсули з хедкрабами пізніше можна побачити в Рейвенхолмі, тож ми вирішили показати їх і тут, щоб розкрити, як Комбінація застосовує цю зброю. Він використав фауну Зену проти людей. Хедкраби, що зариваються в землю, були додані як новий елемент для цієї сцени, яку розширили до більшої площі, аби показати поселення громадян, знищене їхнім нападом."
N/A4007"#commentary\cn_092_airboat_intro.mp3" "[ Джон Морелло ] Тут гравець отримує перший транспортний засіб у грі — аеробот. Ми хотіли створити безпечний простір, де гравці могли тренуватися в керуванні аероботом стільки, скільки їм захочеться, перш ніж рухатися далі. Арена сповнена можливостей для стрибків і трюків, і ми заповнили її токсичним слизом, щоб утримати гравців у аероботі надовше й не дозволяти їм залишити його та просуватися вперед пішки."
N/A4008"#commentary\cn_093_zombie_surprise.mp3" "[ Джефф Лейн ] Ця сцена в каналізаційній трубі містить трохи зухвалий скример. Гравці забрідають сюди, зосереджені та зацікавлені, і тут на них вистрибує підводний зомбі, який майже завжди лякає тестувальників до чортиків. Один із них навіть упав зі стільця, тож ми відзначили цей момент як успішний."
N/A4009"#commentary\cn_094_airboat_time.mp3" "[ Дейв Ріллер ] Знайти баланс між часом на транспорті й часом пішки було непросто. На ранніх тестах ми зрозуміли: якщо дати гравцям мчати аероботом на повній швидкості, вони пролітають повз світ і просто не встигають його роздивитися. А оскільки дослідження оточення та занурення у світ є одними з основних цінностей Half-Life, ми не хотіли, щоб транспорт це нівелював. Тому ми додали періодичні зупинки, де гравці могли вийти й оглянути невеликі ділянки з великою кількістю деталей. Крім того, зі вдосконаленням системи фізики ми відкривали нові способи її використання. Такі зони поза аероботом дозволяли гравцям робити відкриття: наприклад, кидати ящики у воду чи поєднувати бочки, щоб підняти трамплін. Це давало гравцям можливість взаємодіяти з водою й фізикою по-новому, і, як результат, робило гру набагато живішою."
N/A4010"#commentary\cn_095_floating_supplies.mp3" "[ Джош Вейєр ] Під час альфа-тестів канали були буквально всіяні плавучими ящиками з припасами. Гравці розбивали їх аероботом і одразу отримували все потрібне. Так, виглядало це доволі ігрово, зате підтримувало ритм і дозволяло поповнювати запаси на ходу. Щоб надати цьому хоч якоїсь правдоподібності, ми вирішили показати, як саме ящики виявляються так зручно розташованими на шляху Ґордона. Сцена, де громадяни скидають їх униз, підсилює цю вигадку й водночас робить канали живішими. А ще — додає емоції: гравці відчувають себе значущими, коли стільки другорядних персонажів допомагають саме їм."
N/A4011"#commentary\cn_096_grenade_intro.mp3" "[ Брайан Джейкобсон ] Ми задумали цю базу Комбінації водночас як тренувальну зону й майданчик для експериментів із гранатами. Для цього ми розмістили тут нескінченні ящики з ними, щоб показати: гравці можуть вільно використовувати гранати, не боячись, що вони закінчаться. Відривайтеся на повну. У цій сутичці ми застосували розмітку, яка спрямовує солдатів під керуванням ШІ до укриттів і створює хороші умови для використання гранат. Наприкінці зони той самий прийом з нескінченними гранатами допомагає гравцям упоратися з туреллю, адже прямий штурм був би значно складнішим. Ми також додали гранатам яскраве червоне світло й частинковий слід, щоб гравцям було легше відстежувати їхню траєкторію — як власних кидків, так і гранат солдатів Комбінації."
N/A4012"#commentary\cn_097_puzzle_layers.mp3" "[ Дейв Ріллер ] Оскільки гравці часто зовсім не усвідомлюють задуму дизайнера (що, на нашу думку, добре), вони реагують на головоломки найнесподіванішим чином. Навіть прості завдання можуть спричиняти безліч невдалих спроб на шляху до правильного рішення. Так було й із цією головоломкою зі шлюзовими воротами, для якої знадобилося чимало підказок. Іскристе колесо підказувало, що саме тут зазвичай відкривають ворота, але потрібно знайти інший спосіб. Кілька ворон спрямовували погляд гравця до в’язки балок на маятнику. Спершу ми хотіли, щоб гравці кидали гранату й руйнували дерев’яну опору, але це виявилося неочевидним, тож ми додали вибухові бочки як значно чіткіший натяк. Однак навіть після розв’язання головоломки деякі гравці не розуміли, що ворота вже відчинені, й нескінченно нишпорили базою в пошуках іншого виходу. Тому довелося нагадати їм про початкову проблему — зламані ворота. Ми додали дим, сирену й обертовий маячок, і лише тоді на ігрових тестах почали отримувати стабільно хороші результати."
N/A4013"#commentary\cn_098_metrocop_strafing.mp3" "[ Даг Вуд ] Початковий дизайн рівнів із аероботом мав на меті випробувати гравців складними маневрами під вогнем комбінантів. Їхня схема стрільби була розрахована так, щоб змушувати гравців лавірувати між кулями, несучись уперед. Але під час нашого внутрішнього процесу перегляду, відомого як «Нагляд», деякі тестувальники відчували роздратування: по них стріляли, а відповісти було нічим. Вони хотіли, щоб аеробот відчувався потужним і нестримним. Врахувавши цей зворотний зв’язок, ми змістили акцент із ухилення від атак на відчуття сили: швидкісний бій, прорив крізь бар’єри й динаміку, що дає потрібний драйв."
N/A4014"#commentary\cn_100_mounted_gun.mp3" "[ Джефф Лейн ] Стаціонарні кулемети були додані тут, щоб навчити гравця їхній ефективності проти бойового гелікоптера в фінальній битві на водосховищі. Це було необхідно, адже до цього моменту гелікоптер залишався невразливим для зброї гравця, і потрібно було дати зрозуміти, що його можна пошкодити потужнішими засобами. Під час ігрових тестів кулемет виявлявся лише частково ефективним через тиск, якого гравець зазнавав у цей момент, тож ми розробили додаткові ефекти частинок та звукові сигнали, щоб переконливо показати, що гелікоптер дійсно отримує шкоду."
N/A4015"#commentary\cn_101_357_intro.mp3" "[ Джош Вейєр ] «Магнум», на відміну від базового пістолета з нижчою скорострільністю, призначений для більш виваженого, прицільного вогню, завдаючи цілі катастрофічної шкоди. У ранніх версіях «Магнума» було закладене випадкове розсіювання куль, що, як нам здавалося, відповідало його вазі й менш чутливому спусковому гачку. Проте це призводило до розчарувань, коли гравці ретельно прицілювалися, але промахувалися через штраф до точності. Щоб виправити це, ми зробили перший постріл ідеально точним, а кожен наступний ставав менш влучним, поки ви продовжували безперервно стріляти."
N/A4016"#commentary\cn_102_helicopter_bombing_run.mp3" "[ Брайан Джейкобсон ] Це ще один приклад створених нами перешкод для руху під час керування аероботом. Гелікоптер намагається триматися попереду гравця, скидаючи бомби, а якщо той відступає назад — зависає й починає атакувати. Під час одного з тестів бомба випадково впала між стиками труб, створивши доволі кінематографічний момент. Тестувальник відреагував дуже позитивно, тож команда вирішила зробити так, щоб це відбувалося щоразу за скриптом. Такий підхід став частиною нашого органічного процесу дизайну: іноді під час тестів випадково трапляється щось круте, і ми шукаємо спосіб зробити так, щоб воно відбувалося постійно."
N/A4017"#commentary\cn_103_smokestack_collapse.mp3" "[ Даг Вуд ] Працюючи над кінематографічним екшеном на кшталт першого Half-Life, ми завжди хотіли створити великі видовищні сцени руйнування, але тоді це було неможливо реалізувати. Фізика Half-Life 2 запровадила систему розбиття невеликих об’єктів, як-от ящиків, на шматки, і це підштовхнуло нас до ідеї зробити щось значно масштабніше. Ми ризикнули й спробували розбити на шматки падаючий димар. Ми експериментували з масами, поки не отримали потрібний результат, вдосконалили модель і додали багато диму та звукових ефектів — і ось вона, наша перша велика й видовищна сцена руйнування. Зрештою, наша фізика дозволила зробити її лише на межі можливого — у спосіб, який, можливо, виглядає наївно за сучасними мірками, але тоді був по-справжньому вражаючим. Оскільки симуляція щоразу була унікальною, ми мали подбати, щоб великі уламки не перекривали гравцеві шлях. Успіх цієї сцени тільки розпалив наш апетит до ще реалістичніших ефектів руйнування, які з’явилися вже в Episode Two."
N/A4018"#commentary\cn_104_washing_machine_puzzle.mp3" "[ Девід Спейрер ] Ми створили фізичну головоломку з пральною машиною на пізньому етапі розробки, після того як тести показали: гравцям потрібна пауза від безперервного тиску гелікоптера. Контраст у темпі дозволяв підкреслити кульмінаційні моменти, «обнуляючи» емоційний стан гравця та запобігаючи виснаженню чи нудьзі. Те, що гравці сильно реагували на загрозу від гелікоптера було позитивним знаком, але без контролю рівня стресу напруга швидко перетворювалась на монотонність. Спершу гравці просто швидко проїжджали через цю ділянку, але завдяки приємному сонячному світлу й структурі каналу ми вирішили зробити тут паузу та дати можливість гравцеві трохи часу, щоб спокійно розв’язати задачу. Це була перша головоломка з використанням маси й блоків, і саме вона дала поштовх для появи інших фізичних задач у грі. "
N/A4019"#commentary\cn_105_airboat_changeup.mp3" "[ Джефф Лейн ] За відгуками тестувальників, їм бракувало різноманітності під управління аероботом. До того моменту гравець практично не міг протистояти гелікоптеру та іншим ворогам, тому ми вирішили ввести нову зброю — це одночасно змінило темп гри й послужило підготовкою для подальших подій. У наступних зонах ми додали стрільбище, щоб ознайомити людей із гарматою. Завдяки підсиленій фізиці снарядів цілі відлітали далеко, і тому ця зброя відчувалася значно потужнішою за все інше в арсеналі гравця. Під час тестів бою проти гелікоптера багато хто вважав його невразливим. Ці гравці не помітили наших спроб показати, що гелікоптер зазнає ушкоджень від стаціонарних кулеметів Комбінації. Тож ми зробили найпростіше й найочевидніше: розмістили гелікоптер прямо за тунелем, де гравець отримує гармату, і явно дали зрозуміти, що його можна й треба обстрілювати. Це спрацювало."
N/A4020"#commentary\cn_106_donkey_kong_barrel_ramp.mp3" "[ Ерік Сміт ] Цей дренажний схил спершу був просто цікавим елементом архітектури рівня. Але під час тестування ми швидко помітили, як весело гравцям ковзати на аероботі цим схилом, тому додали більше деталей, щоб підсилити цей досвід. Серед іншого — комбінантів, які скочували бочки на гравця, що стало відсиланням до класичної аркадної гри Donkey Kong."
N/A4021"#commentary\cn_107_lambda_cache_interlude.mp3" "[ Даніка Роджерс ] Гра серії Half-Life по суті лінійна, але ми завжди шукаємо способи урізноманітнити шлях гравця й додати трохи нелінійності на рівні локації. Цю абсолютно необов’язкову схованку з лямбдою, яка обертається на засідку зомбі та хедкрабів, було створено лише для того, щоб додати більше варіативності проходженню цієї частини каналів."
N/A4022"#commentary\cn_108_skybox_time_of_day.mp3" "[ Ерік Кіршмер ] Колір скайбоксу й туману протягом цієї глави поступово змінюється, щоб візуально передати плин часу, поки гравець рухається каналами й просувається сюжетом. Два значення кольору туману в протилежних напрямках допомагають створити ілюзію косого кута падіння сонячних променів. На цьому етапі вже видно, що сонце наближається до заходу. Кульмінацією стає арена бою з гелікоптером, де сонце сідає, а в скайбоксі видно Рейвенхолм."
N/A4023"#commentary\cn_109_helicopter_megabomb_origin.mp3" "[ Брайан Джейкобсон ] Наліт гелікоптера з мегабомбами з’явився через баг: один із програмістів випадково прибрав затримку між скиданнями бомб, і гелікоптер почав скидати сотні бомб одночасно. Це виглядало так круто, що ми вирішили залишити цей ефект для фінальної бомбардувальної атаки."
N/A4024"#commentary\cn_110_helicopter_final_battle.mp3" "[ Дейв Ріллер ] Ми спроєктували цю зону як арену для фінального протистояння між гравцем і бойовим гелікоптером Комбінації. Це шанс для гравця остаточно знищити безжального ворога, який переслідував його відтоді, як він подався в підземелля після виходу з лабораторії Кляйнера. Ця зона пройшла багато ітерацій, перш ніж ми досягли ідеального результату. Потрібно було забезпечити достатньо простору для динамічного бою на транспорті, плавний рух із чіткими варіантами вибору шляху та стабільну продуктивність. Ми також прагнули до візуальної чіткості, придатної для бою: ефектної, але не перевантаженої деталями. Водночас важливо було створити на цій локації незабутній краєвид, коли гелікоптер буде знищено."
N/A4025"#commentary\cn_111_airboat_wreckage.mp3" "[ Девід Спейрер ] Спочатку ми знищували аеробот під час стрибка через греблю, тож цей рівень починався для гравця серед уламків його улюбленого транспорту. Але під час командного тестування багато хто висловив розчарування через втрату машини, на якій було проведено стільки часу. Усередині команди точилися довгі суперечки, чи варте це відчуття втрати того, щоб залишити його у грі. Зрештою ми вирішили зберегти аеробот цілим, аби гравець міг одного дня знову зустрітися з ним. Кажуть, він досі десь там чекає на вас."
N/A4026"#commentary\cn_112_arena_exit_gate.mp3" "[ Квінтін Дорокес ] Колісний механізм для підняття воріт ми додали спеціально, щоб змусити гравця знищити гелікоптер, перш ніж він зможе рухатися далі. Подібні елементи ми називаємо «воротами» для гравця — вони не дозволяють просуватися вперед, доки не буде виконано необхідне завдання. І в цьому випадку це буквально ворота."
N/A4027"#commentary\cn_113_blocking_tutorials.mp3" "[ Адріан Фінол ] Іноді потрібно переконатися, що гравець чогось навчився. У розробці ігор стандартний метод для цього — залишити його за «воротами», де, щоб пройти далі, він має продемонструвати нове вміння. Ми намагаємося маскувати такі ворота під природні елементи, аби не створювалося враження, ніби гра просто зупинилася. Звісно, час, ресурси чи сам контекст оточення можуть ускладнити це завдання. У цьому випадку нам потрібно було навчити гравців рухати предмети, тож ми використали просту головоломку зі складанням їх один на одного. Складніші варіанти ми теж тестували, але вони виявилися менш ефективними для навчання саме того, що нам було потрібно."
N/A4028"#commentary\cn_114_natural_storytelling.mp3" "[ Білл Ван Бюрен ] Щоб досягти наших цілей у побудові світу й оповіді на вокзалі, нам був потрібен природний спосіб подачі діалогів — такий, що не виглядав би надто «ігровим» і не потребував навчальних вставок. Ми помітили, що гравці часто підходять до NPC, аби роздивитися їх ближче, і використали це як можливість: NPC реагували на присутність гравця та вимовляли свої репліки. Такий підхід робив взаємодію ненав’язливою, що було особливо важливо, адже громадяни тут не виглядали ані веселими, ані жвавими. Простота цього рішення також відповідала одній із ключових цілей оповіді Half-Life — зробити сюжет чутливим до зацікавленості гравця. Одні хочуть зануритися в усі деталі, іншим достатньо лише знати, куди йти далі. Даючи гравцеві контроль над тим, наскільки вони залучені до історії, і водночас не блокуючи прогрес, ми досягаємо важливої для Half-Life мети. До того ж, чим простіша у реалізації функція, тим більше її варіацій можна додати в гру."
N/A4029"#commentary\cn_115_trainstation.mp3" "[ Чарлі Браун ] Початок гри Half-Life має надважливе завдання: ми повинні познайомити гравців із новим світом і водночас навчити їх взаємодіяти з ним. Гравці мають швидко зрозуміти, що відбувається, хто ключові персонажі, які загрози чекають попереду та яке місце в цьому всьому займають вони. І понад усе — гра повинна бути захопливою та максимально інтерактивною. Щоб досягти цього, потрібні численні ітерації та ігрові тести, особливо в роботі над дрібними моментами, з яких складається загальна картина. У цьому розділі ми зупинимося на кількох ключових моментах, проблемах ігрового дизайну та деяких тестах, де все пішло не зовсім за планом."
N/A4030"#commentary\cn_116_physics_objects.mp3" "[ Девід Сойєр ] Зараз у це важко повірити, але коли виходила Half-Life 2, дрібні об’єкти в іграх — такі, як ці шматки сміття — зазвичай були статичними. Вони або зовсім не рухалися, або робили це дуже примітивно. У кращому разі після удару вони могли розсипатися на кілька спрайтів. Одним із завдань цієї початкової сцени на вокзалі було чітко показати гравцям, що в Half-Life 2 такі речі насправді фізично моделюються. Їх можна піднімати, кидати, ламати, переміщати іншим чином — що завгодно. Тут ми починаємо з дрібниці: сміття розлітається від прибуття потяга, точніше — від невидимого об’єму, що спрацьовує, коли гравець виходить із вагона."
N/A4031"#commentary\cn_117_blocking_tutorials_3.mp3" "[ Ерік Сміт ] Другий недолік цього навчального простору — так зване «неправильне навчання», коли ми випадково навчаємо гравця того, чого не планували. Уникнути цього без ретельного ігрового тестування важко, адже гра постійно щось демонструє, навіть якщо це не було задумано. Яскравіший приклад ми розглянемо далі, на вокзалі. Деякі випадки неправильного навчання критично важливо виправляти: наприклад, якщо гравець засвоює неправильний спосіб користування зброєю чи взаємодії з поширеним ігровим елементом. Але цього разу все було більш делікатно. Навчаючи гравців рухати предмети, ми ненароком підказали їм складати фізичні об’єкти один на одного, щоб вибратися звідкись. Зазвичай у цьому немає нічого поганого, але подібні головоломки далі в грі не застосовуються. У результаті гравці вчилися чомусь зайвому, що тільки засмічувало їхній «ментальний інструментарій» і відволікало від запам’ятовування корисних речей. Ще гірше, що складання предметів для втечі з ігрового простору згодом стало реальною проблемою, якій довелося активно запобігати в кількох місцях. Із такою кількістю фізичних об’єктів у грі заблокувати цю поведінку без тотального накриття локацій стелями було просто неможливо. Тож ми сподівалися, що гравці не надто зацикляться на уроці, вивченому на ранніх етапах, а коли під час тестів вони все ж десь застрягали, ми старалися не нагадувати їм про нього."
N/A4032"#commentary\cn_118_welcome.mp3" "[ Ґейб Ньюелл ] Я Ґейб Ньюелл. Знову ласкаво просимо до Half-Life 2. Минуло вже двадцять років від моменту виходу гри. У цьому ювілейному оновленні ми постаралися врахувати якомога більше побажань спільноти. І хоча це, можливо, було не найголовнішим запитом від фанатів, я часто чую, що людям дуже хотілося б мати режим коментарів, тож ми раді нарешті зробити його доступним. Було непросто згадати безліч деталей розробки Half-Life 2, а ще важче — розбиратися з кодом, якому вже десятиліття, й намагатися зрозуміти, що ж ви тоді, чорт забирай, мали на думці. Окрім додавання коментарів розробників, ми виправили чимало старих помилок і постаралися залишити все у кращому стані, ніж воно було до нас. Принаймні цього разу нам пощастило знати, чим усе закінчилося. Щоб прослухати коментар, наведіть курсор на значок коментарів і натисніть клавішу «Використати». Щоб зупинити коментарі, наведіть курсор на значок, що обертається й знову натисніть «Використати». Будь ласка, дайте знати, що ви про думаєте. Зв’язатися зі мною можна, написавши на gaben@valvesoftware.com. Дякую і приємної гри!"
N/A4033"#commentary\cn_119_metrocop_shoving_citizens.mp3" "[ Джош Вейєр ] Ми пройшли лише кілька кроків — і вже є проблеми, які треба вирішувати. Тут ми знайомимо гравців із комбінантом — ворогом, якого згодом доведеться вбити, — і водночас даємо уявлення про світ, у який вони потрапили. Це простий і зрозумілий момент, що показує стосунки між комбінантами та громадянами, а через них — і з самим гравцем. Паралельно ми підкреслюємо існування базової фізичної симуляції, демонструючи, як NPC можуть невимушено взаємодіяти з об’єктами навколо. Наприклад, побачити, як одна валіза стикається з іншою тоді було доволі новаторським. Саме такі моменти на вокзалі, де ми комбінували кілька цілей, були найвдалішими: вони виглядали природно, і гра не зупинялася лише для того, щоб щось пояснити."
N/A4034"#commentary\cn_120_fall_damage.mp3" "[ Керрі Девіс ] Навчати гравців тому, як щось робити, — надзвичайно важливо для цієї гри. Але щоб вони могли впевнено приймати рішення, їм також потрібно розуміти більш тонкі правила. Цей невеликий момент охоплює два з них. По-перше, він показує, з якої висоти гравець може впасти без шкоди для себе. По-друге, він вводить «словник» гри — спосіб, яким вона спілкуватиметься з ним. Гравці часто бояться отримати шкоду від падіння, а ще більше зробити крок, після якого вже не буде шляху назад. Тому вдало розташований ящик, на який можна приземлитися, сигналізує, що стрибати вниз безпечно і саме так треба рухатися далі. А коли ящик розбивається, це підкреслює роботу фізичної симуляції та, ймовірно, вперше демонструє гравцям, що можна ламати й великі об’єкти."
N/A4035"#commentary\cn_121_sweeping_vortigaunt.mp3" "[ Лора Дабак ] Ще один ключовий момент оповіді — і ще одна демонстрація фізичної системи. Тут ми показуємо, яке місце займають вортіґонти в новому світі, що кардинально відрізняється від їхньої ролі ворогів у Half-Life 1. Як і багато моментів на вокзалі, вортіґонт зі шваброю з’явився завдяки нашому постійному пошуку способів показати, як персонажі можуть природно взаємодіяти з фізикою. Навіщо просто казати гравцям, що вортіґонти тепер доброзичливі, якщо можна показати одного з них, який невимушено підмітає підлогу й зачіпає симульовані об’єкти? Ніщо так явно не сигналізує: «Гей, цього разу не стріляй у мене», як істота, що спокійно займається прибиранням."
N/A4036"#commentary\cn_122_blocking_tutorials_2.mp3" "[ Робін Вокер ] У цьому навчанні є два помітні недоліки. По-перше, гравці можуть усе зламати, викинувши всі ящики у вікно, що, вочевидь, недобре. Тоді вони застрягають, не маючи змоги продовжити. Це ми розглядали як критичний баг, який зупиняє гру й обов’язково потребує виправлення. Ідеальним рішенням було б підкоригувати розміри вікна чи ящиків так, щоб гравець міг туди пролізти, а ящики — ні. Проблема в тому, що ми помітили це вже на пізньому етапі розробки, і внесення навіть такої простої зміни могло мати непередбачувані наслідки, здатні поламати гру — та ще й прямо перед релізом. До того ж ця проблема залишалася суто теоретичною. Ми жодного разу не бачили, щоб тестувальники справді так робили. Наші тести в цій зоні проходили гладко: гравці засвоювали потрібний урок і рухалися далі. Тому змінювати дизайн приміщення так пізно ми не ризикнули й обрали більш консервативне, хоч і менш елегантне рішення. Якщо цікаво — спробуйте самі викинути всі ящики з вікна та подивіться, що буде."
N/A4037"#commentary\cn_123_playground.mp3" "[ Брайан Джейкобсон ] Коли ми шукали способи продемонструвати симуляцію фізики в міському середовищі, дитячий майданчик здався нам природним вибором. А для тих, гравців, які звертали увагу на слова доктора Бріна, це ще й нагадування про ціну, яку заплатило людство за капітуляцію перед Комбінацією. Ми обрали кілька майданчиків із цікавим фізичним потенціалом і почали їх налаштовувати. Навіть із тодішньою просунутою системою фізики такі сцени завжди потребували тонкого ручного доопрацювання, адже повністю симульовані об’єкти взаємодіяли з несимульованими або частково симульованими, як-от гравець чи статична геометрія світу. Легко припустити, що симуляція може «витягнути» більшу частину роботи, але навіть зараз, через двадцять років, це рідко буває так. Працюючи над майданчиком на пізньому етапі розробки, ми ніяк не могли підібрати правильний коефіцієнт тертя для гірки, тож просто поламали драбину, аби гравець не міг піднятися нагору. Але все одно можна просто пройти спереду. Як це часто буває — сміється останнім гравець, а не ми."
N/A4038"#commentary\cn_124_pick_up_that_can.mp3" "[ Чарлі Браун ] Контекстуалізація навчання — створення сюжетної ситуації, в якій воно відбувається, — дозволяє робити більше, ніж просто зупиняти гру, щоб показати гравцеві нову дію. Такі моменти набувають оповідальної цінності. Тут навчання кидати предмети поєднане з історією, яка дає гравцеві вибір у тому, як відреагувати. Після того як гравець бачить як комбінанти мимохідь жорстоко знущаються з громадян, природно поставити його самого в схожу ситуацію. Якщо у гравця були думки щодо того, як мали б відреагувати громадяни, тепер він може їх продемонструвати. Тести показали, що більшість гравців або підкорялися наказу підняти банку, або відмовлялися це робити. Дехто намагався уникнути конфронтації взагалі. Інші спершу підкорялися, а потім, відчувши себе приниженими, мстилися. Завдяки тому, що сцена була відносно обмежена і за простором, і за можливостями дій гравця, ми могли в цілому адекватно реагувати майже на будь-який варіант поведінки."
N/A4039"#commentary\cn_125_promises.mp3" "[ Даніка Роджерс ] На початку будь-якої гри серії Half-Life одна з наших цілей — це дати гравцю певні обіцянки, щоб він зрозумів, чого очікувати далі. Це характерно для всієї індустрії розваг — від фільмів до серіалів і книг — і відеоігри не виняток. Такі обіцянки можуть мати різні форми. Деякі прості: це може бути лише натяк на щось інтригуюче. Інші — багатошарові, як, наприклад, взаємодії з комбінантами. Ставлячи гравця в безпорадне становище проти них, ми закладаємо основу для майбутнього моменту, коли він нарешті зможе відповісти."
N/A4040"#commentary\cn_126_exploration.mp3" "[ Девід Сойєр ] Після того як комбінанти проганяють гравця через вокзал, ми хотіли дати йому можливість дослідити місто. На цій площі було кілька способів взаємодіяти з громадянами, комбінантами, сканерами та міською інфраструктурою. Ми прагнули, щоб ці взаємодії розвивали світ гри без потреби у прямому навчанні, і вдосконалювали їх доти, доки вони не почали працювати природно."
N/A4041"#commentary\cn_127_early_game_exploration.mp3" "[ Девід Спейрер ] До цієї площі гравцеві майже не доводилося замислюватися, куди йти: шлях був очевидним і прямим. Але ми хотіли заохотити дослідження, зробивши подальший напрям менш очевидним. Це могло викликати відчуття загубленості або навіть сум’яття — і це очікувано. Подібні зміни особливо складні на початку гри, коли гравець ще тільки вчиться зчитувати підказки. Ситуацію ускладнювали й контрольно-пропускні пункти з силовими полями: громадяни-NPC проходили крізь них вільно, тоді як гравець — ні. Через це багато тестувальників думали, що є спосіб їх обійти. Зрештою саме численні тести допомогли нам підібрати правильний рівень помітності для провулку далі: освітлення, планування й дерев’яний ящик — об’єкт, який гравці вже сприймали як знак правильного шляху, — усе це разом тонко підштовхувало їх уперед."
N/A4042"#commentary\cn_128_strider.mp3" "[ Даг Вуд ] Цей простий момент — це обіцянка, що пізніше у грі ви зустрінетеся з цією гігантською істотою. Навіть така нескладна сцена вимагала безлічі тестів та ітерацій, адже в Half-Life важливо ніколи не відбирати у гравця контроль. Потрібно було безліч дрібних налаштувань, щоб якомога більше гравців дивилися в потрібне місце у потрібний час. Планування вулиць і сцена з комбінантом були спеціально побудовані так, щоб спрямувати погляд гравця й ідеально обрамити появу страйдера."
N/A4043"#commentary\cn_129_physics_simulation.mp3" "[ Джей Стеллі ] Хоч ми й почали роботу над Half-Life 2 з функціональною сторонньою симуляцією фізики, нам усе одно знадобилися роки додаткової праці як над самою симуляцією, так і над її інтеграцією в гру, перш ніж ми змогли відповідати амбіціям наших дизайнерів. Підтримка придатного для релізу рівня якості та продуктивності була викликом, якого ми очікували, але тоншою проблемою стало визначити, що саме варто симулювати й у якій мірі. Ми не можемо симулювати все, та й навіть якби могли, з точки зору дизайну гри досвід часто кращий, коли цього не робити. У багатьох випадках ми свідомо «підкручуємо» симуляцію, щоб покращити досвід гравця. Такі коригування зазвичай залишаються непоміченими, бо збігаються з його намірами. Наприклад, ми відключали зіткнення між гравцем і великими об’єктами, щоб дозволити йому розвертатися у вузьких просторах. Або налаштовували альтернативний вогонь гвинтівки Комбінації так, щоб кулі трохи «тягнуло» в бік ворогів, роблячи її ефективнішою."
N/A4044"#commentary\cn_130_physics_simulation_2.mp3" "[ Джефф Лейн ] Локації, де ігровий дизайн або інші обмеження впливали на фізичну симуляцію, часто вимагали додаткового налагодження, щоб вона не «ламалася». Наприклад, на ранньому етапі ми експериментували з посиленням симуляції для гравця, тобто робили його рух більш інтегрованим у фізику світу. Ми знали, що це може знизити точність руху, але сподівалися отримати новий і цікавий досвід. Однак після налаштування руху під цю більш симульовану версію, виникла серйозна проблема: фізична сила, потрібна для того, щоб гравець рухався зі звичною швидкістю, була настільки великою, що просте зіткнення з іншими симульованими об’єктами могло вбити гравця від удару. Ми експериментували з цим багато разів, але зрештою не знайшли задовільного рішення й повернулися до менш симульованого руху. Це, утім, теж не стало простішим варіантом — з’явилися нові труднощі у взаємодії менш симульованого гравця з більш симульованими об’єктами. Проте саме це дозволило нам забезпечити той рівень точності руху, який ми хотіли."
N/A4045"#commentary\cn_131_playtesting.mp3" "[ Джон Морелло ] Ігрове тестування — ключова частина нашого процесу створення ігор. Ми ніколи не можемо повністю передбачити, як гравці відреагують або що вони винесуть із того, що ми створили. Тому ми тестуємо, щоб навчатися й покращувати гру. Під час тесту ми не підказуємо гравцеві й не розмовляємо з ним, навіть якщо він застряг, адже вкрай малоймовірно, що після релізу хтось із нас сидітиме поруч і допомагатиме. Наша мета полягає в тому, щоб тестувальники взагалі забули, що вони приймають участь у тестуванні, й грали так, ніби вони вдома. Будь-яке втручання ризикує спотворити дані, тому ми втручаємося лише у випадку бага, який блокує прогрес, або ж, що буває рідше, якщо поведінка гравця настільки незрозуміла, що нам треба з’ясувати, про що він думає."
N/A4046"#commentary\cn_132_playtesting_anecdote_1.mp3" "[ Метт Бун ] Один пам’ятний ігровий тест нагадав нам, що ніколи не можна бути впевненими в тому, про що думають гравці або які висновки вони роблять зі свого досвіду. Один тестер, пройшовши гру з початку й застрягши біля дверей, кілька хвилин перемикався між грою та налаштуваннями клавіатури. Коли ми спитали, що він шукає, той відповів, що намагається знайти управління інвентарем — він думав, що треба використати підібраний раніше предмет, щоб відчинити двері. Ми бачили, як він збирав і кидав фізичні об’єкти, але він неправильно зрозумів, що відбувається. Тестер вважав, що натискання клавіші «Використати» під час утримання предмета переміщує його в інвентар, бо після цього предмет падав прямо вниз. Ми знали, що це просто гравітація, але його припущення не було безглуздим — у деяких пригодницьких іграх того часу предмети справді потрапляли до невидимого інвентарю таким чином. Ми пояснили, що ніякого інвентарю немає, і тест продовжився. Пізніше ми замислилися, чи варто зайнятися цим питанням, але оскільки жоден інший тестувальник не мав подібної плутанини, а всі наші потенційні рішення виглядали надто громіздкими, ми вирішили, що це виняток, який можна залишити без уваги. Та все ж це стало хорошим нагадуванням, як навіть найдрібніші проігноровані деталі можуть збити гравця з пантелику."
N/A4047"#commentary\cn_133_cratebaby.mp3" "[ Скотт Далтон ] Ця маленька лялька має довгу історію. Під час багатомісячного внутрішнього тестування деякі члени команди вигадали собі випробування — спосіб зробити 47-е проходження гри трохи веселішим. Вони клали ляльку в синій ящик поблизу й дивилися, як далеко зможуть пронести її протягом усієї гри. Після виходу Half-Life 2 гравці спільноти теж підхопили цю ідею, додаючи власні правила й історії. Кілька років потому, під час роботи над Episode Two, це надихнуло нас на створення досягнення «Маленький космонавт», де гравці мали пронести садового гнома на ім’я Чомпскі через увесь епізод. Чомпскі навіть повернувся у Left 4 Dead 2 у досягненні «Охороняй гнома», де його потрібно було пронести через кампанію «Похмурий карнавал». Такі взаємодії з гравцями — одні з найприємніших моментів у розробці ігор. Ми створюємо їх, керуючись теоріями, але ніколи не знаємо напевно, до чого це приведе, доки гра не потрапить до рук гравців."
N/A4048"#commentary\cn_134_the_citadel.mp3" "[ Ерік Кіршмер ] Ми хотіли, щоб перший погляд гравця на Сіті-17 одразу виділяв Цитадель і її домінування над містом, символізуючи повну владу Комбінації над людством. Водночас вона мала служити чіткою метою — навіть на початку гри ви вже бачите, де закінчиться ваша подорож. Але попри її колосальний розмір, тестувальники часто її ігнорували. Відчуття глибини й масштабу на комп’ютерному моніторі — штука підступна. Якщо ви грали у VR, то знаєте, що там масштаб сприймається значно природніше. До того ж розташування Цитаделі прямо над гравцем теж не допомагало — можливо тому, що шутери від першої особи привчають дивитися або прямо перед собою, або вниз, під ноги. Щоб підвищити шанси, що гравці звернуть увагу на Цитадель, ми додали птахів, які летять у її бік — тонкий прийом, який, як ми з’ясували, добре працює для спрямування погляду гравця."
N/A4049"#commentary\cn_135_close_captions.mp3" "[ Ян Берньє ] Під час розробки Half-Life 2 до нас звернулися люди, зацікавлені в доступності для людей із вадами зору, й закликали нас вийти за межі системи субтитрів, яку ми створили для Half-Life 1. Вони просили повноцінну систему закритих субтитрів, яка охоплювала б усі ігрові звуки, а не тільки діалоги. Це виявилося значно складнішим завданням, ніж ми думали. Half-Life 2 генерувала величезну кількість звуків, і дуже важливо було правильно їх категоризувати. Не менш важливою була й пріоритизація: діалоги мали виділятися, і потрібно було чітко вказувати, хто саме говорить. Звуки оточення, на кшталт віддаленого бою, були важливі для створення атмосфери на деяких рівнях, але втрачали значення, якщо ворог стріляв десь поруч. До того ж наші дизайнери рівнів часто повторно використовували одні й ті самі звуки в різних контекстах, тож в одному місці вони потребували субтитрування, а в іншому — ні. У результаті кожен звук у грі отримав власні дані субтитрів, відформатовані майже як маленький HTML-документ, що дало нам змогу контролювати стиль відображення кожного рядка. І як у випадку зі звуковими файлами, обсяг цих даних був надто великим, щоб зберігати все в пам’яті, тож ми створили асинхронну систему кешування для їхньої ефективної обробки."
N/A4050"#commentary\cn_136_the_raid.mp3" "[ Девід Сойєр ] Для наступної сцени, де комбінанти вривалися в квартиру, поки гравець перебував усередині, знадобилося багато ітерацій, аби досягти потрібного результату. Зазвичай ми проєктуємо Half-Life так, щоб гравці могли задавати власний темп, адже кожен просувається грою по-різному: хтось мчить уперед, ігноруючи все, що не виглядає загрозою, а хтось методично досліджує кожну дрібницю. Тому коли нам потрібно нав’язати певний ритм, завжди складно зробити так, щоб гравці його відчули й природно підлаштувалися під нього. Оскільки це був перший випадок, коли ми застосували такий підхід, довелося докласти чимало зусиль, щоб дати гравцеві зрозуміти: тут треба рухатися швидко, і часу на дослідження немає."
N/A4051"#commentary\cn_137_materials_and_shaders.mp3" "[ Ґері Мактаґґарт ] Half-Life 2 вийшла в розпал значного зсуву в 3D-графіці, коли індустрія переходила від текстур до матеріалів і шейдерів. У Half-Life 1 кожна поверхня мала текстуру — по суті, зображення, накладене на полігони поверхні. Але вже в Half-Life 2, лише через п’ять років, кожна поверхня мала і матеріал, і шейдер. Шейдер — це фрагмент коду, який визначав спосіб відтворення поверхні. Матеріал задавав властивості того, як поверхня поводиться фізично та як реагує на елементи ігрового процесу. Він також містив посилання на текстури й інші параметри, які шейдер використовував під час відтворення. Завдяки цьому художники й дизайнери отримали значно більший контроль над виглядом і поведінкою об’єктів. Утім, це мало свою ціну: Half-Life 1 могла працювати на комп’ютері лише з центральним процесором, тоді як Half-Life 2 уже вимагала графічного процесора, адже потрібні для матеріалів і шейдерів обчислення були спеціально розроблені під таке обладнання. Скляні двері з ефектом заломлення — яскравий приклад спеціального шейдера, але насправді кожна поверхня в цій сцені відтворюється за допомогою свого шейдера."
N/A4052"#commentary\cn_138_the_raid_2.mp3" "[ Майлз Естес ] Окрім того, щоб гравець відчував тиск і був змушений рухатися вперед, ми мали переконатися, що саме вторгнення відбувається без збоїв. У гравця не повинно було бути жодної можливості уникнути його чи повернутися назад повз комбінантів. Справжня складність полягала не в тому, що гравці намагатимуться «зламати» сцену, а в тому, що багато хто запанікує й побіжить у випадкових напрямках, щойно зрозуміє, що вперше перебуває під реальною загрозою. Цей момент вимагав тонкого балансу: ми хотіли створити втечу, від якої серце вискакує з грудей, дати відчуття справжньої небезпеки, але водночас, щоб гравець проходив сцену з першої спроби й відчував, ніби врятувався дивом. Щоб досягти цього, ми зробили шлях уперед зрозумілим і схожим на той, яким гравець щойно рухався попереднім поверхом. Серія ретельно розміщених тригерів контролює загрози попереду й позаду, підтримуючи тиск, але при цьому залишаючи гравцеві достатньо часу, аби відірватися від переслідувачів."
N/A4053"#commentary\cn_139_health_and_no_hud.mp3" "[ Дейв Ріллер ] Сцена втечі дахами стала унікальним викликом для дизайнерів. Ми не хотіли, щоб вона перетворилася на справжню геймплейну перешкоду — в ідеалі гравець мав пройти її з першої спроби. Водночас ми прагнули створити відчуття реальної небезпеки, аби здавалося, що загроза справжня, якщо він не продовжуватиме рухатися. Складність була в тому, що без костюма HEV у гравця немає інтерфейсу, який показує шкоду чи рівень здоров’я. Після кількох експериментів ми розробили спеціальну систему: червоне світіння на екрані сигналізувало про отримання шкоди. Гравці реагували саме так, як ми й очікували, сприймаючи це як заклик продовжувати рух, і погоня розгорталася за планом. До того ж ми зробили швидке відновлення здоров’я, тож світіння зникало майже відразу. Це давало гравцям зрозуміти, що біг дійсно є правильним вибором, і гарантувало, що випадкова куля в кінці не знищить гравця лише через його вагання на початку."
N/A4054"#commentary\cn_140_playtesting_anecdote_2.mp3" "[ Якоб Юнґельс ] У цьому сегменті нам потрібно було, щоб гравця збили з ніг, а Алікс його врятувала. За обмежених часу й ресурсів ми максимально спростили цю сцену: використали вже існуючі системи й оформили її як звичайний бій, у кінці якого запускався кастомний івент у разі «смерті» гравця. Після кількох тестів для точного налаштування часу ми рушили далі. Але вже ближче до релізу виникла проблема: один тестувальник постійно робив швидке збереження і відразу переходив до нього, щойно думав, що програв. Коли його атакував комбінант, він встигав швидко завантажитися до того, як Алікс встигала втрутитися, і повторив це більше десяти разів, перш ніж ми попросили його зупинитися. На фінальній стадії розробки ми могли виправляти лише критичні баги, адже навіть дрібна зміна могла зламати щось важливіше. Знаючи, що це рідкісний випадок (у більшості тестувальників із цим проблем не виникало), ми внесли лише кілька обережних змін: скоротили затримку між нокдауном і першою реплікою Алікс та замінили чорний екран затемнення на білий. Хоч це й не мало багато сенсу, адже гравці ще не встигли померти стільки разів, щоб почати асоціювати чорний колір із загибеллю. Ми також розглядали ідею тимчасово вимкнути швидке завантаження на час сцени, але побоялися, що це може спричинити баг, через який швидке завантаження залишиться вимкненим назавжди."
N/A4055"#commentary\cn_141_character_reactions.mp3" "[ Аріель Діас ] Визначити, на що — і як саме — мають реагувати персонажі, було постійним викликом. По суті ми завжди прагнемо, щоб гра реагувала на дії гравця. Але будь-яка реакція гри може сприйматися гравцем як винагорода. Тож те, на що реагують персонажі й що ігнорують, фактично навчає гравця, які дії від нього очікує гра. Тому ми обов’язково реагували на те, чого нам хотілося більше, — наприклад, коли гравці возилися з пристроями в лабораторії, — і свідомо ігнорували те, чого хотілося менше, — скажімо, коли хтось без кінця бив Кляйнера коробкою по обличчю. Це не жарт: один тестувальник робив це п’ять хвилин поспіль."
N/A4056"#commentary\cn_142_choreography.mp3" "[ Білл Флетчер ] Систему, яку ми створили й відточували для подання оповіді в Half-Life 2, ми між собою називали Choreo (скорочено від «хореографія»). Спершу нам було корисно уявляти, що ми пишемо п’єсу, де один з акторів не знає сценарію. Нам потрібна була система, здатна керувати рештою акторів: пересувати їх сценою, задавати ролі й репліки. Щоб це працювало, їм доводилося органічно поєднувати наші режисерські команди з динамічними реакціями на позицію та поведінку гравця. Очевидно, найбільшим викликом став хронометраж: будь-яка сцена могла подовжуватись, скорочуватись або навіть зупинятися — залежно від того, що робив гравець."
N/A4057"#commentary\cn_143_phoneme_extraction.mp3" "[ Білл Флетчер ] Ще одним важливим інструментом у FacePoser був редактор фонем. Він обробляв репліки акторів озвучення й виділяв фонеми, щоб генерувати базову синхронізацію губ для персонажів. Для головних героїв наші аніматори використовували це як відправну точку й створювали високоякісні індивідуальні анімації для кожної репліки, включно з повною мімікою. Але в динамічній сцені Choreo аніматори не знали напевно, що відбуватиметься з рештою тіла актора. Це означало необхідність ретельного розподілення команд Choreo та хронометражу в FacePoser, при цьому зберігалася здатність актора динамічно реагувати на дії гравця."
N/A4058"#commentary\cn_144_delivery.mp3" "[ Кен Бьордвелл ] Щоб знайти правильний баланс між передачею інформації та емоційним зв’язком у ключових сценах Choreo, нам знадобилося багато ітерацій та ігрових тестів. У кожній сцені було чимало інформації, яку треба було донести до гравця, але ми не могли просто змусити персонажів виголошувати експозицію — тоді вони почали б сприйматися радше як дороговкази, ніж як люди. Треба було виділити їм час на взаємодію один із одним, дозволяючи гравцеві спостерігати за їхніми стосунками. Водночас ми мали розширити світ, давши гравцеві уявлення про те, що відбувалося за час його відсутності. І все це мало бути зроблено обережно, без зайвого затягування, адже ми хотіли, щоб гра подобалась і тим, хто менш занурений у сюжет. Анімація стала потужним інструментом для передачі емоційних зв’язків між персонажами: вона часто дозволяла швидко передати глибину моменту без перебільшень. Ще одним поширеним прийомом був гумор, який допомагав розрядити атмосферу та розслабити гравця, коли події ставали надто важкими емоційно."
N/A4059"#commentary\cn_145_alyxs_kiss.mp3" "[ Кен Бьордвелл ] Це невеликий момент, але поцілунок Алікс у щоку Ілая був важливим. Згодом ми попросимо гравця врятувати Ілая — і для цього важливо, щоб він справді переймався його долею. Щоб створити цей емоційний зв’язок, треба було показати теплоту й ніжність у стосунках між Алікс та Ілаєм. Ми не хотіли перебільшувати це діалогами чи робити надмірно урочистою подією — усе мало виглядати щиро, а не показово. Тож ми довго відточували нюанси цієї сцени, доки вона не заграла саме тим потрібним тоном."
N/A4060"#commentary\cn_146_storytelling.mp3" "[ Білл Ван Бюрен ] Створення відчуття занурення було одним із головних принципів нашого підходу до оповіді в Half-Life 1. Це привело нас до самозапроваджених обмежень: ніколи не забирати управління у гравця — або робити це лише у виняткових випадках — і залишати аватар гравця мовчазним. Часом ці рамки ускладнювали роботу з оповіддю, але ми вважали важливим зберегти їх і в Half-Life 2. Ми сподівалися, що дотримання цих принципів змусить нас шукати глибші й інтерактивніші способи оповіді."
N/A4061"#commentary\cn_147_archetypes.mp3" "[ Білл Ван Бюрен ] Ми хотіли створити оповідальні зв’язки між Half-Life 1 і Half-Life 2 через персонажів. Ідея полягала в тому, щоб розробити образи, які нагадували б архетипи з Half-Life 1 і здавалися гравцям знайомими, — ніби вони вже зустрічали цих людей у першій грі, але не могли пригадати точно, де саме. доктора Кляйнера ми створили на основі моделі науковця, яка, на нашу думку, була найбільш канонічною. Його особистість значною мірою сформував Гел Робінс, чий голос і акторська гра визначили образ учених Half-Life 1. Одного разу, коли ми саме ламали голову над тим, як має виглядати цей персонаж, у ліфті нам трапився бухгалтер із іншого офісу в нашій будівлі. Поглянувши на нього, ми одразу зрозуміли: «Ось обличчя доктора Кляйнера». На щастя, він охоче погодився, коли ми запитали, чи можна його сфотографувати для створення персонажа відеоігри."
N/A4062"#commentary\cn_148_tone.mp3" "[ Білл Ван Бюрен ] Важливо було вибрати правильний тон для персонажів і їхніх діалогів. Ми прагнули, щоб взаємодія з гравцем була шанобливою, майже дружньою й без відтінку підлеглості. Особливо непросто було з Алікс: вона мала підтримувати гравця, але водночас залишатися сильною та незалежною особистістю — інакше гравці не сприймали б її серйозно. Її зв’язок з Ілаєм ми зробили головним рушієм мотивації гравця, тож було вкрай важливо, аби гравці симпатизували їй і щиро хотіли допомогти. Крім того, ми свідомо протиставили тепло та товариськість союзників гравця ворожості Бріна й Комбінації, щоб викликати в гравців почуття праведного обурення перед майбутніми битвами."
N/A4063"#commentary\cn_149_voice-actors.mp3" "[ Білл Ван Бюрен ] Щоб створити більш живо реагуючих і багатовимірних персонажів у Half-Life 2, ми мусили змінити свій підхід до роботи з акторами озвучення. Якщо в Half-Life 1 для більшості діалогів NPC було досить просто начитати сценарій із мінімальними вказівками, то в Half-Life 2 ми вирішили дати акторам більше можливостей, аби вони могли допомогти розкрити персонажів і вдихнути в них життя. Ми дали акторам значно більше контексту: показували ігровий світ, середовище, де жили їхні герої, й інших персонажів, з якими вони взаємодіяли. Нам були потрібні актори, які могли б засвоїти цю інформацію та втілити її у своїй грі, роблячи персонажів кращими, ніж ми самі уявляли. Ми проводили з основними акторами кілька сесій, дозволяючи їм поступово зрозуміти своїх персонажів і розвивати їх. У сценах, де вони взаємодіяли один з одним, ми часто давали акторам орієнтир у вигляді записів колег, щоб створити кращий зв’язок і природний ритм діалогу. Хоча ми приходили до студії з готовим сценарієм і планом запису, ми завжди стежили, щоб актори були вільні у власних ідеях щодо персонажів й акторської гри. Присутність аніматорів на сеансах озвучення теж мала вирішальне значення: саме вони зшивали діалоги персонажів із фізичними діями й мімікою, формуючи фінальні сцени Choreo. Часто траплялося, що їхнє уявлення про сцену суттєво змінювалося після роботи з актором озвучення."
N/A4064"#commentary\cn_150_citizens.mp3" "[ Білл Ван Бюрен ] Коли ми дійшли до дизайну жителів Сіті-17 і світу за його межами, то вирішили показати їх різноманітність за расою, віком і статтю. Це було важливо з кількох причин: по-перше, щоб підкреслити, що Комбінація поневолила усе людство без винятку; по-друге, щоб кожен гравець міг упізнати себе серед Опору, адже вся Земля об’єдналася проти Комбінації. Спочатку ми знаходили кандидатів для референсів у власному повсякденному житті й серед знайомих, але зрештою скористалися оголошеннями в газеті Seattle Times, щоб все ж зібрати той спектр облич, який ми собі уявляли."
N/A4065"#commentary\cn_151_alyx.mp3" "[ Забі Інґ ] Створення дизайну Алікс було непростим завданням — ми хотіли, щоб гравець водночас і поважав її, і відчував до неї прихильність. Порятунок Ілая був ключовою метою в середині гри, і ми розуміли: гравцям буде легше перейнятися цією місією, якщо їм буде небайдуже до самої Алікс та її стосунків із батьком. Тому ми продумали її образ, написали діалоги та запросили актрису озвучення на підставі уявлення, що Алікс має бути кмітливою, сильною й близькою гравцеві у світі, контрольованому Комбінацією, але при цьому має залишатися харизматичною та привабливою. Ми свідомо уникали об’єктивації, перебільшення й гіперсексуалізації, які були характерними для багатьох ігор 2000-х, бо вважали, що це зруйнувало б задуманий нами образ персонажа."
N/A4066"#commentary\cn_152_lab_interactivity.mp3" "[ Забі Інґ ] У наших хореографічних сценах ми на певний час обмежуємо гравця в діях, щоб можна було зосередитися на персонажах і сюжеті. Але щоб врахувати потреби різних гравців — хтось занурюється в історію повністю, а хтось не здатен стояти на місці довше секунди, — ми вирішили постійно додавати цікаві деталі. Ми розкидали по оточенню сюжетні елементи, і деякі з яких були інтерактивними — свого роду «іграшками», з якими можна було возитися. У деякі ми закладали додатковий шар історії: наприклад, мінітелепорт із кактусом натякав на майбутню несправність великого телепорта. Тут важливий був тонкий баланс — надмір візуальних деталей міг відволікати гравців від суті сцени. В лабораторії Кляйнера ми обмежили інтерактивність, адже це була перша велика сцена на системі Choreo. А вже в лабораторії Ілая ми пішли далі, зробивши так, щоб персонажі реагували на те, з чим взаємодіє гравець."
N/A4067"#commentary\cn_153_gestures.mp3" "[ Даг Вуд ] Кожен наш персонаж мав бібліотеку простих анімацій, які ми називали «жестами». Їх можна було легко накладати поверх інших рухів тіла. Спершу вони задумувалися як спосіб заощадити виробничі ресурси, що дозволяв повторно використовувати анімації протягом гри. Але згодом з’ясувалося, що їхнє значення значно ширше. Люди зазвичай повторюють певні рухи, і вони можуть слугувати своєрідними маркерами особистості. У результаті наша бібліотека жестів допомогла зафіксувати характерні риси кожного персонажа, уніфікувавши розуміння того, ким він є, для всієї команди аніматорів. Завдяки цьому набагато простіше було розподіляти роботу над окремим персонажем між різними аніматорами — а така потреба у виробництві виникала постійно."
N/A4068"#commentary\cn_154_interactive_storytelling.mp3" "[ Ерік Джонсон ] Коли ми починали роботу над Half-Life 2, у більшості ігор оповідь була або високоякісною, але лінійною, або інтерактивною, але доволі примітивною. Ми знали, що гравці вже бачили сильну, добре поставлену історію в іграх, але їх ще ніколи не поміщали прямо в самий центр подій — так, щоб вони могли спостерігати, як вона розгортається навколо них, взаємодіяти з нею та вивчати будь-яку її деталь. Ця ідея нас страшенно надихала, але ми ще не розуміли, як вона працюватиме на практиці та які технології для цього знадобляться. У Half-Life 1 ми вже створили певні інструменти для подання історії, але вони здебільшого подавалися перед гравцем і не мали тієї інтерактивності та глибини, яких ми прагнули. Саме тому лабораторія Кляйнера стала своєрідним полігоном — місцем, де ми випробовували й відшліфовували нашу інтерактивну оповідь."
N/A4069"#commentary\cn_155_monitors.mp3" "[ Ідо Маґал ] У Half-Life 2 та епізодах ми постійно використовуємо монітори для оповіді — настільки часто, що навіть жартуємо з цього. Проблема лише в тому, що вони надто вже корисні. Завдяки їм зручно показувати події в інших місцях і розширювати світ, а ще це простий спосіб дати персонажам поговорити, не вигадуючи, як саме вони опинилися поруч із гравцем. Будь-хто, хто коли-небудь писав якусь історію, особливо із сукупністю персонажів, знає, яке це особливе роздратування — придумати природні причини, чому всі вони раптом опинилися в одному місці. У цьому випадку ми були дуже задоволені тим, як монітор дозволив Алікс телепортуватися, а потім швидко з’явитися в лабораторії Ілая, завдяки чому все виглядало правдоподібно й логічно пов’язано."
N/A4070"#commentary\cn_156_scene_interactivity.mp3" "[ Джефф Лейн ] У певні моменти наших хореографічних сцен ми змушуємо гравця діяти. Це не лише спосіб дати йому чимось зайнятися та втримати інтерес — такі моменти мали ще й кілька важливих цілей. По-перше, вони дозволяли гравцеві надолужити згаяне, якщо той відволікся на щось із оточення: сцена могла спокійно «почекати», доки він не виконає завдання, гарантуючи, що він знову зосередиться на подіях коли повернеться. По-друге, це давало нам змогу розташувати гравця саме там, де потрібно, аби правильно скомпонувати сцену й показати щось важливе. А в деяких випадках ми ще й отримували додаткову користь, використовуючи подібні моменти як навчальні: наприклад, тут гравець уперше вчиться працювати з вилками та розетками — навичкою, що знадобиться йому для головоломок далі в грі."
N/A4071"#commentary\cn_157_kleiners_lab.mp3" "[ Марк Лейдлоу ] Лабораторія Кляйнера була першим елементом оповіді, над яким ми працювали, і саме на неї пішло найбільше часу. Окрім своєї ролі у введенні гравця в гру, вона зрештою стала об'єднувальною концепцією для всієї команди розробників у плані оповіді. Коли ми почали створювати персонажів і систему подачі історії навколо гравця, виникло багато запитань — і всі вони здавалися серйозними ризиками для гри. Чи зможуть гравці отримати важливу інформацію зі сцени? Чи зможемо ми зробити так, щоб вони прив’язалися до цих персонажів? Як підтримати гравців із різним рівнем зацікавленості в сюжеті? Скільки коштуватиме створення такої сцени? І скільки ще подібних сцен нам знадобиться? На ці та багато інших питань неможливо було відповісти, доки ми не зібрали достатню частину сцени й не протестували її на великій кількості гравців. І це було найфрустраційніше: на відміну від багатьох інших проблем, на які можна знайти відповідь за допомогою швидких прототипів, ці питання вимагали значної роботи. Ми часто можемо перевірити ідеї ігрового процесу на низькодеталізованих прототипах, але якщо гравця не зачіпає наша оповідь, коли персонажі виглядають як сірі блоки, наскільки можна бути впевненими, що він виявить до неї інтерес, коли вони будуть повністю реалізовані?"
N/A4072"#commentary\cn_158_characters.mp3" "[ Марк Лейдлоу ] У Half-Life 1 охоронців і вчених можна було радше назвати архетипами, ніж особистостями. Вони були абстракціями персонажів, що відповідали рівню графічної деталізації, якого ми могли досягти на той час. Але з розвитком технологій у Half-Life 2 ми побачили можливість відійти від абстракцій. Вища деталізація моделей персонажів у поєднанні з поліпшеною анімацією переконали нас, що тепер ми можемо зосередитися на створенні індивідуальних персонажів — людей, до яких гравець справді міг би відчувати прихильність. Ми дозволили собі написати повноцінні діалоги й подати їх так, щоб це виглядало достатньо реалістично, аби гравці перестали сприймати персонажів як ігрові фігурки й почали рухатися далі в оповіді разом із ними. У 2001 році, за кілька років після початку розробки, нас надихнула Ico від Japan Studio. Зрежисована аніматором, ця гра вразила нас тим, що персонажі стали головним емоційним зв’язком із гравцем. Це додало нам сміливості й надалі рухатися в тому ж напрямку."
N/A4073"#commentary\cn_159_writing.mp3" "[ Марк Лейдлоу ] В епоху Half-Life 1 цілі гравця в шутерах від першої особи здебільшого зводилися до боротьби з очевидним злом і перемоги над ним. Було важко змусити гравців виявляти інтерес до персонажів, коли вони були настільки низькодеталізованими, як у Half-Life 1. Запланувавши покращення якості моделей у Half-Life 2, ми вирішили спробувати зробити персонажів рушійною силою оповіді. Наша мета полягала в тому, щоб мотивація гравця збігалася з мотивацією персонажів — щоб гравець переймався цими людьми, їхніми надіями й страхами та бажав їм успіху. З огляду на це ми сформували наш підхід до персонажів і діалогів. Ми створювали групу персонажів, які симпатизують один одному і дбають один про одного, сподіваючись, що гравець відчує те саме. Їхня взаємодія мала виглядати природною, наче це компанія старих друзів, які сприймають гравця як одного з них — просто він був відсутній деякий час. Якщо персонажі демонстрували реалістичні емоційні зв’язки між собою, ми вірили, що зможемо вибудувати такий зв’язок і з гравцем."
N/A4074"#commentary\cn_160_animation.mp3" "[ Майлз Естес ] Щоб рухи персонажів виглядали по-людськи правдоподібно, ми складали їх із багатьох шарів анімації, і цей процес вимагав безлічі технічних ітерацій. Навіть такі прості дії, як погляд убік чи крок у певному напрямку, ставали значно складнішими, адже вони мали одночасно реагувати на гравця й підкорятися командам Choreo. Наприклад, просте «подивитися на щось» доводилося розкладати на окремі частини — від руху очей і голови до повороту плечей, верхнього торсу чи всього тіла в будь-якій комбінації. У Half-Life 1 ми обходилися простішим підходом: тіла людей умовно ділилися на верхню та нижню половини, тож вони могли йти в одному напрямку, а дивитися — в іншому. Але для Half-Life 2 такий метод виявився надто штучним. Натомість наші аніматори створили анімації ходьби у всіх восьми напрямках компаса, які згодом можна було плавно поєднувати в реальному часі."
N/A4075"#commentary\cn_161_faceposer.mp3" "[ Ян Берньє ] Головним інструментом для роботи системи Choreo став FacePoser — програма з трохи хибною назвою, яка дозволяла нашим аніматорам будувати всю структуру сцени на часовій шкалі. На ній розташовувалися команди Choreo для акторів разом із потрібними даними для їх виконання. Завдяки цьому можна було задати складні поєднання дій: актор обертається до одного об’єкта, говорить до іншого й водночас рухається в інше місце. При цьому шкала не була жорсткою послідовністю — актори виконували команди, але динамічно реагували на світ довкола. Якщо гравець заважав їм пройти, вони могли затриматися, або ж почекати, щоб вимовити репліку, якщо інший актор затримувався через дії гравця. З FacePoser можна було швидко змінювати сцени: експериментувати з розташуванням, подачею діалогів і хронометражем. Саме ця гнучкість стала критично важливою, щоб знайти правильні рішення для досягнення наших цілей із персонажами та оповіддю."
N/A4076"#commentary\cn_162_choreo_commands.mp3" "[ Ян Берньє ] Ця візуалізація налагодження показує дві найпоширеніші команди Choreo, які актори отримують протягом сцени: «дивись-на» та «перейди-до», як ми називали їх між собою. Актори отримують цілі, на які потрібно дивитися — іноді навіть кілька одночасно, — а потім намагаються сфокусуватися на тій, яка є найбільш логічною в їхньому поточному стані. Водночас вони можуть отримувати команди «перейди-до», які наказують переміститися в певне місце й подивитися в певному напрямку або на певний об’єкт. Навіть ці, здавалося б, прості команди були досить складними. Сцена могла вимагати, щоб актор під час розмови друкував на клавіатурі та дивився на об’єкт, який тримає гравець. Оскільки ми не могли передбачити, де саме буде гравець у сцені, розробка подібних сцен вимагала від нас розбивати кожен елемент на окремі частини й шари. Потім, під час відтворення, їх можна було складати разом у потрібній послідовності залежно від дій гравця та переривати за необхідності."
N/A4077"#commentary\cn_163_antlions.mp3" "[ Керрі Девіс ] Оскільки гравець їздить на баггі по всьому узбережжю, нам був потрібен ворог, який міг би з’явитися будь-де й створювати постійну загрозу, змушуючи гравця залишатися в баггі або триматися поруч із ним. Ідеально для цього підійшли мурашині леви, що з’являються з піску. Завдяки високій рухливості вони могли на коротких відрізках наздоганяти баггі, на відміну від наших людиноподібних ворогів. Крім того, переїжджати їх було ще тим задоволенням."
N/A4078"#commentary\cn_164_thumpers.mp3" "[ Адріан Фінол ] По можливості дуже важливо, щоб гравці відчували, ніби вони самі до чогось доміркувалися. Це робить світ живішим, а не просто низкою ігрових елементів, спеціально розставлених для них. Якщо ми готові прийняти ризик, що певний відсоток гравців може повністю пропустити якийсь елемент, ми можемо застосувати тонший підхід. Ми використали його для обмежувачів периметра створивши ситуації, які гравці, ймовірно, стикнуться, але не будуть змушені взаємодіяти з ними. Є безліч візуальних і звукових підказок, а також реакції мурашиних левів, які допомагають гравцеві зрозуміти, що відбувається. Це не гарантує, що всі гравці це помітять, але тести показали, що більшість таки домірковується."
N/A4079"#commentary\cn_165_d2_coast_09.mp3" "[ Аарон Сілер ] На пізніх етапах розробки узбережжя ігровий код випереджав дизайн рівнів, і програмісти ігрового процесу вже шукали нові завдання й можливості написати більше коду, щоб допомогти довести Half-Life 2 до релізу. Це було здебільшого пов’язано з вимогами рівнів узбережжя, які стали важким тягарем для дизайнерів через величезний масштаб і складний рельєф. У результаті програмісти почали створювати менш масштабні сутички. Згодом, коли дизайнери рівнів їх наздогнали, вони створили цей рівень, зшивши докупи три окремі сутички від програмістів і виконавши всі необхідні доопрацювання для підготовки до релізу."
N/A4080"#commentary\cn_166_final_scene.mp3" "[ Білл Ван Бюрен ] Блокування гравця в капсулі під час фінального протистояння в офісі Бріна було певним компромісом, але воно дозволило зосередитися на персонажах так, як ми не могли зробити деінде. У цій сцені всі сюжетні арки персонажів доходять до завершення, і обмеження гравця цим ракурсом створює можливість для справжньої емоційної розв’язки — кульмінації, підсиленої поєднанням діалогів, акторської гри голосом та анімацій. З погляду виробництва ця сцена була складною: потрібно було правильно вибудувати мізансцену й рухи, досягти чіткого таймінгу, емоційної синергії та узгодженості між усіма анімаціями й голосовими доріжками, записаними окремо. На це пішло багато налаштувань, перш ніж усе склалося у справді драматичну єдність і дало відчуття, що всі персонажі дійсно взаємодіють."
N/A4081"#commentary\cn_167_end_game_scramble.mp3" "[ Дейв Ріллер ] Спочатку для фіналу гри планувалася значно масштабніша хореографічна сцена. Однак команда хореографів була перевантажена величезним обсягом пов’язаної з оповіддю роботи, яка залишалася по всій грі. Щоб трохи їх розвантажити, групі, яка відповідала за ігровий процес у Цитаделі, було доручено створити геймплейне випробування для завершення гри. Це могла бути головоломка, бій — що завгодно. У результаті з’явилася битва з босом Бріном, яка спиралася на вже наявні механіки супергравітаційної гармати й невелику кількість спеціально створеної хореографії. Це дозволило за дуже стислі терміни отримати готовий фінальний продукт."
N/A4082"#commentary\cn_168_combine_portal_effects.mp3" "[ Ґері Мактаґґарт ] Важливою частиною нашого процесу розробки була можливість для будь-якого члена команди зробити внесок у будь-яку частину гри. Коли ігровий процес фінальної битви був остаточно відпрацьований, художники та програмісти візуальних ефектів долучилися до створення видовищної подачі порталу в рідний світ Комбінації й ефекту зупинення часу в кінці гри. Для ефекту порталу був використаний шейдер заломлення, подібний до того, що застосовувався для води."
N/A4083"#commentary\cn_169_citadel_entrance.mp3" "[ Джефф Лейн ] Ми будували маршрут до Цитаделі у зворотному порядку: внутрішню геометрію спершу було створено як художній прототип, щоб довести її вигляд до ідеалу. Ми знали, що гравець виходитиме з каналізаційної труби на карті «Вулична війна», і мали зробити ділянку з ковзаннями та стрибками, яка вела б до входу в Цитадель і з’єднувала обидві частини."
N/A4084"#commentary\cn_170_citadel_steep_landing.mp3" "[ Ренді Ландін ] Цитадель було побудовано вже на дуже пізньому етапі розробки, і спершу ми не мали чіткого бачення її ігрового процесу. Це не було чимось незвичним: хоча зазвичай саме ігровий дизайн веде нас уперед, важливі творчі рішення, ухвалені на початку — як-от сама ідея існування Цитаделі Комбінації, — вимагали окремої дизайнерської роботи, щоб органічно вписатися у фінальний продукт. Після кульмінаційної битви в попередній главі ми вирішили, що фінал у Цитаделі з іншим тоном стане більш винагороджувальним досвідом. Навіть якби ми хотіли ще підняти ставки, вводити нові механіки чи NPC на такому пізньому етапі було занадто ризиковано. Спершу ми планували зробити пасивне оповідальне видовище — поїздку на потязі крізь серце військової машини Комбінації, яка б закінчувалася в офісі Бріна. Але після розробки цього плану ми витратили кілька днів на прототипування механіки супергравітаційної гармати. Ми думали, що наприкінці гри зможемо виконати бажання гравців і дамо їм відчути всемогутність, не порушуючи загальний баланс дизайну. Результати одразу виявилися настільки багатообіцяючими, що ми швидко переробили концепцію, щоб додати супергравітаційну гармату. Замість традиційних фінальних випробувань ми хотіли, щоб гравець відчув себе богом, який може хапати ворогів і виривати пульти зі стін. У підсумку Цитадель поєднує обидві концепції, чергуючи видовищність із неприборканою силою."
N/A4085"#commentary\cn_172_lightmap_pass.mp3" "[ Майк Дюссо ] Інтер’єр Цитаделі відносно простий із геометричної точки зору, але метал Комбінації та ефектне освітлення допомагають передати масштабність цієї споруди. Роздільну здатність карт освітлення було збільшено на ключових поверхнях, які мали візуальний інтерес, і зменшено на тих, що були повністю затінені або розташовані далеко. Через великі масштаби просторів Цитаделі занадто великі поверхні карт освітлення суттєво впливали на продуктивність. Наприкінці розробки ми провели масштабну оптимізацію цих параметрів на всіх рівнях Цитаделі для балансу між візуальною виразністю та продуктивністю. Це стало простіше завдяки новій функції редактора рівнів Hammer, яка відображала поверхні з їхньою щільністю люкселів."
N/A4086"#commentary\cn_173_super_gravity_origins.mp3" "[ Брайан Джейкобсон ] На цьому етапі розробки ми вже були впевнені в дизайні гравітаційної гармати. Ми хотіли дати гравцеві відчути себе справді всемогутнім і взялися за створення її суперпосиленої версії. Це зайняло зовсім небагато часу — можливо, лише день прототипування, — перш ніж ми отримали результат, який нам сподобався, і він став основою геймплею в Цитаделі. Коли фізичний рушій був готовий, ми могли вільно шукати нові й захопливі способи виходити за межі його попередніх обмежень і отримувати цікаві результати. Наш перший прототип — гігантський кавун, що важив сотні кілограмів у нашій фізичній симуляції, — зрештою перетворився на сфери Комбінації, які ви бачите у грі."
N/A4087"#commentary\cn_174_combine_energy.mp3" "[ Брайан Джейкобсон ] Те, що на стадії прототипу починалося з кавуна, зрештою перетворилося на енергетичну сферу, адже звуки її ударів і вибухів стали звучати менше як щось із овочевого ряду й більше як те, що ви бачите в грі. Коли ми почали ітерувати рівні вже без кавунів, то зрозуміли, що енергетичну сферу можна використати не лише як ефектний спосіб знищувати солдатів, а й як елемент головоломок — для вмикання й вимикання різного обладнання. Значно пізніше, у процесі розробки, нам перестав подобатися альтернативний вогонь AR2 у його тодішньому вигляді, і, оскільки команді сподобалася сфера Комбінації, ми зрештою вбудували її прямо в альтернативний режим стрільби AR2. Озираючись назад, ми щоразу дивуємося, як речі, які розроблялися в грі незалежно одна від одної, згодом збираються докупи й допомагають вирішувати проблеми."
N/A4088"#commentary\cn_175_combine_wall_and_balls_training.mp3" "[ Ідо Маґал ] Під час ігрових тестів гравці не помічали, що сфери Комбінації розчиняють солдатів, і не розуміли, чому ті зникають. Спочатку ми намагалися вирішити це, змусивши сфери рикошетити в напрямку ворогів, щоб збільшити ймовірність вбивств із розчиненням. Та зрештою з’ясувалося, що причина в іншому: усе відбувалося під час інтенсивного бою, а в стані стресу люди мають дуже обмежену здатність засвоювати щось нове. У спробі наостанок виправити ситуацію ми додали тренувальну кімнату з силовим полем, яку можна було відкрити лише за допомогою сфери Комбінації. Цей момент було створено спеціально, щоб навчити гравців: сфери не лише деактивують силові поля, але й розчиняють солдатів, якщо відбити їх у ворогів. Навіть після цього результати тестів були лише частково успішними. Попри наші зусилля, деякі гравці все одно не помічали ефекту розчинення. Але у нас закінчився час, і ми вирішили: якщо гравці все одно казали, що почуваються всемогутніми, то нічого страшного, якщо не всі усвідомлювали, чому саме їм вдається перемагати."
N/A4089"#commentary\cn_176_weapon_strip.mp3" "[ Джош Вейєр ] Щойно ми ввели супергравітаційну гармату, нам зовсім не хотілося, щоб гравці поверталися до своєї звичайної зброї. Тож ми зробили єдине логічне рішення — просто дезінтегрували її. Мати загадкового й майже надприродного ворога на кшталт Комбінації дуже зручно, адже цілком природно припустити, що в них може бути дезінтегратор. Чому б і ні? А якби з якоїсь причини нам би знадобилося повернути вам спорядження десь посеред рівня — що ж, у них, звісно, знайшовся б і реінтегратор."
N/A4090"#commentary\cn_177_breen_monologue.mp3" "[ Марк Лейдлоу ] Творчість ніколи не відбувається у вакуумі — ми всі надихаємося іншими речами. Монолог Бріна, який транслюється на моніторах Цитаделі, частково виник із нашої любові до Thief 2, де антагоніст глузував із гравця, поки той нишком пробирався рівнями. У нас реалізація вийшла зовсім іншою, але зерно натхнення саме звідти. Та справжню силу цьому моменту надала гра покійного Роберта Калпа. Його подача була бездоганною: кожну репліку Бріна він озвучував із такою тонкістю й шармом, що персонаж ожив, ставши чимось набагато більшим за рядки на папері. Сеанс озвучення з ним був елементарним: Калп отримував сценарій, інженер натискав «запис» — і цього було досить. Урок, який ми винесли з цього, простий: працювати потрібно з людьми, чий талант перевершує ваш власний, і з тими, у кого ви, безперечно, чогось навчитеся. Не варто заздалегідь фіксувати, як саме має звучати репліка чи розігруватися певний момент, — натомість потрібно довіряти талановитим людям і вірити, що вони зроблять усе це ще кращим."
N/A4091"#commentary\cn_178_dissolved_weapons.mp3" "[ Квінтін Дорокес ] Уся зброя Комбінації тепер розпадається після того, як солдат Комбінації перетворюється на ragdoll-модель під дією гравітаційної гармати. Це було зроблено з двох причин: по-перше, щоб гравці не могли підібрати й використати її; по-друге, щоб підвищити продуктивність на цих картах. Також ми створили менеджер ragdoll-моделей, який автоматично прибирає тіла солдатів у міру просування гравця далі."
N/A4092"#commentary\cn_179_elevator_fight.mp3" "[ Брайан Джейкобсон ] Хоча ми й хотіли, щоб гравець відчував себе всемогутнім та не втрималися від спокуси додати напружений бій біля шахти ліфта. Очікування його прибуття перетворилося на бій, що виявився складнішим, ніж ми спершу планували для цієї частини гри. Під час тестування бій трохи спростили, але часу, щоб відточити баланс як слід, уже не залишалося. Хоча гравцеві ніколи не загрожувала справжня небезпека, сама кількість солдатів створювала враження, ніби це кульмінаційний бій, хоча насправді це було не так."
N/A4093"#commentary\cn_180_replacing_the_prefabs.mp3" "[ Джефф Лейн ] Енергетичні сфери Комбінації мали відносно просту конструкцію: силове поле утримувало об’єкти, що постійно відскакували. Але під час тестування раз по раз виникали баги — сфери виходили з-під контролю і «втікали» з силового поля, створеного для їхнього стримування. Через обмеження нашої технології заготовок тоді доводилося щоразу відновлювати їх вручну, у кожному місці на всіх рівнях Цитаделі, де вони з’являлися."
N/A4094"#commentary\cn_181_strider_fight.mp3" "[ Тед Бекман ] Один із перших прототипів Цитаделі передбачав можливість схопити страйдера супергравітаційною гарматою, і довгий час бій із ним зводився до того, щоб підібратися досить близько та підняти його цією зброєю. Наприкінці розробки ми вирішили, що така механіка робить страйдера надто слабким, особливо після всіх попередніх сутичок із ними під час «Вуличної війни», тому ми замінили цей бій на варіант, де гравець знищує його сферами Комбінації. До моделі страйдера було додано спеціальні деталі, аби його можна було розривати й підривати, замість того щоб просто перетягувати. Це єдиний випадок у грі, коли страйдер має такий ефект."
N/A4095"#commentary\cn_182_getting_in_the_pod.mp3" "[ Забі Інґ ] Послідовність підйому в капсулі, що починається тут, вимагала повного контролю над сценою та поглядом гравця. Це суперечило нашому звичному прагненню залишати гравцеві якомога більше свободи, але для цього фінального етапу ми вважали такий компроміс виправданим. У цей момент гравець настільки сильний, що його було складно тримати під контролем, тож ми мусили його відключити. Водночас усі персонажі у сцені продовжують звертатися до гравця, зберігаючи його в центрі уваги. Ми також змогли додати трохи оповіді через навколишнє середовище. Поїздка через Цитадель, яка починається тут, показує кількох ворогів, для яких у нас були готові художні напрацювання, але які були вирізані з основної гри. Із своєї безпечної капсули гравець може побачити процесинг сталкерів і навіть мигцем помітити краба-синтета."
N/A4096"#commentary\cn_183_turrets.mp3" "[ Майк Дюссо ] Турелі були корисним інструментом дизайну, коли гравець мав приманку: вони могли повністю зупинити мурашиних левів, не дозволяючи їм підходити впритул. Це дозволило нам створювати ситуації, де гравець не міг просто кинути приманку й рухатися далі — йому доводилося обходити й знищувати турелі, щоб мурашині леви могли йти слідом. А спостерігати, як турелі розстрілюють мурашиних левів, виглядало ще й дуже видовищно."
N/A4097"#commentary\cn_184_grenade_puzzle.mp3" "[ Аарон Сілер ] Під час ігрових тестів гравці часто застрягали на цій невеликій головоломці, бо ящик із безлімітними гранатами стояв трохи позаду них на шляху. До цього моменту вони вже добре засвоїли: якщо є такий ящик — значить, саме ці боєприпаси потрібні для розв’язання задачі. Якби тут був ящик із гранатами, усе б одразу стало очевидним. Ми ж хотіли, щоб вони спершу трохи поміркували. Зрештою ми додали тонкий натяк: через вікно на столі було видно гранати, щоб нагадати гравцям про їхню наявність. Саме це допомогло виявити баг під час одного з тестів: гравець підійшов ближче, щоб краще роздивитися, і випадково підібрав гранати просто через скло."
N/A4098"#commentary\cn_185_allied_turrets_balancing.mp3" "[ Адріан Фінол ] Збалансувати цей бій із урахуванням союзних турелей було непросто. Турелі тут виступали новим елементом, і якщо гравці їх ігнорували, ігровий процес здавався повторним, адже він багато в чому нагадував попередні сутички. Ми хотіли зробити так, щоб використання турелей було необхідним і водночас винагороджувало за стратегічне розміщення, але система виявилася сильно бінарною: ідеальне розташування робило бій надто легким, а невдале — дуже складним. Допомогли налаштування та спеціальна логіка ШІ солдатів: вони стали активніше перевертати турелі, кидаючи гранати або заходячи з флангу. Завдяки цим змінам бій менше залежав від ідеальної схеми, а більше — від активного підтримання турелей, оскільки будь-яку побудову зрештою порушували. Ігрові тести показали дуже різні реакції: для одних цей бій здавався надмірно складним, а інші називали його улюбленим. Часу було обмаль, і ми зрештою трохи все спростили й випустили в такому вигляді, хоча й залишилися незадоволені фінальним балансом."
N/A4099"#commentary\cn_186_meeting_mossman.mp3" "[ Аріель Діас ] Возз’єднати гравця й Алікс із Моссман після сцени зради було непросто, адже багато хто з гравців вважав, що Моссман слід застрелити на місці. Ми не могли цього допустити, оскільки не мали часу на розробку альтернативних сюжетних відгалужень. Водночас ми не хотіли явно показувати, що позбавляємо гравців цього вибору, тож намагалися знизити ймовірність того, що вони взагалі спробують це зробити. Куленепробивне скло давало час для діалогу між Алікс і Моссман, у якому поступово ставало зрозуміло, що Алікс не вважає вбивство Моссман правильним рішенням."
N/A4100"#commentary\cn_187_eli_in_pod_choreography.mp3" "[ Кен Бьордвелл ] Ми створили й записали діалоги для цієї сцени ще тоді, коли працювали над Нова Проспект. На тому етапі ми вже знали, що Алікс і Ґордон телепортуються з в’язниці, але конкретики ще не було, тож репліки мали бути достатньо загальними, аби пасувати до будь-якого варіанта, який ми зрештою реалізуємо. Це спонукало нас менше зосереджуватися на діях гравця й більше — на вразливості Алікс та її зв’язку з батьком. Ми сподівалися, що саме емоції стануть рушієм сцени більше, ніж сюжетні деталі. Зрештою, ми прагнули, щоб гравець переживав за цих персонажів і хотів поставити на перше місце те, що важливо для Алікс."
N/A4101"#commentary\cn_188_mossman_and_eli.mp3" "[ Білл Ван Бюрен ] Ця хореографічна сцена потребувала численних ітерацій. Ми хотіли показати сюжетний поворот посеред сцени, не забираючи в гравця контролю. Потрібно було знайти тонкий баланс: зробити цей поворот зрозумілим, але водночас гарантувати, що його не можна буде перервати. Якщо гравець ішов за Алікс до пульта, він мав зрозуміти, що відбувається, коли обернеться. Якщо ж залишався позаду й стежив за Моссман, він так само мав усвідомити ситуацію, але без відчуття, що повинен намагатися цьому завадити. Щоб підібрати правильний таймінг, знадобилося чимало налаштувань і тестів. У результаті ми використали поєднання відволікання уваги, швидкої подачі ключового моменту та пояснення вже після того, як подія відбулася."
N/A4102"#commentary\cn_189_nova_prospekt_entry.mp3" "[ Даніка Роджерс ] Гравець щойно пройшов два насичені боями рівні, тож ми хотіли трохи знизити темп, коли він потрапляв всередину. Ці початкові рівні були задумані для зміни темпу, щоб дати можливість гравцям дослідити інтер’єри Нова Проспект. Поступово ми почали вводити ігрову механіку турелей — спершу як ворожий елемент, а згодом як інструмент, яким міг користуватися сам гравець. Значну частину цього рівня ми побудували на основі прототипів і художніх заготовок, створених раніше під час роботи над загальним виглядом Нова Проспект."
N/A4103"#commentary\cn_190_turret_training_exit.mp3" "[ Даг Вуд ] Ця купа сміття разом із захаращеними сходами була задумана, щоб відбити у гравців бажання тягнути з собою турель. Хоча це й не зламало б нічого, ми хотіли зробити таку поведінку менш імовірною. Створювати незручності для гравця — не найідеальніший дизайнерський підхід, але це було краще, ніж нічого. У результаті багато тестувальників зрештою здавалися й кидали турель, відчуваючи, що гра намагається їм щось підказати."
N/A4104"#commentary\cn_191_allied_antlions.mp3" "[ Ерік Кіршмер ] Маючи нескінченно відроджувану армію мурашиних левів, що атакувала турелі й солдатів, ми мусили визначити роль гравця в боях у Нова Проспект. До цього моменту він уже зійшовся в бою з безліччю солдатів Комбінації, тож ми вирішили зробити тутешній геймплей радше схожим на головоломку й видовищну сцену, а не на чергове бойове випробування. Ми створили ситуації, які залишалися в стабільному стані, доки не втручався гравець. Безпосередньо знищуючи ворогів, він міг схилити баланс сил на користь мурашиних левів, але ми хотіли, щоб справжнє задоволення приносило саме використання приманки. У багатьох випадках, коли гравець кидав її у ворогів, ми запускали додаткові генератори мурашиних левів, випускаючи у бій стрімку хвилю нових істот. Кривава розправа, що розгорталася на очах, і ставала тією винагородою, яка робила приманку особливо приємною у використанні."
N/A4105"#commentary\cn_192_laser_mines.mp3" "[ Ерік Джонсон ] Ми отримали велике задоволення від того, що змогли повернути лазерні міни-пастки у Нова Проспект. Це була зброя з Half-Life 1, яка так і не потрапила до Half-Life 2, але принаймні знайшла своє місце як елемент головоломки. Нам особливо сподобалося, що вони ставали своєрідним моральним тестом для гравця, який керував армією мурашиних левів. Дехто одразу кидав приманку за міни, посилаючи своїх підопічних просто на розправу, а інші стримували «маленьких приятелів», доки не знешкоджували пастки іншими способами. Ми не засуджували жоден підхід."
N/A4106"#commentary\cn_193_final_turret_arena.mp3" "[ Ерік Джонсон ] Під час створення арки ігрового елемента, наприклад використання союзних турелей, ми зазвичай спершу будуємо прототип, який представляє фінальну точку цієї арки. Далі ми багаторазово ітеруємо його, доки ігрові тести не підтвердять, що він працює. Лише після цього рухаємося у зворотному напрямку — додаємо попередні сценарії, які вводять елемент і поступово розвивають навички гравця. Такий підхід гарантує, що фінальна дуга буде цікавою ще до того, як ми витратимо на неї багато часу. Він також дозволяє, до моменту створення навчальних сценаріїв, уже мати достатньо спостережень за тестами, аби розуміти, які навички потребують додаткового керівництва, а які гравці засвоюють інтуїтивно. Цей фінальний сценарій із турелями й був нашою метою — він акцентував захист гравця від ворогів із кількох напрямків, вимагаючи від нього динамічного розміщення та відновлення турелей."
N/A4107"#commentary\cn_194_one_way_drops.mp3" "[ Якоб Юнґельс ] Гравці ніколи не знають напевне, що чекає на них попереду, зате добре орієнтуються в тому, що залишили позаду. Тому, зустрівши ворога, вони часто відступають у знайому зону. Якщо ми створюємо арену, де гравець має битися — особливо проти ворога з особливими вимогами до простору, як-от страж мурашиних левів, — потрібно знайти спосіб запобігти цьому відступу. Найчастіше для цього використовується одностороннє падіння: гравець потрапляє так на арену і вже не може повернутися. Ви, мабуть, не раз бачили цей прийом у грі."
N/A4108"#commentary\cn_195_npcs_on_elevators.mp3" "[ Джей Стеллі ] Ми часто витрачаємо багато часу на розв’язання проблем, яких гравці можуть навіть не помітити. Частина з них — тонкі дизайнерські виклики, інші ж виникають через взаємодію кількох систем одночасно. Наприклад, змусити негральних персонажів (NPC) користуватися ліфтами виявилося досить складним завданням, адже тут задіювалися одразу кілька систем: логіка ШІ, планування навігації, симуляція руху NPC — і це ще не все. До того ж сам ліфт мав власні вимоги до симуляції, не пов’язані з персонажами. Одна з найбільш підступних проблем полягала в тому, що NPC ми симулювали з нижчою частотою, ніж ліфти. У результаті виходило так: NPC стоїть у ліфті, який починає спускатися, а потім кілька разів симулюється сам ліфт і встигає опуститися нижче, ніби залишаючи персонажа позаду. Лише під час наступної симуляції NPC знову «провалювався» вниз, повертаючись на підлогу кабіни. Можете уявити, наскільки важко було сприймати Алікс серйозно, коли вона під час діалогу постійно маленькими ривками злегка просідала вниз."
N/A4109"#commentary\cn_196_looktargets.mp3" "[ Джон Кук ] Одним із ключових інструментів у нашому дизайнерському арсеналі стала ціль погляду — невидима точка в просторі, яка активується, коли гравець дивиться на неї. Дизайнери могли задавати точність, з якою треба, щоб сфокусувався гравець, тривалість погляду та інші умови. Після активації ціль погляду запускала різні події в грі. Наприклад, Алікс могла чекати, доки гравець подивиться на неї, перш ніж озвучити репліку; видовищна сцена починалася лише тоді, коли потрапляла в поле зору; або ж над головою пролітав транспортник Комбінації, якщо гравець дивився в його бік. Коли ми запровадили цей інструмент, дизайнери знайшли для нього безліч застосувань, що зробило ігровий процес значно реалістичнішим. Це особливо важливо в ситуаціях, коли об’єкти рухалися з різною швидкістю чи взагалі непередбачувано, і потрібно було гарантувати, що гравець побачить потрібний момент."
N/A4110"#commentary\cn_197_nova_prospekt_yard.mp3" "[ Джон Морелло ] Бої у дворі Нова Проспект значною мірою були натхненні нашими ранніми спостереженнями за тим, як мурашині леви билися із солдатами Комбінації. Їхня висока рухливість і атаки в ближньому бою вдало поєднувалися зі смертоносною дальньою атакою солдатів і водночас їхньою вразливістю зблизька. Мурашині леви виглядали вражаюче під обстрілом, коли навколо розліталися частинки, а момент, коли вони нарешті діставалися до солдатів і ті падали в ragdoll-анімації, був неймовірно захопливим."
N/A4111"#commentary\cn_198_vent.mp3" "[ Джон Морелло ] Ви, мабуть, і самі знаєте: якщо десь є вентиляційна шахта — в ній обов’язково сидить хедкраб. Це не ми вигадали такі правила — вони, як і самі шахти, спускаються згори."
N/A4112"#commentary\cn_199_kitchen.mp3" "[ Керрі Девіс ] Є неписане правило серед розробників: якщо в грі є кухня — на ній обов’язково має рвонути газ."
N/A4113"#commentary\cn_200_alyxs_tool.mp3" "[ Лора Дабак ] Мультиінструмент Алікс був неймовірно корисним — він дозволяв нам буквально використовувати його як ключ. Часто нам потрібно було стримати гравця, поки ми не будемо готові пустити його далі, і тоді Алікс могла одночасно відкривати прохід та вести діалог. Напевно, ми й справді зловживали цим прийомом, але втриматися було важко. Використання Алікс як «вартового дверей» замість вигадування унікального рішення економило нам час, який можна було спрямувати на інші, часто більш критичні частини гри."
N/A4114"#commentary\cn_201_mossmans_betrayal.mp3" "[ Марк Лейдлоу ] Наш початковий задум щодо арки Джудіт Моссман був у тому, що десь у цьому місці вона зрадить гравця. Але коли ми дісталися цієї сцени, вже розробивши інші частини гри, стало зрозуміло: швидше за все, вона просто намагається захистити Ілая. Ми уявляли, як вона передумає, усвідомивши, що насправді не може зрадити Ґордона. У нас були ідеї, як зробити цей поворот зрозумілішим пізніше, але зрештою ми так і не завершили її арку. Нам подобалася ця неоднозначність у Моссман — гравцям же, схоже, ні: майже всі її відверто ненавиділи. Хоча, можливо, це теж успіх — ми ж наполегливо працювали над тим, аби гравці симпатизували Алікс, а вона сама не надто прихильно ставилася до Джудіт."
N/A4115"#commentary\cn_202_d2_prison_05_start.mp3" "[ Ян Берньє ] Оскільки гравець міг пересувати велику кількість об’єктів, ми часто стикалися з труднощами, особливо з огляду на обмежені можливості процесорів 2003 року. Одне з обмежень полягало в тому, що наша система навігації ШІ не розпізнавала динамічних фізичних об’єктів, як-от ці металеві ліжка. Хоча система руху NPC могла виявляти фізичні об’єкти й оминати їх під час пересування, вони залишалися фактично невидимими при навігаційних запитах стратегічного планування. Це було насамперед наслідком браку продуктивності — ми не могли дозволити собі нічого складнішого. Ми також зіткнулися з проблемами дизайну без очевидних рішень — наприклад, що має робити солдат, якщо гравець повністю перегородить коридор великими об’єктами. Щоб якось це обійти, ми надали NPC додаткову силу, щоб вони могли відштовхувати фізичні предмети. А ще зменшили проблему за допомогою дизайну рівнів: розширили коридори й залишили достатньо вільного простору, аби в ньому могли розміститися будь-які предмети, куди б вони не впали. Це було доволі ризиковане рішення: поєднання солдатів, що ховалися за ліжками, й мурашиних левів, які кидалися в ближній бій, часто створювало ймовірність незграбних зіткнень між системою руху NPC та тими ж ліжками."
N/A4116"#commentary\cn_203_alyx_as_companion.mp3" "[ Майлз Естес ] Ця сцена мимоволі стала прототипом того, що згодом з’явиться в Episode One: Алікс у ролі напарниці плавно рухається маршрутом, де динамічний бій поєднується із заскриптованою хореографією. Тоді ми ще не мали чіткої моделі того, як саме вона взаємодіятиме з гравцем у таких сценаріях, але навіть цей короткий епізод багато чому нас навчив, хоч і часу на повноцінні ітерації вже не залишалося."
N/A4117"#commentary\cn_204_laundry.mp3" "[ Майк Дюссо ] На той момент, коли гравець дістається рівня, відомого як «Пральня», ми вже впевнені, що він добре освоїв використання приманки для вирішення бойових ситуацій. Тож ми вирішили трохи підняти ставки, створивши сценарій, який заохочує гравця діяти ще активніше, поєднуючи приманку з усім арсеналом його зброї."
N/A4118"#commentary\cn_205_side_zombie.mp3" "[ Квінтін Дорокес ] Цей отруйний зомбі завжди був яскравим моментом під час ігрових тестів. Гравці, зосереджені на солдатах Комбінації, мурашиних левах і турелях, давно не зустрічали отруйних зомбі, тож його раптова поява в темряві часто ставала справжнім шоком."
N/A4119"#commentary\cn_206_flares.mp3" "[ Квінтін Дорокес ] Ця ділянка стала гарним контрастом до попереднього сегмента з турелями з точки зору виробничих витрат і кількості ітерацій. Створена на дуже пізньому етапі, вона була швидко зібрана, адже ШІ для Алікс і солдатів Комбінації вже був достатньо відпрацьований. Нам сподобалися темрява й сигнальні ракети, тож ми занотували це як ідею для подальшого розвитку. Згодом ми повернулися до неї під час планування темних ділянок у Episode One."
N/A4120"#commentary\cn_207_magic_wall.mp3" "[ Робін Вокер ] Як і в багатьох наших бойових аренах, нам потрібні були якісь ворота, щоб гравці не могли пройти далі, доки не закінчать бій. Але часу вже не залишалося, і нам довелося переходити до вокзалу. У результаті ми зробили отаку магічну нісенітницю: стіна просто вибухає одразу після того, як ви знищуєте другого штурмовика, відкриваючи шлях уперед. Ми заспокоювали себе тим, що більшість гравців навіть цього не помітять, адже будуть повністю зайняті боєм, та й тестування показало, що зазвичай усі справді закінчували бій до цієї точки. З такою кількістю вибухів по всій арені зруйнована й палаюча стіна виглядала досить природно, тож ми ще й додали кілька простих головоломок із газом з іншого боку, аби це виглядало більш обґрунтовано. Але ні, особливо гордитися цим ми не можемо."
N/A4121"#commentary\cn_208_ragdoll_vortigaunt.mp3" "[ Скотт Далтон ] У цьому мертвому вортіґонті можна побачити чимало болю — і це біль наших дизайнерів рівнів. Тоді наші інструменти розробки не дозволяли напряму задати позу ragdoll-моделі. Тобто, коли NPC помирав і системно падав на землю як ragdoll, ми не мали жодного контролю над тим, у якій саме позі він завмре. Якби ми мали трохи часу на аніматорів, вони могли б зробити нам однокадрову анімацію приблизно в потрібній позі, але графік горів, а невеличка команда аніматорів уже працювала на межі. Тому дизайнер рівнів ставив вортіґонта над цим стільцем, давав йому команду «померти» під час завантаження рівня й дивився, у якій позі зупиниться ragdoll. Потім трохи пересував його й пробував знову. Точно не згадаємо, скільки спроб це забрало, але значно більше, ніж ви могли б подумати."
N/A4122"#commentary\cn_209_nova_prospekt_process.mp3" "[ Ерік Сміт ] Як і Рейвенхолм, Нова Проспект спочатку задумувався з ігровим процесом, що суттєво відрізнявся від фінального. Перша версія робила акцент на боях гравця проти солдатів Комбінації без участі мурашиних левів. На відміну від інших зон гри, де ігровий процес і візуальне оформлення розвивалися паралельно, Нова Проспект отримав значний художній поштовх уже на ранньому етапі. У результаті з’явився набір відполірованих ділянок геометрії рівня з готовим арт-оформленням, які можна було повторно використовувати. Збирати в’язницю з цих частин було зручно, адже її планування саме по собі має природну повторюваність. А коли пізніше ми повернулися до цього розділу з мурашиними левами та приманкою, довелося переосмислити геометрію, щоб підлаштувати її під новий ігровий процес."
N/A4123"#commentary\cn_210_d2_prison_04.mp3" "[ Ерік Кіршмер ] Протягом розробки наші художники створювали невеликі вертикальні зрізи середовищ, які ми називали «арт-зоопарками». Вони показували, як саме слід використовувати текстури й реквізит, щоб ігрові простори відповідали нашим візуальним цілям. Але коли настав час будувати ігровий маршрут у в’язниці, її повторюване планування дозволило нам застосувати ці напрацювання набагато пряміше. Спершу ця карта була створена як основний «арт-зоопарк» для Нова Проспект, але після тестування різних прототипів ігрового процесу — зокрема тих, що зрештою привели до появи приманки, — вона стала частиною справжньої архітектури рівня."
N/A4124"#commentary\cn_211_autosave_dangerous.mp3" "[ Дейв Ріллер ] У Half-Life 1 автозбереження розставляли вручну дизайнери рівнів: вони спрацьовували, коли гравець досягав певної точки чи моменту. Це гарантувало, що гра зберігається автоматично під час вашої подорожі коридорами Чорної Мези. У Half-Life 2 нам знадобився новий інструмент. Проблема виникла на складніших аренах: деякі сутички тривали довго й включали кілька хвиль ворогів, інші ж розтягувалися у часі, поєднуючи дослідження та бій без чіткого поділу. Ми ніколи не хочемо робити автозбереження там, де гравець може загинути одразу після завантаження, бо це загрожує петлею смерті — і якщо ви грали в ігри тих часів, то точно потрапляли в таку ситуацію хоча б раз. Якщо спеціально не вставляти паузи у темп арени, не завжди знайдеш безпечне місце для автозбереження. Після експериментів ми створили функцію Autosave Dangerous («Автозбереження в небезпеці»). Це був інструмент для дизайнерів рівнів, що поєднував автозбереження з часовим інтервалом. Коли дизайнер його активував, гра зберігалася одразу, але саме збереження відкладалося й не було доступним для завантаження. Якщо гравець залишався живим протягом зазначеного часу — скажімо, тридцяти секунд, — це збереження підтверджувалося й ставало останнім автозбереженням. Таким чином ми могли ставити автозбереження у логічних місцях арени, але переконувалися, що воно справді безпечне."
N/A4125"#commentary\cn_212_we_dont_go_to_ravenholm.mp3" "[ Даріо Касалі ] Коли ми завершували роботу над Рейвенхолмом, нас не полишало відчуття, що перехід від лабораторії Ілая виглядав неприродно. Він був занадто різким: лабораторія одразу виходила просто на вулиці міста, де ви опиняєтесь далі, а цієї ділянки, де ви зараз, узагалі не існувало. Наприкінці лабораторії ми щойно дали обіцянку: «Ми більше туди не ходимо», і нам подобалося, як ми поступово нагнітали атмосферу. Але замість цього гравець відразу опинявся в бійці із зомбі, без жодного місця для наростання напруги. Щоб виправити це, ми додали цю перехідну ділянку та наступні вузькі коридори. Вони сповільнювали темп, дозволяли зосередитися на художньому оформленні й освітленні та готували вас до того, щоб на власному досвіді зрозуміти, чому ми більше не ходимо до Рейвенхолма."
N/A4126"#commentary\cn_213_lever_shenanigans.mp3" "[ Даріо Касалі ] Попри всі наші спроби провести чіткий зв’язок між цим важелем і зовнішнім електричним парканом у свідомості гравця, дехто з тестувальників усе одно смикав важіль і не розумів, що відбулося. Деякі навіть блукали навколо, повертали важіль назад і знову йшли шукати щось далі. Оскільки часу, щоб зробити цей зв’язок очевиднішим, уже майже не залишалося, ми вирішили піти іншим шляхом — просто зробили так, щоб важіль відламувався. Це не дозволяло гравцям відкотити свій прогрес і водночас підсилювало відчуття, що Рейвенхолм — місце ненадійне, зруйноване й приречене на занепад."
N/A4127"#commentary\cn_214_town_arenas.mp3" "[ Даріо Касалі ] На цьому етапі в Рейвенхолмі гравець уже опанував усі доступні йому елементи ігрового процесу й може передбачати, як вони взаємодіють. Це дає нам змогу будувати складніші комбінації, підвищуючи рівень загрози й надаючи гравцеві більше свободи у виборі підходів до кожної ситуації. Арена тут — навмисно заплутаний простір, який потрібно досліджувати, і ми використовуємо цей час, щоб поступово нарощувати інтенсивність бою. Чим швидше гравець досліджує територію, тим швидше зростає градус напруги. Вільний характер цього дизайну ускладнював налаштування через широкий діапазон стилів проходження, які могли обирати гравці."
N/A4128"#commentary\cn_215_mines.mp3" "[ Даріо Касалі ] Складний маршрут, яким гравець пробирається крізь цю шахту, дає йому вдосталь часу, щоб роздивитися, що чекає внизу. І сюрприз: хедкраби. Якщо чесно, це дуже часто хедкраби. Але цього разу — отруйні хедкраби. Вони й самі по собі цікаві, але справжнє видовище починається, коли додати до них ще й швидких. Разом вони створюють чудову комбінацію: кожен окремо не надто небезпечний, але в парі — смертоносні. Після отруєння одного удару швидкого хедкраба достатньо, щоб убити гравця. І це те, що біологи назвали б симбіозом. Принаймні, ми так думаємо."
N/A4129"#commentary\cn_216_poison_headcrabs.mp3" "[ Девід Спейрер ] У цій кімнаті отруйні хедкраби з’являються випадково. Ми довго готували для них правильне представлення на рівні пізніше, але щойно побачили, наскільки добре вони працюють у тестах, ентузіазм узяв гору, і невдовзі ми розкидали їх по всьому рівню. Коли ж зрозуміли, що вони з’являються ще до запланованої сцени, було вже надто пізно щось міняти. На щастя, тісна кімната з отруйними хедкрабами добре спрацювала як тренування, адже їхній дизайн допомагає уникнути типової проблеми з навчанням бою. Зазвичай у таких випадках гравці перебувають у стресі й дратуються, якщо постійно гинуть, не розуміючи чому. Саме це й сталося, коли ми пробували навчати їх одночасно, що таке отруйні хедкраби та їхнє «джерело» — отруйний зомбі. Але самі по собі отруйні хедкраби не здатні вбити гравця. Тому, хоча кімната й викликала стрес, вона принаймні не створювала відчуття несправедливості."
N/A4130"#commentary\cn_217_poison_zombie_introduction.mp3" "[ Девід Спейрер ] Обмеження гравця тісним простором, водночас відкриваючи йому огляд назовні, — зручний спосіб підвищити шанси, що він помітить те, на що ми хочемо звернути його увагу. Тут ми спершу підводимо гравця до цього за допомогою стогону, ще до того, як сам отруйний зомбі стане видимим. Спочатку саме ця сцена мала стати першою зустріччю гравця з отруйними хедкрабами, але, як уже згадувалося, ми занадто захопилися й розкидали їх по рівню раніше, зіпсувавши задумане спільне представлення отруйних зомбі та хедкрабів. Утім, зрештою виявилося, що такі перші зустрічі працюють окремо навіть краще."
N/A4131"#commentary\cn_218_final_arena.mp3" "[ Ерік Сміт ] Коли ми закінчили перший прохід над Рейвенхолмом, цей дах планувався як місце фінального бою. Як і багато інших локацій у Рейвенхолмі, він спершу створювався винятково як цікаве візуальне середовище. Нам здавалося важливим, щоб, залишаючи Рейвенхолм, гравець мав момент, аби озирнутися на місто, у якому він щойно вижив, і заодно побачити, куди він прямуватиме далі. Кілька команд, що працювали над ігровим процесом, пробували створити тут кульмінаційний бій, але тісна геометрія й обмеження продуктивності так і не дозволили нам створити фінал, яким ми були б задоволені. Подібно до самої саги Half-Life, здавалося, що Рейвенхолму судилося залишитися без справжнього завершення."
N/A4132"#commentary\cn_219_tables_and_bodies.mp3" "[ Ідо Маґал ] Наприкінці роботи над Рейвенхолмом, коли всі основні елементи вже були готові, ми пройшлися локацією та спробували заповнити кожен порожній простір чимось цікавим. При цьому потрібно було бути обережними: використовувати тільки наявні інструменти й матеріали та не вигадувати нічого нового, аби не ризикувати появою нових багів. Часто, як у цій кімнаті, ми прагнули додати нові моменти ігрового процесу й водночас дати більше деталей та оповіді для зони. Такі невеликі сцени дозволяють уважному гравцеві замислитися над тим, що він бачить, і що це може означати для майбутніх подій."
N/A4133"#commentary\cn_220_physics_object_consistency.mp3" "[ Керрі Девіс ] Усі фізичні об’єкти мають набір параметрів, що визначають їхню поведінку: масу, кількість шкоди, яку вони витримують до руйнування, на які уламки розлітаються тощо. Спочатку ці параметри вручну задавали дизайнери рівнів для кожного предмета — так працювала більшість речей у грі. Але згодом ми зрозуміли, що створили собі проблему: у грі були тисячі фізичних об’єктів, і жодного способу гарантувати їхню узгодженість. У результаті на одному рівні картонна коробка могла розлетітися від одного пострілу з пістолета, а на іншому була абсолютно невразливою. Між собою ми жартома називали такі невідповідності «злочинами» дизайнерів рівнів. Щоб виправити ситуацію та хоч якось упорядкувати все, ми створили систему, яка робила параметри всіх фізичних об’єктів узгодженими на основі їхньої візуальної моделі. Оскільки більша частина гри вже була побудована, ми змушені були дозволити дизайнерам вибірково відмовлятися від цієї системи в окремих випадках, коли їм потрібно було зробити щось «злочинне» для збереження задуманого. Таких дизайнерів ми називаємо «рецидивістами» — і деякі з них досі ведуть своє «злочинне» життя у Valve."
N/A4134"#commentary\cn_222_fast_zombie_introduction.mp3" "[ Ренді Ландін ] Це ще одна зона, спочатку створена для E3 2003, де ми демонстрували бій гравця із загоном солдатів Комбінації. Коли ми повернулися сюди, щоб представити швидкого зомбі, то постаралися зберегти якомога більше з попередньої роботи. Ми хотіли отримати культовий кадр у місячному сяйві: зомбі, що стрибають на тлі місяця, немов перевертні, щоб привернути увагу гравця. Щойно цей момент відбувся, ми вперше запускаємо швидкого зомбі безпосередньо в ігровий простір і кидаємо його на гравця. Щоб знайти баланс між ефектним освітленням і досягненням ігрових цілей, довелося пройти чимало ітерацій."
N/A4135"#commentary\cn_223_ravenholm_gameplay_focus.mp3" "[ Майк Дюссо ] Переглянувши безліч ігрових тестів Рейвенхолма, ми зрозуміли: ядро цього рівня — гравітаційна гармата й фізика. Усвідомивши це, ми відчули, що можемо правильно вибудувати перехід до Рейвенхолма й дати гравцеві час на засвоєння та розуміння того, що на нього чекає далі. Так буває часто: спершу ми створюємо маршрут рівня, з’ясовуємо, що працює, а вже тоді проєктуємо його пролог. Наступний набір приміщень ми зробили саме з цією підготовчою метою. Жорстокість інструментів, які ми даємо гравцеві, допомогла задати потрібний тон — перевести атмосферу з відносної безпеки лабораторії Елі у щось похмуріше й тривожніше."
N/A4136"#commentary\cn_224_player_tools.mp3" "[ Стів Бонд ] На цьому етапі гравці вже непогано освоїли фізику Half-Life 2, але щойно отримали гравітаційну гармату — новий спосіб взаємодії з об’єктами. Ми експериментували з різними речами, які можна було пускати в хід: дискові пили, катапульти, вибухові каністри, капкани, списи та інше. Залишили тільки ті, що справді добре працювали з гарматою, а решту відкинули. Потім ми просто прибрали звичні боєприпаси з рівнів, аби гравець мусив виживати, покладаючись саме на ці підручні об’єкти."
N/A4137"#commentary\cn_225_contrived_setups.mp3" "[ Керрі Девіс ] У навчанні з гравітаційною гарматою й фізичними об’єктами є доволі очевидна постановка. Гравець витягає зі стіни пильний диск — і саме в цей момент із-за рогу кульгає зомбі, немов спеціально створений, щоб отримати цим диском у лоба. Потім гравець пролазить під пасткою з обертовими лезами, щоб вимкнути її, і одразу ж з’являються три зомбі, провокуючи знову її ввімкнути. У нас не було багато часу на доопрацювання цієї ділянки, тому ми робили сцени, які гарантовано спрацюють для будь-кого, а не відкриті ситуації, що залежать від «правильного» вибору гравця. Так, такий дизайн може трохи знижувати креативність, але в цьому випадку, як ми побачили, гравцям, схоже, було цілком байдуже, що ми їх трохи підштовхували до потрібного рішення."
N/A4138"#commentary\cn_226_misteaching_flinches.mp3" "[ Керрі Девіс ] Ще один незабутній ігровий тест і водночас приклад того, яка небезпека може критися в неправильному навчанні гравців стався в Рейвенхолмі. Один із наших принципів дизайну полягає в тому, щоб гра максимально реагувала на дії гравця. Тому, коли ми робили гравітаційну гармату, здавалося очевидним: якщо націлити її на зомбі й натиснути спусковий гачок, щось має статися. Ми додали просту річ — крихітну шкоду й анімацію здригання. Це виглядало природно й приємно відчувалося у грі. Але на одному з тестів гравець одразу відкрив цю фішку й вирішив, що гравітаційна гармата справді шкодить зомбі... що було правдою, просто дуже повільно. Тож він почав без кінця бити струмом бідолаху, поки той зрештою не помирав. Це був жахливий спосіб битися: нудний, затягнутий і ще й нелюдяний — особливо враховуючи, що навколо валялися пильні диски та вибухові каністри. Ми швидко зрозуміли помилку й прибрали анімацію здригання зовсім, навіть попри те, що втратили маленьку, але приємну взаємодію між зомбі та гравітаційною гарматою. У цьому випадку краще було відмовитися від простого ефекту, ніж давати гравцеві хибний сигнал, що гравітаційна гармата — це повноцінна зброя проти зомбі. Іноді навіть найпростіші принципи вимагають компромісів, коли доходиш до деталей."
N/A4139"#commentary\cn_227_fire_trap.mp3" "[ Стів Бонд ] Ця вогняна пастка спершу створювалася як демонстраційний елемент системи вогню, але згодом дизайнер рівнів перетворив її на елемент ігрового процесу для Рейвенхолма. У процесі розробки її не раз збиралися вирізати через навантаження на слабкі ПК — прозорі спрайти спричиняли надто багато повторних прорисовок. Та зрештою знайшовся програміст, який вважав, що пастка настільки важлива для ігрового процесу, що варто докласти зусиль, вирішити проблеми з продуктивністю й усе ж залишити її у грі."
N/A4140"#commentary\cn_228_hallway_cupboards.mp3" "[ Ян Берньє ] Ці завалені мотлохом коридори стали простим способом уповільнити гравця. Ми прагнули зберегти якомога більше наявної геометрії, а повільні зомбі були головними ворогами, тож важко було завадити гравцям просто проскочити повз. На щастя, образ Григорія як божевільного мешканця Рейвенхолма робив такі барикади цілком логічними — він міг легко заблокувати сходи, аби почуватися безпечніше на дахах. Зрештою його й наше рішення завалити шлях купою меблів збіглися. Адже якщо це зупиняє зомбі, то й гравця хоча б уповільнить."
N/A4141"#commentary\cn_229_pacing_switch.mp3" "[ Стів Бонд ] Тепер, коли гравці пройшли етап навчання, ми можемо змінювати темп — від похмурих, клаустрофобних просторів до арен, орієнтованих на активні бої. Оскільки гравець уже знайомий із різними фізичними інструментами середовища, ми можемо вплітати їх у відкриті простори й просто давати гравцеві свободу обирати власний підхід."
N/A4142"#commentary\cn_230_car_crushers.mp3" "[ Стів Бонд ] Ці автомобільні преси вимагали певних коригувань і чимало роботи з нашою системою фізичної шкоди. Взаємодія великих фізичних об’єктів із негральними персонажами завжди створює труднощі. Наприклад, якщо фізичний об’єкт штовхне NPC, його може занести в місце, звідки він уже не вибереться. Для хедкраба це не проблема — він просто вистрибне, — але зомбі може застрягти й безпорадно борсатися в щілині, куди його затиснуло. І це миттєво руйнує атмосферу хорору виживання, яку ми прагнули тут створити."
N/A4143"#commentary\cn_231_car_crusher_lifts.mp3" "[ Ерік Сміт ] Змусити автомобільні преси ще й підіймати гравця виявилося непросто. Річ у тім, що гравець завжди симулюється одночасно і системою фізики, і системою руху. Щоразу, коли ми оновлюємо стан гравця, ми порівнюємо результати обох систем, обираємо «правильний» і синхронізуємо їх, після чого цикл повторюється. Завдяки цьому обидві системи можуть впливати одна на одну: наприклад, коли гравець стоїть на дошці-гойдалці, фізика змушує її прогинатися, а якщо на автомобільному пресі — він піднімає його вгору. Хоча такий підхід із двома системами був складнішим, він виявився простішим у налаштуванні, ніж спроба об’єднати фізику й рух в одній системі. Їх розділення дозволяло нам точно налаштувати систему руху так, щоб вона добре відчувалася сама по собі, а узгоджувати її з фізикою лише тоді, коли вона безпосередньо впливала на гравця."
N/A4144"#commentary\cn_232_paint_cans.mp3" "[ Стів Бонд ] Коли нам вдалося зробити гравітаційну гармату й фізику основою проходження Рейвенхолма, ми почали переглядати рівні й шукати об’єкти, які могли пропустити, адже ми були зосереджені на по-справжньому агресивних речах — пильних дисках чи вибухових каністрах. Одним із таких забутих предметів виявилася банка з фарбою. І все, що треба було зробити, — підкріпити інтуїтивні очікування гравця: якщо кинути її в зомбі, фарба розбризкається на нього."
N/A4145"#commentary\cn_233_bringing_physics_to_the_enemies.mp3" "[ Том Леонард ] Фізичні пастки в Рейвенхолмі були одними з перших елементів ігрового процесу, якими ми справді залишилися задоволені, але вони не давали гравцеві достатньо свободи. Лише пильні диски допомогли нам зрозуміти, в чому полягає справжня суть Рейвенхолма. Завдяки ним гравець міг застосовувати фізику до зомбі, а не спрямовувати зомбі до фізики. Коли ми це усвідомили, Рейвенхолм почав швидко розвиватися. Ми знову й знову прочісували карту в пошуках будь-чого, особливо чогось незвичного, що могло стати для гравця інструментом чи зброєю."
N/A4146"#commentary\cn_234_ravenholm_development.mp3" "[ Том Леонард ] Ми почали розробляти Рейвенхолм ще на ранніх етапах виробництва Half-Life 2, тож він пройшов більше ніж один повний цикл розробки. Перша версія з’явилася ще до появи гравітаційної гармати, й ігровий процес був зосереджений на традиційних боях із зомбі з використанням вогнепальної зброї та кількох фізичних пасток. Ми навіть планували показати Рейвенхолм на E3 у 2002 році, але зрештою гру презентували лише наступного року, у 2003-му. До того моменту ми вже вклали чимало ресурсів у художнє оформлення Рейвенхолма — зазвичай ми уникаємо цього, доки ігровий процес не буде повністю перевірений. Тож, коли ми повернулися до Рейвенхолма з урахуванням механіки гравітаційної гармати, ми могли працювати з великою кількістю вже готової геометрії рівня, спроєктованої під зовсім інші ігрові цілі."
N/A4147"#commentary\cn_235_grigori_plaza.mp3" "[ Стів Бонд ] Ця відкрита площа була однією з ділянок, які ми повністю деталізували ще під час першого етапу розробки. І коли ми повернулися до неї, то хотіли зберегти якомога більше готового художнього оформлення, водночас спроєктувавши новий маршрут для гравця з використанням усіх трьох вимірів: підйоми й спуски через вікна, переміщення дахами та між будівлями. Простір був невеликий, тож на потрібно було максимально ефективно використати наявний маршрут. А оскільки ця зона від початку створювалася з акцентом на художню демонстрацію, ігрового процесу в ній бракувало, і ми мусили врахувати, що тестувальники часто просто пролітали її без зупинок. До того ж площа вже навантажувала нашу систему рендерингу понад закладений бюджет, тож для нових елементів залишалося зовсім мало ресурсу. Завдання полягало в тому, щоб додати невеликі деталі, які змусили б гравця сповільнитися, — розташувавши загрози за кожним кутом і у кожній шпарині рівня."
N/A4148"#commentary\cn_236_ravenholm_development_2.mp3" "[ Том Леонард ] Коли фанати говорять із нами про Half-Life 2, Рейвенхолм часто називають локацією, яка найбільше запам’яталася. Завдяки численним етапам розробки й високій насиченості контентом, у Рейвенхолмі представлено більше роботи членів команди, ніж у будь-якій іншій локації. Саме тут ми зрозуміли, як застосувати наш художній конвеєр для створення потрібних сцен і настрою, як поєднати фізику й ігровий процес із гравітаційною гарматою, як розвивати хедкрабів і зомбі в Half-Life 2 та багато іншого. Тепер, озираючись назад, ми бачимо, що це підтверджує нашу віру в силу ініціативи окремих людей порівняно з централізованим плануванням. Рейвенхолм — це насичена, надзвичайно ефективна локація як з погляду ігрового процесу, так і художнього виконання. Вона є сумою багатьох невеликих внесків окремих людей, які знали, як трохи посунути межі завдяки своїм унікальним можливостям."
N/A4149"#commentary\cn_237_playtester_archetypes.mp3" "[ Том Леонард ] Ітерації та регулярні ігрові тести були життєво важливими для виробництва Half-Life 2. Щотижня ми тихенько спостерігали через плече за тим, як гравець проходить ділянку, над якою ми працювали, занотовуючи, що працює, а що ні. Для нас було важливо проводити тестування на дуже різних рівнях навичок, щоб уникнути рішень, які підходили лише для вузької групи гравців. З часом ми навчилися підбирати тестувальників залежно від стадії розробки. На початку ми запрошували досвідчених геймерів — зазвичай колег по команді, які могли впоратися з «сирими», незавершеними ділянки й добре пояснити свій хід думок. Для тестування боїв ми залучали гравців усіх рівнів, особливо тих, хто вмів креативно користуватися нашими інструментами. А вже коли рівні ставали відшліфованішими, ми переходили до новачків — людей, які рідко грали або взагалі не були знайомі з шутерами від першої особи. Навіть якщо вони навряд чи купили би гру, ми майже завжди дізнавалися щось цінне, просто спостерігаючи за ними."
N/A4150"#commentary\cn_238_the_real_final_arena.mp3" "[ Том Леонард ] На дуже пізньому етапі розробки Half-Life 2, коли ми переглядали всю гру у пошуках останніх можливостей для покращення, ми зрозуміли: Рейвенхолму таки потрібен справжній фінал. Бою на даху було замало. Після деяких обговорень ми вирішили додати фінальну сутичку на цвинтарі, де Григорій стає пліч-о-пліч із гравцем. Це було ризиковане рішення з точки зору розробки, але ми відчували, що це потрібно. Ближче до завершення виробництва ми вже мали зрілий набір інструментів ігрового процесу, а ще важливіше — ми нарешті зрозуміли саму гру. Створення гри — це завжди процес усвідомлення: чому вона приносить задоволення? Чим відрізняється? Які елементи є ключовими? Поступово, будуючи рівні й дивлячись, як їх проходять тестувальники, ми знаходили відповіді на ці питання й удосконалювали гру. Тому цвинтар вийшов швидко й потребував значно менше ітерацій, ніж більшість попередніх зон."
N/A4151"#commentary\cn_239_cities.mp3" "[ Ерік Кіршмер ] Одним із найскладніших завдань у цій частині було створити відчуття великого міста, хоча наші обмеження продуктивності не дозволяли реально відмалювати щось подібне. Тому ми зробили акцент на щільно стиснутих багатоповерхівках, підземних гаражах, тунелях метро, водопропускних трубах та подібних місцях. Вони цілком природні для міського середовища, але при цьому зазвичай не дають побачити горизонт. Потім ми додали спеціальні точки огляду, де весь простір відведено тільки на ефект панорами. Там ми могли витратити весь наш бюджет продуктивності виключно на видовищний краєвид, не залишаючи ресурсу на ворожий ШІ чи бойові сцени."
N/A4152"#commentary\cn_240_strider_4.mp3" "[ Ерік Сміт ] Хоч ця карта й була виробничою, створеною спеціально для страйдера, у нас все ще залишалася й оригінальна тестова карта для перевірки його ШІ. Ми завжди вважали, що мати надійну карту для тестування ШІ — безцінно: вона дозволяє швидко випробовувати нові ідеї ігрового процесу та легко їх налаштовувати. Якщо виникають баги чи проблеми з дизайном, на такій карті їх простіше ізолювати й прогнати кілька ітерацій. Коли всі функції ШІ уже працюють як треба, ми переносимо їх у виробничі карти, де з ними далі працюють дизайнери рівнів. Тестова карта страйдера складалася з грубих контурів зруйнованих будівель і нескінченних генераторів громадян у різних точках і на різних висотах, щоб забезпечити йому постійний потік цілей. Така конфігурація дозволила відточити ШІ страйдера та його зміни стійок так, щоб він був цікавим і динамічним — та навіть просто спостерігати за ним у дії було захопливо."
N/A4153"#commentary\cn_241_perf_arena.mp3" "[ Аарон Сілер ] Ця арена стала серйозним випробуванням для продуктивності. Її масштаб у поєднанні з роботою ШІ страйдера та громадян буквально виводив систему на межу. Коли ми переносили Half-Life 2 на Xbox, ця арена просто не могла потрапити у фінальну версію без коригувань дизайну. Зберегти початковий задум і водночас забезпечити той самий ігровий досвід за меншої кількості інструментів і простору було дуже непросто."
N/A4154"#commentary\cn_242_space_re-use.mp3" "[ Кріс Ґрін ] Повернення до цієї зони дало нам кілька переваг. По-перше, очевидна річ: створення нових локацій завжди коштує дорого, тож якщо ми можемо додати більше ігрового процесу до вже існуючої зони — це виграш. Але для настільки складного бою, де гравець протистоїть кільком страйдерам, повторне використання простору мало ще одну перевагу. Оскільки гравці вже проходили цю зону раніше, вони вже мають уявлення про планування арени. Цього разу вони рухаються в зворотному напрямку, проте маршрут здебільшого збігається з оригінальним. Така знайомість корисна, коли гравцям потрібно просуватися вперед, збираючи ресурси для бою. До того ж зруйнований війною Сіті-17 дав нам гнучкість у тому, щоб змінювати укриття й додавати дрібні перешкоди на шляху, завдяки чому середовище залишалося динамічним і непередбачуваним."
N/A4155"#commentary\cn_243_tenements_and_courtyards.mp3" "[ Даніка Роджерс ] Ми використали чимало дрібних хитрощів і додали різні функції, щоб створити у гравця враження міста, охопленого війною. Більшість роботи була спрямована на те, щоб показати уривки боїв або дати почути звуки далеких сутичок. Цілі погляду дозволяли щоразу створювати якусь подію, коли гравець дивився у вікно, а інструменти на кшталт Tracer Makers давали дизайнерам змогу імітувати трасуючий вогонь між двома точками. У поєднанні з аудіо це створювало ілюзію перестрілки між двома групами ворогів без потреби запускати будь-який ШІ. Ми також придумали невеликі сюжетні лінії для груп громадян, яких гравець міг бачити кілька разів у міру проходження рівня. Усі ці моменти ретельно відточувалися під час ігрових тестів, аби якнайбільше гравців могли їх помітити та прожити."
N/A4156"#commentary\cn_244_hopper_mine_training.mp3" "[ Даріо Касалі ] Цю гофровану металеву панель ми спеціально розмістили над отвором, щоб підштовхнути гравців перейти на гравітаційну гармату й прибрати перешкоду. Це невелика маніпуляція з нашого боку, адже ми з’ясували: навчати роботі з хоперами набагато ефективніше, якщо гравець одразу пробує застосувати до них гравітаційну гармату. Панель суттєво підвищувала шанси, що вона вже буде в руках. У самому отворі ми розмістили кілька хоперів, щоб у гравця було декілька спроб з ними взаємодіяти й шанс відкрити різні способи їх знешкодження. І ще одна особливість: це перший раз, коли ми проводимо таке навчання, поки з гравцем іде цілий загін громадян. Тож ми використали нагоду й додали кілька діалогових реплік про хопери."
N/A4157"#commentary\cn_245_dog_combat.mp3" "[ Ерік Кіршмер ] Пес — дуже кумедний персонаж, і ми постійно шукали способи залучити його до бою разом із гравцем. Але підібрати для нього правильний масштаб — відповідне оточення, новий ШІ ворогів і, можливо, навіть нових супротивників — швидко виходило за межі проєкту. Щоб створити сценарій бою, який справді віддав би належне Псу й не поступався решті гри, це було б майже як робити окрему гру всередині гри. Ми розуміли: він не може просто підбігти до солдата й вдарити його — це виглядало б не надто вражаюче й без належного відчуття величі. Йому потрібні були загрози більшого масштабу та цікаві способи взаємодії з ними. Зрештою ми вирішили створити велику постановочну сцену, досягнувши кінематографічного ефекту бою за участю Пса без необхідності створювати складний ігровий дизайн."
N/A4158"#commentary\cn_246_strider_2.mp3" "[ Ерік Кіршмер ] Ітерації зі страйдером у цій зоні нарешті дали нам ігровий досвід, яким ми були задоволені: гравцям потрібно було перебігати від укриття до укриття, ухиляючись від його вогню й шукаючи ракети. Ми хотіли, щоб гравці відчували себе так, ніби пірнають в укриття в останню мить, тож налаштували шаблон вогню страйдера так, щоб він чітко сигналізував про наближення небезпеки. Ми також створили систему маршрутів для страйдера, завдяки якій він міг динамічно перемикатися між ними — переслідуючи гравця чи встановлюючи лінію вогню. Це дозволяло дизайнерам рівнів ретельно вирівнювати маршрути страйдера з укриттями гравців, забезпечуючи збалансований досвід. Положення ніг страйдера повністю визначалося кодом, і через його непередбачувані рухи нам часто доводилося вручну підлаштовувати деталі, щоб він надійно штовхав автомобіль чи контейнер із солдатами, коли це було потрібно."
N/A4159"#commentary\cn_247_manhack_tunnels.mp3" "[ Ерік Сміт ] Під час розробки поведінки ШІ для NPC ми з’ясували, що програмісту зручно мати тестову карту для експериментів. Часто така карта поступово перетворювалася на середовище, спеціально створене для демонстрації унікальних можливостей NPC. Згодом, коли ШІ був готовий для використання дизайнерами рівнів, ця тестова карта ставала цінною точкою відліку — без неї дизайнери могли випадково створити сценарії, які робили би цікавий ШІ менш захопливим. У деяких випадках нам навіть вдавалося інтегрувати такі тестові карти безпосередньо в гру. Наприклад, ця невелика ділянка починалася як тунелі, у яких відпрацьовувалася поведінка ШІ людорізів."
N/A4160"#commentary\cn_248_sniper_streets_2.mp3" "[ Ерік Джонсон ] У Half-Life 2 кулі насправді не мають траєкторії польоту — вони миттєво досягають цілі. Але для снайпера, з його низькою скорострільністю та пильною увагою гравця до кожного пострілу, ми захотіли змоделювати політ кулі. Такий підхід також краще працював із лазерним прицілом: спершу мітка гасла, а куля влучала трохи згодом, залежно від відстані до снайпера. Однак це створило нову проблему: ми не хотіли, щоб гравці могли просто пробігти вулицею, ухиляючись від пострілів, тож снайпер мусив вести рухому ціль, передбачаючи, куди потрапить куля. Прогнозувати майбутнє положення гравця було складно, адже він може змінювати напрямок значно швидше, ніж це можливо у реальному світі. Тому ми додали додаткові перевірки, щоб виявляти таку поведінку, — наприклад швидке натискання гравцями клавіш «вліво-вправо» під час бігу."
N/A4161"#commentary\cn_249_triangle_plaza.mp3" "[ Ідо Маґал ] Ця битва на площі була складною постановкою, побудованою на поведінці «Штурм», із двома бойовими лініями, що сходяться — по одній на кожне силове поле. Коли солдати заходять із-за полів, їхні лінії не дають їм прориватися поодинці на площу. У міру того як бій загострюється й солдатів стає більше, бойові лінії починають зсуватися до центру площі, і якщо їх вчасно не відбити, вони можуть просто задавити гравця."
N/A4162"#commentary\cn_250_sniper_streets_3.mp3" "[ Якоб Юнґельс ] Однією з механік, яку ми випробовували на цих вулицях, був вогонь на пригнічення. Багато гравців, причаївшись у кінці вулиці, випускали чергу у вікно снайпера, щоб перевірити, чи це має якийсь ефект. Тож ми експериментували з тим, щоб лазерна мітка короткочасно зникала, даючи гравцям час на переміщення. Але після кількох ігрових тестів ми виявили дві проблеми. По-перше, це порушувало напружений ігровий процес у стилі «рухайся та ховайся», якого ми прагнули завдяки снайперові. Біг під час стрільби майже не відрізнявся від інших дій, які гравець виконує в Сіті-17. По-друге, виникла більш підступна проблема: ті, хто першими відкривав для себе вогонь на пригнічення, вважали його обов’язковим і швидко витрачали весь боєзапас. Якщо патрони закінчувалися на півдорозі, гравці часто здавалися, думаючи, що провалили завдання; якщо ж доходили до кінця, то залишалися без набоїв. Натомість ті, хто проходив сценарій нишком, майже нічого не витрачали. Такий розрив у витратах ресурсів зробив майже неможливим балансування боєприпасів у наступних сценах, тому ця механіка так і не потрапила у фінальну версію гри."
N/A4163"#commentary\cn_251_assault_behavior.mp3" "[ Джон Кук ] Найскладнішою поведінкою, яку ми створили для Half-Life 2, була поведінка «Штурм», що використовується в цій частині гри. Вона давала дизайнерам рівнів змогу будувати бойові сценарії з солдатами Комбінації та громадянами, задаючи бойові лінії між ними й контролюючи те, як розгортатиметься бій залежно від дій гравця. NPC, залучені до штурму, намагалися знаходити вигідні вогневі позиції й користуватися укриттям відповідно до розташування бойової лінії. Коли гравець просувався вулицею, він міг відтісняти лінію вперед — тоді союзні громадяни ішли в наступ, а солдати Комбінації відступали. Або ж гравцеві треба було знести кілька турелей Комбінації чи зняти солдата за барикадою, щоб просунути лінію далі."
N/A4164"#commentary\cn_252_bank_roof_mortar.mp3" "[ Джон Морелло ] Коли ми довели ігровий маршрут рівня до цього місця, стало очевидно: гравцеві було б цікаво скористатися мінометом. Мабуть, про це варто було подумати раніше. «Як думаєте, хтось захоче запускати вибухівку в небо, щоб вона падала на поганців? Так, я теж так вважаю». Урешті-решт, гравці стільки часу були під його обстрілом, що можливість відплатити Комбінації тією ж монетою стала б гарною винагородою. Але щойно ми почали це обмірковувати, зрозуміли, скільки мороки воно потребує — і, чесно кажучи, така думка спадає щодня, коли берешся робити відеогру. Для міномета треба було створити анімації та ефекти поруч із гравцем, а ще підготувати велику роботу з постановки ескалації бою на площі, де його можна застосувати. Але, що ще важливіше, у нас не було інтерфейсу для такої унікальної зброї. Як гравці мали б прицілюватися й стріляти? Важко виправдати купу витраченого часу лише на один момент у грі, тож ми вирішили вкласти сили в інші речі й рушили далі. Вибачайте! Можливо, ми вирішимо дизайнерську проблему міномета вже в якійсь майбутній грі серії Half-Life."
N/A4165"#commentary\cn_253_strider.mp3" "[ Керрі Девіс ] Ця ділянка перед банком стала тим місцем, де ми опрацьовували страйдера. Коли ми вперше побачили його концепт-арт, відразу ж захотіли додати його в гру, але виникла купа запитань: як він працюватиме на практиці? У нашому ігровому світі ми ще ніколи не рухали об’єктів такого масштабу, і при таких розмірах він мав бути по-справжньому небезпечним. Тож як гравці мали з ним боротися? Як і з будь-яким іншим ворогом, головне питання завжди одне: як зробити з цього цікавий ігровий процес? Які інструменти потрібні дизайнерам рівнів, щоб створювати з ним сценарії? Саме на ці питання ми й шукали відповіді під час експериментів на цій карті."
N/A4166"#commentary\cn_254_sniper_streets.mp3" "[ Ерік Кіршмер ] Ці вулиці, де повсюди чатували снайпери, стали місцем, де ми розробляли і самого ворога, і основу того ігрового досвіду, який хотіли дати гравцям. Ми прагнули, щоб снайпер стріляв по об’єктах поруч із гравцем, тому спершу зосередилися на пошуку різноманітних цікавих цілей для цього. Ми з’ясували, що як фактор вибору об’єктів добре працює використання поля зору гравця . Завдяки завжди активному лазерному прицілу гравець постійно бачив індикатор уваги снайпера, і коли він зміщувався на об’єкт, на який дивився сам гравець, це виглядало дуже природно й створювало чудові моменти напруги."
N/A4167"#commentary\cn_255_citizen_squad_details.mp3" "[ Метт Райт ] Як тільки ми сформували загін громадян і почали будувати навколо нього сценарії, виявилося, що він створює інші цікаві можливості. Тестувальники почали перейматися долею окремих членів загону, тож ми додали більше деталей у їхній дизайн. Члени загону могли підбирати кращу зброю, якщо знаходили її, передавати гравцеві боєприпаси, коли ті були потрібні, а медики — зцілювати його за необхідності. Також ми мали забезпечити, щоб загін устигав за гравцем, який часто обирав непередбачувані маршрути. За кадром загін «шахрував» різними способами — відновлював здоров’я між боями, швидко пересувався, щоб наздогнати гравця, і навіть телепортувався, якщо це було необхідно."
N/A4168"#commentary\cn_256_citizen_squads.mp3" "[ Кен Бьордвелл ] Наші ранні тести вуличних боїв між Комбінацією та громадянами виявили проблему: без чітких меж бойовий ШІ міг сильно віддалятися від гравця. Солдати могли відступати, щоб перезарядитися чи сховатися, а ШІ громадян починав їх переслідувати. Нам був потрібен спосіб точніше узгодити дії громадян із цілями гравця, інформуючи їх про те, куди гравець прямує та з якими ворогами хоче вступити в бій. Це привело до створення загону громадян. ШІ громадян використовував цей загін, щоб рухатися разом із гравцем, атакувати тих самих ворогів і забезпечувати простий інтерфейс для команд гравця. Спочатку ми мали складнішу систему команд, але вона швидко виявилася громіздкою, тож ми її спростили."
N/A4169"#commentary\cn_257_ai_behaviors.mp3" "[ Майк Дюссо ] Однією з технологій ШІ, розроблених для Half-Life 2, була система поведінки. «Поведінки» — це фрагменти коду ігрового ШІ, які керували NPC у конкретних ситуаціях. Наприклад, була поведінка «Ведення», що дозволяла NPC направляти гравця, і поведінка «Слідування», яка давала змогу NPC йти за гравцем або іншим NPC. Поведінки працювали разом із базовими діями NPC, тож, наприклад, медик із загону, використовуючи «Слідування», щоб не відставати від гравця, усе одно вмів стріляти по ворогах, ухилятися від гранат і навіть простягнути аптечку."
N/A4170"#commentary\cn_258_occlusion.mp3" "[ Брайан Джейкобсон ] У Half-Life 1 і більшій частині Half-Life 2 світ складався переважно із замкнених тунелів і коридорів, які добре працювали з бінарним розбиттям простору (BSP-деревом). По суті, ця технологія дозволяла швидко впорядковувати геометрію й визначати, що саме може бути видимим у полі зору гравця. Але відкриті простори на узбережжі та в інших зовнішніх локаціях не підходили для такого підходу, тож нам знадобилися нові рішення. Одним із них стали портали областей: вони ділили світ на окремі сегменти, розділені порталами — дверима й вікнами (і ні, не тими самими з Aperture Science). Ми також розробили додаткову систему оклюзії, яка, по суті, працювала за принципом: «Якщо гравець не може бачити крізь великий об’єкт, над ним чи навколо нього, то не потрібно рендерити те, що по інший бік». Звучить очевидно, але доводилося добре попрацювати, щоб обчислення «що ж там за об’єктом» не займало більше часу, ніж просто зробити рендеринг усього підряд. Щоб пришвидшити цей процес, дизайнери рівнів розміщували великі об’єми оклюзії всередині основних форм ландшафту та великих об’єктів, як-от будівель. Під час рендерингу ми могли перевіряти межі сутностей відносно цих об’ємів і таким чином уникати показу того, чого гравець усе одно не бачить."
N/A4171"#commentary\cn_259_detail_objects.mp3" "[ Брайан Джейкобсон ] Як тільки ми запустили зовнішні ділянки, стало зрозуміло, що їм бракує дрібної високочастотної деталізації. Тому ми додали невеликі елементи рослинності — траву, кущі тощо — по всьому рельєфу зі зміщеннями. Але ми знали, що не можемо собі дозволити (іншими словами: у нас не було часу) розставляти їх вручну. Тож ми створили систему об’єктів деталізації, яка автоматично генерує дрібну рослинність на основі матеріалу зміщення. Кожен матеріал задавав тип рослинності для розміщення разом із набором параметрів. Під час компіляції карти система обчислювала випадкові точки на поверхні й обирала, яку рослинність там розмістити. З огляду на обмеження продуктивності залишався ще доволі складний етап ручного створення листів текстур рослинності, що дозволяло рендерити все це за один етап."
N/A4172"#commentary\cn_260_displacements_1.mp3" "[ Чарлі Браун ] Після релізу Half-Life 1 наші дизайнери рівнів і художники захотіли мати кращий інструмент для створення зовнішніх середовищ, тож ми розробили першу версію нашої системи рельєфу. Вона ґрунтувалася на підрозділених квадратах. Уявіть собі пласку квадратну поверхню, розбиту на сітку, де кожну точку можна рухати вгору або вниз. Дизайнери рівнів могли з’єднувати кілька таких квадратів і, користуючись інструментом-пензлем, формувати пагорби й долини, регулюючи висоту точок сітки. Для рендерингу ми застосовували спеціальну змішану текстуру, яка поєднувала дві різні поверхні. У кожній точці сітки задавалося, в якій пропорції використовувати кожну текстуру, що забезпечувало плавні переходи між піском, травою, ґрунтом і гравієм. Подібні системи рельєфу не були рідкістю в ігрових рушіях того часу, і ми наївно думали, що цього нашим геймдизайнерам буде достатньо."
N/A4173"#commentary\cn_261_displacements_2.mp3" "[ Чарлі Браун ] Коли перша версія системи рельєфу запрацювала, ми очікували, що дизайнери рівнів використовуватимуть її для відкритих просторів. Але натомість вони почали експериментувати, додаючи деталі в найнесподіваніших місцях. Вони накладали підрозділені квадрати на стіни, щоб створювати зруйновані краї, заокруглювали вуличні бордюри й навіть пробували робити труби. Успіх був різний, адже систему рельєфу розробили для ландшафтів, а не для архітектурних деталей. Тож ми знову повернулися до кодової рутини й перетворили висотно-базовану систему рельєфу на повноцінну систему тривимірних зміщень. Тепер дизайнери могли рухати точки сітки в будь-якому напрямку, а не лише вгору-вниз. Це дало змогу додавати деталі до найрізноманітніших поверхонь, використовуючи змішані текстури для плавних переходів між зміщувальними квадратами та геометрією бінарного розбиття простору (BSP). Втім, для цього знадобилися додаткові технічні доробки, щоб забезпечити узгоджене освітлення між двома рендерами, інакше краї виглядали б помітно розбиття. Але після цього дизайнери рівнів залишилися задоволеними, і ми наївно думали, що цього разу справді буде достатньо."
N/A4174"#commentary\cn_262_displacements_3.mp3" "[ Чарлі Браун ] Маючи в руках загальну систему зміщень, дизайнери рівнів не зупинилися лише на деталізації світу й повернулися до своїх первісних цілей — створення масштабних зовнішніх локацій. Це призвело до чергових оновлень, покликаних збалансувати продуктивність, щоб система могла обробляти і дрібну деталізацію, і великі ділянки рельєфу. Довелося вдосконалити й текстурування, особливо для підтримки складних структур, таких як навислі скелі, неможливі в початковій висотній системі. Дизайнери, не схильні спочивати на лаврах, також почали застосовувати зміщення для створення печер і тунелів. Хоча ці доповнення виглядали чудово, вони потребували ще більшого технічного доопрацювання. Зрештою нам вдалося узгодити всі суперечливі вимоги до різних способів використання системи, і вона увійшла у великі частини ігрового світу. Озираючись назад, можна сказати, що зміщення — це яскравий приклад того, як технології та ігровий дизайн розвиваються разом. Це класична проблема «курки й яйця»: ми не можемо передбачити всі варіанти впливу технології на гру, але й не можемо створити технологію, не знаючи, для чого вона потрібна. Тож, як завжди, ми починаємо з обґрунтованого припущення й дивимося, куди воно нас приведе."
N/A4175"#commentary\cn_263_particles.mp3" "[ Кріс Ґрін ] Для рушія Source ми інвестували в розширення технологій частинок і спецефектів. Це дозволило створювати більш реалістичний і складний рух частинок, а також хитромудріші форми й шейдерні ефекти. Особливо велике значення мало додавання рельєфного текстурування до частинок — воно суттєво покращило їхній об’ємний вигляд. Хоча пізніші версії рушія Source включали потужний редактор системи частинок, у початковій версії, використаній у Half-Life 2, усе трималося на ручній роботі: кожен ефект програміст мав створювати вручну з максимальною ретельністю, і це було доволі трудомістко."
N/A4176"#commentary\cn_264_cubemaps.mp3" "[ Кріс Ґрін ] З появою матеріалів і шейдерів нам знадобилося рішення для відбиваючих поверхонь — скла чи сталі. Такі поверхні мали «знати», що саме відображати, але в 2003 році ми ще не могли виконувати подібний рендеринг у реальному часі. Тож ми розробили систему кубічних карт для попередньо обчислених відбиттів. Кубічна карта — це набір із шести зображень, розташованих на внутрішніх гранях куба, які фіксують оточення в усіх напрямках — наче панорамна фотографія, що охоплює вас з усіх боків. Дизайнери рівнів розставляли по картах невидимі маркери, і під час компіляції ми генерували кубічну карту для кожного з них. Потім, у грі, коли потрібно було зробити рендеринг відбиваючої поверхні, ми знаходили найближчу попередньо обчислену кубічну карту й використовували її для створення відбиття."
N/A4177"#commentary\cn_265_water_shader.mp3" "[ Ґері Мактаґґарт ] Найскладнішим шейдером, який ми створили для гри, був шейдер води, що повністю використовував можливості нових програмованих відеокарт. Якщо на рівні була вода, сцену доводилося рендерити тричі: спершу підводний світ для заломлення, потім відбитий вигляд, і нарешті — об’єкти над водою. Під час рендерингу поверхні води ми поєднували зображення з заломленням і відбиттям, показуючи більше відбиття під гострими кутами завдяки рівнянню Френеля. Ми також відстежували глибину дна під поверхнею, роблячи воду прозорішою й менш викривлюючою на мілководді. Крім того, нам довелося розробити два альтернативні методи рендерингу для слабших відеокарт: на картах середнього рівня відображалося спрощене відбиття без заломлення й прозорості, а на найслабших — лише частково прозора поверхня."
N/A4178"#commentary\cn_266_normal_maps.mp3" "[ Ґері Мактаґґарт ] Half-Life 2 розроблялася в епоху бурхливого розвитку графіки, коли на ринку з’явилися перші відеокарти з підтримкою програмованих шейдерів. Завдяки цій технології ми стали одними з перших, хто реалізував карти нормалей — метод, що значно покращував освітлення поверхонь. Карта нормалей описувала мікрорельєф поверхні, дозволяючи освітлювати кожен піксель полігону так, щоб поверхні виглядали набагато об’ємнішими й деталізованішими, ніж це було можливо в Half-Life 1."
N/A4179"#commentary\cn_267_rendering_systems.mp3" "[ Ґері Мактаґґарт ] На початку 2000-х ми не могли дозволити собі універсальний рендерер із широкими можливостями сучасних рушіїв. Обмеження центрального та графічного процесорів, а також пам’яті вимагали дуже специфічних рішень для задач рендерингу, щоб ми могли витиснути максимум продуктивності з апаратного забезпечення гравців. У результаті в Half-Life 2 фактично було три різні рендерери: один для геометрії світу, другий для зовнішнього рельєфу, а третій для динамічних об’єктів, таких як персонажі та предмети. Ці три рендерери мали підтримувати складну матрицю функцій: зіткнення, трасування променів, декалі, попередньо обчислене освітлення, розрахунки видимості тощо. Крім того, кожен рендерер мав працювати з DirectX 7, 8 і 9. Відмінності між цими версіями DirectX були значними і часто вимагали різних підходів до зберігання даних і рендерингу; у них навіть використовувалися різні мови програмування! Загалом це фактично означало дев’ять різних рендерерів, кожен із яких потребував унікальних рішень, і забезпечити однаковий вигляд між ними було однією з найскладніших технічних задач, з якими ми зіткнулися під час розробки."
N/A4180"#commentary\cn_268_dynamic_shadows.mp3" "[ Ґері Мактаґґарт ] Зосередившись на персонажах і фізичних об’єктах, ми вважали необхідним створити динамічну систему тіней, щоб показати їх у всій красі. У 2003 році графічні процесори ще не мали спеціальних можливостей для обробки тіней, які є сьогодні, тож продуктивність була серйозною проблемою. Наше остаточне рішення виглядало приблизно так і виконувалося кожного кадру. Спершу ми визначали всі об’єкти, які могли відкидати тіні в полі зору. Для цього треба було знайти ті, що перебували в піраміді видимості або трохи поза нею — щоб урахувати сутності, невидимі на екрані, але тінь яких могла потрапити в кадр. Потім ми рендерили чорну «тіньову» версію кожного з цих об’єктів в єдину текстуру тіней. Для цього використовувалася модель із найнижчим рівнем деталізації, щоб процес був максимально швидким. Нарешті, ми застосовували цю текстуру тіней для відтворення тіней у полі зору гравця, затемнюючи вже відрендерені пікселі. Ми акуратно вирізали кожну тінь у цій текстурі, щоб у випадку перекриття кількох тіней вони правильно накладалися одна на одну. Приємно згадувати, як ми тоді це реалізовували, але загалом зараз усе набагато краще, адже сучасні графічні процесори роблять цю задачу значно простішою."
N/A4181"#commentary\cn_269_combinatorial_shader_explosion.mp3" "[ Ґері Мактаґґарт ] Рендеринг став набагато складнішим під час розробки Half-Life 2 через додавання апаратних шейдерів — невеликих фрагментів коду, що керували тим, як відображається кожен піксель поверхні. У 2003 році шейдери були значно обмеженішими, ніж сьогодні: шейдери часів Half-Life 2 не підтримували умовних операторів і мали суворі обмеження на розмір коду. Це означало відсутність логіки if/else для зміни поведінки залежно від умов і неможливість створювати великі шейдери з широким набором функцій. Крім того, компіляція шейдерів за потреби була занадто повільною, тож нам доводилося компілювати їх заздалегідь. Щоб працювати в цих межах, ми обчислювали всі можливі комбінації й зберігали кожну окремо як її власний шейдер. Наприклад, якщо шейдер працював із поверхнею, освітленою одним джерелом світла, то для двох джерел потрібна була ще одна версія, для трьох — ще одна, і так далі. А якщо шейдер також підтримував карту нормалей, для кожної кількості світел потрібні були вже по дві версії — з картою нормалей і без. Додавання функцій на кшталт змішування текстур, тонування вершин, дзеркальних відблисків, альфа-тестування та різних типів освітлення (спрямованого, точкового, прожекторного) призвело до вибухового зростання кількості шейдерів. На момент релізу ми мали тисячі окремих шейдерів. Невдовзі після цього ми випустили Lost Coast із підтримкою HDR, і кількість шейдерів знову подвоїлася. Коли компіляція шейдерів на локальних комп’ютерах розробників почала забирати надто багато часу, ми перейшли на розподілену компіляцію по всій мережі за допомогою VMPi. Також ми мали режим динамічної компіляції шейдерів, який був корисним для розробки: він забезпечував швидкий результат, але призводив до короткочасних пригальмовувань частоти кадрів у моменти компіляції."
N/A4182"#commentary\cn_270_gpu_wild_west.mp3" "[ Джей Стеллі ] Під час розробки ми стикалися з багатьма рішеннями, на які впливав вибір мінімальних характеристик — найменш потужної комбінації центрального (ЦП) та графічного процесорів (ГП), що все одно мала забезпечити прийнятний ігровий досвід. На початку 2000-х різноманіття серед ГП було набагато більшим, ніж сьогодні: відмінності стосувалися не лише швидкодії, а й фундаментальних підходів до рендерингу. Проте тоді ми не мали реальних даних про апаратне забезпечення наших гравців. Які ЦП та ГП вони використовували? Скільки оперативної пам’яті мали? Яку версію Windows? Ми звернулися до Microsoft у надії, що вони знають відповіді на запитання на кшталт: «Скільки карт із підтримкою DX7 чи DX8 зараз у використанні?» На жаль, у них також не було цих даних. Усвідомивши, що без такої інформації ми ризикуємо ухвалювати помилкові рішення, ми розробили інструмент аналізу, який дозволяв гравцям надсилати нам характеристики свого «заліза», й інтегрували його в ранню версію Steam. Дані виявилися настільки корисними, що ми вирішили зробити їх публічними, запустивши у квітні 2003 року опитування Steam про апаратне забезпечення (Steam Hardware Survey). Відтоді воно допомагає нам і, сподіваємося, іншим розробникам приймати обґрунтовані рішення."
N/A4183"#commentary\cn_271_3d_skybox.mp3" "[ Джей Стеллі ] Ми завжди прагнули відтворити світ, який здавався би більшим, ніж дозволяють обмеження нашої карти. У Half-Life 1 ми використовували текстуру кубічної карти, щоб гравці могли бачити за межі ігрової зони. Але в Half-Life 2 ми хотіли, щоб цей вид на більший світ був динамічним, а не просто статичною текстурою. Розмір нашої карти був обмежений приблизно на півмилі в кожному вимірі, та ми зрозуміли: можна створити значно більший зовнішній світ, якщо зберігати його у зменшеному масштабі. Так ми винайшли 3D Skybox. Це маленька коробка, прихована всередині справжньої ігрової карти, яка містить геометрію у масштабі 1/16. У ній є контрольна точка, що відповідає початку координат основної карти. Під час рендерингу простору за межами ігрової зони ми використовуємо геометрію з 3D Skybox, розташовану за цією контрольною точкою й збільшену в 16 разів. Найскладнішим було домогтися плавного поєднання освітлення й туману між основною картою та скайбоксом, але зрештою нам це вдалося. У результаті світ став виглядати значно масштабнішим і з глибшим ефектом занурення, ніж у Half-Life 1."
N/A4184"#commentary\cn_272_missing_material.mp3" "[ Джей Стеллі ] На ранньому етапі розробки низькорівневого графічного коду ми зрозуміли, що буде складно помітити полігони без текстур. Зазвичай у такому випадку вони просто відображалися чорними, і в темних сценах це легко лишалося непоміченим. Щоб надійніше виявляти таку помилку, ми створили візуально очевидну «текстуру помилки», яка автоматично генерувалася щоразу, коли текстура не завантажувалася. Так з’являлася тепер уже культова фіолетово-чорна шахівниця, що згодом зажила власним життям далеко за межами Half-Life 2."
N/A4185"#commentary\cn_273_air_resistance.mp3" "[ Джей Стеллі ] Однією з важливих функцій, яку ми додали до фізичного рушія Half-Life 2, став опір повітря. Тоді фізичні рушії зазвичай використовували загальне демпфування для уповільнення об’єктів під час руху. Але воно просто симетрично прибирало енергію. Щоб зробити рухи більш правдоподібними, ми вирішили змоделювати саме опір повітря. Це дало нам асиметричну поведінку: швидкість уповільнення об’єкта залежала від того, яка площа його поверхні була обернена в напрямку руху чи обертання. Ця функція стала ключовою для того, щоб вибухи та предмети, кинуті гравітаційною гарматою, виглядали переконливо. Об’єкти, що швидко рухаються і швидко обертаються — одні з найбільш ресурсомістких для симуляції у рушії Half-Life 2, тож опір повітря ще й поліпшував продуктивність ЦП у випадках вибухів. Крім того, він допомагав показати різницю матеріалів і мас предметів. Щільніші об’єкти легше відштовхують повітря, і це помітно. Завдяки цьому ефекту різниця між картонною коробкою та дерев’яною дошкою стає очевидною, а об’єкти у світі Half-Life 2 загалом здаються значно реалістичнішими."
N/A4186"#commentary\cn_274_early_tech_planning.mp3" "[ Кен Бьордвелл ] Реліз гри завжди багато чого нас навчає — ми нарешті бачимо, які рішення спрацювали, а що наступного разу варто було б зробити інакше. Тож після Half-Life 1, коли ми сіли думати, яким може бути сиквел, у нас був цілий ворох відгуків від гравців для опрацювання. На їх основі ми склали головний список напрямів, на яких мала зосередитися Half-Life 2. Ми не намагалися вигадати конкретний досвід гравця, а радше підходили до питання з технологічного боку. Охоронці й науковці в Чорній Мезі добре себе показали — а що, якби ми зробили значно більший акцент на персонажах? Нам подобалася наша інтерактивна розповідь — а що, якби ми змогли робити її ще різноманітнішою? Дослідження та взаємодії в Чорній Мезі були захопливими для гравців — можливо, фізична система дала б змогу розвинути це ще далі? У всіх цих сферах ми намагалися уявити найкращу версію гри, якою вона могла б стати за кілька років, і вже від цього відмотували назад, складаючи список технологічних кроків, які могли привести нас до цього."
N/A4187"#commentary\cn_275_character_lighting.mp3" "[ Кен Бьордвелл ] У перший рік розробки ми щосили намагалися зробити персонажів настільки реалістичними, як того хотілося. Насправді було чимало різних проблем, і кожна зрештою вимагала окремих технологічних та художніх рішень. Першою серйозною проблемою стало освітлення. На той час у ігрових технологіях було безліч спрощень — частково через обмеження продуктивності, але здебільшого через нерозуміння, як світло взагалі працює. Щоб персонажі виглядали добре, у їхні моделі й текстури вбудовували більшість рішень — тіні, блиск і навіть відчуття об’єму. Виглядало це ефектно, але водночас штучно: було видно, що це саме «ігрові» персонажі. Алікс ми спершу теж робили за цим принципом: з «запеченим» освітленням, як актрису з власною мобільною світловою установкою, що гарантувала їй гарний вигляд за будь-яких умов. Але все це не спрацювало. У динамічному світі гри вона могла виглядати чудово в одних умовах і повністю нереалістично в інших. Ми пробували посилювати її «світлову установку», але швидко стало зрозуміло, що це глухий кут. Тоді ми все відкинули й почали заново: моделі, текстури, освітлення. Цього разу ми зосередилися не на тому, «як має бути красиво», а на тому, як воно працює в реальному світі. Це, можливо, звучить очевидно, але тоді в іграх так не робили. Цікаво, що поза рендерером нові моделі й текстури виглядали гірше, ніж попередні. Але поступово ми позбулися всіх спрощень і хибних уявлень про те, як працює світло, текстури й графічні карти, і зібрали все заново. І коли ми, нарешті, побачили Алікс у грі, в динамічному середовищі, де вона завжди виглядала однаково переконливо — вона просто засяяла. Абсолютно органічна, цілісна, частина світу Half-Life 2."
N/A4188"#commentary\cn_276_gamma_correction.mp3" "[ Джон Морелло ] Наш рушій має систему рендерингу, яка збирає дані про стан гри й обчислює колір для кожного пікселя на екрані. Але в цьому процесі беруть участь не лише наш код, а й програмне й апаратне забезпечення інших людей — зокрема графічні процесори та монітори. На певному етапі розробки ми були незадоволені тим, як виглядають персонажі. Вони здавалися восковими, навіть хворобливими. Шкіра виглядала неправильно. Ми довго налаштовували освітлення, але так і не змогли знайти баланс: або персонажі виглядали краще, або світ — і навпаки. На щастя, у нас ще був повнофункціональний програмний рендерер, який дозволяв нам запускати гру без графічного процесора (тоді це було актуально, адже багато гравців узагалі не мали відеокарт). І коли ми подивилися гру через нього, проблеми зі шкірою зникли. Це означало, що проблема не в нашому освітленні. Ми ретельно передивилися весь код рендерингу, шукаючи баг, але марно. Тоді ми звернулися безпосередньо до виробників графічних процесорів і попросили перевірити, чи не спотворюють вони наші значення пікселів. Так почалася майже дворічна переписка. Нам навіть довелося створити систему, яка відстежувала колір окремого пікселя на всіх етапах рендерингу, щоб довести свою правоту. Зрештою ми переконали виробників: на їхніх картах гамма-корекція виконувалася неправильно, на рівні низькорівневої математики. Після виходу нових драйверів наші персонажі одразу почали виглядати так, як і мали — так само, як у програмному рендерері."
N/A4189"#commentary\cn_277_facial_technology.mp3" "[ Кен Бьордвелл ] Ми хотіли, щоб гравці справді переживали за наших персонажів. А щоб мати хоча б шанс на це, треба було серйозно вкластися у технології для створення облич. Люди інстинктивно звертають увагу на обличчя — підсвідомо й постійно. Тож планка тут була надзвичайно високою: якби ми не дотягнулися до неї, ми б відштовхнули гравців від персонажів замість того, щоб наблизити до них. Ми почали з довгих досліджень — і вони були невтішними. Найкращі приклади високоякісної міміки просто не могли відтворюватися в реальному часі. А ті, що працювали в реальному часі, були далекі від якості, яку ми прагнули отримати. Ми хотіли рівня анімаційного кіно, але там один кадр міг рендеритися годинами й створювався сотнею аніматорів, тоді як у грі персонаж мав динамічно говорити репліки поверх емоцій, згенерованих діями гравця, — і все це силами кількох художників. У підсумку ми звернулися до системи кодування рухів обличчя доктора Пола Екмана (FACS), розробленої ще у 1970-х. Вона дала нам словник для опису міміки в інструментах і коді, а також ціль, на яку можна було рівнятися. І ми вирішили застосувати її повністю, тоді як інші брали лише окремі фрагменти. Це означало багато часу на ітерації: як втиснути всі ці рухи в обмеження продуктивності, що в нас були. Ми також досить довго просто спостерігали за людьми, шукаючи «дрібниці з великим ефектом» — на кшталт еластичності шкіри чи тіней на зубах. І зрештою, хоча ми й не змогли реалізувати все, нам вдалося втілити найважливіше для того, щоб міміка персонажів виглядала переконливо."
N/A4190"#commentary\cn_278_eye_shader.mp3" "[ Кен Бьордвелл ] Ще одним критично важливим елементом для створення переконливих облич стали очі. Люди надзвичайно добре «читають» по очах. У мозку навіть є спеціальна ділянка, яка відповідає за це — аж до того, щоб визначати напрямок погляду за відблисками на рогівці. Але тут є безліч дрібних нюансів, які мають значення. Очі насправді не є ідеальними сферами. Коли рухається рогівка, повіки деформуються. Рух очей впливає на ймовірність моргання. Самі очі розташовані не точно за зіницею, а з невеликим зміщенням. Здається, це дрібниці, але їхня відсутність одразу б’є по правдоподібності персонажа. Ми довго працювали над очима, поступово вдосконалюючи модель очного яблука та набір його функцій. Частину речей довелося реалізовувати через зовнішні інтерфейси — наприклад, щоб персонаж міг фіксувати погляд на чомусь у середовищі. Інші працювали на підсвідомому рівні ШІ, як-от моргання. Здавалося б, очевидна необхідність річ, але якщо воно виглядає неправильно — відразу збиває з пантелику. Особливо велике значення мали відблиски в очах. На екрані вони займають мізерний простір, але різниця від них була колосальна. Ми зрозуміли, що нарешті впоралися, коли побачили: без шейдера очей персонаж виглядав як лялька — ніби й людина, але щось у цьому відштовхувало. А щойно ми його вмикали, миттєво виникало відчуття, що на нас дивиться справжня жива людина."
N/A4191"#commentary\cn_279_combine_gunship.mp3" "[ Кен Бьордвелл ] Штурмовик став для нас цікавою проблемою. У нас уже була модель польоту гелікоптера, і часу створювати щось зовсім нове не було. Тож ми налаштували її так, щоб вона відчувалася інакше, а з отриманих у симуляції значень побудували органічні анімаційні стани штурмовика. Ми прагнули зберегти все максимально реалістичним. Наприклад, у нього є фізичне обмеження на те, наскільки він може повернути передню частину, щоб навести гармату. Якщо цього кута замало, він має змінити траєкторію польоту, щоб повернути гармату у потрібний бік — просто «читерити» йому заборонено. Іншою ключовою особливістю був звук двигуна. У нас була система просторового звучання, тож гравець міг орієнтуватися, де саме він знаходиться. Але оскільки штурмовик швидко рухається і летить високо в небі, далеко від орієнтирів, важко визначити його відстань і швидкість. Щоб це виправити, ми додали ефект Доплера: висота звуку двигуна змінюється залежно від його швидкості відносно гравця. Цей ефект ледве помітний, але неймовірно ефективний: він допомагає підсвідомо визначити, де саме перебуває штурмовик і куди він рухається. Це критично важлива інформація, яка дає вам зрозуміти, що він полює на вас."
N/A4192"#commentary\cn_280_risk.mp3" "[ Кен Бьордвелл ] Озираючись на Half-Life 2 зараз, через 20 років, розумієш, наскільки жахливим був увесь процес розробки. Створення ігор — це завжди важко. І ти ніколи не маєш того, чого найбільше хочеш: можливості оцінити ризики наперед, ще до того, як почнеш додавати до них нові. Візьмімо нашу технологію анімації облич. Потрібно було, напевно, 3–4 роки роботи, перш ніж ми могли б бути впевнені, що вона справді запрацює. Але чекати стільки часу ми не могли. Уже в перший рік ми почали ухвалювати рішення щодо дизайну гри, створення ресурсів та інших технологій, виходячи з припущення, що анімація облич у фіналі буде працювати — і якісно, і продуктивно. Якби цього не сталося, багато з тих рішень також не спрацювали б. І так було не лише з анімацією. Інші великі рішення ми також робили наосліп. Ми мусили будувати — і лише сподіватися, що наші припущення виявляться правильними через багато років. Це було жахливо."
N/A4193"#commentary\cn_281_hugs_and_pickups.mp3" "[ Кен Бьордвелл ] Іноді навіть найпростіші речі можуть стати справжнім кошмаром. Наприклад, змусити одного персонажа обійняти іншого чи навіть просто підняти предмет зі столу може створити купу проблем. І все це ще більше ускладнюється нашим динамічним середовищем, в якому персонажі й об’єкти не мають фіксованих позицій, а гравець постійно носиться й заважає. Для цього потрібна дуже хитромудра синхронізація. Складність у тому, що люди роблять усе це автоматично. Коли ви йдете до столу, щоб підняти чашку, тіло вже готується: ноги й руки займають правильне положення, і все збігається саме в той момент, коли ви дотягуєтеся до предмета. Якщо ж ви йдете когось обійняти, то обидва робите це одночасно, постійно підлаштовуючись одне під одного. Щоб відтворити це в грі, ми мусили навчити персонажів бути свідомими не лише світу, а й одне одного. І навіть більше — мати уявлення про свої наміри наперед. Є спокуса розбити дію на прості кроки — підійти до столу, подивитися на чашку, взяти чашку. Це зручно й легко повторно використовувати. Але так діють роботи, а не люди. Наші персонажі мали знати, що вони йдуть до столу саме з наміром взяти чашку, щоб синхронно виконати всі мікрорухи й схопити її в потрібний момент. А коли таких персонажів двоє, то це взагалі схоже на справжні переговори: обоє повинні «домовитися», де й коли все станеться. І зробити це без збоїв. Такі моменти взаємодії зазвичай короткі, але вони критично важливі для того, щоб персонажі виглядали правдоподібними."
N/A4194"#commentary\cn_282_ropes.mp3" "[ Майк Дюссо ] У всіх референсах, які ми збирали для Сіті-17, ми помітили, що всюди були кабелі й дроти. Вони становили значну частину дрібної деталізації міста. Нам дуже подобався вигляд цих старих європейських вулиць, обплутаних хаотичною мережею сучасних комунікацій. Ми зрозуміли, що нам потрібне рішення для кабелів, тросів та подібних елементів — і що вони обов’язково мають бути динамічними. Дизайнери рівнів із ентузіазмом створювали головоломки з розетками, і підключення шнура до кожної допомагало гравцям краще зрозуміти саму механіку. Ще на ранніх етапах ми створили систему тросів і постійно вдосконалювали її в процесі розробки. Усередині кожен трос складався з кількох сегментів між двома кінцевими точками, які могли рухатися незалежно. Кожен сегмент діяв як пружина й реагував на сили в грі — від легкого вітру до гуркоту штурмовика Комбінації, що пролітав над головою. Під час рендерингу сегменти завжди розверталися до камери й мали рельєфну текстуру, що було вкрай важливо для того, щоб троси виглядали об’ємними й реалістичними."
N/A4195"#commentary\cn_283_vmpi.mp3" "[ Майк Дюссо ] Під час розробки нас дедалі більше розчаровувала повільність ітерацій ігрового процесу, головним чином тому, що компіляція карт, необхідна для попереднього розрахунку освітлення й видимості, займала години. А комп’ютери у 2000 році були набагато повільніші за сучасні та мали лише одне ядро процесора. Натхненні SETI@Home — розподіленою програмою, яка використовувала ПК по всьому світу для аналізу радіосигналів у пошуках ознак позаземного життя, — ми створили власну систему VMPi. Вона розподіляла процес компіляції карти між усіма офісними комп’ютерами. Сьогодні подібні системи запускають на гігантських кластерах графічних процесорів, але тоді ми просто використовували всі комп’ютери в офісі. Щоб встигати за нашим кодом освітлення, який розвивався так само швидко, як і карти, VMPi також розповсюджувала нові .exe-файли на всі комп’ютери й одразу їх запускала. Озираючись назад, це виглядає як повний кошмар для будь-якого айтішника: ми фактично надсилали довільний виконуваний файл на всі робочі ПК, і вони просто його виконували. Абсолютне божевілля. Але цей підхід спрацював: швидкість ітерацій карт зросла в рази, і зрештою VMPi стала для нас дуже важливим інструментом."
N/A4196"#commentary\cn_284_field_of_view.mp3" "[ Керрі Девіс ] У Half-Life 1 ми використовували 90-градусне поле зору (FOV), що тоді було доволі стандартним для шутерів від першої особи. Але під час розробки Half-Life 2 воно перестало нас влаштовувати. Оскільки гра була сфокусована на персонажах, ми витратили багато зусиль на деталізовану анімацію облич і тіл, але при FOV 90 гравець не міг достатньо наблизитися, щоб повністю оцінити ці деталі. Тож ми почали експериментувати зі зменшеним полем зору й зрештою зупинилися на 75 градусах. І нам, і гравцям довелося трохи звикати до цього, а ще знадобилося окреме поле зору для моделей від першої особи — зброї, яку гравець тримає внизу екрана. Адже вони були створені під 90 градусів і при 75 виглядали дещо спотвореними. Але ця зміна дозволила нам зробити те, що ми хотіли, — поставити наших персонажів в центр уваги."
N/A4197"#commentary\cn_285_reference_maps.mp3" "[ Ренді Ландін ] Оскільки наші персонажі в Half-Life 2 стали значно правдоподібнішими порівняно з Half-Life 1, ми хотіли, щоб і сам ігровий світ відчувався так само реалістичним. У Half-Life 1 обмеження шутерів від першої особи часто підштовхували нас до використання стилізованих або абстрактних середовищ. Але в Half-Life 2 ми прагнули створити сетинг, який би виглядав наближеним до реальності — а це вимагало уваги до безлічі дрібниць, які раніше залишалися поза увагою. Одним із ключових кроків стало створення еталонних карт, щоб стандартизувати перенесення реальних пропорцій у гру. Вони визначали такі параметри, як розміри стін і дверей, висота дверних ручок, інтер’єрне освітлення, масштаб меблів і загальний масштаб типових об’єктів. Ми також розробили стандартизовані текстури для дизайнерів рівнів — із закладеними значеннями масштабу та освітлення, щоб макети з самого початку були узгодженими. Окрім налаштування фізичного світу, ці еталонні карти визначали й те, як гравець рухатиметься в ньому: на яку висоту він може стрибати, наскільки низько пригинатися, а також розміри проходів на кшталт вентиляційних шахт. Використовуючи ці карти як основу, ми змогли зберегти узгоджену геометрію світу та забезпечити реалістичні пропорції середовища у всій грі."
N/A4198"#commentary\cn_286_response_rules.mp3" "[ Скотт Далтон ] Ми з самого початку знали, що хочемо бачити в грі багато динамічних діалогів, тож нам потрібна була система, яка могла б ефективно з цим працювати. Ми прагнули зробити її такою, щоб звукорежисери могли додавати й редагувати репліки без допомоги програмістів, щоб діалоги були тісно пов’язаними зі станом гри й при цьому мінімізували повтори. З огляду на ці вимоги ми створили систему Response Rules («правила реагування»). Кожного разу, коли персонаж говорить поза межами заздалегідь зрежисованої сцени, саме ця система визначає, яку репліку він промовить. Замість того, щоб підбирати репліки напряму, ШІ персонажів постійно відмічає «можливості для промови» щоразу, коли відбувається якась подія: помічання гравця, отримання шкоди, використання останнього патрона, зіткнення з переважаючими силами ворога тощо. Під час такої події він надсилає системі «правил реагування» пакет даних про поточний стан гри, а система повертає найбільш відповідну репліку — якщо вона передбачена. Такий підхід дозволив нашим звукорежисерам створювати справжню матрицю прийняття рішень для діалогів. Наприклад, у персонажа можуть бути різні репліки для оголошення про перезарядку: під час обстрілу, після завершення бою, коли в живих лишився тільки один союзник або якщо в полі зору з’явився страйдер. На момент релізу Half-Life 2 ми відчували, що лише трохи торкнулися потенціалу цієї системи. В Episode One вона стала ключовою для Алікс, а згодом лягла в основу динамічних діалогів у наших наступних іграх — від класів у Team Fortress 2 до персонажів Left 4 Dead."
N/A4199"#commentary\cn_287_audio_caching.mp3" "[ Ян Берньє ] Ще однією проблема, з якою ми зіткнулися — колосальний обсяг звуку у грі. Ігрових ефектів, музики й діалогів було занадто багато, щоб тримати все в оперативній пам’яті, яка у 2003 році була на вагу золота. Але, як можна здогадатися, звуки мали відтворюватися миттєво, особливо ті, що безпосередньо стосувалися ігрового процесу. Тож ми створили аудіокеш, який зберігав у пам’яті лише перші 125 мс кожного аудіофайлу. Це число було нашим найкращим припущенням про те, скільки часу потрібно, щоб встигнути підвантажити повний файл із диска. Коли в грі запускався звук, його початок програвався з кешу і паралельно починалося завантаження всього файлу. До того моменту, як кешований уривок закінчувався, файл уже встигав завантажитися, і звук не переривався. Були й додаткові функції — наприклад, нещодавно використані звуки залишалися в пам’яті повністю, щоб ті, що відтворюються часто, не доводилося підвантажувати знову й знову. У сучасних рушіях цей підхід став універсальним: так кешують не лише звук, а й будь-які інші ресурси."
N/A4200
39184201}
39194202}