¿Hacerlo frente al diseño de software sólido?

Con apenas tiempo suficiente para completar los juegos que creamos, ¿cómo puede lograr un buen equilibrio entre una arquitectura de software sólida y hacer un buen progreso para lograrlo?

Mi desafío personal: ¿Qué tal ser efectivo hoy y pensar a largo plazo al mismo tiempo? Además, mientras lo hace, ¿es mejor que desee aprender cosas nuevas en el camino en lugar de recurrir a los mismos patrones repetitivos que ha estado utilizando en los últimos 5 años?

Cuanta menos experiencia tenga, más tiempo perderá con el diseño inicial. Hacer buenos diseños es algo que aprenderá al hacerlo y luego ver / evaluar cómo resulta. Algunas decisiones tienen implicaciones de largo alcance pero oscuras. Después de algunos juegos, probablemente puedas hacer que el diseño inicial sea bastante sólido y valdrá la pena invertir más tiempo en esta etapa.

Mi lema: hacer las cosas en primer lugar, pero usar su sentido común para detectar qué componentes son más críticos que otros y diseñarlos bastante bien, dentro de su límite de tiempo. Por ejemplo, si la IA es crítica para tu juego, asegúrate de poder extenderla / cambiarla fácilmente más adelante. O, si vas a escribir un componente que usarás en cada juego, diséñalo para que sea reutilizable. Controla tu tiempo y no te vuelvas loco en el diseño. Establezca una fecha límite de diseño y después de eso, comience a piratear todo para obtener su fecha límite de lanzamiento. ¡Pero asegúrate de tener en cuenta qué puntos necesitan refactorizar / rediseñar después y calcular en algún momento antes de comenzar el próximo juego para mejorar esas cosas, para que no te muerdan!

Un buen consejo: si tiene que elegir entre dos opciones, no se demore demasiado en los detalles. Muy a menudo, no hay "bueno" o "malo". En algunas situaciones, A será mejor, en otras B será, y en general, la diferencia entre ambos no siempre valdrá la pena.

Hay mucha experiencia que ganar en el diseño de software o juegos, así que asegúrese de dedicar parte de su tiempo a la investigación (por ejemplo, leer un libro sobre diseño, leer sobre la experiencia de otros, hablar con otros programadores sobre sus diseños, etc.) )

La gente es terrible para predecir el futuro. Esto es especialmente cierto para los juegos, donde los requisitos pueden cambiar a diario.

Hay un principio llamado YAGNI , también conocido como "No lo vas a necesitar", que básicamente dice que no debes implementar algo hasta que sepas que lo vas a necesitar.

He visto tantos sistemas empantanados con rigidez arquitectónica que en realidad no usaron ninguno de ellos, ya que las características que las personas pensaban que iban a necesitar nunca llegaron a ser utilizadas.

Mi filosofía personal es hacer lo más simple que pueda funcionar . Dicho esto, hay una diferencia entre Getting It Done y Hacking Shit Together. Escribir código con un propósito no debe implicar hacer cosas que generan "olor a código" como hacer público todo, tener clases de blob que hagan todo, o cualquiera de esas docenas de otras cosas que significan código "malo".

Esto se evalúa como verdadero en mi mentalidad hoy:

• Pragmatismo sobre ideología
• (1) Haz que funcione (2) luego hazlo bien - el juego termina si olvidas el paso 2
• ¡Liberarlo!
• Demasiado diseño inicial será una pérdida de tiempo
• TDD y Clean Code llevan a diseños de software más simples y estables

Soy amigo de la creación rápida de prototipos de software. Especialmente durante el desarrollo del juego. Es bueno para aprender, probar y usar cosas rápidamente. Para la programación cercana al hardware o algoritmos complicados es el mejor método para mí.

Theory();
RapidPrototype();
bool bOk = false;
while(!bOk)
{
 Testing();
 LotOfFixing();
 PlayingWith(); 
 bOk= AnalysingResults();
}
FinalFastAndNiceDataStructuresAndCode();

Mi versión de Rapid Prototype debe tener la corteza de prototipo adecuada:

• Max interfaz de entrada amigable para configurar directivas y configurar variables o datos.
• Estable excepciones y manejo de errores.
• En línea, como la función de depurador, pero a nivel de lo que necesita.
• Max interfaz de salida amigable para mostrar o capturar resultados de todas las formas posibles y necesarias.

Ventajas:

• Puede mejorar la corteza de RapidPrototype durante todo el desarrollo.
• Puede ver y configurar su código de muchas maneras.
• Puede enfocarse solo en la teoría y el problema de lo que necesita resolver.
• Puede desarrollar rápidamente cualquier parte nueva del proyecto y probarlo con el resto de las cosas finales.
• Puede entregar cosas nuevas para usar en el llenado de contenido más rápidamente y finalizarlo más tarde (especialmente en el caso de sandbox)
• Puede describir y mostrar fácilmente principios o soluciones a cualquier otra persona. En línea.
• El prototipo funcional y transparente es la mejor fuente de información para el código final (cualquier otra persona puede hacerlo).

Si lo haces bien, puedes tener una versión real de depuración / aprendizaje de tu producto al final.
Lo estamos utilizando en nuestro proyecto y estamos contentos con él.

Echa un vistazo al desarrollo ágil de software . Aunque no es una bala de plata, su objetivo es hacer ambas cosas (hacerlo y tener un diseño de software sólido).