You could load assets after the game has started using the sprite_add, background_add, ect., storing them in the, or a subfolder of, the game directory.
We are talking about GM:Studio here, so be
extremely careful when dynamically loading graphic assets. Doing so will create a new texture page for each added resource. Trading executable file size reduction for additional external files (which essentially are equally large in file size) and a loss of performance is, under most circumstances, not worth it.
The exception to this is when it is impossible or unfeasible to store all of the game's graphic assets in RAM and they have to be dynamically swapped in and out, and even in that case, texture pages and therefore swaps should not be ignored. There's an extension that basically is a runtime texture packer that helps to mitigate this issue:
http://gmc.yoyogames.com/index.php?showtopic=669935
It should, however, be noted that this is a drastic measure which changes
a lot about a game's inner workings and introduces lots of new things developers will have to keep in mind in order to not run into issues, and therefore should not be considered unless it is evident that there is a problem with the way things are currently handled (and huge file size is not always a problem per se). I'm not suggesting to apply this to average projects - I'm only explaining the pros and cons to allow readers to make a qualified judgment about whether this measure is suitable for their game or not.
@connorhawke:
First things first: Make a backup of your project.
This will not reduce the executable's file size, but it may reduce the project folder's size: Go to File -> Export Project and export your project as a .gmz file. Load this .gmz file back into GM:S and save the project (either delete the old project folder and save it to the same folder as before, or save it to a new folder and then rename it to the old project folder name - just don't mix the two together). The output of this will be all of your project's files minus any resources you have deleted in your project tree but not on disk, temporary files, etc.
That aside, audio files are the worst offenders of file size inflation. Therefore, make sure that all background audio resources are set to
Compressed - Streamed. This will export the audio file separately rather than including it in the executable file. If it's still bundled with the executable even after changing to this setting, you are using the single runtime executable export. Export it as a zip instead and all files that can be separate will be separate.
Let us know if you're still having file size issues after trying out our suggestions.