Me refiero principalmente a UML, pero cualquier método que funcione es viable. Entonces, ¿realmente modelas tus juegos con UML / otros diagramas o métodos diferentes? Tuve una asignatura en mi universidad sobre modelar con UML y parecía más esfuerzo que beneficio real, pero me doy cuenta de que podría ser solo porque nunca he creado un sistema informático complejo enorme. Entonces, ¿vale la pena y qué tipos de diagramas / métodos suelen ser * los mejores?
* Por supuesto, muchas veces se deben elegir herramientas concretas para resolver problemas concretos, pero quizás haya algunos patrones.
Editar: Olvidé una cosa importante: ¿creas diagramas antes o después de implementar cosas? Lo que quiero decir es que cuando uno diseña e implementa algo que generalmente cambia de opinión o surge algo inesperado y uno tiene que hacer cambios, a veces importantes, y hacerlo en diagramas ya complejos parece tan inútil como en el código mismo.
fuente
Respuestas:
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.
fuente
Ciertamente, tanto estructural como conductual, mi regla general es que hago diagramas cuando el costo de hacer el diagrama es menor que intentar recordar qué demonios estaba pensando un mes después, o cuando necesito explicarme claramente a mí mismo. algún otro desarrollador
Diagramas de clases cuando la jerarquía de herencia se vuelve suficientemente compleja
Diagramas de objetos cuando cosas como la creación de instancias de objetos se convierten en algo que limita con la creación de un monstruo de Frankenstein a partir de partes dispares, especialmente útil en usuarios de vértices de fregadero de cocina y sombreadores de píxeles, para asegurarse de que todos los bits necesarios se introduzcan en la tubería
Diagramas de secuencia cuando las interacciones detalladas entre un conjunto de objetos se vuelven complejas; esto es extremadamente útil en el modelado de flujos de representación complejos donde se necesita información previamente calculada en ubicaciones aguas abajo apenas relacionadas
fuente
Los diagramas son una excelente manera de comunicarse, documentar y ayudar a su diseño , y el diseño es la parte más importante del desarrollo de software. UML tiene muchas funciones, pero no debe utilizarlas todas al mismo tiempo, solo las que son útiles.
Al navegar en una nueva ciudad, ¿realmente se detiene y mira un mapa, en lugar de continuar y seguir las señales? De eso se trata el diseño frente a la codificación. Cuando las cosas no son familiares, cuando el problema es complejo, cuando te sientes perdido, es cuando pensar en el diseño es más útil, y es mejor hacerlo antes que después. Es mucho más fácil cambiar su diseño antes de implementar algo .
Los diagramas son una excelente manera de visualizar el problema y ayudar a su diseño, especialmente para los pensadores visuales (que la mayoría de nosotros en gamedev me imagino). Muchos problemas se vuelven triviales, los defectos se vuelven evidentes, cuando está claramente mapeado en un diagrama. Algunos problemas que puede encontrar en un diagrama:
Además, los diagramas son excelentes para comunicar y documentar su diseño, ya sea para personas no técnicas o personas que son nuevas en su proyecto, y recuerde, ¡en 6 meses usted también es prácticamente nuevo en el proyecto!
La forma en que usa UML debe basarse en estas consideraciones. Diagramación por tu propio bien? Use la notación con la que se sienta más cómodo. ¿Colaborando con otros desarrolladores? Intente incluir los detalles de las llamadas a la API, los tipos de mensajes, las direcciones de las dependencias. ¿Hablando de arquitectura? Cajas negras y conexiones simples serán suficientes. Nadie usa el conjunto completo de características UML de todos modos , , además es muy útil como un conjunto de notación estandarizada que mucha gente entiende, mientras que mis garabatos de servilleta pueden ser incomprensibles para usted y viceversa.
En cuanto a mí, uso diagramas todo el tiempo: simples dibujos de bloc de notas para proyectos personales, simples diagramas UML en el trabajo. Este diagrama UML es lo que consideraría demasiado complejo, y uno que nunca haría porque el costo de producirlo y mantenerlo supera su beneficio, pero por supuesto YMMV.
fuente
Yo diría que hay dos tipos de diagramas. Diagramas formales y garabatos.
Con respecto a los diagramas formales, los hago cuando estoy trabajando con otros programadores, pero rara vez lo hago cuando estoy programando solo.
Sin embargo, eso no significa que me siento y codifique lo que se me ocurra. En mi opinión, lo más importante al programar (o en realidad cualquier cosa en la vida) es pensar primero y hacer después .
La codificación es una tarea muy mecánica. Escribe y las palabras aparecen en la pantalla. La idea es que cuando comience a codificar, ya debería haber resuelto el problema en cuestión. Hacer garabatos es una excelente manera de ordenar sus pensamientos, e incluso forzarse a pensar que necesita hacer la parte de codificación correctamente. Los garabatos no están destinados a guardarse para referencia futura, solo para que pueda comprender fácilmente sus procesos de pensamiento.
No te preocupes si te tomas demasiado tiempo para pensar. Creo que se produce un buen equilibrio cuando dedicas el 90% de tu tiempo a pensar y el 10% a codificar. He conocido a varios programadores "senior" que viven "no tenemos tiempo para pensar, solo para hacer". Pero incluso si llaman a su código "hecho" antes que aquellos que se toman el tiempo para pensar en lo que están haciendo, ellos (o las almas desafortunadas que quedan después) pasan innumerables horas arreglando y arreglando algo que debería haberse construido correctamente. desde el principio.
¡Lo mejor es que pensar es gratis! no tienes que estar sentado en tu computadora para pensar. Puede pensar en el código mientras come, viaja, hace ejercicio ... De hecho, las mejores ideas surgen cuando menos las espera, así que mantenga su mente abierta en todo momento y solo comience a codificar cuando realmente sepa lo que sabe. vamos a codificar.
Aquí hay un artículo relacionado con el que estoy de acuerdo.
Editar : con respecto al formato real y el tipo de diagramas, te recomiendo que vayas a estilo libre, y en realidad a mano en lugar de usar herramientas preempaquetadas. Recuerde que el punto es ayudarlo en su proceso de pensamiento, así que siéntase libre de dibujar lo que quiera. La semántica es lo que quiera que sean, y pueden ser diferentes entre los diagramas, e incluso entre diferentes partes del diagrama.
Hay tres beneficios principales con los diagramas de estilo libre / manuscritos sobre las herramientas preempaquetadas:
No está obligado a cumplir con el tipo de diagrama admitido por la herramienta que elija. A veces los mapminds funcionarán, a veces algo más como UML estará bien, mientras que otras veces un diagrama lógico funcionará. Otras veces, un diagrama completamente personalizado es lo que funciona, y ninguna herramienta puede darle toda la flexibilidad de los diagramas de estilo libre (intente perforar un agujero a través del papel y continúe en el reverso del papel, en su paquete favorito, y vea qué sucede)
Pasará más tiempo haciendo diagramas en lugar de usar la herramienta. Independientemente de la herramienta, el lápiz y el papel son siempre más rápidos en la diagramación que en el teclado y pasar el mouse por los menús para encontrar los elementos específicos que está buscando.
No necesita una computadora para escribir a mano. La mayoría de las veces estoy haciendo diseños complejos, los hago en una biblioteca, un café o incluso dentro de un avión. Además, las buenas ideas siempre aparecen en el momento menos apropiado, así que asegúrese de llevar siempre algo con lo que escribir y algo sobre lo que escribir.
fuente
Puede valer la pena señalar algunas charlas de diagramas de diseño de la Game Developers Conference 2013. Estos son algunos ejemplos muy prácticos y probados, y parece que se han presentado en muchas conferencias a lo largo de los años.
(Las otras respuestas han hecho un trabajo admirable al demostrar por qué y cómo los diagramas centrados en el diseño pueden ser tremendamente útiles en la planificación, construcción, crecimiento y mantenimiento de una base de código, por lo que dejaré ese aspecto en paz y confiaré en que estos recursos podrían ser útiles a cualquiera que visite la pregunta).
Joris Dormans y Ernest Adams discutieron el diseño del juego Machinations / sistema de diagrama de equilibrio. (Aquí hay un video de GDC Vault con fondos de pago de GDC EU 2012; muestras de GDC 2013 en el wiki de Dormans.) En lugar de intentar parafrasear, así es como el wiki describe el sistema:
Noah Falstein dio una charla llamada "El arte arcano de los diagramas de dependencia de rompecabezas" (video de GDC Vault con paredes de pago ). No puedo encontrar ningún enlace que no sea de pago aquí, pero varias personas han discutido o publicado sus notas en línea.
Ambas conversaciones discutieron cuándo crearon y cómo mantuvieron estos diagramas, en una medida u otra.
fuente
Probablemente debería consultar este artículo sobre el uso de una gramática abstracta simple para describir su ciclo de juego, cómo puede ayudarlo a identificar problemas de diseño y lo fácil que es iterar a ese nivel.
http://www.gamasutra.com/blogs/JoshuaStarner/20130205/186060/Applying_Abstract_Models_to_Game_Design.php
También puedo guiarte hacia mi propio trabajo sobre el tema, más basado en la economía del ciclo del juego, usando recursos abstractos para rastrear cosas como oportunidades, suerte o preparación:
http://www.stephanebura.com/diagrams/
Si encuentra útil este enfoque, debería echar un vistazo a las Maquinaciones de Joris Dormans, una herramienta para hacer tales diagramas y ejecutar sus simulaciones:
http://www.jorisdormans.nl/machinations/
Todo su proceso se explica en su libro:
http://www.amazon.com/Game-Mechanics-Advanced-Design-Voices/dp/0321820274/
fuente