Game's Size

Started by Baguettator, Tue 30/06/2020 10:47:12

Previous topic - Next topic

Baguettator

I created this topic because it was starting in another topic, but it is clearier (and more interessant, I think) (and more fair, I believe !) to put it in a specific topic, maybe it could help someone else :)

I was asking about what can we do to decrease Game's Size. There were the first answers :

Snarky said :

Inefficient scripting makes no significant difference to game size (it could potentially cause it to run slower), but reducing GUIs and buttonsâ€"as long as you also delete the associated spritesâ€"might.

The game size is almost entirely made up of graphics (sprites and room backgrounds) and audio. Importing the same graphics multiple times, or being inefficient when you have small variations (huge sprites that are nearly exactly the same except for a small difference, instead of just having the static part as one sprite and the bit that varies separately) tends to bloat the game size. Also avoid excessive frame-by-frame animations, which should instead be done as videos. If an animation is more than say 100 frames (of individual sprites), you may want to rethink. Many things can be done in-engine instead of being pre-rendered as separate sprites. Similarly, many, large room backgrounds take up a lot of space, and there are ways to store them more efficiently (typically using tile-based drawing or other standard elements that you can reuse in order to create different rooms from the same small set of graphics).

For audio, it's mostly about using efficient sound compression, e.g. OGG format (and of course not importing the same sound multiple times, or sound you're not using).

Edit: That's not to say that you shouldn't simplify and clean up your code. Bad code is difficult and tedious to work with, and can drain your energy for working on the game. If you've learned a significantly better way to do it, it's often worth going back and fixing it. (Though at the same time, if it works, you shouldn't put so much work into polishing it that you don't make any other progress.)

Crimson Wizard said :

Right, this is the first reason to simplify the code :) Improving game's perfomance is a reason to optimise it, but that's kind of a different thing (and sometimes you have to write more complex code when doing that).

I said : (my last answer with some questions)

OK, thanks a lot for your replies about decreasing the Game's Size. Effectively I could  decrease that by separating existing sprites in several sprites (one for the part that doesn't change, for example the "background" of a button, and other sprites for the part that changes, for example the "text" of the button.). Maybe also by using "labels" for some texts, but labels are less "flexible" for text alignment, so I have to test before.

About audio's format (OGG you said), I will take a look at that. It won't be difficult to change that quickly since I use a very few audios in my game, and it is still not ready to play.

What's about image's format ? I'm using basically PNG and BMP, but I didn't think a lot about that, and I am not an expert about compressing the image, or choose the right format...


Baguettator

Thanks for the answer ! I understood that Game's size is most linked to the number of sprites the game use, so maybe I'm going to check if I can reduce the number of sprites, in fact I think it can bo done with a bit of work :)

Crimson Wizard

Quote from: Baguettator on Sun 05/07/2020 16:19:52
Thanks for the answer ! I understood that Game's size is most linked to the number of sprites the game use, so maybe I'm going to check if I can reduce the number of sprites, in fact I think it can bo done with a bit of work :)

What's your game resolution and how many sprites you already have? For low-res games I would not be worrying about size of sprites too early, unless you are doing a very long game with lot's of animations.

Baguettator

#4
Sorry, I didn't notice your answer :)

My game resolution is 1920*1080, and actually I use almost 2200 sprites. Some are very small, but some (maybe 100 of them) are 1920*1080.

I think I could reduce drastically the number of sprites by replacing some sprites with Label GUI (in fact, lots of my sprites are with a common background, but a different text on it). I think I can get 400-500 sprites less by using GUI Labels, but it will be less practical to use Labels GUI for the Text (and maybe less pretty :) )

However, my game's size is 2Gb, and I think it could be decreased a lot. And I'm afraid of something : maybe my Game's Size is huge because of the resolution. But if I change Resolution of the game, I will be obliged to rework on each sprite and give it the right size according the new resolution ?

And because my game isn't finished, will I get a limit if I use too much sprites or if the game's size is too much ?

Actually, ascprset.spr is 1 998 350 Ko . :S

EDIT : also I was thinking about : I have readen something that the game can use files on the computer that have not been compiled. Maybe I didn't well understand, but... could be a solution to use large sprites outside the compiled game to reduce his size ?

Crimson Wizard

#5
Quote from: Baguettator on Thu 06/08/2020 12:18:35
My game resolution is 1920*1080, and actually I use almost 2200 sprites. Some are very small, but some (maybe 100 of them) are 1920*1080.

I think I could reduce drastically the number of sprites by replacing some sprites with Label GUI (in fact, lots of my sprites are with a common background, but a different text on it). I think I can get 400-500 sprites less by using GUI Labels, but it will be less practical to use Labels GUI for the Text (and maybe less pretty :) )

Definitely, splitting big images in parts, extracting non-changing part, is a way I would recommend to go regardless of whether it appears to be a problem or not.
You could make a screens-sized GUI with a big sprite on background and labels for text. I don't know your exact situation, but in general case this is what labels are for :).
But you do not have to use labels if they do not look good, in this case you could try having one background sprite and smaller sprites with text on them, for example.


Quote from: Baguettator on Thu 06/08/2020 12:18:35
However, my game's size is 2Gb, and I think it could be decreased a lot. And I'm afraid of something : maybe my Game's Size is huge because of the resolution. But if I change Resolution of the game, I will be obliged to rework on each sprite and give it the right size according the new resolution ?

Game size on disk directly depends on the (geometric) size and number of sprites, so it's up to you to find a balance between looks and game size. There are lots of ways to decrease game size. Breaking animations in changing and static parts, cutting unused transparent borders as much as possible, reusing same sprites for various purposes, etc.


Quote from: Baguettator on Thu 06/08/2020 12:18:35
And because my game isn't finished, will I get a limit if I use too much sprites or if the game's size is too much ?

Actually, ascprset.spr is 1 998 350 Ko . :S

Before AGS 3.5.0 the limit of ascprset.spr is roughly 2 GB. Since AGS 3.5.0 you can have much more.
Also, sprite file may be reduced if you enable sprite compression in General Settings.


Quote from: Baguettator on Thu 06/08/2020 12:18:35
EDIT : also I was thinking about : I have readen something that the game can use files on the computer that have not been compiled. Maybe I didn't well understand, but... could be a solution to use large sprites outside the compiled game to reduce his size ?

That was a workaround that could solve the issue of sprite file being too big before AGS 3.5.0.
Also, this may be used as a way to provide downloadable update :).
But in general, extra files on disk are also part of game files, so total size is still the same, is not it?

Baguettator

QuoteBut you do not have to use labels if they do not look good, in this case you could try having one background sprite and smaller sprites with text on them, for example.

You mean that it is best to have one sprite for the background and 100 sprites with only the texts (and transparent background for the text) that are placed on the background sprite than having 100 sprites with the same background and their own text together ?

QuoteBefore AGS 3.5.0 the limit of ascprset.spr is roughly 2 GB. Since AGS 3.5.0 you can have much more.

So, what's the limit for AGS 3.5.0 ? I use this version of AGS, so I'm happy that it could manage a lot more files with larger size :D

QuoteThat was a workaround that could solve the issue of sprite file being too big before AGS 3.5.0.
Also, this may be used as a way to provide downloadable update :).
But in general, extra files on disk are also part of game files, so total size is still the same, is not it?

Well I thought that by using large sprites (especially those that are 1920*1080) in an extra folder, that is not compiled in the game, it could help to have a game more stable, but maybe I was wrong. Maybe it has to be used only if I get over the limit of number of sprites ! :)


Crimson Wizard

#7
Quote from: Baguettator on Thu 06/08/2020 13:52:53
You mean that it is best to have one sprite for the background and 100 sprites with only the texts (and transparent background for the text) that are placed on the background sprite than having 100 sprites with the same background and their own text together ?

If the background is much larger then the text, then definitely yes, make 1 big background and "cut out" text sprites.

Quote from: Baguettator on Thu 06/08/2020 13:52:53
So, what's the limit for AGS 3.5.0 ? I use this version of AGS, so I'm happy that it could manage a lot more files with larger size :D

64-bit file size, which is something like 18 446 744 073 709 551 616 bytes, should be enough for a while :P.

Baguettator

Quote64-bit file size, which is something like 18 446 744 073 709 551 616 bytes, should be enough for a while :P.

When you say that number of bytes, you mean how much octets ? more than 10Go ?

Crimson Wizard

Quote from: Baguettator on Thu 06/08/2020 14:53:11
Quote64-bit file size, which is something like 18 446 744 073 709 551 616 bytes, should be enough for a while :P.

When you say that number of bytes, you mean how much octets ? more than 10Go ?

I never used word "octet" before, but I guess that's the same thing (8-bits)? The number is something like 18 billion GB, or Go if you prefer. This is a theoretical limit which may be addressed by a program, but it also depends on operating system's and filesystem limit, which may be less.

Baguettator

OK, so sorry for my misunderstanding, but if I understand well, the previous limit was 2GB and know it is about 18 000 000 GB ???  :confused:

Crimson Wizard

#11
Quote from: Baguettator on Thu 06/08/2020 16:44:29
OK, so sorry for my misunderstanding, but if I understand well, the previous limit was 2GB and know it is about 18 000 000 GB ???  :confused:

18 000 000 000 GB :)

Or 18 Exabytes, if I remember name right.

https://en.wikipedia.org/wiki/Exabyte

Quote
A processor with a 64-bit address bus can address 16 exbibytes of memory,[1] which is over 18 exabytes.

This is the difference between having 32-bit numbers and 64-bit numbers :).

Baguettator

Whaoo, so I am far far far to reach the limit !!!!!!!!!!!!!!!!!!!! :D

Many thanks for all these precisions, I will try to decrease the game's size in any case, but I am so happy now that I know the limit is just huuuuuuge :D

Baguettator

And if I authorize the game to compress the sprite files in the General Settings, will the quality be a lot less in quality ? Or is it not so a huge difference that it is worthy to chose that ?

Crimson Wizard

#14
Quote from: Baguettator on Thu 06/08/2020 18:44:38
And if I authorize the game to compress the sprite files in the General Settings, will the quality be a lot less in quality ? Or is it not so a huge difference that it is worthy to chose that ?

There's no difference in quality as lossless compression is used. Sprites get decompressed and restored to original look when loaded in game.

There may or may not be perfomance impact, but it's hard to predict. There are two factors: compressed sprites take less disk space and hence faster to load, but decompression itself also takes time. It was suggested that file reading operations take longer in general compared to operations in memory, so this may even speed things up a little, but frankly I never did any tests. This is too dependant on system (how fast is disk, how fast is CPU etc)

Baguettator

OK, I will try that. So I have just to choose "Compress sprites" in the General Settings, then Compile my game, and that's all ?

SMF spam blocked by CleanTalk