Escribir Game Engine desde cero con OpenGL [cerrado]

15

Quiero comenzar a escribir mi motor de juegos desde cero para aprender, ¿cuáles son los requisitos previos y cómo hacerlo, qué lenguajes de programación y cosas me recomiendan? Además, si tienes buenos artículos y libros sobre eso, será genial. ¡Gracias por adelantado!

Mis lenguajes y herramientas de programación son:

  • C / C ++ ¿es bueno usar solo C?
  • Pitón
  • OpenGL
  • Git
  • GDB

Lo que quiero aprender de él:

  • Core Game Engine
  • Renderizado / Gráficos
  • Juego / Reglas
  • Entrada (teclado / mouse / controladores, etc.)

En Renderizado / Gráficos:

  • 3D
  • Sombreado
  • Encendiendo
  • Texturizado
Wazery
fuente
Dos puntos: esta pregunta, como es, es demasiado amplia. ¿Qué características desea, qué plataforma (s) desea admitir, qué paradigmas desea explorar, cuánta responsabilidad desea poner en un lenguaje de secuencias de comandos (si corresponde) y una gran cantidad de otras cosas? No voy a molestarme en seguir enumerando.
Tetrad
8
Dos: hay una sabiduría común prevaleciente de que otras personas dirán que no debes concentrarte en hacer un motor sin un juego. Un motor sin juego significa que no puedes probar que tu motor es útil . Los buenos motores requieren que las personas coman su propia comida para perros, por así decirlo. Un blog comúnmente vinculado a más de este argumento está aquí: scientificninja.com/blog/write-games-not-engines
Tetrad
2
^ No solo eso, sino que escribir un motor sin un juego para motivar los requisitos de las funciones da como resultado un deslizamiento de las características y un mal diseño de la API. Hasta que sepa lo que necesita, insinuado por los requisitos del juego, no podrá poner cosas útiles en su motor. Del mismo modo, si no ha tenido que usar el motor para programar, es posible que algunas de sus decisiones sean realmente torpes.
ChrisE
1
No veo el punto en sus listados. El hecho de que conozca C / C ++ y Python nos ayuda, pero ¿por qué enumerar que puede usar el control de versiones y un depurador?
El pato comunista
2
@TheCommunistDuck: Hola, eso es mejor que algunos desarrolladores. :)
ChrisE

Respuestas:

11

Puedes escribir un motor de juego en prácticamente cualquier idioma usando prácticamente cualquier método de renderizado. Podría escribir un motor de juego en bash usando la salida de la consola, por ejemplo.

Entonces, creo que sería mejor definir qué es exactamente lo que quieres aprender al escribir tu propio motor. Hay muchos "campos" en el desarrollo de juegos.

  • Core Game Engine

  • Renderizado / Gráficos

  • AI

  • Redes

  • Juego / Reglas

  • Sonido

  • Entrada (teclado / mouse / controladores, etc.)

etc. Desde allí puedes incluso tener subtemas. En Renderizado / Gráficos

  • 2d o 3d?

  • Modelado

  • Sombreado

  • Encendiendo

  • Texturizado

  • GUIs / Huds / Interfaces.

  • etcétera etcétera

¡Solo uno de esos subtemas podría consumir muchas horas (o años) de estudio!

Entonces, primero define lo que quieres aprender. Comience simple.

Use cualquier idioma con el que se sienta cómodo, aunque algunos son más adecuados para ciertas tareas. Por ejemplo, el motor central y la representación probablemente se realicen mejor con un lenguaje de nivel "inferior" como C / C ++ (si necesita rendimiento, eso es); pero algo como IA o Reglas de juego podría hacerse mejor en un lenguaje de nivel superior. Nada dice que no puedes mezclar y combinar. Puede escribir su motor en C ++, su renderizado en C (ya que funciona bien con OpenGL) y luego usar LUA para escribir sus Reglas de juego, etc.

Como ejemplo, hay un motor de juego llamado Slick2D. Está escrito en Java y es de código abierto. Es un ejemplo de un motor 2D simple escrito y diseñado realmente bien. Puedes aprender conceptos básicos a partir de eso, como bucles de juego, administrar estados de juego, etc.

Si te sientes cómodo con C / C ++; Sugeriría echar un vistazo a SDL / OpenGL. Maneja parte de la limpieza como entrada, sonido, creación de ventanas, etc. y puede enfocarse en otras cosas.

usuario697111
fuente
44
Ahh, los días en que estaba aprendiendo C ++ y los juegos de consola eran increíblemente divertidos ... [crea un nuevo proyecto de consola ...]
Nick Bedford
Actualicé mi pregunta, espero darme muchos recursos increíbles :)
Wazery
4

SDL + OpenGL es una excelente opción para iniciar un motor de juego personalizado.

Yo personalmente uso una versión C-ish de C ++ porque descubrí que funciona mejor para mí. Con eso quiero decir que no uso ninguna excepción. Hay dos razones para eso: en primer lugar, las excepciones requieren un código de excepción seguro hasta el final que con OpenGL y SDL no es exactamente fácil de lograr. Sin embargo, lo más importante es que de esta manera es muy fácil exponer objetos C ++ sobre C ABI, lo que es increíblemente útil si intentas incorporar un lenguaje de secuencias de comandos a la mezcla.

Estoy en un barco similar al tuyo y escribí algunas de mis aventuras con SDL y OpenGL en un blog ( immersedcode.org ) en caso de que alguien más esté interesado.

Para la arquitectura general, tengo dos sugerencias: si quieres un motor 3D, mira el libro "Game Engine Architecture" de Jason Lander. Si todo lo que desea es 2D, mantenga el diseño lo más simple posible y déjese inspirar por XNA u otros proyectos.

Por último: no llame a OpenGL por todo el lugar. Hazte un favor y aíslalo en un par de lugares para que puedas cambiar entre el escritorio OpenGL / OpenGL ES o incluso DirectX en un momento posterior si lo deseas.

Armin Ronacher
fuente
0

No use C a menos que un detalle de implementación lo mantenga a punta de pistola. De lo contrario, use C ++, porque es un lenguaje mucho más capaz, y siempre puede elegir no usar esas capacidades más adelante. Personalmente no tengo nada a favor o en contra de Python, nunca lo he usado.

No recomendaría OpenGL contra DirectX porque DX tiene un enfoque moderno orientado a objetos, que es mucho más limpio y más comprensible / menos propenso a errores. La interfaz que ofrece OpenGL es extremadamente pobre en comparación.

Lo último que tengo es que he escuchado de muchas personas en las que confío que GDB apesta por completo y que el depurador de Visual Studio es, de lejos, el mejor. Esta no es mi experiencia personal, así que tómalo con un poco de sal.

DeadMG
fuente
44
"OpenGL vs. DX". El hecho de que DirectX sea más OO no es realmente importante. En cuanto a ser más comprensible ... OpenGL (antes de 3) expone una interfaz bastante sencilla, y una que es fácil de escanear, ya que todo está en una metodología imperativa de estilo C. "Establezca la matriz de proyección en esto. Comience triángulos. Aquí hay un vert. Aquí hay un vert. Aquí hay un vert. Termine los triángulos". La serie 1.x de API OpenGL es buena para mojarse los pies en la programación de gráficos, y combinada con SDL (o incluso GLUT ... urg) le permite obtener una aplicación en 30-50 líneas de código.
ChrisE
2
@ChrisE: Claro que sí. Hay algo llamado extern "C", y su uso apropiado hace que escribir una interfaz C sea bastante trivial, especialmente para Python, donde existe un convertidor dentro de Boost que facilita el enlace. ¿Qué hay de las características del lenguaje C ++? Son grandes . Un mayor uso de las características del lenguaje de C ++ aumenta la confiabilidad de un proyecto y la facilidad de codificación masiva para una compensación de rendimiento muy menor que aceptable. Las características del lenguaje de C son patéticas en comparación. Por ejemplo, el uso correcto de un compilador C ++ moderno puede garantizar que no haya pérdidas de memoria. Hazlo en C.
DeadMG
1
@DeadMG: Si OOP fue realmente un gran problema, también, la respuesta aquí es Java o C #, y no C ++. Lo que no estoy de acuerdo es que el uso de las funciones de C ++ no hace que su código sea mágico mejor, más rápido o incluso más confiable; tienes que saber cómo usar esas características, y ¿aprender un idioma además de diseñar un motor realmente es un buen uso del tiempo? No. No es para alguien que hace esto por primera vez. Puede aprender todo C en un día o dos, cómodamente, y nunca se preguntará qué está haciendo el lenguaje. OpenGL, el útil conjunto de llamadas básicas en cualquier caso, ofrece la misma transparencia.
ChrisE
2
OOP no es un gran problema, no en motores de juegos de alto rendimiento. Claro que es útil, pero a menudo es la abstracción incorrecta. Tener un buen flujo de datos, la ubicación y el diseño de la memoria es generalmente mejor. Si bien muchos equipos usan C ++, no usan la mayoría de las características de C ++. Sin excepciones, tan pocos virtuales como sea posible, sin RTTI, sin STL / Boost. ¿Por qué? Ejecución rápida y predecible y código pequeño en múltiples plataformas. Codifico en C y solo hay dos áreas en las que preferiría usar C ++: bloqueos de ámbito y matrices genéricas. No vale la pena en mi humilde opinión.
nulo
44
En GL frente a D3D: no hay una pila de matriz en el núcleo GL3 / 4, y no hay una pila de atributos. Tanto GL como D3D se asignan a la misma arquitectura de hardware, pero muchas veces GL se siente más delgado. Claro que la máquina de estado GL es un poco molesta, pero también lo es el hardware real;) Aprender cualquiera de ellos está bien, y siempre que comprenda lo que está sucediendo, puede cambiar fácilmente a la otra (o una API de consola).
nulo