Progetta per schermi di grandi dimensioni

In questa guida imparerai ad adattare il tuo gioco in modo che funzioni su diversi fattori di forma Android.

Prima di iniziare, leggi Supporta il ridimensionamento degli schermi di grandi dimensioni. I giochi moderni su Android devono adattarsi a tutte le dimensioni dello schermo senza fare affidamento sui livelli di compatibilità del sistema. In questo modo, hai sempre il controllo su come viene visualizzato il tuo gioco e quest'ultimo offre un'esperienza di gioco premium, anche su fattori di forma come XR o dispositivi in cui non è possibile ruotare lo schermo.

Per farlo, completa le seguenti attività:

1. Disattiva il letterbox di sistema e implementa il tuo letterbox nel motore.
2. Rendi l'area con letterbox utilizzabile e appropriata dal punto di vista tematico.
3. Affronta le considerazioni di progettazione necessarie per consentire al tuo gioco di scalare da 21:9 a 1:1 e a 9:21.

Comandi per i test

Durante la creazione e il test del gioco, verifica che il gioco esegua il rendering di eventuali letterbox. Inoltre, devi forzare l'orientamento verticale e orizzontale del gioco, perché i dispositivi come le TV e i display delle auto non possono ruotare rispetto all'orientamento verticale o orizzontale predefinito.

Per verificare se il tuo motore grafico utilizza il letterbox di sistema, utilizza il comando adb shell cmd window set-letterbox-style. Ad esempio, il seguente comando rende le letterbox di sistema di colore verde brillante e aggiunge un raggio dell'angolo al gioco, rendendo evidente se il gioco torna alla modalità di compatibilità del sistema operativo:

adb shell "cmd window set-letterbox-style --backgroundType solid_color --backgroundColor '#00FF00' --cornerRadius 30 --isEducationEnabled false"

Per forzare un orientamento per i test, utilizza adb shell cmd window user-rotation lock. In questo modo puoi simulare il comportamento del tuo gioco su un dispositivo che non rispetta gli override dell'app per l'orientamento o capire cosa vedono gli utenti su un dispositivo XR o simile a un PC in cui le finestre possono essere visualizzate in verticale o in orizzontale indipendentemente dall'orientamento del dispositivo.

Innanzitutto, metti il dispositivo in uno stato in cui puoi eseguire l'override dell'orientamento dell'app:

adb shell cmd window set-ignore-orientation-request true
adb shell cmd window fixed-to-user-rotation enabled

Successivamente, prova a cambiare l'orientamento del gioco in orizzontale:

adb shell cmd window user-rotation lock 1

Poi prova a cambiare l'orientamento del gioco in verticale:

adb shell cmd window user-rotation lock 0

Ripristina la configurazione OEM del dispositivo riavviando o eseguendo i seguenti comandi:

adb shell cmd window reset-letterbox-style
adb shell cmd window fixed-to-user-rotation default
adb shell cmd window user-rotation free
adb shell cmd window set-ignore-orientation-request reset

Perché disattivare il letterbox di sistema?

Il sistema controlla sempre il letterbox di sistema. Rilevando le dimensioni dello schermo e gestendo l'area di visualizzazione, puoi ridurre i problemi, come gli input ignorati, che si verificano quando gli input lasciano l'area di gioco. Puoi anche espandere gli elementi non di gameplay fino al bordo dello schermo, anche se i contenuti del gioco rimangono fissi al centro. Le modalità di compatibilità del sistema possono rendere disponibile un gioco, ma spetta a te, in qualità di sviluppatore, renderlo fantastico per i tuoi giocatori.

Esempio di implementazione di letterbox

La maggior parte dei motori grafici ti consente di controllare dove viene eseguito il rendering di una videocamera sullo schermo. Per implementare il tuo letterbox, misura le proporzioni dell'area di rendering e regola il rettangolo di ritaglio per l'area inutilizzata anziché lasciare che il sistema applichi il letterbox al gioco. L'esempio seguente limita una fotocamera al rendering in proporzioni limitate, consentendo al contempo alle fotocamere o ai passaggi della UI di espandersi alle dimensioni logiche dello schermo intero:

[SerializeField]
private float minAspectRatio = 4f / 3f;

[SerializeField]
private float maxAspectRatio = 21f / 9f;

private Camera _camera;

private void Awake()
{
    _camera = GetComponent<Camera>();
}

public void MaintainAspectRatio()
{
    int viewWidth = Screen.width;
    int viewHeight = Screen.height;

    // 1. Calculate screen aspect ratio
    float scaleScreen = viewWidth / (float)viewHeight;
    Rect rect = _camera.pixelRect;

    // 2. Scale to the fullest of the lower between width or height
    if (scaleScreen > maxAspectRatio)
    {
        // use height, lock width to max at aspect scale
        rect.width = viewHeight * maxAspectRatio;
        rect.height = viewHeight;
    }
    else if (scaleScreen < minAspectRatio)
    {
        // use width, lock height to min at aspect scale
        rect.width = viewWidth;
        rect.height = viewWidth / minAspectRatio;
    }
    else
    {
        // within allowed aspect ratio range, use full screen
        rect.width = viewWidth;
        rect.height = viewHeight;
    }

    rect.x = Mathf.Floor((viewWidth - rect.width) * 0.5f);
    rect.y = Mathf.Floor((viewHeight - rect.height) * 0.5f);

    Debug.Log("camera view width = " + rect.width +
        " height = " + rect.height +
        " x = " + rect.x +
        " y = " + rect.y);

    // 3. Commit the new size to the camera so that it takes effect
    _camera.pixelRect = rect;
}

/**
 * @brief Calculates a bounded-aspect-ratio gameplay viewport and scissor
 * rectangle and records them directly into a Vulkan command buffer.
 *
 * @note Requires `VK_DYNAMIC_STATE_VIEWPORT` and `VK_DYNAMIC_STATE_SCISSOR` to
 * be enabled on the bound graphics `VkPipeline`.
 *
 * @param command_buffer   Active `VkCommandBuffer` in the recording state.
 * @param window_width     Full physical window or swapchain width in pixels.
 * @param window_height    Full physical window or swapchain height in pixels.
 * @param min_aspect_ratio Minimum allowed aspect ratio (`width / height`).
 * @param max_aspect_ratio Maximum allowed aspect ratio (`width / height`).
 */
void MaintainAspectRatio(VkCommandBuffer command_buffer, uint32_t window_width,
                         uint32_t window_height, float min_aspect_ratio,
                         float max_aspect_ratio) {
  if (command_buffer == VK_NULL_HANDLE || window_width == 0 ||
      window_height == 0 || min_aspect_ratio <= 0.0f ||
      max_aspect_ratio < min_aspect_ratio) {
    return;
  }

  // 1. Calculate screen aspect ratio.
  const float view_width = static_cast<float>(window_width);
  const float view_height = static_cast<float>(window_height);
  const float scale_screen = view_width / view_height;

  // 2. Scale to the fullest of the lower between width or height.
  float rect_width = view_width;
  float rect_height = view_height;
  if (scale_screen > max_aspect_ratio) {
    // Use height, lock width to max at aspect scale (pillarbox).
    rect_width = std::floor(view_height * max_aspect_ratio);
    rect_height = view_height;
  } else if (scale_screen < min_aspect_ratio) {
    // Use width, lock height to min at aspect scale (letterbox).
    rect_width = view_width;
    rect_height = std::floor(view_width / min_aspect_ratio);
  } else {
    // Within allowed aspect ratio range, use full screen.
    rect_width = view_width;
    rect_height = view_height;
  }

  const float rect_x = std::floor((view_width - rect_width) * 0.5f);
  const float rect_y = std::floor((view_height - rect_height) * 0.5f);

  // 3. Commit the new viewport and scissor to the command buffer so that
  // subsequent gameplay draw calls are transformed and clipped to this region.
  const VkViewport viewport = {
      .x = rect_x,
      .y = rect_y,
      .width = rect_width,
      .height = rect_height,
      .minDepth = 0.0f,
      .maxDepth = 1.0f,
  };
  const VkRect2D scissor = {
      .offset =
          {
              .x = static_cast<int32_t>(rect_x),
              .y = static_cast<int32_t>(rect_y),
          },
      .extent =
          {
              .width = static_cast<uint32_t>(rect_width),
              .height = static_cast<uint32_t>(rect_height),
          },
  };

  vkCmdSetViewport(command_buffer, 0, 1, &viewport);
  vkCmdSetScissor(command_buffer, 0, 1, &scissor);
}

Per una procedura dettagliata in Unity, consulta il codelab Ottimizza i giochi Unity per schermi grandi e pieghevoli.

Gestisci schermi di grandi e piccole dimensioni

Sui display più piccoli, come quelli degli smartphone e i display esterni dei pieghevoli, l'esperienza utente migliore potrebbe essere un gioco bloccato in modalità verticale o orizzontale. Man mano che gli schermi diventano più grandi, come nel caso di tablet, Chromebook, display per auto o display interni di pieghevoli, diventa meno auspicabile o addirittura impossibile ruotare il dispositivo, mentre il display fisico più grande mantiene il gioco giocabile in proporzioni fuori asse.

Per offrire ai giocatori la migliore esperienza, rileva le dimensioni dello schermo in fase di runtime e limita la rotazione quando necessario, offrendo al contempo ai giocatori una maggiore flessibilità man mano che le dimensioni dello schermo aumentano. Android considera la soglia ideale sw600dp, una larghezza minima di 600 pixel indipendenti dalla densità (600 dp). Questo valore è correlato a WindowSizeClass.WIDTH_DP_MEDIUM_LOWER_BOUND. Utilizza computeMaximumWindowMetrics per convalidare le dimensioni dello schermo disponibili nelle configurazioni multi-display.

Per supportare questa funzionalità nel tuo gioco, supporta tutti gli orientamenti nel manifest e, poi, sia in onCreate() che in onConfigurationChanged(), valuta la larghezza minima e imposta il blocco dell'orientamento in modo appropriato:

1. Rimuovi i blocchi di orientamento statici nel manifest e dichiara la gestione delle modifiche alla configurazione:

   <activity
       android:name=".MainActivity"
       android:resizeableActivity="true"
       android:configChanges="orientation|screenSize|smallestScreenSize|screenLayout|density|keyboard|keyboardHidden" />
   

2. Aggiungi le importazioni richieste:

   import android.content.pm.ActivityInfo
   import android.content.res.Configuration
   import android.os.Bundle
   import androidx.activity.enableEdgeToEdge
   import androidx.window.core.layout.WindowSizeClass
   import androidx.window.layout.WindowMetricsCalculator
   import kotlin.math.min
   

3. Gestisci sia onCreate che onConfigurationChanged:

   override fun onCreate(savedInstanceState: Bundle?) {
       enableEdgeToEdge()
       super.onCreate(savedInstanceState)
       applyAdaptiveOrientationPolicy()
       // ...
   }
   
   override fun onConfigurationChanged(newConfig: Configuration) {
       super.onConfigurationChanged(newConfig)
       applyAdaptiveOrientationPolicy()
       // ...
   }
   

4. Aggiorna l'orientamento richiesto in base alla larghezza minima dello schermo, bloccando gli schermi compatti sull'orientamento di progettazione preferito del gioco:

   private fun applyAdaptiveOrientationPolicy() {
       // compute the smallest screen bound in dp
       val maxMetrics = WindowMetricsCalculator.getOrCreate().computeMaximumWindowMetrics(this)
       val minDimensionPx = min(maxMetrics.bounds.width(), maxMetrics.bounds.height())
       val displaySmallestWidthDp = minDimensionPx / maxMetrics.density
   
       val targetOrientation = if (displaySmallestWidthDp >= WindowSizeClass.WIDTH_DP_MEDIUM_LOWER_BOUND) {
           // Large display (>= 600dp): allow free rotation in any orientation
           ActivityInfo.SCREEN_ORIENTATION_UNSPECIFIED
       } else {
           // Compact display (< 600dp): lock to your game's preferred orientation
           // (use SCREEN_ORIENTATION_SENSOR_LANDSCAPE for landscape-first games)
           ActivityInfo.SCREEN_ORIENTATION_PORTRAIT
       }
   
       // Guard against redundant setter calls to avoid configuration change loops
       if (requestedOrientation != targetOrientation) {
           requestedOrientation = targetOrientation
       }
   }
   

Progetta tenendo conto dei problemi comuni

Supportare una gamma di proporzioni e orientamenti offre ai giocatori la migliore esperienza utente possibile. A differenza degli smartphone, i display più grandi sono spesso fissi in orientamento orizzontale o verticale e, in alcuni casi, lo schermo è quasi quadrato. Su questi dispositivi più grandi, i giocatori spesso svolgono più attività contemporaneamente mentre giocano. Sfruttando al massimo lo spazio sullo schermo, puoi coinvolgere più giocatori più spesso e per sessioni di gioco più lunghe.

Le sezioni seguenti forniscono soluzioni per far sì che il tuo gioco offra un'esperienza premium su tutti i fattori di forma, anziché un gioco per smartphone incorporato in uno schermo non per smartphone.

Videocamere con riconoscimento dell'aspect ratio

Nei giochi 3D, se uno schermo è troppo alto, i giocatori possono avere l'impressione di visualizzare il gioco attraverso una fessura stretta, mentre se è troppo largo, i giocatori potrebbero perdersi le interazioni progettate. Come nei giochi 2D, puoi mantenere sempre visibile un'"area di sicurezza". Il codice seguente consente di passare da un campo visivo orizzontale a un campo visivo verticale della videocamera in base al confronto tra le proporzioni attive e le proporzioni di riferimento di 1920 x 1080. In questo modo, un designer può creare un gioco per un display 1080p e sapere che tutto ciò che è stato progettato all'interno di quel frame di riferimento rimane visibile:

[SerializeField]
private Camera _camera;

[SerializeField]
private float _referenceWidth = 1920f;

[SerializeField]
private float _referenceHeight = 1080f;

[SerializeField]
private float _referenceVerticalFov = 60f;

public float ReferenceAspectRatio => _referenceWidth / Mathf.Max(0.0001f, _referenceHeight);

private void Awake()
{
    if (_camera == null)
    {
        _camera = GetComponent<Camera>();
    }
}

// Built-in Render Pipeline callback. In URP, subscribe to
// RenderPipelineManager.beginCameraRendering or call UpdateFov() on resize.
private void OnPreCull()
{
    UpdateFov();
}

public void UpdateFov()
{
    if (_camera == null || _camera.orthographic)
    {
        return;
    }

    float referenceAspect = ReferenceAspectRatio;
    float currentAspect = _camera.aspect;
    if (currentAspect <= 0.0001f)
    {
        return;
    }

    float targetVerticalFov;

    if (currentAspect >= referenceAspect)
    {
        // Viewport is wider than (or equal to) the reference safe area
        targetVerticalFov = _referenceVerticalFov;
    }
    else
    {
        // Viewport is skinnier than the reference safe area
        float referenceHorizontalFov = Camera.VerticalToHorizontalFieldOfView(_referenceVerticalFov, referenceAspect);
        targetVerticalFov = Camera.HorizontalToVerticalFieldOfView(referenceHorizontalFov, currentAspect);
        targetVerticalFov = Mathf.Clamp(targetVerticalFov, 1f, 179f);
    }

    if (!Mathf.Approximately(_camera.fieldOfView, targetVerticalFov))
    {
        _camera.fieldOfView = targetVerticalFov;
    }
}

/**
 * @brief Calculates an aspect-aware Vulkan perspective projection matrix using
 * GLM that keeps a reference safe area (e.g., 1920x1080) visible across
 * aspect ratios.
 *
 * @note Uses `glm::perspectiveZO` for Vulkan's `[0, 1]` depth range and
 * inverts `projection[1][1]` for Vulkan's top-left (`+Y` down) clip space.
 *
 * @param viewport_width         Active gameplay viewport width in pixels.
 * @param viewport_height        Active gameplay viewport height in pixels.
 * @param reference_width        Authored safe-area reference width in pixels.
 * @param reference_height       Authored safe-area reference height in pixels.
 * @param reference_vertical_fov Authored vertical FOV in degrees (e.g., 60.0f).
 * @param near_plane             Near clipping plane distance (`zNear > 0.0f`).
 * @param far_plane              Far clipping plane distance (`zFar > zNear`).
 * @return Aspect-aware `glm::mat4` perspective projection matrix for Vulkan.
 */
glm::mat4 CalculateAspectAwareProjectionMatrix(
    float viewport_width, float viewport_height, float reference_width = 1920.0f,
    float reference_height = 1080.0f, float reference_vertical_fov = 60.0f,
    float near_plane = 0.1f, float far_plane = 100.0f) {
  if (viewport_width <= 0.0001f || viewport_height <= 0.0001f) {
    return glm::mat4(1.0f);
  }

  // 1. Compare the active viewport aspect ratio against the reference safe
  // area.
  const float reference_aspect =
      reference_width / std::max(0.0001f, reference_height);
  const float current_aspect = viewport_width / viewport_height;

  float target_vertical_fov_rad = glm::radians(reference_vertical_fov);

  if (current_aspect >= reference_aspect) {
    // Viewport is wider than (or equal to) the reference safe area (Hor+).
    target_vertical_fov_rad = glm::radians(reference_vertical_fov);
  } else {
    // Viewport is skinnier than the reference safe area (Vert+):
    // Convert reference vertical FOV -> reference horizontal FOV -> new
    // vertical FOV at current_aspect so the safe area is never cropped.
    const float tan_half_horiz =
        std::tan(target_vertical_fov_rad * 0.5f) * reference_aspect;
    target_vertical_fov_rad = 2.0f * std::atan(tan_half_horiz / current_aspect);
    target_vertical_fov_rad = std::clamp(
        target_vertical_fov_rad, glm::radians(1.0f), glm::radians(179.0f));
  }

  // 2. Build the Vulkan [0, 1] depth perspective matrix and flip +Y clip space.
  glm::mat4 projection = glm::perspectiveZO(
      target_vertical_fov_rad, current_aspect, near_plane, far_plane);
  projection[1][1] *= -1.0f;
  return projection;
}

Cassette delle lettere completamente interattive

Alcuni giochi hanno un'area di gioco fissa per design, spesso in linea con considerazioni di progettazione basate sul genere, come il campo fisso di uno sparatutto verticale o lo scorrimento dello schermo utilizzato per un'estetica retrò.

Per questi giochi, scala l'area di gioco in modo che un asse del gioco sia sempre massimizzato per riempire l'area di gioco. L'asse massimizzato può cambiare in base ai formati relativi del gioco e ai limiti del display.

Ancora gli elementi HUD e UI fino al bordo sicuro dello schermo: evita i ritagli, ma posiziona gli elementi interattivi come i controlli virtuali, le barre della salute e le minimappe il più lontano possibile dall'area di gioco. In questo modo, la parte interattiva del gioco utilizza l'intero schermo e i giocatori su fattori di forma come tablet e pieghevoli possono giocare comodamente senza dover allungare eccessivamente le dita.

Infine, rendi l'area del letterbox appropriatamente a tema o diegetica. Prendi in considerazione bordi che corrispondono alla tavolozza o al set di riquadri sullo schermo, un tavolo o uno schermo virtuale per giochi da tavolo o retrò oppure minimappe estese e immagini decorative.

Nell'esempio seguente, il gioco viene visualizzato a schermo intero per la maggior parte delle proporzioni. Quando le proporzioni sono inferiori a 4:3, viene eseguito il rendering di uno skybox con colori a tema, mentre gli elementi UI come i controlli continuano a essere posizionati sul bordo dello schermo:

Nebbia di guerra

Molti sviluppatori di giochi temono che i giocatori possano ottenere un vantaggio sleale da proporzioni verticali o orizzontali estreme. Ad esempio, un giocatore in un gioco competitivo come un'arena di combattimento online multiplayer (MOBA) potrebbe utilizzare uno schermo molto verticale per avere una visuale approfondita della corsia di un avversario.

Per i giochi di strategia e simulazione dall'alto, valuta la possibilità di eseguire il rendering di una nebbia di guerra:

• Non eseguire il rendering della geometria finché il giocatore non può visualizzarla.
• Esegui il rendering della geometria che il personaggio del giocatore non può vedere attivamente come oscurata, senza elementi dinamici.
• Esegui il rendering solo di avversari, oggetti collezionabili e altri oggetti dinamici che il personaggio del giocatore può vedere attivamente in modo diegetico.

Se combini questa tecnica con letterbox completamente interattivi e visualizzi la UI fino al bordo dello schermo, il giocatore ottiene un'esperienza che sembra sia rifinita che intenzionale, senza che tu debba riprogettare la struttura dei livelli o il bilanciamento della squadra.

Se questo gioco viene espanso per riempire uno schermo più grande senza una nebbia di guerra, vengono mostrate parti della mappa che il giocatore non dovrebbe vedere:

Eseguendo il rendering di una nebbia di guerra e nascondendo elementi dinamici come nemici e oggetti, mantieni l'equità nel gioco utilizzando l'intero frame disponibile per il gioco:

Geometria con dissolvenza in uscita

Molti giochi, in particolare quelli di strategia a turni, utilizzano una tecnica simile alla nebbia di guerra descritta nella sezione precedente e non eseguono il rendering della geometria che il giocatore non ha scoperto o con cui non può interagire durante una determinata fase.

Se un campo visivo espanso rivelasse parti del set o del filmato che il giocatore non dovrebbe vedere, mascherare determinate parti della scena in modo pulito ottiene lo stesso effetto pratico di un letterbox senza la percezione di un bordo statico fisso.

Nell'esempio seguente, l'espansione del gioco a proporzioni più ampie rivela un'orda di zombie fuori dalle mura del castello:

In alternativa, puoi omettere il rendering della geometria del livello oltre i limiti dell'area di gioco corrente:

Confini diegetici

Nei giochi 3D immersivi in cui un campo visivo espanso può portare a un vantaggio competitivo nei giochi multiplayer in prima o terza persona o rivelare aree non create di giochi basati su set fissi, valuta la possibilità di creare elementi diegetici nel gioco per limitare il campo visivo anziché fare affidamento su un letterbox rettangolare. Ecco alcuni esempi:

• L'abitacolo di un veicolo, ad esempio un'auto o un aereo
• L'interno di un casco
• Una vignetta che indica il bordo della visione di un giocatore

Gli elementi UI e HUD devono comunque estendersi fino al bordo dello schermo o essere incorporati nei limiti diegetici. L'ideale è renderli dinamici. Questi elementi diegetici possono anche aiutare i giocatori che soffrono di cinetosi, soprattutto sui formati XR, fornendo un aiuto per l'accessibilità oltre a contribuire a mitigare la complessità dei nuovi formati.

Evita di eseguire il rendering del gioco su una superficie all'interno di una scena statica non interattiva. Sebbene questo approccio sia migliore rispetto al rendering di barre nere per letterbox e pillarbox, i giocatori notano rapidamente i bordi statici e possono sentirsi frustrati se i loro giochi preferiti vengono visualizzati in una sezione dello schermo di dimensioni simili a quelle di uno smartphone su formati diversi.

In questo esempio, un gioco progettato per lo schermo di uno smartphone standard viene visualizzato all'interno di una TV simulata con un gamepad scheumorfico per adattarsi alle proporzioni più quadrate comuni sui display interni dei pieghevoli:

Alcuni giochi 3D potrebbero dover limitare il campo visivo per motivi di equità competitiva o per considerazioni di progettazione. L'utilizzo di una cabina di pilotaggio, di un casco o di un'altra metafora diegetica per limitare il campo visivo è preferibile alle barre nere:

Risorse aggiuntive

• Crea un gioco Unity fantastico su tutti i fattori di forma
• Rendi il tuo gioco compatibile con tutti i fattori di forma
• Abilita l'input naturale su tutti i fattori di forma
• Gestisci l'orientamento del dispositivo con la prerotazione Vulkan