WEBVTT - How Game Engines Work 0:00:04.120 --> 0:00:07.160 Get in touch with technology with tech Stuff from how 0:00:07.200 --> 0:00:13.800 stuff Works dot com. Hey there, and welcome to tech Stuff. 0:00:13.840 --> 0:00:16.439 I'm your host, Jonathan Strickland. I'm an executive producer with 0:00:16.480 --> 0:00:19.919 How Stuff Works and I love all things tech. It's 0:00:19.960 --> 0:00:23.599 good to be back and listener ton Ky asked if 0:00:23.640 --> 0:00:27.800 I could do an episode all about game engines, and 0:00:28.000 --> 0:00:31.480 I said yes. So today we're going to learn all 0:00:31.520 --> 0:00:34.879 about game engines. What they do? You know, what are 0:00:34.960 --> 0:00:37.120 some of the big ones that are used in the business. 0:00:37.400 --> 0:00:41.680 But first things first, what the heck is a game engine? Well, 0:00:41.760 --> 0:00:43.800 a lot of this episode is going to focus on that, 0:00:44.200 --> 0:00:47.559 But here's the too long, didn't read version if you 0:00:47.680 --> 0:00:50.319 just want to get right down to it. It's a 0:00:50.400 --> 0:00:55.120 framework upon which you can build a video game. But 0:00:55.200 --> 0:00:57.639 that's doing a bit of a disservice to all the 0:00:57.640 --> 0:01:01.160 things that a game engine allows developers to do. And 0:01:01.640 --> 0:01:05.880 it's a complicated question to answer because there are a 0:01:05.920 --> 0:01:08.360 lot of different game engines out there. They go about 0:01:08.440 --> 0:01:12.240 doing what they do in different ways and to different extents. 0:01:12.280 --> 0:01:14.360 But I'm going to do my best to kind of 0:01:14.360 --> 0:01:18.800 take a high level view of this that is as 0:01:18.840 --> 0:01:23.120 applicable across the board as is possible. So when you 0:01:23.160 --> 0:01:26.240 think about a video game, everything that happens in that 0:01:26.319 --> 0:01:30.880 game is, ultimately, when you really boil it down, a 0:01:30.920 --> 0:01:35.880 math problem. Computers will take in input, they perform operations 0:01:36.080 --> 0:01:39.960 on that input according to some sort of program, essentially 0:01:40.040 --> 0:01:44.640 a set of directions or instructions, and then they produce output. 0:01:45.360 --> 0:01:48.280 So everything that happens within the context of a computer 0:01:48.600 --> 0:01:53.000 or video game is ultimately an expression of math as 0:01:53.040 --> 0:01:57.480 defined by code. Now, for more than a decade, every 0:01:57.560 --> 0:02:00.920 game that came out was essentially an ex ample of 0:02:01.000 --> 0:02:05.400 developers building this whole thing out from scratch. They might 0:02:05.480 --> 0:02:08.960 take some source code and make some changes in it 0:02:09.040 --> 0:02:11.560 to create a sequel to a popular game, but most 0:02:11.639 --> 0:02:15.680 games included new, unique code that was written in a 0:02:15.720 --> 0:02:18.960 new way to define the virtual world and how stuff 0:02:19.000 --> 0:02:21.919 happens within it, as well as how the program would 0:02:21.919 --> 0:02:25.359 execute the functions that made the game playable. It would 0:02:25.400 --> 0:02:29.760 just be written from scratch, over and over. But then 0:02:30.680 --> 0:02:35.520 came a little game called Doom in from its software, 0:02:35.919 --> 0:02:39.680 and its software released a press kit that's a doom 0:02:39.800 --> 0:02:43.600 would introduce a new paradigm in gaming with the quote 0:02:43.680 --> 0:02:48.720 unquote doom engine. John Carmack of it had come up 0:02:48.760 --> 0:02:52.560 with a new way to define and develop games, and 0:02:52.560 --> 0:02:58.720 it effectively split games into two general buckets of stuff. 0:02:59.320 --> 0:03:03.760 One bigucket of stuff was all about content. The other 0:03:03.800 --> 0:03:07.880 big bucket was the core functionality of the game itself. 0:03:08.240 --> 0:03:11.239 So let's start with the content bucket. It's the easier 0:03:11.280 --> 0:03:14.240 one to understand. That's where all the assets for the 0:03:14.280 --> 0:03:18.520 game would exist. Assets could include stuff like graphics, like 0:03:18.600 --> 0:03:21.960 all the different graphic models, what characters look like, what 0:03:22.120 --> 0:03:27.200 settings look like. It could also include AI, behaviors or physics. 0:03:27.760 --> 0:03:29.720 In fact, that it consists of just about all the 0:03:29.760 --> 0:03:32.760 elements the player would experience while playing the game, So 0:03:32.840 --> 0:03:36.720 you as the player, the stuff that you would experience, 0:03:36.800 --> 0:03:41.280 that you would see, that you would hear. Ultimately, those 0:03:41.280 --> 0:03:44.240 are all assets. So what the heck do I mean 0:03:44.280 --> 0:03:47.240 by core functionality and game engines? What's left for a 0:03:47.280 --> 0:03:50.800 game engine to do if all the content is in 0:03:50.840 --> 0:03:53.960 this other bucket. Well, the core functionality contains all the 0:03:54.040 --> 0:03:56.400 rules to make the stuff in the assets and the 0:03:56.480 --> 0:03:59.920 content bucket actually work within the context of the game. 0:04:00.000 --> 0:04:03.480 The game engine is a foundation you get. Think of 0:04:03.480 --> 0:04:07.560 it as a scaffold or a frame, has its own 0:04:07.560 --> 0:04:10.440 set of rules that the content has to adhere to 0:04:10.640 --> 0:04:13.760 in order to work within the context of a game. 0:04:14.040 --> 0:04:18.040 It is in effect a software development kit or s 0:04:18.160 --> 0:04:21.400 d K that allows the game developers to create the 0:04:21.480 --> 0:04:25.600 assets without having to code everything in advanced programming languages 0:04:25.880 --> 0:04:29.520 for the most part. So Michael Inger over at Giant 0:04:29.560 --> 0:04:33.039 Bomb created a pretty simple overview of a software and 0:04:33.120 --> 0:04:36.200 hardware stack to kind of show where a game engine 0:04:36.240 --> 0:04:38.920 fits in in the grand scheme of things. So, these 0:04:38.960 --> 0:04:43.640 are different layers of operations. Uh, they're not. It's not 0:04:43.720 --> 0:04:48.839 really physical layers, but it's a way to conceptualize this. 0:04:49.360 --> 0:04:52.159 So at the very top layer, the layer that would 0:04:52.200 --> 0:04:56.520 face the video game player, the part that that is 0:04:56.720 --> 0:04:59.640 outwardly facing to the world, you have the actual game. 0:05:00.000 --> 0:05:02.640 It's at the very top of this stack. For the 0:05:02.720 --> 0:05:05.440 purposes of this, we're going to make up a fictional game. 0:05:05.480 --> 0:05:10.279 I'm gonna call it tech Stuff Adventure for a princely sum. 0:05:10.440 --> 0:05:13.520 Under that layer, you then have the game engine. So 0:05:13.560 --> 0:05:16.359 the game sits on top of the game engine. The 0:05:16.440 --> 0:05:20.440 game engine supports the game. Beneath the game engine, you 0:05:20.480 --> 0:05:23.800 have what is called the application layer. This is sort 0:05:23.839 --> 0:05:26.640 of a communication channel. It allows the game engine to 0:05:26.760 --> 0:05:31.760 interoperate with a computer's operating system. That's the next layer down. 0:05:31.839 --> 0:05:35.839 So we're familiar with operating systems things like Windows, uh, 0:05:36.080 --> 0:05:41.520 mac os. Those are the user interfaces to interact with 0:05:41.560 --> 0:05:46.680 a computer. More directly below the operating system level is 0:05:46.920 --> 0:05:51.600 BIOS that's basic input output layer. This is sort of 0:05:51.640 --> 0:05:56.800 the firmware that allows the actual communication between the software 0:05:56.880 --> 0:06:01.560 and the hardware. Beneath BIO is the actual hardware, the 0:06:01.600 --> 0:06:06.320 actual circuitry that the computer runs on. Beneath that is 0:06:06.360 --> 0:06:10.200 the electricity that is powering everything. That is the different 0:06:10.400 --> 0:06:15.000 different cotrols and voltage that indicate whether it's a zero 0:06:15.160 --> 0:06:18.880 or a one essentially, and as Anger points out, game 0:06:18.920 --> 0:06:22.599 engines will sometimes communicate straight through to the BIOS layer. 0:06:22.880 --> 0:06:26.520 They skip the application and operating system layer and will 0:06:26.560 --> 0:06:29.560 interact directly with a bioslayer, And this helps maximize the 0:06:29.600 --> 0:06:32.920 efficiency of hardware usage. It means the game can take 0:06:33.000 --> 0:06:36.320 up more of the computer's assets and create a more 0:06:36.560 --> 0:06:41.279 immersive experience. Now, around the time that Doom launched, computer 0:06:41.360 --> 0:06:45.440 games were becoming pretty sophisticated. They were pushing hardware to 0:06:45.520 --> 0:06:49.279 the limits, and building a game from scratch was becoming 0:06:49.279 --> 0:06:52.280 a more daunting prospect. You know, way back in the day, 0:06:52.800 --> 0:06:56.719 a single person could create a triple A title game 0:06:57.120 --> 0:07:01.160 out of a garage using a simple computer. But by 0:07:01.200 --> 0:07:03.320 the time Doom was coming around, these games were becoming 0:07:03.360 --> 0:07:07.279 so sophisticated, so complicated that it required a team of 0:07:07.320 --> 0:07:10.280 developers working together to get it done in any reasonable 0:07:10.280 --> 0:07:13.840 amount of time, and developing a single game was taking 0:07:13.960 --> 0:07:16.560 longer and a lot more people than games from just 0:07:16.640 --> 0:07:19.640 a few years earlier. So game engines helped reduce the 0:07:19.680 --> 0:07:22.960 amount of time and efforts spent developing a game. For 0:07:23.040 --> 0:07:26.720 as long as the game engine remains relevant. Game engines 0:07:26.800 --> 0:07:31.320 can age into you know, obsolescence. You can get a 0:07:31.360 --> 0:07:34.760 game engine that no longer can take advantage of hardware 0:07:34.760 --> 0:07:38.240 to a point that makes it meaningful. But a lot 0:07:38.280 --> 0:07:42.480 of game engines are upgradeable, so we'll get into that 0:07:42.480 --> 0:07:45.560 a little bit more later now, to make matters more complicated. 0:07:45.840 --> 0:07:48.880 Around the same time when Doom was coming out, we 0:07:48.920 --> 0:07:53.000 started to see an incredible growth and expansion cards for computers, 0:07:53.040 --> 0:07:56.320 both for graphics cards and audio cards. If you listen 0:07:56.400 --> 0:07:59.600 to my in vidio episodes, you'll likely remember this was 0:07:59.640 --> 0:08:03.680 a time aime of competing standards in hardware and application 0:08:03.720 --> 0:08:07.720 programmer interfaces and developing a game for the PC started 0:08:07.760 --> 0:08:11.800 to get tough because these standards in hardware were changing 0:08:11.840 --> 0:08:15.040 so rapidly. You wanted your game to be as pretty 0:08:15.280 --> 0:08:17.960 and as as advanced as it possibly could be. You 0:08:18.000 --> 0:08:22.080 wanted to be at that leading edge, but the development 0:08:22.160 --> 0:08:25.200 cycle for a game might not match up with the 0:08:25.240 --> 0:08:28.320 advancement of hardware. You know, you might be working on 0:08:28.360 --> 0:08:32.200 a game on one standard of hardware, and while you're 0:08:32.200 --> 0:08:35.880 working on the game, the hardware is you know, upgraded, 0:08:36.240 --> 0:08:39.680 and you're still working on the older version. So it 0:08:39.800 --> 0:08:44.959 was really challenging. The big difference here for PCs versus 0:08:45.000 --> 0:08:46.840 consoles is that you didn't have to worry about this 0:08:46.880 --> 0:08:51.640 with consoles. Consoles are different. A console's hardware remains consistent. 0:08:51.920 --> 0:08:55.800 Typically you might get a new version of that console 0:08:55.880 --> 0:09:00.280 that has beefier specs, but consoles tend to be locked down. 0:09:00.640 --> 0:09:04.120 You don't expand them with new hardware, so there's not 0:09:04.240 --> 0:09:07.240 really any worry about that. You can develop a game 0:09:07.320 --> 0:09:12.520 for that specific hardware specification and be reasonably sure that's 0:09:12.559 --> 0:09:17.400 going to apply across the entire spectrum, so you don't 0:09:17.400 --> 0:09:21.440 have to worry about this fast development cycle of expansion cards. 0:09:21.880 --> 0:09:24.400 Now there are many different types of game engines, and 0:09:24.480 --> 0:09:27.360 thus there are different approaches to building out a framework. 0:09:27.600 --> 0:09:31.640 It's kind of like programming languages. A programming language is 0:09:31.679 --> 0:09:34.600 purpose is to give a person, you know, the programmer, 0:09:35.000 --> 0:09:37.960 the ability to create a set of instructions for a 0:09:38.000 --> 0:09:42.560 computer to follow. But computers understand machine code, and that 0:09:42.800 --> 0:09:45.000 tends to me very hard for humans to work with. 0:09:45.160 --> 0:09:49.160 It's not intuitive, it's easy to lose your place. Humans 0:09:49.200 --> 0:09:52.840 do much better with more abstract languages that can be 0:09:52.880 --> 0:09:57.559 converted into machine code for computers to follow those instructions. 0:09:57.800 --> 0:10:00.280 So the language the humans use and lang which the 0:10:00.320 --> 0:10:05.080 computers use are different. They require an interpreter between them. 0:10:05.280 --> 0:10:08.720 Game engines are kind of like the same thing, except 0:10:08.760 --> 0:10:11.960 they go one step further out from programming languages to 0:10:12.000 --> 0:10:15.240 create a platform upon which game developers can build out 0:10:15.280 --> 0:10:19.800 their games. Harold Serrano wrote a great overview of game 0:10:19.840 --> 0:10:24.040 engines and breaks them down into three smaller entities. At 0:10:24.080 --> 0:10:26.360 the top is why he calls a math engine that 0:10:26.480 --> 0:10:29.000 handles all the operations that the rest of the game 0:10:29.040 --> 0:10:32.480 relies upon, and that sends those instructions to the computer. 0:10:32.800 --> 0:10:35.640 It's the heart of the game engine. It contains the 0:10:35.760 --> 0:10:39.160 rules for all those operations, whether they be vector operations 0:10:39.200 --> 0:10:44.599 such as addition and subtraction, or matrix operations like transforms 0:10:44.640 --> 0:10:48.400 or transpositions. Then Serrano writes, you have the two engines 0:10:48.440 --> 0:10:51.360 that this math engine feeds into, and those would be 0:10:51.360 --> 0:10:54.800 the rendering engine and the physics engine. And we'll start 0:10:54.800 --> 0:10:58.600 by talking about the renderer or rendering engine. And for 0:10:58.679 --> 0:11:01.280 a lot of this I'm relying up Bond The Incredible 0:11:02.200 --> 0:11:06.800 an exhaustive series of articles on Extreme Tech about the 0:11:06.800 --> 0:11:10.640 anatomy of a game engine. It's an eleven part series. 0:11:10.679 --> 0:11:13.440 They were written by a game designer named Jake Simpson. 0:11:14.080 --> 0:11:16.880 Uh the articles came out in two thousand two, so 0:11:17.000 --> 0:11:20.720 they're a little dated, but the general principles remain sound. 0:11:21.120 --> 0:11:23.200 So if at the end of this episode you still 0:11:23.240 --> 0:11:25.880 want to learn a lot more about game engines, and 0:11:25.960 --> 0:11:29.600 I mean a lot more, go check out that series 0:11:29.600 --> 0:11:32.480 of articles over at Extreme Tech, because Jake Simpson wrote 0:11:32.520 --> 0:11:37.920 about twenty six thousand words on the subject. It's an 0:11:37.920 --> 0:11:42.040 incredible account. Anyway, the renderer's job is to produce the 0:11:42.120 --> 0:11:45.720 visualizations of data so that there's something for the player 0:11:45.760 --> 0:11:49.120 to look at. It is creating the visuals on the screen. 0:11:49.200 --> 0:11:52.280 According to the current state of the game, and it 0:11:52.320 --> 0:11:55.800 does this rapidly, multiple times a second, and in reaction 0:11:55.880 --> 0:11:59.160 to the inputs it receives. So in the first person shooter, 0:11:59.440 --> 0:12:02.320 that can include changing the angle of view as a 0:12:02.320 --> 0:12:04.640 player turns the character to the left or to the right, 0:12:05.000 --> 0:12:08.120 as well as the way that graphics are changing as 0:12:08.240 --> 0:12:12.079 enemies are moving closer or further away, or they're moving 0:12:12.120 --> 0:12:16.520 behind cover. All of these things affect what the renderer 0:12:16.559 --> 0:12:20.120 has to create for us to see. Now, you don't 0:12:20.160 --> 0:12:24.080 actually build those elements in the renderer. You would use 0:12:24.120 --> 0:12:28.520 a different tool to build all of these graphic models themselves. 0:12:28.920 --> 0:12:32.040 You might use something like Maya or Blender, and that's 0:12:32.040 --> 0:12:36.080 where you would design all of these graphic elements. The 0:12:36.160 --> 0:12:40.120 game engines renderer is in charge of taking those assets 0:12:40.440 --> 0:12:44.120 and displaying them in the appropriate way on the screen 0:12:44.640 --> 0:12:48.200 so that they are in the right location, at the 0:12:48.320 --> 0:12:51.840 right size, at the right orientation, with the right lighting effects, 0:12:51.840 --> 0:12:55.000 the right texture effects. All of those things have to 0:12:55.040 --> 0:12:59.080 be just right based upon the moment you are seeing 0:12:59.120 --> 0:13:03.839 them in the game, and the game engine handles those rules. Now, 0:13:03.840 --> 0:13:07.400 there's more important stuff about things like light effects and 0:13:07.520 --> 0:13:10.040 textures that I need to get into. But first let's 0:13:10.080 --> 0:13:20.960 take a quick break and thank our sponsor. Now, the 0:13:21.040 --> 0:13:26.080 rendering engine creates a really big demand on computer processors 0:13:26.080 --> 0:13:29.040 in general. Back in the day we're talking, it could 0:13:29.040 --> 0:13:33.280 represent or more of all the CPUs processing time on 0:13:33.360 --> 0:13:37.319 a game. And with the invention of graphics processing units 0:13:37.440 --> 0:13:41.760 or GPUs as we've called them, building a renderer requires 0:13:41.800 --> 0:13:47.959 an extensive understanding of hardware and three dimensional math. Virtual 0:13:48.040 --> 0:13:51.920 three dimensional objects exists as a series of points in 0:13:52.040 --> 0:13:54.240 virtual space, so you can kind of think of as 0:13:54.240 --> 0:13:58.000 connect the dots, except it's connect the dots in three dimensions, 0:13:58.000 --> 0:14:02.160 not just in two, and the dot are points called vertices. 0:14:02.600 --> 0:14:07.920 Programmers create models that define the relationship between vertices so 0:14:07.960 --> 0:14:11.400 that the computer knows how far apart any two given 0:14:11.520 --> 0:14:15.679 vertices are from each other. So, for example, let's say 0:14:15.679 --> 0:14:19.800 you're building a pyramid, just a static pyramid in virtual space. 0:14:20.560 --> 0:14:24.520 A pyramid has four sides, and the computer would have 0:14:24.600 --> 0:14:27.880 to understand how far apart the different points of the 0:14:27.920 --> 0:14:30.400 pyramid are from each other. From the tippy top of 0:14:30.440 --> 0:14:33.320 the pyramid to the four points along the base of 0:14:33.360 --> 0:14:36.400 the pyramid, they would all have a certain distance from 0:14:36.440 --> 0:14:39.680 one another that would remain the same no matter what 0:14:39.760 --> 0:14:44.800 orientation you put that pyramid in because the pyramid is 0:14:44.840 --> 0:14:50.160 a static object. It's not flippy filippy. So uh, the 0:14:50.160 --> 0:14:54.040 game engine understands that that virtual object has four faces, 0:14:54.840 --> 0:14:57.520 three that face outward and one that would face downward, 0:14:58.040 --> 0:15:01.080 and complex shapes and video games are made up of 0:15:01.120 --> 0:15:03.800 things like this, like surfaces like this, except they're made 0:15:03.840 --> 0:15:08.000 up of thousands or hundreds of thousands of polygons. Now 0:15:08.040 --> 0:15:11.480 you can imagine that the game sends instructions to the 0:15:11.520 --> 0:15:15.640 renderer to display the appropriate graphics at the appropriate angles, 0:15:15.880 --> 0:15:19.720 with the appropriate orientations, with regard to each other. The 0:15:19.760 --> 0:15:22.760 game doesn't have to understand how the renderer does this. 0:15:23.120 --> 0:15:25.760 It's just saying something like, I need you to show 0:15:26.160 --> 0:15:30.880 this tree over here, a mountain over there, and I 0:15:30.920 --> 0:15:34.960 don't know a rabbit, wear rabbit over in this direction, 0:15:35.200 --> 0:15:38.040 and the renderer follows the set of rules to display 0:15:38.240 --> 0:15:41.520 those things so that they appear correctly within the context 0:15:41.600 --> 0:15:43.920 of a player's point of view, so that the rabbit 0:15:43.960 --> 0:15:47.680 doesn't appear to be larger than the mountain, for example. Now, 0:15:47.720 --> 0:15:50.360 one thing a rendering engine can do to manage this 0:15:50.520 --> 0:15:53.840 massive amount of data that it has to handle is 0:15:53.920 --> 0:15:59.360 a process that's called culling. Culling involves eliminating the need 0:15:59.400 --> 0:16:03.200 to calculate the math that represents stuff you cannot see 0:16:03.640 --> 0:16:07.960 from your perspective. So here's some examples. If there are 0:16:07.960 --> 0:16:11.200 objects that are very very far away from you, so 0:16:11.240 --> 0:16:15.160 they are beyond where your vision could detect them, that's 0:16:15.160 --> 0:16:18.120 not going to be represented, so that math can be dropped. 0:16:18.200 --> 0:16:20.720 There's no need to worry about it because you can't 0:16:20.760 --> 0:16:24.040 see it anyway. A lot of games will introduce fog 0:16:24.320 --> 0:16:27.200 for this purpose, and you'll have fog that cuts off 0:16:27.240 --> 0:16:30.080 your vision at a certain distance, and that way the 0:16:30.160 --> 0:16:34.120 rendering engine doesn't have to draw progressively smaller and smaller 0:16:34.240 --> 0:16:41.040 landmarks off into the distance. Then there's also things like occlusion. 0:16:41.760 --> 0:16:45.440 This is when you have one object blocking some or 0:16:45.520 --> 0:16:48.720 all of another object. So, for example, let's say you're 0:16:48.720 --> 0:16:52.000 playing a fantasy game. You're playing an Elder Scrolls game. 0:16:52.120 --> 0:16:55.520 Let's say, and you're looking at a forest uh in 0:16:55.600 --> 0:16:57.920 a mountain range, and you see a frost troll and 0:16:57.960 --> 0:17:00.480 the frost trols lurking behind the rocks. You can only 0:17:00.480 --> 0:17:02.960 see part of the frost trol. Well, some of that 0:17:03.000 --> 0:17:06.920 frost trol obviously is obscured by the scenery. So rather 0:17:06.960 --> 0:17:10.760 than calculate all the information that represents that frost trol 0:17:10.960 --> 0:17:14.240 in its entirety, the culling process would remove any of 0:17:14.240 --> 0:17:16.080 the bits that would be out of your view due 0:17:16.080 --> 0:17:18.000 to the rock. It would say, oh, we don't need 0:17:18.040 --> 0:17:20.840 to calculate this stuff because the player can't see it, 0:17:20.960 --> 0:17:23.240 so we're just gonna leave that out. We'll just include 0:17:23.240 --> 0:17:25.720 the stuff that the player can see based upon their 0:17:25.800 --> 0:17:29.800 angle of view. The rendering engine is only concerned with 0:17:29.880 --> 0:17:32.280 the bits you can actually see, which is in a 0:17:32.359 --> 0:17:36.280 way kind of like lossy audio compression formats like MP 0:17:36.440 --> 0:17:38.840 three you remember, I've talked about that in the past, 0:17:38.880 --> 0:17:41.560 where MP three files. One of the reasons they are 0:17:41.600 --> 0:17:45.160 so much smaller than raw audio files is that they 0:17:45.200 --> 0:17:48.960 eliminate all the sounds that are, at least in theory, 0:17:49.000 --> 0:17:53.159 outside the range of human hearing. Because if it's outside 0:17:53.160 --> 0:17:55.840 the range of human hearing, if we cannot perceive it, 0:17:55.920 --> 0:17:59.840 there's no need to preserve that information, at least in theory. 0:18:00.320 --> 0:18:04.000 Rendering also sets the rules for how graphics will pop 0:18:04.040 --> 0:18:08.000 into view. So, for example, translucent surfaces things that you 0:18:08.040 --> 0:18:12.080 can see through have to render in after the opaque surfaces, 0:18:12.600 --> 0:18:15.680 and that way you can see through the translucent ones properly. 0:18:16.000 --> 0:18:19.000 So let's say you're looking through Let's say it's a waterfall. 0:18:19.280 --> 0:18:21.600 It's a very thin waterfall, and you can see through 0:18:21.640 --> 0:18:25.120 it to the other side. Well, the other side would 0:18:25.119 --> 0:18:28.040 have to render in first, and then the waterfall would 0:18:28.040 --> 0:18:30.640 render in. Uh. And so you can think of it 0:18:30.800 --> 0:18:34.040 as a sequence that goes back to front, the further 0:18:34.160 --> 0:18:39.520 away from you, the back surfaces that should come in first, 0:18:39.600 --> 0:18:41.680 and then the surfaces ahead of time. So maybe there's 0:18:41.720 --> 0:18:46.440 a lighting uh see, a lighting source that's between the 0:18:46.480 --> 0:18:50.480 waterfall and whatever is behind it that would look come 0:18:50.520 --> 0:18:52.720 in next, and then the waterfall would come in last. 0:18:52.880 --> 0:18:55.000 But this all happens, or at least it should happen 0:18:55.359 --> 0:18:59.720 very very very quickly. So preferably it's fast enough where 0:18:59.720 --> 0:19:01.920 you even be noticeable. It would all just seem to 0:19:01.960 --> 0:19:04.640 appear at the same time. That's not always the case. 0:19:04.680 --> 0:19:07.400 If you're playing a very advanced game on high settings, 0:19:07.440 --> 0:19:10.720 on hardware that can't quite handle it, you'll run into 0:19:10.800 --> 0:19:13.119 problems when this stuff starts to try and kick in. 0:19:13.720 --> 0:19:17.040 The rendering engine also has to take other factors into account. 0:19:17.080 --> 0:19:20.320 The game will send information about textures, and the renderer 0:19:20.359 --> 0:19:23.840 has to apply those textures to the various polygons in 0:19:23.880 --> 0:19:27.560 the view. So otherwise, if you didn't have textures, you 0:19:27.600 --> 0:19:30.240 would just end up with a messy wire frame universe. 0:19:30.280 --> 0:19:32.680 It would be very hard to be able to make 0:19:32.680 --> 0:19:35.679 heads or tails out of anything, especially for very complicated 0:19:36.280 --> 0:19:39.080 graphics heavy games. It would just be these sets of 0:19:39.160 --> 0:19:42.040 lines and polygons and you wouldn't be able to tell 0:19:42.040 --> 0:19:47.480 what is what. After the renderer UH has to calculate 0:19:47.680 --> 0:19:50.359 the textures, it then has to figure out how bright 0:19:50.480 --> 0:19:53.760 each surface should be given the light sources in the area. 0:19:53.760 --> 0:19:57.680 It has to apply logic to the lighting. So if 0:19:57.720 --> 0:20:00.639 you have a torch on a wall and you have 0:20:00.680 --> 0:20:04.359 an object that would be partly illuminated by this torch, 0:20:05.160 --> 0:20:07.240 some parts of the surface of that object should be 0:20:07.240 --> 0:20:09.879 brighter than others, and the game engine is responsible for 0:20:09.960 --> 0:20:13.280 applying this logic in a way that makes sense based 0:20:13.359 --> 0:20:16.720 upon where the light sources are in your area. So 0:20:17.040 --> 0:20:20.879 if you're in a dark corridor aboard a defunct space station, 0:20:20.920 --> 0:20:24.080 the sparse light sources will highlight some surfaces will leave 0:20:24.160 --> 0:20:26.800 others in shadow, and the renderer has to take into 0:20:26.840 --> 0:20:30.000 account all of this when drawing out the scene. It 0:20:30.080 --> 0:20:33.240 also has to do some collision detection as well, although 0:20:33.280 --> 0:20:36.879 that will come into play also with physics and AI. 0:20:37.040 --> 0:20:40.560 But collision detection is when you have two virtual elements 0:20:40.600 --> 0:20:43.399 that would come into contact with one another within the 0:20:43.480 --> 0:20:46.680 virtual environment. So in the real world, if you had 0:20:46.720 --> 0:20:50.520 real things, they would hit each other. Well, these are 0:20:50.600 --> 0:20:54.080 virtual objects. They don't they don't have any actual mass. 0:20:54.680 --> 0:20:58.720 But with good collision detection, virtual elements will appear to 0:20:58.800 --> 0:21:02.720 move naturally with hard to each other, and they'll appear 0:21:02.840 --> 0:21:06.720 to have this contact and the reaction to that contact, 0:21:06.760 --> 0:21:09.280 and they won't just pass through. Otherwise it would be 0:21:09.840 --> 0:21:13.280 like you're phasing through solid objects, and that kind of 0:21:13.320 --> 0:21:16.280 breaks the immersion of a video game if that was 0:21:16.320 --> 0:21:20.040 not intended. If you want to learn way more about lighting, 0:21:20.080 --> 0:21:22.520 I recommend reading the Anatomy of a Game Engine articles 0:21:22.560 --> 0:21:25.760 I mentioned already by Jake Simpson, because he goes into 0:21:25.800 --> 0:21:28.840 a lot more detail over the various approaches to lighting. 0:21:28.880 --> 0:21:33.320 I'm grouping them all in a general category, but there 0:21:33.359 --> 0:21:39.440 are several different methods to going about lighting scenes in games, 0:21:39.520 --> 0:21:43.159 and Simpson goes through them and and much more detail 0:21:43.200 --> 0:21:44.800 than I will hear. I don't want to do a 0:21:45.200 --> 0:21:48.639 fifteen episode series about game engines. It is fascinating, but 0:21:48.680 --> 0:21:50.359 it goes further in the weeds than I think we 0:21:50.440 --> 0:21:52.919 need to for this episode. Will just allow that the 0:21:52.960 --> 0:21:55.880 rendering engine has to take all these different factors into 0:21:55.880 --> 0:21:59.000 account to display the assets of the game properly for 0:21:59.040 --> 0:22:03.080 the player. Now, one really interesting thing about rendering engines 0:22:03.320 --> 0:22:06.320 is that if you design it properly, you can make 0:22:06.359 --> 0:22:10.800 it really modular within the larger game engine itself. Remember, 0:22:10.840 --> 0:22:14.399 the rendering engine is just one component of the game engine. 0:22:15.240 --> 0:22:18.879 Now that means you could overhaul the rendering engine for 0:22:19.000 --> 0:22:24.960 future games, you get more advanced ways of creating, uh 0:22:25.000 --> 0:22:29.360 the graphics. Maybe there are new effects that you can apply. Well, 0:22:29.400 --> 0:22:33.520 you can actually create a new rendering engine and disconnect 0:22:33.560 --> 0:22:36.160 the old one from your game engine, plug the new 0:22:36.160 --> 0:22:38.760 one in, and it should work with all the other 0:22:38.800 --> 0:22:43.080 components seamlessly. If you actually built your game engine in 0:22:43.119 --> 0:22:46.880 that way, you have to actually have built it this way, 0:22:46.920 --> 0:22:49.760 but it's possible. You can make this where the rendering 0:22:49.760 --> 0:22:52.600 engine is sort of a plug in play approach. It's 0:22:52.600 --> 0:22:55.119 a little more complicated than that, but that's the concept. 0:22:55.920 --> 0:22:58.720 It's way easier said than done, but it's one of 0:22:58.760 --> 0:23:01.680 the ways legacy game jids have stuck around for so long. 0:23:02.200 --> 0:23:05.359 It's not that people perfected the game engine a decade ago. 0:23:05.800 --> 0:23:09.000 It's that the game engines elements can evolve over time 0:23:09.320 --> 0:23:12.640 and plug back into the overall engine itself to give 0:23:12.640 --> 0:23:15.600 it more usefulness. Now there's a lot more to talk 0:23:15.640 --> 0:23:18.480 about when it comes to rendering images, and some of 0:23:18.480 --> 0:23:20.440 the stuff I'm going to mention in the next section 0:23:20.480 --> 0:23:23.960 will come back to touch on rendering. But rendering as 0:23:23.960 --> 0:23:26.600 fascinating as it is and as advanced as it gets 0:23:26.600 --> 0:23:29.280 with all the different particle effects and lighting effects and 0:23:29.320 --> 0:23:32.199 texture mapping and all that is only part of the 0:23:32.200 --> 0:23:34.359 game engine. We still have a lot more to talk about, 0:23:34.640 --> 0:23:37.280 which I'll get to right after we take this break 0:23:37.520 --> 0:23:47.960 to thank our sponsor. The game engine can also play 0:23:48.000 --> 0:23:52.720 a really important role in sending audio information to computer hardware. Now, again, 0:23:53.000 --> 0:23:56.720 the audio itself, that's those are assets, But the game 0:23:56.760 --> 0:24:00.960 engine determines how the audio plays out within the context 0:24:01.000 --> 0:24:04.119 of the game, and it might send information out to 0:24:04.160 --> 0:24:07.479 a dedicated sound card, or these days it might be 0:24:07.520 --> 0:24:12.040 through an integrated audio that's already on the motherboard and 0:24:12.080 --> 0:24:15.920 then directly onto speakers or headphones. Back when I got 0:24:15.960 --> 0:24:19.119 fed up with PC gaming in the nineties, and that 0:24:19.200 --> 0:24:22.159 was because there were these different graphics and sound cards. 0:24:22.160 --> 0:24:27.280 They're all battling for supremacy, and getting one set of 0:24:28.080 --> 0:24:31.119 sound cards or graphics cards could mean missing out on 0:24:31.240 --> 0:24:34.520 some games that don't support those formats, or getting a 0:24:34.600 --> 0:24:37.600