¿Planificación de juegos y diseño de software? Siento que UML no es conveniente

En mi universidad, siempre enfatizan y exageran sobre el diseño UML y otras cosas, en las que siento que no funcionará bien con el diseño de la estructura del juego. Ahora, solo quiero un consejo profesional sobre cómo debo comenzar el diseño de mi juego. La historia es que tengo cierta habilidad en la programación y he hecho muchos juegos menores, como hacer que algún juego de plataformas en 2D funcione hasta cierto punto. El problema que encuentro sobre mi programa es el diseño de baja calidad. Después de codificar por un tiempo, las cosas comienzan a desmoronarse debido a una mala planificación (cuando agrego una nueva función, tiende a hacer que tenga que volver a codificar todo el programa). Sin embargo, planificar todo sin una sola falla de diseño es demasiado ideal. Por lo tanto, ¿algún consejo sobre cómo debo planificar mi juego? ¿Cómo debo ponerlo en imágenes visibles, para que mis amigos y yo podamos ver los diseños?

Planeaba comenzar a codificar un juego con mi amigo. Este será mi primer trabajo en equipo, por lo que cualquier consejo profesional sería un placer. ¿Hay alguna otra alternativa que UML?

Otra pregunta es ¿cómo se ve normalmente la creación de prototipos?

Solo quiero un consejo profesional sobre cómo debo comenzar el diseño de mi juego.

El diseño del juego es la especificación de la jugabilidad, los activos, los sistemas de puntuación, etc., estos no son específicos del software. Como tal, UML es la herramienta incorrecta para esa tarea.

Cuando se trata de diseñar el código para implementar estos sistemas, UML es una buena herramienta para la tarea, ya que su equipo lo sabe y se adhiere a los tipos de diagramas más comunes. Normalmente, cuando intente diseñar una característica, sabrá si necesita usar una descripción o un diagrama. Si necesita usar un diagrama, UML le ofrece una forma estándar de dibujarlo, lo cual es algo bueno.

Después de codificar por un tiempo, las cosas comienzan a desmoronarse debido a una mala planificación (cuando agrego una nueva función, tiende a hacer que tenga que volver a codificar todo el programa).

Eso generalmente es un problema con la forma en que programa, en lugar de cómo planea. Un buen software generalmente es fácil de extender y reutilizar. Si se apega a las buenas prácticas de programación, este problema disminuirá. Pero una mejor planificación también ayudará, y no necesita diagramas complejos para esto. Solo tener una lista de características significará que cuando codifica una cosa, tiene las otras características en mente y puede considerarlas a medida que codifica.

Por lo tanto, ¿algún consejo sobre cómo debo planificar mi juego? ¿Cómo debo ponerlo en imágenes visibles, para que mis amigos y yo podamos ver los diseños?

Parece que estás mezclando 2 problemas aquí, el diseño del juego y el diseño del código.

Sugiero escribir primero un diseño de juego básico, especificando las características que necesita, los gráficos y los sonidos que necesita, cómo se gana y se pierde el juego, etc. Busque 'documentos de diseño' si necesita ayuda.

A partir de ahí, tendrá una idea de las características que necesita para codificar. Puede mirar cada característica a su vez e intentar pensar en cómo implementarlas. Los diagramas pueden ayudar a mostrar las relaciones entre diferentes clases y objetos en su juego, pero la habilidad de saber qué objetos necesitan existir es algo que debe aprender a través de la práctica y / o la lectura adicional.

Además, intente trabajar en proyectos más pequeños y menos ambiciosos. Eso lo acostumbrará a escribir un buen código de trabajo, sin necesidad de una extensa planificación o reescrituras.

No entender algo hace que sea fácil de descartar. El UML es una herramienta de ingeniería utilizada para comunicar las ideas que tiene de forma estructurada. Un juego es un sistema que puede ser diseñado como cualquier otro. En todo caso, la complejidad y el dinamismo de un juego hacen que una representación visual de sus partes y sus interacciones sean invaluables.

Los diagramas UML son diferentes vistas de un modelo del sistema en discusión. Comienzo con casos de uso para una persona que se sienta frente a mi programa y lo inicia. En el caso de un juego, hay dos tipos de usuarios: diseñadores y jugadores. Escribo un caso de uso para cada una de las cosas que puedo ver haciendo. Luego hago algunas tarjetas CRC para determinar qué servicios necesito proporcionar. Luego hago un diagrama de clase para las interfaces que proporcionarán estos servicios y sus relaciones. Esto se basa en las tarjetas CRC. Luego vienen los diagramas dinámicos para eventos como la inicialización que requieren planificación y orquestación. Luego diagramas estáticos más detallados que muestran las clases que implementan las interfaces.

Todo el tiempo estoy escribiendo código y creando prototipos y evolucionando en la dirección de proporcionar los servicios para cumplir con los requisitos de mi juego. No se crea nada que no sea compatible con el usuario a través de los casos de uso. Escribo algunos elementos de diagrama inútiles, pero entre la codificación de la interfaz y la diagramación escribo muy poco código inútil. Los diagramas me dan la confianza de que entiendo la forma en que la clase que estoy escribiendo encaja en todo el sistema.

El punto que estoy tratando de hacer es que un programa trivial se puede escribir sin planes, pero un juego es cualquier cosa menos trivial. Hace algún tiempo, cuando OOP era nuevo, hubo mucha experimentación y algunas de las mejores prácticas salieron a la luz. La comunidad de desarrollo de software acordó que necesitábamos un lenguaje para escribir y analizar los diseños de software. El UML es el lenguaje que desarrollamos. Todos lo sabemos y lo entendemos, por lo que si desea utilizar las soluciones de otras personas para sus problemas (libros, debates en línea, artículos, catálogos de patrones, etc.) y no reinventar la rueda, debe aprender a leer la notación estándar. Como beneficio adicional, cuando te obligas a pensar en tu sistema en otro idioma, aprendes cosas inesperadas.

Existen muchas metodologías diferentes, pero todas identifican el problema y describen una solución de manera sistemática. Esto es ingenieria. El UML es enorme y complejo, pero ningún modelo utiliza cada construcción. Es como una navaja suiza. Debe conocerlo y descubrir cómo usarlo para respaldar su proceso de ingeniería. Lo importante no es qué proceso o metodología, sino que tiene uno. De lo contrario, se ahogará en complejidad.

También estoy trabajando en algunos proyectos de juegos independientes con un amigo (equipo de 2 personas). Como alguien en una situación similar a la suya, puedo ofrecer algunas cositas que me han resultado útiles.

1. Si sus ideas son aproximadas, intente implementarlas de una en una en proyectos de creación de prototipos muy pequeños. Por ejemplo, ahora estoy haciendo un juego de plataformas en 2D, y hacer que el salto del jugador sea correcto es extremadamente importante para mí. Entonces, hice un nuevo proyecto donde las únicas 2 cosas que suceden son a) Dibujar al jugador en la pantalla yb) Detectar la entrada y volver a dibujar el salto [el personaje ni siquiera puede moverse hacia la izquierda o la derecha]
2. Algunas personas pueden fruncir el ceño ante este consejo, pero primero piensen en escribir el manual del juego (para explicar los conceptos, controles, objetivos). Esto puede hacer 2 cosas por usted: generar un documento muy necesario, pero también esbozar los subsistemas de su juego y los detalles necesarios para el jugador. Si sabe de antemano lo que el jugador necesita saber, entonces sabe de antemano lo que debe hacer.
3. Escriba el código en trozos lo suficientemente pequeños (es decir, modulares ) para que las piezas factorizadas se puedan mover o organizar mejor sin sentir que está tratando de eliminar todas las piezas medianas de espagueti de un plato de pasta.

Esperemos que haya encontrado al menos una información útil allí, ¡y buena suerte!

Creo que hay algunas conclusiones valiosas de UML que no puedes negar. Por otro lado, tenga en cuenta que UML fue creado para procesos de negocios , ya sabes, modelando sistemas que tienen mucha gente interactuando con ellos, todos con diferentes deseos y necesidades. UML intenta asegurarse de que no omita nada ni se vea abrumado por los detalles.

UML es "una forma estándar de visualizar la arquitectura de un sistema"

UML describe

• ocupaciones
• actores
• Procesos de negocios
• esquemas de bases de datos
• componentes (lógicos)
• declaraciones de lenguaje de programación
• componentes de software reutilizables

Pero si estás haciendo un juego simple, ¿realmente necesitas modelar todo esto?

• Actores: El jugador.

¿Cuánto ayuda eso?

Sin embargo, modelar algunas de las otras cosas es muy útil. Por ejemplo, si está haciendo un pequeño MMO, definitivamente desea esquemas de base de datos bien diseñados.

Entonces, si bien las conclusiones de UML son excelentes (sepa lo que está haciendo, escriba los requisitos y dibuje diagramas de diagramas de flujo donde sea necesario), y los elementos son muy útiles, tiendo a sentir que el proceso UML completo es un poco de un agujero redondo redondo para juegos.

UML no es una cosa, es una colección de cosas que algunas de ellas tienen valor, otras no tanto. los casos de uso de estilo anterior (al menos lo que llamamos casos de uso) que establecen

• nombre
• requisitos
• condiciones previas
• disparadores
• comportamiento
• acciones alternativas
• excepciones

Puede ser bastante útil. aunque lo que encuentre para "Casos de uso" si realiza una búsqueda en la web (las imágenes) son más para software general.

También le daría algo de crédito al diagrama de la Clase. esto muestra que puede mostrar la relación entre todos sus objetos y que conoce el diseño de su arquitectura.

De lo que se trata es de que su conjunto de características debe estar planificado y bloqueado int (alquilado en una configuración de necesidad / deseo) antes del modelado, e incluso se inicia el diagrama. estos deben estar todos en su Breve / Tratamiento / Guión (a veces denominado tono, documento de características e historia). luego, a partir de ahí, harías tus documentos técnicos que tienen tus modelos y diagramas.

hay compañías que usan UML, pero generalmente son compañías que tienen equipos de diseño e implementación separados. las compañías que crearán toda su documentación y luego la entregarán a un equipo de monos de código para crear un prototipo / alfa. se dice que si puedes modelar tu juego con precisión, deberías poder dárselo a un equipo completamente diferente y hacer que lo programen, aunque esto es más un sueño imposible que una precisión.

Le enseñarán sobre UML en su universidad para ayudarlo a comunicar sus ideas al resto de su equipo y mostrar a los profesores que tiene un buen conocimiento práctico de los principios básicos de ingeniería de software.

Como cualquier discusión sobre lenguaje, herramientas o diseño, generalmente se reduce a cómo USTED lo usa. Elija la mejor herramienta / lenguaje / diseño para el trabajo y respalde su elección con una sólida justificación. Admito que UML no es tan flexible para la producción de juegos, aunque puedo decir que lo hemos usado eficazmente para modelar características del motor, como las comunicaciones y el tiempo de la red, la gestión de tareas paralelas y los casos de uso. No hay nada peor que explicar lo mismo a 5 miembros diferentes del equipo 10 veces diferentes porque no lo entienden del todo. Aquí está la documentación, léala.

Dependiendo de cuán sólidos sean sus diseños y cuán disciplinado sea su equipo, puede ser bastante productivo poder modelar sus propias construcciones en torno a aquellas que aún no se han iniciado, y aún así saber exactamente cómo funcionarán debido a documentación.

A pesar de esto, probablemente escuchará (y se dará cuenta con dureza) que se trata de DOCUMENTOS VIVOS y, a menos que se revisen y actualicen regularmente, se volverán obsoletos de manera rápida e inútil.