Explore
For Enterprise
Join for Free
Log In

artes y humanidades
Negocios
Ciencias de la Computación
Ciencia de Datos
Tecnología de información
salud
Matemáticas y Lógica
Desarrollo Personal
Ciencias Físicas e Ingeniería
Ciencias sociales
Aprendizaje de un idioma
Grados
Certificados

Explorar todo lo que Coursera tiene para ofrecer

Explorar
Buscar
For Enterprise
Inicia Sesión
Únete de forma gratuita

Introducción a un motor 3D (Parte V)

Loading...

Motores gráficos en videojuegos: game engine

Universitat Autònoma de Barcelona

3.9 (88 calificaciones) | 5K estudiantes inscritos

Curso 4 de 6 en Diseño y Creación de videojuegos Programa Especializado

VERSIÓN EN ESPAÑOL Para todas aquellas personas que han querido saber cómo se creaba un videojuego, en este curso vamos a explicar cómo crear un pequeño motor, uno de los elementos nucleares de cualquier videojuego. El curso persigue comprender su concepto, entender qué es ese núcleo que en terminología inglesa se conoce como 'game engine', Analizaremos no solo su papel, sino qué utilidades debe proporcionar para ser utilizado en un videojuego. Y todo ello, explicando cómo crear un pequeño motor desde cero, que nos permitirá crear un videojuego en DirectX11. Un curso donde cualquier persona podrá entender los conocimientos básicos sobre el funcionamiento de un motor, y donde las personas con formación en programación aprenderán a crear su propio motor. El curso está estructurado de tal forma que desde el primer día tengamos resultados en pantalla y cualquier persona pueda seguir el propio curso. El resultado será un pequeño motor de videojuegos 3D sobre DirectX11, donde crearemos un pequeño videojuego de tipo FPS. IMPORTANTE Subtítulos en inglés disponibles. _________________ ENGLISH VERSION For those who ever wanted to know how to create a video game, in this course we will explain how to create a small engine, one of the main elements in any video game. This course wants to understand their concept, understand what is this nucleus called 'game engine'. We will analyze their role and which utility it has to provide in aim to be used in a video game. We will do all this by explaining how to create a small engine which will allow us to create a DirectX11 video game. A course in which anyone will be able to understand the basic knowledges on an engine's functioning, and where people who have studied programming will be able to create their own engine. This course is structured so that from the first day we have results on screen and anyone can follow them. IMPORTANT English subtitles are available for this course.

Revisiones

3.9 (88 calificaciones)

5 stars
46 ratings
4 stars
16 ratings
3 stars
9 ratings
2 stars
9 ratings
1 star
8 ratings

AJ

Feb 25, 2016

Muy buen curso, lleva el avance muy rápido, pero explica lo elemental.

JM

Sep 27, 2017

Fue el mejor curso en internet que he visto... no esperaba menos

De la lección

Introducción a un motor 3D

En este módulo aprenderemos los conocimientos necesarios para crear una aplicación DirectX 11 con Microsoft Visual Studio. Una vez creada nuestra aplicación en DirectX 11 64 bits aprenderemos a pintar modelos de tipo Debug como Ejes, cajas, esferas y grids.

Introducción a un motor 3D (Parte I)17:09

Introducción a un motor 3D (Parte II)10:43

Introducción a un motor 3D (Parte III)12:01

Introducción a un motor 3D (Parte IV)10:59

Introducción a un motor 3D (Parte V)12:26

Introducción a un motor 3D (Parte VI)14:42

Impartido por:

Enric Martí Gòdia
Associate Professor
Jordi Arnal Montoya
CEO en Kaneda Games y Colaborador docente

Transcripción

We will go on explaining the camera systems we've mounted on

our engine.

CameraManager manages the different cameras in our game.

Inside our engine, we can have more than one camera, either for Debug,

to play, or whatever we want.

So, for the CameraManager we've used a class,

which reads an XML file (we will explain them later) and

based on this XML file we can create different cameras inside our game.

To read the XML files we use the XMLParser class.

Again, we've got a camera controllers dictionary

where a name is defined,

each camera is defined by a name and based on those camera controllers

we can pick a camera controller depending on its name.

We've got the method, CameraController, which will add a new kind of camera

associated to a name, a position, a zoom, etc.

We've got the method, ChangeVision, which swaps from using a vision camera

to another, and then the ChangeControl, which changes the camera controller

between one and the other, so we've got the two methods which will be used later on

the Frustum to know if an sphere is visible, going through a position and a radius,

or if a container box is visible, passing a minimum and a maximum.

Also the Load method, which will be responsible for charging us the XML file

and then the Camera method which will give us back to the camera directly

and the Update, which updates the CameraManager.

We get to the CameraManager and we see that when it is built,

the Frustum is built, the first camera is inserted,

which is a camera called Player,

from a FPS, and this is the one we are going to use as camera control and camera vision.

We've got the destroyer which will be the responsible to delete each of the cameras

and we've got another method,

CameraController, which depending on the kind of camera will give me a camera

controller, either a spheric-type camera or a FPS camera.

ChangeVision will iterate respect to the many

different camera controllers and then we've got the StartElement method,

which is the one which will patch the XML file.

This means we've got a XML file just like the one we will going to see right now.

This is an XML file. The XML file has a parent that in our case is

CameraManager, a Main tag, and we've got two kinds of elements, in this case,

SphericalCameraController and FPSCameraController.

Those kinds of elements have properties, which are different for each kind,

the name in the XYZ camera controllers' position and the zoom to

the spherical and on the other side we've got the FPS camera controller

which has another name and another XYZ position for this kind of camera.

If we go to the code, for each element

on the XML file, the CameraManager, the SphericalCameraController or

the FPSCameraController the method OnStartElement will be called.

So if this element is called SphericalCameraController

we get its properties, its name attributes, its XYZ position,

its zoom and we add a spherical CameraController using its name,

its position and its zoom.

If we get to a FPSCameraController type we take off the name,

the XYZ position, we don't need to take off the zoom,

and we make a CameraController passing through the camera type, the name and the position.

So, why do we do it with XML?

Well, because if we want to add a new camera to our game,

by simply copying this line and modifying its parameters

and changing its name, we would be adding a new camera to our game.

So the XML will be very good to us because we will be able to modify our game's

behavior, simply modifying an external file to the game,

so we don't have to recompile the code,

we don't need to generate the EXE file again and we can do it externally.

A person who doesn't have programming knowledge

might do it through XML files.

Let's go on, the SphereVisible,

as we said before, simple tells us whether an object is visible or not,

depending on its container box, and does the same on its containing box.

The CameraController method gives back a camera counter based on its name,

the Update method updates the camera counter from which we've got the control

and it updates the camera depending on the camera counter we've got as vision

and it will update the camera Frustum. To update this camera frustum

we need the View and the camera projection. Finally we've got the Log method which

will be responsible for updating the cheated file.

Finally, to end with the cameras,

we've got the FPS cameras, which are a First Person Shooter,

a first person camera, and the spherical camera.

For the spherical cameras and the first person cameras we will calculate it

the following way: a camera will define the Yaw and the Pitch.

The Yaw would be on the XZ plane, this means, if this is the XZ

plane this one would be the Yaw angle.

It's basically where we are looking at, and the Pitch will define

on the Y plane if we are looking up to the sky or down to the ground.

In a character the Yaw would define if we are looking to the sides and the Pitch

if we are looking upward or downward, those would be the camera angles.

So for our camera controller we will have our position,

our Yaw angle and our Pitch angle.

So on an XZ plane we've got the eye,

which would be the position, this would be a FPS, the FPS camera and the LookAt.

This would

equal to the position plus the direction

multiplied by the distance, which might be 1, and this would be the LookAt.

So our camera

would be this one.

The camera direction would be the

Yaw cosine multiplied by

Pitch cosine, the Pitch sine is

the Yaw sine multiplied by the Pitch cosine.

This would be our camera vector director.

So in aim to calculate the eye and the LookAt we need to do this.

In a spherical camera the way to work is the opposite.

In a spherical camera we would have

a position, an eye,

and the LookAt, which would be equal to the position.

So our camera would be looking towards this position.

To calculate the eye, the LookAt

would equal to the position and the eye would equal to the position

minus the direction we've previously calculated.

This is a spherical camera. X multiplied by the zoom

is the distance

we want to look at regarding the object we are looking at.

This would be our spherical camera calculation.

Let's go on with the classes we've got in our game.

We've got the Player class, which in this first session

will only have the position and the FPS controller,

and this is what we will move, as we will see the camera controller depending on the update

we can move it towards the camera direction,

forward, backward or sideways, with the Move method.

So we've got the variables position, speed

in case we are using Shift, and then the

current vertical speed, and the vertical speed when we use the Jump key.

So if we go to the CPP we get the code,

we've got the Jump key,

it simply assigns the vertical speed to the value of the

Speed Yaw vertical variable to make it jump and then the Update menu,

which what does in the classical is, in case it doesn't,

it turns on the Library, modifies the camera Yaw

depending on the axis X movement, which is the mouse, as if we were looking from our left

to our right moving the mouse horizontally from one side to the other side and

on the other side, the vertical axis will move the Pitch up or down,

just as we would do with the view. Then we will check the key,

if the left, right, up, or down key are pressed,

which are the W, A, S, D keys, the classical FPS controllers.

W will move forward, S will move backward,

A will move left and D will move right.

We also have the L Forward or L Straight variables,

which have a positive or negative value.

So, if the keys are pressed in a determined way,

we call the Move method, which will be multiplied by the vector

forward or sideways depending on if the method is Straight or Forward.

The vector we said before forward will be the Yaw Cosine in X and

the Yaw Sine in Z and 0 in Y and the Strafe will be perpendicular to the front vector.

What it will do is move the angle forward 90 degrees,

180 divided by 2, which will move on the perpendicular

axis regarding to the camera Forward.

Then it updates the Vertical Speed depending on the gravity and in case

it is under 2 meters, so now we don't have any physics engine

we would leave it at 2 meters and the Vertical Speed in 0, and finally we update the

camera position depending on the position we've calculated multiplied

by the speed and by the time, this means: we calculate the position

depending the movement given by the linear motion formula.

The linear motion formula is (X)

position = (Xu) starter position + (V) speed x (T) time.

As we are working on 3 dimensions, the speed on the XZ axis, in the

XZ plane is a determined speed and on the vertical axis it is the speed modified

by the gravity and in the original position it is 3 dimensions,

which is 3 dimensions,

and this is a constant value called Elapsed Time.

So this is the formula with which we modify our

character's movement.

Explora nuestro catálogo

Inscríbete de manera gratuita y obtén recomendaciones personalizadas, actualizaciones y ofertas.

Coursera brinda acceso universal a la mejor educación del mundo, al asociarse con las mejores universidades y organizaciones, para ofrecer cursos en línea.

© 2019 Coursera Inc. Todos los derechos reservados.

Descargar en la App Store

Consíguelo en Google Play

Coursera
Acerca de
Liderazgo
Empleo
Catálogo
Certificados
Certificados MasterTrack™
Grados
For Enterprise
For Government

Comunidad
Learners
Partners
Developers
Beta Testers
Translators

Conectar
Blog
Facebook
LinkedIn
Twitter
Instagram
Youtube
Blog de Tecnología

Más
Términos
Privacidad
Ayuda
Accesibilidad
Prensa
Contacto
Directorio
Afiliados