Estoy a punto de desarrollar un juego 2D basado en sprites para Windows 7 Phone, usando XNA. La capacitación y los tutoriales disponibles son bastante útiles, pero el problema que enfrento es que cada uno de ellos aborda su diseño de clase de manera diferente, y el código no está particularmente bien factorizado. Como resultado, me ha resultado difícil comprender bien qué responsabilidades debo asignar a una clase en particular.
Por ejemplo, podría tener una clase de sprite base BaseSpriteque sepa cómo dibujarse, verificar colisiones, etc. Entonces podría tener una AnimatedSpriteclase que supiera cómo navegar por su hoja de sprites, una ExplodingSpriteclase, etc. Esta técnica se demuestra en el ejemplo de Space Invaders en los materiales de Windows 7 Phone Jumpstart Session 2 .
Alternativamente, podría colocar la mayor parte de la representación y ejecución de la responsabilidad del juego en una GameScreenclase; esa clase y sus clases derivadas se comportan más como formularios o páginas web en términos de sus responsabilidades. Las clases de Sprite son contenedores más simples con mucha menos lógica.
Esta es la técnica utilizada en el juego Alien Sprite de Windows 7 Phone Training Kit y en otros ejemplos de administrador de estado del juego.
¿Cuál es el enfoque correcto orientado a objetos para el diseño de clases en el desarrollo de juegos?
En los juegos, el patrón Componente es una solución común.
fuente
Los Principios SÓLIDOS se aplican tanto al diseño del código del juego como a cualquier otra profesión, al menos hasta que llegue a optimizar, por lo que usaría su primer ejemplo como punto de partida.
Sin embargo, iría más lejos, porque BaseSprite parece que tiene la tendencia a convertirse en una megaclase. El Principio de Responsabilidad Única dicta que la colisión, el renderizado y la navegación deben ser manejados por componentes, en lugar de entradas individuales en una jerarquía de clases. La clase holding de todos estos componentes solo debe manejar empujar posiciones mundiales entre ellos.
fuente
En los últimos proyectos, me he inclinado más hacia un enfoque de estilo MVC.
Al principio no estábamos seguros de si esto funcionaría, pero funcionó perfectamente.
Modelo
Los objetos de datos. Solo los datos puros. Sin comportamiento, sin renderizado.
Administrador de datos. Solo manejo de "listas" de objetos de datos. (También se puede mejorar para admitir la agrupación).
Ver
Los llamamos renderizadores. Para cada tipo de objeto de datos hay un renderizador. Cuando se llama con un administrador, representará todos los objetos de esa lista.
Controlador
Igual que los renderizadores, pero controla el comportamiento.
Ejemplo
El ShipManager tiene una lista de barcos. El ShipController moverá las Naves de acuerdo a su estado. El ShipRenderer representará las Naves de acuerdo a su estado.
Por qué
De esta manera, la vista y la lógica están estrictamente separadas. Hace que portar a una nueva plataforma sea bastante fácil. La optimización del diseño de datos dentro del XxxManager también es muy fácil.
fuente