Не могли всі ігри уникнути завантаження після запуску?

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

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

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

Причин цього не робиться багато:

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

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

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

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

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

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

У межах безперервної кампанії, або коли розробник має великий контроль над розташуванням гравця, таке рішення, безумовно, є життєздатним, як ви кажете. Naughty Dog любить виконувати час завантаження, у Jak і Daxter, як відомо, немає часу завантаження на PS2, а Uncharted ігри мають на початку єдиний час завантаження.

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

Час.

Вам потрібен час, щоб заощадити час. Або вам потрібні гроші, щоб компенсувати брак часу. У будь-якому випадку, "Немає часу завантаження!" це особливість, яку можуть запропонувати лише ті, хто має розкіш, щоб собі це дозволити. Потрібно дуже ретельне планування, і вам потрібно дуже добре зрозуміти, що ви робите, і не всі розробники ігор мають ресурси для цього.

Зрештою, це обмежені ресурси.

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

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

І при всьому цьому завантаження подібним чином є вирішеною проблемою (TM), але це не робить його простим. Це витрачає багато ресурсів і часу, як на оптимізацію ресурсів, так і на їх використання для забезпечення безперебійного відтворення, а в самому коді - асинхронний код важкий. Це також може означати зменшення досвіду гри, навіть якщо все піде правильно - це означає, що ви повинні переконатися, що ви не перетинаєте можливості пропускної здатності вашого найнижчого загального знаменника, тому вам потрібно знизити якість моделей і текстур або зробити їх менш різноманітні, а геометрія ваших світів сильно обмежена. Якщо ви цього не зробите, то гра буде зовсім неспроможною - поки я пам’ятаю людей, які грали в ігри, на які було потрібно 10 хвилин (а то й довше!), Щоб завантажити карту, просто тому, що їхній комп’ютер був не зовсім під силу, гра сама після цього добре працює. Якби у нього було безшовне завантаження, гра просто заморожувала б або демонструвала потворні текстури та моделі весь час, очікуючи завантаження даних. Відкладене завантаження не є виграшним, це компроміс, як і більшість інженерних речей :)

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

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

Ці проблеми просто не є проблемою - все попередньо завантажено.

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

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

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

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

Оскільки ви використовували пейджинг на місцевості як приклад, я продовжу з цим.

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

А тепер уявіть швидку подорож. Немає жодного способу передбачити, куди користувач може вибрати. Вони мають (як правило) майже всю карту на вибір. Попереднє завантаження всіх можливих місць швидкого подорожі зайняло б занадто багато пам’яті (ви можете спочатку завантажити всю карту в пам’ять) і занадто багато часу (якщо припустити, що не було завантажено всю карту). Коли це станеться? Коли вони відкривають діалог швидкого подорожі? Проблема стала б лише в кілька разів гіршою!

Ось чому навіть у більшості ігор, які виконують пейджинги на місцевості без навантаження, все ще є екрани завантаження для швидкого пересування. Крім того, якщо ви рухаєтесь досить швидко, ви можете іноді запускати екрани завантаження навіть у іграх із картами без навантаження (я пам'ятаю, що це робив у TES Oblivion).

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

• Збереження файлів: вам потрібно буде завантажити кожен файл збереження до того, як користувач вийде на екран збереження, або здогадайтеся, який файл він може завантажити (останні 5 тощо).
• Інтерфейс користувача: Багато стратегічних ігор змінюють свій інтерфейс користувача залежно від вашої фракції. Вам потрібно буде завантажити всі можливі розробки інтерфейсу користувача, перш ніж користувач розпочне свою гру.
• Ігровий світ: у процедурно створених іграх, таких як Minecraft або RTS-ігри, такі як Civilization, світ не існує до перегляду, з різними масштабами. Попереднє завантаження цього неможливо, оскільки вони не існували для початку; попередній їх обчислення в кращому випадку можна зробити аналогічно попередньому завантаженню, і це не застосовується у випадку RTS.

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

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

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

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

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

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

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