Comencé la programación de C #, para luego desarrollar juegos con XNA. Leí un buen libro de desarrollo de juegos para C #. Como ya conocía otros idiomas, pude aprender rápidamente las características de C # y el código de sintaxis. Luego me acerqué a XNA. Como el libro que estaba leyendo era un poco viejo, lo dejé a un lado y comencé a mirar tutoriales de desarrollo de juegos sobre XNA a través de Internet. Pude lograr y entender la mayoría de ellos, usando gráficos 2D. Creé sprites animados, hice que mis personajes se movieran en cualquier dirección, desplacé mi fondo junto con el movimiento de mis personajes, y así sucesivamente. Todo se hizo con XNA "en bruto".
Encontré algunas de esas cosas difíciles de entender y descubrí que algunas cosas ya están integradas en el marco. Encontré otros motores de juego, que pude entender claramente al menos los códigos de línea simples, como " FlatRedBall " , " Axiom " y " Quick Start Engine " . Ya conocía a los famosos, como "OGRE" , "Unreal" y "Unity" . Al mismo tiempo, tuve la tentación de tirarlo todo a la basura y comenzar a aprender algunos programas famosos de motores de juegos. Quería quedarme con XNA, ya que me tomó tiempo aprender; tiempo no me gustaría desperdiciarlo.
Esta vez, lo dejo a los experimentados. ¿Puedo pasar por algún motor de juego y usar lo que tiene para ofrecer, incluso si estoy comenzando con el desarrollo del juego? Algunas personas podrían pensar que es bueno acostumbrarse a las rutinas aburridas de un marco desnudo. Si es así, ¿cuál sería el recomendado para comenzar? Escuché que varía de un mercado a otro. Quizás podríamos considerar que quiero un juego de rol específico.
Respuestas:
Depende de lo que quieras aprender. Si quieres "crear un juego" puedes ser bueno con un motor. Yo personalmente no recomiendo esto.
Si realmente quieres entender cómo funcionan los gráficos por computadora, debes profundizar y aprender todo. Desde actualizar su álgebra lineal (al menos matrices, vectores y espacios lineales) hasta comprender cómo funcionan las tuberías gráficas. XNA es el mejor marco para comenzar. Mi primer juego fue en él (me refiero a un juego real, la primera aplicación 3D fue tanques de batalla en openGL). Si desea comenzar la programación 3D, no tenga planes tan ambiciosos, no puede hacer un juego de rol ahora. Debes intentar hacer un juego en el que estés volando en el espacio lleno de cubos y tratando de disparar a los rojos, para aprender lo básico. Probablemente te llevará más tiempo del que crees :). Pero te enseñará mucho.
¡Y ve por ello! La programación de gráficos en 3D es lo mejor que puede hacer para vivir. Es difícil, divertido y creativo en un solo paquete.
fuente
No hay nada de malo en usar un motor existente, todo se reduce a tus objetivos.
Si está más interesado en construir algunos juegos o diseños de juegos, cuanto más rápido llegue al código de juego, mejor. Algo así como Unity es genial aquí, ya que puede usar su conocimiento de C # y comenzar a adjuntar scripts a objetos y tener algo ejecutándose de inmediato.
Si quieres convertirte en un programador de juegos, entonces necesitas entender las cosas en un nivel inferior. Un marco como XNA es un buen punto de partida. Puedes confiar en el marco para poner las cosas en marcha y luego comenzar a reemplazar partes del marco con tu propio código a medida que aprendes a construir cada componente de tu juego.
fuente
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. **
fuente