Me encanta odiar el juego indie

La historia trata sobre cómo decidí comenzar a desarrollar el juego sin conocimiento y experiencia en esta área, sin un motor e inversiones. ¿Por qué necesito esto? ¿Por qué alguien más? Sobre fracasos y éxitos, sobre el comienzo de la publicación de desarrollo independiente.

Hola a todos! Mi nombre es Roma y durante varios años he estado desarrollando para incrustar, perdóname, C / C ++. La programación para mí es un poco más que trabajo. De ahí el deseo de tener un proyecto propio que crezca, y con ello mi profesionalidad. Creo en ello, de todos modos. Se han probado muchos lenguajes y tecnologías, muchas ideas y tantas fallas. Creo que alguien se reconoció a sí mismo. Esta publicación hablará sobre comenzar el desarrollo de un juego de computadora en C ++ usando OpenGl. Lo siguiente será sobre lo siguiente:

1. Dificultades que surgen frente a mí y enfoques para su solución.
2. Descripción general de las tecnologías utilizadas y las herramientas de desarrollo.
3. Enlaces a recursos usados ​​en la red.

Lo que no sucederá más allá:

1. Sobre las complejidades del desarrollo de C ++. El lenguaje se mencionará con ese grado de abstracción para que pueda ser reemplazado fácilmente por otro OOP de soporte nativo.
2. Acerca de los motores prefabricados y su uso. No tengo nada en contra, incluso estoy a favor. Pero una publicación sobre otra cosa.
3. Sobre la magnífica imagen con los sombreadores de última generación. Tan lejos tan lejos

Entonces, una publicación sobre aventurerismo y arte. El enfoque de desarrollo descrito al final de la publicación me parece al menos no canónico. Sin embargo, creo que tiene derecho a existir. Si lees hasta este lugar y te gusta diseñar desde palos y ir medios improvisados, entonces no te decepcionará.

Inicio y fracaso

Una breve revisión de las herramientas para desarrollar un juego 2D sin ningún motor demostró que inmediatamente debe elegir un marco para procesar el mouse, el teclado, así como el soporte para audio y visualización de primitivas gráficas. La biblioteca SFML fue seleccionada. Les tomó cerca de una semana conocerse, algo fue esbozado: los tanques condujeron a lo largo de un campo rectangular y se mataron entre ellos, fue posible construir sus fábricas y cosas similares en el espíritu del RTS de principios de la década de 2000. Parecía aburrido y quería 3D. Sabía menos sobre 3D que javascript sobre seguridad de tipos. Google fue el primero en lanzar OpenGl, que está pasado de moda. Y también sobre las recomendaciones para usar el llamado Core Profile de este OpenGl. ¿Quién soy yo para escribir con métodos obsoletos? De los intentos de cruzar Core Profile con SFML, resultó que SFML no admite este perfil al mismo tiempo que usa su módulo de gráficos. Fue un fuerte golpe moral, ya que los recursos se gastaron en aprender SFML. Además, no toda la base de código se abstrajo de la biblioteca de gráficos.

GLFW y la nueva esperanza

Como sugiere el nombre de la sección, Core Profile OpenGl y GLFW se llevan bien. El principal recurso que uso en OpenGl. Sí, sí, sin una VPN, lo más probable es que no se abra, gracias a los defensores de Runet. Ayudante En una semana o dos, elementos geométricos simples con texturas flotarán alrededor de la pantalla. Cambiar a GLFW con SFML le enseñará a alguien a valorar el principio de inversión de dependencia (D en SÓLIDO). Como resultado, nació

No me hice ilusiones sobre el lado estético del problema, pero el prototipo estaba vivo. Sí, era feo, pero todos conocen un famoso cuento de hadas. El estado de ánimo mejoró. En ese momento, la tarea más difícil para mí hoy estaba resuelta: crear un modelo con animación. La tarea se dividió en subtareas:

1. Crear animaciones en un editor, por ejemplo, en Blender.
2. Exporte a un formato compatible con animación, como Collada.
3. Importar en C ++, por ejemplo, con la biblioteca Assimp.
4. Diseño de clases y su implementación usando OpenGl.

Por lo tanto, los tanques recibieron una torre giratoria.

Cuando está orgulloso del trabajo, pero avergonzado de mostrarlo

Sí, hoy no todos pueden apreciar las abstracciones bellamente diseñadas, especialmente cuando no lo son . Se necesitaba algo para complacer la vista. Esto era algo así como un paisaje procesal. El generador es conocido desde hace mucho tiempo por todos, pero no para mi Ruido de Perlin . Resultó que hay parámetros que requieren una selección empírica. La recompilación es un duro golpe para la psique, por lo que era necesario una GUI para la creación de prototipos. La búsqueda resultó en una brillante biblioteca ImGui . Con él, los parámetros numéricos, colores, modos de visualización, personalización es un placer. El resultado del generador resultante.

Un poco de niebla

La niebla se muestra a una altura dada con una saturación dada en un sombreador de fragmentos utilizando una función seleccionada empíricamente. Si es necesario, puede agregar varias capas de niebla con sus propios parámetros, incluido el color. Un ejemplo de un paisaje antes y después de aplicar una simulación de niebla:

El momento en que se necesitaban algoritmos

Si lo hizo La segunda vez en 5 años. Se trata de encontrar un camino entre dos puntos en presencia de obstáculos, ¡porque las unidades terrestres no pueden moverse alrededor de las montañas! El algoritmo A * viene al rescate. El pseudocódigo tomó desde aquí . La implementación requiere la creación de perfiles y la optimización, así como muchos otros lugares, sin embargo, en la versión actual, las unidades rodean obstáculos, si es que existe el camino. En algún momento en ese momento la idea del juego tomó forma.

El espacio que somos ...

La idea de trabajo que evolucionará es la exploración del planeta por parte de los pioneros. Creación de una bioesfera, atmósfera y, en última instancia, ecosfera. Daré un ejemplo. Inicialmente, la vida solo será posible dentro de una cúpula creada artificialmente, dentro de la cual será posible cultivar seres vivos: plantas, animales. Ellos, a su vez, afectarán el paisaje. El siguiente es un ejemplo de una cúpula y el paisaje debajo de ella a través de N y M iteraciones, N <M.

Sobre Mercator, Tierra y Política

Un paisaje plano ya es algo, pero solo una de las vistas del planeta. Desde mi punto de vista, es mucho más atractivo mirar un cuerpo cósmico más real. ¡Tiempo de cartografía!

Sospechaba que si era imposible colocar un rectángulo sobre una esfera sin distorsión, entonces el número de métodos de visualización se convirtió en una revelación. La proyección de Mercator más común tiene problemas con la visualización en los polos y distorsiona enormemente las proporciones cuando se aleja del ecuador. Tanto es así que parece que la Federación Rusa es más grande que África y Estados Unidos, Australia.

Al final resultó que, una medida de distorsión también se puede calcular analíticamente. En términos generales, un círculo en un plano se convierte en una elipse en una esfera y viceversa. La tarea era la siguiente: agregar una vista de un cuerpo esférico a una vista plana. De ahí el problema: qué tipo elegir para el principal y cuál mostrar con distorsión. Se decidió mostrar una vista plana sin distorsión como una vista que permite más operaciones, incluyendo seleccionar y mover unidades. La vista del cuerpo esférico se dejó para operaciones con aviones, por ejemplo, satélites artificiales. Como pantalla, la proyección estereográfica de Gall se utiliza como uno de los compromisos. Las distorsiones se calcularon usando elipses de distorsión, también son la matriz de Tisso. Como resultado, puede ver lo siguiente: la captura de pantalla muestra una vista del planeta como un cuerpo esférico con dos cúpulas, una de las cuales alimenta dos fuentes de energía, la otra, una fuente.

Módulos de software y ciclo de desarrollo

La tarea mínima en la etapa “¿Debería comenzar en absoluto?” Fue la siguiente: evolucionar de simple a complejo y hermoso durante todo el año. Es extremadamente fácil durante un par de semanas desde el amor del proyecto alcanzar el asco. Tengo cinco razones para esto:

1. La primera razón es el código. Sin soporte para una arquitectura sana y refactorización, la mayoría de las veces será una corrección de errores, pero ¿cuál es la alegría?
2. Inadecuada concentración en uno. Al estar involucrado en un algoritmo de hora, una hora, un modelo en Blender, no puedo lograr el objetivo.
3. Concentración excesiva Después de haber estado involucrado en el motor y los algoritmos durante mucho tiempo, la imagen no cambia y parece que no hay progreso.
4. Dificultad para dominar la herramienta. La riqueza de la interfaz de Blender o la API de OpenGl inspira respeto, si no miedo. Puede llevar varios días desde el comienzo hasta la primera prueba de concepto, que es un golpe muy moral.
5. Altas expectativas y falta de preparación para el fracaso. A veces es difícil abandonar el enfoque de "Diseño, implementación y no retorno" en favor del "Prototipo / Implementación / Refinamiento de interfaces"

Siendo un campeón de TDD, debo decir que no veo la posibilidad de aplicarlo con tal porcentaje de I + D. Me alegrará si usted, querido lector, me da razones para dudar.

Por el momento, se han destacado las siguientes áreas de desarrollo:

1. Diseñando modelos en Blender.
2. Implementación de algoritmos y matemáticas, por ejemplo, A * o Perlin Noise.
3. Desarrollo de la parte "motor". Se entiende, por ejemplo, como un generador de terreno o la importación de un modelo de Blender.
4. Desarrollo de un módulo responsable de renderizado.
5. Desarrollo de lógica de juego. Requiere que ella use el motor y el módulo de renderizado.
6. Refactorización

Los planes incluyen la separación de los módulos 2-5 a nivel de biblioteca con una fachada en cada uno. Una de las posibles razones: agregar la funcionalidad de control de la cámara requiere una recopilación en cascada de una gran cantidad de código fuente.

La práctica muestra que resulta que funciona de manera productiva si te enfocas en un área durante 5-10 horas. Menos - se pierde el foco, más - el ojo está borroso.

Periódicamente, para lograr el objetivo, veo que es posible violar algunas reglas de desarrollo normal, siempre que se marque el lugar de la violación y se asigne tiempo para la refactorización. Esto último ocurre cada 7-10 días. Ejemplo: crear temporalmente variables globales. Los eliminaré pasándolos a los constructores / métodos durante la refactorización, lo que ayudará a distinguir las clases con baja conectividad y alto engranaje. Lo que implicará una nueva ronda de refactorización. Las ventajas de este enfoque:

1. Disponibilidad para implementar nuevas ideas. Rechazo de lo viejo.
2. La capacidad de evolucionar interfaces.

Contras:

1. La refactorización puede retrasarse.
2. Veo un apoyo poco realista para las pruebas unitarias / simulacros.
3. Algunos superan las dificultades en Vim. ¿Por qué Vim si agrega contras? Entonces, ¿cuáles son las ventajas para mí más?

Para continuar

¡Gracias por su atención a mi humilde post! Todo el código está aquí . Además de las tareas descritas anteriormente, tomó mucho tiempo familiarizarse con Blender, la personalización de vim y la refactorización. Si fue al menos un poco interesante, por favor escriba. Puedo cubrir algo con más detalle en una de las siguientes publicaciones. Un video con un poco más de detalles de implementación está aquí .