Consejos de un aficionado
// De cero a aficionado durante años de aprendizaje
Definitivamente me mantendría alejado de motores de alto nivel como Unity o Torque2D MIT. Son excelentes para prototipos pequeños, pero nunca los tomaría en serio para desarrollar mi propio videojuego. ¿Por qué habría? ¿Cuál es el punto a menos que no sea más que un simple SideScroller o una nueva versión de Arcade?
La mayoría de los motores de juegos, bibliotecas o marcos no hacen nada más que las tareas más simples con una gran cantidad de código hinchado con funciones y características que nunca usará.
Cuando era nuevo en el desarrollo de juegos hace años, comencé en la cima. Motores de muy alto nivel. No hay nada demasiado alto como RPG MAKER, pero definitivamente alto como Unity y Torque. Luego bajé, a XNA y C #, porque tenía muchos recursos y tutoriales. Mi proyecto principal necesitaba el rendimiento, o tal vez solo soy obsesivo-compulsivo por querer un rendimiento increíble en mi software, incluso si no es un proyecto grande. XNA simplemente no lo cortó, y tuve muchos problemas con el motor que leí que requirieron un dolor de cabeza para solucionarlo. ¿Cuál es el punto de usar algo de "nivel superior" como XNA / C # cuando estás haciendo el mismo trabajo (reparando errores y problemas de XNA) como lo harías con tu propio motor en C ++?
Después de un tiempo de aprendizaje, finalmente aprendí sobre cómo se diseñan los motores de juego y comencé a investigar el código de los motores. Al leer lo que la mayoría de los profesionales tienen que decir y las quejas de los críticos de los motores de juegos, me di cuenta: "¿Por qué usar un motor?"
Repasar mi C ++ y realmente entrar en algunas filosofías usadas en ese lenguaje me ayudó mucho. Sin embargo, había pasado tanto tiempo aprendiendo tanto que solo quería comenzar a hacer un juego.
Así que terminé con algo con muchos elogios, era C ++ y un nivel muy bajo: SDL. Desafortunadamente, esto fue un dolor de cabeza. Es un nivel tan bajo que no veo razón alguna para usar esta biblioteca. Prefiero simplemente aprender OpenGL y hacerlo yo mismo desde cero. Honestamente, fue principalmente el hecho de que necesitaba implementar mi propio código para hacer algo tan básico como voltear una imagen (y la implementación de otros no funcionaba debido a cómo manejaba los sprites) lo que me llevó a tirar basura a SDL permanentemente. Es genial si quieres un procesador de software, pero en mi opinión, prefiero tirarlo a la basura con hardware (OpenGL) o superior (SFML).
No queriendo comprar otro libro en Amazon y aprender otra API, fui más alto. SFML es simplemente maravilloso, sin mencionar elogiado en todo Internet. He leído casi un sinfín de críticas positivas, casi sin negativas. No puedo decir lo mismo para SDL. Maneja todos los conceptos básicos extremos, pero deja el resto a mí y a otras bibliotecas de mi elección. Me he quedado con eso desde entonces.
En mi opinión, un motor de juego es una tontería. Las bibliotecas de bajo nivel son opciones mucho mejores para programadores expertos y principiantes.
También para tener en cuenta, aprendí más sobre conceptos de programación y agudicé mis habilidades de desarrollo de software cuando me vi obligado a manejar las cosas a un nivel inferior al que aprendí con los motores de juegos WYSIWYG de alto nivel.
¿Qué te ofrece algo como Unity sobre XNA? Edición visual y una muleta. Los novatos eventualmente aprenderán que todavía tendrás que codificar casi todo el juego tal como lo harías si tuvieras C ++ desnudo, y los editores visuales son ineficientes para algo que podrías crear tú mismo.
¿Qué le ofrece algo como XNA sobre SFML o su propia implementación de OpenGL y otras bibliotecas útiles? OMI, absolutamente nada bueno. Peor rendimiento, C # en lugar de C ++, una gran cantidad de tutoriales para novatos pero significativamente menos profesionalismo, y algunos protectores de dolores de cabeza que IMO son una vez más una muleta para lo que debería aprender con C ++. Inicialmente, me sentí intimidado con C ++ y amaba C #, principalmente debido a los comentarios y rumores de las opiniones de tontos que tenían los mismos problemas que tuve inicialmente con C ++: solo quería un programador lo suficientemente bueno. Me di cuenta de que necesitaba aprender más fundamentos y agudizar mis debilidades para superar los problemas que tenía con C ++, que C # "facilitó". ¿Echo de menos la simplicidad de algunas cosas en C #? ¡Ni siquiera! Sé cómo hacerlo en C ++ sin problemas.
Si las bibliotecas de bajo nivel o el aprendizaje de DirectX / OpenGL lo intimidan, solo espere hasta que comience a meterse en la complejidad de crear un videojuego completo.
Mi filosofía sobre los motores de juego se puede resumir en dos ejemplos que explican la redundancia y la inutilidad de los motores, excepto en circunstancias aisladas.
Los novatos que se sienten intimidados con las bibliotecas de bajo nivel, tendrán una convulsión cuando descubran que incluso con un motor de alto nivel como Unity, (además de la representación gráfica, reproducción de audio, carga de contenido; cosas básicas reales) será casi idéntico a hacer un juego desde cero La complejidad está en diseñar un juego, no entender la API o desarrollar las clases para mostrar en la pantalla.
Los expertos que no se sienten intimidados por la complejidad de crear un juego completo en algo como Unity, no tienen uso para Unity porque el tiempo que tomaría aprender con confianza la API y los requisitos de un motor específico es probablemente más dolor de cabeza y más tiempo del que llevaría codificar las pocas clases necesarias para hacer lo básico.
Por lo tanto, los motores son inútiles para los novatos, porque los novatos no pueden hacer nada con ellos porque carecen de las habilidades de ingeniería. Del mismo modo, los motores son inútiles para los veteranos, porque ya tienen las habilidades de ingeniería para hacerlo sin un motor, y también podrían hacer funcionar su propio 'motor' más eficiente y específico que pasar por el dolor de cabeza de aprender tanto la API del motor del juego, funciones y peculiaridades de rendimiento. Sin mencionar la pesadilla masiva de trabajar con motores que a veces no puedes tocar porque no son de código abierto (o incluso si lo son, leer el código de otros puede ser una pesadilla a veces).
Diablos, incluso algunos "marcos de juego" de "bajo nivel" no son más que unas pocas clases para crear una ventana, mostrar en la pantalla y reproducir audio. Esto es algo que un profesional podría hacer desde cero utilizando otras bibliotecas como SDL / SFML o su propia implementación de OpenGL / DirectX / OpenAL, en una fracción del tiempo que lleva completar un videojuego completo.
TLDR;
Si quieres programar, aprende a ser programador .
Evita usar motores , pero no seas tonto e ignora las bibliotecas increíblemente útiles.
Si quieres ser un diseñador de juegos , prueba un motor WYSIWYG y saca esos juegos.
Si quieres ser un programador de juegos , evita los motores como la muleta que son.
Para mí , el uso de motores de juego de nivel superior paralizó mi capacidad de convertirme en programador. En el momento en que comencé a usar bibliotecas de nivel inferior o no usé ninguna biblioteca en absoluto, comencé a aprender tanto que rápidamente pasé de ser un novato total a alguien que ahora puede crear videojuegos sin ninguna referencia, tutoriales o libro junto a mí. Solo mi compilador y mucha ingeniería y práctica.
La cantidad de aprendizaje que obtuve de las bibliotecas de bajo nivel en una CORTA cantidad de tiempo fue mucho mayor que la cantidad que gané en una MUY LARGA cantidad de tiempo con MOTORES de mayor nivel. **