4Aces said:
It is not about the overall size, but if that size is warranted.
Totally agree with this. I actually like where this thread is going - it's moved from an (amusing but trivial) discussion about at what point in the games development timeline the total sum of historic code was less than the largest available single game into something very relevant; how large can download/install sizes keep inflating given, a) the predominance of the digital purchase and, b) the fact that, as several commentators have pointed out, even in Europe/USA most of us are on sub-par connections compared to what is actually possible.
I think there is some confusion about 'optimisation' though. When I think of that term, I think of the most efficient piece of code to perform a given task in clock cycles of the processor. Even when you are doing something simple like sorting a set of data into alphabetical or numerical order there are many different ways this can be accomplished. Some do this more efficiently in terms of speed (my definition of optimisation these days) and some do it more efficiently in terms of how many bytes those instructions takes up in memory (my old definition of optimisation back in the '80s and '90s!).
I think it is a bit disingenous to compare 'install size' to optimisation as the actual code that runs the game is a very small percentage of the total data on any install these days. I suppose if you are talking about something like using a 2048x2048 texture when a 256x256 would do then, yes, I'd agree to a certain extent but I still maintain there is no point in compressing data anymore, apart from at the download stage.
Back in the '80s I wrote a lot of those text-only adventure games for the Spectrum. We used quite a clever little system that scanned through all the text the writer had created looking for repeating patterns or common words: the, ing, you, look, walk, etc., etc. We then replaced those multi-character words or partial words with a one-character replacement so that when the game was reading through the text data and found a non-alphabetical code, it looked it up in an array and replaced that code with the letters. Clever use of this system could get more text into 48k than should actually have been possible, but damn, it was slow come time to throw it up onto the screen:
Because we didn't know how long a given line of text was going to be at any one time due to these characters, and the fact that we had a fixed width screen, we had to generate the line in memory and then figure out if the last word would wrap onto the next line. If it did, we saved it, backtracked, deleted that word and then added it into the buffer for the next line and so on. This is no big deal on your 2.5Ghz PC. It is a massive deal on a 2.5Mhz Spectrum!
I know that was a bit rambling, but I thought the more technically-minded (and perhaps older!) readers would appreciate an explanation of why 'TEH OPTIMIZINGS!' means different things, at different times to different people, and not necessarily why installs seem bloated sometimes.
Why go through all that hassle these days to display some words? Well, we don't now. We leave it 'unoptimised' in terms of space allocation, but very optimised in terms of speed.
As game worlds get larger, as graphics data becomes more complex, as voice and a huge variety of music, effects and soundtracks become de-rigeur for even small indie projects, it is inevitable that there is only one way installation sizes are going to go and it most certainly not downwards as I see it.
I wonder if there is a Moore's Law equivalent for this or if there is a critical point at which it all falls apart due to lack of infrastructure for all but the lucky few? If I hadn't had this half bottle of Merlot, I feel quite sure I would already have worked out the equation