Ludum Dare pro tips: polish up your Unity builds

Posted by (twitter: @rjhelms)
April 22nd, 2016 12:31 pm

We see a lot of Unity games every Ludum Dare. In the past, I’ve heard some griping about this, but let’s face it: Unity is perfect for game jams. It has its quirks and limitations, but when time is of the essence, you can’t beat a platform that’s easy to work in and lets you forget about the basics, and jump right in to seeing your idea in action.

However, this can be a bit of a mixed blessing: because Unity handles so much for you behind the scenes, there’s a few steps that are easy to forget about when it comes time to package up your game and submit it, but which go a long way to polishing up the impression your game makes on people rating it. Unity’s gotten a lot better at handling these things in a sane manner, especially with version 5.3, but it still benefits your game to give things a once-over.

If you’re not using Unity, feel free to ignore this post, but if you are – read on! I’m mostly going to be focusing on standalone builds, but it’s a good habit to get in the practice of thinking of these things even when you’re intending on making a web game.

1. Delete those .pdb files

I’m not sure why Unity still insists on doing this, but when you do a Windows build, there will be two .pdb files in the build folder:

No one wants your .pdb files, Unity.

No one wants your .pdb files, Unity.

These files are created during compile time, to provide information for a debugger. If you’re distributing development builds across a team of devs and testers, they’d be very handy, but for release builds going to end users they’re useless. Thankfully, they compress down pretty small, but deleting them – or leaving them out of your final .zip file, like I did here – will shave about 35MB off your game’s download and around 140MB off how much it takes up on disk.

2. Set the Company and Product Names

This one’s easy to miss, because it doesn’t seem like it does much, but it’s essential that you set these options, under Edit > Project Settings > Player. These determine where in the registry (Windows) or on disk (Mac and Linux) the settings for your game are stored – if you leave them blank, or set them to something generic, when someone goes to fire up your game the settings they see (ie resolution, graphics quality etc) may not be the defaults you’ve set, but rather those from the last game they played. Take a look at my registry:

Are these the settings for your game? No? Didn't think so.

Are these the settings for your game? No? Didn’t think so.

If you leave these settings blank, or set them to something generic, you’re leaving a lot up to chance as to whether the people playing your game see it as you intended or not.

3. Set your supported aspect ratios

If your game only displays correctly at certain aspect ratios, be sure to configure them in the same Player Settings screen. If your game only looks or plays right at 4:3, that’s fine – but it makes a poor impression for a player to find that out by firing the game up full-screen on their 16:9 monitor, only to find half the UI is cut off. This is compounded by point #2, because if you’ve left the company and game names blank, your game might fire up with an aspect ratio you don’t support prepopulated as the defaults.

4. Configure your quality options

This is one that’s burned me before more than once: by default, Unity has a whole bunch of quality settings, with defaults set “appropriately” for most cases. Is your game actually resource-intensive enough to need quality settings? If so, are you prepared to test that they all show your game as expected?

This is what my game looks like on "Fastest" quality. That's not an option in the version I released.

This is what my game looks like on “Fastest” quality: the already-tiny sprites are squashed even more, and look terrible. That’s not an option in the version I released.

Especially for 2D games with a pixel art style, like what I typically make for Ludum Dare, the lower quality settings won’t make your game faster, just worse. I tend to delete them all except for “Fantastic” – but if you’re going to leave other ones in, make sure you can live with how they look, and tweak them accordingly. You do this under Edit > Project Settings > Quality.

5. Test your defaults!

So, you’ve done steps 1-4, and you’re confident that you’ve got all your project settings configured appropriately. You’ve launched the build you’re going to release, and everything looks perfect. No worries, right? Wrong.

The whole time that you’ve been developing your game, Unity’s been storing settings in your registry (Windows) or on disk (Mac/Linux), so when it comes time to launch the final build, you’re not actually seeing the defaults – although you might be seeing what you think are the defaults. To make absolutely sure, you’ve got to blow away the stored settings before doing that final test: On Windows, you can do this by deleting the HKEY_CURRENT_USER/SOFTWARE/[CompanyName]/[ProductName] folder in your registry, with all the usual caveats that apply to making manual changes to your registry. On a Mac, the settings are stored in a .plist at ~/Library/Preferences/unity.[CompanyName].[ProductName].plist, and on Linux they’re stored in your home directory at ~/.config/unity3d/[CompanyName]/[ProductName].

If everything looks good when you launch a game after deleting those settings, you’re good to go!

This might all seem like fiddly little things, but they don’t take long and can go a long way towards making your game look more polished and professional. My practice lately is to forget about this stuff when I’m in the heat of development, and then just run through these points as a checklist right at the top of the submission hour.

Thanks for making it this far, and I hope you found this helpful. Is there anything else you do when you’re packaging up your Unity games to make the experience smooth for people playing it? Let me know! Also, obligatoryplugplayandratemygamehereitsgood.

Tags: , , , ,

8 Responses to “Ludum Dare pro tips: polish up your Unity builds”

  1. Manou says:

    Thank you for this! I suspected this behaviour with settings from another game, reading some commentaries on my game.

    Gonna apply all this.
    Need a sticky for this for next ludum dares!

  2. Manou says:

    Do you know if it’s the same thing for WebGL export ? with registry and stuff ?

    • rjhelms says:

      Glad you found this helpful!

      I don’t know too much about WebGL – the unity docs say that the settings “are stored using the browser’s IndexedDB API”, though I’m not sure how you’d go about resetting that.

      • Manou says:

        mmmm ok, thank you !

      • subpixel says:

        That’s a tricky one.

        IndexedDB is a dictionary stored by your browser. It’s sandboxed, meaning that each site gets its own exclusive database. That makes sense: you don’t want any other site randomly reading the data you’ve stored while your user was on your site.

        It is per site though, so I’m guessing that roughly the same rules apply here: if you’re hosting on a popular domain, or if you’re hosting multiple games, then without a unique key like the company and product, then unity probably is writing to the same keys for all games. Chrome has some debugging tools that let you look inside the indexedDB. You could go and see what effect your game has once you’ve tried to play it.

  3. JoeManaco says:

    I completely disagree with “Unity is perfect for game jams”. Unity is a great tool for sure, but I don’t get the point why it’s better suited for gamejams than other engines/libs/languages/tools. To be honest I’m wondering why so oft people choose Unity for projects it is not suited to very well (Simple 2D Games, GUI intensive games etc.).

  4. himani3 says:

    Thank you so much for the making this track. and now its available in our window 10 and its so interesting to use any body can try this here.

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]