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

17

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?

jmp97
fuente

Respuestas:

20

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.) )

Nef
fuente
77
+1, buen consejo. No te dejes atrapar por la infame parálisis de análisis, ya que esto no te lleva a ninguna parte. Mientras que la refactorización es una herramienta poderosa para corregir fallas pasadas, no tenga miedo de cometer errores.
Michael Klement
1
Ahh Parálisis de análisis . Mi mayor enemigo! Debería construir un juego donde Analysis Parálisis sea ​​servido como End-Boss. Mejor empiezo diseñando la arquitectura del juego primero ... ¡Noooo! Bromas aparte: ¡Gran respuesta y buen comentario!
bummzack
12

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".

Tétrada
fuente
8

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
jmp97
fuente
¿Puedes dar más detalles sobre el desarrollo basado en pruebas en un entorno de juego? Aparte de cierta lógica básica, nunca he encontrado que los programas altamente interactivos sean muy adecuados para este tipo de cosas. Además, está enlazando a la página de desambiguación;)
drxzcl
2
@Ranieri Si dibuja una línea entre las partes que interactúan con el hardware de gráficos y la entrada del usuario, la prueba es sencilla.
Jonathan Fischoff
@Ranier Gracias, arreglé el enlace. Estoy de acuerdo en que presentar pruebas primero para simulaciones interactivas o juegos cliente-servidor puede ser complicado. Además de las pruebas unitarias, es probable que desee realizar algunas pruebas de funcionalidad de nivel superior y posiblemente sesiones de reproducción que se ejecutan a ciertos intervalos. En cualquier caso, pensar en las pruebas primero es probable que valga la pena en muchos escenarios. Encuentre algunas vistas interesantes en gamedev.stackexchange.com/questions/1905/…
jmp97
5

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.

samboush
fuente
1
Este es un buen consejo, aunque recomendaría un momento u otro tipo de recurso vinculado en el bucle, después de lo cual simplemente saldrá (0) y probará otro prototipo.
@ Joe Wreschnig: los planes de tiempo se pueden incluir en AnalysingResults (), pero creo que puede usar RapidPrototype por un tiempo y terminarlo más tarde o ponerlo en los planes. Mejor que te quedes atascado para siempre :). En RapidPrototype también puedes simular la funcionalidad. Es bastante útil de muchas maneras.
samboush
1

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).

lindon fox
fuente
2
No creo que haya una metodología de desarrollo que no pretenda "hacerlo y tener un diseñador de software sólido".
@ Joe Creo que muchas metodologías de "peso pesado" tienden a preferir CYA sobre software sólido. De hecho, gran parte de mi experiencia no ágil tiende a ser "no tiene por qué ser correcto, tiene que ser en este momento", mientras que "ágil" pretende decir "tiene que ser en este momento, pero haz todo lo que puedas puede hacer las cosas bien sobre la marcha ".
dash-tom-bang
Yo diría que el desarrollo ágil tiene muy poca influencia sobre si el código es sólido o no. La esencia de Agile es pasar todo su tiempo de desarrollo solo en cosas importantes. El código aún puede ser un desastre al momento de la entrega, porque la calidad del código (o la falta de deuda técnica) rara vez es una medida del éxito en una entrega.
Magnus Wolffelt