Standalone Player Settings

This page details the Player Settings specific to standalone platforms (Mac OSX, Windows and Linux). A description of the general Player Settings can be found here.

Resolution And Presentation

Property:	Function:
Resolution
Default is Full Screen	Should the game start in fullscreen mode by default?
Default Screen Width	Default width of the game screen in pixels.
Default Screen Height	Default height of the game screen in pixels.
Run in background	Should the game keep running (rather than pausing) if the app loses focus?
Standalone Player Options
Capture Single Screen	If enabled, standalone games in fullscreen mode will not darken the secondary monitor in multi-monitor setups (no longer supported on Mac OS X).
Display Resolution Dialog	Should the game start with a dialog to let the user choose the screen resolution? The options are Disabled, Enabled and Hidden by Default (ie, the dialog only appears if the alt key is held down at startup).
Use Player Log	Write a log file with debugging information. If you plan to submit your application to the Mac App Store you will want to leave this option un-ticked. Ticked is the default.
Resizable Window	Allow user to resize the standalone player window.
Mac App Store Validation	Enable receipt validation for the Mac App Store.
Mac Fullscreen Mode	How should fullscreen mode operate on MacOSX? The options are Capture Display (ie, Unity takes over the whole display and the user cannot switch apps until fullscreen mode is exited), Fullscreen Window and Fullscreen Window with Menu Bar and Dock.
Supported Aspect Ratios	The aspect ratios that will appear in the Resolution Dialog at startup (as long as they are supported by the user’s monitor).

Icon

Property:	Function:
Override for Standalone	Check if you want to assign a custom icon you would like to be used for your standalone game. Different sizes of the icon should fill in the squares below.

Splash Image

Property:	Function:
Config Dialog Banner	Add your custom splash image that will be displayed when the game is starting.

Other Settings

Property:	Function:
Rendering
Rendering Path	This property is shared between Standalone and WebPlayer content.
Vertex Lit	Lowest lighting fidelity, no shadows support. Best used on old machines or limited mobile platforms.
Forward with Shaders	Good support for lighting features; limited support for shadows.
Deferred Lighting	Best support for lighting and shadowing features, but requires certain level of hardware support. Best used if you have many realtime lights.
Color Space	Which color space should be used for rendering? The options are Gamma and Linear.
Use Direct3D 11	Use Direct3D 11 for rendering. When D3D11 is not available or this flag is off, D3D9 will be used.
Static Batching	Set this to use Static batching (inactive by default in webplayers).
Dynamic Batching	Set this to use Dynamic Batching on your build (activated by default).
GPU Skinning	Should DX11/ES3 GPU skinning be enabled?
Stereoscopic Rendering	Should stereoscopic rendering be enabled?
Configuration
Scripting Define Symbols	Custom compilation flags (see the platform dependent compilation page for details).
Optimization
API Compatibility Level	See below
.Net 2.0	.Net 2.0 libraries. Maximum .net compatibility, biggest file sizes
.Net 2.0 Subset	Subset of full .net compatibility, smaller file sizes
Prebake Collision Meshes	Should collision data be added to meshes at build time?
Preload Shaders	Should shaders be loaded when the player starts up?
Preloaded Assets	An array of assets to be loaded when the player starts up.
Optimize Mesh Data	Remove any data from meshes that is not required by the material applied to them (tangents, normals, colors, UV).

API Compatibility Level

You can choose your mono api compatibility level for all targets except the webplayer. Sometimes a 3rd party .net dll will use things that are outside of the .net compatibility level that you would like to use. In order to understand what is going on in such cases, and how to best fix it, get “Reflector” on windows.

1. Drag the .net assemblies for the api compatilibity level in question into reflector. You can find these in Frameworks/Mono/lib/mono/YOURSUBSET/
2. Also drag in your 3rd party assembly.
3. Right click your 3rd party assembly, and select “Analyze”.
4. In the analysis report, inspect the “Depends on” section. Anything that the 3rd party assembly depends on, but is not available in the .net compatibility level of your choice will be highlighted in red there.

Details

Customizing your Resolution Dialog

You have the option of adding a custom banner image to the Screen Resolution Dialog in the Standalone Player. The maximum image size is 432 x 163 pixels. The image will not be scaled up to fit the screen selector. Instead it will be centered and cropped.

Publishing to the Mac App Store

Use Player Log enables writing a log file with debugging information. This is useful to find out what happened if there are problems with your game. When publishing games for Apple’s Mac App Store, it is recommended to turn this off, because Apple may reject your submission otherwise. See this manual page for further information about log files.

Use Mac App Store Validation enables receipt validation for the Mac App Store. If this is enabled, your game will only run when it contains a valid receipt from the Mac App Store. Use this when submitting games to Apple for publishing on the App Store. This prevents people from running the game on any computer then the one it was purchased on. Note that this feature does not implement any strong copy protection. In particular, any potential crack against one Unity game would work against any other Unity content. For this reason, it is recommended that you implement your own receipt validation code on top of this using Unity’s plugin feature. However, since Apple requires plugin validation to initially happen before showing the screen setup dialog, you should still enable this check, or Apple might reject your submission.

Windows Store Apps

Most of these settings are transferred to Package.appxmanifest when creating Visual Studio solution for the first time.

Note: If you build your project on top of the existing one, Unity won’t overwrite Package.appxmanifest file if it’s already present, that means if you change something in Player Settings be sure to check Package.appxmanifest, if you want Package.appxmanifest to be regenerated, simply delete it, and rebuild your project from Unity.

To read more about App package manifest, please visit http://msdn.microsoft.com/en-us/library/windows/apps/br211474.aspx.

Settings from Packaging, Application UI, Tile, Splash screen, Capabilities directly transfer to settings in Package.appxmanifest file.

Certificate

Every Windows Store App needs a certificate which identifies a developer, Unity will create a default certificate, if you won’t provide your own.

Compilation

As you know, Unity uses Mono when compiling script files, and you can use the API located in .NET 3.5. Compilation Overrides allows you to use .NET for Windows Store Apps (also known as .NET Core) in your C# files, the API is available here.

When Compilation Overrides is set to:

1. None - C# files are compiled using Mono compiler.
2. Use .Net Core - C# files are compiled using Microsoft compiler and .NET Core, you can use Windows Runtime API, but classes implemented in C# files aren’t accessible from JS. Note: when using API from Windows Runtime, it’s advisable to wrap the code with NETFX_CORE define, because the API is only avaible when building to Windows Store Apps, and it’s not available in Unity Editor.
3. Use .Net Core Partially - C# files not located in Plugins, Standard Assets, Pro Standard Assets folders are compiled using Microsoft compiler and .NET Core, all other C# files are compiled using Mono compiler. The advantage is that classes implemented in C# are accessible from JS.

Note: You won’t be able to test .NET Core API in Unity Editor, because it doesn’t have access to .NET Core, so you’ll be able to test the API only when running Windows Store App.

Note: You cannot use .NET Core API in JS.

Here’s a simple example how to use .NET Core API in scripts.

    string GetTemporaryFolder()
    {
    #if NETFX_CORE
        return Windows.Storage.ApplicationData.Current.TemporaryFolder.Path;
    #else
        return "LocalFolder";
    #endif
    }

Plugins

Unprocessed Plugins contains a list of plugins which are ignored by Unity’s preprocessing tools (like SerializationWeaver, AssemblyPreprocessor, rrw), usually you don’t need to modify this list, unless you’re getting an error that Unity’s failed to preprocess your plugin.

What will happen if you’ll add a plugin to this list?

Unity won’t inject additional IL code into your assembly used for serialization purposes, but if you’re plugin isn’t referencing UnityEngine.dll, that’s totally fine, because Unity won’t serialize any data from your plugin.

Independent Input Source

Let’s you enable an option for independent input source, you can read more here. Basically this makes your input more responsive, and usually you want this option to be enabled.

Low Latency Presentation API

Let’s you enable Low Latency Presentation API, basically this create D3D11 swapchain with DXGI_SWAP_CHAIN_FLAG_FRAME_LATENCY_WAITABLE_OBJECT flag, read more here and should increase input responsiveness. This option is disabled by default because on hardware with older GPU drivers, this option makes game laggy, if you enable this option - be sure to profile your game if the performance is still acceptable.

Capabilities

These options are directly copied to Package.appxmanifest.

Note: If you’re build your game on top of previous package, Package.appxmanifest won’t be overwritten.