Facilitare le distribuzioni di giochi XNA per i non programmatori

Attualmente sto lavorando a un gioco di ruolo, usando come base lo starter kit RPG di XNA. (http://xbox.create.msdn.com/en-US/education/catalog/sample/roleplaying_game) Sto lavorando con un piccolo team (due designer e un artista di musica / suono), ma sono l'unico programmatore. Attualmente, stiamo lavorando con il seguente sistema (insostenibile): il team crea nuove immagini / suoni da aggiungere al gioco o modifica suoni / immagini esistenti, quindi trasferisce il loro lavoro in un repository, dove manteniamo una build corrente di tutto. (Codice, immagini, suono, ecc.) Ogni giorno o giù di lì, creo un nuovo programma di installazione, che riflette le nuove immagini, le modifiche al codice e il suono, e tutti lo installano.

Il mio problema è questo: voglio creare un sistema in cui il resto della squadra può sostituire i suoni di combattimento, per esempio, e possono immediatamente vedere i cambiamenti, senza dover aspettare che io costruisca. Il modo in cui l'installazione di XNA, se pubblico, codifica tutti i file immagine e audio, quindi il team non può "hot swap". Posso configurare Microsoft VS sulla macchina di tutti e mostrare loro come pubblicare rapidamente, ma volevo sapere se c'era un modo più semplice per farlo.

Qualcuno si è imbattuto in questo quando si lavora con i team che utilizzano XNA?

Prima di tutto, non penso che tu debba pubblicare e creare un programma di installazione ogni volta. Basta compilare il progetto e posizionare i file di output (ovvero la cartella EXE e Content più eventuali dipendenze DLL che si potrebbero utilizzare) nel repository e dovrebbe essere eseguito anche sul proprio computer, purché sia ​​installato il redist XNA.

Per quanto riguarda la tua domanda, posso pensare a due soluzioni, una delle quali prevede l'installazione di Visual Studio sui loro computer e l'altra prevede alcune modifiche al gioco:

• Chiedi loro di installare Visual Studio e di insegnare loro a passare le loro risorse attraverso la pipeline di contenuti XNA. Devono solo creare un progetto di pipeline di contenuti, trascinare lì i file e creare. Quindi possono scambiare i file XNB risultanti con quelli nella cartella del progetto ed eseguire EXE per vedere le modifiche.

• Se stai sviluppando per Windows, puoi modificare il codice in modo che carichi le risorse in fase di esecuzione nei loro formati originali, senza dover passare attraverso la pipeline di contenuti. Per caricare immagini che potresti usare Texture2D.FromStream(come in questo esempio ) e per l'audio la migliore soluzione che ho trovato è stata invece usare l'API FMOD (come in questo esempio ). Quindi possono semplicemente scambiare le risorse direttamente ed eseguire il gioco.

Per fare ancora di più, potresti anche provare a rendere il tuo gioco il più possibile guidato dai dati. Questo in pratica significa che tutto ciò che dovresti poter modificare facilmente nel gioco, come le statistiche della classe dei personaggi o il percorso delle immagini e dei file audio che stai usando, dovrebbe essere tolto dal codice e inserito in file di testo esterni (ad es. XML, JSON, INI). Quindi devi solo modificare quei file in un editor di testo per vedere le modifiche nel gioco e non è necessario ricostruirlo.

Un po 'in ritardo alla festa, ma ecco la mia idea.

Vorrei andare con la terza possibilità che non comporta nulla di simile alla modifica della base di codice già esistente. Funzionerà se, eseguirai il commit (e la copia) dei file binari (il file .exe attuale del gioco e i .dll associati dalla compilation) da qualche parte in una directory di output, ad esempio con uno script post-build. In seguito, assumerò che stiamo parlando di Visual Studio 2010 e XNA Game Studio 4.0 (la procedura è molto simile per altre versioni, basta sostituire alcuni numeri)

Quindi, l'idea è: creare uno script (.cmd) nella radice del progetto, dove risiede la soluzione .sln, con i seguenti passaggi:

1. Richiamare il "Prompt dei comandi di Visual Studio 2010":

   chiama "C: \ Programmi (x86) \ Microsoft Visual Studio 10.0 \ VC \ vcvarsall.bat" x86

   Questo per far sì che il nostro script sia in grado di trovare le librerie XNA e tutti gli strumenti e i binari richiesti.

2. Chiamare l'attività MSBuild sul Progetto contenuto (.contentproj):

   msbuild / proprietà: XNAContentPipelineTargetPlatform = Windows / proprietà: XNAContentPipelineTargetProfile = Raggiungi mygame.content / projectfile.contentproj

   È possibile modificare le proprietà in base a piattaforme / profili diversi specificati. Puoi anche andare oltre per creare contenuti per più piattaforme contemporaneamente (Windows Phone, Xbox 360 o Windows). Il profilo può essere: Reach o HiDef (http://msdn.microsoft.com/en-us/library/ff604995.aspx)

3. Copia ricorsivamente l'output nella cartella in cui i file binari + gioco reale sono archiviati nel repository:

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

   Per i dettagli sulle bandiere, è possibile richiamare nel prompt dei comandi: xcopy /?. I più importanti sono:, /dper copiare solo i file modificati - nel caso in cui tu abbia molti asset è utile non copiare più e più volte quelli già esistenti e non modificati; /yper sovrascrivere automaticamente i file esistenti in modo che possano essere aggiornati con una versione più recente. L'ho usato xcopyperché il normale copynon può copiare cartelle ricorsivamente per quanto ne so - e probabilmente stai strutturando il contenuto in cartelle e sottocartelle. Inoltre, è meglio del normale copy(molte bandiere diverse).

4. Chiama in pausemodo che lo script attenda l'input dell'utente. Questo è utile per verificare se la build andava bene e non si sono verificati errori.

Ora, gli artisti (o chiunque) che modificano i file di contenuto, devono semplicemente fare doppio clic sullo script .cmd e il nuovo contenuto verrà creato e copiato nella directory di output in cui si trovano gli artefatti commessi, pronto per essere testato.

Tuttavia, c'è un piccolo problema, per il quale dovrai tornare al primo punto del post di David: se gli artisti vogliono modificare il progetto Content aggiungendo / rimuovendo / spostando i file, devono farlo aprendo il progetto in Visual Studio (o modifica manuale del file di progetto, che dubito che chiunque farebbe). Come ho detto, questo è un piccolo problema, perché potrebbero semplicemente eseguire il commit dei nuovi file nel repository e tu, il programmatore li includerà nel progetto di contenuto quando il codice sarà fatto per gestirli.

Su questa idea, Shawn Hargreaveas ha pubblicato qualcosa su msbuild e la creazione di progetti di contenuto dalla riga di comando: http://blogs.msdn.com/b/shawnhar/archive/2006/11/07/build-it-ahead-of-time .aspx La sua soluzione era quella di creare un nuovo file, ma penso che sia più facile e più gestibile utilizzare direttamente il file di progetto già esistente.

PS: scusami per il lungo post xD