Desain untuk perangkat layar besar

Dalam panduan ini, Anda akan mempelajari cara menyesuaikan game agar berfungsi di berbagai faktor bentuk Android.

Sebelum memulai, baca Mendukung perubahan ukuran layar besar. Game modern di Android harus beradaptasi dengan semua ukuran layar tanpa mengandalkan lapisan kompatibilitas sistem. Dengan cara ini, Anda selalu memiliki kontrol atas cara game ditampilkan dan game Anda memberikan pengalaman pemain premium, bahkan pada faktor bentuk seperti XR atau perangkat yang layarnya tidak dapat diputar.

Untuk melakukannya, selesaikan tugas-tugas berikut:

  1. Nonaktifkan tampilan lebar sistem dan terapkan tampilan lebar dalam mesin Anda sendiri.
  2. Buat area tampilan lebar dapat digunakan dan sesuai secara tematis.
  3. Atasi pertimbangan desain yang diperlukan agar game Anda dapat diskalakan dari 21:9 hingga 1:1 dan menjadi 9:21.

Perintah untuk pengujian

Saat mem-build dan menguji game, pastikan game Anda merender letterbox sendiri. Anda juga harus memaksa game ke orientasi potret dan lanskap, karena perangkat seperti TV dan layar dalam mobil tidak dapat berputar dari orientasi lanskap atau potret defaultnya.

Untuk memeriksa apakah game engine Anda menggunakan tampilan lebar sistem, gunakan perintah adb shell cmd window set-letterbox-style. Misalnya, perintah berikut membuat tampilan lebar sistem berwarna hijau terang dan menambahkan radius sudut ke game Anda, sehingga terlihat jelas jika game Anda kembali ke mode kompatibilitas sistem operasi:

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

Untuk menerapkan orientasi tertentu saat pengujian, gunakan adb shell cmd window user-rotation lock. Hal ini membantu Anda menyimulasikan perilaku game di perangkat yang tidak mematuhi penggantian aplikasi untuk orientasi, atau memahami apa yang dilihat pengguna di perangkat XR atau seperti PC, tempat jendela dapat muncul dalam mode potret atau lanskap, terlepas dari orientasi perangkat.

Pertama, tempatkan perangkat Anda dalam status yang memungkinkan Anda mengganti orientasi aplikasi:

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

Selanjutnya, uji perubahan game Anda ke mode lanskap:

adb shell cmd window user-rotation lock 1

Kemudian, uji perubahan game Anda ke mode potret:

adb shell cmd window user-rotation lock 0

Reset perangkat Anda ke konfigurasi OEM dengan memulai ulang atau menjalankan perintah berikut:

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

Mengapa menonaktifkan tampilan lebar sistem?

Sistem selalu mengontrol tampilan lebar sistem. Dengan mendeteksi ukuran layar dan mengelola area tampilan sendiri, Anda dapat mengurangi masalah, seperti input yang hilang, yang terjadi saat input keluar dari area game. Anda juga dapat memperluas elemen non-gameplay ke tepi layar, meskipun konten game Anda tetap berada di tengah. Mode kompatibilitas sistem dapat membuat game tersedia, tetapi sebagai developer game, Anda harus membuat game yang bagus untuk pemain.

Ilustrasi layar ponsel, perangkat foldable, tablet, dan laptop yang menandai area jendela aktif.
Gambar 1. Faktor bentuk ponsel, perangkat foldable, tablet, dan laptop.

Contoh penerapan tampilan lebar

Sebagian besar game engine memberi Anda kontrol atas tempat kamera merender di layar. Untuk menerapkan tampilan lebar Anda sendiri, ukur rasio aspek area yang dirender dan sesuaikan persegi panjang pemangkasan untuk area yang tidak digunakan, bukan membiarkan sistem menampilkan game Anda dalam tampilan lebar. Contoh berikut membatasi satu kamera untuk merender ke rasio aspek yang dibatasi, sekaligus memungkinkan kamera atau penerusan UI diperluas ke ukuran layar logis penuh:

Unity

[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;
}

C++ (Vulkan)

/**
 * @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);
}

Untuk panduan langkah demi langkah di Unity, lihat codelab Mengoptimalkan Game Unity untuk Layar Besar dan Perangkat Foldable.

Menangani ukuran layar besar dan kecil

Pada layar yang lebih kecil, seperti ponsel dan layar luar perangkat foldable, pengalaman pengguna terbaik mungkin adalah game yang dikunci dalam mode potret atau lanskap. Seiring bertambah besarnya layar—seperti tablet, Chromebook, layar dalam mobil, atau layar dalam perangkat foldable—memutar perangkat menjadi kurang diinginkan atau bahkan tidak mungkin, sementara layar fisik yang lebih besar membuat game tetap dapat dimainkan dalam rasio aspek di luar sumbu.

Untuk memberikan pengalaman terbaik kepada pemain, deteksi ukuran layar saat runtime dan batasi rotasi jika diperlukan, sekaligus berikan lebih banyak fleksibilitas kepada pemain seiring bertambahnya ukuran layar. Android menganggap batas ideal adalah sw600dp, lebar terkecil 600 piksel kepadatan mandiri (600 dp). Hal ini berkorelasi dengan WindowSizeClass.WIDTH_DP_MEDIUM_LOWER_BOUND. Gunakan computeMaximumWindowMetrics untuk memvalidasi ukuran layar yang tersedia dalam konfigurasi multi-layar.

Untuk mendukung hal ini dalam game Anda, dukung semua orientasi dalam manifes, lalu di onCreate() dan onConfigurationChanged(), evaluasi lebar terkecil dan tetapkan kunci orientasi dengan tepat:

  1. Hapus kunci orientasi statis dalam manifes dan deklarasikan penanganan perubahan konfigurasi:

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

    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. Menangani onCreate dan onConfigurationChanged:

    override fun onCreate(savedInstanceState: Bundle?) {
        enableEdgeToEdge()
        super.onCreate(savedInstanceState)
        applyAdaptiveOrientationPolicy()
        // ...
    }
    
    override fun onConfigurationChanged(newConfig: Configuration) {
        super.onConfigurationChanged(newConfig)
        applyAdaptiveOrientationPolicy()
        // ...
    }
    
  4. Perbarui orientasi yang diminta berdasarkan lebar layar terkecil, dengan mengunci layar kecil ke orientasi desain pilihan game Anda:

    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
        }
    }
    

Mendesain untuk mengatasi masalah umum

Mendukung berbagai rasio aspek dan orientasi akan memberikan pengalaman pengguna terbaik kepada pemain Anda. Tidak seperti ponsel, layar yang lebih besar sering kali ditetapkan dalam orientasi lanskap atau potret, dan dalam beberapa kasus, layarnya hampir persegi. Di perangkat yang lebih besar ini, pemain sering kali melakukan banyak tugas sekaligus saat memainkan game Anda. Dengan memaksimalkan penggunaan ruang layar, Anda dapat berinteraksi dengan lebih banyak pemain, lebih sering, dan untuk sesi bermain yang lebih lama.

Bagian berikut memberikan solusi yang membuat game Anda terasa seperti pengalaman premium di berbagai faktor bentuk, bukan game ponsel yang disematkan di layar non-ponsel.

Kamera yang mendukung aspek rasio

Dalam game 3D, jika layar terlalu tinggi, pemain dapat merasa seperti melihat game melalui celah sempit, dan jika terlalu lebar, pemain mungkin melewatkan interaksi yang dirancang. Seperti dalam game 2D, Anda dapat membuat "area aman" selalu terlihat. Kode berikut mengalihkan kamera antara ruang pandang horizontal dan ruang pandang vertikal berdasarkan perbandingan rasio aspek aktif dengan rasio aspek referensi 1920x1080. Dengan cara ini, desainer dapat membuat game untuk layar 1080p dan mengetahui bahwa semua yang didesain dalam frame referensi tersebut tetap terlihat:

Unity

[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;
    }
}

C++ (Vulkan)

/**
 * @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;
}

Letterbox yang sepenuhnya interaktif

Beberapa game memiliki area bermain tetap berdasarkan desain, yang sering kali sesuai dengan pertimbangan desain berbasis genre, seperti bidang tetap dari game tembak-tembakan vertikal atau scroll layar balik yang digunakan untuk estetika retro.

Untuk game ini, sesuaikan skala area gameplay agar pas sehingga satu sumbu game selalu dimaksimalkan untuk mengisi area gameplay. Sumbu yang dimaksimalkan dapat berubah berdasarkan rasio aspek relatif game dan batas tampilan.

Tempatkan elemen HUD dan elemen UI hingga ke tepi aman layar: hindari potongan, tetapi tempatkan elemen interaktif seperti kontrol virtual, indikator health, dan minimap sejauh mungkin dari area gameplay. Dengan cara ini, bagian interaktif game menggunakan seluruh layar, dan pemain di faktor bentuk seperti tablet dan perangkat foldable dapat memainkan game Anda dengan nyaman tanpa perlu meregangkan jari secara berlebihan.

Terakhir, buat area tampilan lebar memiliki tema atau diegetik yang sesuai. Pertimbangkan border yang cocok dengan palet atau set ubin di layar, meja atau layar virtual untuk game papan atau retro, atau minimap yang diperluas dan visual dekoratif.

Dalam contoh berikut, game dirender dalam ukuran penuh untuk sebagian besar rasio aspek. Jika rasio aspek lebih sempit dari 4:3, game akan merender skybox berwarna tematik sambil terus menempatkan elemen UI seperti kontrol di tepi layar:

Game side-scrolling di hutan yang dirender tanpa tepi dalam jendela lanskap lebar dengan kontrol sentuh di sudut.
Gambar 2. Game dirender dalam ukuran penuh dengan rasio lebar tinggi standar.
Game hutan side-scrolling di jendela yang lebih sempit dari 4:3, menampilkan bar letterbox dedaunan kuning bertema dengan kontrol sentuh yang diposisikan di tepi layar luar.
Gambar 3. Game dengan rasio aspek lebih sempit dari 4:3 yang merender skybox bertema dengan kontrol UI yang ditambatkan ke tepi layar.

Fog of war

Banyak developer game khawatir bahwa pemain dapat memperoleh keuntungan yang tidak adil dari rasio aspek vertikal atau horizontal yang ekstrem. Misalnya, pemain dalam game kompetitif seperti multiplayer online battle arena (MOBA) mungkin menggunakan layar yang sangat vertikal untuk mendapatkan tampilan mendalam ke jalur lawan.

Untuk game strategi dan simulasi top-down, pertimbangkan untuk merender fog of war:

  • Jangan merender geometri sama sekali hingga pemain dapat melihatnya.
  • Render geometri yang tidak dapat dilihat secara aktif oleh karakter pemain sebagai redup, tanpa elemen dinamis.
  • Hanya render lawan, item yang dapat dikumpulkan, dan objek dinamis lainnya yang dapat dilihat secara aktif oleh karakter pemain secara diegetik.

Jika Anda menggabungkan teknik ini dengan tampilan lebar yang sepenuhnya interaktif dan merender UI ke tepi layar, pemain akan mendapatkan pengalaman yang terasa halus dan disengaja tanpa mengharuskan Anda mendesain ulang struktur level atau keseimbangan tim.

Memperluas game ini untuk mengisi layar yang lebih besar tanpa fog of war akan menampilkan bagian peta yang tidak boleh dilihat pemain:

RPG top-down di layar kecil yang menampilkan Sir Bugdroid memegang perisai dan lentera di dekat pedang bercahaya di atas tumpuan, jembatan sungai, dan jalur lori tambang.
Gambar 4. Tampilan kamera asli di layar yang lebih kecil.
Tampilan yang diperluas dari peta RPG top-down yang sama di layar besar yang menampilkan golem dan peti harta karun di dalam ruang dungeon dan goblin di seberang sungai.
Gambar 5. Tampilan yang diperluas menampilkan bagian peta yang tidak boleh dilihat pemain.

Dengan merender fog of war dan menyembunyikan elemen dinamis seperti musuh dan item, Anda menjaga keadilan dalam game sekaligus menggunakan frame penuh yang tersedia untuk game:

RPG top-down di layar kecil yang menampilkan area aktif di sekitar pemain.
Gambar 6. Area terlihat yang aktif di sekitar karakter pemain.
Tampilan peta RPG top-down yang diperluas, dengan medan yang jauh diredupkan dan musuh serta item di luar garis pandang pemain disembunyikan.
Gambar 7. Tampilan yang diperluas dengan kabut perang yang meredupkan medan yang jauh dan menyembunyikan elemen dinamis.

Memudarkan geometri

Banyak game, terutama dalam ruang strategi berbasis giliran, menggunakan teknik yang mirip dengan fog of war yang dijelaskan di bagian sebelumnya dan tidak merender geometri yang belum ditemukan pemain atau yang tidak dapat berinteraksi dengan pemain selama setpiece tertentu.

Jika ruang pandang yang diperluas akan menampilkan bagian set atau sinematik yang tidak boleh dilihat pemain, menyamarkan bagian tertentu dari adegan dengan cara yang dirancang dengan rapi akan mencapai efek praktis yang sama seperti letterbox tanpa persepsi batas statis yang tetap.

Dalam contoh berikut, memperluas game ke rasio aspek yang lebih besar akan menampilkan gerombolan zombie di luar dinding kastil:

Tampilan RPG taktis isometrik Bugdroid dan Mecha Hamster di dalam dinding kastil.
Gambar 8. Area bermain di dalam dinding kastil dengan rasio aspek yang lebih sempit.
Tampilan RPG taktis isometrik yang diperluas, memperlihatkan segerombolan musuh yang menunggu di luar gerbang kastil bawah.
Gambar 9. Rasio aspek yang lebih besar menampilkan gerombolan zombie di luar dinding kastil.

Sebagai gantinya, Anda dapat menghilangkan geometri level rendering di luar batas area bermain saat ini:

Tampilan RPG taktis isometrik Bugdroid dan Mecha Hamster di dalam dinding kastel.
Gambar 10. Area bermain di dalam dinding kastil.
Tampilan RPG taktis isometrik yang diperluas, dengan geometri level dan musuh di luar dinding kastil dihilangkan.
Gambar 11. Rasio aspek yang lebih besar, dengan geometri level tidak dirender di luar area bermain saat ini.

Batas diegetik

Dalam game 3D imersif, perluasan ruang pandang dapat memberikan keunggulan kompetitif dalam game multiplayer orang pertama atau ketiga, atau menampilkan area yang tidak dibuat dalam game berbasis set tetap. Pertimbangkan untuk membangun elemen diegetik ke dalam game untuk membatasi ruang pandang, daripada mengandalkan letterbox persegi panjang. Contohnya meliputi:

  • Interior kokpit kendaraan seperti mobil atau pesawat
  • Bagian dalam helm
  • Vinyet yang menunjukkan tepi penglihatan pemain

Elemen UI dan HUD harus tetap diperluas ke tepi layar atau digabungkan ke dalam batas diegetik, dan membuatnya dinamis adalah hal yang ideal. Elemen diegetik ini juga dapat membantu pemain yang mengalami mabuk perjalanan—terutama pada faktor bentuk XR—memberikan bantuan aksesibilitas selain membantu mengurangi kompleksitas rasio aspek baru.

Hindari merender game di platform dalam adegan statis non-interaktif. Meskipun pendekatan tersebut lebih baik daripada merender kotak hitam untuk letterbox dan pillarbox, pemain akan segera melihat batas statis dan dapat merasa frustrasi jika game favorit mereka dirender ke patch layar berukuran ponsel pada faktor bentuk non-ponsel.

Dalam contoh ini, game yang didesain untuk layar ponsel standar dirender di dalam televisi simulasi dengan gamepad skeumorfik untuk mengakomodasi rasio aspek yang lebih persegi yang umum pada layar dalam perangkat foldable:

Game labirin 3D yang dirender di dalam bingkai televisi CRT simulasi dengan gamepad skeuomorfik di latar depan.
Gambar 12. Game dirender di dalam frame televisi simulasi statis dengan gamepad skeumorfik.

Beberapa game 3D mungkin perlu membatasi ruang pandang, baik untuk keadilan kompetitif maupun untuk pertimbangan desain. Menggunakan kokpit, helm, atau metafora diegetik lainnya untuk membatasi ruang pandang lebih disukai daripada menggunakan kotak hitam:

Tampilan labirin 3D sudut pandang orang pertama dari dalam kokpit bola hamster berbentuk bola dengan minimap di atas dan kontrol sentuh di bawah.
Gambar 13. Bingkai kokpit bulat diegetik yang membatasi ruang pandang sekaligus menambatkan HUD dan kontrol ke tepi layar.

Referensi lainnya