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:
- Abandona la idea. Esto significa que su juego está funcionalmente limitado por su motor.
- 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.
- 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.