Який найкращий підхід до проектування AssestManager, який міститиме посилання на графіку, звуки тощо в грі?
Чи слід зберігати ці активи в парі "ключ / значення"? Тобто я запитую "фоновий" актив і Map повертає пов'язаний растровий файл? Чи є ще кращий спосіб?
Конкретно я пишу гру Android / Java, але відповіді можуть бути загальними.
Відповіді:
Це залежить від сфери вашої гри. Менеджер активів абсолютно необхідний для більших назв, тим більше для менших ігор.
Для більших назв вам потрібно керувати проблемами, такими як:
Що стосується менших назв, то це менше питання, а такі структури, як XNA, мають у собі менеджери активів - дуже мало сенсу повторно їх вигадувати.
Якщо вам потрібен диспетчер ресурсів, насправді не існує рішення одного розміру, але я виявив, що хеш-карта з ключем як хеш * імені файлу (опущені та роздільники все 'виправлено') добре працює для проектів, над якими я працював.
Зазвичай не рекомендується вбудовувати жорсткі файли файлів у вашому додатку, зазвичай краще мати інший формат даних (наприклад, xml), щоб зображувати назви файлів на "ідентифікаторах".
(Намагаючись уникнути обговорення "не використовувати менеджера активів", оскільки я вважаю це офтопічним.)
Карта ключа / значення - дуже зручний підхід.
У нас є одна реалізація ResourceManager, де Фабрики для різних типів ресурсів можуть реєструватися.
Метод "getResource" використовує шаблони, щоб знайти правильний Factory для потрібного типу ресурсу і повертає певний ResourceHandle (знову використовуючи шаблон для повернення SpecificResourceHandle).
Ресурси перераховуються ResourceManager (всередині ResourceHandle) і вивільняються, коли вони більше не потрібні.
Першим доданком, який ми написали, був метод "reload (XYZ)", який дозволяє нам змінювати ресурси за межами працюючого двигуна, не змінюючи жодного коду чи перезавантажуючи гру. (Це важливо, коли художники працюють над консолями;))
Більшу частину часу ми маємо лише на екземплярі ResourceManager, але іноді ми створюємо новий екземпляр лише для рівня або карти. Таким чином, ми можемо просто викликати "відключення" на levelResourceManager і переконатися, що нічого не протікає.
// very abbreviated!
// this code would never survive our coding guidelines ;)
ResourceManager* pRm = new ResourceManager;
pRm->initialize( );
pRm->registerFactory( new TextureFactory );
// [...]
TextureHandle tex = pRm->getResource<Texture>( "test.otx" ); // in real code we use some macro magic here to use CRCs for filenames
tex->storeToHardware( 0 ); // channel 0
pRm->releaseResource( pRm );
// [...]
pRm->shutdown(); // will log any leaked resourceВиділені класи менеджерів майже ніколи не є правильним інженерним інструментом. Якщо вам потрібен лише один раз (наприклад, фон або карта), його потрібно запитувати лише один раз і нехай він нормально гине, коли ви закінчите з ним. Якщо вам потрібно кешувати певний тип об'єкта, вам слід скористатися фабрикою, яка спочатку перевіряє кеш і іншим чином щось завантажує, поміщає в кеш, а потім повертає - і ця фабрика може бути просто статичною функцією, що отримує доступ до статичної змінної , а не власний тип.
Стів Йегґе (серед багатьох, багатьох інших) написав гарну історію про те, як марні класи менеджерів, внаслідок одинарного шаблону, закінчуються. http://sites.google.com/site/steveyegge2/singleton-considered-stupid
Я завжди думав, що хороший менеджер активів повинен мати кілька режимів роботи. Ці режими, швидше за все, будуть окремими вихідними модулями, що приєднуються до загального інтерфейсу. Два основних режими роботи:
Вам знадобиться інструмент, який може захопити всі збірки із спільної бази даних та створити виробничий набір даних.
У свої роки як розробник я ніколи не бачив нічого подібного, хоча працював лише у кількох компаній, тому моя думка не є репрезентативною.
Оновлення
Гаразд, кілька негативних голосів. Я розширю на цю конструкцію.
По-перше, вам не потрібні фабричні заняття, тому що якщо у вас є:
TextureHandle tex = pRm->getResource<Texture>( "test.otx" );ви знаєте тип, так що просто робіть:
TextureHandle tex = new TextureHandle ("test.otx");але тоді, що я намагався сказати вище, це те, що ви б не використовували явні назви файлів, текстура для завантаження визначалася б моделлю, на якій використовується текстура, тож вам насправді не потрібно читати людського імені, це може бути 32-бітове ціле значення, що набагато простіше обробляти процесор. Отже, у конструкторі для TextureHandle у вас є:
if (texture already loaded)
update texture reference count
else
asset_stream = new AssetStream (resource_id)
asset_stream->ReadBytes
create texture
set texture ref count to 1AssetStream використовує параметр resource_id для пошуку місця розташування даних. Як це зробити, це залежатиме від середовища, в якому ви працюєте:
У розробці: потік шукає ідентифікатор у базі даних (наприклад, використовуючи SQL), щоб отримати ім'я файлу, а потім відкриває файл, файл може бути кешований локально або витягнутий із сервера, якщо локальний файл не існує або є застарілий.
У випуску: потік шукає ідентифікатор у таблиці ключ / значення, щоб отримати зміщення / розмір у великому, упакованому файлі (як WAD-файл Doom).
Те, що я люблю робити для активів, - це створити одноразового менеджера . Натхненні двигуном Doom, грудочки - це фрагменти даних, які містять активи, що зберігаються у груповому файлі, який оголошує назви грудок, довжини, тип (растрова карта, звук, шейдер тощо) та тип вмісту (файл, інший грудочок, всередині сам файл грудочки). При запуску ці грудочки вводяться у бінарне дерево, але ще не завантажуються. Кожна карта (яка також є грудочкою) має перелік залежностей, які є просто назвами грудочок, над якими карта повинна працювати. Ці грудочки, якщо вони вже не завантажені, завантажуються під час завантаження карти. Додатково завантажуються груди сусідніх карт на карті, але не одночасно, але коли двигун з якихось причин простоює. Це може зробити карти безшовними, а екрану для завантаження немає.
Мій метод ідеально підходить для карт відкритого світу, але гра на основі рівня не виграє від безшовності цього методу. Сподіваюся, це допомагає!