In che modo un team dovrebbe condividere / archiviare i contenuti di gioco durante lo sviluppo?


8

Oltre a Dropbox, cosa è stato particolarmente utile per archiviare e condividere contenuti di gioco come immagini durante lo sviluppo (funzionalità simili impostate su Dropbox come lavorare offline, sincronizzazione automatica e supporto per windows / osx)?

Stiamo cercando di ospitare il nostro server SharePoint, ma sembra essere davvero focalizzato sui documenti ... Forse Box.net funzionerebbe?

MODIFICARE

Per il codice, stiamo usando Git.

Per essere più precisi, stavo cercando un modo semplice e automatico per rendere disponibili a tutti i contenuti prodotti da artisti / ingegneri audio. Funzionalità come l'approvazione delle risorse non fanno male. Seguendo la risposta collegata da Tetrad, Alienbrain sembrava piuttosto interessante ma ... è fuori dal nostro budget (potrebbe essere qualcosa su cui investire in futuro).

Cosa ha finito per fare ...

Stavamo andando con Box.net ma il download delle app di sincronizzazione per l'uso desktop ci ha richiesto di aspettare di essere contattati da loro per qualche motivo. Non abbiamo avuto molto tempo per aspettare, quindi abbiamo finito con Dropbox Teams. Box.net ha un bel set di funzionalità, ma non ci siamo mai sentiti bloccati senza di loro.

Grazie per l'aiuto :).


4
Stai cercando un sistema di controllo versione? gamedev.stackexchange.com/questions/480/...
Tetrade

Una semplice sceneggiatura e SCP?
jcora,

Risposte:


18

Dipende dalla natura del contenuto:

  • È una risorsa caricata dal gioco, come un modello o una trama? Volete un sistema di controllo della versione.
  • È una forma di dati non caricata direttamente dal gioco, ma utilizzata per creare dati caricati direttamente dal gioco, come un foglio di calcolo di localizzazione? Vuoi un sistema di controllo della versione.
  • È un documento che delinea il design del gioco, alcuni dettagli delle funzionalità o un processo o una procedura tecnica? Vuoi un sistema di controllo della versione.
  • È un file che può essere ricostruito da qualcosa che è già in controllo di versione, come eseguibili e oggetti linker? Lei probabilmente non si desidera un sistema di controllo di versione (*).
  • È un file che si desidera condividere temporaneamente con un collega, come una modifica del codice o un asset aggiornato, che non si desidera permanentemente nel gioco, ma che è necessario per continuare il proprio lavoro? Non vuoi un sistema di controllo della versione. (^)

(^) Ci sono alcune opzioni in questo caso:

  • Hai citato Dropbox, il che è fantastico quando stai collaborando con i team a qualsiasi distanza, ma ti limita a 2 GB. Questo dovrebbe andare bene per un uso temporaneo, dato che tutti gli altri dati dovrebbero essere sotto controllo della versione; tuttavia, se hai bisogno di più spazio, ora c'è un'opzione (a pagamento) Dropbox per squadre .

  • Se non vuoi pagare per il costo di un piano Dropbox più grande, ma devi solo condividere file di grandi dimensioni, utilizzare una delle dozzine di siti di condivisione di file (come RapidShare) potrebbe essere un'opzione.

  • L'hosting di un server FTP può anche essere praticabile per te.

  • Se stai lavorando sulla stessa LAN (o puoi configurare una VPN), sia Windows che Mac possono creare condivisioni di rete che sono scrivibili l'una dall'altra, senza limiti di dimensioni. È comune creare una condivisione di lettura / scrittura denominata Dropbox e utilizzarla per lo scambio di file. È anche comune nominare le macchine dopo i loro utenti; cioè per inviare un file a John Doe, posso aprire la condivisione \\JOHNDOE\Dropboxe posizionare lì il file.

  • Menzione speciale per Git se condividi codice: puoi creare un ramo separato con le modifiche del codice e passare al repository principale. Altre persone possono quindi prendere le tue modifiche, senza interrompere il tuo masterramo. (In questi casi, è comune posizionare il tuo ramo in una directory con il tuo nome, ad es johndoe/bugfix.)

(*) Occasionalmente, ti consigliamo di eseguire il commit / archiviazione di file eseguibili e file di simboli da qualche parte per eseguire il debug di problemi con build precedenti, senza bisogno di ricostruire il gioco. Questo è comunemente il caso delle discariche.


1
per riassumere: tutto ciò che riguarda il prodotto che non è generato da altre cose relative al progetto passa al controllo della versione.
jwenting

Risposta di fatto, sebbene possa essere più complicata di quanto sembri. "like working offline" <- questo significa hg / git / alcuni altri DVCS, a meno che svn non possa essere considerato "lavorare offline". Tuttavia, la principale preoccupazione dell'OP sono le immagini, poiché i DVCS, come so, non gestiscono molto bene i binari, in quel caso potrebbe aver bisogno di SVN.
kizzx2,

svn funziona bene con invii / aggiornamenti poco frequenti, purché ci sia una buona divisione del lavoro (altrimenti il ​​numero di conflitti di unione può sfuggire di mano, come con qualsiasi sistema di questo tipo).
jwenting

Conserveresti tutte le trame e i modelli nel controllo del codice sorgente, anche se si sommano a gigabyte? (Non ho mai lavorato su un progetto con quella quantità di dati non di codice sorgente, quindi mi chiedo come la gente faccia questo)
RomanSt

1
@romkyns: Sì, sicuramente memorizzerei tutto in un VCS. Ad un certo punto, ti pentirai di non averlo. Per quanto riguarda la gestione di repository di grandi dimensioni: è una seccatura, ma può essere mitigato inserendo i dati in repository separati. Il nostro attuale progetto al lavoro ha un repository "art-source" (100+ GB) e un repository "intermedio" (~ 20 GB). Gli artisti impegnano le loro fonti di trama / modello in arte-fonte, ma poi le esportano in intermedio per il consumo da parte del gioco (o sistema di costruzione). Solo gli artisti hanno bisogno del repository completo di fonti d'arte; tutti gli altri hanno solo bisogno di intermedi.
Blair Holloway,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.