C++, el diseño de clases y las responsabilidades

Question

acabo de leer algunas preguntas relacionadas que surgieron cuando me escribió el tema, así que voy a tratar de no repetir esos.

Recientemente he comenzado a revisar un proyecto de aprendizaje que comencé hace unos dos o tres años: un puerto C++ de un motor Mega Man. Sí, utilicé sprites rotos. También estoy usando una biblioteca de motor de juegos para dibujo, música y entrada.

Mi código original fue atroz. Si bien podría (pero apenas) llamarse OO, se olvidó por completo. Empecé a agregar cosas como interfaces y eliminé muchos códigos repetitivos. Hay algunas cosas de las que no estoy seguro, porque el diseño del juego se vuelve muy complejo a veces.

El objeto que representa mi biblioteca de juegos es actualmente global (sé que los globales suelen ser malos) porque muchos objetos pueden confiar en él aquí y allá para cosas como cargar su arte o música. ¿Cuál es la mejor manera de sacar ese objeto fuera del alcance global, sin tener que pasar cincuenta parámetros a todo lo que de otra manera lo usaría directamente?

Siguiente pregunta: Como todos sabemos, Mega Man dispara muchos pequeños proyectiles blancos. Actualmente, el objeto del jugador es responsable de los objetos de proyectiles que en los incendios, la actualización de su posición y tal (literalmente, llamando al método proyectil :: Update() una vez para cada disparo, dentro del método jugador :: Update()). ¿Es esta la manera incorrecta de hacerlo? Mi primera mejora fue hacer que todos estos objetos implementaran una interfaz DrawnObject, para que mi juego pueda dibujar todo. Hacer lo mismo para las Actualizaciones significaría tomar el control de los proyectiles lejos del Jugador y dárselos a algún objeto del Juego más amplio. La razón por la que dudo sobre esto es que se siente como el antipatón del objeto de Dios. ¿O estoy malinterpretando dicho antipatrón? Todavía hay una complejidad adicional involucrados - los proyectiles mueren si salen de la pantalla visible, por lo que cualquier llamada a actualizar el proyectil requeriría la persona que llama para tener acceso al objeto de imagen.

Eso es todo por ahora, volveré con más problemas cuando los alcance. Fin de la primera publicación!

Answer 1

En cuanto a hacer una clase global, utilizaría un singleton, luego simplemente llame a Game :: GetInstance() que devolvería un puntero a la clase global.

En cuanto a las partículas, la forma en que siempre he manejado los juegos fue hacer una clase que maneja todos los objetos. En el bucle principal de mis juegos, llamaba a esa clase la función UpdateObjects, que pasaría por una lista de elementos que tenía almacenados y llamaría a cada una de sus funciones de Actualización. Lo mismo con Render y colisión.

Answer 2

He vanamente con el diseño del juego en el pasado, pero no puedo pretender ser un experto.

Para acceder a un objeto a nivel mundial, se recomienda usar un singleton

de objetos en movimiento, sugeriría hacer todo lo que una clase padre que entiende ubicación de la pantalla y tiene un método de actualización. Siempre que se crea un nuevo objeto, añadirlo a un vector que contiene todos los objetos, una vez por cuadro, que el paso por el vector y ejecutar la actualización en todos los objetos.

Answer 3

El objeto que representa mi biblioteca de juegos es actualmente mundial (sé globales son generalmente mal) porque muchos objetos pueden confiar en ella, aquí y allá para cosas como la carga de su arte o música.¿Cuál es la mejor manera de llevar a cabo ese objeto fuera del alcance global , sin tener que pasar cincuenta parámetros a todo lo que lo usaría directamente?

Estoy de acuerdo con la solución singleton antes mencionada.

siguiente pregunta: Como todos sabemos, Mega hombre dispara un montón de pequeños blancos proyectiles. Actualmente, el objeto del jugador es responsable de los objetos proyectiles que en los incendios, la actualización de su posición y tal (literalmente, llamando al proyectil :: Update() método de una vez para cada disparo, dentro del jugador :: Update() método).

Hay un principio de diseño ágil para la construcción del código llamado: "El principio de responsabilidad única". Según él "NUNCA DEBE HABER MÁS DE UNA RAZÓN PARA UNA CLASE A CAMBIO ". Así que supongo que comenzaría por separar las responsabilidades de la clase Player de las clases separadas: p. uno para posicionamiento y uno para disparar.

ver un ejemplo y más sobre el tema SRP