STL для ігор, так чи ні? [зачинено]

Кожна мова програмування має свою стандартну бібліотеку контейнерів, алгоритмів та інших корисних матеріалів. З такими мовами, як C #, Java та Python, користуватися мовою без її стандартної лібрики практично неможливо .

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

Отже ... добре підходить STL чи ні?

Ще коли я працював у професійному розвитку ігор, STL був занадто незрілим і роздутим. Але це було> 10 років тому.

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

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

Просто переконайтеся, що ви знаєте, як використовувати STL та використовувати його у своїй грі. Прочитайте кілька книг і подивіться код реалізації в STL, який ви використовуєте.

Я б сказав, що найкраще використовувати STL, якщо ви точно не знаєте , чому ви не хочете ним користуватися.

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

Скарги на те, що STL застосовує "вузький погляд на світ", вражають мене трохи дурним. Вони є контейнерами. Вони мають обмежений набір операцій, оскільки контейнери мають обмежений набір операцій. Що ти робиш, що не з цим?

Я бачив дуже мало причин не використовувати STL для ігор.

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

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

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

Індивідуальний варіант, такий як EA STL , спеціально розроблений для ігор і може отримати набагато кращі показники пам’яті та зручність використання консолі. Він став відкритим кодом у 2016 році відповідно до пункту BSD-3 зі сховищем на GitHub .

Ось, що Майк Актон (директор двигуна на Іграх про безсоння Spyro Dragon, Ratchet & Clank і Resistance) повинен був сказати про це, коли його запитали тут . Зауважте, його запитали як про STL, так і для Boost в цілому, як це стосується використання в ігрових розробниках.

STL / Boost, чи належить він до gamedev? Якщо тільки його частини, то які?

Ви тут питаєте про дві різні речі, правда? STL та Boost, окремо. Але насправді моя відповідь одна і та сама: ні в одному немає нічого поганого , але я не перешкоджаю їх використанню. Використання будь-якого способу заохочує людей підходити до вирішення проблеми, а не знаходити рішення проблеми. Рішення завжди повинно відповідати наявним даним та обмеженням обладнання та ін. І STL, і Boost мають надзвичайно вузький погляд на "світ", і їх відповідне використання обмежене. Дійсно, я відволікаю їх, тому що вони ведуть програмістів відразу в неправильному напрямку, я часто кажу, якщо вам здається, що вам потрібен або один, напевно, ви не дуже розумієте проблему, яку ви "

Я також помітив, що більшість розробників про ігор більше прагнуть до C, ніж до C ++.

Якщо ви виявите, що переписуєте щось, що вже існує в STL, з будь-якої причини зупиніться . Використовуйте STL.

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

Чи добре підходить STL для ігор? Безумовно. Ігри - це складне програмне забезпечення, STL надає функції, що допомагають керувати складністю, тому це добре.

Чи це добре підходить для вашої платформи? Не обов'язково. Якщо ви пишете для консолі, то вам слід бути дуже уважним щодо використання пам'яті та кешу. STL не робить це дуже просто.

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

Я знаю, що це дуже пізно на вечірку, але зміни часу та відповіді залишаються в стороні. C ++ 11 має досить глибокі зміни, багато з яких - підвищення продуктивності C ++ та стандартної бібліотеки. Здається, ті, хто не використовує STL або Boost, як правило, не йдуть в ногу з новими стандартами, залишаючи домашні розкручені рішення не потребуючи важливих удосконалень, звичайно це не завжди так.

Я використовував STL у кожному проекті з середини 90-х до сьогодні, за винятком короткого часу в EA. Я думаю, що сторона анти STL мала певні раціональні причини не використовувати її. Таких значною мірою немає. Спеціальні розподільники - це одне рішення, використання резерву - інше, і не передавати речі за значенням - це третя частина, але вони досить прості і будь-який програміст повинен це знати. Що важливіше, але це використання алгоритмів. Автори-компілятори точно знають, що робить for_each (), і можуть оптимізувати код. Це не може статися з домашньою рулонною петлею. for_each () на об'єкт const ще краще. Microsoft оптимізує for_each багатьма способами, включаючи серіалізацію. У них також є бібліотека AMP, у якій паралельний_фор_ех (). Якщо у вас є можливість, поговоріть з цим інженерів-компіляторів. Компілятори консолей оптимізують те, що звикає, так що sa трохи проблеми з куркою та яйцями. Microsoft стає дуже важким із C ++ 11, і наступний XBox не буде відрізнятися. Я не маю уявлення про PS4, ми ще цього не отримали.

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

Поняття про те, що Boost і STL мають вузький погляд на вирішення проблем, - це чисте божевілля. Я приголомшений тим, що багато речей у STL та Boost можна налаштувати через риси та політику. Шукайте порівняння рядків незалежно від регістру, наприклад.

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

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

Це гаряча тема в розробці ігор. Я особисто не рекомендую його, за винятком, можливо, EASTL, як згадувалося вище. У мене є дві основні проблеми зі STL (технічно "Стандартна бібліотека C ++", оскільки STL більше не називається) в іграх. 1) Динамічне розподіл пам'яті часто витрачає багато часу виконання в іграх, коли використовується STL. 2) Використання STL заохочує масив структур підходити до архітектури ігор, тоді як підхід до структури масивів набагато зручніший для кешу.

Це залежить. Наскільки великий проект, яка платформа (и) та яка хронологія?

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

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

Знайте, коли торгувати продуктивністю для зручності!

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

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

STL абсолютно чудовий для використання в іграх, якщо ви добре це розумієте. Наш двигун досить широко використовує його, і це ніколи не було проблемою. У мене немає досвіду розробки консолей, що може бути зовсім іншою історією, але вона добре підтримується на всіх платформах ПК (Windows / Mac / Linux).

Найголовніше - зрозуміти, які сильні та слабкі сторони кожного типу контейнерів, і вибрати правильний контейнер для роботи, яку ви виконуєте.

Мій колишній роботодавець перейшов від використання надійного набору спеціальних класів контейнерів на STL. Час збирання збільшився, і налагодження налагодилося вниз, обидва досить значно. Якби ми починали з нуля, STL (можливо, краще використовувати), мабуть, мав би сенс, але мені ніколи не було зрозуміло, що ми отримали що-небудь при переході на STL, що могло б виправдати викидання робочого, швидкого, налагоджуваного коду.

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

Мої 2 копійки на це те, що STL працює чудово. Я розробляв 3D-ігровий двигун (не якості AAA, але достатньо просунутого типу сценаріїв, відкладеного візуалізації, інтегрованої фізики Bullet) для ПК, і я ще не бачив, щоб контейнери стали основним вузьким місцем. Неправильне використання 3D-API та неякісні алгоритми були найкращими цілями (визначаються шляхом профілювання!) Кожного разу, коли я заходив і намагався досягти трохи більшої продуктивності.

Я будував ігри, використовуючи STL, і мені це подобається, і це, здається, працює добре.

Гарне питання! Більш конкретний питання - які загальні вимоги до гри, які не можуть бути задоволені STL та Boost.

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

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

Однак для розробки лише для ПК я думаю, що STL та Boost дуже хороші. Хоча загальноприйняті рішення не завжди ідеальні, вони часто досить хороші. Ваше перше рішення проблеми майже ніколи не є ідеальним, і ви вдосконалюєте або замінюєте недоліки, поки вона не стане достатньою.

STL добре підходить для вашої гри, якщо STL добре підходить для вашої гри.

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

Люди не повинні уникати використання STL у своїх іграх, оскільки інші люди уникають використання STL в іграх; вони повинні уникати його використання, якщо вони зважили всі свої варіанти і справді вірять, що інша реалізація поліпшить якість їх продукту.

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

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

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

Я думаю, що цю дискусію можна узагальнити так:

посередньо написаний специфічний код програми <добре написаний код загального призначення <добре написаний специфічний код програми

Будь-хто, чиє домашнє рішення потрапило б до категорії 3, напевно знає відповідь на початкове запитання щодо своєї конкретної проблеми. STL потрапляє в категорію 2. Таким чином , для тих , хто потребує , щоб задати питання, «повинен я використовувати STL», відповідь, ймовірно , так.

STL все в порядку для використання на ПК, оскільки його вдосконалена система віртуальної пам’яті робить необхідність ретельного розподілу пам'яті трохи менш важливою (хоча все-таки потрібно бути дуже обережною). На консолі, з обмеженими можливостями віртуальної пам’яті або відсутністю надмірних кеш-витрат, ви, ймовірно, краще писати власні структури даних, які мають передбачувані та / або обмежені паттові помилки на розподіл пам'яті. (І ви, звичайно, не помилитесь, зробивши те ж саме і на проекті для ігор на ПК.)

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

Найкраще в програмному забезпеченні, на відміну від більшості інших дисциплін, полягає в тому, що ви завжди зможете змінити речі згодом, якщо виявите, що це не працює так, як вам хотілося б. Пізніше ви дізнаєтесь, що STL не працює для вас у цьому проекті? Зірвіть його, поставте щось інше на своє місце. Вам не подобається, як ви розділили обов'язки між своїми об'єктами? Рефактор. Вам не подобається, що ви використовували предмети? Замініть їх прямими методами С. Вам не подобається, що все, що зберігається в структурах, та методи маніпулювання ними? Замініть їх об’єктами C ++.

Я кажу, що це STL. Моя причина досить проста:

1. Вам не потрібно STL, щоб писати ігри. Навіть не великі.
2. STL значно збільшує час компіляції.
3. Великий час компіляції призводить до менших ітерацій над вашою розробкою.

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

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