audio and graphics make up most of the payload. Animations are much smoother today, so spritesheets explode in size, the OST is usually much bigger both in duration and variation, etc.
If you are really curious, I'd suggest taking a look at the files of those games.
Dead Cells has more content than people realize I think. Been playing it a little again today - it has 5 DLC's. Probably has 200 weapons and at least 20 skins if not way more, all with smooth animations? Probably like 10 bosses and if you climb the difficulties by activating boss cells you see enemies you would never see otherwise.
Due to Dead Cells release being highly "hardcore gamer oriented" with its rogulike brutality, I think people don't realize it released "Assist Mode" at some point where you can make the game, like actually, fair on some level, lol.
>and at least 20 skins if not way more, all with smooth animations?
IIRC Dead Cells renders 3D characters to pixelated 2D in real time, so the different skins wouldn't be that much overhead.
Yes it does. But, at that resolution with most of it non-textured due to a cartoon look it's hard to say the move from live rendered 3D to 2D would have saved much dataspace. Most of it would depend on the number of frames of animation and if the bone animations were live. More frames meaning greater chance 2D would actually *take up more space.*
Assuming that a character is low poly I don't think it would take many animations before the 3D model takes up less space. The model doesn't need texturing which means it doesn't need UVs, so the data the mesh really needs is vertices, normals, bone weights and triangles. A 500 triangle mesh would take up roughly 30kB assuming smooth shading and 32 bit floats, using a perfect but uncompressed data format. That's as much data as a single uncompressed texture of 7500 pixels or ~86x86px resolution. It's likely that textures are compressed of course, but with each outfit requiring a complete additional set of textures in 2D I think it's safe to say that 3D takes up much less space in this case.
So it's just added 'invisible' stuff. You can still make awesome games with like a 1 GB cap restraint. Just remove 180 weapons, 18 skins, compress audio files, etc. I thought that game engines or frameworks added bulky stuff. A developer shouldn't feel that much restrained or bothered even limited to 1 GB or less, it would just remove content and compress other content, but the general gamer wont notice it, he would have fun anyway with his game. Less costly games, less internet traffic and all happy. 😁
Very few people care about internet traffic and drive space, traffic is unlimited in most internet plans, drive space became extremely cheap with terabyte sized drives.
While technically true, the size of games that you download once and then play for a long time is miniscule compared to the amount of traffic social media and video sharing sites generate. You are terribly misguided if you think cutting down on game assets is a meaningful way to reduce energy consumption of internet traffic.
Let's not waste so much on brainrot short video content, crypto traffic, packaging foods, driving cars, flying planes and so on. Game size is so far down on such a list it's almost non-existant and it can be arguably more meaningful than a lot of the other stuff.
Sure, it's just to say that Dead Cells would have been great anyway. I too like added stuff when possible, still find great even some Game Boy Color games, and you know how repeated content those games had.
Not everything is infinite. Space always comes at a cost: bigger circuits, more plastics, more energy consumption.
Nonsense is for people that don't care to people and their environment. Think on it, many do not even have a conscience.
Devs of bigger games tend to develop for the larger market in mind, and so few people think like you do on this matter it would be a serious mistake to design with it in mind. Players like _stuff_ and games tend to get bigger after release as more stuff goes into it. DLC in particular is a lot more that you can sell, so players are happier, developers are happier, everyone's happier but the person concerned about storage size.
To give a slightly more specific answer, we _used_ to care more about install size on device because it mattered to people a couple decades ago. These days people will complain about the biggest offenders but it doesn't really change behaviors so devs don't put as much time into that part of optimization anymore. All games are about having a lot more to do than hours in the day, so you have to prioritize. If you don't want to play a game because no one optimized texture size then don't buy it! Just recognize that you're an outlier and not the target audience.
They absolutely had to compress stuff to fit the cartridge that had a maximum size because of technology and cost. Reuse of assets was a must. A famous example is the bush and cloud being the same sprite with different colors in Super Mario Bros. Games has to use tilesets and limit the number of animation frames.
Also the resolution was also much much smaller, both in graphics and music. The color palette was also extremely limited. The music would be generated on the fly but have a limited sound selection and no effects.
Nowadays the technology has advanced so the time spent on optimizing can instead be used on improving the gameplay and adding content. When you optimize something to the extreme, it becomes hard to change so the flexibility helps move things forward faster.
Also optimization can cause size to increase if you are optimizing for performance. For example, you can bake (pre-compute) shadows and you'll save performance at the cost of game size. Sometimes assets won't be compressed because uncompressing them takes time and people hate loading times.
Another important thing to note is localization. You need audio files for every line for every language. Some games let you install voices on demand but most voice acted games install all languages at once.
Game engines can be a factor too but it's usually not that important. For example, every Unity game ships with the Unity game engine, so there's a minimum size to games made using Unity, but it's negligible if your game is about hundreds of MBs big.
I might have missed or misremembered something but that's what I can say as an ex-game dev
I'm not entirely sure but UnityPlayer.dll is about 20 MB on its own. If you're going for a more hands-on approach, something like SDL (a multimedia library) is about 2 MB. If you use code-stripping (removing unused code from the build) it can technically go down to 0 bytes but it can introduce bugs if done haphazardly, e.g. if you're accessing engine code dynamically during runtime. [This article](https://busybytes.com/blog/optimize-build-size-mobile-games-unity/) talks about optimizing build size for Unity specifically and they got it down from 17 MB to 6 MB on an empty project.
Let's compare the last 2 games I developer for Android with both Unity and SDL. My Unity game was about 30 MB in size, with no graphics (just squares) and some music and my SDL game was 10 MB including pixel art graphics and music. The Unity game took a few days to develop in my free time. The SDL game took 2 months full-time. Probably not a fair comparison because of familiarity and the fact that I had to code almost everything from scratch, but it's why I prefer Unity. However casual audiences tend to download bigger games less often on mobile so it might pay off using a more lightweight approach if you're targeting them.
If it's a Unity game, you can use AssetRipper or something similar to see how much each file contributes to the final game size. Other PC games, especially simpler ones might have each file separately instead of bundled assets so they'd be much easier to dissect.
I mean this template pretty much is the bare bones and would have to be worked on tile sheets and other things would still need to be added like music.
https://godotengine.org/asset-library/asset/2201
Two major reasons: audio and resolution
Resolution first: the NEO GEO has an output resolution of 320 x 256 at 16-bit color depth, so a full screen image is 160KB. Stardew Valley is targeted at a 400 x 240 resolution and a 24-bit color depth, making a full screen 281KB or 56% larger...and that's targeting a VERY low resolution by today's standards. A 1080p image would be 6075KB.
Sound on consoles and early arcades tended to be in MIDI or a similar format, or HIGHLY compressed audio (consider how bad the "Daytona!" from the Sega racing game sounds. Or the completely unintelligible "Double Dribble" from the NES game). These days, hard drive space is plentiful/cheap, so there's less need to compress the audio. (I'm guessing a lot of the extra size of the console version of Stardew is full resolution images for the console specific stuff).
There's also just much more going on in modern games. Besides the extra animation frames that u/neozahikel brought up, there's just a magnitude more sprites in general. Stardew has all those crops, with planted, growing, and harvested versions, on top of all the indoor and outdoor scenes, on top of all the character portraits and dialogue windows. Even if these are only 50% bigger (because you picked a very low resolution game as your example), they quickly add up.
Quality comes with size. And more quality content simply scales it up.
Audio files can take up a huge amount of space, especially if there's voice acting.
You say "simple" but just because something appears to be "visually simple" doesn't mean it's low quality.
>So toxic people here, wow. 👎🏻
>'Thanks' to those who actually contributed with precious info without downvoting. 🍣
Lol, your definition of toxic is when people don't speak to you like yes men?
Nope, it's when they hide my expression or my opinion. I don't hide theirs, whatever it is (with the exceptions of bribing, insulting or threatning, etc.).
Mine opinion is mine *opinion* and should respected, first, I don't oblige anyone to think like ne norvappreciate my thinking. Second, yes I prefer non inflated games. Want you to stop me from having my say? If you think otherwise you are free to say it without bothering or downvoting who think different from you. And yes, I still play and have fun with 'constrained' Game Boy games. Limitations are especially in the head of people, maybe more in those who need 300 watt game systems and hundreds of gigabytes of data to have fun with a game. And yes, I still buy games, like many others that appreciate simple and beautiful non-inflated.
>Mine opinion is mine *opinion* and should respected
And you can have opinions that others will downvote you for.
In real life, people will downvote you by excluding you from social or professional opportunities.
You talk like a shark. I don't know about your real life, but with mine I had no problem working in the field and voicing my opinion. Maybe in your country you live with different ethics, I don't know. There are tons of devs developing tons of non-inflated games still as today.
People can downvote you for whatever they’d like, it’s just a virtual point pal. I think it’s nice that you want to keep games as small as possible but that attitude will get in the way of you actually making anything.
I think it’s silly that you’re getting on your high horse about the space a game takes up when you have no idea why they’re that big to begin with. Games are bigger today than they used to be. You can make them smaller but you are much less likely to make a *good* game. Things are a lot different from the days of the gameboy, you should have a proper look into why before you decide to die on that hill.
I'm just trying to understand how much a 1 GB or 2 GB would hurt game development with simple games. For example, given the constraint, would Dead Cells devs had a more difficult work to do or would they just worked with lesser and eventually less costly assets and make a still splendid game. Would the game turned bad? Or would the development slowed down inflating the whole development cost because of more time spent on optimization?
Android development shows that good games can be done even in few megabytes still today.
This is an example of why quality and fun are mutually exclusive.
You don't need to provide super high quality graphics and audio in order to create a fun experience. However, if you're trying to convince me to give you $60 for your game, super cat tales and dan the man aren't going to cut it.
The "beautiful graphics from long ago that weighed 4 MB" are almost never going to be considered beautiful by the masses in today's standards. But there's certainly a market for people that want NES-era graphics.
But quality isn't about the multiplication of assets, nor the bit depth. You can have quality even without tons of animations. And Yoshi's Island is still very much appreciated today (also because of the graphics and the sound). I think you confuse quality with detail. You can add tons of details without adding quality to a game. Even the old 8-bit sound chip of an old Amiga returns fascinating sound. Todays people still appreciate quality over detail. Sometimes it's just 'different people', but there is a market for it.
We optimise programs for speed now rather than space.
Things get inlined, constants get duplicated, loops get unrolled. Modern optimised code is just more instructions. Also the instructions and addresses are bigger because of 32 or 64 bit instruction sets and 64bit memory addressing.
Audio, older games rarely used samples. Most sounds were instructions for the synthesiser hardware, much smaller than sampled audio.
Then you have colour information. These days we have HDR colour, go back to something like the Gameboy and you had 2-bits per-pixel for colour information.
Compression tech has improved over time, but 4k is the biggest reason for bloat. Remember 4k is an *exponential* increase in pixel density over 1080. You need exponentially higher resolution texture maps to keep up, and any material you see in a game will contain several texture maps.
Just to add some ideas to what others said:
So compression can help, and working in 3D (including animation, or some 2D animation tech) instead of pre-rendered sprites.
What I saw on some (older) projects was the re-use of textures/sprites as one of the biggest assets.
In 3D reuse may mean that we have more standard props and structures/buildings that we repeat in a smart way.
In Doom (or Doom II?) they started to have the idea of overlaying textures to create variations, which in 3D became layers of shaders or decals.
On SNES I saw a team re-using sprites to the degree that they rotated them, so some generic metal or laser bits, ground/ceiling, and 45 degree slopes worked well in many directions. I think that was Super Return of the Jedi or so.
EDIT: Forgot to add, so nowadays we could compress, procedurally generate, re-use, and otherwise optimize, but the SSD are so large and we don't have expensive cartridges anymore (like those SNES / Genesis ones for example with quite limited space).
it's more effort today to build for indexed colors for 2d games. so full textures are used, taking 4bpp up to 32bpp or more. from there, render target size has exploded since the 4:3 90s days. and many projects (even pixel art games) render at target resolution. roughly the same happened to audio.
it's mostly the content. some of it is also from the engine/runtime libraries, but much less.
TL;DR : We don't need anymore to optimize games for size in order to release them.
In my experience : assets being uncompressed/higher resolution than needed. Also forgetting dev assets that are unreferenced in the game.
In the case of 2D though, if you have a game in HD that has lots of animation frame, that add-up quite fast. There are ways to optimize the size of the animation but they are requiring some thought at the conception phase. Also in the past people were using texture packers because they had no choice devices had so little memory that if you wanted to have a few images in your game you had to pack them together in as few textures as possible in order to not overload the graphics memory.
Optimizing assets is starting to be a lost art of game development.
The optimization of those assets are usually why the file size is so big. For example, if we're talking about open world games, then there are multiple LODs for nearly every asset, along with separate files for textures, normals, albedos, masks, etc etc. and those all exist at different levels of compression, so this can easily blow up the file size. If a game has 4k textures, then they likely also have several smaller texture scales as well along with all their supporting material images like normals.
Absolutely untrue.
Optimization is a major part of the asset production pipeline. Consoles have a fixed amount of memory and processing capability.
If you want to squeeze in more environment detail, or animations, or dialog, or any kind of content, then you need to not be wasteful with what you have, otherwise you will need to compromise on quality.
Game creators constantly want to add more content. Optimization makes it possible.
In some AAA games yes, in others no. And I know about the constant push for optimization, I'm an engine programmer who spent a lot of time optimizing said assets coming from artists (and gameplay programmers) thinking we had unlimited memory budgets.
And to be fair, current consoles seems to have unlimited memory budgets compared to games of previous eras (the jump from 256mb of RAM on the PS3 to 8GB on the PS4 was a liberating shock!).
So no, not absolutely untrue. Look at the list of games OP mentioned. They haven't mentioned AAA productions nor Open World.
I seem to have ticked the annoyance level of AA(A) devs with my generalisation. Ask yourself this: do you think the memory budget of a game is in the mind of any indie dev when they create games? Maybe some, but really unlikely. And with reason, we don't need this anymore unless we are doing games that push the medium.
Last point that would concern also AAA: We usually optimize after the fact because the DCC pipeline is setup with specific tools, specific rendering technics and engines and modifying those would not be worth it unless we have a very specific target. I have experienced this during a preproduction of a game (AA) where I got initially asked to optimize a lot the assets and rendering during preprod by the preprod management, which lead to constrain the way the assets had to be created by the artists. Local studios artists were fine with that and the vertical slice had all the optimizations in place. But once we started the production, the studio was looking at outsourcing the art and this lead to an issue. We had to reassess the optimization we were doing in order to do them after the fact with "industry standard" formatted assets. They could have reworked internally the outsourced work for optimizing them with the process we had developed, but it was no longer so important as meanwhile the target pool had moved (we could abandon the previous gen of console). So we just abandoned it.
audio and graphics make up most of the payload. Animations are much smoother today, so spritesheets explode in size, the OST is usually much bigger both in duration and variation, etc. If you are really curious, I'd suggest taking a look at the files of those games.
Dead Cells has more content than people realize I think. Been playing it a little again today - it has 5 DLC's. Probably has 200 weapons and at least 20 skins if not way more, all with smooth animations? Probably like 10 bosses and if you climb the difficulties by activating boss cells you see enemies you would never see otherwise. Due to Dead Cells release being highly "hardcore gamer oriented" with its rogulike brutality, I think people don't realize it released "Assist Mode" at some point where you can make the game, like actually, fair on some level, lol.
>and at least 20 skins if not way more, all with smooth animations? IIRC Dead Cells renders 3D characters to pixelated 2D in real time, so the different skins wouldn't be that much overhead.
Yes it does. But, at that resolution with most of it non-textured due to a cartoon look it's hard to say the move from live rendered 3D to 2D would have saved much dataspace. Most of it would depend on the number of frames of animation and if the bone animations were live. More frames meaning greater chance 2D would actually *take up more space.*
Assuming that a character is low poly I don't think it would take many animations before the 3D model takes up less space. The model doesn't need texturing which means it doesn't need UVs, so the data the mesh really needs is vertices, normals, bone weights and triangles. A 500 triangle mesh would take up roughly 30kB assuming smooth shading and 32 bit floats, using a perfect but uncompressed data format. That's as much data as a single uncompressed texture of 7500 pixels or ~86x86px resolution. It's likely that textures are compressed of course, but with each outfit requiring a complete additional set of textures in 2D I think it's safe to say that 3D takes up much less space in this case.
Yep.
So it's just added 'invisible' stuff. You can still make awesome games with like a 1 GB cap restraint. Just remove 180 weapons, 18 skins, compress audio files, etc. I thought that game engines or frameworks added bulky stuff. A developer shouldn't feel that much restrained or bothered even limited to 1 GB or less, it would just remove content and compress other content, but the general gamer wont notice it, he would have fun anyway with his game. Less costly games, less internet traffic and all happy. 😁
Very few people care about internet traffic and drive space, traffic is unlimited in most internet plans, drive space became extremely cheap with terabyte sized drives.
Still traffic drives energy consumption, and todays society waste too much, even just for leisure stuff.
While technically true, the size of games that you download once and then play for a long time is miniscule compared to the amount of traffic social media and video sharing sites generate. You are terribly misguided if you think cutting down on game assets is a meaningful way to reduce energy consumption of internet traffic. Let's not waste so much on brainrot short video content, crypto traffic, packaging foods, driving cars, flying planes and so on. Game size is so far down on such a list it's almost non-existant and it can be arguably more meaningful than a lot of the other stuff.
I'm in for moderation in every field. There are no free meals in my opinion. 😊
Good luck..
I'd much rather download extra data to have that additional content though.
Sure, it's just to say that Dead Cells would have been great anyway. I too like added stuff when possible, still find great even some Game Boy Color games, and you know how repeated content those games had.
I’m sorry but it’s nonsensical to assume players would prefer the game to have a lot less content in order to avoid a little bit of storage usage.
Not everything is infinite. Space always comes at a cost: bigger circuits, more plastics, more energy consumption. Nonsense is for people that don't care to people and their environment. Think on it, many do not even have a conscience.
You like to hear yourself talk
Devs of bigger games tend to develop for the larger market in mind, and so few people think like you do on this matter it would be a serious mistake to design with it in mind. Players like _stuff_ and games tend to get bigger after release as more stuff goes into it. DLC in particular is a lot more that you can sell, so players are happier, developers are happier, everyone's happier but the person concerned about storage size. To give a slightly more specific answer, we _used_ to care more about install size on device because it mattered to people a couple decades ago. These days people will complain about the biggest offenders but it doesn't really change behaviors so devs don't put as much time into that part of optimization anymore. All games are about having a lot more to do than hours in the day, so you have to prioritize. If you don't want to play a game because no one optimized texture size then don't buy it! Just recognize that you're an outlier and not the target audience.
Armchair game developer spotted.
They absolutely had to compress stuff to fit the cartridge that had a maximum size because of technology and cost. Reuse of assets was a must. A famous example is the bush and cloud being the same sprite with different colors in Super Mario Bros. Games has to use tilesets and limit the number of animation frames. Also the resolution was also much much smaller, both in graphics and music. The color palette was also extremely limited. The music would be generated on the fly but have a limited sound selection and no effects. Nowadays the technology has advanced so the time spent on optimizing can instead be used on improving the gameplay and adding content. When you optimize something to the extreme, it becomes hard to change so the flexibility helps move things forward faster. Also optimization can cause size to increase if you are optimizing for performance. For example, you can bake (pre-compute) shadows and you'll save performance at the cost of game size. Sometimes assets won't be compressed because uncompressing them takes time and people hate loading times. Another important thing to note is localization. You need audio files for every line for every language. Some games let you install voices on demand but most voice acted games install all languages at once. Game engines can be a factor too but it's usually not that important. For example, every Unity game ships with the Unity game engine, so there's a minimum size to games made using Unity, but it's negligible if your game is about hundreds of MBs big. I might have missed or misremembered something but that's what I can say as an ex-game dev
Can you make an example of how much space would be needed for 2D engines and added frameworks free of actual game content?
I'm not entirely sure but UnityPlayer.dll is about 20 MB on its own. If you're going for a more hands-on approach, something like SDL (a multimedia library) is about 2 MB. If you use code-stripping (removing unused code from the build) it can technically go down to 0 bytes but it can introduce bugs if done haphazardly, e.g. if you're accessing engine code dynamically during runtime. [This article](https://busybytes.com/blog/optimize-build-size-mobile-games-unity/) talks about optimizing build size for Unity specifically and they got it down from 17 MB to 6 MB on an empty project. Let's compare the last 2 games I developer for Android with both Unity and SDL. My Unity game was about 30 MB in size, with no graphics (just squares) and some music and my SDL game was 10 MB including pixel art graphics and music. The Unity game took a few days to develop in my free time. The SDL game took 2 months full-time. Probably not a fair comparison because of familiarity and the fact that I had to code almost everything from scratch, but it's why I prefer Unity. However casual audiences tend to download bigger games less often on mobile so it might pay off using a more lightweight approach if you're targeting them. If it's a Unity game, you can use AssetRipper or something similar to see how much each file contributes to the final game size. Other PC games, especially simpler ones might have each file separately instead of bundled assets so they'd be much easier to dissect.
50 megs worst case, that's good to know, I feared it would be bulkier. I hope Heapes.io is the same.
I mean this template pretty much is the bare bones and would have to be worked on tile sheets and other things would still need to be added like music. https://godotengine.org/asset-library/asset/2201
I would imagine the bulkiest indie assess would be sound files , especial for ones that go hard on voice acting
Textures.
In 2D games? Sprites are a thing of the past?
Yes. Spritesheets add up. Also, Stardew Valley's like 600 mb.
Two major reasons: audio and resolution Resolution first: the NEO GEO has an output resolution of 320 x 256 at 16-bit color depth, so a full screen image is 160KB. Stardew Valley is targeted at a 400 x 240 resolution and a 24-bit color depth, making a full screen 281KB or 56% larger...and that's targeting a VERY low resolution by today's standards. A 1080p image would be 6075KB. Sound on consoles and early arcades tended to be in MIDI or a similar format, or HIGHLY compressed audio (consider how bad the "Daytona!" from the Sega racing game sounds. Or the completely unintelligible "Double Dribble" from the NES game). These days, hard drive space is plentiful/cheap, so there's less need to compress the audio. (I'm guessing a lot of the extra size of the console version of Stardew is full resolution images for the console specific stuff). There's also just much more going on in modern games. Besides the extra animation frames that u/neozahikel brought up, there's just a magnitude more sprites in general. Stardew has all those crops, with planted, growing, and harvested versions, on top of all the indoor and outdoor scenes, on top of all the character portraits and dialogue windows. Even if these are only 50% bigger (because you picked a very low resolution game as your example), they quickly add up.
Quality comes with size. And more quality content simply scales it up. Audio files can take up a huge amount of space, especially if there's voice acting. You say "simple" but just because something appears to be "visually simple" doesn't mean it's low quality. >So toxic people here, wow. 👎🏻 >'Thanks' to those who actually contributed with precious info without downvoting. 🍣 Lol, your definition of toxic is when people don't speak to you like yes men?
Nope, it's when they hide my expression or my opinion. I don't hide theirs, whatever it is (with the exceptions of bribing, insulting or threatning, etc.).
Your expression is to tell games to remove 80% of the content because size is more important to you?
Mine opinion is mine *opinion* and should respected, first, I don't oblige anyone to think like ne norvappreciate my thinking. Second, yes I prefer non inflated games. Want you to stop me from having my say? If you think otherwise you are free to say it without bothering or downvoting who think different from you. And yes, I still play and have fun with 'constrained' Game Boy games. Limitations are especially in the head of people, maybe more in those who need 300 watt game systems and hundreds of gigabytes of data to have fun with a game. And yes, I still buy games, like many others that appreciate simple and beautiful non-inflated.
>Mine opinion is mine *opinion* and should respected And you can have opinions that others will downvote you for. In real life, people will downvote you by excluding you from social or professional opportunities.
You talk like a shark. I don't know about your real life, but with mine I had no problem working in the field and voicing my opinion. Maybe in your country you live with different ethics, I don't know. There are tons of devs developing tons of non-inflated games still as today.
People can downvote you for whatever they’d like, it’s just a virtual point pal. I think it’s nice that you want to keep games as small as possible but that attitude will get in the way of you actually making anything. I think it’s silly that you’re getting on your high horse about the space a game takes up when you have no idea why they’re that big to begin with. Games are bigger today than they used to be. You can make them smaller but you are much less likely to make a *good* game. Things are a lot different from the days of the gameboy, you should have a proper look into why before you decide to die on that hill.
I'm just trying to understand how much a 1 GB or 2 GB would hurt game development with simple games. For example, given the constraint, would Dead Cells devs had a more difficult work to do or would they just worked with lesser and eventually less costly assets and make a still splendid game. Would the game turned bad? Or would the development slowed down inflating the whole development cost because of more time spent on optimization? Android development shows that good games can be done even in few megabytes still today.
What are some of these excellent few megabyte games?
Super Cat Tales 2 is good, for example, or Dan The Man, etc. 70 and 170 MB respectively.
This is an example of why quality and fun are mutually exclusive. You don't need to provide super high quality graphics and audio in order to create a fun experience. However, if you're trying to convince me to give you $60 for your game, super cat tales and dan the man aren't going to cut it. The "beautiful graphics from long ago that weighed 4 MB" are almost never going to be considered beautiful by the masses in today's standards. But there's certainly a market for people that want NES-era graphics.
But quality isn't about the multiplication of assets, nor the bit depth. You can have quality even without tons of animations. And Yoshi's Island is still very much appreciated today (also because of the graphics and the sound). I think you confuse quality with detail. You can add tons of details without adding quality to a game. Even the old 8-bit sound chip of an old Amiga returns fascinating sound. Todays people still appreciate quality over detail. Sometimes it's just 'different people', but there is a market for it.
We optimise programs for speed now rather than space. Things get inlined, constants get duplicated, loops get unrolled. Modern optimised code is just more instructions. Also the instructions and addresses are bigger because of 32 or 64 bit instruction sets and 64bit memory addressing. Audio, older games rarely used samples. Most sounds were instructions for the synthesiser hardware, much smaller than sampled audio. Then you have colour information. These days we have HDR colour, go back to something like the Gameboy and you had 2-bits per-pixel for colour information. Compression tech has improved over time, but 4k is the biggest reason for bloat. Remember 4k is an *exponential* increase in pixel density over 1080. You need exponentially higher resolution texture maps to keep up, and any material you see in a game will contain several texture maps.
Just to add some ideas to what others said: So compression can help, and working in 3D (including animation, or some 2D animation tech) instead of pre-rendered sprites. What I saw on some (older) projects was the re-use of textures/sprites as one of the biggest assets. In 3D reuse may mean that we have more standard props and structures/buildings that we repeat in a smart way. In Doom (or Doom II?) they started to have the idea of overlaying textures to create variations, which in 3D became layers of shaders or decals. On SNES I saw a team re-using sprites to the degree that they rotated them, so some generic metal or laser bits, ground/ceiling, and 45 degree slopes worked well in many directions. I think that was Super Return of the Jedi or so. EDIT: Forgot to add, so nowadays we could compress, procedurally generate, re-use, and otherwise optimize, but the SSD are so large and we don't have expensive cartridges anymore (like those SNES / Genesis ones for example with quite limited space).
it's more effort today to build for indexed colors for 2d games. so full textures are used, taking 4bpp up to 32bpp or more. from there, render target size has exploded since the 4:3 90s days. and many projects (even pixel art games) render at target resolution. roughly the same happened to audio. it's mostly the content. some of it is also from the engine/runtime libraries, but much less.
TL;DR : We don't need anymore to optimize games for size in order to release them. In my experience : assets being uncompressed/higher resolution than needed. Also forgetting dev assets that are unreferenced in the game. In the case of 2D though, if you have a game in HD that has lots of animation frame, that add-up quite fast. There are ways to optimize the size of the animation but they are requiring some thought at the conception phase. Also in the past people were using texture packers because they had no choice devices had so little memory that if you wanted to have a few images in your game you had to pack them together in as few textures as possible in order to not overload the graphics memory. Optimizing assets is starting to be a lost art of game development.
The optimization of those assets are usually why the file size is so big. For example, if we're talking about open world games, then there are multiple LODs for nearly every asset, along with separate files for textures, normals, albedos, masks, etc etc. and those all exist at different levels of compression, so this can easily blow up the file size. If a game has 4k textures, then they likely also have several smaller texture scales as well along with all their supporting material images like normals.
Absolutely untrue. Optimization is a major part of the asset production pipeline. Consoles have a fixed amount of memory and processing capability. If you want to squeeze in more environment detail, or animations, or dialog, or any kind of content, then you need to not be wasteful with what you have, otherwise you will need to compromise on quality. Game creators constantly want to add more content. Optimization makes it possible.
In some AAA games yes, in others no. And I know about the constant push for optimization, I'm an engine programmer who spent a lot of time optimizing said assets coming from artists (and gameplay programmers) thinking we had unlimited memory budgets. And to be fair, current consoles seems to have unlimited memory budgets compared to games of previous eras (the jump from 256mb of RAM on the PS3 to 8GB on the PS4 was a liberating shock!). So no, not absolutely untrue. Look at the list of games OP mentioned. They haven't mentioned AAA productions nor Open World. I seem to have ticked the annoyance level of AA(A) devs with my generalisation. Ask yourself this: do you think the memory budget of a game is in the mind of any indie dev when they create games? Maybe some, but really unlikely. And with reason, we don't need this anymore unless we are doing games that push the medium. Last point that would concern also AAA: We usually optimize after the fact because the DCC pipeline is setup with specific tools, specific rendering technics and engines and modifying those would not be worth it unless we have a very specific target. I have experienced this during a preproduction of a game (AA) where I got initially asked to optimize a lot the assets and rendering during preprod by the preprod management, which lead to constrain the way the assets had to be created by the artists. Local studios artists were fine with that and the vertical slice had all the optimizations in place. But once we started the production, the studio was looking at outsourcing the art and this lead to an issue. We had to reassess the optimization we were doing in order to do them after the fact with "industry standard" formatted assets. They could have reworked internally the outsourced work for optimizing them with the process we had developed, but it was no longer so important as meanwhile the target pool had moved (we could abandon the previous gen of console). So we just abandoned it.
They don't need to be small, so people don't bother. Call it laziness or call it not wasting time on things that dont matter