Минуло багато років, як я зробив gamedev, але крім приємної відповіді, я хочу додати і деталізувати деякі речі.
Перше, що вже згадувалося, полягає в тому, що результат є просто зоровим і слуховим проти жорстких "критичних FPS" обмежень та обчислювальних / бюджетних пам'яток. Ідеї коректності розмиваються, коли питання більше нагадують: "Чи добре це виглядає? Чи працює це гладко, без заїкань? Це чудово звучить?" в той час як розробники налаштовують і налаштовують і наближаються, тоді як співпраця дизайнерів / розробників призводить до того, що речі виглядають і звучать дещо по-різному з кожною швидкою ітерацією.
Ще одне - тестери можуть бути приголомшливими! Я ніколи не знаходив більш виділеної групи тестерів в будь-якому іншому домені, оскільки вони хочутьперевірити програмне забезпечення. Вони веселяться. Вони залежні і сплять поруч із комп'ютером, вивчаючи кожен куточок гри. Виявити навіть неясні глюки стає досить легко, коли люди насправді розважають ретельно випробовуючи кожен куточок програмного забезпечення, а практично його залежать від нього. У моїй нинішній галузі з тестерами трохи складніше працювати, оскільки багато з них є професіоналами, які пов'язують свій життєвий шлях із програмним забезпеченням, і тому вони покладаються на кілька функцій, щоб виконати свою роботу, і не обов'язково зацікавлені у виснаженні кожен куточок і крихітка весь час. Природно, коли ми не можемо так сильно покластися на людських тестерів, нам потрібно більш автоматизоване тестування.
Ще одне полягає в тому, що база даних коду для гри, як правило, не підтримується і не змінюється і не розширюється роками та роками. Це не так, як розробникам Super Mario, які спочатку розробили його на монтажі 6502, довелося зберігати щось, що нагадує цей оригінальний код задовго після доставки гри. Doom 3, ймовірно, використовує нульові рядки коду (або закрити) від Doom 1. Якщо є франшиза, що триває, новіші ігри більше нагадують "продовження", ніж "оновлення". Більшість ігор просто доставляють і, можливо, випускають кілька патчів, DLC, а потім робиться код. Це величезний контраст від моєї індустрії VFX, де я працював над підтримкою коду, починаючи з днів Amiga, який переносився та підтримувався десятиліттями. Ігри зазвичай не '
Однією з причин такого недовговічного коду баз ігор є те, що вони настільки прив'язані до обладнання. У поєднанні з їх найсучаснішим характером та критичними вимогами до FPS, вони часто не можуть бути розроблені таким чином, щоб витягувати деталі апаратних засобів, навіть не закриваючи. Вони часто пишуться дуже спеціально для цільового покоління обладнання, і зазвичай недовго до того, як PS3 заміняється PS4, який потім застаріває і замінюється PS5 тощо, і все дуже швидко. Можливості апаратних засобів відіграють настільки важливу роль у розробці та розробці гри, що, як правило, не варто намагатися підтримувати багато того самого коду, написаного для PSX, як для PS4, наприклад, більшість ігрових франшиз, які тривають поколіннями, все ще пишуть свої двигуни нового покоління значною мірою за основу для новітнього обладнання.
З короткотривалою кодовою базою настає обмежений час обслуговування (тобто обмежений час, протягом якого код має бути змінений). З обмеженим часом для зміни коду, який не охоплює роки, коли розширення двигуна збільшується і збільшується з кожним оновленням, а також у поєднанні з тим, що ігри ніде не наближаються до критичних місій, не існує такої абсолютно критична потреба застосувати найбільш вичерпне тестування блоку та інтеграції. Немає користі робити це у забезпеченні цілісності майбутніх змін, якщо майбутні зміни не будуть вноситись, а аспект тестування та рефакторингу застарілих кодових баз, природно, не має значення, якщо в першу чергу немає "спадщини".
Ще одна невелика, яка не завжди актуальна - це те, що гра може націлювати лише на дуже вузький спектр обладнання без будь-яких портів на робочому столі. У цих випадках величезне джерело непередбачуваних збоїв у цих контекстах - це користувачі, які працюють із програмним забезпеченням із корінним обладнанням та драйверами.
Однак, інтеграційне тестування на найвищому / найгрубішому рівні, як правило, може бути корисним відразу. Наприклад, багато ігор можуть використовувати спосіб запису, як змінюється стан гри з часом для "повторів". Такі функції відтворення можуть гарантувати, що гра є детермінованою, а також використовуватись як форма інструменту тестування самостійно для відтворення ігрового сеансу, записаного раніше кимось іншим.
Я також стикався з гамедеями, що працюють в невеликих студіях, які робили такі речі, як писати ботів для своєї гри, і боти грали в гру з максимальною швидкістю і виконували цю симуляцію, спочатку стикаючись із незрозумілою аварією через день-два, потім виправляли її, потім запустив симуляцію ще раз і повторював, поки не було більше збоїв, що зупиняли показ, навіть після запуску його протягом тижнів. Отже, є такі цікаві прагматичні підходи, як той, який я бачив від gamedevs до тестування свого програмного забезпечення, але часто таким чином, що нагадує найгрубіший рівень інтеграційного тестування та дуже сильно моделює речі до того, як гравці насправді взаємодіють із грою.
Нарешті, ці великі ігрові двигуни AAA починають нагадувати зовсім інший вид звіра: триваліший термін експлуатації, успішно обробляючи обладнання трохи краще, з більшими базами коду та довшими тривалістю обслуговування, тоді як редактори їх рівня починають нагадувати повноцінне середовище розробки. Я думаю, що ці великі двигуни, ймовірно, зажадають більш ретельної процедури тестування, особливо якщо час їхнього коду значно збільшується. Ще багато ігрових студій не пишуть величезних ігрових двигунів AAA: вони або ліцензують їх, або розробляють невеликий фірмовий движок, який значно менший за обсягом і не буде підтримуватися роками.