Me gusta pensar que todo lo que nos rodea puede representarse, de una forma u otra, a través de un diagrama. Incluso si es solo un diagrama lineal que representa la transición entre los estados de un objeto en particular a lo largo del tiempo (como un ser vivo, pasando por una serie de estados desde el nacimiento hasta la muerte). Utilizo diagramas para exponer mis pensamientos e ideas para la implementación real. Improviso bastante.
Por lo tanto, mis diagramas están la mayor parte del tiempo en un nivel muy alto y se sienten como mapas mentales .
Para agregar algunos ejemplos, este es en realidad un mapa de herencia de clase (uno que ha sido cortado) en mi juego donde Interactive Object es el tipo base.
Este es un diagrama FSM ( máquina de estado finito ) para una trampa de púas (esas impresionantes trampas en las que pisas y picos woosh aparecen desde el suelo).
Este es un diagrama del manual (llamado de esta manera porque pretende ser un diagrama de regreso a menudo ) que dibujé recientemente. Describe los componentes de un juego y también ayuda a reunir los recursos necesarios, ya que puede ver de inmediato qué se necesita y qué no. Recomiendo estos en proyectos pequeños, ya que se vuelven bastante grandes en los grandes. Sin embargo, se pueden ampliar aún más, para que eso pueda arreglar las cosas.
Cuando voy a un nivel inferior, generalmente es porque necesito planificar los aspectos más complejos de mi arquitectura, y generalmente trato con UML allí. Sin embargo, nunca me concentro en generar UML absolutamente limpio y correcto. Adopté lo que más me gustó de la convención UML y lo convertí en un buen UML de mapa mental. Es simple y hace el trabajo por mí, pero no lo haría en un entorno donde se espera UML real, por razones obvias.
Otra situación cuando tengo que ir a un nivel inferior es cuando tengo que describir algoritmos reales. Yo uso lo que yo llamo diagramas de flujo . Es un formato inspirado en los diagramas utilizados en las pruebas de caja blanca .
Una muestra de la trampa de espinas que dibujé ahora se vería así:
Esta es normalmente la capa final entre diagramas e implementaciones de algoritmos reales. Si surge la necesidad, detallo más los diagramas de flujo (con instrucciones adicionales ejecutadas), y deduzco o calculo la complejidad, y construyo casos de prueba precisos. También prefiero diagramas sobre pseudocódigo.
No está relacionado con el desarrollo del juego, también tengo un buen formato para describir las pantallas en una aplicación de pantallas múltiples, la funcionalidad que el usuario puede activar en cada pantalla y la relación entre pantallas. Normalmente los construyo antes de comenzar el desarrollo real, y actúan como un mapa durante todo el proceso de desarrollo. Si es para un cliente, ¡el diagrama de pantalla es aún más útil! Me ayuda a pasar por todo el proyecto, de principio a principio, y tener en cuenta todas las funcionalidades que va a necesitar. Por lo tanto, es invaluable proporcionar una estimación precisa de costo y tiempo.
Así que sí, definitivamente diagrama todo y cualquier cosa. Si tengo una idea, puedo y definitivamente dibujaré un diagrama para ella. Si de alguna manera comienzo un proyecto sin al menos un diagrama muy amplio que me respalde, me siento paralizado.