How Game Engines Work

But first things first, what the heck is a game engine? Well, a lot of this episode is going to focus on that, But here's the too long, didn't read version if you just want to get right down to it. It's a framework upon which you can build a video game. But that's doing a bit of a disservice to all the things that a game engine allows developers to do. And it's a complicated question to answer because there are a

lot of different game engines out there. They go about doing what they do in different ways and to different extents. But I'm going to do my best to kind of take a high level view of this that is as applicable across the board as is possible. So when you think about a video game, everything that happens in that game is, ultimately, when you really boil it down, a

math problem. Computers will take in input, they perform operations on that input according to some sort of program, essentially a set of directions or instructions, and then they produce output. So everything that happens within the context of a computer or video game is ultimately an expression of math as defined by code. Now, for more than a decade, every game that came out was essentially an ex ample of

developers building this whole thing out from scratch. They might take some source code and make some changes in it to create a sequel to a popular game, but most games included new, unique code that was written in a new way to define the virtual world and how stuff happens within it, as well as how the program would execute the functions that made the game playable. It would

just be written from scratch, over and over. But then came a little game called Doom in from its software, and its software released a press kit that's a doom would introduce a new paradigm in gaming with the quote unquote doom engine. John Carmack of it had come up with a new way to define and develop games, and it effectively split games into two general buckets of stuff. One bigucket of stuff was all about content. The other big bucket was the core functionality of the game itself.

So let's start with the content bucket. It's the easier one to understand. That's where all the assets for the game would exist. Assets could include stuff like graphics, like all the different graphic models, what characters look like, what settings look like. It could also include AI, behaviors or physics. In fact, that it consists of just about all the elements the player would experience while playing the game, So you as the player, the stuff that you would experience,

that you would see, that you would hear. Ultimately, those are all assets. So what the heck do I mean by core functionality and game engines? What's left for a game engine to do if all the content is in this other bucket. Well, the core functionality contains all the rules to make the stuff in the assets and the content bucket actually work within the context of the game.

The game engine is a foundation you get. Think of it as a scaffold or a frame, has its own set of rules that the content has to adhere to in order to work within the context of a game. It is in effect a software development kit or s d K that allows the game developers to create the assets without having to code everything in advanced programming languages

for the most part. So Michael Inger over at Giant Bomb created a pretty simple overview of a software and hardware stack to kind of show where a game engine fits in in the grand scheme of things. So, these are different layers of operations. Uh, they're not. It's not really physical layers, but it's a way to conceptualize this. So at the very top layer, the layer that would face the video game player, the part that that is outwardly facing to the world, you have the actual game.

It's at the very top of this stack. For the purposes of this, we're going to make up a fictional game. I'm gonna call it tech Stuff Adventure for a princely sum. Under that layer, you then have the game engine. So the game sits on top of the game engine. The game engine supports the game. Beneath the game engine, you have what is called the application layer. This is sort of a communication channel. It allows the game engine to

interoperate with a computer's operating system. That's the next layer down. So we're familiar with operating systems things like Windows, uh, mac os. Those are the user interfaces to interact with a computer. More directly below the operating system level is BIOS that's basic input output layer. This is sort of the firmware that allows the actual communication between the software and the hardware. Beneath BIO is the actual hardware, the

actual circuitry that the computer runs on. Beneath that is the electricity that is powering everything. That is the different different cotrols and voltage that indicate whether it's a zero or a one essentially, and as Anger points out, game engines will sometimes communicate straight through to the BIOS layer. They skip the application and operating system layer and will interact directly with a bioslayer, And this helps maximize the

efficiency of hardware usage. It means the game can take up more of the computer's assets and create a more immersive experience. Now, around the time that Doom launched, computer games were becoming pretty sophisticated. They were pushing hardware to the limits, and building a game from scratch was becoming a more daunting prospect. You know, way back in the day, a single person could create a triple A title game

out of a garage using a simple computer. But by the time Doom was coming around, these games were becoming so sophisticated, so complicated that it required a team of developers working together to get it done in any reasonable amount of time, and developing a single game was taking longer and a lot more people than games from just a few years earlier. So game engines helped reduce the amount of time and efforts spent developing a game. For

as long as the game engine remains relevant. Game engines can age into you know, obsolescence. You can get a game engine that no longer can take advantage of hardware to a point that makes it meaningful. But a lot of game engines are upgradeable, so we'll get into that a little bit more later now, to make matters more complicated. Around the same time when Doom was coming out, we started to see an incredible growth and expansion cards for computers,

both for graphics cards and audio cards. If you listen to my in vidio episodes, you'll likely remember this was a time aime of competing standards in hardware and application programmer interfaces and developing a game for the PC started to get tough because these standards in hardware were changing so rapidly. You wanted your game to be as pretty and as as advanced as it possibly could be. You wanted to be at that leading edge, but the development cycle for a game might not match up with the

advancement of hardware. You know, you might be working on a game on one standard of hardware, and while you're working on the game, the hardware is you know, upgraded, and you're still working on the older version. So it was really challenging. The big difference here for PCs versus consoles is that you didn't have to worry about this with consoles. Consoles are different. A console's hardware remains consistent.

Typically you might get a new version of that console that has beefier specs, but consoles tend to be locked down. You don't expand them with new hardware, so there's not really any worry about that. You can develop a game for that specific hardware specification and be reasonably sure that's going to apply across the entire spectrum, so you don't have to worry about this fast development cycle of expansion cards.

Now there are many different types of game engines, and thus there are different approaches to building out a framework. It's kind of like programming languages. A programming language is purpose is to give a person, you know, the programmer, the ability to create a set of instructions for a computer to follow. But computers understand machine code, and that tends to me very hard for humans to work with.

It's not intuitive, it's easy to lose your place. Humans do much better with more abstract languages that can be converted into machine code for computers to follow those instructions. So the language the humans use and lang which the computers use are different. They require an interpreter between them. Game engines are kind of like the same thing, except they go one step further out from programming languages to create a platform upon which game developers can build out

their games. Harold Serrano wrote a great overview of game engines and breaks them down into three smaller entities. At the top is why he calls a math engine that handles all the operations that the rest of the game relies upon, and that sends those instructions to the computer. It's the heart of the game engine. It contains the rules for all those operations, whether they be vector operations such as addition and subtraction, or matrix operations like transforms

or transpositions. Then Serrano writes, you have the two engines that this math engine feeds into, and those would be the rendering engine and the physics engine. And we'll start by talking about the renderer or rendering engine. And for a lot of this I'm relying up Bond The Incredible an exhaustive series of articles on Extreme Tech about the anatomy of a game engine. It's an eleven part series. They were written by a game designer named Jake Simpson.

Uh the articles came out in two thousand two, so they're a little dated, but the general principles remain sound. So if at the end of this episode you still want to learn a lot more about game engines, and I mean a lot more, go check out that series of articles over at Extreme Tech, because Jake Simpson wrote about twenty six thousand words on the subject. It's an incredible account. Anyway, the renderer's job is to produce the visualizations of data so that there's something for the player

to look at. It is creating the visuals on the screen. According to the current state of the game, and it does this rapidly, multiple times a second, and in reaction to the inputs it receives. So in the first person shooter, that can include changing the angle of view as a player turns the character to the left or to the right, as well as the way that graphics are changing as enemies are moving closer or further away, or they're moving behind cover. All of these things affect what the renderer

has to create for us to see. Now, you don't actually build those elements in the renderer. You would use a different tool to build all of these graphic models themselves. You might use something like Maya or Blender, and that's

where you would design all of these graphic elements. The game engines renderer is in charge of taking those assets and displaying them in the appropriate way on the screen so that they are in the right location, at the right size, at the right orientation, with the right lighting effects, the right texture effects. All of those things have to be just right based upon the moment you are seeing

them in the game, and the game engine handles those rules. Now, there's more important stuff about things like light effects and textures that I need to get into. But first let's take a quick break and thank our sponsor. Now, the rendering engine creates a really big demand on computer processors in general. Back in the day we're talking, it could represent or more of all the CPUs processing time on

a game. And with the invention of graphics processing units or GPUs as we've called them, building a renderer requires an extensive understanding of hardware and three dimensional math. Virtual three dimensional objects exists as a series of points in virtual space, so you can kind of think of as connect the dots, except it's connect the dots in three dimensions, not just in two, and the dot are points called vertices.

Programmers create models that define the relationship between vertices so that the computer knows how far apart any two given vertices are from each other. So, for example, let's say you're building a pyramid, just a static pyramid in virtual space. A pyramid has four sides, and the computer would have to understand how far apart the different points of the

pyramid are from each other. From the tippy top of the pyramid to the four points along the base of the pyramid, they would all have a certain distance from one another that would remain the same no matter what orientation you put that pyramid in because the pyramid is

a static object. It's not flippy filippy. So uh, the game engine understands that that virtual object has four faces, three that face outward and one that would face downward, and complex shapes and video games are made up of things like this, like surfaces like this, except they're made up of thousands or hundreds of thousands of polygons. Now you can imagine that the game sends instructions to the renderer to display the appropriate graphics at the appropriate angles,

with the appropriate orientations, with regard to each other. The game doesn't have to understand how the renderer does this. It's just saying something like, I need you to show this tree over here, a mountain over there, and I don't know a rabbit, wear rabbit over in this direction, and the renderer follows the set of rules to display those things so that they appear correctly within the context of a player's point of view, so that the rabbit

doesn't appear to be larger than the mountain, for example. Now, one thing a rendering engine can do to manage this massive amount of data that it has to handle is a process that's called culling. Culling involves eliminating the need to calculate the math that represents stuff you cannot see

from your perspective. So here's some examples. If there are objects that are very very far away from you, so they are beyond where your vision could detect them, that's not going to be represented, so that math can be dropped. There's no need to worry about it because you can't

see it anyway. A lot of games will introduce fog for this purpose, and you'll have fog that cuts off your vision at a certain distance, and that way the rendering engine doesn't have to draw progressively smaller and smaller landmarks off into the distance. Then there's also things like occlusion. This is when you have one object blocking some or all of another object. So, for example, let's say you're playing a fantasy game. You're playing an Elder Scrolls game.

Let's say, and you're looking at a forest uh in a mountain range, and you see a frost troll and the frost trols lurking behind the rocks. You can only see part of the frost trol. Well, some of that frost trol obviously is obscured by the scenery. So rather than calculate all the information that represents that frost trol in its entirety, the culling process would remove any of the bits that would be out of your view due

to the rock. It would say, oh, we don't need to calculate this stuff because the player can't see it, so we're just gonna leave that out. We'll just include the stuff that the player can see based upon their angle of view. The rendering engine is only concerned with the bits you can actually see, which is in a way kind of like lossy audio compression formats like MP three you remember, I've talked about that in the past,

where MP three files. One of the reasons they are so much smaller than raw audio files is that they eliminate all the sounds that are, at least in theory, outside the range of human hearing. Because if it's outside the range of human hearing, if we cannot perceive it, there's no need to preserve that information, at least in theory. Rendering also sets the rules for how graphics will pop

into view. So, for example, translucent surfaces things that you can see through have to render in after the opaque surfaces, and that way you can see through the translucent ones properly. So let's say you're looking through Let's say it's a waterfall. It's a very thin waterfall, and you can see through it to the other side. Well, the other side would have to render in first, and then the waterfall would

render in. Uh. And so you can think of it as a sequence that goes back to front, the further away from you, the back surfaces that should come in first, and then the surfaces ahead of time. So maybe there's a lighting uh see, a lighting source that's between the waterfall and whatever is behind it that would look come in next, and then the waterfall would come in last. But this all happens, or at least it should happen very very very quickly. So preferably it's fast enough where

you even be noticeable. It would all just seem to appear at the same time. That's not always the case. If you're playing a very advanced game on high settings, on hardware that can't quite handle it, you'll run into problems when this stuff starts to try and kick in. The rendering engine also has to take other factors into account. The game will send information about textures, and the renderer has to apply those textures to the various polygons in

the view. So otherwise, if you didn't have textures, you would just end up with a messy wire frame universe. It would be very hard to be able to make heads or tails out of anything, especially for very complicated graphics heavy games. It would just be these sets of lines and polygons and you wouldn't be able to tell what is what. After the renderer UH has to calculate the textures, it then has to figure out how bright each surface should be given the light sources in the area.

It has to apply logic to the lighting. So if you have a torch on a wall and you have an object that would be partly illuminated by this torch, some parts of the surface of that object should be brighter than others, and the game engine is responsible for applying this logic in a way that makes sense based

upon where the light sources are in your area. So if you're in a dark corridor aboard a defunct space station, the sparse light sources will highlight some surfaces will leave others in shadow, and the renderer has to take into account all of this when drawing out the scene. It also has to do some collision detection as well, although that will come into play also with physics and AI.

But collision detection is when you have two virtual elements that would come into contact with one another within the virtual environment. So in the real world, if you had real things, they would hit each other. Well, these are virtual objects. They don't they don't have any actual mass. But with good collision detection, virtual elements will appear to move naturally with hard to each other, and they'll appear to have this contact and the reaction to that contact,

and they won't just pass through. Otherwise it would be like you're phasing through solid objects, and that kind of breaks the immersion of a video game if that was not intended. If you want to learn way more about lighting, I recommend reading the Anatomy of a Game Engine articles I mentioned already by Jake Simpson, because he goes into a lot more detail over the various approaches to lighting.

I'm grouping them all in a general category, but there are several different methods to going about lighting scenes in games, and Simpson goes through them and and much more detail than I will hear. I don't want to do a fifteen episode series about game engines. It is fascinating, but it goes further in the weeds than I think we need to for this episode. Will just allow that the rendering engine has to take all these different factors into account to display the assets of the game properly for

the player. Now, one really interesting thing about rendering engines is that if you design it properly, you can make it really modular within the larger game engine itself. Remember, the rendering engine is just one component of the game engine. Now that means you could overhaul the rendering engine for future games, you get more advanced ways of creating, uh

the graphics. Maybe there are new effects that you can apply. Well, you can actually create a new rendering engine and disconnect the old one from your game engine, plug the new one in, and it should work with all the other components seamlessly. If you actually built your game engine in that way, you have to actually have built it this way, but it's possible. You can make this where the rendering

engine is sort of a plug in play approach. It's a little more complicated than that, but that's the concept. It's way easier said than done, but it's one of the ways legacy game jids have stuck around for so long. It's not that people perfected the game engine a decade ago. It's that the game engines elements can evolve over time and plug back into the overall engine itself to give

it more usefulness. Now there's a lot more to talk about when it comes to rendering images, and some of the stuff I'm going to mention in the next section will come back to touch on rendering. But rendering as fascinating as it is and as advanced as it gets with all the different particle effects and lighting effects and texture mapping and all that is only part of the game engine. We still have a lot more to talk about, which I'll get to right after we take this break

to thank our sponsor. The game engine can also play a really important role in sending audio information to computer hardware. Now, again, the audio itself, that's those are assets, But the game engine determines how the audio plays out within the context of the game, and it might send information out to a dedicated sound card, or these days it might be through an integrated audio that's already on the motherboard and

then directly onto speakers or headphones. Back when I got fed up with PC gaming in the nineties, and that was because there were these different graphics and sound cards. They're all battling for supremacy, and getting one set of sound cards or graphics cards could mean missing out on some games that don't support those formats, or getting a less enjoyable experience because you have to emulate something else.

And now I'll have to do a whole episode on the history of sound cards at some point, because it's also really interesting history. But the important thing to remember now is that since or So Intel, what they came out with the a C audio CODAC back that made it possible for hardware manufacturers to include an integrated chip on the motherboard that could emulate a sound Blaster sixteen

audio card. And since then we've seen advances in integrated audio, which has reduced the necessity to have an additional sound card installed on your computer. Back in the day, if you wanted to have really good sound, you had to buy a sound card because the IBM and IBM compatible computers only had a speaker that could create just simple tones, one tone at a time, and there was no variation in volume. So if you wanted any more complexity or sophistication,

you had to get a standalone sound card. That's not the case today now we have these integrated audio features. Some gamers argue that you still want to have a standalone sound card to really get the fidelity necessary for a really good gaming experience. Also, they tend to be better if you want to use voice while you're playing

UM and you want your voice to sound good. Sometimes that means getting your own independent sound card with your computer, But more and more gamers these days seem to rely more heavily on just the uh integrated audio that's on motherboards. The reason I bring this up at all is because if you read the articles by Jake Simpson, they go

into some detail about sending audio to computer hardware. That's a little bit dated because again those articles came out in two thousand two, but game engines still have to be able to set rules for all of those sound elements today. So, for example, let's say you're playing a stealth based game, and audio is really important to this kind of gameplay. You're playing a character that's trying to

stay out of view, You're sneaking around. You need to be able to hear where other characters, monsters whatever it may be, are in relation to your location so that you don't give away your presence, and the quality of audio you here should depend on lots of other factors, such as is the other character Let's say, are they in the same space that you are in are then are they in the same room? Are they in a room next door? Is there a wall or door between you?

Because if there is, that should maybe muffle the sound a bit. You shouldn't hear a person who's in a room over and there's a big wooden door between you. You shouldn't be able to hear them as if they're standing right next to you talking clear as day. You should hear a muffled sound. Maybe you can't even quite make out what's being said. Or let's say that you are sneaking around in an area that's got water and you're you're you're going under the water. The sound should

be different when you're underwater. You should have that that kind of muffled effect. Again, you wouldn't expect it to sound like someone's right there next to you. You might want to have effects like echo involved or reverb, something like that. The game engine can apply those effects to the same audio assets based upon the actual uh context

of the game at that moment. So if you're playing one way, Let's say you're playing the exact same level, but you're playing it in two very different ways, and in one way, you're sneaking underground underneath a surface where people are walking around, you would hear things differently than if you played it a second way and you're sneaking through that room where you're actually going into the room where other people are, you would be able to hear

things much more differently. And the game engine should be able to interpret that information and present it properly because it's applying the rules based upon its understanding of where the player is in relation to the other assets in the game. Some game engines allow developers to import a map into the game engine itself, and then the engine will overlay what is essentially a sound map on top

of the physical map of the game level. The sound map indicates which effects should apply to sounds in various spots depending upon player location, and that can include areas where the nature of sound will change as the player character moves through an environment, so you get dynamics. In other words, you might be jumping off the side of a cliff and you hear someone yelling after you, and their voice might change as you're falling away and change even more. Let's say you plunge into a lake and

it changes even more when you go under water. That stuff is possible because of the logic the game engines used to manipulate these assets. A game engine also typically includes instructions The game needs to accept inputs from control mechanisms so that the player can actually take control of whatever it is they're playing in the game. That can include stuff like a joystick, or a mouse and keyboard, or a game pad, a steering wheel, those sort of

peripheral devices. The two main methods of handling input are called events and polling. So with the events approach, the game engine text incoming input signals like if you hit a button on a game pad or you pull a trigger on a joystick. That incoming signal then activates a custom code that is mapped to that input. So the custom code might say every time the player pulls the trigger on a joystick, it's mapped with a command for

fire the main weapon. The polling is used to monitor position values, like the position of a joystick, whether it's in neutral position where it's centered, or it is being pushed forward or pulled back or moved from one side to the other, or the same thing for the position of a thumbstick or for the relative x y position

of a mouse. As you move these different devices around, that changes that positional value associated with that device, and again that gets mapped to an appropriate action within the game, such as your character turns or moves forward or backward or whatever it might be. One of the biggest challenges

of modern games is online play. It pretty much a standard for most games these days, and in fact, more and more games are acquiring a persistent online connection to even play them at all, even if it's just a single player game. But incorporating online elements introduces a ton of other problems that would be show stoppers if programmers

had to solve for them manually with every single game. So, for example, uh, well, the nature of traffic across the Internet by itself creates tons of potential problems from latency, which is the lag between when you send a command and when it gets executed, two dropped packets which can create errors. So when you think about it, it's actually pretty amazing that we can have online simultaneous play between

multiple players within the same game. If you're in a multiplayer game, let's say you're playing something like Overwatch, for example, every character you see on screen represents another human player playing that game somewhere else in the world, but your instance of the video game, the game you see on your system, has to create the image and make sure it reflects the proper position and orientation of every other

player's character. So if I'm facing down Reaper and Overwatch and Reaper's back is to me, Reaper should not be able to shoot me. I should be confident that the player controlling Reaper can't see me because the character has turned away from me. But this requires my instance of the game to render Reaper accurately, even with those challenges

I mentioned earlier. For that reason, game engines tend to have components that handle the online communication aspects of a game, so that game developers can focus on creating the assets that make the game special in the first place, but not worry about handling all that Internet communications nonsense. Artificial intelligence is another component that can be incorporated partly into a game engine. Typically this would involve using a third

party path finding solution. I'd go into more detail on this one, but I'm running along, and also it starts to get over my head pretty darn quickly, if I'm being honest. But one interesting example I want to point out of how AI can go awry and how pathfinding can become a problem is a game that came out in two thousand and thirteen. It's called Aliens Colonial Marines. A lot of you may have heard of this game.

When it came out, critics and gamers alike complained that the game was buggy and that the enemies would behave in really weird ways. They get stuck in levels, they would all just not behave in a very strategic manner. They would just kind of rush at the player and a mode. While exploring the game's code, discovered that in one of the initialization files for the game, there was a typo. There was a line of code that was meant to attach AI components to a specific points on

a map. They called it tethering, and it would give the AI the ability to behave in a tactical way within certain sectors or tethers of a level. But in this line of code, the word tether t E t h E R had a superfluous A. In it, it was spelled as t e A t h e R,

almost like heather, and that was a typo. Removing the A using just a regular editor program and then executing the game again created an experience more like what the developers had intended, with AI suddenly becoming more of a threat to the player being able to behave in a more strategic way. It didn't solve all the problems that game had, but it definitely solved a big one. So the game engine in this case was performing properly the

whole time. It was just because there was a typo in the code that was being executed in the game engine that the problem was happening at all. Then we finally have a physics engines. These are components that determine the physical rules within the virtual world. So, if you're talking about a first person shooter, if you drop a weapon, does it fall to the ground? If so, how fast? How strong is gravity? Does it float away? How far can you jump? How fast can you run? How far

can you fall without taking any damage? If you knock out an opponent, does the opponent disappear? Do they flop realistically like a rag doll? Does have the rag Doll physics that became really popular ballad decade ago and are

still popular today. These sorts of things and more, including how effects behave in different environments, all depend upon the physics engine, and this is also the main part of the engine that determines things like collision detection and what happens if two virtual objects actually make contact within the game, or how a solid stiff object moves through a space

as opposed to a more Bindi floppy object. So there are a lot of off the shelf physics engines out there that you can plug into a game engine, just as there are off the shelf tools for building in game models. UH. The physics engines have names like Havoc, which started out as a physics engine component from an Irish company. Now it's owned by Microsoft. UH. There's other ones. There's like Newton Game Dynamics that's an open source physics engine,

but there there's several out there on the market. Physics engines use lots of different techniques to create or simulate real world physics in a virtual world, and just like game engines, there's not just a single way to achieve this goal. There are lots of different approaches, but they all try to do the same thing, they just try to do it in different ways. And there's so much more I could go into, like the graphic user interface design for the game or the scripting process for developers

where outcomes will occur when certain triggers are hit. But you get the idea. I think the game engine is the facilitator that ultimately translates the content that developers have created into meaningful information for a computer system, so that the right stuff off happens at the right time, at least ideally. Sometimes just bad code makes bad things happen. And there are a lot of different game engines out there in the wild. Here are a few notable ones.

I opened the show talking about Doom. While the ID Tech game engine is still being used largely by independent game developers, but others as well. The Unreal Engine is one of the most famous game engines out there. It was created by Epic Games. It's named after the Unreal Tournament series of shooter games, but it's been used for tons of other games to including stuff like Gears of War and Mass Effect. Unity three D is another big game engine that one's from Unity Technologies. It's used by

a lot of independent and mobile games. The Cry engine was developed by cry Tech for games like far Cry e A Dice uses a game engine called frost Bite as the foundation for games like Battlefield. Other developers have their own proprietary game engines. For example, rock Star, which makes the Grand Theft Auto and Red Dead Redemption series, uses the rock Star Advanced Game Engine or RAGE to

power its games. Insomniac Games created a special game engine for their title Sunset Overdrive, and then used a modified version of that game engine for the recent Spider Man game for the PS four. Now. Ultimately, these game engines create an environment so that developers can focus on those elements that define a game without having to fuss over the minute mathematical details. The game engine handles all of that.

So I hope that is a good overview of what game engines are and how they work from uh, from a a basic standpoint. Obviously, getting deep into it would require a whole series of episodes getting very technical and very specific, because again, different game engines do this in different ways. But it is a fascinating topic and hopefully that lets you know a little bit more about what it means when someone talks about a game engine and what it does, and whether it's a good game engine

or a bad game engine. You understand a little bit more of where that's coming from. If you guys have any suggestions for future episodes of tech Stuff, maybe it's a technology, a company, person in tech. Maybe there's someone I should interview or have on as a guest. Let me know, send me your suggestions. The email address for the show is tech Stuff at how stuff works dot com, or drop me a line on Facebook or Twitter. The handle of both of those for the show is text

stuff H s W. Don't forget. You can go over to T public dot com slash tech stuff. That's T E E public dot com slash tech Stuff. That's where we have all of our merch. You guys really like the code like a girl T shirts and so do I. I love that one. But we have tons of other stuff on there, including our tech Stuff capture shirt, prove that You're not a robot and more. So go check those out and follow us on Instagram and uh yes,

that's it. I'm done. I'll talk to you again really soon for more on this and thousands of other topics. Is it how stuff Works dot com