Полегшення розгортання ігор XNA для непрограмістів

Зараз я працюю над RPG, використовуючи пусковий набір RPG від XNA як основу. (http://xbox.create.msdn.com/en-US/education/catalog/sample/roleplaying_game) Я працюю з невеликою командою (двома дизайнерами та одним виконавцем музики / звуку), але я єдиний програміст. В даний час ми працюємо з такою (нестійкою) системою: команда створює нові фотографії / звуки для додавання до гри, або вони змінюють наявні звуки / фотографії, потім вони передають свою роботу в сховище, де ми зберігаємо поточну збірку всього. (Код, зображення, звук тощо) Кожен день я створюю новий інсталятор, відображаючи нові зображення, зміни коду та звук, і кожен встановлює його.

Моє питання полягає в наступному: я хочу створити систему, де інша частина команди може замінити бойові звуки, наприклад, і вони можуть негайно побачити зміни, не чекаючи, коли я буду будувати. Спосіб налаштування XNA, якщо я публікую, він кодує всі файли зображень та звуків, тому команда не може "гаряче заміняти". Я можу налаштувати Microsoft VS на всіх машинах і показати їм, як швидко публікувати, але хотів дізнатися, чи існує простіший спосіб зробити це.

Хтось проти цього стикався, працюючи з командами, що використовують XNA?

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

Щодо вашого питання, я можу придумати два рішення, одне з яких передбачає встановлення Visual Studio на своїх машинах, а інше передбачає внесення деяких змін у гру:

• Попросіть їх встановити Visual Studio і навчити їх передавати свої активи через контент-контент XNA. Їм просто потрібно створити проект контентного конвеєра, перетягнути туди файли та скласти. Потім вони можуть поміняти отримані файли XNB на файли в папці проекту та запустити EXE, щоб побачити зміни.

• Якщо ви розробляєте для Windows, ви можете змінити свій код таким чином, щоб він завантажував активи під час виконання в оригінальних форматах, без необхідності проходити конвеєрний контент. Для завантаження зображень, які ви могли використовувати Texture2D.FromStream(наприклад, цей приклад ), і для аудіо найкращим рішенням, який я знайшов, було використання API FMOD (наприклад, цей приклад ). Тоді вони можуть просто поміняти активи безпосередньо та запустити гру.

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

Трохи запізнився на вечірку, але ось моя ідея.

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

Отже, ідея полягає в тому, щоб створити скрипт (.cmd) в корені проекту, де знаходиться .sln-рішення, виконавши такі кроки:

1. Закликайте "Командний рядок Visual Studio 2010":

   виклик "C: \ програмні файли (x86) \ Microsoft Visual Studio 10.0 \ VC \ vcvarsall.bat" x86

   Це для того, щоб наш скрипт міг знайти бібліотеки XNA та всі необхідні інструменти та двійкові файли.

2. Викличте завдання MSBuild у проекті контенту (.contentproj):

   msbuild / property: XNAContentPipelineTargetPlatform = Windows / властивість: XNAContentPipelineTargetProfile = Досягти mygame.content / projectfile.contentproj

   Ви можете змінювати властивості за вказаними різними платформами / профілями. Можна навіть піти далі, щоб одночасно створити вміст для більшої кількості платформ (Windows Phone, Xbox 360 або Windows). Профіль може бути: Reach або HiDef (http://msdn.microsoft.com/en-us/library/ff604995.aspx)

3. Рекурсивно скопіюйте вихід у папку, де бінарні файли + фактична гра зберігається у сховищі:

   xcopy / d / y / i / e bin \ x86 \ налагодження \ вміст * .. \ game_output \ вміст

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

4. Зателефонуйте, pauseщоб сценарій чекав на введення користувачем. Це корисно, щоб перевірити, чи збірка була в порядку, і помилок не було.

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

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

З цього приводу Шон Харгрівес розмістив щось про msbuild та створення контентних проектів з командного рядка: http://blogs.msdn.com/b/shawnhar/archive/2006/11/07/build-it-ahead-of-time .aspx Його рішення полягало у створенні нового файлу, але я вважаю, що простіше та більш рентабельно використовувати безпосередньо вже існуючий файл проекту.

PS: Вибачте за довгий пост xD