«Думаю, золота доба вже позаду»: як розробляли ігри в дев’яностих і нульових

Сучасні ігри створюють великі команди, студії з різних кутків планети, а для розробки вони використовують UE5, штучний інтелект і потужне «залізо». Та в індустрії були й культові проєкти, які працювали без цього всього і були приголомшливими: згадати хоча б Diablo та DOOM.

Нещодавно цікаве обговорення на цю тему з’явилося на Hacker News. Там безліч розробників згадали, як їм вдавалося робити ігри 20–30 років тому. А ще міркували про те, чи стали ігри складнішими сьогодні. Публікуємо найцікавіші з цих відповідей.

Оригінальний пост звучав так:

«Цікаво дізнатися, як такі ігри, як RollerCoaster Tycoon, SimCity 2000, Warcraft II й Descent (ця мене вражає), вдалося створити й запустити на комп’ютерах, які мали жорсткий диск 500 МБ, центральний процесор на 300 МГц і 4 МБ оперативної пам’яті? І як ОС Windows 95 змогла залишитися настільки маленькою?

Чи можливо відтворити цей рівень ефективності на сучасних системах? Запитую, тому що мене цікавить створення відеоігор-симуляторів. Dwarf Fortress і Rimworld зрештою страждають від однієї проблеми: процесор просто помирає.

Якщо я створюю вікно з C++ і SFML, використовується 60 МБ оперативної пам’яті (і це зовсім не вражає). Якщо я поміщу на екран 3 000 000 плиток (за допомогою Vertex Arrays), використовується 1 ГБ оперативної пам’яті (оце от вражає) і я можу плавно панорамувати всі плитки. Які ще методи доступні?»

Dave_Rosenthal: Доводилося перемальовувати лише ту частину на екрані, де був рух

Я створював ігри в 90-х. Очевидно, найскладнішою частиною тоді була графіка.

Ми мусили враховувати, скільки інструкцій в пікселі на кадр можна собі дозволити. Адже у 90-х важко було оновити всі пікселі навіть на дисплеї 320×200×8 біт (тобто в стандартному режимі на 256 кольорів) зі швидкістю 30 кадрів на секунду. Тож доводилося перемальовувати лише ту частину на екрані, де був рух. Завдяки цьому з’явились такі ігри, як Donkey Kong, де світ був статичним і оновлювалися лише кілька елементів.

У 90-х ми дійшли тієї точки, коли з’явився процесор Pentium на 66 МГц (фантастика!). Тоді ваші 66 МГц / 320 (висоти) / 200 (ширини) / 30 (кадрів на секунду) давали вам 34 такти на піксель. 34 — це значно більше, ніж треба для bitblt з 2D (наприклад, для обробки пам’яті в кожному рядку в спрайті), тож ми могли перейти від 2D-ігор, схожих на Маріо, до 3D.

З частотою пікселізації на 34 такти ви можете написати мапер текстур (в assembly), який мав приблизно 10–15 тактів на піксель (якщо пам’ять не зраджує) і залишити кілька циклів для всього іншого. Ви також мали підтримувати низький overdraw-рівень (щоб кожна частина екрана малювалася лише один-два рази). За допомогою цих методів ви могли створити гру, де була б 3D-графіка та оновлення в кожному кадрі.

Іншою великою проблемою було те, що тоді операція з рухомою комою була повільною (а деякі процесори могли мати чи не мати співпроцесорів з рухомою комою), тому ми використовували багато математичних операцій з нерухомою комою та наближеннями. Складнощі були з тим, щоб виконувати ділення, потрібне для обчислень перспективи в 3D-іграх. Операція була суперповільною, і фіксовані коми тут не працювали. Одне ділення на піксель могло перевищити всі ваші обмеження! «Правильні з погляду перспективи» текстурні мапери не були поширені в 90-х, а ігри типу Descent, які покладалися на них, використовували багато наближень, щоб виконати операцію швидко.

Скриншот з гри Descent 1995 року

Agentlien: Дуже схоже на те, як ми працюємо сьогодні

Чесно кажучи, хоча нині цифри більші, а операції з рухомою комою швидко виконуються на сучасних процесорах, але те, що було тоді, все ще дуже схоже на те, як ми працюємо сьогодні. Нещодавно я провів два роки в команді продуктивності, де ми працювали над великою інді-грою. І більшість часу я просив художників спростити меші, покращити рівні деталізації, збільшити кількість фрагментів, які відсікатимуться (Culling) тощо. Моя робота полягала в оптимізації самого рендерингу.

snorkel: Всім нам доводилося платити за додаткові 2 МБ, щоб пограти в Doom

Графіка (і звук) мали значно нижчу якість, були менші світи, менше персонажів, менше рухів. Кадри з персонажами готувалися наперед; підлоги та стелі були пласкими, текстури мали менше кольорів, світло й тіні заздалегідь наносилися на статичні поверхні, ігровий код налаштовувався на продуктивність рівня асемблерного коду, текстури були симетричні та низькоконтрастні... І всім нам доводилося платити за додаткові 2 МБ оперативної пам’яті, щоб пограти в Doom.

DeathArrow: Писати оптимізований код на C чи асемблері було просто

Я займався графікою, застосовуючи режим 13h, пізніше з VGA. Це було значно легше, ніж використовувати Vulkan або DX12. Процесори були простішими, а з DOS і Windows 95 було значно легше працювати, ніж з Windows 10.

Тобто писати оптимізований код на C чи асемблері було просто. Якщо ми повернемося на 10 років, програмування на мікропроцесорах Z80, MOS Technology 6510 чи Motorola 68k було насправді ще простішим.

djmips: Продюсер ніяк не міг второпати, на що я згаяв два місяці

Я також працював над ААА-грою у дев’яностих, однією з перших 3D FPS ігор з величезною історією. Кожна деталь в пам’яті гри була налаштована. Одного разу я витратив понад два місяці просто на те, щоб зайти й зменшити кожну структуру, видалити непотрібне та звести змінні до абсолютного мінімуму. Були (Bools) зберігалися в одному біті. Якщо змінній знадобилося б менше ніж 256 значень, вона б зберігалася в одному байті. Я змінив багато структур даних, аби все максимально оптимізувати. Нетехнічний продюсер ніяк не міг второпати, на що я згаяв два місяці, але дуже радів, що гра працює і _нічогісінько_ в грі наче й не змінилось, все виглядає так само.

TacticalCoder: Багато ігрових жанрів уже тоді досягли досконалості

Для AI-ворогів справи дійсно покращились: ми досягли прогресу. Але для геймплеїв типу «людина проти людини» в дев’яностих ми мали практично все.

Warcraft II через Kali (для симуляції локальної мережі через інтернет, бо ж у Warcraft II не було battle.net) мав фактично геймплей Warcraft III: Reforged.

Half-Life і її мод Counter-Strike були фактично сучасними FPS.

Diablo II (розробка для Windows 1995 розпочалася у 1997 році, а гра вийшла у 2000) була по суті ідеальною з погляду кооперативного геймплею та досконалою грою в жанрі hack ‘n’ slash.

Це було настільки ідеально, що нещодавно Blizzard випустила гру з ідентичним ігровим процесом, навіть більшість помилок повторила (деякі вже виправила, як-от баг з оновленням eth armor). Це та ж гра, але із сучасною графікою.

Ігри були настільки хороші, що навіть через два з лишком десятки років ви можете повторно випустити той самий геймплей з оновленою графікою. Бо це була досконала річ.

Тому я дуже не погоджуюся з тим, що «ігри мали простіший геймплей». Багато ігрових жанрів уже тоді досягли досконалості саме з погляду ігрового процесу. Відтоді їм просто додають блиску.

jpgvm : Чекаю, що за мого життя настане нова золота епоха з VR/AR

Тодішні ігри справді були набагато складнішими, адже не треба було дбати про універсальну привабливість кожної гри, бюджети були значно скромнішими. Я думаю, що золота доба ігор вже позаду, але з нетерпінням чекаю, що за мого життя настане нова золота епоха з VR/AR.

meheleventyone: Cучаcна реалізація стала навіть простішою

Я погоджуюся, що зазвичай це був не такий простий геймплей, але простіша симуляція. А в деяких жанрах, зокрема в іграх RTS, сучасна реалізація стала навіть простішою, ніж колись. По суті геймплей має певний ліміт складності, якого ми вже досягли у 90-х. Сьогодні ми можемо робити значно складніші моделювання, але рівень складності на перший погляд не надто відрізнятиметься.

thewileyone: Ви маєте працювати в рамках своїх обмежень

Проста відповідь полягає в тому, що ви маєте працювати в рамках своїх обмежень. Раніше я працював у компанії, яка займалась електронною комерцією, це був дуже ранній конкурент Amazon. Оскільки інтернет тоді був дуже повільним, у нас було правило, що наша домашня сторінка повинна бути менше як 100 кБ, включно з іконками зображень. Кожен стиснутий шматок на 1 кБ був святом. Навіть сьогодні домашня сторінка Amazon важить менше за 1 МБ, перевірте. Тепер із CSS-фреймворками, JS-фреймворками, ad-фреймворками та перехресними посиланнями сторінки завантажуються вічність навіть з меншими обсягами контенту.

Трохи корисних ресурсів

georgewsinger: Я раджу глянути це відео. У ньому співзасновник Naughty Dog Енді Гевін розповідає про різні хаки, які використовували на першій PlayStation, щоб забезпечити плавну і безперебійну роботу Crash Bandicoot. Повну версію подивитися також варто.

pkphilip: Дев’яності були часом, коли ми робили що завгодно, аби вичавити кожну дрібку продуктивності з обладнання. Одна книга на цю тему виділяється серед інших — це праця Майкла Абраша "Graphics Programming Black Book«(є на GitHub і на Dr. Dobb’s). Тепер потужність процесора, кількість ядер, розміри оперативної пам’яті й жорстких дисків, можливості відеокарти зросли, тож розробники більше не вичавлюють продуктивність, як раніше.

smcameron: Пам’ятаю, читав групу новин comp.graphics.algorithms, коли тільки з’явилася Descent. Люди трохи божеволіли, намагаючись зрозуміти, як ця штука працює. Я знайшов оцю сторінку, яка пояснює, що там робилося для візуалізації текстур.

Нагадаємо, нещодавно ми публікували інтерв’ю з розробником «Героїв 3» Девідом Мюлліхом , який почав створювати ігри ще наприкінці 70-х. Він розповів про свою кар’єру, правила геймдизайну, роботу в Disney та поділився враженнями про український геймдев.

Підписуйтеся на Telegram-канал @gamedev_dou, щоб не пропустити найважливіші статті і новини