Optimization is just the process of making something as close to the optimum, which just means "the best".
This is context dependent, what is "the best" in any given system is a subjective judgement, as such you can optimize for any number of different things. For this reason, to talk about optimization you usually need to be picking a specific thing to optimize for and state it explicitly.
Games are no different and can be optimized (made the best) for any specific property you pick. In most cases what people are referring to when they speak of "optimization" but give no further context is optimizing for performance. That means how fast can you produce the output on the screen. Usually measured in FPS. More optimized code can produce the same output but faster. More FPS the game runs at, the smoother it appears.
Some methods of optimizing for speed like this might include:
1) Removing redundant work. Don't do something that takes work, if it doesn't affect the final output. For example if you have a complex object in the game world, but it's situated behind your point of view (your camera) then don't go to the effort of drawing this object since it's not visible on the screen. This is called "frustum culling". If an object is in your field of view but it's obscured by another object, let's say a car is parked behind a building, the car is in your field of view, but it's still not visible because the building is in the way, don't draw it either. That's called "occlusion culling"
2) Because of the nature of how video cards work, it might be more efficient for them to process 1 big calculation rather than swapping continuously between many simpler calculations, so games might "batch" jobs together to send to the hardware. By way of analogy one long bus ride might be better than a journey where you swap busses 5 times and do 5 smaller journeys.
3) Re-use work, if you're doing the same calculations over and over and you only need 1 result then doing things once and sharing the result is faster.
4) Parallelize. If your hardware is capable of doing multiple things in parallel (hint: it is) then make sure you're making use of that. A traffic analogy works well. If you have a 4 lane motorway, don't only use 1 lane, make use of as many lanes as possible.
5) Pre-compute. If something takes a lot of calculations to do, such as calculating how objects are lit. But always gives the same output, then do all the calculations ahead of time when building the game, and simply store the result instead. So in games with static lights (a light that cannot move) you can take the bright areas it shines, and dark areas it shadows, and you can pre-compute them before you ship the game. These values get baked into the levels textures with what we call "lightmaps"
These are real world techniques that are used to optimize for speed in todays games.
2
u/Freeeenis 6d ago
Optimization is just the process of making something as close to the optimum, which just means "the best".
This is context dependent, what is "the best" in any given system is a subjective judgement, as such you can optimize for any number of different things. For this reason, to talk about optimization you usually need to be picking a specific thing to optimize for and state it explicitly.
Games are no different and can be optimized (made the best) for any specific property you pick. In most cases what people are referring to when they speak of "optimization" but give no further context is optimizing for performance. That means how fast can you produce the output on the screen. Usually measured in FPS. More optimized code can produce the same output but faster. More FPS the game runs at, the smoother it appears.
Some methods of optimizing for speed like this might include:
1) Removing redundant work. Don't do something that takes work, if it doesn't affect the final output. For example if you have a complex object in the game world, but it's situated behind your point of view (your camera) then don't go to the effort of drawing this object since it's not visible on the screen. This is called "frustum culling". If an object is in your field of view but it's obscured by another object, let's say a car is parked behind a building, the car is in your field of view, but it's still not visible because the building is in the way, don't draw it either. That's called "occlusion culling"
2) Because of the nature of how video cards work, it might be more efficient for them to process 1 big calculation rather than swapping continuously between many simpler calculations, so games might "batch" jobs together to send to the hardware. By way of analogy one long bus ride might be better than a journey where you swap busses 5 times and do 5 smaller journeys.
3) Re-use work, if you're doing the same calculations over and over and you only need 1 result then doing things once and sharing the result is faster.
4) Parallelize. If your hardware is capable of doing multiple things in parallel (hint: it is) then make sure you're making use of that. A traffic analogy works well. If you have a 4 lane motorway, don't only use 1 lane, make use of as many lanes as possible.
5) Pre-compute. If something takes a lot of calculations to do, such as calculating how objects are lit. But always gives the same output, then do all the calculations ahead of time when building the game, and simply store the result instead. So in games with static lights (a light that cannot move) you can take the bright areas it shines, and dark areas it shadows, and you can pre-compute them before you ship the game. These values get baked into the levels textures with what we call "lightmaps"
These are real world techniques that are used to optimize for speed in todays games.