Визначення активів у ігровому двигуні?

12

Я хочу визначити свої завантажені активи, але не знаю, який саме вибрати. Є 2 варіанти:

Ім'я (рядок)
- Це найпростіший, а також швидкий з не упорядкованим_мапом (O (1)), але шлях повільніше, ніж за допомогою цілих чисел.
- Легко зрозумілий в коді.
Цілі особи
- Найшвидший.
- Не зрозумілі в коді.

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

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

— Тудварі
джерело

10

Чому б не реалізацію обох? Версія рядка підключається до словника <string, int>, який, в свою чергу, називає словник <int, Asset>. Ви можете обійти шар на основі рядка в коді, але використовувати шар на основі рядка для взаємодії з користувачем.

— Krythic

2

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

— DMGregory

Та ж проблема в дещо іншому контексті: Різні методи реалізації предмета - які відмінності?

— Філіпп

19

Ви можете підтримати обох.

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

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

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

Мій випадок: я хочу змінити матеріал Об’єкта, тому надсилаю запит з назвою нового матеріалу. (рядок) Потім у графічній системі відбувається пошук по <string, pointer> unorderered map, і вказівник матеріалу об'єкта буде замінений на новий покажчик. Тож у моєму випадку мені не доведеться перетворювати його на ціле число? (тому що я перетворюю його на покажчик і в частих алгоритмах я використовую покажчики, я використовую лише рядки для випадкових речей.)

— Tudvari

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

— Тудварі

1

У своєму проекті я використовую хешовані рядки, які перетворюються під час компіляції в унікальні (я бажаю!) Номери. Отже, коли мені потрібен ресурс, наприклад текстура, яку я просто називаю

MngTexture->get(hash("my_texture"))

А оскільки я створюю просту системну систему сутностей і мені потрібно завантажувати дані компонентів з файлів, я створив просту мову, наприклад json, для зберігання даних, але є компільованим (перетворення слів і знаків з цифр у число та з рядків у хешовані значення) . Так, наприклад, якщо я хочу пов'язати текстуру з хешем ID ("my_texture") з "ball.PNG" у моєму файлі даних, у мене буде

|my_texture| = "ball.PNG"

Де || це оператор, який повідомляє компілятору хеш-слова всередині.

Тому я в основному використовую рядки, відображені в ints під час компіляції (щоб вони не мали накладних витрат), як у фактичному коді, так і у файлах, що є потоками для завантаження компонентів. Для обчислення хеша час компіляції просто google його, це проста функція 5-10 рядків коду.

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

Сподіваюсь, це може допомогти.

— Люка
джерело

0

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

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

— steeveeet
джерело