¿Qué tipo de documento para el diseño del juego? [cerrado]


9

¿Qué tipo de soporte / formato utiliza para almacenar y difundir la documentación de diseño de su juego? Wiki? Archivos doc? Archivos en el repositorio? ¿Carpeta compartida? Google Doc?

Proporcione pros y contras para cada uno.

Respuestas:


14

Estoy usando Google Docs porque todo lo que realmente necesito es un editor de texto que esté en línea. Puedo colaborar con personas en línea con relativa facilidad y sé que mi información está segura allí en caso de que mi computadora falle.

Otra opción que vale la pena mirar es usar Dropbox . Coloque un documento de Word allí e instantáneamente tendrá un entorno colaborativo con control de versiones.


55
PD Google Docs es completamente INCREÍBLE para la edición colaborativa en tiempo real a partir de la reciente actualización (creo que a mediados de septiembre). Dropbox, por otro lado, no tiene resolución de conflictos (cambia el nombre de un archivo en conflicto, lo que puede crear aún más confusión), por lo que es bastante terrible para la edición simultánea de archivos, pero excelente para la copia de seguridad y el intercambio / edición no simultánea.
Ricket

¿Hay alguna manera de tener documentos de Google locales (como el servidor de la empresa instalado)?
Klaim

1
@Klaim, si obtienes Google Apps para tu dominio, puedes hacerlo. google.com/apps/intl/en/business/index.html
Jesse Dorsey

44
Noctrine, todavía está alojado en google. Simplemente aparece en su dominio por cortesía de una entrada de CNAME. Si necesita que los datos estén físicamente en su red local, esto no funcionará. OTOH, a menos que requiera una autorización de seguridad para trabajar en su "juego", este último requisito suele ser más una indicación de paranoia y megalomanía que cualquier otra cosa.
drxzcl

1
Sí, ya sé de dominios (ya tengo varias aplicaciones de Google para mis dominios), pero digamos que no tiene acceso a Internet, sino solo a una red local.
Klaim

5

Wiki

Pros:

  • La última versión siempre accesible a través de la web, desde fuera del sitio, etc.
  • Bastante fácil de usar (si se mantiene alejado de aquellos con un choque de trenes para formatear como MediaWiki, eso es)
  • Indexación automática, búsqueda, categorización fácil
  • Fácil de atribuir cambios a las personas y hacerlas responsables de los cambios.
  • Admite la vinculación y hace que sea fácil y efectivo factorizar detalles
  • Puede enlazar a páginas wiki directamente desde informes de errores internos y otra correspondencia, lo que hace que la verificación de un error sea muy fácil
  • Historial de versiones y control de revisión típicamente integrado

Contras:

  • A veces DEMASIADO fácil de cambiar (* ver más abajo) y requiere disciplina
  • Las páginas pueden no estar sincronizadas cuando se editan de forma aislada (a menudo no hay 'búsqueda y reemplazo global', por ejemplo)
  • Las páginas quedan huérfanas o reemplazadas y se dejan como campos minados potenciales para los codificadores más adelante. ( "¿Qué quieres decir con que ya no lo estamos implementando? ¡Todavía está en la wiki de diseño!" )
  • La sintaxis puede ser un poco esotérica a menos que obtenga el paquete correcto
  • Tiene que organizar el alojamiento o aceptar lo que está disponible en línea de forma gratuita
  • No hay una ruta clara a través del documento: ¿cómo se lee 'todo'?
  • Difícil de imprimir. ¿Puedes imprimirlo todo con un clic? ¿Puede imprimir fácilmente todo lo relevante para una característica dada para llevarlo a una reunión? ¿Se puede anotar la versión digital fácilmente sin ocultar el documento subyacente?

(* Utilizamos un wiki para un proyecto y los diseñadores siempre estuvieron tentados a entrar y 'mejorar' partes de él, incluso en las características que habían sido firmadas y enviadas para ser codificadas. Luego, cuando QA llegó a probar la característica, sería una pesadilla porque a menudo el diseño sugeriría algo diferente a lo que realmente estaba codificado, y tomaría un poco de trabajo frustrante descubrir qué sucedió primero, el cambio en el diseño o el código).


1
Todos sus inconvenientes no son realmente un problema si está utilizando Confluence, con la excepción del alojamiento que no es gratuito a menos que lo aloje en su servidor LAN y permita que otros se unan a través de DynDNS o un servicio similar.
LearnCocos2D

Lo curioso es que usamos JIRA para nuestro proyecto. Supongo que nadie consideró Confluence también o tal vez el costo era demasiado alto. Voté tu respuesta de todos modos.
Kylotan

Documentos de diseño basados ​​en Wiki ... Por favor, por favor ... No lo hagas.
Laurent Couvidou

3

Archivos de texto

En mi proyecto actual, estoy usando archivos de texto sin formato en mi carpeta "Docs" del proyecto, almacenados en el repositorio al lado del código.

Pros:

  • La documentación se mantiene cerca del trabajo real, por lo que es fácil de encontrar.
  • El formato simple significa que es fácil y rápido mantener la documentación.
  • El formato simple también significa que hay poco riesgo de perder documentación debido a bloqueos del servidor, corrupción de archivos, etc.
  • Un tiempo de configuración absolutamente mínimo hace que este sea un gran comienzo para un solo desarrollador o equipos pequeños (2-3 personas).
  • El uso del control de versiones significa que los cambios se rastrean y, a menudo, uno puede vincular los cambios en la documentación directamente con un cambio en el código.
  • Tan fácil de trabajar como el texto, por lo que la búsqueda, la edición, etc. a menudo se pueden hacer con herramientas de línea de comandos.

Contras:

  • Más de un par de usuarios y el documento se desincronizarían fácilmente.
  • Sin enlaces, por lo que puede usar un documento grotescamente grande o varios documentos más pequeños pero desconectados.
  • Opciones limitadas de formato y publicación (aunque la conversión, como a través de Markdown, es fácil de hacer).
  • Tan fácil de trabajar como el texto, a menudo la única forma de buscar, editar de forma avanzada, etc., es usar herramientas de línea de comandos.

No es algo en lo que quiera confiar para ningún tipo de trabajo en equipo, pero el poder de los archivos de texto en el repositorio para permitirle trabajar directamente no debe subestimarse para el desarrollador único. Actualmente utilizo un documento como una especie de resumen / planificador maestro que contiene el diseño general, un segundo documento que actúa como una lista de tareas pendientes que el juego necesita, un tercer documento como un rastreador de errores suelto y documentos auxiliares para elabora en "característica x" según sea necesario.


2

No utilice un formato / editor de documentos que no sea compatible con múltiples usuarios (por ejemplo, MS Word, Open Office Writer). Solo una persona puede editar el documento, e incluso con el control de código fuente es demasiado fácil comenzar a trabajar en una versión desactualizada, y al guardar eso básicamente destruyes todo lo que el otro usuario ha hecho desde la última vez que el usuario actualizó su versión del documento

Las carpetas compartidas son, con mucho, la peor solución y una opción absoluta para cualquier tipo de activo que se suponga que se trabaje en colaboración. Nunca puede estar seguro de que alguien más esté trabajando en ese archivo en este momento, o lo hará en los próximos minutos. Tampoco tiene seguimiento de cambios y no puede volver a una versión anterior en caso de desastre (error humano o estupidez humana o negligencia humana).

Preferiblemente use un Wiki, pero uno que sea fácil de usar y sea verdaderamente WYSIWYG. Yo personalmente juro por Confluence , que también se usa en estudios de desarrollo de juegos más grandes y solo cuesta $ 10 para hasta 10 usuarios y espectadores ilimitados.

La mayoría de los otros wikis (MediaWiki, TikiWiki, etc.) tienen el inconveniente de que tienen una curva de aprendizaje empinada o incluso son prácticamente inutilizables por personal no técnico. No es que no puedan aprenderlo, pero (con razón) no aceptan usar un sistema de documentos que básicamente requiere que escribas código como HTML. Este es mi motivo favorito: los wikis que dicen que son WYSIWYG, pero todo lo que hacen es insertar la sintaxis en el texto que está escribiendo. Eso no es WYSIWYG!

La guía para usar un wiki es colocar cada encabezado en una página separada, para que pueda cortar el documento en muchas partes manejables. Confluence ofrece características con las que puede agregar todas esas subpáginas en un solo sitio o documento, que se puede exportar a PDF, por ejemplo.


1

Creo que One Note es una buena opción. Es algo así como un Wiki pero con una gran cantidad de soporte de edición de texto enriquecido. Además del cliente de escritorio estándar que viene con Office, hay una versión basada en la web con el paquete Office Live . Honestamente, creo que la versión basada en la web, que es gratuita, debería ser suficiente para la mayoría de las necesidades y cuando se combina con Skydrive tienes un sistema bastante bueno para colaborar en un documento en vivo.


evernote.com también es una posibilidad para las personas que desean una alternativa gratuita a OneNote. Tiene un cliente web y clientes para varias plataformas (computadoras de escritorio, teléfonos) y almacena todas sus notas "en la nube". Creo que también tiene funciones de colaboración, pero pueden ser premium.
CodexArcanum

0

Para uno de mis proyectos de código abierto, hemos estado usando (gasp) SharePoint para almacenar documentos y medios. Administrar usuarios y permisos es bastante sencillo, y tiene soporte para el historial completo de versiones. Hemos tenido el sitio de SharePoint durante aproximadamente cuatro años, por lo que es muy posible que haya mejores opciones hoy en día. Sin embargo, nos ha funcionado bastante bien. Está alojado por un tercero (por alrededor de $ 20 / mes), por lo que después de la configuración inicial prácticamente no ha habido mantenimiento por nuestra parte. Además de admitir bibliotecas de documentos e imágenes, SharePoint tiene soporte Wiki, aunque no estoy seguro de qué tan bien se compara con los motores Wiki más populares.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.