Як працюють патчі в іграх?

37

Ігри консолей та ПК іноді мають виправлення, щоб виправити помилки, які розробники пропустили / не встигли виправити.

Моє запитання - як вони працюють?

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

console pc patching

Ви хочете змінити складені ігри, які ви зробили, використовуючи невеликий патч?

— вовкдаун

Ні, мене просто цікавить теорія, що стоїть за нею. Мої ігри досить малі, щоб їх просто перекомпілювати і розповсюдити всю гру знову :)

— MulletDevil

4

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

— вовкдаун

3

Кілька мегабайт не "мало". Припустимо, у нас три мегабайтний файл, який становить шість мегабайт виконуваного коду, стислий. Припустимо, що вказівки в середньому мають шість байтів, тож це близько мільйона інструкцій. (Нехай ігнорують статичні дані, такі як літеральні рядки та що-небудь.) Якщо рядок C відповідає приблизно десяти машинним інструкціям, це 100 000 рядків коду. Це здається достатньою для основного двигуна гри. Більшість розмірів інсталяції будуть такими, як карти текстури, екрани, відеопослідовності.

2

кілька мегабайт можуть бути невеликими, все залежить від того, що в ньому є і який відсоток від загальної бази коду, що є. Якщо, скажімо, всю карту рівня 3D потрібно замінити через обрані формати файлів тощо, включаючи всі текстури і що ні, то кілька мегабайт можуть бути дуже маленькими.

— jwenting

30

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

Ви можете взяти цю концепцію далі і спробувати знайти області з двох файлів, де дані однакові, і повністю їх опустити.

Нарешті, ви можете використовувати структуру кожного типу файлів на вашу користь. Наприклад, в EXE ви можете упакувати кожен метод окремо (лише ті, що змінилися) та відновити EXE самостійно під час застосування патчу; майте на увазі, однак, що це дуже ймовірно в царині надмірності і, можливо, не варто докладати зусиль (виграш над простим bdiff може не виправдати зайвої складності, яка може зламатись у дикій природі). В якості іншого прикладу ви можете використовувати різні файли для сценаріїв.

Однак більшість систем виправлення в дикій природі беруть найпростіший шлях: вони просто пакують файли, які були змінені - вони не намагаються лише змінити пакунки в межах цих файлів (напевно, з поважної причини, більшість контенту ігор вже стиснуті і створюють патчі проти високих ентропія або стислі дані взагалі не працюватимуть ).

— Джонатан Дікінсон
джерело

Що ви маєте на увазі під упаковкою кожного методу в exe окремо. Це практично?

— вовкдаун

@ArthurWulfWhite так. Для Інді-хаус, мабуть, не варто часу, оскільки це займе велику кількість часу та зусиль (вам, по суті, потрібно написати власний лінкер) - як компанія, що займається виключно "технологією латки", варто було б докласти зусиль. Все залежить від того, наскільки великий виконуваний код - я швидко переглянув Sacred 2, і він становив 26 Мб (8 Мб для основного EXE). Бінарний розбіг, можливо, зможе наблизитись до нього - все-таки це ідея, яку варто поставити там (я знаю, що КАП добре стискає EXE, оскільки вони користуються перевагою структури).

— Джонатан Дікінсон

Це дуже цікаво. Я вважаю, що пропускна здатність є такою, якою вона є сьогодні, мінімізація розміру патчів ігор не є основною проблемою. +1 цікава, продумана відповідь.

— вовкдаун

У більшості ігор це не можливо здійснити виправлення окремих методів. Компілятор може мати досить різний вихід з навіть простими змінами коду. Рішення автоматичного вбудовування можуть змінюватися, може змінюватися макет таблиці символів тощо. Зміни коду також часто змінюють внутрішню структуру API. Оптимізації вже розмивають межу між межами функцій порівняно з тим, що ви бачите в редакторі коду. Системи DRM також сильно каламутять воду. Патч-системи використовують оптові заміни або бінарні розрізники та стискають їх. Все, що ви пропонуєте, просто занадто крихке для доставки в реальному світі, imo.

— Шон Міддлічч

2

@SeanMiddleditch Я збираюся це зробити лише для того, щоб довести, що це можливо :).

— Джонатан Дікінсон

15

Виконаний код гри не завжди знаходиться лише у виконаному файлі, часто він поділяється на кілька динамічних бібліотек (наприклад, ігрові, графічні та звукові двигуни), власне виконуваний файл і, можливо, безліч сценаріїв для різних цілей.

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

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

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

2

Ви можете згадати це як приклад: daemonology.net/bsdiff

— wolfdawn

2

Гарна практична відповідь. +1

— вовкдаун

2

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

У більшості сучасних ігор є сотні меґів даних про ігри (в основному текстури, моделі, дані про рівні тощо). Вони вимагають виправлення досить часто. Наскільки мені відомо, видавці зазвичай мають стандартний власний спосіб цього зробити.

Потрібно сказати, що є приклади з відкритим кодом. Деякі дистрибутиви Linux (Fedora?) Використовують двійкові розрізки для своїх патчів. Ви можете дослідити їх і прочитати їх вихідний код або документацію.

— MarkR
джерело

-1

Сучасні diffалгоритми можуть ефективно знаходити послідовності байтів, спільні між двома бінарними файлами. Не дивно, якщо задуматися. Стиснення файлів також залежить від знаходження однакових послідовностей байтів.

Після того, як у вас з'явиться список однакових послідовностей байтів, вам просто потрібно надіслати старі та нові зміщення, довжину і, звичайно, все, що є абсолютно новим. Що стосується приймальної сторони, то це пряма збірка. Скопіюйте біти, які потрібно зберегти зі старого файлу, заповніть нові біти.

Створити виправлення стає ще простіше, якщо ваш лінкер може виплюнути MAP-файл, у якому перераховано зміщення кожної функції у файлі.

— MSalters
джерело