¿Cuán detallados y / o completos son / son sus documentos de diseño del juego antes de comenzar un proyecto?

Lo que me pregunto es qué tan completos suelen ser sus documentos de diseño antes de comenzar la implementación de un proyecto. Estoy hablando de proyectos medianos a muy pequeños con un equipo muy pequeño aquí, donde incluso el documento completo puede tener solo unas pocas docenas de páginas.

¿Comienza con un marco básico y comienza a desarrollar los detalles al mismo tiempo que comienza la implementación?

¿Completas completamente cada sección antes de que se inicie alguna implementación? Si es así, ¿qué cambio porcentual has visto después de que comienza la implementación?

Si tiene experiencia con uno de los dos escenarios que describí, me encantaría conocer su opinión sobre los problemas que causó esa ruta en particular y qué obstáculos cree que le ayudaron a evitar.

Si la idea del juego se basa en gran medida en un concepto de juego inusual , lo prototipo de inmediato , utilizando un proyecto anterior como plantilla. El 95% del tiempo esto lleva a darse cuenta de que no es tan divertido como me imaginaba, y hacerlo divertido requeriría más recursos de lo que vale.

Mientras tanto, si estoy trabajando en otro proyecto, me tomo mi tiempo, hago un garabato para tener una idea de cómo debería ser el prototipo (trate de no distraerse con el boceto). Luego lo comparto con mis amigos, en parte para ver si tienen algún aporte, pero principalmente para pensar en cosas que no son obvias de inmediato (siempre hay toneladas de cosas, incluso para las personas más inteligentes que piensan en las ideas más simples). Después de un par de horas como esta, anotaré algunos conceptos clave que deben estar en la arquitectura, literalmente ~ 20 palabras. Entonces puedo construir un prototipo cuando tenga tiempo.

Actualmente mis diseños de juego se han detallado adecuadamente antes de comenzar.

Desarrollaré la mayoría de las clases importantes, dibujaré algunas maquetas (los dibujos suelen ser horribles), haré una descripción del juego.

Aunque esto se debe principalmente a tener un largo viaje al trabajo y nada más que hacer. Preferiría pasar menos tiempo haciendo esto y más tiempo programando, ya que desarrollar clases que probablemente cambiarán parece excesivo.

Trabajando en equipos pequeños en juegos pequeños (equipos de un solo hombre en juegos casuales pequeños), pasé del "diseño pesado" al "diseño rápido". Encuentro que el desarrollo iterativo (dos semanas centrado en un solo objetivo, por ejemplo, el juego principal) ayuda a desarrollar el diseño y le da algo para jugar, lo que significa que no cambiará de opinión e invalidará el 90% de lo que diseñó. se veía bien "en papel" pero no en el juego.

Dicho esto, paso la mayor parte de mi tiempo de diseño en la mecánica y el juego principales (cómo funcionará el juego principal), y eso rara vez cambia mucho: recibe ajustes y, a veces, recojo nuevas ideas o dejo caer viejas ideas; pero nada pasa sin un prototipo funcional.

En el aspecto técnico, cualquier cosa debe pensar al menos unos minutos antes de hacer que el código sea real. Pero, siempre puedes refactorizar más tarde.

La documentación de diseño tiene un costo de mantenimiento; A medida que las cosas cambian, debe volver y volver a leer y actualizar cualquier documento existente. Como tal, debería ser un objetivo de producción minimizar la cantidad de documentación que se puede mantener, ya que eso maximizará el tiempo dedicado a construir el juego.

A partir de ahí, se deduce que no desea diseñar todo hasta el más mínimo detalle de antemano, porque sabe muy bien que la mitad cambiará, y luego se enfrentará a una gran cantidad de tiempo perdido. Haz el diseño mínimo necesario para comenzar a hacer el juego principal. Cuando termine, repita según sea necesario, luego repita el proceso para cada nueva característica.