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.
Introducción a un motor 3D (Parte V)
Loading...
Del curso dictado por Universitat Autònoma de Barcelona
Motores gráficos en videojuegos: game engine
85 calificaciones
Universitat Autònoma de Barcelona
85 calificaciones
Curso 4 de 6 en SpecializationDiseño y Creación de videojuegos
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.
Conoce a los instructores
Enric Martí GòdiaAssociate Professor
Computer Science
Jordi Arnal MontoyaCEO en Kaneda Games y Colaborador docente
Ciencias de la Computación (UAB)
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.
© 2018 Coursera Inc. Todos los derechos reservados.
