¿Qué ventajas ofrece OpenGL desnudo sobre frameworks / motores para desarrolladores pequeños? [cerrado]

16

He notado una tendencia de desarrolladores independientes que se alejan de los frameworks y motores, y se mueven hacia el uso de OpenGL desnudo, o el uso combinado con SDL / SFML2. Como desarrollador independiente, no puedo ver lo que OpenGL de bajo nivel puede ofrecer en motores o marcos separados.

La mayoría de los motores y marcos decentes le brindan la funcionalidad que necesita y nunca se interponen en su camino. También pueden abrir la opción de tratar con OpenGL directamente. ¡Algunos incluso ofrecen la funcionalidad para compilar multiplataforma!

Entiendo la aspiración de aprender lo que está sucediendo debajo del capó, pero no veo ninguna ventaja que OpenGL pueda ofrecer a los desarrolladores independientes sobre motores o marcos.

¿Podría explicar el razonamiento detrás de la creación de juegos desde cero usando OpenGL?

Franco
fuente
Como estudiante de posgrado en programación de juegos y gráficos, puedo dar fe de las complejidades de aprender OpenGL desde cero. Si estuviera haciendo un juego indy hoy, absolutamente usaría SDL o alguna otra biblioteca. Pero también entiendo mucho más sobre gráficos hoy que cuando comencé mis estudios, aprender una API me ayudó bastante a comprender cómo funcionan las GPU en general y cómo interactúan el hardware y el software. Pero para hacer un producto comercial, absolutamente usaría una biblioteca de terceros en este punto.
Philip

Respuestas:

23

Esta es en gran medida una pregunta / respuesta basada en la opinión, por lo que en realidad no es necesariamente ideal para esta plataforma, pero de todos modos:

¿Por qué no hay framework / motor como indie? Aquí están mis dos centavos:

  • Falta de presupuesto: este es probablemente el punto más importante para la mayoría de los desarrolladores pequeños / independientes. Muchos frameworks o motores no le permitirán publicar su producto sin comprar una versión más cara (suponiendo que haya una versión barata o gratuita disponible) y / o pagar regalías, algo que siempre tendrá que considerar para proyectos pequeños. A veces incluso tienes que pagar una vez por plataforma también.
  • Complejidad: la mayoría de los motores o marcos se dividen en una de dos categorías:
    • Están muy limitados para un género especial ( RPG Maker es un ejemplo típico).
    • O simplemente son demasiado genéricos con muchas cosas que probablemente no usará de todos modos (como Unity ).
  • Código de propiedad: la mayoría de los motores no son de código abierto y para obtener la fuente real, tendrá que pagar aún más (si está disponible). Sin el código fuente real, la transferencia a otras plataformas puede ser difícil o incluso imposible (nuevamente, RPG Maker sería un ejemplo perfecto).
  • Clunkyness: esta es mi opinión personal, pero al menos para mí esto es a menudo una gran decepción teniendo en cuenta los motores y marcos prefabricados, especialmente cuando estás construyendo solo un pequeño juego. ¿Quién quiere jugar un pequeño juego de descanso que tiene un tamaño de 200 KB pero trae un tiempo de ejecución de 50 MB?
  • Elección del idioma: algunos motores y marcos no proporcionan bibliotecas para usar en su propio código. En su lugar, proporcionan un marco o tiempo de ejecución que utilizará su propio lenguaje de secuencias de comandos o algún lenguaje establecido (como Javascript o C #). Si está escribiendo su propio motor personalizado, puede usar el idioma que elija.
  • Protección de su trabajo: si está utilizando un motor o marco prefabricado, es muy probable que a otros les resulte mucho más fácil cambiar o descompilar su código o activos, algo que quizás desee evitar (incluso si es solo para mantener su puntaje más alto) limpiar). El código personalizado y el manejo de activos agregan un obstáculo mucho más grande que tomar, especialmente cuando se compila en código nativo.
  • Marca: Esto puede ser menor para muchos, pero algunos motores y marcos lo obligan a mostrar su logotipo o incluso anuncios, esencialmente tomando sus libertades para elegir quién / qué promocionar. Por supuesto, esto a menudo depende de la licencia real, las tarifas de licencia, etc.
  • Incompatibilidad con las licencias: esto es algo que muchos ni siquiera consideran al elegir un motor, pero dependiendo de lo que quiera hacer, esto podría ser un factor importante. Incluso si compra algún motor, es posible que no pueda revelar ninguna fuente o material relacionado. Algo así podría hacer imposible la modificación, incluso si desea que los usuarios puedan hacerlo. Tome como ejemplo el motor Source de Valve ( Half-Life 2 , Team Fortress 2 , etc.): permiten que los modders usen su motor para sus propios proyectos. Si estos juegos se basaran en (por ejemplo) Unreal Engine, esto no sería posible debido a las limitaciones implícitas en los términos de la licencia.
Mario
fuente
11
más una cosa más: una vez que aprendes openGL, lo sabes. No tiene que volver a aprenderlo en cada idioma o aprender cómo un marco / motor específico quiere que lo implemente para cada nuevo marco / motor. Esto también conduce a una mayor portabilidad
Wes
Aunque no es el problema más común, es posible que en el motor o el marco la idea simplemente no sea posible o sea demasiado complicada (por ejemplo, Minecraft)
akaltar
@akaltar: Cierto, pero al mismo tiempo esperaría que alguien elija un motor que se ajuste al objetivo previsto. Por ejemplo, no use un motor 3D para un juego 2D y viceversa.
Mario
9

La mayoría de los motores y marcos decentes le brindan la funcionalidad que necesita y nunca se interponen en su camino.

¿Ellos? Eso más bien depende exactamente de lo que estás haciendo, gráficamente hablando.

Para muchos tipos de juegos, hay respuestas estándar para preguntas gráficas. El juego 2D promedio, por ejemplo, puede manejarse bien con la destreza 2D de, por ejemplo, XNA / MonoGame. Son solo sprites, que pueden venir en lotes por terreno, pueden rotarse, etc.

Pero, si su juego solía ser un juego 2D promedio, entonces lee sobre alguna técnica genial, como usar un mapa de altura para construir un impostor que tenga la apariencia de profundidad en relación con la pantalla. Y tú quieres hacer eso.

Ahora está empleando el mapeo normal e incluso posiblemente el mapeo de paralaje. Todo en el mismo contexto de "renderizado de sprites", pero requiere más de lo que pueden manejar muchos motores 2D puros. Específicamente, requiere un "sprite bliting" multitexturado, que no es algo que muchos motores 2D puedan hacer.

¿Qué haces si tu motor no puede adaptarse contigo? Eso significa que tienes que hacer múltiples pases, uno para el color y otro para la iluminación a través del mapa normal. Pero eso no funciona, porque necesita el campo de altura del mapa normal para emplear el mapeo de paralaje en la búsqueda de color. ¿Y ahora que? Necesita el alfa para hacer transparencia, por lo que no puede robar el alfa. Y el motor simplemente no admite múltiples texturas.

Por lo tanto, debe elegir uno de los siguientes:

  1. Abandona la idea. Esto significa que su juego está funcionalmente limitado por su motor.
  2. Hackear el motor para tener múltiples texturas. Suponiendo que tiene acceso al código fuente, ahora lo está asumiendo usted mismo para tocar el código de otra persona. Esto también significa que necesitas mantenerlo y no romperlo con su tropiezo.
  3. Haz lo mejor que puedas, dentro de las limitaciones del motor. Para que pueda obtener paralaje en los mapas normales, pero no en los colores. Puede que no sea exactamente lo que querías, pero es mejor que nada.

Solo como ejemplo, tome Geometry Wars. La mayoría de los motores 2D succionarían este tipo de imágenes, ya que la mayoría de ellos se basan en dibujar sprites, no en líneas. Es un juego que necesita un tipo de renderizador muy especializado.

Al final del día, debes asumir la responsabilidad de los elementos de tu juego que son importantes para las necesidades de tu juego. Si el aspecto visual de su juego se desarrolla principalmente por el estilo artístico de las imágenes y modelos que usa, en lugar de los efectos específicos, entonces usar una solución preempaquetada está bien. Pero si el estilo visual de su juego se define significativamente por el código de representación personalizado, es muy probable que un motor estándar pueda convertirse en una limitación seria si decide hacer cosas que están fuera de la caja.

Además, hay un problema muy práctico: no todos los motores de juego son igualmente portátiles.

Con el reciente aumento de las plataformas móviles, el mercado de juegos se extiende a través de numerosos sistemas operativos y dispositivos de interfaz de usuario. No todos los motores funcionan en todos los dispositivos. Y si su motor no funciona en una plataforma, ciertamente no se tomará el tiempo para hacerlo funcionar en una. Después de todo, por eso usaste un motor en primer lugar, ¿verdad?

Si es importante para usted que su juego funcione en una plataforma en particular, entonces nuevamente debe asumir la responsabilidad. Y la forma "más fácil" de garantizar el éxito con esto es hacerlo usted mismo. Para construir un motor que pueda funcionar en múltiples plataformas, quizás empleando marcos más simples específicos de la plataforma donde sea necesario para manejar algunos detalles de bajo nivel. De esa manera, si se rompe, es su código; eres la mejor persona para poder solucionarlo.

Nicol Bolas
fuente
Me gusta tu respuesta, pero me parece muy extraño que hayas elegido XNA como ejemplo. No sufre ninguno de los inconvenientes que menciona, excepto posiblemente la portabilidad.
Seth Battin