I was making a build of RaceCraft, and I realized that it was humongous (140+ mb), so I looked at my assets and realized that my sound files were all 10 to 40 meg wav files, so I converted them all to 1-4 mb mp3s and rebuilt it. Now the build is 160+ mb though! What happened, and how do I reduce the size of the build?
starmanta’s point is the prob but another helper to reduce file size is Strip Debug Symbols when you build your final. not going to help you much with this one. just a tid bit…
Jeremy, Jeremy, Jeremy…What are we gonna do with you…
hey Moldorma, if you want to test code is working, you can add a line like this
function OnTriggerEnter(){
Debug.Log("Trigger Entered");
}
And that informs you on the console at bottom of screen, that the trigger has worked(or not). Its very handy, I debug.log almost every event, and sometimes it saves heaps of time…
When you build, any line like that is removed to save space. I really dont know how a line of code can take up any space, mind you, I suspect its a throwback to the 80’s when Jeremy and others were coding up Pong clones, and the game was only a few kilobytes. Maybe some of the engine gets excluded and it actually does save some noticible space. OTEE?
Download audacity to encode your .ogg files, I delivered hires waves to give you some room to try heavy or lite compression. Encoding is no big deal, but check every outputed file as audacity can fail about 20% of the time.
Yeah, I already converted them all to .oggs now. The file size went from 160mb to 60mb. Compressed size went from 130mb to 20mb. I posted the demo in Showcase, for what its worth. As for Debug Symbols, I’ve never used them. I just throw in “Print(“It worked”)” or something to test it, and then take it out by hand once I’ve confirmed its success.
I could be wrong, but I’m pretty certain that that’s not what debug symbols are at all. When print statements are compiled, they’re compiled, and Unity won’t recompile the script for the build just to strip out a kilobyte of program data.
Debug symbols basically mark every bit of code with information about it - what class it’s in, the function name, etc, etc, etc. This becomes useful - as far as Unity is concerned - when you profile your built app, it can tell you whether a lot of time is being spent in Update, FixedUpdate, etc. For example, one of my games’ profile revealed that a lot of time was being spent in FixedUpdate, which led me to realize how bad an idea it was to call BroadcastMessage in FixedUpdate.
It can probably be used to track down crashes and such too, though I’ve never come across that situation myself.
But 90% of the time, you’ll lose nothing important by stripping debug symbols. In most cases, if you DO want to do this sort of profiling, you’d be better off making a special build for it.
StarManta is right…debug symbols are for profiling, like with Shark. You should turn them off for any build that you are distributing because they can use a lot of space. Debug.Log is basically just a print statement.
maybe a stupid question but i have to ask - if you strip the debug symbols on a test build - does that mean they’re gone from the project for good or is it just that build? (it would seem to me just that build but i’ve read multiple times now ‘only on your final build’ so i want to be sure ; )
I posted the demo in Showcase, for what its worth. As for Debug Symbols, I’ve never used them. I just throw in “Print(“It worked”)” or something to test it, and then take it out by hand once I’ve confirmed its success.