Facilitar implementaciones de juegos XNA para no programadores

Actualmente estoy trabajando en un RPG, utilizando el kit de inicio RPG de XNA como base. (http://xbox.create.msdn.com/en-US/education/catalog/sample/roleplaying_game) Estoy trabajando con un pequeño equipo (dos diseñadores y un artista de música / sonido), pero soy el único programador. Actualmente, estamos trabajando con el siguiente sistema (insostenible): el equipo crea nuevas fotos / sonidos para agregar al juego, o modifican los sonidos / fotos existentes, luego envían su trabajo a un repositorio, donde mantenemos una compilación actual de todo. (Código, imágenes, sonido, etc.) Cada día más o menos, creo un nuevo instalador, reflejando las nuevas imágenes, los cambios de código y el sonido, y todos lo instalan.

Mi problema es este: quiero crear un sistema donde el resto del equipo pueda reemplazar los sonidos de combate, por ejemplo, y puedan ver los cambios de inmediato, sin tener que esperar a que construya. La forma en que la configuración de XNA, si publico, codifica todos los archivos de imagen y sonido, por lo que el equipo no puede "intercambiar en caliente". Puedo configurar Microsoft VS en la máquina de todos y mostrarles cómo publicar rápidamente, pero quería saber si había una forma más sencilla de hacerlo.

¿Alguien se ha enfrentado a esto cuando trabaja con equipos que usan XNA?

En primer lugar, no creo que deba publicar y crear un instalador cada vez. Simplemente construya el proyecto y coloque los archivos de salida (es decir, el EXE y la carpeta Contenido más cualquier dependencia de DLL que pueda estar usando) en el repositorio, y también debería ejecutarse en su computadora, siempre que tengan instalada la redist XNA.

En cuanto a su pregunta, puedo pensar en dos soluciones, una de las cuales implica instalar Visual Studio en sus máquinas, y otra implica hacer algunos cambios en el juego:

• Haga que instalen Visual Studio y les enseñe a pasar sus activos a través de la canalización de contenido XNA. Solo necesitan crear un proyecto de canalización de contenido, arrastrar los archivos allí y compilar. Luego pueden intercambiar los archivos XNB resultantes con los de la carpeta del proyecto y ejecutar el EXE para ver los cambios.

• Si está desarrollando para Windows, puede cambiar su código para que cargue los activos en tiempo de ejecución en sus formatos originales, sin tener que pasar por la línea de contenido. Para cargar imágenes que podría usar Texture2D.FromStream(como este ejemplo ) y para audio, la mejor solución que encontré fue usar la API de FMOD en su lugar (como este ejemplo ). Luego pueden intercambiar los activos directamente y ejecutar el juego.

Para llevar las cosas aún más lejos, también puedes intentar hacer que tu juego sea lo más basado en datos posible. Básicamente, esto significa que todo lo que puedas cambiar fácilmente en el juego, como las estadísticas de la clase de personaje, o la ruta de las imágenes y los archivos de sonido que estás usando, deben eliminarse del código y colocarse en archivos de texto externos. (por ejemplo, XML, JSON, INI). Entonces solo necesita editar esos archivos en un editor de texto para ver los cambios en el juego, y no hay necesidad de reconstruirlos.

Un poco tarde para la fiesta, pero aquí está mi idea.

Iría con la tercera posibilidad, que no implica nada como modificar la base de código ya existente. Esto funcionará si confirma (y copia) los archivos binarios (el .exe real del juego y los .dlls asociados de la compilación) en algún lugar de un directorio de salida, por ejemplo, con un script posterior a la compilación. En adelante, asumiré que estamos hablando de Visual Studio 2010 y XNA Game Studio 4.0 (el procedimiento es muy similar para otras versiones, solo necesito reemplazar algunos números)

Entonces, la idea es: crear un script (.cmd) en la raíz de su proyecto, donde reside la solución .sln, con los siguientes pasos:

1. Invoque el "Símbolo del sistema de Visual Studio 2010":

   llame a "C: \ Archivos de programa (x86) \ Microsoft Visual Studio 10.0 \ VC \ vcvarsall.bat" x86

   Esto es para que nuestro script pueda encontrar las bibliotecas XNA y todas las herramientas y binarios necesarios.

2. Llame a la tarea MSBuild en el Proyecto de contenido (.contentproj):

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

   Puede modificar las propiedades por diferentes plataformas / perfiles especificados. Incluso puede ir más allá para crear el contenido para más plataformas a la vez (Windows Phone, Xbox 360 o Windows). El perfil puede ser: Reach o HiDef (http://msdn.microsoft.com/en-us/library/ff604995.aspx)

3. Copie recursivamente el resultado en la carpeta donde se almacenan los binarios + el juego real en el repositorio:

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

   Para más detalles sobre las banderas, puede invocar en el símbolo del sistema: xcopy /?. Los importantes son: /dpara copiar solo archivos modificados; en caso de que tenga muchos recursos, es útil no copiar una y otra vez los ya existentes y no modificados; /ypara sobrescribir automáticamente los archivos existentes para que puedan actualizarse con una versión más nueva. Lo he usado xcopyporque lo normal copyno puede copiar carpetas recursivamente hasta donde yo sé, y probablemente esté estructurando el contenido en carpetas y subcarpetas. Además, es mejor que lo normal copy(muchas banderas diferentes).

4. Llame pausepara que el script espere la entrada del usuario. Esto es útil para verificar si la compilación estuvo bien y no se encontraron errores.

Ahora, los artistas (o cualquier persona) que modifique los archivos de contenido, solo tienen que hacer doble clic en el script .cmd y el nuevo contenido se creará y copiará en el directorio de salida donde están los artefactos comprometidos, listos para ser probados.

Sin embargo, hay un pequeño problema, por el cual tendrá que recurrir al primer punto de la publicación de David: si los artistas desean modificar el proyecto de Contenido agregando / eliminando / moviendo archivos, deben hacerlo abriendo el proyecto en Visual Studio (o editando el archivo del proyecto a mano, lo que dudo que alguien haga). Como dije, este es un problema pequeño, porque podrían simplemente confirmar los nuevos archivos en el repositorio, y usted, el codificador los incluirá en el Proyecto de Contenido cuando el código esté listo para manejarlos.

Sobre esta idea, Shawn Hargreaveas publicó algo sobre msbuild y la construcción de los proyectos de contenido desde la línea de comandos: http://blogs.msdn.com/b/shawnhar/archive/2006/11/07/build-it-ahead-of-time .aspx Su solución fue crear un nuevo archivo, pero creo que es más fácil y más fácil de usar directamente el archivo del proyecto ya existente.

PD: Perdón por la larga publicación xD