Faciliter les déploiements de jeux XNA pour les non-programmeurs

Je travaille actuellement sur un RPG, en utilisant le kit de démarrage RPG de XNA comme base. (http://xbox.create.msdn.com/en-US/education/catalog/sample/roleplaying_game) Je travaille avec une petite équipe (deux designers et un artiste de musique / son), mais je suis le seul programmeur. Actuellement, nous travaillons avec le système (non durable) suivant: l'équipe crée de nouvelles photos / sons à ajouter au jeu, ou modifie des sons / photos existants, puis elle engage son travail dans un référentiel, où nous gardons une version actuelle de tout. (Code, images, son, etc.) Chaque jour environ, je crée un nouvel installateur, reflétant les nouvelles images, les changements de code et le son, et tout le monde l'installe.

Mon problème est le suivant: je veux créer un système où le reste de l'équipe peut remplacer les sons de combat, par exemple, et ils peuvent immédiatement voir les changements, sans avoir à attendre que je construise. La façon dont la configuration de XNA, si je publie, encode tous les fichiers image et son, donc l'équipe ne peut pas "remplacer à chaud". Je peux configurer Microsoft VS sur la machine de tout le monde et leur montrer comment publier rapidement, mais je voulais savoir s'il y avait un moyen plus simple de le faire.

Quelqu'un s'est-il heurté à cela en travaillant avec des équipes utilisant XNA?

Tout d'abord, je ne pense pas que vous ayez besoin de publier et de créer un programme d'installation à chaque fois. Générez simplement le projet et placez les fichiers de sortie (c'est-à-dire l'EXE et le dossier Content ainsi que toutes les dépendances DLL que vous utilisez) dans le référentiel, et il devrait également fonctionner sur leur ordinateur, tant qu'ils ont la redistribution XNA installée.

Quant à votre question, je peux penser à deux solutions, dont l'une consiste à installer Visual Studio sur leurs machines, et l'autre implique d'apporter quelques modifications au jeu:

• Demandez-leur d'installer Visual Studio et apprenez-leur à transmettre leurs ressources via le pipeline de contenu XNA. Il leur suffit de créer un projet de pipeline de contenu, d'y faire glisser les fichiers et de les créer. Ensuite, ils peuvent échanger les fichiers XNB résultants avec ceux du dossier de projet et exécuter l'EXE pour voir les modifications.

• Si vous développez pour Windows, vous pouvez modifier votre code afin qu'il charge les ressources lors de l'exécution dans leurs formats d'origine, sans avoir à passer par la ligne de contenu. Pour charger des images que vous pourriez utiliser Texture2D.FromStream(comme cet exemple ) et pour l'audio, la meilleure solution que j'ai trouvée était d'utiliser l'API FMOD à la place (comme cet exemple ). Ensuite, ils peuvent simplement échanger les actifs directement et lancer le jeu.

Pour aller encore plus loin, vous pouvez également essayer de rendre votre jeu aussi axé sur les données que possible. Cela signifie essentiellement que tout dans le jeu que vous devriez pouvoir modifier facilement, comme les statistiques de classe de personnage ou le chemin des images et des fichiers audio que vous utilisez, doit être retiré du code et placé dans des fichiers texte externes. (par exemple XML, JSON, INI). Ensuite, il vous suffit de modifier ces fichiers dans un éditeur de texte pour voir les changements dans le jeu, et il n'est pas nécessaire de les reconstruire.

Un peu tard pour la fête, mais voici mon idée.

J'irais avec la 3e possibilité qui n'implique rien de tel que la modification de la base de code déjà existante. Cela fonctionnera si, vous allez valider (et copier) les binaires (le jeu .exe réel et les .dll associés de la compilation) quelque part dans un répertoire de sortie - par exemple avec un script post-construction. À partir de là, je suppose que nous parlons de Visual Studio 2010 et XNA Game Studio 4.0 (la procédure est très similaire pour les autres versions, il suffit de remplacer certains chiffres)

Donc, l'idée est: créer un script (.cmd) à la racine de votre projet, où réside la solution .sln, avec les étapes suivantes:

1. Appelez l '"invite de commandes Visual Studio 2010":

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

   C'est pour que notre script puisse trouver les bibliothèques XNA, et tous les outils et binaires nécessaires.

2. Appelez la tâche MSBuild sur le projet de contenu (.contentproj):

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

   Vous pouvez modifier les propriétés en fonction des différentes plateformes / profils spécifiés. Vous pouvez même aller plus loin pour créer le contenu de plusieurs plateformes à la fois (Windows Phone, Xbox 360 ou Windows). Le profil peut être: Reach ou HiDef (http://msdn.microsoft.com/en-us/library/ff604995.aspx)

3. Copiez récursivement la sortie dans le dossier où les binaires + le jeu réel sont stockés sur le référentiel:

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

   Pour plus de détails sur les drapeaux, vous pouvez invoquer dans l'invite de commande: xcopy /?. Les plus importants sont:, /dpour copier uniquement les fichiers modifiés - dans le cas où vous avez de nombreux actifs, il est utile de ne pas copier encore et encore ceux déjà existants et non modifiés; /ypour remplacer automatiquement les fichiers existants afin qu'ils puissent être mis à jour avec une version plus récente. J'ai utilisé xcopyparce que la normale copyne peut pas copier récursivement les dossiers pour autant que je sache - et probablement vous structurez le contenu dans des dossiers et sous-dossiers. De plus, c'est mieux que la normale copy(beaucoup de drapeaux différents).

4. Appelez pausepour que le script attende l'entrée de l'utilisateur. Ceci est utile pour vérifier si la construction s'est bien passée et qu'aucune erreur n'a été rencontrée.

Désormais, les artistes (ou n'importe qui) qui modifient les fichiers de contenu doivent simplement double-cliquer sur le script .cmd et le nouveau contenu sera construit et copié dans le répertoire de sortie où se trouvent les artefacts validés, prêts à être testés.

Cependant, il y a un petit problème, pour lequel vous devrez revenir au premier point du message de David: si les artistes veulent modifier le projet de contenu en ajoutant / supprimant / déplaçant des fichiers, ils doivent le faire en ouvrant le projet dans Visual Studio (ou modifier le fichier de projet à la main, ce que je doute que quiconque ferait). Comme je l'ai dit, c'est un petit problème, car ils pourraient simplement valider les nouveaux fichiers dans le référentiel, et vous, le codeur les inclura dans le projet de contenu lorsque le code sera fait pour les gérer.

Sur cette idée, Shawn Hargreaveas a publié quelque chose sur msbuild et la construction des projets de contenu à partir de la ligne de commande: http://blogs.msdn.com/b/shawnhar/archive/2006/11/07/build-it-ahead-of-time .aspx Sa solution a été de créer un nouveau fichier, mais je pense qu'il est plus facile et plus facile à utiliser directement le fichier de projet déjà existant.

PS: Désolé pour le long post xD