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?
Respuestas:
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:
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:
Ventajas:
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).