¿Cómo debe un equipo compartir / almacenar contenido del juego durante el desarrollo?

Además de Dropbox, ¿qué ha sido especialmente útil para almacenar y compartir contenido del juego como imágenes durante el desarrollo (conjunto de características similares a Dropbox como trabajar sin conexión, sincronización automática y soporte para Windows / OSX)?

Estamos buscando alojar nuestro propio servidor de SharePoint, pero parece estar realmente centrado en los documentos ... ¿Quizás Box.net funcionaría?

EDITAR

Para el código, estamos usando Git.

Para ser más precisos, estaba buscando una manera fácil y automática para que el contenido producido por artistas / ingenieros de audio estuviera disponible para todos. Características como las aprobaciones de activos tampoco hacen daño. Siguiendo la respuesta vinculada por Tetrad, Alienbrain parecía bastante interesante pero ... está fuera de nuestro presupuesto (puede ser algo en lo que invertir en el futuro).

Lo que terminó haciendo ...

Íbamos a usar Box.net, pero la descarga de las aplicaciones de sincronización para uso de escritorio nos obligó a esperar a que nos contactaran por alguna razón. No tuvimos mucho tiempo para esperar, así que terminamos yendo con Dropbox Teams. Box.net tiene un buen conjunto de características, pero nunca nos sentimos retenidos sin ellas.

Gracias por la ayuda :).

server storage

— irwinb
fuente

¿Estás buscando un sistema de control de versiones? gamedev.stackexchange.com/questions/480/…

— Tetrad

Un simple script y scp?

— jcora

Depende de la naturaleza del contenido:

¿Es un activo cargado por el juego, como un modelo o una textura? Desea un sistema de control de versiones.
¿Es alguna forma de datos que el juego no carga directamente, sino que se utiliza para crear datos cargados directamente por el juego, como una hoja de cálculo de localización? Desea un sistema de control de versiones.
¿Es un documento que describe el diseño del juego, algunos detalles de las características o un proceso o procedimiento técnico? Desea un sistema de control de versiones.
¿Es un archivo que se puede reconstruir a partir de algo que ya está en el control de versiones, como ejecutables y objetos vinculadores? Usted probablemente no quiere un sistema de control de versiones (*).
¿Es un archivo que desea compartir con un compañero de trabajo temporalmente, como un cambio de código o un activo actualizado, que no desea permanentemente en el juego, pero que necesita para continuar su trabajo? No quieres un sistema de control de versiones. (^)

(^) Hay algunas opciones en este caso:

Mencionó Dropbox, que es excelente cuando colabora con equipos a cualquier distancia, pero lo limita a 2 GB. Esto debería estar bien para uso temporal, dado que todos los demás datos deberían estar en control de versión; sin embargo, si necesita más espacio, ahora hay una opción de Dropbox para equipos (de pago) .
Si no desea pagar el costo de un plan de Dropbox más grande, pero solo necesita compartir ocasionalmente archivos grandes, puede ser una opción usar uno de los muchos sitios para compartir archivos (como RapidShare).
Alojar un servidor FTP también puede ser viable para usted.
Si está trabajando en la misma LAN (o puede configurar una VPN), tanto Windows como Mac pueden crear recursos compartidos de red que se pueden escribir entre sí, sin restricciones de tamaño. Es común crear un recurso compartido de lectura / escritura llamado Dropbox, y usarlo para intercambiar archivos. También es común nombrar máquinas después de sus usuarios; es decir, para enviar un archivo a John Doe, puedo abrir \\JOHNDOE\Dropboxel recurso compartido y colocar el archivo allí.
Mención especial para Git si está compartiendo código: puede crear una rama separada con los cambios de su código y acceder a su repositorio principal. Otras personas pueden tomar sus cambios, sin interrumpir su masterrama. (En estos casos, es común colocar su sucursal en un directorio con su nombre, es decir johndoe/bugfix).

(*) Ocasionalmente, querrá confirmar / almacenar archivos ejecutables y de símbolos en algún lugar para solucionar problemas con versiones anteriores, sin necesidad de reconstruir el juego. Este suele ser el caso cuando se trata de volcados de memoria.

— Blair Holloway
fuente

para resumir: todo lo relacionado con el producto que no sea generado por otras cosas relacionadas con el proyecto pasa al control de versiones.

— Jwenting

Respuesta de facto, aunque puede ser más complicado de lo que parece. "como trabajar sin conexión" <- esto significa hg / git / algún otro DVCS, a menos que svn pueda considerarse como "trabajando sin conexión". Sin embargo, la principal preocupación del OP son las imágenes, los DVCS, como sé, no tratan muy bien los archivos binarios, en ese caso puede necesitar SVN.

— kizzx2

svn funciona bien con envíos / actualizaciones poco frecuentes, siempre que haya una buena división del trabajo (de lo contrario, el número de conflictos de fusión puede salirse de control, como con cualquier sistema de este tipo).

— Jwenting 01 de

¿Almacenaría todas las texturas y modelos en el control de origen, incluso si se suman a gigabytes? (Nunca he trabajado en un proyecto con esa cantidad de datos sin código fuente, así que me pregunto cómo la gente hace esto)

— RomanSt

@romkyns: Sí, definitivamente lo almacenaría todo en un VCS. En algún momento, te arrepentirás de no tenerlo. Con respecto a la gestión de repositorios muy grandes: es una molestia, pero puede mitigarse colocando datos en repositorios separados. Nuestro proyecto actual en el trabajo tiene un repositorio "fuente de arte" (más de 100 GB) y un repositorio "intermedio" (~ 20 GB). Los artistas comprometen sus fuentes de textura / modelo en fuente de arte, pero luego las exportan a intermedias para el consumo del juego (o sistema de construcción). Solo los artistas necesitan el repositorio completo de fuente de arte; todos los demás solo necesitan intermedios.

— Blair Holloway