Te estás acercando al revés.
¿Cuál debería ser en su motor es la siguiente:
todo el código que resultó ser común entre su primer y su segundo juego.
Primero, escribe un juego. No escriba un motor, porque, como ha descubierto, no sabe qué debe contener ni cómo debe diseñarse. Escribe un juego en su lugar.
Una vez que tenga ese juego, escriba otro juego. Luego, cuando hayas hecho eso, examina el código del segundo juego. ¿Cuánto fue reutilizado desde el primer juego?
Todo lo que se volvió a utilizar se debe refactorizar en un proyecto separado. Ese proyecto ahora es tu motor de juego.
Esto no significa que no deba planificar, o no intente escribir un buen código. Pero asegúrese de estar trabajando para algo concreto, algo en lo que pueda distinguir una buena implementación de una mala. Una buena implementación de un juego, es una que funciona, es divertida y no falla. Escribe tu código para lograr esas cosas primero.
¿Una buena implementación de un motor? Eso es más complicado. ¿Cuál es una buena implementación de un renderizador? De un marco de AI? De un sistema de partículas? En última instancia, la única forma de determinar si tiene un buen motor es viendo qué tan bien funciona en un juego real. Entonces, si no tienes un juego, no tienes forma de evaluar tu motor. Y si no tiene forma de evaluar su motor, no tiene forma de juzgar si alguna parte del código que está escribiendo es realmente útil.
Nada en contra de esto, sino que probablemente sería mejor publicando esto en los foros de gamedev.net. – ryeguy
Buena (y flexible) detección de colisión. –
detección de colisión se encuentra en el motor Farseer Phsyics –