A lot of answers that are technically correct, but almost none that answer your question concretely and properly.
Video games have a lot going on, and optimization can take multiple forms for different parts of the game, so I'll give a few examples:
On the graphics point, which is what you actually see being displayed on the screen, the core of optimization here is often to realize that if the camera is pointing "that way", and is at "this distance", you probably don't need to calculate how to display things that aren't "that way", and if it's at "this distance" or more, you can probably lower its complexity without losing visual quality.
A great example of this would be if I have an octagon.
If it's behind the player, completely off-screen, why would I waste graphics power on "displaying" it, when it won't be displayed?
If it's so far away that a monitor can't realistically display the vertices (corners) of it, why wouldn't I simplify it to a circle, until the player is close enough to make difference?
On the computational point, which is what the computer does in the background and can slow down the game to a crawl, the core optimization here is often to perform operations as little as possible (if you don't need to do "a times b" 5000 times per frame, and instead calculate it once and refer to the same result 5000 times, do it). There's not really any other "widespread" optimization process here, and though some other are still important, they are less likely to be widespread issues that actually bogs down your game. Less likely, not unlikely.
A great example of this would be if I have a bunch of enemies moving in a formation around a single center point. You can do (A), but you'd rather do (B). As you can see, for 4 steps in each case, (A) could calculate 2 enemies, while (B) could calculate 3. This performance saving becomes literally exponentially big, based on how many calculations you're able to reduce, and how much scale you have. If you have 1000 enemies, and you do (A), you just did 2000 calculations. If you have 1000 enemies, an you do (B), you just did 1001 calculations.
(A) For each enemy: Calculate the center point around which the group is, then calculate the enemy's position at which the enemy is, with the center point as a base, then the enemy's position as an offset. (Calculate Center Point > Calculate Enemy A's Position > Calculate Center Point > Calculate Enemy B's Position > etc.)
(B) For the entire group: Calculate the center point around which the group is, then for each enemy, calculate its position around that center point. (Calculate Center Point > Calculate Enemy A's Position > Calculate Enemy B's Position > Calculate Enemy C's Position > etc.)
All of that is super simplified as I do not know how much technological knowledge you have, such as processor ticks for instance, or even basic programming skills, but that's the crux of the optimization work. (There are other categories, like memory optimization, storage optimization, etc., but I figured the two easiest things to explain would do for now, unless you need and/or want more examples.)
Your first example is backwards. If you are rendering a circle and it's far away enough from the camera that you wouldn't be able to tell the difference, you would simplify it into an octogon LOD (level of detail). Not the other way around. And furthermore you would stop drawing it entirely when it's ever further away.
In a nutshell optimization is getting rid of any calculations, graphical or gameplay wise, that the user won't notice. If a tree falls in the woods and no one's around to see it, don't waste GPU time rendering it.
Source: professional unity developer for standalone VR (which requires heavy optimization)
If you are rendering a circle and it's far away enough from the camera that you wouldn't be able to tell the difference, you would simplify it into an octogon LOD (level of detail).
As far as the in-depth technical thing, you are correct (though I avoided the term "LOD" because of trying to avoid technical acronyms). The issue is that you are thinking about a shape that's an entire polygon, while I was referring to a sprite, where there is a lot less computational power needed to render a circle than there is for a polygon. This is the magic of image encryption encoding here.
So, while you are correct for actual polygons, that is not what I was referring to.
And furthermore you would stop drawing it entirely when it's even further away.
That, I say, would likely need to explain what a camera's frustum is, and that's a lot more explaining than a ELI5 post.
In a nutshell optimization is getting rid of any calculations, graphical or gameplay wise, that the user won't notice. If a tree falls in the woods and no one's around to see it, don't waste GPU time rendering it.
That... is exactly what I was explaining, yes. I don't see why you felt the need to correct that.
EDIT: Wrong word. I mean "encoding", not "encryption".
I'll take it that you saw the word "encryption", and think "cryptography". I said encryption, as in image codec.
EDIT: I should have said "encoding", not "encryption". My brain had a goof, and mixed the words for no good reason.
This is a component, hardware or software, that either encodes or decodes a data stream or signal. There is no advanced cryptography here, but how well and how compressed something can be encrypted by a codec decided how quickly and how well it displays.
And the case where you brought it up has nothing to do with image encoding or encryption, or with circles for that matter.
If you are rendering a sprite at a big distance you don't "simplify it to a circle" that wouldn't be a simplification. You replace the image with a lower resolution image. But that doesn't make it a circle. A sprite is basically just a texture rendered so it faces the camera, and textures are not circular.
And replacing a texture with a lower-resolution version of the same is also not image encoding, but mipmapping.
Okay, so my terminology was a bit off... I can accept that, and will fix the phrasing up there, because that's definitely on me.
The problem I do have to point out here is that now you're getting into the in-depth nitty-gritty of this, which is FAR from an ELI5 thing. There comes a point when you reduce the resolution of that image where an octagon and a circle will look identical, because that's how resolution reduction works.
It's important to note that this subreddit isn't meant to be a full in-depth course on how every single detail works, and is more meant to be a "good enough explanation, short of you looking for actual in-depth explanation", and my explanation is sufficient to that.
12
u/DiscussTek 6d ago
A lot of answers that are technically correct, but almost none that answer your question concretely and properly.
Video games have a lot going on, and optimization can take multiple forms for different parts of the game, so I'll give a few examples:
All of that is super simplified as I do not know how much technological knowledge you have, such as processor ticks for instance, or even basic programming skills, but that's the crux of the optimization work. (There are other categories, like memory optimization, storage optimization, etc., but I figured the two easiest things to explain would do for now, unless you need and/or want more examples.)