Speaker 1: Get in touch with technology with tech Stuff from how
Speaker 1: stuff Works dot com. Hey there, and welcome to tech Stuff.
Speaker 1: I'm your host, Jonathan Strickland. I'm an executive producer with
Speaker 1: How Stuff Works and I love all things tech. It's
Speaker 1: good to be back and listener ton Ky asked if
Speaker 1: I could do an episode all about game engines, and
Speaker 1: I said yes. So today we're going to learn all
Speaker 1: about game engines. What they do? You know, what are
Speaker 1: some of the big ones that are used in the business.
Speaker 1: But first things first, what the heck is a game engine? Well,
Speaker 1: a lot of this episode is going to focus on that,
Speaker 1: But here's the too long, didn't read version if you
Speaker 1: just want to get right down to it. It's a
Speaker 1: framework upon which you can build a video game. But
Speaker 1: that's doing a bit of a disservice to all the
Speaker 1: things that a game engine allows developers to do. And
Speaker 1: it's a complicated question to answer because there are a
Speaker 1: lot of different game engines out there. They go about
Speaker 1: doing what they do in different ways and to different extents.
Speaker 1: But I'm going to do my best to kind of
Speaker 1: take a high level view of this that is as
Speaker 1: applicable across the board as is possible. So when you
Speaker 1: think about a video game, everything that happens in that
Speaker 1: game is, ultimately, when you really boil it down, a
Speaker 1: math problem. Computers will take in input, they perform operations
Speaker 1: on that input according to some sort of program, essentially
Speaker 1: a set of directions or instructions, and then they produce output.
Speaker 1: So everything that happens within the context of a computer
Speaker 1: or video game is ultimately an expression of math as
Speaker 1: defined by code. Now, for more than a decade, every
Speaker 1: game that came out was essentially an ex ample of
Speaker 1: developers building this whole thing out from scratch. They might
Speaker 1: take some source code and make some changes in it
Speaker 1: to create a sequel to a popular game, but most
Speaker 1: games included new, unique code that was written in a
Speaker 1: new way to define the virtual world and how stuff
Speaker 1: happens within it, as well as how the program would
Speaker 1: execute the functions that made the game playable. It would
Speaker 1: just be written from scratch, over and over. But then
Speaker 1: came a little game called Doom in from its software,
Speaker 1: and its software released a press kit that's a doom
Speaker 1: would introduce a new paradigm in gaming with the quote
Speaker 1: unquote doom engine. John Carmack of it had come up
Speaker 1: with a new way to define and develop games, and
Speaker 1: it effectively split games into two general buckets of stuff.
Speaker 1: One bigucket of stuff was all about content. The other
Speaker 1: big bucket was the core functionality of the game itself.
Speaker 1: So let's start with the content bucket. It's the easier
Speaker 1: one to understand. That's where all the assets for the
Speaker 1: game would exist. Assets could include stuff like graphics, like
Speaker 1: all the different graphic models, what characters look like, what
Speaker 1: settings look like. It could also include AI, behaviors or physics.
Speaker 1: In fact, that it consists of just about all the
Speaker 1: elements the player would experience while playing the game, So
Speaker 1: you as the player, the stuff that you would experience,
Speaker 1: that you would see, that you would hear. Ultimately, those
Speaker 1: are all assets. So what the heck do I mean
Speaker 1: by core functionality and game engines? What's left for a
Speaker 1: game engine to do if all the content is in
Speaker 1: this other bucket. Well, the core functionality contains all the
Speaker 1: rules to make the stuff in the assets and the
Speaker 1: content bucket actually work within the context of the game.
Speaker 1: The game engine is a foundation you get. Think of
Speaker 1: it as a scaffold or a frame, has its own
Speaker 1: set of rules that the content has to adhere to
Speaker 1: in order to work within the context of a game.
Speaker 1: It is in effect a software development kit or s
Speaker 1: d K that allows the game developers to create the
Speaker 1: assets without having to code everything in advanced programming languages
Speaker 1: for the most part. So Michael Inger over at Giant
Speaker 1: Bomb created a pretty simple overview of a software and
Speaker 1: hardware stack to kind of show where a game engine
Speaker 1: fits in in the grand scheme of things. So, these
Speaker 1: are different layers of operations. Uh, they're not. It's not
Speaker 1: really physical layers, but it's a way to conceptualize this.
Speaker 1: So at the very top layer, the layer that would
Speaker 1: face the video game player, the part that that is
Speaker 1: outwardly facing to the world, you have the actual game.
Speaker 1: It's at the very top of this stack. For the
Speaker 1: purposes of this, we're going to make up a fictional game.
Speaker 1: I'm gonna call it tech Stuff Adventure for a princely sum.
Speaker 1: Under that layer, you then have the game engine. So
Speaker 1: the game sits on top of the game engine. The
Speaker 1: game engine supports the game. Beneath the game engine, you
Speaker 1: have what is called the application layer. This is sort
Speaker 1: of a communication channel. It allows the game engine to
Speaker 1: interoperate with a computer's operating system. That's the next layer down.
Speaker 1: So we're familiar with operating systems things like Windows, uh,
Speaker 1: mac os. Those are the user interfaces to interact with
Speaker 1: a computer. More directly below the operating system level is
Speaker 1: BIOS that's basic input output layer. This is sort of
Speaker 1: the firmware that allows the actual communication between the software
Speaker 1: and the hardware. Beneath BIO is the actual hardware, the
Speaker 1: actual circuitry that the computer runs on. Beneath that is
Speaker 1: the electricity that is powering everything. That is the different
Speaker 1: different cotrols and voltage that indicate whether it's a zero
Speaker 1: or a one essentially, and as Anger points out, game
Speaker 1: engines will sometimes communicate straight through to the BIOS layer.
Speaker 1: They skip the application and operating system layer and will
Speaker 1: interact directly with a bioslayer, And this helps maximize the
Speaker 1: efficiency of hardware usage. It means the game can take
Speaker 1: up more of the computer's assets and create a more
Speaker 1: immersive experience. Now, around the time that Doom launched, computer
Speaker 1: games were becoming pretty sophisticated. They were pushing hardware to
Speaker 1: the limits, and building a game from scratch was becoming
Speaker 1: a more daunting prospect. You know, way back in the day,
Speaker 1: a single person could create a triple A title game
Speaker 1: out of a garage using a simple computer. But by
Speaker 1: the time Doom was coming around, these games were becoming
Speaker 1: so sophisticated, so complicated that it required a team of
Speaker 1: developers working together to get it done in any reasonable
Speaker 1: amount of time, and developing a single game was taking
Speaker 1: longer and a lot more people than games from just
Speaker 1: a few years earlier. So game engines helped reduce the
Speaker 1: amount of time and efforts spent developing a game. For
Speaker 1: as long as the game engine remains relevant. Game engines
Speaker 1: can age into you know, obsolescence. You can get a
Speaker 1: game engine that no longer can take advantage of hardware
Speaker 1: to a point that makes it meaningful. But a lot
Speaker 1: of game engines are upgradeable, so we'll get into that
Speaker 1: a little bit more later now, to make matters more complicated.
Speaker 1: Around the same time when Doom was coming out, we
Speaker 1: started to see an incredible growth and expansion cards for computers,
Speaker 1: both for graphics cards and audio cards. If you listen
Speaker 1: to my in vidio episodes, you'll likely remember this was
Speaker 1: a time aime of competing standards in hardware and application
Speaker 1: programmer interfaces and developing a game for the PC started
Speaker 1: to get tough because these standards in hardware were changing
Speaker 1: so rapidly. You wanted your game to be as pretty
Speaker 1: and as as advanced as it possibly could be. You
Speaker 1: wanted to be at that leading edge, but the development
Speaker 1: cycle for a game might not match up with the
Speaker 1: advancement of hardware. You know, you might be working on
Speaker 1: a game on one standard of hardware, and while you're
Speaker 1: working on the game, the hardware is you know, upgraded,
Speaker 1: and you're still working on the older version. So it
Speaker 1: was really challenging. The big difference here for PCs versus
Speaker 1: consoles is that you didn't have to worry about this
Speaker 1: with consoles. Consoles are different. A console's hardware remains consistent.
Speaker 1: Typically you might get a new version of that console
Speaker 1: that has beefier specs, but consoles tend to be locked down.
Speaker 1: You don't expand them with new hardware, so there's not
Speaker 1: really any worry about that. You can develop a game
Speaker 1: for that specific hardware specification and be reasonably sure that's
Speaker 1: going to apply across the entire spectrum, so you don't
Speaker 1: have to worry about this fast development cycle of expansion cards.
Speaker 1: Now there are many different types of game engines, and
Speaker 1: thus there are different approaches to building out a framework.
Speaker 1: It's kind of like programming languages. A programming language is
Speaker 1: purpose is to give a person, you know, the programmer,
Speaker 1: the ability to create a set of instructions for a
Speaker 1: computer to follow. But computers understand machine code, and that
Speaker 1: tends to me very hard for humans to work with.
Speaker 1: It's not intuitive, it's easy to lose your place. Humans
Speaker 1: do much better with more abstract languages that can be
Speaker 1: converted into machine code for computers to follow those instructions.
Speaker 1: So the language the humans use and lang which the
Speaker 1: computers use are different. They require an interpreter between them.
Speaker 1: Game engines are kind of like the same thing, except
Speaker 1: they go one step further out from programming languages to
Speaker 1: create a platform upon which game developers can build out
Speaker 1: their games. Harold Serrano wrote a great overview of game
Speaker 1: engines and breaks them down into three smaller entities. At
Speaker 1: the top is why he calls a math engine that
Speaker 1: handles all the operations that the rest of the game
Speaker 1: relies upon, and that sends those instructions to the computer.
Speaker 1: It's the heart of the game engine. It contains the
Speaker 1: rules for all those operations, whether they be vector operations
Speaker 1: such as addition and subtraction, or matrix operations like transforms
Speaker 1: or transpositions. Then Serrano writes, you have the two engines
Speaker 1: that this math engine feeds into, and those would be
Speaker 1: the rendering engine and the physics engine. And we'll start
Speaker 1: by talking about the renderer or rendering engine. And for
Speaker 1: a lot of this I'm relying up Bond The Incredible
Speaker 1: an exhaustive series of articles on Extreme Tech about the
Speaker 1: anatomy of a game engine. It's an eleven part series.
Speaker 1: They were written by a game designer named Jake Simpson.
Speaker 1: Uh the articles came out in two thousand two, so
Speaker 1: they're a little dated, but the general principles remain sound.
Speaker 1: So if at the end of this episode you still
Speaker 1: want to learn a lot more about game engines, and
Speaker 1: I mean a lot more, go check out that series
Speaker 1: of articles over at Extreme Tech, because Jake Simpson wrote
Speaker 1: about twenty six thousand words on the subject. It's an
Speaker 1: incredible account. Anyway, the renderer's job is to produce the
Speaker 1: visualizations of data so that there's something for the player
Speaker 1: to look at. It is creating the visuals on the screen.
Speaker 1: According to the current state of the game, and it
Speaker 1: does this rapidly, multiple times a second, and in reaction
Speaker 1: to the inputs it receives. So in the first person shooter,
Speaker 1: that can include changing the angle of view as a
Speaker 1: player turns the character to the left or to the right,
Speaker 1: as well as the way that graphics are changing as
Speaker 1: enemies are moving closer or further away, or they're moving
Speaker 1: behind cover. All of these things affect what the renderer
Speaker 1: has to create for us to see. Now, you don't
Speaker 1: actually build those elements in the renderer. You would use
Speaker 1: a different tool to build all of these graphic models themselves.
Speaker 1: You might use something like Maya or Blender, and that's
Speaker 1: where you would design all of these graphic elements. The
Speaker 1: game engines renderer is in charge of taking those assets
Speaker 1: and displaying them in the appropriate way on the screen
Speaker 1: so that they are in the right location, at the
Speaker 1: right size, at the right orientation, with the right lighting effects,
Speaker 1: the right texture effects. All of those things have to
Speaker 1: be just right based upon the moment you are seeing
Speaker 1: them in the game, and the game engine handles those rules. Now,
Speaker 1: there's more important stuff about things like light effects and
Speaker 1: textures that I need to get into. But first let's
Speaker 1: take a quick break and thank our sponsor. Now, the
Speaker 1: rendering engine creates a really big demand on computer processors
Speaker 1: in general. Back in the day we're talking, it could
Speaker 1: represent or more of all the CPUs processing time on
Speaker 1: a game. And with the invention of graphics processing units
Speaker 1: or GPUs as we've called them, building a renderer requires
Speaker 1: an extensive understanding of hardware and three dimensional math. Virtual
Speaker 1: three dimensional objects exists as a series of points in
Speaker 1: virtual space, so you can kind of think of as
Speaker 1: connect the dots, except it's connect the dots in three dimensions,
Speaker 1: not just in two, and the dot are points called vertices.
Speaker 1: Programmers create models that define the relationship between vertices so
Speaker 1: that the computer knows how far apart any two given
Speaker 1: vertices are from each other. So, for example, let's say
Speaker 1: you're building a pyramid, just a static pyramid in virtual space.
Speaker 1: A pyramid has four sides, and the computer would have
Speaker 1: to understand how far apart the different points of the
Speaker 1: pyramid are from each other. From the tippy top of
Speaker 1: the pyramid to the four points along the base of
Speaker 1: the pyramid, they would all have a certain distance from
Speaker 1: one another that would remain the same no matter what
Speaker 1: orientation you put that pyramid in because the pyramid is
Speaker 1: a static object. It's not flippy filippy. So uh, the
Speaker 1: game engine understands that that virtual object has four faces,
Speaker 1: three that face outward and one that would face downward,
Speaker 1: and complex shapes and video games are made up of
Speaker 1: things like this, like surfaces like this, except they're made
Speaker 1: up of thousands or hundreds of thousands of polygons. Now
Speaker 1: you can imagine that the game sends instructions to the
Speaker 1: renderer to display the appropriate graphics at the appropriate angles,
Speaker 1: with the appropriate orientations, with regard to each other. The
Speaker 1: game doesn't have to understand how the renderer does this.
Speaker 1: It's just saying something like, I need you to show
Speaker 1: this tree over here, a mountain over there, and I
Speaker 1: don't know a rabbit, wear rabbit over in this direction,
Speaker 1: and the renderer follows the set of rules to display
Speaker 1: those things so that they appear correctly within the context
Speaker 1: of a player's point of view, so that the rabbit
Speaker 1: doesn't appear to be larger than the mountain, for example. Now,
Speaker 1: one thing a rendering engine can do to manage this
Speaker 1: massive amount of data that it has to handle is
Speaker 1: a process that's called culling. Culling involves eliminating the need
Speaker 1: to calculate the math that represents stuff you cannot see
Speaker 1: from your perspective. So here's some examples. If there are
Speaker 1: objects that are very very far away from you, so
Speaker 1: they are beyond where your vision could detect them, that's
Speaker 1: not going to be represented, so that math can be dropped.
Speaker 1: There's no need to worry about it because you can't
Speaker 1: see it anyway. A lot of games will introduce fog
Speaker 1: for this purpose, and you'll have fog that cuts off
Speaker 1: your vision at a certain distance, and that way the
Speaker 1: rendering engine doesn't have to draw progressively smaller and smaller
Speaker 1: landmarks off into the distance. Then there's also things like occlusion.
Speaker 1: This is when you have one object blocking some or
Speaker 1: all of another object. So, for example, let's say you're
Speaker 1: playing a fantasy game. You're playing an Elder Scrolls game.
Speaker 1: Let's say, and you're looking at a forest uh in
Speaker 1: a mountain range, and you see a frost troll and
Speaker 1: the frost trols lurking behind the rocks. You can only
Speaker 1: see part of the frost trol. Well, some of that
Speaker 1: frost trol obviously is obscured by the scenery. So rather
Speaker 1: than calculate all the information that represents that frost trol
Speaker 1: in its entirety, the culling process would remove any of
Speaker 1: the bits that would be out of your view due
Speaker 1: to the rock. It would say, oh, we don't need
Speaker 1: to calculate this stuff because the player can't see it,
Speaker 1: so we're just gonna leave that out. We'll just include
Speaker 1: the stuff that the player can see based upon their
Speaker 1: angle of view. The rendering engine is only concerned with
Speaker 1: the bits you can actually see, which is in a
Speaker 1: way kind of like lossy audio compression formats like MP
Speaker 1: three you remember, I've talked about that in the past,
Speaker 1: where MP three files. One of the reasons they are
Speaker 1: so much smaller than raw audio files is that they
Speaker 1: eliminate all the sounds that are, at least in theory,
Speaker 1: outside the range of human hearing. Because if it's outside
Speaker 1: the range of human hearing, if we cannot perceive it,
Speaker 1: there's no need to preserve that information, at least in theory.
Speaker 1: Rendering also sets the rules for how graphics will pop
Speaker 1: into view. So, for example, translucent surfaces things that you
Speaker 1: can see through have to render in after the opaque surfaces,
Speaker 1: and that way you can see through the translucent ones properly.
Speaker 1: So let's say you're looking through Let's say it's a waterfall.
Speaker 1: It's a very thin waterfall, and you can see through
Speaker 1: it to the other side. Well, the other side would
Speaker 1: have to render in first, and then the waterfall would
Speaker 1: render in. Uh. And so you can think of it
Speaker 1: as a sequence that goes back to front, the further
Speaker 1: away from you, the back surfaces that should come in first,
Speaker 1: and then the surfaces ahead of time. So maybe there's
Speaker 1: a lighting uh see, a lighting source that's between the
Speaker 1: waterfall and whatever is behind it that would look come
Speaker 1: in next, and then the waterfall would come in last.
Speaker 1: But this all happens, or at least it should happen
Speaker 1: very very very quickly. So preferably it's fast enough where
Speaker 1: you even be noticeable. It would all just seem to
Speaker 1: appear at the same time. That's not always the case.
Speaker 1: If you're playing a very advanced game on high settings,
Speaker 1: on hardware that can't quite handle it, you'll run into
Speaker 1: problems when this stuff starts to try and kick in.
Speaker 1: The rendering engine also has to take other factors into account.
Speaker 1: The game will send information about textures, and the renderer
Speaker 1: has to apply those textures to the various polygons in
Speaker 1: the view. So otherwise, if you didn't have textures, you
Speaker 1: would just end up with a messy wire frame universe.
Speaker 1: It would be very hard to be able to make
Speaker 1: heads or tails out of anything, especially for very complicated
Speaker 1: graphics heavy games. It would just be these sets of
Speaker 1: lines and polygons and you wouldn't be able to tell
Speaker 1: what is what. After the renderer UH has to calculate
Speaker 1: the textures, it then has to figure out how bright
Speaker 1: each surface should be given the light sources in the area.
Speaker 1: It has to apply logic to the lighting. So if
Speaker 1: you have a torch on a wall and you have
Speaker 1: an object that would be partly illuminated by this torch,
Speaker 1: some parts of the surface of that object should be
Speaker 1: brighter than others, and the game engine is responsible for
Speaker 1: applying this logic in a way that makes sense based
Speaker 1: upon where the light sources are in your area. So
Speaker 1: if you're in a dark corridor aboard a defunct space station,
Speaker 1: the sparse light sources will highlight some surfaces will leave
Speaker 1: others in shadow, and the renderer has to take into
Speaker 1: account all of this when drawing out the scene. It
Speaker 1: also has to do some collision detection as well, although
Speaker 1: that will come into play also with physics and AI.
Speaker 1: But collision detection is when you have two virtual elements
Speaker 1: that would come into contact with one another within the
Speaker 1: virtual environment. So in the real world, if you had
Speaker 1: real things, they would hit each other. Well, these are
Speaker 1: virtual objects. They don't they don't have any actual mass.
Speaker 1: But with good collision detection, virtual elements will appear to
Speaker 1: move naturally with hard to each other, and they'll appear
Speaker 1: to have this contact and the reaction to that contact,
Speaker 1: and they won't just pass through. Otherwise it would be
Speaker 1: like you're phasing through solid objects, and that kind of
Speaker 1: breaks the immersion of a video game if that was
Speaker 1: not intended. If you want to learn way more about lighting,
Speaker 1: I recommend reading the Anatomy of a Game Engine articles
Speaker 1: I mentioned already by Jake Simpson, because he goes into
Speaker 1: a lot more detail over the various approaches to lighting.
Speaker 1: I'm grouping them all in a general category, but there
Speaker 1: are several different methods to going about lighting scenes in games,
Speaker 1: and Simpson goes through them and and much more detail
Speaker 1: than I will hear. I don't want to do a
Speaker 1: fifteen episode series about game engines. It is fascinating, but
Speaker 1: it goes further in the weeds than I think we
Speaker 1: need to for this episode. Will just allow that the
Speaker 1: rendering engine has to take all these different factors into
Speaker 1: account to display the assets of the game properly for
Speaker 1: the player. Now, one really interesting thing about rendering engines
Speaker 1: is that if you design it properly, you can make
Speaker 1: it really modular within the larger game engine itself. Remember,
Speaker 1: the rendering engine is just one component of the game engine.
Speaker 1: Now that means you could overhaul the rendering engine for
Speaker 1: future games, you get more advanced ways of creating, uh
Speaker 1: the graphics. Maybe there are new effects that you can apply. Well,
Speaker 1: you can actually create a new rendering engine and disconnect
Speaker 1: the old one from your game engine, plug the new
Speaker 1: one in, and it should work with all the other
Speaker 1: components seamlessly. If you actually built your game engine in
Speaker 1: that way, you have to actually have built it this way,
Speaker 1: but it's possible. You can make this where the rendering
Speaker 1: engine is sort of a plug in play approach. It's
Speaker 1: a little more complicated than that, but that's the concept.
Speaker 1: It's way easier said than done, but it's one of
Speaker 1: the ways legacy game jids have stuck around for so long.
Speaker 1: It's not that people perfected the game engine a decade ago.
Speaker 1: It's that the game engines elements can evolve over time
Speaker 1: and plug back into the overall engine itself to give
Speaker 1: it more usefulness. Now there's a lot more to talk
Speaker 1: about when it comes to rendering images, and some of
Speaker 1: the stuff I'm going to mention in the next section
Speaker 1: will come back to touch on rendering. But rendering as
Speaker 1: fascinating as it is and as advanced as it gets
Speaker 1: with all the different particle effects and lighting effects and
Speaker 1: texture mapping and all that is only part of the
Speaker 1: game engine. We still have a lot more to talk about,
Speaker 1: which I'll get to right after we take this break
Speaker 1: to thank our sponsor. The game engine can also play
Speaker 1: a really important role in sending audio information to computer hardware. Now, again,
Speaker 1: the audio itself, that's those are assets, But the game
Speaker 1: engine determines how the audio plays out within the context
Speaker 1: of the game, and it might send information out to
Speaker 1: a dedicated sound card, or these days it might be
Speaker 1: through an integrated audio that's already on the motherboard and
Speaker 1: then directly onto speakers or headphones. Back when I got
Speaker 1: fed up with PC gaming in the nineties, and that
Speaker 1: was because there were these different graphics and sound cards.
Speaker 1: They're all battling for supremacy, and getting one set of
Speaker 1: sound cards or graphics cards could mean missing out on
Speaker 1: some games that don't support those formats, or getting a
Speaker 1: less enjoyable experience because you have to emulate something else.
Speaker 1: And now I'll have to do a whole episode on
Speaker 1: the history of sound cards at some point, because it's
Speaker 1: also really interesting history. But the important thing to remember
Speaker 1: now is that since or So Intel, what they came
Speaker 1: out with the a C audio CODAC back that made
Speaker 1: it possible for hardware manufacturers to include an integrated chip
Speaker 1: on the motherboard that could emulate a sound Blaster sixteen
Speaker 1: audio card. And since then we've seen advances in integrated audio,
Speaker 1: which has reduced the necessity to have an additional sound
Speaker 1: card installed on your computer. Back in the day, if
Speaker 1: you wanted to have really good sound, you had to
Speaker 1: buy a sound card because the IBM and IBM compatible
Speaker 1: computers only had a speaker that could create just simple tones,
Speaker 1: one tone at a time, and there was no variation
Speaker 1: in volume. So if you wanted any more complexity or sophistication,
Speaker 1: you had to get a standalone sound card. That's not
Speaker 1: the case today now we have these integrated audio features.
Speaker 1: Some gamers argue that you still want to have a
Speaker 1: standalone sound card to really get the fidelity necessary for
Speaker 1: a really good gaming experience. Also, they tend to be
Speaker 1: better if you want to use voice while you're playing
Speaker 1: UM and you want your voice to sound good. Sometimes
Speaker 1: that means getting your own independent sound card with your computer,
Speaker 1: But more and more gamers these days seem to rely
Speaker 1: more heavily on just the uh integrated audio that's on motherboards.
Speaker 1: The reason I bring this up at all is because
Speaker 1: if you read the articles by Jake Simpson, they go
Speaker 1: into some detail about sending audio to computer hardware. That's
Speaker 1: a little bit dated because again those articles came out
Speaker 1: in two thousand two, but game engines still have to
Speaker 1: be able to set rules for all of those sound
Speaker 1: elements today. So, for example, let's say you're playing a
Speaker 1: stealth based game, and audio is really important to this
Speaker 1: kind of gameplay. You're playing a character that's trying to
Speaker 1: stay out of view, You're sneaking around. You need to
Speaker 1: be able to hear where other characters, monsters whatever it
Speaker 1: may be, are in relation to your location so that
Speaker 1: you don't give away your presence, and the quality of
Speaker 1: audio you here should depend on lots of other factors,
Speaker 1: such as is the other character Let's say, are they
Speaker 1: in the same space that you are in are then
Speaker 1: are they in the same room? Are they in a
Speaker 1: room next door? Is there a wall or door between you?
Speaker 1: Because if there is, that should maybe muffle the sound
Speaker 1: a bit. You shouldn't hear a person who's in a
Speaker 1: room over and there's a big wooden door between you.
Speaker 1: You shouldn't be able to hear them as if they're
Speaker 1: standing right next to you talking clear as day. You
Speaker 1: should hear a muffled sound. Maybe you can't even quite
Speaker 1: make out what's being said. Or let's say that you
Speaker 1: are sneaking around in an area that's got water and
Speaker 1: you're you're you're going under the water. The sound should
Speaker 1: be different when you're underwater. You should have that that
Speaker 1: kind of muffled effect. Again, you wouldn't expect it to
Speaker 1: sound like someone's right there next to you. You might
Speaker 1: want to have effects like echo involved or reverb, something
Speaker 1: like that. The game engine can apply those effects to
Speaker 1: the same audio assets based upon the actual uh context
Speaker 1: of the game at that moment. So if you're playing
Speaker 1: one way, Let's say you're playing the exact same level,
Speaker 1: but you're playing it in two very different ways, and
Speaker 1: in one way, you're sneaking underground underneath a surface where
Speaker 1: people are walking around, you would hear things differently than
Speaker 1: if you played it a second way and you're sneaking
Speaker 1: through that room where you're actually going into the room
Speaker 1: where other people are, you would be able to hear
Speaker 1: things much more differently. And the game engine should be
Speaker 1: able to interpret that information and present it properly because
Speaker 1: it's applying the rules based upon its understanding of where
Speaker 1: the player is in relation to the other assets in
Speaker 1: the game. Some game engines allow developers to import a
Speaker 1: map into the game engine itself, and then the engine
Speaker 1: will overlay what is essentially a sound map on top
Speaker 1: of the physical map of the game level. The sound
Speaker 1: map indicates which effects should apply to sounds in various
Speaker 1: spots depending upon player location, and that can include areas
Speaker 1: where the nature of sound will change as the player
Speaker 1: character moves through an environment, so you get dynamics. In
Speaker 1: other words, you might be jumping off the side of
Speaker 1: a cliff and you hear someone yelling after you, and
Speaker 1: their voice might change as you're falling away and change
Speaker 1: even more. Let's say you plunge into a lake and
Speaker 1: it changes even more when you go under water. That
Speaker 1: stuff is possible because of the logic the game engines
Speaker 1: used to manipulate these assets. A game engine also typically
Speaker 1: includes instructions The game needs to accept inputs from control
Speaker 1: mechanisms so that the player can actually take control of
Speaker 1: whatever it is they're playing in the game. That can
Speaker 1: include stuff like a joystick, or a mouse and keyboard,
Speaker 1: or a game pad, a steering wheel, those sort of
Speaker 1: peripheral devices. The two main methods of handling input are
Speaker 1: called events and polling. So with the events approach, the
Speaker 1: game engine text incoming input signals like if you hit
Speaker 1: a button on a game pad or you pull a
Speaker 1: trigger on a joystick. That incoming signal then activates a
Speaker 1: custom code that is mapped to that input. So the
Speaker 1: custom code might say every time the player pulls the
Speaker 1: trigger on a joystick, it's mapped with a command for
Speaker 1: fire the main weapon. The polling is used to monitor
Speaker 1: position values, like the position of a joystick, whether it's
Speaker 1: in neutral position where it's centered, or it is being
Speaker 1: pushed forward or pulled back or moved from one side
Speaker 1: to the other, or the same thing for the position
Speaker 1: of a thumbstick or for the relative x y position
Speaker 1: of a mouse. As you move these different devices around,
Speaker 1: that changes that positional value associated with that device, and
Speaker 1: again that gets mapped to an appropriate action within the game,
Speaker 1: such as your character turns or moves forward or backward
Speaker 1: or whatever it might be. One of the biggest challenges
Speaker 1: of modern games is online play. It pretty much a
Speaker 1: standard for most games these days, and in fact, more
Speaker 1: and more games are acquiring a persistent online connection to
Speaker 1: even play them at all, even if it's just a
Speaker 1: single player game. But incorporating online elements introduces a ton
Speaker 1: of other problems that would be show stoppers if programmers
Speaker 1: had to solve for them manually with every single game. So,
Speaker 1: for example, uh, well, the nature of traffic across the
Speaker 1: Internet by itself creates tons of potential problems from latency,
Speaker 1: which is the lag between when you send a command
Speaker 1: and when it gets executed, two dropped packets which can
Speaker 1: create errors. So when you think about it, it's actually
Speaker 1: pretty amazing that we can have online simultaneous play between
Speaker 1: multiple players within the same game. If you're in a
Speaker 1: multiplayer game, let's say you're playing something like Overwatch, for example,
Speaker 1: every character you see on screen represents another human player
Speaker 1: playing that game somewhere else in the world, but your
Speaker 1: instance of the video game, the game you see on
Speaker 1: your system, has to create the image and make sure
Speaker 1: it reflects the proper position and orientation of every other
Speaker 1: player's character. So if I'm facing down Reaper and Overwatch
Speaker 1: and Reaper's back is to me, Reaper should not be
Speaker 1: able to shoot me. I should be confident that the
Speaker 1: player controlling Reaper can't see me because the character has
Speaker 1: turned away from me. But this requires my instance of
Speaker 1: the game to render Reaper accurately, even with those challenges
Speaker 1: I mentioned earlier. For that reason, game engines tend to
Speaker 1: have components that handle the online communication aspects of a game,
Speaker 1: so that game developers can focus on creating the assets
Speaker 1: that make the game special in the first place, but
Speaker 1: not worry about handling all that Internet communications nonsense. Artificial
Speaker 1: intelligence is another component that can be incorporated partly into
Speaker 1: a game engine. Typically this would involve using a third
Speaker 1: party path finding solution. I'd go into more detail on
Speaker 1: this one, but I'm running along, and also it starts
Speaker 1: to get over my head pretty darn quickly, if I'm
Speaker 1: being honest. But one interesting example I want to point
Speaker 1: out of how AI can go awry and how pathfinding
Speaker 1: can become a problem is a game that came out
Speaker 1: in two thousand and thirteen. It's called Aliens Colonial Marines.
Speaker 1: A lot of you may have heard of this game.
Speaker 1: When it came out, critics and gamers alike complained that
Speaker 1: the game was buggy and that the enemies would behave
Speaker 1: in really weird ways. They get stuck in levels, they
Speaker 1: would all just not behave in a very strategic manner.
Speaker 1: They would just kind of rush at the player and
Speaker 1: a mode. While exploring the game's code, discovered that in
Speaker 1: one of the initialization files for the game, there was
Speaker 1: a typo. There was a line of code that was
Speaker 1: meant to attach AI components to a specific points on
Speaker 1: a map. They called it tethering, and it would give
Speaker 1: the AI the ability to behave in a tactical way
Speaker 1: within certain sectors or tethers of a level. But in
Speaker 1: this line of code, the word tether t E t
Speaker 1: h E R had a superfluous A. In it, it
Speaker 1: was spelled as t e A t h e R,
Speaker 1: almost like heather, and that was a typo. Removing the
Speaker 1: A using just a regular editor program and then executing
Speaker 1: the game again created an experience more like what the
Speaker 1: developers had intended, with AI suddenly becoming more of a
Speaker 1: threat to the player being able to behave in a
Speaker 1: more strategic way. It didn't solve all the problems that
Speaker 1: game had, but it definitely solved a big one. So
Speaker 1: the game engine in this case was performing properly the
Speaker 1: whole time. It was just because there was a typo
Speaker 1: in the code that was being executed in the game
Speaker 1: engine that the problem was happening at all. Then we
Speaker 1: finally have a physics engines. These are components that determine
Speaker 1: the physical rules within the virtual world. So, if you're
Speaker 1: talking about a first person shooter, if you drop a weapon,
Speaker 1: does it fall to the ground? If so, how fast?
Speaker 1: How strong is gravity? Does it float away? How far
Speaker 1: can you jump? How fast can you run? How far
Speaker 1: can you fall without taking any damage? If you knock
Speaker 1: out an opponent, does the opponent disappear? Do they flop
Speaker 1: realistically like a rag doll? Does have the rag Doll
Speaker 1: physics that became really popular ballad decade ago and are
Speaker 1: still popular today. These sorts of things and more, including
Speaker 1: how effects behave in different environments, all depend upon the
Speaker 1: physics engine, and this is also the main part of
Speaker 1: the engine that determines things like collision detection and what
Speaker 1: happens if two virtual objects actually make contact within the game,
Speaker 1: or how a solid stiff object moves through a space
Speaker 1: as opposed to a more Bindi floppy object. So there
Speaker 1: are a lot of off the shelf physics engines out
Speaker 1: there that you can plug into a game engine, just
Speaker 1: as there are off the shelf tools for building in
Speaker 1: game models. UH. The physics engines have names like Havoc,
Speaker 1: which started out as a physics engine component from an
Speaker 1: Irish company. Now it's owned by Microsoft. UH. There's other ones.
Speaker 1: There's like Newton Game Dynamics that's an open source physics engine,
Speaker 1: but there there's several out there on the market. Physics
Speaker 1: engines use lots of different techniques to create or simulate
Speaker 1: real world physics in a virtual world, and just like
Speaker 1: game engines, there's not just a single way to achieve
Speaker 1: this goal. There are lots of different approaches, but they
Speaker 1: all try to do the same thing, they just try
Speaker 1: to do it in different ways. And there's so much
Speaker 1: more I could go into, like the graphic user interface
Speaker 1: design for the game or the scripting process for developers
Speaker 1: where outcomes will occur when certain triggers are hit. But
Speaker 1: you get the idea. I think the game engine is
Speaker 1: the facilitator that ultimately translates the content that developers have
Speaker 1: created into meaningful information for a computer system, so that
Speaker 1: the right stuff off happens at the right time, at
Speaker 1: least ideally. Sometimes just bad code makes bad things happen.
Speaker 1: And there are a lot of different game engines out
Speaker 1: there in the wild. Here are a few notable ones.
Speaker 1: I opened the show talking about Doom. While the ID
Speaker 1: Tech game engine is still being used largely by independent
Speaker 1: game developers, but others as well. The Unreal Engine is
Speaker 1: one of the most famous game engines out there. It
Speaker 1: was created by Epic Games. It's named after the Unreal
Speaker 1: Tournament series of shooter games, but it's been used for
Speaker 1: tons of other games to including stuff like Gears of
Speaker 1: War and Mass Effect. Unity three D is another big
Speaker 1: game engine that one's from Unity Technologies. It's used by
Speaker 1: a lot of independent and mobile games. The Cry engine
Speaker 1: was developed by cry Tech for games like far Cry
Speaker 1: e A Dice uses a game engine called frost Bite
Speaker 1: as the foundation for games like Battlefield. Other developers have
Speaker 1: their own proprietary game engines. For example, rock Star, which
Speaker 1: makes the Grand Theft Auto and Red Dead Redemption series,
Speaker 1: uses the rock Star Advanced Game Engine or RAGE to
Speaker 1: power its games. Insomniac Games created a special game engine
Speaker 1: for their title Sunset Overdrive, and then used a modified
Speaker 1: version of that game engine for the recent Spider Man
Speaker 1: game for the PS four. Now. Ultimately, these game engines
Speaker 1: create an environment so that developers can focus on those
Speaker 1: elements that define a game without having to fuss over
Speaker 1: the minute mathematical details. The game engine handles all of that.
Speaker 1: So I hope that is a good overview of what
Speaker 1: game engines are and how they work from uh, from
Speaker 1: a a basic standpoint. Obviously, getting deep into it would
Speaker 1: require a whole series of episodes getting very technical and
Speaker 1: very specific, because again, different game engines do this in
Speaker 1: different ways. But it is a fascinating topic and hopefully
Speaker 1: that lets you know a little bit more about what
Speaker 1: it means when someone talks about a game engine and
Speaker 1: what it does, and whether it's a good game engine
Speaker 1: or a bad game engine. You understand a little bit
Speaker 1: more of where that's coming from. If you guys have
Speaker 1: any suggestions for future episodes of tech Stuff, maybe it's
Speaker 1: a technology, a company, person in tech. Maybe there's someone
Speaker 1: I should interview or have on as a guest. Let
Speaker 1: me know, send me your suggestions. The email address for
Speaker 1: the show is tech Stuff at how stuff works dot com,
Speaker 1: or drop me a line on Facebook or Twitter. The
Speaker 1: handle of both of those for the show is text
Speaker 1: stuff H s W. Don't forget. You can go over
Speaker 1: to T public dot com slash tech stuff. That's T
Speaker 1: E E public dot com slash tech Stuff. That's where
Speaker 1: we have all of our merch. You guys really like
Speaker 1: the code like a girl T shirts and so do I.
Speaker 1: I love that one. But we have tons of other
Speaker 1: stuff on there, including our tech Stuff capture shirt, prove
Speaker 1: that You're not a robot and more. So go check
Speaker 1: those out and follow us on Instagram and uh yes,
Speaker 1: that's it. I'm done. I'll talk to you again really
Speaker 1: soon for more on this and thousands of other topics.
Speaker 1: Is it how stuff Works dot com