Чому ігри, здавалося б, перезавантажують весь рівень при перезапуску рівня?


47

Чи дійсно дані так змінилися під час гри?

Я припускаю, що тривала пауза між перезавантаженням рівня - це перезавантаження всього рівня. Але мені здається, що добре реалізована система повинна просто мати можливість «пінг» до початку рівня.

Це більш помітно на консолях, але це не помітно на іграх на ПК.


8
Відповідь на це дуже залежить від гри, від розробників, їх звичок та досвіду та багатьох інших факторів. Єдина правильна відповідь на загальному рівні буде: іноді модифікований багато, іноді немає, іноді речей потокові в і , таким чином , початок не в пам'яті більше, а іноді гри вже робити «пінг» назад до початку рівня, і ігри, які іноді не мають вагомих причин, чому вони не можуть цього зробити, а іноді це просто тому, що вони недостатньо реалізовані
Крістіан

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

Питання не чорно-біле. Скільки штату перезавантажено? Безліч ігор перезавантажують цілі набори текстур без поважних причин. Звичайно, перехід від 5 до рівня 6 може означати завантаження нових текстур, але це не означає, що ви повинні робити це кожного разу, коли ви (повторно) починаєте рівень 6
MSalters

@MSalters В основному це стосується стану гри, а не ресурсів, можливо, вам не потрібно буде перезавантажувати загальну текстуру використання, але більше ворога, якого ви вже вбили - об'єкт для цього потрібно знищити і перезавантажити в початковому стані (навіть якщо його текстура все ще добре зберігається в пам’яті.)
Том «Блакитний» Піддок,

Я думаю, що хтось грав у Wing Commander III у спадок.
Ерік Реппен

Відповіді:


54

Ну а тепер - яке просте, але цікаве питання вирішити.

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

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

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

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

  • Видаліть будь-які динамічно створені гібриди для цієї стіни (але не видаляйте їх із стану, який ви завантажили)
  • Видаліть частинку пилу з отвору для кулі
  • Замініть / відремонтуйте стіну, щоб позбутися від створених отворів
  • Скиньте боєприпаси до програвача
  • І т.д. ...

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

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

Отже, для великих рівнів вмісту - завантаження одного стану замість обчислення та "перемотування" одного:

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

Однак, як протилежний приклад бойової гри (чудовий приклад з реального життя, як Street Fighter 4), можливо, не потрібно буде перезавантажувати все, що багато активів, щоб перезапустити рівень. Два гравці, стан середовища для рівнів та прості рівні таймери здебільшого статичні та не динамічні (здоров’я гравців завжди відновлюється на 100% кожен раунд, таймери скидаються на 90 секунд, а рівень не має отворів від куль [чи це робиться!] ) і таким чином скидання рівня є справою відновлення бійців до повного здоров'я та повернення довкілля до початкових позицій (як, наприклад, глядачів на деяких рівнях).

Отже, для бойової гри при проведенні реваншу (не переходячи з раунду в раунд) вам потрібно:

  • Скиньте здоров'я та енергію на макс. Чи за замовчуванням (завжди однакові на персонажа)
  • Скидання таймера
  • Скинути початкові положення символів
  • Скиньте місцевість до стану за замовчуванням (жодних отворів від куль не виправити чи перезавантажити!)

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

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

Я сподіваюся, що це пролило трохи світла на ваше запитання.


7
Чудова відповідь ... цинічна сторона мене поставила б ваше: "менше роботи для чортів" вище за список ... але, можливо, його реалізація двигуна могла б бути кращою.
Меш

3
А як щодо відновлення помилок? NPC не рухається через помилку у фізичній системі, витік пам’яті тощо. Навіть якщо гра ретельно перевірена, такі речі все одно трапляються і повинен бути спосіб перевести гру в відомий і робочий стан.
Султан

9
Менша робота - це завидною метою досягнення, а не предмет сорому. Ви можете витратити тиждень, щоб створити систему перемотування назад і місяць, щоб виправити всі помилки, або перезавантажити та отримати інші функції =)
Патрік Хьюз

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

1
+1 Я просто хочу уточнити, що перезавантаження рівня та завантаження рівня - якщо перезавантаження все викидає і починається з нового завантаження - не потрібно писати нового коду для досягнення мети гри. Система перемотування назад - це абсолютно новий набір коду, який нетривіальний, і оскільки він залежить від змінного стану, налагоджувати вкрай складно. Приклад: "Виправлення помилок: перезапуск рівня після скидання шолому поверх бомби після вибуху ракети в межах 200 пікселів води більше не спричиняє аварії на робочому столі." Коротше кажучи, вам доведеться мати дійсно хороший привід для того, щоб турбуватися.
BrianH

14

Для уточнення існуючих відповідей на ваше запитання щодо консолей: їм не вистачає пам'яті, щоб зберігати як початковий стан, так і поточний стан для великих складних ігор.

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

"Найкраща" консоль поточного покоління має лише 512 МБ пам'яті, поділеної між процесорними даними та графікою. Це крихітні. Один з нинішніх головних болів розвитку консолей - це намагання вписатись в ігри, які відповідають сьогоднішньому рівню якості з таким невеликим обсягом пам'яті. Підрахунок кілобайт може стати важливим, особливо наближеним до дати корабля. Зберігання копії початкового стану рівня - це деякий обсяг даних, який можна зробити без, дозволяючи використовувати більше пам'яті для речей, які роблять гру цікавішою під час гри, а не просто робити швидше перезавантаження рівня.

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

Все може змінитися кардинально з консолями наступного покоління та їх 8 Гб пам'яті. Або вони можуть залишатися такими самими, просто моделями та матеріалами з більшою роздільною здатністю та великою кількістю активних ігрових об'єктів. Час покаже. Зважаючи на те, що PC-ігри, як правило, орієнтовані на машини з 2 ГБ оперативної пам’яті та 512 МБ VRAM (хоча багато хто набирає набагато більші значення), 8 ГБ нових консолей є досить розкішними, наскільки мінімальні базові лінії. Ми, швидше за все, побачимо перехід до ігор, що вимагають 64-бітного процесора / ОС і 4-8 ГБ оперативної пам’яті з 1-2 ГБ VRAM в найближчі роки. Збереження декількох станів у пам'яті для швидкого зйомки повинно бути набагато простішим.


+1 Фантастична інформація та чудове пояснення того, чому консолі помітно повільніші при перезавантаженні.
Том «Блакитний» Піддак

7

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

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

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


3
Ви можете перевірити відповідь Шона на прикладі технічного випадку, коли ви можете перезавантажити рівень над "скиданням"
SpartanDonut

2

Для забезпечення великого рівня або безшовного рівня гри, навіть з обмеженою пам’яттю (пам’ять завжди занадто мало, питання полягає в тому, якщо ви вперше потрапили на ліміт оперативної пам’яті чи на відеокарті), є ще одна стратегія:

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

Dungeon Siege приходить до тями (колись розробники заявляли, що управління пам'яттю забирає більше процесорної потужності, ніж реальна гра), більшість MMORPGS це роблять, стрільці з відкритим середовищем повинні це робити ... У цих випадках початок рівень (або навіть точка повторної зарибу 30 секунд тому) може більше не бути (повністю) в пам'яті.

Найчастіше свіже перезавантаження - це найпростіший, найдешевший і, можливо, найшвидший спосіб.

Редагувати: Ось стаття про механізми завантаження облоги Dungeon: Постійний світ облоги підземелля


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

2

Маючи відмінні відповіді Шона та Блю щодо обмежень фізичної платформи та про-кон-рішень, я хочу розглянути коментар до іншого підходу:

Чому ви повинні, ймовірно, просто повністю перезавантажити рівень

Отже, у вас виклик loadLevel () працює бездоганно, так! Ви завантажуєте інформацію про файл рівня і крокуєте через побудову на ньому світу, створюючи об'єкти та завантажуючи текстури та звуки під час руху. Потім, коли це все зроблено - або зроблено "достатньо", щоб відтворити гру, ви викликаєте startPlay () і ваш світ розкривається, і ваша музика починає грати.

Тепер, коли ви закінчите з рівнем, або переходите до меню, або виходите з гри, ви зателефонуєте unloadLevel (), щоб звільнити всі ресурси та пам'ять, яку ви тримали, щоб забезпечити безперебійний досвід.

Тепер, що станеться, коли ви хочете додати функцію "Перезапуск рівня"? Ну...

unloadLevel(currentLevel);
loadLevel(currentLevel);
startPlay();

І ви зробили! Ніякого нового коду, не більше декількох простих функціональних дзвінків, і ви вже написали та налагодили це все, так що тепер ваша нова блискуча функція перезавантаження перекреслена зі списку, і, ймовірно, більше ніколи не зустрінеться - безкрутний, неіржавіючий код найкращий вид! Перемістіть код у функцію restartCurrentLevel (), і ви зможете скласти цей код і ніколи більше не дивитися на нього - можливо, переконавшись, що є рівень для перезавантаження, звичайно :)

Але тоді вам цікаво, чи це не марно, вивантажуйте речі, які ви збираєтеся знову перезавантажити. Ну а якщо ваші рівні та ресурси невеликі, то найбільше вам доводиться отримувати - це кілька запасних секунд часу завантаження кожного разу, коли «Перезапуск» викликається навіть у повільних системах (а може бути і старих смартфонах), тож хто турбується? "Передчасна оптимізація", ви маєте кращі справи зі своїм часом.

Ах, але тепер ваші рівні зростають, а ваші текстури стають все більш детальними, а саундтрек розбивається на 512 кбіт / с з окремими каналами для кожного голосу та музичного шару (це здавалося гарною ідеєю в той час, хоча ви не можете згадати чому. ..) і щось про "залежне від стану походження воксельного проміння багатовимірних матриць перетворення Фур'є", яке, на вашу думку, просто складено і не є реальною справою, а завантаження рівня насправді потребує певного часу, і його початок вас дратує. Ви навіть пройшли тестування з реальними людьми, і вони насправді демонструють неприємність до очікування, оскільки це гірше, ніж подібні ігри (ви не очікуєте, що столиця MMORPG зі 100 гравцями повністю завантажиться за <2 секунди, чи не так?), і це проблема.

То як оптимізувати? Ну, якщо перезавантаження рівня - це проблема, то чи не проблема завантаження рівня ? Якщо ви думаєте, що це просто перезавантаження, чому на землі люди перезаряджають ваш рівень набагато частіше, ніж вони в першу чергу просто завантажують рівень? Звучить як проблема гри, а не проблема кодування. Хто вважає, що її задоволення перезавантажувати рівень знову і знову, і просто хоче, щоб це було швидше, а не цілком уникнути ?

Спершу виправте справжню проблему!

Але скажемо, що ваша гра розроблена, тому вам слід перезапустити хоча б періодично, а час завантаження достатньо довгий, щоб її нормально зробити один раз і зовсім неминуче, але вам не хочеться робити це знову. Що це за гра? Здається, це якась дивна проблема ... можливо, портальна гра, що має високу роздільну здатність, де передбачається, що ви збираєтеся зіпсувати головоломку повторно?

Перш за все, ви повинні усвідомити, що це не тривіально. Вам потрібно буде написати абсолютно новий, неперевірений код, і це "залежно від стану", щоб ви могли навіть не знати, що є чи не збирається повторно використовувати між рівневими п'єсами. Чи є у вашому рівні випадкові елементи, нерести, змінні текстури (чи ваші скелети лише іноді носять броні?) Чи інші змінні елементи? Чи є речі, які залежать від плеєра, як наряд чи індивідуальна модель або кольори / двері / пастки?

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

Незалежно від того, що ви робите, навіть якщо ваша гра проста, ви збираєтесь потрапляти в незрозумілі помилки, які базуються на рівні рівня / гравця, коли рівень перезапускався, що не трапляється, коли ви завантажуєте рівень в перший раз. Таким чином, ви можете писати оновлення гри з текстом:

"Якщо накинути шолом на бомбу на плитку, яка біля неї вибухнула ракетою, яка також знаходилася в межах 200 пікселів води, більше не зіпсує ваші дані гри та не призведе до краху гри".

Справжня причина Більшість ігор не турбує

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

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

Те саме стосується програмного забезпечення, від ігор до мультимедійних презентацій Power Point - якщо все, що ви робите, це поголити кілька секунд з завантажувального екрану, люди витрачають 1% свого часу на перегляд, то це краще зробити неймовірно дрібницею або ви отримуєте дуже погана віддача від інвестованого часу.

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


0

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

Оскільки це коштує більше грошей і часу, розробники ігор зазвичай цього не роблять.


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

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

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

Отже, ваша реакція на мій перший рядок відповідей, який стосується "не потрібно деталей", правда? якщо я видалю цей рядок, ви б повернули -1 бал назад?
Xtro

Як не дивно - так. Ніколи не відволікайте деталі, де це можна надати, і ви, як правило, знайдете, що ваші відповіді отримують набагато більшу оцінку.
Том 'Блакитний' Піддок
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.