I want to keep my game with the (reasonably) lowest size. Any tips?

[SirLean]

As simple as I put it in the title...

I'm sure there are good tips that won't take away game quality.

 How can I improve the compression size or the overall good optimization to avoid my game weigh more than I'd like to?...

Trying to keep it at 500mb actually.

Any tips? thanks a lot

[Crimson Wizard]

This is a very big topic, but I would begin with saying that this topic consists of two large chapters:
1) Compressing resources.
2) Effective use of resources in game.

I put "compression" first, because it's easier to understand, imo. Also it's easiest to apply if you're already at the final stage of making this game.
But if you're making a high-resolution game, then the second part is also important; and not only for the game size on disk, but for runtime performance.

There was a topic in the manual dedicated to the resource management, but looking at it now it unfortunately turns out too short and generic, without going into many details, or real file format specifics, and does not fully explain everything it mentions:
https://adventuregamestudio.github.io/ags-manual/DistGame.html#managing-the-graphics-footprint
I believe it must be improved, and maybe this forum thread may help with that too, as it goes.

I will cover some things briefly for now.


1.1) Compression of sprites. AGS stores sprites as raw pixel data, but can apply an optional compression to that. This is controlled by option "Compiler -> Sprite file compression". As of 3.6.0 compression options are:
- RLE - this method is best suited for simple pixel gfx with low number of colors;
- LZW - this method is much better for quality high-resolution gfx with big number of colors. It's also always used for room backgrounds and cannot be changed there.
Switching compression should be safe anytime, so you may change, rebuild, record the size of the "acsprset.spr" file, change, rebuild and record the size again.
There's another option that controls sprite saving: "Enable sprite storage optimization". This option is best to left always on, the switch is there mostly for emergency/debugging purposes. If you're curious, what it does is that it secretly converts 32-bit sprites into 8-bit sprites with palette, but only when it's actually going to gain space. Then when the game is run, engine converts them back to 32-bit for proper display. This option is intended for 32-bit games that emulate old-school gfx with limited palette (like this game for example), and may reduce sprites size at most by ~4 times.

1.2) Compression of audio. I had never done any research, but hearing what some other people mentioned in the past, AGS games seem to be notorious for their developers using audio files of a way too high quality, usually unnecessarily high bitrate. This is probably because many games are done by hobbyists who do not have much knowledge in audio engineering, and so they may use downloaded free audio files without checking for specifics.
But having overly high bitrate may significantly increase the size of audio clips.

Unfortunately, I am not an expert in this either, so someone should give a hint, or point to some tutorial, but regardless I believe it's important to find a good bitrate which both ensures an acceptable quality and don't boost the size too much. There are tools that let convert audio in batch, changing bitrate and other parameters (such as ffmpeg for instance). After you found a good set of parameters, it may be worth converting all of your audio to these.


In regards to "chapter" 2, "Effective use of resources", that's again a large topic, so only to touch few  subjects.

2.1) Fullscreen animations. The size of gfx file depends on the sprite's resolution. Fullscreen frame is rather large, and if you have fullscreen animation, that means it's even bigger. To give some perspective: 320 x 200 x 32-bit is 320x200x4 = 256000 bytes. 1280 x 720 x 32-bit is 3686400 bytes (~3.7 MB). You may continue this calculation. E.g. a fullscreen animation in 720p of 10 frames would be 37 MB, 10-frame animation in 1080p would be ~83 MB. This of course does not account for the sprite compression, but should give an idea.

Depending on the purpose of a fullscreen animation, two ways of optimizing one are:
- If it's an animated cutscene, consider using OGV videos, which have far better compression that separate sprites (although the quality may be not as "sharp").
- If it's a background animation, consider splitting it up into parts that animate and those that do not, and use separate room objects to animate only parts of the room.
- If it's some kind of a screen effect, consider using a smaller sprite, place it on overlay and scale it up to the necessary size in script. Not saying this will work always, but if this is something that does not require perfect detail (like falling streams of rain, for example), it may actually be a solution.

2.2) Using low-res gfx in high-res game. Overall, remember that you may scale lower res sprites in game using object scaling (which has fast performance); if you do not need much detail to some gfx. If you are making your game with "old-school" pixelated gfx, do not resize sprites to high-res even if you want a high-res game for some reason (for example, for the purpose of having high-res "modern" guis and text fonts). Keep them low-res and scale objects, or zoom-in whole room viewport instead.

2.3) Changing character/object views. If you have too many variants of character looks, and required number of sprites skyrockets, you may consider two methods:
- Combine a character from two or more characters. E.g. one character is a body, another is "dress" or "shadow", and so on. This method was (still is?) widely used in arcade games, where character parts could have separate animations.
- Use dynamic sprites and change the looks in script at runtime, repainting the view frames.

[SirLean]

Hi Crimson, you are amazing!

1) by activating LZW compression, my Windows compiled game went from 194 MB to 102 MB.

2) when importing a sprite, I always, since I started making this game unchecked the "Remap palette (8-bit image only" option. Should I keep it checked to make the game weigh less? or activating it will lower the sprite quality too much?

thanks for the amazing tips 

[Crimson Wizard]

2) when importing a sprite, I always, since I started making this game unchecked the "Remap palette (8-bit image only" option. Should I keep it checked to make the game weigh less? or activating it will lower the sprite quality too much?

This option is strictly for 8-bit graphics, it has nothing to do with sprite compression.
What it does is replaces the sprite's colors with the colors from game palette.

It's ignored for non-8-bit sprites.

[SirLean]

Thanks!

 Also, if there's an animation happening let's say a bird flying from far away, that will eventually be a playable character after the animation of the animal coming near the screen and doing something occurs...

 Should I aim to animate the flying bird animation as an object? or should I already set it as a character?

Would that make any size difference in the game file?

[Crimson Wizard]

Should I aim to animate the flying bird animation as an object? or should I already set it as a character?

Would that make any size difference in the game file?

You are overthinking this.
Characters and objects on their own are just 15-20 numeric properties; they are a microscopic value in the total size of the game.
What matters is: graphics and sounds, the resolution of rooms.