The recent The Last of Us for PC made me realize I had no idea what’s meant by “optimizing” a game.
Same with optifine in Minecraft improving performance. How do these things work to just make games use fewer resources?
In: 158
Often in program code there’s multiple ways to do something and the simplest way often isn’t the fastest way. Sometimes the fastest way is just downright ugly and horrible to look at. When you’re working on some giant program that’s still changing and more stuff is being added to it, often it’s better to pick the simplest way even if it’s slower. This is because programmer confusion is a huge source of bugs, where multiple humans are going back into the same program and changing each other’s stuff as more gets added. Anything to cut down on programmer confusion during this phase is a good thing. You need for all your programmers to easily and quickly understand what each other did.
This is one reason to deliberately NOT pick the most fast, optimal way to write the program. Programmer time is way more expensive that CPU time, and making things more complex (as is often needed to pick the fastest solution) increases programmer time.
Another reason to deliberately not pick the most fast, optimal way is because in the early stages nothing is set in stone yet. Writing an optimal fast version of the program is often based on a lot of assumptions like “this scenario cannot happen, that scenario cannot happen, therefore we don’t need a generic solution that handles them…” But if the assumption “this scenario cannot happen” is based on a current design that is likely to change, it’s not safe to write code that depends on it.
Later, toward the end, when all aspects of the design are more set in stone, and you aren’t adding new features as much, it becomes safer to go in and make previously simplistic crude code into much faster but harder to understand code.
Often in program code there’s multiple ways to do something and the simplest way often isn’t the fastest way. Sometimes the fastest way is just downright ugly and horrible to look at. When you’re working on some giant program that’s still changing and more stuff is being added to it, often it’s better to pick the simplest way even if it’s slower. This is because programmer confusion is a huge source of bugs, where multiple humans are going back into the same program and changing each other’s stuff as more gets added. Anything to cut down on programmer confusion during this phase is a good thing. You need for all your programmers to easily and quickly understand what each other did.
This is one reason to deliberately NOT pick the most fast, optimal way to write the program. Programmer time is way more expensive that CPU time, and making things more complex (as is often needed to pick the fastest solution) increases programmer time.
Another reason to deliberately not pick the most fast, optimal way is because in the early stages nothing is set in stone yet. Writing an optimal fast version of the program is often based on a lot of assumptions like “this scenario cannot happen, that scenario cannot happen, therefore we don’t need a generic solution that handles them…” But if the assumption “this scenario cannot happen” is based on a current design that is likely to change, it’s not safe to write code that depends on it.
Later, toward the end, when all aspects of the design are more set in stone, and you aren’t adding new features as much, it becomes safer to go in and make previously simplistic crude code into much faster but harder to understand code.
Often in program code there’s multiple ways to do something and the simplest way often isn’t the fastest way. Sometimes the fastest way is just downright ugly and horrible to look at. When you’re working on some giant program that’s still changing and more stuff is being added to it, often it’s better to pick the simplest way even if it’s slower. This is because programmer confusion is a huge source of bugs, where multiple humans are going back into the same program and changing each other’s stuff as more gets added. Anything to cut down on programmer confusion during this phase is a good thing. You need for all your programmers to easily and quickly understand what each other did.
This is one reason to deliberately NOT pick the most fast, optimal way to write the program. Programmer time is way more expensive that CPU time, and making things more complex (as is often needed to pick the fastest solution) increases programmer time.
Another reason to deliberately not pick the most fast, optimal way is because in the early stages nothing is set in stone yet. Writing an optimal fast version of the program is often based on a lot of assumptions like “this scenario cannot happen, that scenario cannot happen, therefore we don’t need a generic solution that handles them…” But if the assumption “this scenario cannot happen” is based on a current design that is likely to change, it’s not safe to write code that depends on it.
Later, toward the end, when all aspects of the design are more set in stone, and you aren’t adding new features as much, it becomes safer to go in and make previously simplistic crude code into much faster but harder to understand code.
I had to do this within my own game and basically it means exactly what it sounds like. But more from a problem solving sense. You have to find ways to accomplish the same things with less processing and less memory. Some good examples from my experience were reducing the number of computations required to move objects, consolidating similar repetitive code into reusable scripts, decreasing the number of objects being rendered during a single frame by pausing enemies and bullets that were off screen. Lots and lots of things like that. Hours and hours of work and debugging. Trial and error. Creating simplicity from complex problems.
Game engines can do pretty amazing things. However if they aren’t optimised properly they can ruin a game. From a Level Designers point of view. Levels are full of geometry. Some factors that impact on performance are the number of triangles (Tris), Drawcells, Shadowcells, LOD, number of Entities (things that do stuff like doors and bots) and Vis Portals.
These things need to be optimised. One way to reduce Tris is to have the engine only draw things the player can actually see. Vis Portals control this. This video will explain this. This is the game The Dark Mod. More modern games are much more refined methods.
Game engines can do pretty amazing things. However if they aren’t optimised properly they can ruin a game. From a Level Designers point of view. Levels are full of geometry. Some factors that impact on performance are the number of triangles (Tris), Drawcells, Shadowcells, LOD, number of Entities (things that do stuff like doors and bots) and Vis Portals.
These things need to be optimised. One way to reduce Tris is to have the engine only draw things the player can actually see. Vis Portals control this. This video will explain this. This is the game The Dark Mod. More modern games are much more refined methods.
I had to do this within my own game and basically it means exactly what it sounds like. But more from a problem solving sense. You have to find ways to accomplish the same things with less processing and less memory. Some good examples from my experience were reducing the number of computations required to move objects, consolidating similar repetitive code into reusable scripts, decreasing the number of objects being rendered during a single frame by pausing enemies and bullets that were off screen. Lots and lots of things like that. Hours and hours of work and debugging. Trial and error. Creating simplicity from complex problems.
Game engines can do pretty amazing things. However if they aren’t optimised properly they can ruin a game. From a Level Designers point of view. Levels are full of geometry. Some factors that impact on performance are the number of triangles (Tris), Drawcells, Shadowcells, LOD, number of Entities (things that do stuff like doors and bots) and Vis Portals.
These things need to be optimised. One way to reduce Tris is to have the engine only draw things the player can actually see. Vis Portals control this. This video will explain this. This is the game The Dark Mod. More modern games are much more refined methods.
I had to do this within my own game and basically it means exactly what it sounds like. But more from a problem solving sense. You have to find ways to accomplish the same things with less processing and less memory. Some good examples from my experience were reducing the number of computations required to move objects, consolidating similar repetitive code into reusable scripts, decreasing the number of objects being rendered during a single frame by pausing enemies and bullets that were off screen. Lots and lots of things like that. Hours and hours of work and debugging. Trial and error. Creating simplicity from complex problems.
Optimising is a process, it isn’t one specific thing you do. Basically any change you make to improve program performance is optimisation, and that’s generally achieved by using fewer system resources.
It can be anything including removing unnecessary code, simplifying complex code, taking shortcuts, hardcoding things with safe assumptions, using different code that works better with certain platforms/hardware. Sometimes you can tweak things to achieve massive performance gains with minimal noticeable impact.
Latest Answers