Al diseñar un juego, ¿cuál es su forma preferida de diseñar el juego antes de comenzar a codificar?

Asumiré que te refieres al diseño de software, ya que el diseño del juego ocurre antes, durante y después de la codificación.

Debido a la naturaleza propensa a cambios del código del juego. Por lo general, evito cualquier diseño de software complejo, especializado o profundo. Optando por un diagrama de muy alto nivel de los principales sistemas y su interacción. Utilizo cualquier cosa, desde lucidchart hasta powerpoint simple, lápiz y papel para hacer este diagrama. Piensa realmente UML simplificado. Ver la arquitectura general visualmente generalmente nos ayuda a mí y a mi equipo a descubrir cómo van las cosas juntas.

Descubrí que cualquier documento de diseño de software más detallado tiende a editarse varias veces al día y cuesta más tiempo y esfuerzo mental de lo que contribuye.

A veces siento que un sistema es lo suficientemente complejo como para garantizar un documento de diseño. Pero eso es bastante raro. Sin embargo, solo he trabajado en juegos pequeños a medianos. Entonces, mmm.

Una cosa que siempre mantengo super documentada es la API del servidor del cliente. Perder ese documento puede costarle días (lamentablemente lo sé por experiencia). Me gusta usar hojas excell compartidas para eso.

Esa es una pregunta interesante que tienes aquí. No lo he pensado hasta ahora, lo preguntaste.

Cuando pienso en una idea de juego y empiezo a desarrollarla, primero trato de traducir mis ideas en conceptos de programación. Como trabajo principalmente en Unity, un ejemplo podría ser:

“Entonces quiero implementar un sistema de punto de control. Podría almacenar la posición del último jugador conocido en una variable y luego llamar al administrador del juego para crear una instancia del jugador en dicha posición “.

Y aplico ese mismo proceso para cada parte de la mecánica central del juego antes de saltar a la programación real. Al separar un gran problema en piezas más pequeñas, puedo codificar más rápido y terminar un prototipo MVP de una manera bastante rápida.

Por supuesto, no siempre funciona, algunas mecánicas son más difíciles de implementar. Pero al menos estoy en una posición relativamente cercana a mi objetivo.

Puede haber muchos pasos o menos. La más importante es enumerar las actividades del juego. 2 a 6 verbos de acción simple; las cosas que hacen los jugadores Ese es el juego.

Correr, disparar, resolver, coleccionar, fabricar, comerciar, explorar, negociar, construir, cavar, conducir, emparejar, etc.

Comienzo con un documento dedicado a las notas, donde escribo todas mis ideas, o las olvidaré. Comienzo con cualquier idea inicial candente que me haya movido a crear el documento. Solo un montón de viñetas. Luego empiezo a organizar mis pensamientos dispersos en temas. Mi documento de notas continuará creciendo durante todo el desarrollo y después.

Dependiendo del juego, también puedo hacer algunos prototipos en papel. Esto es totalmente para mi beneficio, ya que trato de aislar las ideas y traducirlas a un juego real. Por ejemplo, es posible que pueda hacer una versión funcional de su juego de mesa e invitar a otros a jugar con usted. Puede transmitir el espíritu del juego completo, o solo puede expresar algunas de las características clave que crees que son importantes.

Una vez que mis notas alcanzan una especie de masa crítica, y una imagen clara se está fusionando, escribo un documento de tono interno entre 1–4 páginas. Es posible que ya haya transmitido la idea a algunos miembros del equipo y haya recibido aliento para mostrarles más. Describo los principales conceptos y características del juego, y por qué merece ser creado. La diversión debería ser obvia.

Si lo pretendo para un editor, puedo continuar trabajando en el documento de campo con asistencia del equipo de arte hasta que sea formal y hermoso, hermético y exterior y esté listo para que lo lean los extraños hostiles. El recuento de páginas probablemente seguirá siendo el mismo. Los editores no quieren leer. Se estimarán plataformas, audiencia, tiempo de juego y tiempo de desarrollo.

Los editores ya no se preocupan mucho por los documentos de presentación en estos días, porque francamente, no tienen mucha imaginación. Quieren ver el juego tan claramente como se lo puedes mostrar. Un juego terminado sería bueno, o una demostración tan ajustada que es casi un juego terminado. Quieren que haya invertido mucho de su propio dinero.

Si el juego seguirá siendo independiente e interno, entonces comenzaré un documento de diseño preliminar. Esto se vuelve más específico sobre las características del juego. Su propósito es compartir la visión del juego con el equipo, definir el alcance y permitir que el equipo comience a aislar las características clave para el desarrollo y la programación.

El diseño preliminar generalmente se convierte en el verdadero documento de diseño. Por lo general, se espera que el documento de diseño se complete antes de que comience el desarrollo, aunque es posible que los cronogramas no lo permitan. Nunca he trabajado en un juego que no requiera que actualice y agregue al diseño constantemente durante todo el ciclo de desarrollo. El GDD debería dejar poco a la imaginación. En un mundo ideal, cualquier miembro de su equipo debería poder encontrar lo que necesita del GDD y ser capaz de usar esa estructura como un plan para construir lo que sea que necesiten construir.

En la práctica, a menudo detallo un tema en mi documento de notas antes de pasarlo al documento de diseño. Si trabajo directamente en el documento de diseño, es posible que tenga que dejar de trabajar por cualquier motivo antes de que termine. Puede tardar días o semanas en completarse, y no me gusta tener temas incompletos en mi GDD. Su experiencia puede ser diferente.

Ese es mi enfoque de diseñador no técnico, pero hay muchos otros métodos. Lo que sea que funcione. Es posible que tenga las habilidades para comenzar a construir prototipos digitales muy temprano, y creo que es una excelente manera de lanzar el juego. No tengo esas habilidades, pero a menudo presiono a los miembros del equipo que sí tienen esas habilidades para ayudarme con los prototipos. Si usted es un diseñador programador, es posible que desee simplemente comenzar a construir. Creo que es peligroso sin un plan claro, pero no tengo dudas de que hay muchas historias de éxito.

Tengo muchas ideas. Comienzo con mi idea inicial. Imagina cómo jugará eso, desarrollarlo en mi mente. Puedo o no documentar mis pensamientos en esta etapa.

Cuando tengo claro mi premisa central, hago un prototipo vivo. Hago algo que muestra los elementos centrales del juego. Luego modifico eso hasta que me gusta cómo se siente, luego lo amplío. Expandir y ajustar, expandir y ajustar.

Pero definitivamente me quedo en la fase de “idea dando vueltas en mi cabeza” por un buen tiempo antes de comenzar a codificar. Necesita tiempo para que lo desarrolle en mi mente.

Idea. Explicarlo a un niño.

Prototipo. Constrúyelo. En dura realidad. Use papel, tarjetas, fichas, ladrillos de lego, lo que sea.

Iterar. Crea muchas versiones. Busca ese factor divertido.

Puedes comenzar a codificar ahora