Немного опоздал на вечеринку, но вот моя идея.
Я бы пошел с 3-й возможностью, которая не предполагает ничего, как изменение уже существующей базы кода. Это будет работать, если вы зафиксируете (и скопируете) двоичные файлы (действительный .exe игры и связанные с ним .dll из компиляции) где-нибудь в выходном каталоге - например, с помощью сценария после сборки. Далее, я предполагаю, что мы говорим о Visual Studio 2010 и XNA Game Studio 4.0 (процедура очень похожа для других версий, просто нужно заменить некоторые цифры)
Итак, идея такова: создайте скрипт (.cmd) в корне вашего проекта, где находится решение .sln, со следующими шагами:
Вызвать «Командную строку Visual Studio 2010»:
вызов "C: \ Program Files (x86) \ Microsoft Visual Studio 10.0 \ VC \ vcvarsall.bat" x86
Это сделано для того, чтобы наш скрипт мог найти библиотеки XNA и все необходимые инструменты и двоичные файлы.
Вызовите задачу 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)
Рекурсивно скопируйте вывод в папку, в которой хранятся бинарные файлы + реальная игра:
xcopy / d / y / i / e bin \ x86 \ Debug \ Content * .. \ game_output \ Content
Более подробную информацию о флагах, вы можете вызвать в командной строке: xcopy /?
. Важными из них являются: /d
копирование только измененных файлов - если у вас много ресурсов, полезно не копировать снова и снова уже существующие и неизмененные файлы; /y
для автоматической перезаписи существующих файлов, чтобы их можно было обновлять более новой версией. Я использовал, xcopy
потому что обычный copy
не может копировать рекурсивно папки, насколько я знаю, - и, вероятно, вы структурируете содержимое в папках и подпапках. Плюс, это лучше, чем обычно copy
(много разных флагов).
Вызовите, pause
чтобы скрипт ждал ввода пользователя. Это полезно для проверки правильности сборки и отсутствия ошибок.
Теперь артистам (или всем, кто) изменяет файлы содержимого, нужно просто дважды щелкнуть сценарий .cmd, и новый контент будет создан и скопирован в выходной каталог, в котором находятся зафиксированные артефакты, и готов к тестированию.
Однако есть небольшая проблема, для которой вам придется вернуться к 1-му пункту поста Дэвида: если художники хотят изменить проект контента, добавляя / удаляя / перемещая файлы, они должны сделать это, открыв проект в Visual Studio (или редактирование файла проекта вручную, что, я сомневаюсь, кто-нибудь сделает). Как я уже сказал, это небольшая проблема, потому что они могут просто зафиксировать новые файлы в репозитории, и вы, кодер, включите их в Content Project, когда код будет создан для их обработки.
В связи с этой идеей Шон Харгривиас опубликовал что-то о msbuild и создании проектов контента из командной строки: http://blogs.msdn.com/b/shawnhar/archive/2006/11/07/build-it-ahead-of-time .aspx Его решением было создание нового файла, но я думаю, что проще и удобнее обслуживать напрямую уже существующий файл проекта.
PS: простите за длинный пост xD