¿Vale la pena planificar antes de saltar en el código?

Siempre pensé que la planificación es importante para un juego. Pero no sé en qué punto. Algunos me dicen que codifique en lugar de planificar, pero siento que todavía es importante porque cuando esté en el código sabrá qué hacer a continuación más fácilmente. Actualmente estoy trabajando en un juego que tendrá mucho contenido, así que decidí comenzar un documento de diseño que presentara ese contenido y, en un nivel lateral, estoy haciendo pruebas de concepto para verificar si se puede hacer. Partes de cada prueba de concepto podrían usarse luego en el juego real.

EDITAR: Estoy trabajando solo en este proyecto.

Entonces mi pregunta es: ¿Vale la pena planificar antes de saltar al código? Todavía estoy interesado en saber lo que otros tienen que decir sobre esto. Porque todavía recibo algunas personas que dicen que debo codificar en lugar de pensar ... ¿cuál es tu opinión sobre esto?

Dijiste dos cosas inteligentes en tu pregunta:

1. "código en lugar de pensar": hay una filosofía completa que describe esto: http://gettingreal.37signals.com/toc.php
2. "pruebas de concepto para verificar si se puede hacer": he visto y tenía muchas ideas que resultaron imposibles o extremadamente difíciles de hacer cuando estaban casi terminadas. A veces, simplemente no puede predecirlo, porque su entorno de programación (lenguaje, bibliotecas, rendimiento de hardware) lo limita.

Por eso digo:

• diseñe, pero no haga un gran documento de diseño si no está buscando colaboradores o inversores, a menos que sea divertido para usted y lo tome como un descanso de la programación;
• ten siempre en mente lo que quieres lograr; cada módulo debe tener una entrada y salida diseñada; de esa manera puede probar fácilmente el módulo y no tener la sensación de vagar en la niebla;
• recuerde que diseña la mayor parte del tiempo de todos modos, ya que escribir código toma solo alrededor del 5% de su tiempo (al menos escribir el código final);
• la programación no es una ciencia teórica, en lugar de verificar si algo funcionará en una hoja de papel, simplemente puede codificarlo e intentarlo; el producto final se trata principalmente de hacer que la entrada del usuario sea infalible, la GUI se vea bien y se maneje con casos especiales: una prueba sucia de una idea se puede hacer de inmediato;
• crea una lista de tareas si tienes miedo de olvidar tus ideas
• hable con sus amigos sobre sus ideas, ya que serán menos entusiastas y pueden tener más experiencia en un campo; una vez tuve la idea de mantener en secreto los parámetros de la unidad (en un juego estratégico), pero mi amigo me dijo que es una mala idea, ya que jugó un juego como este y fue una experiencia de usuario terrible.

Sí, pero solo un poco .

Para la programación de juegos, especialmente la programación de juegos, es esencial tener un buen caso de uso antes de escribir cualquier código. Por ejemplo, qué se supone que debe hacer el jugador, dónde se supone que debe ir y cómo, cómo interactúa con el mundo, etc. Esto puede ser un guión gráfico bosquejado en papel, o salir de una discusión con un compañero ... Esto es parte del diseño del juego , y será una tontería comenzar a codificar sin siquiera tener una idea aproximada de cómo se supone que debe jugarse el juego.

Pero los juegos tienen que ser creados de forma iterativa . No puedes crear una gran especificación para tu juego y esperar que sea divertido jugarlo. Necesita pruebas de juego regulares para descubrir qué funciona y qué no, y seguir iterando. Cuanto más rápido se ejecute el ejecutable, más rápido se puede probar el diseño del juego, mejor será el juego al final. Por lo tanto, siempre es mejor comenzar a codificar lo antes posible, desde un diseño de juego muy no formal, ver qué sale y seguir adelante.

Una cosa es segura, ya que está codificando solo, no necesita ningún documento o metodología de diseño de software sofisticado, el código fuente es el diseño.

Algunos dicen que deberías codificar en lugar de pensar? Bueno, para codificar necesita saber lo que quiere crear, para saber qué quiere crear, primero debe pensar lo que quiere tener, ergo, debe pensar antes de codificar;).

Y en serio, probablemente no necesites un plan detallado desde el principio, pero tener un esquema y / o hitos siempre es beneficioso, también para tu actitud, cuando taches las cosas como lo hiciste, estarás más animado a hacer más trabajo.

Se necesita codificación y planificación. Primero planifique, luego codifique, pero no planifique todo de una vez. Planifique un núcleo, codifíquelo, actualice su plan según sea necesario, luego planifique las características que se suman a la jugabilidad, gráficos, sonidos, sprites, etc., esto hará que el juego que está creando se vea mejor y, en general, se sienta mejor. Obviamente, puede ejecutar dicho ciclo más de una vez, y le aconsejo que tome decisiones que respalden la ampliación si surge la necesidad.

Debe saber a dónde va antes de escribir código y escribir / dibujar puede ser una buena manera de materializar lo que desea lograr. Digo dibujar porque dibujar diagramas, bocetos, etc. también puede ayudarte mucho. No necesita hacer un documento maravilloso hecho con Word ni nada, solo tome un lápiz y un trozo de papel (¿muchos trozos de papel?) Y dibuje, escriba todo lo que pueda pensar.

Para mí, es una buena práctica usar lápiz y papeles, ayuda a materializar sus ideas y también establece dónde quiere ir para evitar ir a cualquier parte, fijar su objetivo. Funciona para todo lo que necesita reflexión. Y es obvio en muchos dominios escribir cosas antes de hacer el trabajo real.

Hacer lo que funcione para usted. Personalmente, planifico las cosas en pequeña medida, pero no tengo documentos de diseño, son planes extremadamente detallados antes de comenzar a codificar cualquier cosa. Haga lo que sea más productivo para usted, especialmente porque está trabajando solo.

(Supongo que la pregunta se hace desde el punto de vista del diseño del código / arquitectura, no desde el punto de vista del diseño del juego, aunque la respuesta al menos en cierto grado se aplica a ambos).

Como ya se dijo, necesita ambos, y necesita equilibrarlo. Tanto el diseño excesivo como el diseño insuficiente de su flujo / estructura de código pueden causar problemas. Es difícil decir cuál es el equilibrio correcto, pero en general encuentro que necesito tener al menos una vaga idea de cómo el resto del código se unirá con lo que estoy programando en este momento, y pensar en posibles problemas, de lo contrario, tiendo a "codificarme en un callejón sin salida": me meto en una situación en la que me doy cuenta de "está bien, ahora gracias a cómo resolví este problema, creé un nuevo problema que dio toda mi solución anterior (o incluso más, en el peor de los casos) ) inútil ".

En general, en mi opinión, puede juzgar aproximadamente si tiene el equilibrio correcto al pensar en escenarios de "qué pasaría si" como en "qué pasaría si luego (cuando todo esté completamente implementado en el paradigma similar al que estoy usando ahora) descubra que la parte A debe funcionar de manera ligeramente diferente, lo que significa que tengo que volver a trabajar por completo la parte B que se conecta con ella para acomodar los cambios ". Si el cambio arquitectónico en una parte no requiere que cambie más de una o dos partes, y los cambios no caen en cascada (lo que significa que a su vez debe cambiar también las siguientes partes que se conectan a la parte B, y luego las partes que se conectan a ellos, etc.), el código está compartimentado de una manera relativamente buena.

Pero realmente, esto es algo por lo que te sentirás después de ganar algo de experiencia. Esta es en parte la razón por la que todos dan consejos al principio del juego para codificar primero algo conocido y fácil (Breakout / Tetris / Snake) y hacerlo completamente, con todos los menús, sonidos, efectos, todo para que el juego esté completamente terminado: es mejor arruinar un proyecto más pequeño, y hacerlo (ya sea de manera buena o mala) lo ayudará exactamente a tener una idea de cuán lejos abarcan los efectos de varias decisiones arquitectónicas.