Содействие развертыванию игр XNA для не программистов


12

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

Моя проблема заключается в следующем: я хочу создать систему, в которой остальная часть команды может заменить, например, звуки боя, и они могут сразу увидеть изменения, не дожидаясь, пока я построю их. Способ установки XNA, если я его опубликую, кодирует все графические и звуковые файлы, поэтому команда не может «горячей замены». Я могу настроить Microsoft VS на каждом компьютере и показать им, как быстро публиковать, но я хотел знать, есть ли более простой способ сделать это.

Кто-нибудь сталкивался с этим при работе с командами, использующими XNA?


2
Под кодировкой XNA всех изображений и звуковых файлов вы имеете в виду, что они создаются конвейером содержимого XNA и превращаются в файлы .xnb?
Дэвид Гувейя

Я не могу вспомнить точное расширение, но они проходят через стандартный конвейер, да.
Сал

Ответы:


12

Прежде всего, я не думаю, что вам нужно каждый раз публиковать и создавать установщик. Просто создайте проект и поместите выходные файлы (т. Е. EXE и папку Content плюс любые зависимости DLL, которые вы, возможно, используете) в репозиторий, и он также должен запускаться на их компьютере, если на них установлено перенаправление XNA.

Что касается вашего вопроса, я могу подумать о двух решениях, одно из которых включает в себя установку Visual Studio на свои машины, а другое - внесение некоторых изменений в игру:

  • Пусть они установят Visual Studio и научат их передавать свои ресурсы через конвейер содержимого XNA. Им просто нужно создать проект конвейера контента, перетащить туда файлы и собрать. Затем они могут поменять местами полученные файлы XNB с файлами в папке проекта и запустить EXE, чтобы увидеть изменения.

  • Если вы разрабатываете для Windows, вы можете изменить свой код так, чтобы он загружал ресурсы во время выполнения в их исходных форматах, без необходимости проходить через раздел содержимого. Для загрузки изображений, которые вы можете использовать Texture2D.FromStream(как в этом примере ) и для аудио, лучшее решение, которое я нашел, - это использовать API FMOD (как в этом примере ). Затем они могут просто поменяться активами напрямую и запустить игру.

Чтобы пойти дальше, вы также можете попытаться сделать свою игру максимально управляемой данными. По сути, это означает, что все в игре, что вы сможете легко изменить, например, статистика классов персонажей или путь к используемым изображениям и звуковым файлам, должно быть изъято из кода и помещено во внешние текстовые файлы. (например, XML, JSON, INI). Затем вам нужно всего лишь отредактировать эти файлы в текстовом редакторе, чтобы увидеть изменения в игре, и нет необходимости перестраивать.


1
Спасибо за ваш быстрый ответ. Мне нравится ваше второе решение, и у меня возник вопрос, который возник из него: есть ли способ в VS создать флаг, похожий по стилю на #IF DEBUG, который позволил бы мне сделать что-то вроде #IF NON_PRODUCTION_MODE, таким образом я могу обернуть все вызовы FromStream () в этот непроизводственный вызов. Наконец, когда я буду готов отправить игру в производство, я легко смогу переключать режимы и снова кодировать звуковые файлы.
Сал

1
@ Сал Да, вы можете сделать это. Проверьте документацию здесь .
Дэвид Гувейя

1
@Sal По умолчанию Visual Studio создает два профиля сборки: Debug и Release. Вы можете поменять местами между двумя Build->Configuration Manager. По умолчанию в сборке отладки определен DEBUGсимвол компиляции, что означает, что вы можете обернуть свой не выпускаемый код #if ( DEBUG ) doStuffIWouldntDoInRelease(); #elif theActualReleaseCode(); #endif.
Cypher

1
@Sal Кроме того, я обнаружил, что было намного проще просто включить каталоги bin / * в репозиторий, и попросить дизайнеров / artist / qa просто проверить папку bin, чтобы они могли запускать самые последние версии. Делая это, они получают все зависимости, текстуры, аудио и т. Д. Все вместе. Затем каждый день все, что им нужно было делать, - svn updateэто записывать в свой рабочий каталог, и они были в курсе.
Cypher

4

Немного опоздал на вечеринку, но вот моя идея.

Я бы пошел с 3-й возможностью, которая не предполагает ничего, как изменение уже существующей базы кода. Это будет работать, если вы зафиксируете (и скопируете) двоичные файлы (действительный .exe игры и связанные с ним .dll из компиляции) где-нибудь в выходном каталоге - например, с помощью сценария после сборки. Далее, я предполагаю, что мы говорим о Visual Studio 2010 и XNA Game Studio 4.0 (процедура очень похожа для других версий, просто нужно заменить некоторые цифры)

Итак, идея такова: создайте скрипт (.cmd) в корне вашего проекта, где находится решение .sln, со следующими шагами:

  1. Вызвать «Командную строку Visual Studio 2010»:

    вызов "C: \ Program Files (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 \ Debug \ Content * .. \ game_output \ Content

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

  4. Вызовите, 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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.