Como cliente, tratando de hacer que un programador / programador desarrolle mis ideas en un programa funcional, ¿qué debo proporcionar a mis desarrolladores?

Soy el director de un grupo de desarrollo de juegos de inicio (digo "grupo" porque todavía no es una empresa oficial). Recientemente he ganado la voluntad de algunos codificadores que están dispuestos a ayudarme con el proyecto, pero están pidiendo documentación.

Entiendo la necesidad de documentación, y tengo muchas de nuestras ideas en algunos documentos diferentes, pero imagino que querré organizarla de alguna manera que los desarrolladores puedan entender de forma individual y colectiva.

¿Hay algo que deba dejar fuera de ese documento? Si es así, ¿qué tipo de cosas? ¿Existe una plantilla adecuada para este tipo de documento? En caso afirmativo, ¿dónde puedo encontrarlo? ¿Hay algo más que deba saber para ofrecerles a los codificadores antes de que comiencen su trabajo?

Sé que tengo muchas preguntas aquí. Espero que eso no sea un problema. Gracias de antemano por cualquier orientación!

El desarrollo de juegos generalmente funciona un poco diferente al desarrollo de aplicaciones. La razón es que los juegos suelen tener requisitos mucho menos estrictos. No tiene un problema comercial bien definido que su software debe resolver. Los únicos requisitos verdaderos de un juego son "se ejecuta correctamente en la plataforma objetivo", "atrae al grupo demográfico objetivo" y "es divertido jugar" (y tal vez "vende muchas microtransacciones" si se encuentra en esa sección de la industria ) Todo lo demás está sujeto a cambios durante el desarrollo.

Sin embargo, para asegurarte de que todos los desarrolladores del juego estén trabajando en la misma dirección y no terminen peleando hasta la muerte por diferencias creativas, debes tener una "visión" codificada de cómo quieres que se vea y juegue el juego final. . Esta visión generalmente está codificada en un Documento de diseño de juegos . Tal documento generalmente describe:

• La premisa básica del juego:
  • The pitch pitch : La idea principal del juego, descrita lo más brevemente posible.
  • ¿Cuál es el género del juego?
  • ¿Quién es tu objetivo demográfico?
  • ¿A qué plataformas estás apuntando?
• La mecánica del juego:
  • ¿Qué acciones puede realizar el jugador en este juego y cómo afectan al juego?
  • ¿Qué entidades que no son jugadores están en el juego, cómo se comportan y cómo interactúan entre sí y con el jugador?
• El alcance:
  • ¿Cuánto contenido quieres que tenga el juego?
  • ¿Qué nivel de calidad quieres que tenga ese contenido?
• La dirección estética del juego:
  • ¿Qué ambiente general quieres que tenga el juego?
  • ¿Cómo quieres que se vea el juego?
  • ¿Cómo quieres que suene el juego?
• Cuando se trata de historia, depende mucho del género. Algunos juegos no necesitan historia en absoluto. Muchos juegos solo necesitan unas pocas oraciones. Pero si está creando un juego basado en la trama, como un juego de rol o una aventura, esta puede ser la parte más larga del documento de diseño y puede incluir:
  • Una descripción del mundo en el que se desarrolla el juego y sus ubicaciones clave.
  • Una descripción de los personajes importantes, su apariencia, su personalidad y su historia de fondo.
  • Una descripción básica de la trama que se cuenta durante el juego.

Si buscas en la web, puedes encontrar muchas plantillas para documentos de diseño de juegos. La industria de los juegos tiene menos formalidades y procesos estandarizados que el resto de la industria, por lo que no encontrará el único estándar ISO para gobernarlos a todos. Simplemente trate de encontrar un estilo que se adapte a su proyecto, su equipo y su metodología de trabajo.

Sin embargo, esté abierto a cambios durante el desarrollo. Cuando los documentos de diseño de juegos de juegos populares se filtran al público, ya sea intencionalmente o no, generalmente puede notar algo interesante. Si compara estas primeras notas de diseño con el juego terminado, generalmente habrá muchas diferencias considerables. Esto suele ser el resultado de un proceso de diseño que los desarrolladores de juegos llaman Fail Faster :

1. Crea un diseño rudo
2. Crea un prototipo simple
3. Juega con una mentalidad crítica y descubre lo que no funciona
4. Revisa tu diseño
5. Regrese a la etapa 2

Por lo tanto, no tenga miedo de cambiar o cortar características cuando se dé cuenta durante las pruebas de juego de que en realidad no son tan divertidas como lo eran en su cabeza. Además, esté abierto a sugerencias del equipo. La mayoría de las personas en la industria del desarrollo de juegos decidieron unirse a la industria porque quieren poner en práctica sus propias ideas de juegos. Por lo tanto, dar a su equipo una influencia creativa puede ser un gran motivador para ellos. Pero como buen productor, también es su deber decir "¡No!" si cree que una idea no funcionaría o excedería el presupuesto.

Tengo muchas ganas de jugar tu juego.