¿Qué debo considerar al evaluar bibliotecas, motores y marcos para hacer un juego?

Voy a hacer un juego. Me di cuenta de que hay muchos motores de juegos, bibliotecas y marcos disponibles, y estoy teniendo algunos problemas para decidir cuál usar.

Ya soy bastante bueno con algunos lenguajes de programación, pero hay otros que no conozco en absoluto. No estoy en contra de aprender nuevos lenguajes de programación, si eso ayuda, pero mi verdadero objetivo es hacer mi juego.

¿Qué criterios debo usar para comparar motores, bibliotecas y marcos entre sí, para poder decidir cuál me permitirá ser el más productivo para terminar mi juego?

Es algo así como elegir un automóvil o una computadora. O prácticamente cualquier cosa que tenga una variedad de características, algunas de las cuales te interesan mucho, otras que no te importan y algunas que quizás incluso no quieras incluir.

1. Haga una lista de las características que le interesan. Es decir, soporte 2D / 3D, iluminación, física, utiliza un lenguaje que conoce bien, etc.
2. Clasifíquelos según su importancia, según su proyecto actual.
3. Investigue sus opciones y, para cada opción, intente clasificar sus características de soporte en función de qué tan bien se alinean con los objetivos de su proyecto.
4. Utiliza el que mejor se adapte a tus objetivos. Alternativamente, puede seleccionar los primeros y darles una prueba de manejo. Implemente alguna característica simple de su juego y vea cuál le gusta más.

Creo que mucho de esto se reduce a saber realmente lo que quieres. Lo que significa que necesitarás tener una idea bastante buena del juego que estás haciendo. Lo que probablemente significa que necesitarás un plan bastante detallado sobre cómo implementar tu juego y qué va a incluir. Como beneficio adicional, tener toda esa información detallada realmente te ayudará a completar tu juego. Es mucho más fácil seguir un plan y marcar cosas de una lista que simplemente tener una idea para un juego y simplemente comenzar a escribir código.

Primero debes tener al menos una idea aproximada de cuál será tu juego y qué necesitará. Hay preguntas habituales como si tu juego necesitará física o no. Luego están las preguntas interrelacionadas, que se refieren principalmente al entorno en el que se desarrollará y ejecutará su juego, y qué tan comercial es o no su juego.

• ¿Qué plataformas admitirán? ¿En qué plataforma estás desarrollando tu juego?
• ¿En qué lenguaje (s) de programación piensa implementar su juego?
  • Esto está influenciado por las plataformas que pretende admitir.
• ¿Qué tipo de gráficos, audio y entrada tendrá tu juego?
• ¿Su juego es gratuito o de código abierto, o es comercial?
  • Si es de código abierto, ¿querrá comercializar más tarde, ya sea con su juego o con otro juego que use el motor de su primer juego?

Si va a estar solo en Windows, entonces las bibliotecas basadas en DirectX y C # son buenas candidatas. Si quieres ser multiplataforma, entonces querrás mirar las bibliotecas basadas en OpenGL y C / C ++, o Flash si tu juego es 2D y puedes permitirte las herramientas de Adobe. Al igual que su plataforma, su lenguaje de programación influirá en sus bibliotecas disponibles. Un programa escrito en C ++ tendrá dificultades para llamar a una biblioteca Java.

Si tu juego es comercial, entonces puedes considerar comprar un motor como Unity. Si su juego es gratuito o de código abierto, querrá centrarse en las bibliotecas que también son de código abierto, o al menos gratuitas para proyectos no comerciales. Las bibliotecas de código abierto también son útiles para proyectos comerciales, por supuesto. Al mirar las bibliotecas de código abierto, asegúrese de verificar su licencia. Algunas licencias requieren que haga partes de su propio software de código abierto dependiendo de cómo use una biblioteca. Restringirse a las bibliotecas de código abierto obviamente colocará otro límite en las bibliotecas que puede usar.

Al mirar una biblioteca, asegúrese de verificar cuán activo es su desarrollo y comunidad. Confiaría en una biblioteca que es conocida y mantiene activamente más de una que está alojada en la página web de la universidad de alguien que no se ha actualizado desde 1999.

Una última pregunta, especialmente si este no es su primer proyecto de juego, es si hay o no aspectos de su juego tendrá que sabe que usted lucha con si intenta hacerlo por sí solo. Porque estos aspectos en particular son candidatos para encontrar una biblioteca. Si su juego necesita detección de colisión y sabe que no puede implementar la detección de colisión usted mismo (como yo no puedo), considere elegir un motor de física y aprovechar las funciones de detección de colisión en él.

• ¿La biblioteca hace lo que necesitas?
• ¿Está especializado para hacer lo que necesita? ¿Cuánto desorden se le atribuye?
• ¿Cómo está diseñado? ¿Quieres vomitar cuando lo ves? Si es así, entonces probablemente no sea la mejor opción tanto para su salud como para su cordura.
• ¿Es lo suficientemente flexible para sus necesidades? No es bueno notar que la biblioteca no funciona después de que ya haya escrito la mitad de su código.
• ¿Qué tan futura es la biblioteca? ¿El desarrollador agrega funciones con el tiempo? ¿Está arreglando las cosas? ¿Está mejorando las cosas? Esto puede marcar una gran diferencia si es probable que el desarrollo de tu juego tarde unos años. No es tan importante para pequeños proyectos que tendrá en un mes.
• ¿Es el tamaño apropiado? Para proyectos pequeños, puede hacer una gran diferencia si el reproductor tiene que descargar 20 MB o 200 MB. Los proyectos más grandes son probablemente lo suficientemente grandes como para que el tamaño del middleware haga poca diferencia.

Además de las características específicas del juego que la gente ha comentado, también debes considerar algunas preguntas generales.

1. estructura de soporte: incluso si el motor del juego es perfecto, tal vez el soporte sea demasiado costoso o inexistente.
2. qué tan fácil es aprender: es posible que no desee algo demasiado grande, ya que el tiempo para aprender puede ser prohibitivo.
3. cubre sus planes futuros: es posible que no desee invertir tiempo aprendiendo un motor perfecto por ahora, solo para volver a aprender un nuevo motor desde cero para el próximo proyecto. O tal vez quieras eso.
4. licencia: si está creando un juego de código cerrado, asegúrese de que la licencia del motor no sea de código abierto.

Una breve hoja de trucos para evaluar bibliotecas, marcos, motores y SDK y elegir el mejor

• Las bibliotecas, los frameworks, los SDK de motores, etc., son herramientas destinadas a resolver problemas por usted o ayudarlo a resolver problemas y cumplir con ciertos requisitos.
• Evaluar significa descubrir cuál cumple con la mayoría de los requisitos.

Por lo tanto, incluso antes de comenzar a evaluar, debe ser claro en qué escenario se encuentra y qué requisitos tiene / desea tener porque estas son las preguntas que la evaluación debe responder.

El escenario define de dónde provienen los requisitos (quién decide qué es un requisito y qué no).

Los escenarios típicos son:

El escenario del proyecto más pasatiempo

Tú solo o con algunos amigos quieres crear tu (tal vez el primero) juego. Perfecto, puede decidir todo por su cuenta y solo está limitado a las desiciones técnicas básicas y los requisitos técnicos (si se trata de un juego móvil, un juego de PC, un juego de consola, un juego web, ...). Puedes decidir lo que quieras.

Los requisitos implícitos serán que tal vez desee aprender algo específico (un lenguaje, un marco / motor específico)

El escenario estudiantil

Los requisitos pueden provenir de su maestro. Requisitos típicos que tenía en ese caso: el juego debe tener algunos elementos físicos y soporte de red multijugador. O tiene que estar escrito en C ++. Entonces evaluar se vuelve fácil. Está buscando un motor de juego que le permita codificar en c ++ y ya puede incluir un motor de red y física.

Un requisito más malvado (de la vida real): todo tiene que escribirse desde cero (pero está permitido usar bibliotecas). Por lo tanto, no se permite ningún editor (por ejemplo, Unity3D). Por lo tanto, no está buscando motores / sdks sino bibliotecas.

El escenario del juego indie

Quieres ganar dinero con el juego más adelante. Por lo tanto, deberá venderlo de alguna manera, lo que lo llevará a verificar qué requisitos provienen de la tienda en la que desea vender su juego.

¿Permite juegos Java, juegos HTML5, ....)

¿Requiere que incluya bibliotecas específicas (en caso afirmativo, en qué idiomas están disponibles esas bibliotecas)

Google Playstore requerirá que escribas tu juego como juego de Android, Apple AppStore requerirá que escribas tu juego como aplicación de iOS. O tiene el requisito de elegir un motor multiplataforma.

El escenario profesional

No solo tiene una tienda que proporciona requisitos, sino que es muy probable que un editor o un cliente tenga sus propias imaginaciones de requisitos. En este escenario, también tendrá un equipo más grande de desarrolladores empleados. Dependiendo de su conjunto de habilidades, surgen nuevos requisitos (nuestros programadores solo pueden escribir c ++, por lo que no podemos usar un motor de juegos Java / Android puro sin que necesiten (mucho) tiempo para aprender algo nuevo).

No voy a entrar en detalles para este escenario, una vez que logró formar un equipo de empleados y encontrar un cliente / editor, ya sabe lo que está buscando para evaluar las cosas.

¿Cómo decido cuáles son mis requisitos cuando soy un hobbiest o indi y nadie más me lo dice?

¿Hacerte preguntas sobre tus objetivos y tu juego?

• ¿Cuál debería ser mi juego? móvil, pc, web (html / Js), qué controladores usaré (pantalla táctil, giroscopio, gamepad)

• Qué hay de nuevo en mi juego y qué otros juegos también tienen. Esas partes que otros juegos también tienen (renderización, audio, manejo de entrada) serán realizadas por la mayoría de las herramientas (motores de juego) que puedas encontrar o es fácil agrupar bibliotecas que tengan esa funcionalidad en tu propio juego o motor de juego.

• ¿Cuál es la dimensión de mi proyecto: pájaros enojados o skyrim? Angry Birds se puede hacer en casi todas las herramientas y skyrim se limitaría a herramientas de alto rendimiento con (supuesta) años de personalización adicional (los motores de terreno de alto rendimiento no son fáciles)

• ¿Mi único objetivo es terminar un juego? ¿si? perfecto, puedes usar algo muy avanzado como Unity, Unreal, ... tener un editor útil y una gran comunidad que te proporcione tutoriales y responda tus preguntas. Le quita la carga de manejar tareas de bajo nivel como la carga de malla, implementar sus propias funciones matemáticas, ...

• ¿Mi objetivo es aprender algo específico? ¿si? ¿Que quieres aprender?

• ¿Qué idioma debo elegir? Si el objetivo sigue siendo hacer tu juego, ¿elige el que tú / tu equipo conocen mejor? Si quieres aprender un idioma específico, elegirás una herramienta en ese idioma.

• ¿La herramienta X tendrá suficiente rendimiento para mi juego? Tal vez, nunca lo sabrás. Incluso en grandes producciones, la fase de optimización y pulido lleva mucho tiempo y es un gran esfuerzo hacerlo. Comience a preocuparse por el rendimiento cuando tenga problemas de rendimiento. No sabe cómo funcionará la herramienta a menos que alcance sus límites. Todo en el sitio web del desarrollador de herramientas es solo una suposición aproximada. Después de años de evaluar herramientas, dejé de creer cualquier cosa del sitio web de los desarrolladores.

Responder tales preguntas lo lleva a los requisitos. La evaluación es encontrar una lista de herramientas y PRUEBAS (no solo leer la página de inicio) de lo que la herramienta puede proporcionar o no.

Los requisitos no se cortan en piedra sino que son dinámicos. Van y vienen durante el desarrollo. Si el juego necesita física o no, por ejemplo, depende del diseño. Si el diseño cambia, el requisito también puede cambiar.

Tome los requisitos que tiene y comience. Los requisitos cambiantes son el pan de cada día del sufrimiento, ahm, desarrolladores felices, independientemente del tamaño del proyecto y el nivel de experiencia.

Vaya aquí .

A pesar de la cantidad de motores de juego que existen, en realidad no tienes tantas opciones.

1. restricciones de licencia. Algunos motores obstaculizarán su capacidad para lanzar su producto sin pagar primero grandes tarifas de licencia, por ejemplo, Unity , utilizada para cobrar una tarifa adicional para compilar a iOS, por ejemplo (esto cambió en 2016 )
2. plataformas ¿Te importa apuntar a múltiples plataformas? ¿Cuáles?
3. 2D o 3D? Algunos motores atienden a 2D.
4. Requiere física? Algunos motores proporcionan física
5. FPS, RTS? Puede ser conveniente utilizar un motor especializado para el tipo de juego que estás creando.
6. Obviamente te gustaría trabajar en tu idioma favorito. ¿No te gusta C? ¡Entonces no uses Allegro!
7. ¿Eres un gran patrón de diseño, fanático de OOP? Patrones bien conocidos de "sobreuso" de OGRE
8. Desarrollo activo? Debería considerar la compensación entre la disponibilidad de características de última generación (DX11 / OGL 4) frente a la estabilidad de un motor cuyo desarrollo disminuyó hace un par de años.
9. ¿Usuario base? Una gran base de usuarios generalmente significa mejores foros, por lo que es más fácil responder sus preguntas.