Facilitando implantações de jogos XNA para não programadores

Atualmente, estou trabalhando em um RPG, usando o starter kit de RPG da XNA como base. (http://xbox.create.msdn.com/en-US/education/catalog/sample/roleplaying_game) Estou trabalhando com uma equipe pequena (dois designers e um artista de música / som), mas sou o único programador. Atualmente, estamos trabalhando com o seguinte sistema (insustentável): a equipe cria novas fotos / sons para adicionar ao jogo, ou modifica os sons / fotos existentes, depois envia seu trabalho para um repositório, onde mantemos uma versão atual de tudo. (Código, imagens, som etc.) Todos os dias, mais ou menos, crio um novo instalador, refletindo as novas imagens, alterações de código e som, e todos os instalam.

Meu problema é o seguinte: quero criar um sistema em que o restante da equipe possa substituir os sons de combate, por exemplo, e eles possam ver imediatamente as alterações, sem ter que esperar que eu construa. A maneira como a instalação do XNA, se eu publicar, codifica todos os arquivos de imagem e som, para que a equipe não possa "trocar de forma direta". Posso configurar o Microsoft VS na máquina de todos e mostrar a eles como publicar rapidamente, mas eu queria saber se havia uma maneira mais simples de fazer isso.

Alguém se deparou com isso ao trabalhar com equipes usando XNA?

Antes de tudo, não acho que você precise publicar e criar um instalador toda vez. Apenas crie o projeto e coloque os arquivos de saída (ou seja, o EXE e a pasta Conteúdo, além de quaisquer dependências DLL que você possa estar usando) no repositório, e ele também deverá ser executado no computador deles, desde que o redNA do XNA esteja instalado.

Quanto à sua pergunta, posso pensar em duas soluções, uma das quais envolve a instalação do Visual Studio em suas máquinas e outra envolve fazer algumas alterações no jogo:

• Faça com que eles instalem o Visual Studio e os ensinem a passar seus ativos pelo pipeline de conteúdo XNA. Eles só precisam criar um projeto de pipeline de conteúdo, arrastar os arquivos para lá e construir. Em seguida, eles podem trocar os arquivos XNB resultantes pelos da pasta do projeto e executar o EXE para ver as alterações.

• Se você estiver desenvolvendo para o Windows, poderá alterar seu código para que ele carregue ativos em tempo de execução em seus formatos originais, sem ter que passar pelo conteúdo. Para carregar imagens que você poderia usar Texture2D.FromStream(como este exemplo ) e para áudio, a melhor solução que encontrei foi usar a API FMOD (como este exemplo) ). Depois, eles podem trocar os ativos diretamente e executar o jogo.

Para levar as coisas ainda mais longe, você também pode tentar tornar seu jogo o mais orientado a dados possível. Isso basicamente significa que tudo no jogo que você deve poder mudar facilmente, como estatísticas da classe de personagem ou o caminho das imagens e arquivos de som que você está usando, deve ser retirado do código e colocado em arquivos de texto externos (por exemplo, XML, JSON, INI). Então você só precisa editar esses arquivos em um editor de texto para ver as mudanças no jogo, e não há necessidade de reconstruir.

Um pouco tarde para a festa, mas aqui está a minha ideia.

Eu iria com a terceira posibilidade, que não envolve nada como modificar a base de código já existente. Isso funcionará se você confirmar (e copiar) os binários (o jogo real .exe e as DLLs associadas da compilação) em algum lugar do diretório de saída - por exemplo, com um script pós-compilação. A partir de agora, assumirei que estamos falando do Visual Studio 2010 e do XNA Game Studio 4.0 (o procedimento é muito semelhante para outras versões, basta substituir alguns números)

Portanto, a ideia é: crie um script (.cmd) na raiz do seu projeto, onde reside a solução .sln, com as seguintes etapas:

1. Invoque o "Prompt de Comando do Visual Studio 2010":

   chame "C: \ Arquivos de programas (x86) \ Microsoft Visual Studio 10.0 \ VC \ vcvarsall.bat" x86

   Isso está em ordem para que nosso script encontre as bibliotecas XNA e todas as ferramentas e binários necessários.

2. Chame a tarefa MSBuild no projeto de conteúdo (.contentproj):

   msbuild / propriedade: XNAContentPipelineTargetPlatform = Windows / propriedade: XNAContentPipelineTargetProfile = Alcance mygame.content / projectfile.contentproj

   Você pode modificar as propriedades por diferentes plataformas / perfis especificados. Você pode ir além para criar o conteúdo para mais plataformas ao mesmo tempo (Windows Phone, Xbox 360 ou Windows). O perfil pode ser: Reach ou HiDef (http://msdn.microsoft.com/en-us/library/ff604995.aspx)

3. Copie recursivamente a saída para a pasta em que os binários + jogo real estão armazenados no repositório:

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

   Para mais detalhes sobre as bandeiras, você pode invocar no prompt de comando: xcopy /?. Os importantes são: /dcopiar apenas arquivos modificados - caso você tenha muitos recursos, é útil não copiar repetidamente os arquivos já existentes e não modificados; /ypara substituir automaticamente os arquivos existentes, para que possam ser atualizados com uma versão mais recente. Eu usei xcopyporque o normal copynão pode copiar pastas recursivamente até onde eu sei - e provavelmente você está estruturando o conteúdo em pastas e subpastas. Além disso, é melhor que o normalcopy (muitas bandeiras diferentes).

4. Ligar pause para que o script aguarde a entrada do usuário. Isso é útil para verificar se a construção foi boa e se não foram encontrados erros.

Agora, os artistas (ou qualquer pessoa) que modifique os arquivos de conteúdo precisam apenas clicar duas vezes no script .cmd e o novo conteúdo será construído e copiado no diretório de saída onde estão os artefatos confirmados, prontos para serem testados.

No entanto, há um pequeno problema, para o qual você terá que voltar ao primeiro ponto da postagem de David: se os artistas quiserem modificar o projeto Content adicionando / removendo / movendo arquivos, eles precisam fazer isso abrindo o projeto no Visual Studio (ou editar o arquivo do projeto manualmente, o que duvido que alguém faria). Como eu disse, esse é um pequeno problema, porque eles podem apenas confirmar os novos arquivos no repositório, e você, o codificador, os incluirá no Projeto de Conteúdo quando o código for feito para lidar com eles.

Com essa ideia, Shawn Hargreaveas postou algo sobre o msbuild e a construção dos Projetos de Conteúdo a partir da linha de comando: http://blogs.msdn.com/b/shawnhar/archive/2006/11/07/build-it-ahead-of-time .aspx Sua solução foi criar um novo arquivo, mas acho que é mais fácil e sustentável de usar diretamente o arquivo de projeto já existente.

PS: Desculpe pelo longo post xD