促进非程序员的XNA游戏部署

我目前正在开发RPG，以XNA的RPG入门套件为基础。（http://xbox.create.msdn.com/zh-CN/education/catalog/sample/roleplaying_game）我正在与一个小团队（两名设计师和一名音乐/声音艺术家）合作，但我是唯一的团队程序员。当前，我们正在使用以下（不可持续的）系统：团队创建新的图片/声音以添加到游戏中，或者他们修改现有的声音/图片，然后将其工作提交到存储库中，我们将在此存储最新版本一切。（代码，图像，声音等）每天，我都会创建一个新的安装程序，以反映新的图像，代码更改和声音，然后每个人都进行安装。

我的问题是：我想创建一个系统，团队的其他成员可以替换战斗声音，例如，他们可以立即看到更改，而不必等待我建立。如果我发布的话，XNA的设置方式将对所有图像和声音文件进行编码，因此团队无法进行“热插拔”。我可以在每个人的计算机上设置Microsoft VS，并向他们展示如何快速发布，但是我想知道是否有更简单的方法来执行此操作。

与使用XNA的团队合作时，有人反对吗？

首先，我认为您不需要每次都发布和创建安装程序。只需构建项目并将输出文件（即EXE和Content文件夹以及您可能正在使用的任何DLL依赖项）放置在存储库中，只要安装了XNA redist，它也应在其计算机上运行。

关于您的问题，我可以想到两种解决方案，其中一种涉及在其计算机上安装Visual Studio，另一种涉及对游戏进行一些更改：

• 让他们安装Visual Studio并教他们通过XNA内容管道传递资产。他们只需要创建一个内容管道项目，将文件拖到那里并构建即可。然后，他们可以将结果XNB文件与项目文件夹中的文件交换，然后运行EXE来查看更改。

• 如果您是为Windows开发的，则可以更改代码，以使其在运行时以其原始格式加载资产，而无需通过内容提示。对于加载图像，您可以使用Texture2D.FromStream（如本示例），对于音频，我发现的最佳解决方案是改用FMOD API（如本示例）。然后他们可以直接交换资产并运行游戏。

为了进一步发展，您还可以尝试使游戏尽可能以数据为驱动力。这基本上意味着，游戏中您应该能够轻松更改的所有内容（例如角色类状态或所使用的图像和声音文件的路径）均应从代码中删除并放置在外部文本文件中（例如XML，JSON，INI）。然后，您只需要在文本编辑器中编辑这些文件即可查看游戏中的更改，并且无需重建。

晚会晚了一点，但这是我的主意。

我会考虑第三种可能性，它与修改现有代码库无关。如果您要在输出目录中的某个位置（例如，使用构建后脚本）提交（并复制）二进制文件（实际的游戏.exe和来自编译的关联的.dll），这将起作用。从现在开始，我假设我们正在谈论Visual Studio 2010和XNA Game Studio 4.0（其他版本的过程非常相似，只需要替换一些数字即可）

因此，这个想法是：在项目的.sln解决方案所在的根目录中创建一个脚本（.cmd），其步骤如下：

1. 调用“ Visual Studio 2010命令提示符”：

   调用“ C：\ Program Files（x86）\ Microsoft Visual Studio 10.0 \ VC \ vcvarsall.bat” x86

   这是为了使我们的脚本能够找到XNA库以及所有必需的工具和二进制文件。

2. 在内容项目（.contentproj）上调用MSBuild任务：

   msbuild / property：XNAContentPipelineTargetPlatform = Windows / property：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脚本，便会生成新内容并将其复制到已提交工件的输出目录中，以进行测试。

但是，有一个小问题，您必须退回到David帖子的第一点：如果艺术家想通过添加/删除/移动文件来修改Content项目，则必须打开Visual Studio中的项目（或手动编辑项目文件，我怀疑有人会这样做）。就像我说的那样，这是一个小问题，因为它们可以将新文件提交到存储库中，而您，在完成处理这些文件的代码后，编码器会将它们包括在Content Project中。

关于这个想法，Shawn Hargreaveas从命令行发布了一些有关msbuild和构建内容项目的信息：http : //blogs.msdn.com/b/shawnhar/archive/2006/11/07/build-it-ahead-of-time .aspx他的解决方案是创建一个新文件，但是我认为直接使用已经存在的项目文件更加容易和可维护。

PS：对不起，很久很久以前xD