Universidad Politécnicade Madrid

Escuela Técnica Superior deIngenieros Informáticos

Grado en Ingeniería Informática

Trabajo Fin de Grado

MOTOR para VIDEOJUEGOS en VISTAISOMÉTRICA IVE (ISOMETRIC VIEW

ENGINE).

Autor: Adrián Monforte GalvezTutor(a): Tomas San Feliu Gilabert

Madrid, Junio 2021

Este Trabajo Fin de Grado se ha depositado en la ETSI Informáticos de laUniversidad Politécnica de Madrid para su defensa.

Trabajo Fin de GradoGrado en Ingeniería Informática

Título: MOTOR para VIDEOJUEGOS en VISTA ISOMÉTRICA IVE (ISOMETRICVIEW ENGINE).

Junio 2021

Autor: Adrián Monforte GalvezTutor: Tomas San Feliu Gilabert

Lenguajes y Sistemas Informáticos e Ingeniería de SoftwareETSI InformáticosUniversidad Politécnica de Madrid

Agradecimientos

Dar las gracias a todas y cada una de las personas que han participado en esta locuraconmigo.

A mis amigos los cuales me ayudaron y motivaron para seguir adelante.

A mi familia los cuales me apoyaron cuando decidí cambiarme de ciudad, persi-guiendo un sueño y sin los cuales no habría sido posible.

A mi pareja, que me ha aguantado y apoyado durante esta larga jornada.

Sobre todo, a mis abuelos que no pueden compartir conmigo este momento, perosé que estarían orgullosos.

!Gracias!

i

Resumen

Ive es un motor para la creación de videojuegos en vista isométrica.

El mundo de los videojuegos es muy grande, existen infinidad de videojuegos, perolas herramientas para crearlos son bastante limitadas. Las grandes compañías usanmotores propietarios, por lo tanto, nadie tiene acceso a ellos. Existen motores con loscuales desarrollar tus videojuegos, pero son pocos.

Por eso nació Ive, para aumentar las posibilidades, porque crear un motor es unatarea muy extensa y compleja. Pero cuando especializas tu motor y te dedicas a ha-cer una sola cosa, pero hacerla bien, se pueden conseguir cosas muy buenas en muypoco tiempo.

Este motor ha sido diseñado para un propósito muy específico, la proyección isomé-trica, para dar la impresión de estar jugando en tres dimensiones, cuando realmenteson dos dimensiones. Ahora mismo cuenta con: renderizado, eventos, cámara, enti-dades y físicas.

El motor ha sido desarrollado pensando en el futuro, permite una fácil implemen-tación para el soporte de otros sistemas operativos y otras APIs de renderizado. Ac-tualmente soporta Windows mediante OpenGL.

iii

Abstract

Ive is a game engine focused on isometric view video games.

The video game market is huge, there is almost infinite video games, but the toolsfor making them are limited. Big companies create their own private game engines.There are available game engines for everyone, but not many.

That’s why Ive was born, to give more options, because making a game engine isa titanic task. But when you specialize your game engine and you focus on one thing,you can achieve great things in so little time.

This engine was designed for one specific use, the isometric projection, which gi-ves the player a three dimension illusion with a two dimension setting. Right now theengine has: renderer, events, camera, entities and physics.

The engine has been developed looking into the future, allowing an easy implemen-tation for other operative systems support and other APIs support. At the moment itsupports Windows with OpenGL.

v

Tabla de contenidos

1. Introducción 11.1. Motivación del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Motores de videojuegos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3.1. Lista de objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2. Estado del arte 32.1. Historia de los motores de videojuegos . . . . . . . . . . . . . . . . . . . . 32.2. Mercado actual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.3. Tecnologías en el desarrollo de videojuegos . . . . . . . . . . . . . . . . . 4

2.3.1. Lenguajes de programación . . . . . . . . . . . . . . . . . . . . . . . 42.3.2. APIs para renderizado . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3.3. Componentes utilizados en el desarrollo . . . . . . . . . . . . . . . 52.3.4. Entorno de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3. Planteamiento 73.1. ¿Como va a ser el motor? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1.1. Proyección isométrica . . . . . . . . . . . . . . . . . . . . . . . . . . 73.1.2. Empezar desde cero . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.1.3. Empezar desde una base . . . . . . . . . . . . . . . . . . . . . . . . 11

4. Desarrollo 134.1. Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.1.1. Ive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.1.2. Sandbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.1.3. Partes del motor de videojuegos . . . . . . . . . . . . . . . . . . . . 18

4.1.3.1. Aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.1.3.2. Ventanas y eventos . . . . . . . . . . . . . . . . . . . . . . . 194.1.3.3. Renderizado . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.1.3.4. Cámara . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.1.3.5. Entidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.1.3.6. Físicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.1.3.7. Cohesión de las partes . . . . . . . . . . . . . . . . . . . . 24

4.1.4. Integración del motor de videojuegos . . . . . . . . . . . . . . . . . 254.1.4.1. Conexión al motor . . . . . . . . . . . . . . . . . . . . . . . 254.1.4.2. Clases accesibles del motor . . . . . . . . . . . . . . . . . . 25

4.2. Manual de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.2.1. Ejecución del motor . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

vii

TABLA DE CONTENIDOS

4.2.2. Funciones disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5. Resultados y conclusiones 275.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.2. Base usada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.2.1. ¿Por qué? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.2.2. Como . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.2.3. Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.3. Impacto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.4. Líneas futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Bibliografía 31

Anexo 32

viii

Índice de figuras

1. Proyección isométrica de varias figuras tridimensionales. . . . . . . . . . 82. Cuadricula en vista isométrica. . . . . . . . . . . . . . . . . . . . . . . . . 93. Escalera en vista isométrica. . . . . . . . . . . . . . . . . . . . . . . . . . . 94. No se puede determinar la diferencia de altura. . . . . . . . . . . . . . . . 105. Cuadricula en vista isométrica. . . . . . . . . . . . . . . . . . . . . . . . . 10

6. Estructura del proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157. Estructura del proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168. Estructura del proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179. Proceso de abstracción del renderizado de una figura. . . . . . . . . . . . 23

10. Momento inicial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3311. Movimiento de la camara. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3412. Movimiento del jugador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3413. El jugador llega al borde. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

ix

Capítulo 1

Introducción

1.1. Motivación del proyecto

¿Hoy en día quien no ha jugado a un videojuego? La mayoría de los jóvenes decidepasar su tiempo libre jugando videojuegos. ¿Por qué? Existen infinidad de razones,tantas como jugadores, unos dicen que ayuda a olvidarse de problemas, otros queasí pueden jugar con sus amigos estén donde estén y haga el tiempo que haga. Perolo mejor de los videojuegos es la variedad que hay, da igual que deporte te guste,si te gusta construir, viajar, ser pirata o incluso ser una célula y evolucionar hastaconquistar el espacio, da igual, hay un videojuego para ti.

Yo como la mayoría, me gustan los videojuegos, cuando aprendí a programar lo hi-ce creando pequeños juegos en ASCII, como el tres en raya, un snake, una patatacaliente y cada vez más complejos con clases de guerreros y enemigos. Pero cuandoquieres pasar del ASCII de la terminal a texturas y ventanas, es un mundo nuevo yademás un mundo bastante complejo. Por eso cuando hace un par de años un vi-deojuego que me encantaba se quedó a mitad de su desarrollo, con bastantes bugsy mal optimizado, decidí crear mi propio videojuego. Me estuve informando sobre losmotores para ello. Te das cuenta de que, aunque hay infinidad de videojuegos, mo-tores para crearlos hay pocos y la gran mayoría reciben actualizaciones cada variosaños. Lo cual me motivó a investigar sobre motores de videojuegos y a realizar esteproyecto.

1.2. Motores de videojuegos

Un motor de videojuegos, es el núcleo necesario para la ejecución de un videojuego,ya que proporciona a los desarrolladores un sistema de renderizado, físicas, audio ymucho más.

Los motores de videojuegos son programas muy complejos y extensos. Cuentan convarios componentes principales: renderización, audio, físicas, inteligencia artificial yscripting. Motores como Unity o Unreal, tienen todos estos componentes y cada varie-dad de ellos. Son motores que llevan decenas de años en el mercado, actualizándosey con muchos desarrolladores detrás.

1

1.3. Objetivos

Los hay que no tienes que programar nada, están diseñados para introducir a losmás jóvenes a este mundo, pero claro la eficiencia de estos videojuegos será muybaja.

Los motores de videojuegos tienen que lidiar con uno de los grandes problemas dehoy en día en el desarrollo de software, queremos que los programas y videojuegosvayan super fluidos y se vean muy bien con cada hardware del mercado.Existen APIs para hacer funcionar los motores en las diferentes plataformas: OpenGL,DirectX, Vulkan... Cada motor tiene que asegurarse de que tiene compatibilidad conlas más grandes y eso puede repercutir en la eficiencia y en la complejidad del desa-rrollo.

1.3. Objetivos

El objetivo es crear un motor de videojuegos, uno muy específico y sencillo. Es muchomás sencillo y eficiente hacer una cosa bien que 10 a medias. Por ello el objetivoes crear un motor para videojuegos en vista isométrica, con un sencillo sistema defísicas de entidades y fluidos. Aplicando todos los conocimientos en matemáticas yprogramación adquiridos durante el grado.

1.3.1. Lista de objetivos

Conocer los motores de desarrollo para videojuegos.

Aplicar los conocimientos de programación en el desarrollo de videojuegos.

Aplicar técnicas de ingeniería para simulaciones.

Aplicar los conocimientos de metodologías ágiles.

Aplicar los conocimientos de matemáticas en el desarrollo de videojuegos.

2

Capítulo 2

Estado del arte

En este capítulo se muestra la evolución de los motores de videojuegos y el mer-cado actual, tanto de motores como APIs(Application Programming Interface) paradesarrollarlos.

2.1. Historia de los motores de videojuegos

Los motores de videojuegos, aparecieron años después de los videojuegos, ya que losprimeros videojuegos eran desarrollados desde cero, para sacar el máximo partido ala maquina en la que se fuera a ejecutar. A mediados de los años 90, creció muchola popularidad de los videojuegos de disparos en primera persona y con ellos el na-cimiento de los motores de videojuegos, como los conocemos hoy en día. El hecho detener una mecánica tan parecida hizo que las empresas reutilizaran el código basede estos videojuegos para crear unos nuevos: mismo movimiento, físicas, mapas yenemigos.

Demasiado en común como para volver a hacerlo de cero. Las empresas dedicadasal desarrollo de videojuegos empezaron a dedicar equipos, para que crearan motorespara sus videojuegos, ahorrando mucho tiempo y dinero. Así se empezaron a crearmotores realmente grandes con soporte para gráficos 2d y 3d, multiplataforma, consistemas de scripting para hacer la vida más fácil a los desarrolladores y muchasotras funcionalidades.[1]

2.2. Mercado actual

En el mercado actual, nos encontramos con varias opciones "gratis"para desarrollarvideojuegos. Estos motores se llaman suite, ya que tienen todo lo necesario para crearel videojuego a tu gusto. Existen dos que son de lejos los más usados, Unreal Enginey Unity, estos dos motores son mundialmente conocidos ya que puedes desarrollartu videojuego con ellos gratis, eso sí, si lo publicas y ganas algo de dinero tendrásque pagar.

Unreal Engine: es el más potente y tiene un sistema 3d espectacular, tambiénes el que te hace pagar más si ganas dinero.

3

2.3. Tecnologías en el desarrollo de videojuegos

Unity: más amplio, puedes desarrollar un videojuego de casi cualquier estilo.Tiene más manga ancha con las ganancias, tienes que ganar bastante dineropara llegar al punto de tener que pagarles.

Existen motores menos populares:

CryEngine: el cual es bastante parecido a Unreal pero un escalón por debajo.

Amazon Lumberyard: es una versión modificada por Amazon del CryEngine, elcual es totalmente gratis, aunque es bastante nuevo.

Godot: el primer open-source y eso le hace ser tan popular, aunque en rendi-miento esta por detrás de los anteriores.

GameMaker: motor exclusivo de 2d, lo malo de este motor es que no tiene unaversión gratuita, necesitas pagar una licencia para usarlo.

Ogre3D: un motor grafico que incluir en tu motor. Solo añade el apartado gráfico,pero lo hace muy bien.

Armory: Este es un caso especial ya que es un motor que se integra en blender,el cual es un software de modelado y animación 3d.[2]

2.3. Tecnologías en el desarrollo de videojuegos

2.3.1. Lenguajes de programación

A la hora de crear un videojuego puedes hacerlo con casi todos los lenguajes de pro-gramación, si tienes la paciencia y los conocimientos. Ya que la gran mayoría cuentacon librerías GUI (graphical user interface) y con ellas poder desarrollar tus juegos.Un buen ejemplo de un videojuego creado en java sin un motor detrás es minecraft.Minecraft es un juego super extenso en cuanto a mecánicas, pero por estar realizadoen java carece de un buen rendimiento, lo cual le obliga a tener un apartado graficocon muy poco detalle y muchas limitaciones de entidades y distancia de renderizado(la cantidad de mapa que puedes ver en cada momento).

Cuando hablamos de motores de videojuegos la cosa cambia, ya que aquí lo impor-tante es la eficiencia. Por ello los motores de videojuegos se desarrollan en C++, yaque te proporciona un mayor control sobre los recursos que el resto de los lenguajes,siendo con diferencia el mejor cuando buscas el máximo de rendimiento. C++ es unlenguaje muy complejo por ese manejo de recursos. Por ello casi todos los motoresdisponen de scripts en lenguajes más sencillos para ayudar en el desarrollo de losvideojuegos. Por ejemplo, Unreal engine está completamente desarrollado en C++ ylos videojuegos creados con Unreal deben ser desarrollados en C++. Este motor noes el mejor por ser sencillo sino por ser el más eficiente en todos los aspectos. Porotro lado, esta Unity un motor desarrollado en C++ y C#. Esto hace que sea muchomás sencillo desarrollar videojuegos con él ya que puedes desarrollarlo en C# eso sinunca llegará al rendimiento que alcanza Unreal por esto mismo.

Para desarrollar este trabajo se va a utilizar C++. Es el lenguaje del cual se puedeconseguir un mayor rendimiento, además de que al ser el más utilizado en el entornode desarrollo de motores de videojuegos, habrá más utilidades y ayuda que para elresto de lenguajes.[3]

4

Estado del arte

2.3.2. APIs para renderizado

Las APIs para el renderizado es una parte fundamental de los motores de videojuegos.Son librerías para sacar el máximo de la reproducción de gráficos en pantalla.Dentro de las APIs más utilizadas nos encontramos con dos multiplataforma: OpenGLy Vulkan, y dos especificas: DirectX y Metal.

OpenGL: Esta es la API elegida para el desarrollo del motor, dado que es mul-tiplataforma, puede ser utilizada en Windows, macOS o Linux. Sumándole lasencillez a la hora de implementarla en tu motor, la hacen la mejor opción paraempezar en el mundo de los motores de videojuegos.[4]

Vulkan: Esta API también es multiplataforma y no solo para ordenadores, sinotambién para dispositivos móviles. A diferencia de las otras tres Vulkan es unaAPI de bajo nivel lo cual implica que tú, tienes mucho más control sobre todo loque ocurre, proporcionando mucho mejor rendimiento. Por lo tanto, es una APIde la cual puedes obtener mejores resultados a costa de una implementaciónmucho más compleja.

DirectX: Es una API desarrollada por Microsoft para Windows y Xbox. Esta APIal ser desarrollada por Microsoft es la ideal para utilizar en Windows y Xbox yaque saca el máximo partido.

Metal: Es una API desarrollada por Apple para macOS y iOS. Esta API al igualque DirectX está desarrollada exclusivamente para los productos Apple y por lotanto para sacar el máximo partido de ellos.

2.3.3. Componentes utilizados en el desarrollo

Aparte del lenguaje de programación y de la API de renderizado, el motor cuenta convarios componentes necesarios para el correcto funcionamiento de este.

Premake: Premake es una herramienta que, mediante una serie de scripts, es-critos en el lenguaje lua, te permite generar los archivos del proyecto con laconfiguración deseada. Este componente se ha elegido porque al contar con en-torno de pruebas del motor y tantos componentes, se necesitaba una formasencilla y rápida de preparar el conjunto de archivos con todas sus configura-ciones. Se ha elegido premake por delante de CMake por su sencillez ya que ala hora de crear los scripts es bastante más sencillo.[5]

spdlog: spdlog es un sistema multiplataforma de logs (información del sistemaque se imprime por pantalla mientras dura la ejecución del programa). Estecomponente es muy necesario para entender que está pasando, que procesosfuncionan correctamente y cuáles no. Además de una gran ayuda a la hora deprobar el motor mediante debug.[6]

GLFW: GLFW es una librería para la API OpenGL, que proporciona una formade creación de ventanas y eventos. Esencial en un videojuego, las ventanas parala visualización y gestión de eventos para controles.[7]

glad: glad es un componente necesario para la implementación de OpenGL enel motor.[8]

5

2.3. Tecnologías en el desarrollo de videojuegos

ImGui: ImGui es la implementación de la interfaz de usuario. Permitiendo mos-trar los gráficos en pantalla, mediante vertex buffers (es la forma que tieneOpenGL de manejar la información que se muestra por pantalla).[9]

glm: glm es una librería de matemáticas para usar con OpenGl.[10]

2.3.4. Entorno de desarrollo

El entorno de desarrollo elegido es Visual Studio ya que proporciona una buenasolución para manejar los proyectos y los componentes extra.[11]

6

Capítulo 3

Planteamiento

Cuando realizas un proyecto con tantas opciones, necesitas plantearte muy bien queopciones vas a elegir para tu proyecto y darles prioridades.

3.1. ¿Como va a ser el motor?

La primera idea y la base de este proyecto, es que el entorno sea visualizado desdeuna projección isométrica.Las partes más básicas para que un motor de videojuegos funcione:

Aplicación: Mantiene todos los demás componentes funcionando mientras no secierre el programa.

Ventanas: Añade la funcionalidad necesaria para manejo de ventanas y eventosdentro de las ventanas.

Renderizado: Nos permite mostrar en las ventanas los gráficos del videojuego.

3.1.1. Proyección isométrica

La proyección isométrica es un sistema de representación gráfica. El cual se caracte-riza por representar un objeto tridimensional en un plano de dos dimensiones. Estoes posible ya que los tres ejes ortogonales principales tienen el mismo ángulo: 120◦.

7

3.1. ¿Como va a ser el motor?

Esta proyección, es utilizada en dibujo técnico, por la sencillez de dibujar objetostridimensionales en papel.

Figura 1: Proyección isométrica de varias figuras tridimensionales.

8

Planteamiento

Esta proyección, se usa en los videojuegos para crear la ilusión de un entorno entres dimensiones, pero usando uno en dos dimensiones, lo cual consigue disminuirla cantidad de texturas que se necesitan renderizar y por lo tanto mejorar el rendi-miento.

Figura 2: Cuadricula en vista isométrica.

Figura 3: Escalera en vista isométrica.

9

3.1. ¿Como va a ser el motor?

Esta proyección, cuenta con un problema importante. Al ser una proyección en dosdimensiones no hay profundidad, por lo tanto existen problemas de distancias e ilu-siones ópticas.

Figura 4: No se puede determinar la diferencia de altura.

Figura 5: Cuadricula en vista isométrica.

10

Planteamiento

3.1.2. Empezar desde cero

Empezar desde cero, creando las funciones básicas sin componentes externos. Lacreación de la capa de ventanas y la capa de renderizado, habrían consumido todoel tiempo disponible, ya que son partes bastante complejas y extensas. Al finalizarel trabajo contaríamos con una ventana en la que se muestran algunos polígonossin nada más. A largo plazo (sin la limitación de horas) sería la mejor opción ya quetodos los funcionamientos serían a tu gusto y medida, y con completo entendimientoy control sobre ellos.

3.1.3. Empezar desde una base

Al final se optó por empezar con una base. Por la limitación de tiempo, para podermostrar cosas funcionando, no solo polígonos.

En internet, hay mucha información sobre cualquier campo y los motores de vi-deojuegos no iban a ser menos, hay motores opensurce para ver cómo funcionan,hay explicaciones e incluso guías. En YouTube, existe un canal (The Cherno[12]) queenseña cómo desarrollar un motor de videojuegos, además de videos donde enseñaprogramación en C++ y OpenGL. Este canal fue el elegido para crear la base del mo-tor. Siguiendo sus videos guía para la creación de la arquitectura del proyecto, capade aplicación, capa de ventanas, capa de renderizado y capa de manejo de entidades.Se eligió este en particular ya que no es copiar y pegar, sino que tú vas viendo comose hace todo, lo vas entendiendo y adaptando a tus necesidades. Además de mostrary explicar los componentes necesarios para una buena y rápida realización de unmotor de videojuegos.

11

Capítulo 4

Desarrollo

Cada una de las partes que componen este proyecto, como funcionan y como serelacionan.

4.1. Arquitectura del sistema

El motor está compuesto por dos proyectos diferentes.

4.1.1. Ive

Es el proyecto principal del motor el cual cuenta con las funcionalidades básicas parael correcto funcionamiento de este.Lista de los componentes del proyecto Ive:1

src/Ive: Es el archivo que contiene la ruta a los archivos que puede usar elproyecto Sandbox.

src/ivepch: Es el archivo que contiene todas las librerias de C++ necesarias.

src/Ive/Application: Es la clase que se encarga de la ejecución inicial.

src/Ive/Core: Es el archivo que contiene funciones basicas del motor.

src/Ive/EntryPoint: Es el archivo encargado de la creación, ejecución y destru-ción del motor.

src/Ive/Input: Es la clase de entrada de los eventos.

src/Ive/KeyCodes: Es el archivo que define el codigo de cada tecla.

src/Ive/Layer: Es la clase base de las capas del motor.

src/Ive/LayerStack: Es la clase que maneja la clase Layer.

src/Ive/Log: Es la clase que define las macros e inicializa el Logger.

src/Ive/MouseButtonCodes: Es el archivo que define el codigo de cada botondel ratón.

1Estas listas son para mostrar los archivos que componen el proyecto, con una muy breve explica-ción, y como esta estructurado.

13

4.1. Arquitectura del sistema

src/Ive/Window: Es la clase que crea la ventana inicial del motor.

src/Ive/Events/ApplicationEvent: Es la clase que maneja los eventos de la apli-cacion.

src/Ive/Events/Event: Es la clase que categoriza los eventos.

src/Ive/Events/KeyEvent: Es la clase que maneja los eventos de teclado.

src/Ive/Events/MouseEvent: Es la clase que maneja los eventos de ratón

src/Ive/ImGui/ImGuiBuild: Es el archivo que incluye ImGui.

src/Ive/ImGui/ImGuiLayer: Es la clase que gestiona todo lo referente a ImGui.

src/Ive/Renderer/Buffer: Es la clase abstracta2 que maneja los buffers de datosde la API.

src/Ive/Renderer/GraphicsContext: Es la clase abstracta que inicializa la API.

src/Ive/Renderer/OrthographicCamera: Es la clase que crea y mueve la cama-ra.

src/Ive/Renderer/OrthographicCameraController: Es la clase que maneja loscambios en la camara.

src/Ive/Renderer/RenderCommand: Es la clase que manda los comandos a eje-cutar a la clase RendererAPI.

src/Ive/Renderer/Renderer: Es la clase que inicializa la escena.

src/Ive/Renderer/RendererAPI: Es la clase abstracta que manda los comandosa la API

src/Ive/Renderer/Shader: Es la clase que permite dar color a las figuras que serenderizan.

src/Ive/Renderer/VertexArray: Es la clase abstracta que maneja los Array dedatos de la API.

src/Platform/OpenGL/OpenGLBuffer: Es la clase que maneja los buffers de da-tos.

src/Platform/OpenGL/OpenGLContext: Es la clase que inicializa el sistema derenderizado.

src/Platform/OpenGL/OpenGLRendererAPI: Es la clase que ejecuta los coman-dos de renderizado.

src/Platform/OpenGL/OpenGLVertexArray: Es la clase que maneja los Array dedatos.

2Una clase abstracta sirve para todas la APIs de renderizado. Esta hace la llamada a la API en usopara que esta lo gestione.

14

Desarrollo

src/Platform/Windows/WindowsInput: Es la clase que maneja las entradas dela ventana.

src/Platform/Windows/WindowsWindow: Es la clase que maneja la ventana delmotor

vendor/Glad/: Es el modulo de implementación de OpenGL.

vendor/GLFW/: Es el modulo de ventanas y eventos de OpenGL.

vendor/glm/: Es el modulo de matemáticas de OpenGL.

vendor/imgui/: Es el modulo de interfaz de usuario.

vendor/spdlog/: Es el modulo de logs.

4.1.2. Sandbox

Es el proyecto ejemplo, que haciendo uso de las funciones de Ive puedes crear unvideojuego. Lista de los componentes del proyecto Sandbox:

src/Sandbox: Es la clase que genera los datos y llama a las funciones para lacreación del videojuego.

Figura 6: Estructura del proyecto.

15

4.1. Arquitectura del sistema

Figura 7: Estructura del proyecto.

16

Desarrollo

Figura 8: Estructura del proyecto.

17

4.1. Arquitectura del sistema

4.1.3. Partes del motor de videojuegos

Explicación en profundidad de cada una de las partes principales de este motor devideojuegos.

4.1.3.1. Aplicación

Empezando por el principio nos encontramos la capa de Aplicación la cual es la en-cargada de la inicialización de la aplicación, el logger y que ambos tengan un correctofuncionamiento.Archivos en la ruta(Ive/src/Ive):

EntryPoint: Contiene el main del motor.

1 Ive : : Log : : In i t ( ) ;

Inicializa el logger para mostrar toda la información que consideremos necesa-ria.

1 auto app = Ive : : CreateApplication ( ) ;2 app−>Run( ) ;3 delete app;

Inicializa la aplicación, la ejecuta hasta que se cierra el videojuego y la borra.

Application: Encargada de la inicialización de las ventanas y los manejadores deeventos.

1 Application ( ) ;

Crea la ventana principal y la prepara para aceptar los eventos. Crea una ven-tana para la utilización del modulo ImGui.

1 Run( ) ;

Bucle principal, se ejecuta mientras no se cierre la ventana y se encarga deactualizar cada capa adicional y la ventana principal, en cada iteración.

1 OnEvent ( Event& e ) ;

Encargado de manejar los eventos referidos al cierre de ventanas.

18

Desarrollo

1 PushLayer ( Layer* layer ) ;2 PushOverlay ( Layer* layer ) ;

Encargado de manejar la posición de las ventanas.

1 OnWindowClose ( WindowCloseEvent& e ) ;

Core: Contiene definiciones básicas para el correcto funcionamiento del motor,por ejemplo: plataforma en la que se va a ejecutar el programa, activación dedetección de errores y eventos con tecla fn.

Log: Contiene las macros necesarias para mostrar los diferentes tipos de infor-mación relevante en la ejecución

1 In i t ( ) ;

Haciendo uso del módulo spdlog lo inicializa para que funcione correctamenteconjunto a la aplicación.

4.1.3.2. Ventanas y eventos

Parte fundamental para poder interactuar con el motor. Archivos en la ruta (Ive/sr-c/Ive/Events):

Event: Es el encargado de categorizar los eventos recibidos.

KeyEvent: Encargado de controlar los eventos de teclado.

1 KeyPressedEvent ( int keycode , int repeatCount ) ;2 KeyReleasedEvent ( int keycode ) ;3 KeyTypedEvent ( int keycode ) ;

Dependiendo de qué manera se ha pulsado una tecla realiza una acción u otra.

MouseEvent: Encargado de controlar los eventos de ratón.

1 MouseMovedEvent ( float x , float y ) ;2 MouseScrolledEvent ( float xOffset , float yOffset ) ;3 MouseButtonPressedEvent ( int button ) ;4 MouseButtonReleasedEvent ( int button ) ;

Dependiendo de qué manera se ha usado el ratón realiza una acción u otra.

19

4.1. Arquitectura del sistema

ApplicationEvent: Encargado de controlar los eventos la ventana de aplicación.

1 WindowResizeEvent (unsigned int width , unsigned int height ) ;2 WindowCloseEvent ( ) ;3 AppTickEvent ( ) ;4 AppUpdateEvent ( ) ;5 AppRenderEvent ( ) ;

Gestiona las posibles acciones con la ventana.

Archivos en la ruta (Ive/src/Ive/):

Window: Este es un archivo abstracto. Es al cual llama el programa y este asu vez llama a la clase que esta asignada a la plataforma. Si estas en Windowsllama a los archivos de manejo de ventanas de ese sistema operativo. De estaforma puedes implementar las ventanas en todos los sistemas operativos que sequiera, agregando la detección de sistema operativo en el archivo Core y así serun motor multiplataforma.

Input: Este es el archivo abstracto de manejo de entrada de eventos de tecladoy ratón.

Layer: Clase que se usa para la implementación de capas.

LayerStack: Clase que maneja varias Layer para poder crear capas de gráficos oeventos en la aplicacion.

Archivos en la ruta (Ive/src/Platform/Windows):

WindowsInput: Es la implementación de la clase que maneja la entrada de even-tos de teclado y ratón en Windows.

WindowsWindow: Es la implementación que inicializa, actualiza, gestiona loseventos, gestiona los atributos y cierra la ventana en Windows. Haciendo usodel módulo GLFW.

4.1.3.3. Renderizado

Parte principal de cualquier motor de videojuegos es la capacidad de mostrar imáge-nes y figuras por pantalla.3

glad: glad es el módulo encargado de dar al motor acceso a las funciones deOpenGL.

ImGui: ImGui es el módulo encargado de dar al motor una interfaz de usuario.

glm: glm es el módulo encargado de dar al motor una librería de matemáticas.

3Existen juegos que no usan renderizado, sino caracteres ASCII para crear el juego. Estos son juegosde texto no videojuegos.

20

Desarrollo

Archivos en la ruta (Ive/src/Ive/Renderer) y en la ruta (Ive/src/Platform):

Buffer: Clase abstracta de OpenGLBuffer.

OpenGLBuffer: Es la clase encargada del manejo de los VertexBuffer y los In-dexBuffer.

1 OpenGLVertexBuffer ( float * vertices , uint32_t size ) ;2 Bind ( ) override ;3 Unbind ( ) override ;4 BufferLayout& GetLayout ( ) override ;5 SetLayout ( const BufferLayout& layout ) override ;

Bind y Unbind son dos métodos que se utilizan para que no perdamos la infor-mación entre las llamadas.

1 OpenGLIndexBuffer ( uint32_t * indices , uint32_t count ) ;2 Bind ( ) override ;3 Unbind ( ) override ;4 uint32_t GetCount ( ) override ;

GetCount te devuelve el número de índices de las figuras a renderizar.

GraphicsContext: Clase abstracta de OpenGLGraphicsContext.

OpenGLGraphicsContext: Clase que inicializa el renderizado.

1 In i t ( ) override ;2 SwapBuffers ( ) override ;

Init inicializa GLFW y glad para que el proceso de renderizado funcione correc-tamente.SwapBuffers avanza los buffers para que al actualizar la ventana no haya pro-blemas.

RenderCommand: Es la clase encargada de llamar a la API con los comandosbásicos de renderizado.

Renderer: Es la clase encargada de inicializar la escena enviada desde el juegoy cerrarla cuando termine.

1 BeginScene ( OrthographicCamera& camera ) ;2 EndScene ( ) ;3 Submit ( const std : : shared_ptr<Shader>& shader , const std : : shared_ptr<

VertexArray>& vertexArray , const glm : : mat4& transform = glm : : mat4(1.0 f ) ) ;

Submit es el metodo encargado de juntar la información que ha mandado elvideojuego y mandársela a RenderCommand.

21

4.1. Arquitectura del sistema

RendererAPI: Clase abstracta de OpenGLRendererAPI.

OpenGLRendererAPI: Clase encargada de ejecutar los comandos básicos de ren-derizado.

1 SetClearColor ( const glm : : vec4& color ) override ;2 Clear ( ) override ;3 DrawIndexed ( const std : : shared_ptr<VertexArray>& vertexArray ) override ;

Primero se limpia la escena y después de dibuja la información del vertexArraycreado en el Renderer

Shader: Clase que permite dar color a las figuras renderizadas.

1 Shader ( const std : : string& vertexSrc , const std : : string& fragmentSrc ) ;2 Bind ( ) const ;3 Unbind ( ) const ;4 UploadUniformMat4 ( const std : : string& name, const glm : : mat4& matrix ) ;5 UploadUniformFloat4 ( const std : : string& name, const glm : : vec4& values ) ;

VertexArray: Clase abstracta de OpenGLVertexArray.

OpenGLVertexArray: Clase que maneja los datos que contienen los VertexBuffery los IndexBuffer.

1 OpenGLVertexArray ( ) ;2 Bind ( ) const override ;3 Unbind ( ) const override ;4 AddVertexBuffer ( const std : : shared_ptr<VertexBuffer>& vertexBuffer )

override ;5 SetIndexBuffer ( const std : : shared_ptr<IndexBuffer>& indexBuffer )

override ;

22

Desarrollo

Proceso que sigue el motor a la hora de realizar el render de una figura (Se hanincluido las instrucciones fundamentales).

Figura 9: Proceso de abstracción del renderizado de una figura.

23

4.1. Arquitectura del sistema

4.1.3.4. Cámara

Parte que permite la vista isométrica. Archivos en la ruta (Ive/src/Ive/Renderer):

OrthographicCamera: Clase que realiza la inicialización de la cámara y los mo-vimientos de esta.

1 OrthographicCamera ( float l e f t , float right , float bottom , float top ) ;2 SetProjection ( float l e f t , float right , float bottom , float top ) ;3 SetPosition ( const glm : : vec3& position ) ;4 SetRotation ( float rotation , glm : : vec3 axis ) ;5 RecalculateViewMatrix ( ) ;

La función RecalculateViewMatrix se llama al cambiar la posición de la cámarao la rotación para actualizarla.

OrthographicCameraController: Clase que recibe la información de Sandbox yeventos, la procesa y la manda a OrthographicCamera.

1 OrthographicCameraController ( float aspectRatio , bool rotation = false );

2 OnUpdate ( ) ;3 OnEvent ( Event& e ) ;4 OnResize ( float width , float height ) ;5 SetZoomLevel ( float l e ve l ) ;

4.1.3.5. Entidades

El sistema de entidades esta implementado en el proyecto Sandbox. Este permite lacreación de una entidad con la forma, colores y posición deseados. Además, cuentacon movimiento independiente y colisiones.

4.1.3.6. Físicas

El sistema de físicas cuenta con colisión de entidades lo cual permite que la entidadno se salga del mapa, o no atraviese obstáculos.

4.1.3.7. Cohesión de las partes

Para el correcto funcionamiento de todas las partes como una sola se hace uso de:

Premake: Premake mediante scripts en lua genera los archivos necesarios parala ejecución del motor.

Ive.h: Es el archivo puente entre Ive y Sandbox, en él se incluyen los archivosde Ive que Sanbox necesita para crear un videojuego.

ivepch.h: Es el archivo que provee a todo el proyecto de las librerías de C++necesarias para su funcionamiento.

24

Desarrollo

4.1.4. Integración del motor de videojuegos

Como se consigue que un juego use el motor y ha que partes tiene acceso.

4.1.4.1. Conexión al motor

El proyecto Sandbox incluye el archivo Ive.h dándole acceso a las clases necesariaspara la correcta immplementación de un videojuego.

4.1.4.2. Clases accesibles del motor

Las clases incluidas:

Buffer: Se almacenan los vértices y el diseño de la figura

VertexArray: Información que se ha almacenado previamente en el buffer.

Shader: Creación del shader que se va a mostrar en el renderizado.

Input: Control de las entradas por teclado y ratón.

RenderCommand: Procesos previos al renderizado.

Renderer: Inicializa la escena con la cámara, muestra las figuras en pantalla ycierra la escena.

OrthographicCamera: Gestiona la posición de la cámara en la escena y sus mo-vimientos.

OrthographicCameraControler: manda a la cámara los eventos de movimiento.

4.2. Manual de uso

Por el momento el motor carece de una interfaz de usuario terminada, por lo cualtodo el desarrollo ha de ser mediante Código.

4.2.1. Ejecución del motor

El motor ha sido desarrollado en Visual Studio 2019. Por lo tanto, para una correctaejecución del motor se recomienda su uso.

Una vez descargado antes de abrirlo, hay que ejecutar el archivo GenerateProjects.batque se encuentra en la carpeta Ive/scripts. A continuación, abrir el archivo Ive.sln(abrir con Visual Studio) que se encuentra en Ive/. Esto abrirá todos los proyectosnecesarios para el correcto funcionamiento del motor. Dentro del proyecto Sandboxse puede usar todo lo implementado.

25

4.2. Manual de uso

4.2.2. Funciones disponibles

El proyecto Sandbox puede hacer uso de cualquier función pública de las clases quese incluyen en el archivo Ive.h:

1 // For use by Ive applications2

3 #include "Ive/Application.h"4 #include "Ive/Layer.h"5 #include "Ive/Log.h"6

7 #include "Ive/Input.h"8 #include "Ive/KeyCodes.h"9 #include "Ive/MouseButtonCodes.h"

10

11 #include "Ive/ImGui/ImGuiLayer.h"12

13 // −−−Renderer−−−−−−−−−−−−−−−−−−−−−14 #include "Ive/Renderer/Renderer.h"15 #include "Ive/Renderer/RenderCommand.h"16

17 #include "Ive/Renderer/Buffer.h"18 #include "Ive/Renderer/Shader.h"19 #include "Ive/Renderer/VertexArray.h"20

21 #include "Ive/Renderer/OrthographicCamera.h"22 #include "Ive/Renderer/OrthographicCameraController.h"23

24 // −−−Entry Point−−−−−−−−−−−−−−−−−−−−−25 #include "Ive/EntryPoint.h"26 // −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

26

Capítulo 5

Resultados y conclusiones

Conclusiones personales, analisis del impacto y lineas a seguir en el desarrollo deeste proyecto.

5.1. Conclusiones

Ha sido un proyecto extenso y complejo. Ha habido muchas complicaciones, al seralgo tan diferente ha supuesto muchos problemas en su desarrollo. Un lenguaje cono-cido, pero en el que no había profundizado. Un mundo nuevo de APIs de renderizadoy módulos externos.

Al principio fue difícil, ya que el plan de trabajo se descuadró bastante, el desarrollode la base del motor llevó más de lo esperado haciendo que tuviera que eliminar lacapa de generación de mundos. La capa de renderizado resulto ser bastante extensa,debido a la decisión de crear una abstracción para que en el futuro se pudieran ma-nejar diferentes APIs con más facilidad. Al terminar la capa de renderizado surgió unimprevisto que cambio todo el rumbo, la necesidad de una cámara para el movimien-to y la proyección isométrica, esto hizo que tuviera que eliminar la capa de gestión dememoria, generación de caminos y reducir la capa de físicas.

Una vez entendí el funcionamiento de OpenGL y las matemáticas que usa, todo fuemás sencillo y avanzó mucho más rápido. La decisión de empezar con una base dereferencia no ha sido la mejor decisión. Aunque me ha permitido tener una estructuramás limpia, con perspectiva de futuro y sin duda con una mejor programación de loque yo hubiera hecho. Considero que al principio me ralentizó mucho, ya que necesitéde mucho tiempo para preparar todo y entenderlo bien. Además de que al estar tantotiempo con la base no he dedicado todo el tiempo que me hubiera gustado a usarOpenGL y en la capa de entidades y físicas.

Aun con todo estoy contento con el resultado tengo un motor de videojuegos en vistaisométrica, con entidades, unas físicas de colisión y movimiento de cámara y jugador.Por supuesto esto no se va a quedar aquí, he disfrutado mucho de esta experiencia yaprendido mucho. Cuando ves un simple cuadrado moverse por la pantalla despuésde muchas horas de intentarlo es maravilloso.

27

5.2. Base usada

5.2. Base usada

Como he comentado en diferentes ocasiones, para la realización de este trabajo se hausado una base de internet. Me gustaría explicar el porqué, como y conclusión.

5.2.1. ¿Por qué?

Nunca había trabajado en el campo de los motores de videojuego, ni renderizado,en nada de este proyecto. Por eso mismo cuando estaba buscando información pa-ra realizar la propuesta, me encontré con este canal de YouTube[12] el cual es deuna persona que se ha dedicado profesionalmente al desarrollo de motores de vi-deojuegos, y el cual tenía una serie de videos guía sobre cómo desarrollar un motorde videojuegos, además de videos enseñando C++ y OpenGl. Así que decidí usar esecontenido como base de mi trabajo.

5.2.2. Como

Una vez comenzado el trabajo, seguí estos videos, sobre todo para tener una buenaestructura y un código bien hecho. Este proceso no era llegar y copiar el código, eramirarlo muy bien, entenderlo y modificarlo a mis necesidades. Esto hizo que las capasbásicas antes del renderizado me llevaran bastante tiempo.

5.2.3. Conclusión

Ahora que he terminado tengo claro que no lo hubiera hecho así, ya que no he podidodesarrollar mi proyecto como me hubiera gustado por el hecho de empezar siguiendounas guías. Aun así, estoy contento con el resultado y al haber elegido así puedocontinuar con este trabajo en un futuro ya que cuenta con una base sólida.

5.3. Impacto

Este proyecto tiene un impacto directo en el objetivo sostenible de educación de ca-lidad. Un motor de videojuegos tiene como función principal la creación de un vi-deojuego. Para ello es necesario un gran componente de creatividad. A la hora decrear un videojuego hay mucha implicación de matemáticas, física y lógica, ademásde muchos otros campos dependiendo del tipo de juego que se quiera desarrollar.

La mejor forma de aprender es hacer algo que te gusta y los juegos gustan a todo elmundo.

5.4. Líneas futuras

Este trabajo ha sido pensado desde un principio para no parar aquí. Por eso setomó la decisión de empezar con una base, para tener mejores cimientos de cara alfuturo, esto ha quitado bastante tiempo del desarrollo, pero gracias a esto el motor devideojuegos puede soportar cualquier API de renderizado y soporta cualquier sistemaoperativo. Puntos por implementar a continuación:

Texturas: Crear una capa de texturas que permita aplicar imágenes externas alos polígonos renderizados.

28

Resultados y conclusiones

Memoria: Crear funciones que optimicen diferentes situaciones de mucho usode recursos.

Sombras: Crear un sistema de sombras para las entidades.

Particulas: Crear un sistema de partículas

Scripting: Crear un sistema que permita definir comportamientos dentro deljuego con un lenguaje más sencillo como lua.

Audio: Crear un sistema de audio.

APIs: Agregar soporte para Vulkan, DirectX y Metal.

Multiplataforma: Agregar soporte para Linux y macOS.

Ampliar y mejorar lo implementado hasta ahora.

29

Bibliografía

[1] MomentsOnline. (2020, Abr 21). Brief history of game-engine then till now. [On-line]. https://momentsonline69.medium.com/create-any-game-with-gdevelop-game-engine-9c8ca2344921

[2] Pedro Pablo Fernández. (2020, Feb 18). Motores gráficos y de juego: definición,tipos y modelos de negocio. [Online]. https://www.hyperhype.es/motores-graficos-y-de-juego-definicion-tipos-y-modelos-de-negocio/

[3] ISO/IEC. (2020). ISO International Standard ISO/IEC 14882:2020(E) – Pro-gramming Language C++. Geneva, Switzerland: International Organization forStandardization (ISO).

[4] Khronos Group. (2021). OpenGL. [Online]. https://www.opengl.org/

[5] —. (2021). Premake. [Online]. https://premake.github.io/

[6] —. (2021). spdlog. [Online]. https://github.com/gabime/spdlog

[7] —. (2021). GLFW. [Online]. https://www.glfw.org/

[8] —. (2021). glad. [Online]. https://github.com/Dav1dde/glad

[9] —. (2021). ImGui. [Online]. https://github.com/ocornut/imgui

[10] —. (2021). glm. [Online]. https://github.com/g-truc/glm

[11] Microsoft. (2021). Microsoft Visual Studio Community 2019. [Online].https://visualstudio.microsoft.com/

[12] Yan Chernikov. (2021). Listas con video guia/tutoriales: Game Engine, OpenGl,C++. [Online]. https://www.youtube.com/user/TheChernoProject

31

Anexo

Imagenes del resultado final del trabajo.

Figura 10: Momento inicial.

33

Figura 11: Movimiento de la camara.

Figura 12: Movimiento del jugador.

BIBLIOGRAFÍA

Figura 13: El jugador llega al borde.

35

Este documento esta firmado porFirmante CN=tfgm.fi.upm.es, OU=CCFI, O=Facultad de Informatica - UPM,

C=ES

Fecha/Hora Thu Jun 03 19:53:53 CEST 2021

Emisor delCertificado

EMAILADDRESS=camanager@fi.upm.es, CN=CA Facultad deInformatica, O=Facultad de Informatica - UPM, C=ES

Numero de Serie 630

Metodo urn:adobe.com:Adobe.PPKLite:adbe.pkcs7.sha1 (AdobeSignature)