12
\$\begingroup\$

I'm currently working on an RPG, using the RPG starter kit from XNA as a base. (http://xbox.create.msdn.com/en-US/education/catalog/sample/roleplaying_game) I'm working with a small team (two designers and one music/sound artist), but I'm the only programmer. Currently, we're working with the following (unsustainable) system: the team creates new pics/sounds to add to the game, or they modify existing sounds/pics, then they commit their work to a repository, where we keep a current build of everything. (Code, images, sound, etc.) Every day or so, I create a new installer, reflecting the new images, code changes, and sound, and everyone installs it.

My issue is this: I want to create a system where the rest of the team can replace the combat sounds, for instance, and they can immediately see the changes, without having to wait for me to build. The way XNA's setup, if I publish, it encodes all of the image and sound files, so the team can't "hot swap." I can set up Microsoft VS on everyone's machine and show them how to quickly publish, but I wanted to know if there was a simpler way of doing this.

Has anyone come up against this when working with teams using XNA?

\$\endgroup\$
2
  • 2
    \$\begingroup\$ By XNA encoding all of the images and sound files, do you mean that they are built by the XNA content pipeline and turned into .xnb files? \$\endgroup\$ Commented Sep 21, 2012 at 15:17
  • \$\begingroup\$ I can't remember the exact extension, but they do go through the standard pipeline, yeah. \$\endgroup\$ Commented Sep 21, 2012 at 15:19

2 Answers 2

Reset to default
12
\$\begingroup\$

First of all, I don't think you need to be publishing and creating an installer every time. Just build the project and place the output files (i.e. the EXE and the Content folder plus any DLL dependencies you might be using) in the repository, and it should run on their computer too, as long as they have the XNA redist installed.

As for your question, I can think of two solutions, one of which involves installing Visual Studio on their machines, and other involves making some changes to the game:

  • Have them install Visual Studio and teach them to pass their assets through the XNA content pipeline. They just need to create a content pipeline project, drag the files there and build. Then they can swap the resulting XNB files with the ones in the project folder, and run the EXE to see the changes.

  • If you're developing for Windows, you can change your code so that it loads assets at runtime in their original formats, without having to go through the content pipline. For loading images you could use Texture2D.FromStream (like this example) and for audio the best solution I've found was to use the FMOD API instead (like this example). Then they can just swap the assets directly and run the game.

To take things even further, you could also try to make your game as data-driven as possible. This basically means that everything in the game that you should be able to change easily, such as character class stats, or the path of the images and sound files you're using, should be taken out of the code and placed in external text files (e.g. XML, JSON, INI). Then you only need to edit those files in a text editor to see changes in the game, and there's no need to rebuild.

\$\endgroup\$
4
  • 1
    \$\begingroup\$ Thank you for your quick response. I'm liking your second solution, and I have a question that arose from it: is there a way in VS to create a flag similar in style to the #IF DEBUG, which would allow me to do something like, #IF NON_PRODUCTION_MODE, that way I can wrap all of the FromStream() calls in this non production call. Finally, when I'm ready to send the game into production, I'll easily be able to switch modes, and encode the sound files again. \$\endgroup\$ Commented Sep 21, 2012 at 16:04
  • 1
    \$\begingroup\$ @Sal Yes you can do just that. Check the documentation here. \$\endgroup\$ Commented Sep 21, 2012 at 16:18
  • 1
    \$\begingroup\$ @Sal By default, Visual Studio creates two build profiles: Debug and Release. You can swap between the two from Build->Configuration Manager. By default, the Debug build has the DEBUG compilation symbol is defined, which means you can wrap your non-release code with #if ( DEBUG ) doStuffIWouldntDoInRelease(); #elif theActualReleaseCode(); #endif. \$\endgroup\$ Commented Sep 21, 2012 at 16:26
  • 1
    \$\begingroup\$ @Sal Also, I found it was a lot easier to just include the bin/* directories in the repository, and have the designers/artists/qa to just check out the bin folder so they can run the latest and greatest. By doing that, they get all the dependencies, textures, audio, etc. all together. Then each day all they had to do was svn update on their working directory and they were up to speed. \$\endgroup\$ Commented Sep 21, 2012 at 16:28
4
\$\begingroup\$

A little bit late to the party, but here is my idea.

I would go with the 3rd posibility which involves nothing like modifying the already existing code-base. This will work if, you will commit (and copy) the binaries (the actual game .exe and the associated .dlls from the compilation) somewhere in an output directory - for example with a post-build script. Onwards, I will assume we are talking about Visual Studio 2010 and XNA Game Studio 4.0 (The procedure is very similar for other versions, just need to replace some numbers)

So, the idea is: create a script (.cmd) in the root of your project, where the .sln solution resides, with the following steps:

  1. Invoke the "Visual Studio 2010 Command Prompt":

    call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86

    This is in order for our script to be able to find the XNA libraries, and all the required tools and binaries.

  2. Call the MSBuild task on the Content Project (.contentproj):

    msbuild /property:XNAContentPipelineTargetPlatform=Windows /property:XNAContentPipelineTargetProfile=Reach mygame.content/projectfile.contentproj

    You can modify the properties by specified different platforms/profiles. You can even go further to build the content for more platforms at a time (Windows Phone, Xbox 360 or Windows). The profile can be: Reach or HiDef (http://msdn.microsoft.com/en-us/library/ff604995.aspx)

  3. Copy recursively the output to the folder where the binaries + actual game is stored on the repository:

    xcopy /d /y /i /e bin\x86\Debug\Content* ..\game_output\Content

    For details on the flags, you can invoke in the command prompt: xcopy /?. The important ones are: /d, to copy only modified files - in case you have many assets it's useful not to copy over and over again the already existing and unmodified ones; /y for automatically overwriting existing files so they can be updated with a newer version. I've used xcopy because the normal copy can't copy recursively folders as far as I know - and probably you are structuring the content in folders and sub-folders. Plus, it's better than the normal copy (lots of different flags).

  4. Call pause so the script will wait for user input. This is useful to check if the build was fine and no errors were encountered.

Now, the artists (or anyone) who modifies the content files, need just to double click the .cmd script and the new content will be built and copied to the output directory where the commited artifacts are, ready to be tested.

However, there is a small problem, for which you'll have to fallback to the 1st point of David's post: if the artists want to modify the Content project by adding/removing/moving around files, they have to do that by opening the project in Visual Studio (or editing the project file by hand, which I doubt anyone would do). Like I said, this is a small issue, because they could just commit the new files in the repository, and you, the coder will include them in the Content Project when the code is done to handle those.

On this idea, Shawn Hargreaveas posted something about msbuild and building the Content Projects from command line: Link His solution was to create a new file, but I think it's easier and more maintainable to use directly the already existing project file.

PS: Sorry for the long post xD

\$\endgroup\$

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.