Esta página detalla los Player Settings específicos a Windows Store Apps. Una descripción de los Player Settings en general se pueden encontrar aquí.
La mayoría de estas configuraciones son transferidas a Package.appxmanifest cuando se crea una solution de Visual Studio por primera vez.
Tenga en cuenta: Si construye su proyecto encima del existente, Unity no sobrescribirá el archivo Package.appxmanifest si ya está presente, eso significa que si cambia algo en los Player Settings asegúrese de verificar Package.appxmanifest, si quiere que Package.appxmanifest sea regenerado, simplemente elimínelo, y re-construya su proyecto de Unity.
Para leer más acerca de App package manifest, por favor visite http://msdn.microsoft.com/en-us/library/windows/apps/br211474.aspx.
Los ajustes de Packaging, Application UI, Tile, Splash screen, Capabilities directamente transferidas a los ajustes en el archivo Package.appxmanifest.
Las orientaciones soportadas de los Player Settings también se rellenan en el manifest (archivo Package.appxmanifest en el solution de Visual Studio). En Windows 8.1 (Store y Phone) no se toman más acciones, Unity se iniciará en la orientación que está presente actualmente, por lo que si cambia la orientación de su aplicación en el código antes de inicializar Unity, se iniciará en esa orientación. En Windows 10 Universal Apps Unity re-iniciará la orientación a la que utilizó en los Player Settings, independientemente de lo que especifique en el manifest. Esto se debe a que el propio Windows ignora las configuraciones en las computadoras de escritorio y tabletas. Tenga en cuenta que siempre puede cambiar las orientaciones soportadas mediante la API de scripting de Unity.
Cada Windows Store Apps necesita un certificado que identifica a un desarrollador, Unity creará un certificado predeterminado, si usted no proporciona el suyo.
Como sabe, Unity utiliza Mono al compilar archivos script y puede utilizar la API ubicada en .NET 3.5. Compilation Overrides le permite usar .NET para Windows Store Apps (también conocido como .NET Core) en sus archivos de C#, la API está disponible aquí.
Tenga en cuenta: Usted no puede utilizar la .NET Core API en los scripts de JS.
Aquí hay un simple ejemplo de cómo utilizar la .NET Core API en los scripts.
string GetTemporaryFolder()
{
#if NETFX_CORE
return Windows.Storage.ApplicationData.Current.TemporaryFolder.Path;
#else
return "LocalFolder";
#endif
}
Los Plugins sin procesar contienen una lista de plugins que son ignorados por las herramientas de pre-procesamiento de Unity (como SerializationWeaver, AssemblyPreprocessor, rrw), usualmente usted no necesita modificar esta lista, al menos de que usted esté obteniendo un error de que Unity hay fallado de pre-procesar su plugin.
Qué pasará si usted agregará un plugin a esta lista?
Unity no inyectará código IL adicional a su assembly utilizado para los propósitos de serialización, pero si su plugin no está referenciando UnityEngine.dll, eso está completamente bien, ya que Unity no serializará cualquier dato de su plugin.
Le permite a usted habilitar una opción para fuentes de input independientes, usted puede leer más aquí. Básicamente, esto hace que su input sea más responsivo, y usualmente usted quiere que esta opción esté habilitada.
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.
Estas opciones son directamente copiadas a Package.appxmanifest.
Tenga en cuenta: Si usted está construyendo su juego encima de un paquete previó, Package.appxmanifest no será sobre-escrito.