Marco o biblioteca de Game Engine [cerrado]

Estoy en las etapas de planificación para un motor de juego interno que estoy a punto de comenzar a crear, que se utilizará para todos mis juegos en el futuro. Pero estoy luchando un poco con cómo debería construirse.

Las opciones se reducen a: marco o biblioteca.

Mi objetivo básico es ocultar los detalles del motor tanto como sea posible para mantener el desarrollo de juegos de alto nivel en scripts y archivos de configuración tanto como sea posible. Pero también para reutilizar el motor central para cualquier herramienta que podamos desarrollar en el futuro.

Los marcos pueden hacer que las cosas sean agradables y fáciles de desarrollar, pero luego estás encerrado. Las bibliotecas son buenas si solo estás interesado en un subsistema específico. Pero necesitamos unir todo en un juego por juego.

Bueno, también hay otro, construir el motor como un exe independiente que maneja todos los recursos del juego y todos los subsistemas. La lógica del juego (y otras cosas dinámicas por juego) se realiza exclusivamente en scripts con archivos de configuración para configurar cada subsistema interno del motor.

Cuál me dará más flexibilidad en el futuro.

Gracias.

Editar: Gracias a todos, supongo que estaba viendo esto desde una perspectiva incorrecta. Realmente no podemos planificar algo como esto sin un conocimiento a priori de lo que necesitan los juegos, supongo que es por eso que no existe un motor general para todos los géneros.

Me enfocaré primero en el juego propiamente dicho y luego analizaré iterativamente al final de cada juego cómo hacer abstracciones decentes para bibliotecas o marcos dependiendo de mi flujo de trabajo (o posiblemente el de un futuro equipo).

No te preocupes por el futuro todavía. Preocúpate por tu juego actual, ahora. De lo contrario, no va a llegar a ninguna parte porque está preocupado por los detalles.

Debes concentrarte en construir el juego primero y luego, si el juego fue lo suficientemente exitoso, puedes extraerlo en algo reutilizable para tu próximo juego. Esto evitará que te encierres en otra cosa y te dará control total sobre tu proyecto.

Construye un marco.

Tengo experiencia en la construcción de ambos. Prefiero usar bibliotecas sobre frameworks. Los marcos se sienten muy restrictivos y "mandones" . Entonces, cuando construí mi primer juego, quería construir un motor que estuviera compuesto por muchas bibliotecas que pudieran reutilizarse fácilmente en otros proyectos.

Fue un desastre. Pasé la mitad de mi tiempo escribiendo código de pegamento entre mis diversas bibliotecas. Mis bibliotecas también tienden a estar llenas de abstracciones adicionales, por lo que se convirtió en una tarea enorme agregar funciones a las bibliotecas / componentes.

Ahora, sin embargo, mis motores están construidos con el juego que estoy escribiendo en mente. Todavía mantengo mis ojos abiertos para las abstracciones que me permitirán reutilizarlo o las nuevas características que agregaré en juegos posteriores. Estoy mucho más feliz y productivo.

Para mí, el punto de inflexión fue decidir no publicar mi motor. Todavía puedo publicarlo, pero por ahora, saber que no necesito justificar los hacks específicos de mi juego para otros usuarios me ha permitido construir un motor más adecuado para mis juegos.

Veo esto con demasiada frecuencia.
¿Por qué construir un motor, para usar en futuros juegos, cuando no sabes qué juegos necesitan?
¿Por qué no construir el juego primero, y luego otro, y otro, reutilizando tan a menudo como sea posible?
Luego tiene una biblioteca de código, probablemente desorganizada, pero que se muestra útil.
Entonces puedes organizarlo.

Y para 'framework vs library', lo basaría en lo cansado que está de escribir un ciclo de juego una y otra vez y otras cosas. ;)

Un marco no necesariamente necesita encerrarte. Mira XNA.

Mantenlo simple.

Si no está seguro de qué camino tomar, simplemente haga lo que su juego requiera. Intenta escribir pequeñas bibliotecas básicas para cosas que creas que podrían usarse en el futuro. Examina el desarrollo de software basado en datos. Sugiero buscar en sistemas de entidades basadas en componentes. No base el código alrededor de cosas que son únicas, como un jugador. Un jugador es solo otro objeto, como cualquier otra cosa. Una entidad tiene componentes, quizás una lista de componentes.

Al escribir pequeñas bibliotecas contenidas que interactúan entre sí, puede seguir adelante y determinar cuáles reutilizar para su próximo juego. Personalmente, tengo cosas como una biblioteca "contenedor" para tipos de almacenamiento de datos. Tengo una biblioteca matemática para tales cosas. Hay varias cosas como estas que puede ordenar y escribir como módulos. Cámara, efectos, entrada, entidad, movimiento, física, renderizado, manejo de recursos, enhebrado, la lista continúa.

Escribir pequeños componentes independientes a menudo aumenta la legibilidad y las posibilidades de depuración de su código.

Mike Acton y los juegos insomnes (www.insomniacgames.com) han escrito muchos temas y debates sobre el desarrollo de juegos, en particular basados ​​en datos. Búsquelos y vea qué tipo de información es demasiado compleja y cuál encuentra interesante y comprensible. Son grandes desarrolladores con mucha experiencia.

Creo que estás haciendo una generalización prematura. No se quede atascado demasiado en las preguntas de uso futuro en este momento. Elige una respuesta y corre con ella, aprende de ella. Lanza una moneda si no tienes preferencia.

Comienza construyendo un juego. Cuando construyas tu segundo juego, tendrás una mejor idea de qué partes son reutilizables y pueden convertirse en funciones de biblioteca robustas. Cuando construyas tu tercer juego, tendrás una mejor idea de qué estructura es reutilizable y puede convertirse en un marco robusto.

En términos de flexibilidad, creo que respondió a su propia pregunta: "Los marcos pueden hacer que las cosas sean agradables y fáciles de desarrollar, pero luego está encerrado ". Esto no significa que los marcos tengan que ser inflexibles; cada juego, por ejemplo, tiene un ciclo de juego. Marco de XNA de Microsoft es la biblioteca 99%, pero su juego se extiende la clase de juego que acaba proporciona algunas funciones en blanco por las cosas que están garantizados para estar en cada partido: LoadContent, Update, Draw. Es un excelente ejemplo de un marco no restrictivo.

Se podría decir que un marco no es más que una biblioteca combinada con una (s) clase (s) de plantilla que están conectadas a la biblioteca, al menos esta ha sido mi experiencia.

Tiendo a preferir bibliotecas sobre frameworks. jMonkeyEngine , por ejemplo, es genial, pero es un marco y, como resultado, he notado que recibe toneladas de flak. SDL , por otro lado, es increíblemente popular; Es solo una biblioteca. Proporciona lo que necesita, pero se sale de su camino para hacer lo que quiera con él.

Con una biblioteca, no necesariamente hay que pegar mucho juego por juego, especialmente si escribe partes de su biblioteca para apoyar cada parte del ciclo del juego; un contador / contador de cuadros por segundo, por ejemplo, evitaría que esa parte comúnmente reescrita necesite reinventarse con cada juego.

Además, las bibliotecas pueden ser tan generales o específicas como desee hacerlas. Si está haciendo un juego de carreras y quiere que su biblioteca tenga características específicas de carreras, está bien. Es tu creación y puedes elegir exactamente qué tan flexible la quieres. Esto sería muy factible en una situación en la que tienes un contrato a largo plazo con Nascar para desarrollar numerosos juegos de carreras, por ejemplo. No necesariamente querría un marco que lo vincule potencialmente a un clásico juego de carreras en círculo cuando Nascar aparezca y solicite un juego offroad, pero querría una biblioteca específica para juegos de carreras ya que sabe que Nascar no es No voy a pedir un tirador.

Aquí también hay un consejo para el desarrollo: si escribes la biblioteca junto a un juego, inevitablemente terminarás acoplando accidentalmente la biblioteca al juego, o haciéndola demasiado inflexible, sin importar cuánta planificación hagas. Lo resolverá tan pronto como intente hacer un juego diferente con él, y pasará tiempo separándolo; esto no es necesariamente algo malo y es posible que decidas conscientemente hacerlo, ya que tendrás más tiempo libre después del lanzamiento de tu primer juego. Pero si está buscando una biblioteca estelar desde el principio, intente hacer dos juegos totalmente diferentes al mismo tiempo, y extraiga las piezas similares en su biblioteca. Obtendrá MUCHO menos acoplamiento, será mucho más flexible y su tercer juego probablemente expondrá algunas debilidades, pero su biblioteca será mucho mejor al final. Sin embargo, obviamente es mucho más difícil y requiere más tiempo.