Unity Motorunda Mobil Oyun Geliştirmede Adaptive Performance Sisteminin Derinlemesine Analizi

Modern mobil oyun geliştirme ekosisteminde donanım kapasitelerinin geometrik olarak artması, grafiksel sınırları zorlayan oyunların taşınabilir cihazlarda çalıştırılabilmesinin önünü açmıştır. Ancak mobil platformlar, masaüstü veya konsol sistemlerinin aksine aktif soğutma mekanizmalarından (fanlar veya sıvı soğutma sistemleri) yoksundur. Bir System-on-Chip (SoC) mimarisinde merkezi işlem birimi (CPU), grafik işlem birimi (GPU), bellek kontrolcüleri ve ağ modülleri milimetrik bir alan içerisinde bir arada bulunur.¹ Bu bileşenlerin yüksek saat hızlarında (clock speed) sürekli olarak çalıştırılması, kaçınılmaz bir şekilde devasa miktarda atık ısı üretimine neden olur.

Cihazın ısısı kritik eşiklere ulaştığında, işletim sistemi donanımı fiziksel hasardan korumak ve bataryanın kimyasal yapısının bozulmasını engellemek amacıyla "Thermal Throttling" (Termal Darboğaz) adı verilen bir savunma mekanizmasını devreye sokar.² Bu mekanizma, CPU ve GPU saat frekanslarını aniden ve agresif bir biçimde düşürür. Oyun geliştiricileri açısından bu durum, saniyedeki kare sayısının (FPS) aniden çökmesi, giriş gecikmelerinin (input lag) artması ve oyuncu deneyiminin bütünüyle bozulması anlamına gelir.³ Tam bu noktada, yazılım ile donanım arasında köprü kurarak oyun motorunun cihazın termal dinamiklerine proaktif bir şekilde uyum sağlamasını hedefleyen Unity Adaptive Performance (Uyarlanabilir Performans) sistemi devreye girmektedir. Bu rapor, geliştirme sürecinde sıklıkla karşılaşılan yapılandırma uyarılarının anatomisinden başlayarak, Adaptive Performance paketinin temel mimarisini, ölçeklendirme algoritmalarını, entegrasyon stratejilerini ve sağladığı optimizasyon avantajlarını akademik ve profesyonel bir derinlikte incelemektedir.

"Adaptive Performance Settings" Uyarısının Kök Nedenleri ve Yapılandırma Çözümleri

Unity oyun motorunda yeni bir mobil proje başlatıldığında veya mevcut bir proje mobil platformlara (Android, iOS) derlenmek üzere yapılandırıldığında, konsol ekranında sıklıkla şu uyarı veya türevi mesajlar belirmektedir: "No Adaptive Performance provider package installed. Adaptive Performance requires a provider to get information during runtime. Please install a provider such as Adaptive Performance Samsung (Android) from the Adaptive Performance Settings".⁴ Geliştiricilerin geliştirme süreçlerini duraksatan bu uyarının altında yatan temel neden, Unity'nin modüler paket yönetim sisteminin ve donanım soyutlama katmanının (Hardware Abstraction Layer) çalışma prensibidir.

Unity, özellikle "Mobile 2D", "Mobile 3D" veya "Universal Render Pipeline (URP)" gibi şablonlarla proje oluşturulduğunda, Adaptive Performance temel paketini projeye önceden yüklenmiş (pre-installed) olarak dahil etmektedir.⁵ Ancak temel paket, cihaz donanımından veri okuyabilecek veya işletim sistemine müdahale edebilecek yerel (native) kütüphanelere kendi başına sahip değildir. Paketin işlevsel hale gelebilmesi için hedeflenen işletim sistemine (Android vb.) veya test ortamına özel bir "Provider" (Sağlayıcı) modülünün projeye eklenmesi ve yapılandırılması gerekmektedir.⁶ Sağlayıcı modülü eksik olduğunda, temel paket çalışma zamanında (runtime) donanım sensörlerine ulaşamaz ve bu uyarıyı fırlatarak geliştiriciyi bilgilendirir. Uyarının çözümü ve yapılandırma adımları, geliştirme yapılan hedef platforma ve kullanılan Unity sürümüne göre ciddi metodolojik farklılıklar göstermektedir.

Geliştirme sürecinde karşılaşılan bu uyarının çözümü platform bazlı olarak ele alınmalıdır. İşletim sistemlerinin donanım API'lerine erişim izinleri farklı olduğundan, Unity'nin sunduğu çözümler de farklılık gösterir.

Hedef PlatformUyarının Teknik NedeniUygulanması Gereken Çözüm MetodolojisiAndroidADPF veya Samsung GameSDK ile haberleşecek yerel eklentinin projede bulunmaması.Unity Package Manager üzerinden Adaptive Performance Android Provider veya cihaz spesifik bir hedef varsa Samsung (Android) Provider paketi kurulmalıdır.⁶ Ardından Edit > Project Settings > Adaptive Performance menüsünden ilgili sağlayıcı aktif edilmelidir.iOS (Apple)iOS ekosisteminde Adaptive Performance için Unity tarafından desteklenen resmi bir donanım sağlayıcısının (provider) mevcut olmaması.⁴Projeye Mobile özellik seti eklendiğinde Adaptive Performance bir bağımlılık (dependency) olarak gelir ve silinemez. iOS derlemeleri için bu uyarı zararsızdır ve göz ardı edilebilir (ignore) veya bağımlılığı kırmak için Mobile modülü paket yöneticisinden kaldırılabilir.⁴Masaüstü Editör (PC/Mac)Windows veya macOS işletim sistemlerinde mobil cihazlara özgü termal sensörlerin ve SoC mimarilerinin bulunmaması.Geliştirme bilgisayarında mobil şartları simüle edebilmek için Simulator (Desktop) Provider yüklenmeli ve Device Simulator penceresi kullanılarak sanal bir termal ortam yaratılmalıdır.²Unity 6 (Build Profiles)Unity 6 ile gelen derleme profillerinde (Build Profiles), ana projenin Adaptive Performance ayarlarına ek olarak profile özel yapılandırmanın unutulması.File > Build Profiles menüsünde seçili platform için Add Settings > Adaptive Performance Settings butonu tıklanarak sağlayıcı atanmalıdır. Unity 6.000.x sürümlerinde bu ayarların eklenmemesi "No default loader found" hatasına yol açmaktadır.⁹

Bu uyarı, özünde bir derleme (compile) hatası değil, bir optimizasyon eksikliği bildirimidir. Geliştirici bu uyarıyı yoksayarak oyunda cihazda çalıştırabilir; ancak bu durumda oyun, donanımın termal durumu hakkında tamamen kör (blind) bir şekilde çalışacak ve kaçınılmaz olarak işletim sisteminin acımasız termal darboğaz müdahalelerine maruz kalacaktır.

Adaptive Performance Sisteminin Mimarisi ve Sağlayıcı (Provider) Ekosistemi

Adaptive Performance, oyun motorunun karar alma mekanizmaları ile fiziksel donanım arasında iki yönlü bir iletişim köprüsü kurar. Bu mimarinin veri toplama katmanı, sağlayıcılar (providers) tarafından oluşturulur. Android ekosisteminin son derece parçalanmış (fragmented) yapısı, tek bir donanım API'sinin tüm cihazlarda çalışmasını imkansız kıldığından, Unity bu sorunu farklı donanım çerçevelerine (frameworks) entegre olan spesifik sağlayıcılar ile aşmaktadır.

Android Dynamic Performance Framework (ADPF) Entegrasyonu

Unity'nin temel "Android Provider" modülü, Google tarafından Android 12 işletim sistemi ve sonrasında kullanıma sunulan Android Dynamic Performance Framework (ADPF) mimarisi üzerine inşa edilmiştir.² ADPF, oyunlar ile işletim sisteminin termal yönetimi arasında doğrudan bir diyalog kurulmasını sağlayan devrimsel bir API setidir. Geleneksel yaklaşımlarda işletim sistemi, oyunun hangi karesinin (frame) ne kadar işlemci gücüne ihtiyaç duyduğunu tahmin etmeye çalışır ve bu tahminler genellikle yanlış CPU saat hızlarının atanmasıyla sonuçlanır.

Unity Adaptive Performance Android sağlayıcısı ise "Performance Hint API" (Performans İpucu Arayüzü) aracılığıyla işletim sistemine sürekli bir veri akışı sağlar.⁶ Motor, her bir kare renderlandığında o karenin hedef süresini (örneğin 60 FPS hedefleniyorsa 16.6 milisaniye) ve CPU ile GPU'nun bu kareyi tamamlamak için harcadığı gerçek süreyi (actual duration) ADPF sistemine raporlar.⁶ Bu hassas geri bildirim döngüsü sayesinde Android işletim sistemi, CPU çekirdeklerinin frekansını yalnızca oyunun ihtiyacı olduğu kadar yükseltir. Cihaz ısınmaya başladığında işletim sistemi termal uyarıları Unity'e geri gönderir, böylece motor içi grafik ölçeklendiricileri donanım seviyesinde yavaşlatma yaşanmadan önce devreye girer.⁶ Android Provider'ın kararlı sürümü olan 1.2 ve üzeri versiyonları (Pixel cihaz sınırlamasını aşan sürümler) Adaptive Performance 5.0 ve Unity 2021.3 sonrasında desteklenmektedir.⁶

Samsung GameSDK ve Spesifik Donanım Optimizasyonları

Samsung, Android ekosistemindeki en geniş pazar paylarından birine sahip olması nedeniyle, kendi donanımlarının sınırlarını zorlayabilmek adına GameSDK adında özelleştirilmiş bir donanım arayüzü sunmaktadır. Unity'nin Adaptive Performance Samsung (Android) sağlayıcısı, standart ADPF özelliklerinin ötesine geçerek doğrudan Samsung SoC'lerinin derinine inen metrikler elde edilmesine olanak tanır.²

Samsung sağlayıcısı, Android 10 ve üzeri işletim sistemine sahip, GameSDK 3.2 ve daha güncel sürümleri destekleyen devasa bir cihaz yelpazesini kapsar. Bu kapsama alanı, giriş seviyesinden amiral gemisi cihazlara kadar uzanarak geliştiricilere çok geniş bir optimizasyon alanı sunar.

Desteklenen Samsung Galaxy SerileriModeller (GameSDK 3.2+ / Android 10+)Galaxy S SerisiS9, S10e, S10, S10+, S10 Lite, S20, S20+, S20 Ultra, S20 Lite, S21, S21+, S21 Ultra, S22, S22+, S22 Ultra¹³Galaxy Note SerisiNote9, Note10, Note10+, Note10 Lite, Note20, Note20 Ultra¹³Galaxy Z (Katlanabilir) SerisiZ Fold2¹³Galaxy A SerisiA10s, A11, A21s, A31, A41, A50s, A51, A51 5G, A71, A71 5G, A80, A8 2018, A9 2018, A90 5G¹³Galaxy Xcover SerisiXcover 4s, Xcover Pro¹³

Bu cihazların sağladığı en önemli donanımsal avantajlardan biri "Değişken Yenileme Hızı" (Variable Refresh Rate - VRR) teknolojisidir.¹³ VRR desteği şimdilik Galaxy S20, S21, S22 ve Note 20 cihazlarında aktif olarak kullanılabilmektedir.¹³ Adaptive Performance, cihazın sınırlarına ulaştığını tespit ettiğinde ve oyunun FPS değerini örneğin 60'tan 45'e düşürmeye karar verdiğinde, Samsung VRR API'sine bir komut göndererek ekranın fiziksel yenileme hızını da 45 Hz'e düşürür.¹⁶ Bu senkronizasyon, grafik yırtılmalarını (screen tearing) engellediği gibi ekran panelinin fazladan güç tüketmesinin de önüne geçer ve cihazın daha hızlı soğumasına ciddi bir katkı sağlar. Ayrıca Samsung sağlayıcısı, GameSDK 3.5 (Android 12) ve üzeri cihazlarda işlemcinin big.LITTLE mimarisindeki büyük ve küçük çekirdeklerin yük dağılımlarını gösteren "Cluster Info" verilerine erişim imkanı da sunmaktadır.¹³

Termal Metrikler ve Darboğaz (Bottleneck) Tespit Algoritmaları

Adaptive Performance'ın proaktif bir optimizasyon sunabilmesinin ardındaki mühendislik, sürekli olarak veri toplayan sensör analiz sistemlerine dayanır. Oyunun çalışma zamanında oluşturulan IAdaptivePerformance arayüzü (interface), donanımdan iki ana kategoride veri seti okur: Termal Durum Geri Bildirimi (Thermal State Feedback) ve Çerçeve Zamanlaması (Frame Timing). Bu veriler doğrultusunda sistemin o anki performansı sınırlayan ana unsurun (darboğaz) ne olduğuna karar verilir.

Termal Geri Bildirim ve Uyarı Seviyeleri

Cihazın ısıl durumu sadece basit bir santigrat derece okuması üzerinden değerlendirilmez. Termal dinamikler, normalize edilmiş ve analitik olarak işlenmiş üç farklı metrik üzerinden izlenir ²:

İlk metrik olan TemperatureLevel (Sıcaklık Seviyesi), 0.0 ile 1.0 arasında normalize edilmiş (0.0 standart oda/çalışma sıcaklığı, 1.0 mutlak maksimum ısıl eşik) bir kayan nokta (float) değeridir.² Geliştiriciler bu değeri kullanarak oyunun arayüzünde oyuncuya cihazın ısınma durumunu grafiksel bir bar olarak sunabilir veya kendi özel optimizasyon mantıklarını kurgulayabilirler.

İkinci ve daha öngörüsel metrik olan TemperatureTrend (Sıcaklık Eğilimi), -1.0 ile 1.0 arasında

değişen ve sıcaklığın matematiksel türevini, yani değişim hızını temsil eden bir değerdir. 2 Değerin 1.0 olması cihazın son derece hızlı bir şekilde ısındığına işaret ederken, 0 değeri sıcaklığın sabit kaldığını, -1.0 ise agresif bir soğuma periyoduna girildiğini gösterir. Sistemin bu trendleri algılayıp geçerli bir ortalama alması genellikle yaklaşık on saniyelik bir analiz süreci gerektirir. 2 Üçüncü ve en kritik metrik ise WarningLevel (Uyarı Seviyesi) olarak adlandırılan, işletim sisteminin termal duruma vereceği tepkiyi belirten kategorik bir sınıflandırmadır. 2

Uyarı Seviyesi (WarningLevel) İşletim Sistemi Durumu Adaptive Performance'ın Oyun Motorundaki Reaksiyonu NoWarning (0) Cihaz optimal sıcaklıklardadır. Herhangi bir termal yavaşlatma söz konusu değildir. Oyunun hedeflenen en yüksek çözünürlük, kare hızı ve görsel kalitede render edilmesine izin verilir. 2 ThrottlingImminent (1) Termal kapasite dolmak üzeredir. İşletim sistemi donanım frekanslarını henüz düşürmemiştir ancak tehlike çok yakındır. Proaktif müdahale başlar. Görsel etkisi düşük ölçeklendiriciler devreye sokularak (örneğin gölge mesafesinin kısaltılması) cihazın bir sonraki faza geçmesi engellenmeye çalışılır. 2 Throttling (2) Donanım kritik sıcaklığa ulaşmıştır ve işletim sistemi kendini korumak için CPU/GPU saat frekanslarını agresifçe düşürmüştür. En agresif optimizasyon faturası kesilir. Hedef kare hızı (Target FPS) dramatik şekilde düşürülür, ana render çözünürlüğü kısıılır ve cihazın normal sıcaklığa dönmesi için radikal ödünler verilir. 2

Çerçeve Zamanlaması ve Darboğaz (Bottleneck) Tespiti

Bir oyunun saniyede 60 kare hızına ulaşamaması birden fazla donanımsal yetersizlikten kaynaklanabilir. Sorunun grafik işlemcisinin (GPU) yetersizliğinden mi, yoksa ana işlemcinin (CPU) hesaplama gücünün tükenmesinden mi kaynaklandığını bulmak optimizasyonun ilk kuralıdır. Adaptive Performance, bu analizi yapabilmek için averageFrameTime (ortalama toplam kare süresi) ve averageGpuFrameTime (ortalama GPU çalışma süresi) verilerini her karede takip eder. 17 CPU süresi, Unity'nin ana ipliğinin (main thread) oyun mantığını çalıştırması ve render ipliğinin (render thread) verileri GPU'ya göndermek için hazırlaması (draw call batching vb.) süreçlerini kapsar. 17 Önemli bir detay olarak, CPU süresi ölçümüne işletim sistemi seviyesindeki blokajlar veya CPU'nun GPU'nun işini bitirmesini beklediği boşta geçirdiği süreler (idle/wait times) dahil edilmez. 17 Bu sürelerin analizi neticesinde sistem mevcut darboğazı (PerformanceBottleneck) dört kategoriden birine atar: ● CPU: Oyun içi yapay zeka algoritmaları, karmaşık fizik hesaplamaları veya aşırı sayıdaki obje örneklemeleri (instantiation) işlemciyi boğmaktadır. 20

● GPU: Çok katmanlı saydamlık efektleri (overdraw), yüksek çözünürlüklü dokuların okunması, ağır post-processing efektleri (örneğin SSAO veya Bloom) grafik birimini sınırlandırmaktadır. 22

● TargetFrameRate (Fillrate): Sistem hedef kare hızına zaten ulaşmıştır, herhangi bir donanımsal boğulma yoktur ve donanım potansiyelinin altında dahi çalışsa yetmektedir. 2

● Unknown: Gecikmenin kaynağının kesin olarak belirlenemediği ara durumlardır.

Geliştiriciler, PerformanceStatus.PerformanceBottleneckChangeEvent olayına abone olarak (delegate pattern ile) oyun esnasında darboğaz durumunun değiştiği anları yakalayabilir ve buna uygun algoritmik tepkiler verebilirler. 23 Örneğin, darboğaz aniden CPU'ya kaydığında, açık dünyadaki yapay zeka birimlerinin görüş açısı (raycast) tarama sıklığı saniyede 60 defadan 15 defaya düşürülerek işlemci üzerindeki matematiksel yük anında hafifletilebilir.

Karar Alma ve Yürütme Motoru: Indexer ve Ölçeklendiriciler (Scalers)

Adaptive Performance sisteminin otonom olarak çalışmasını sağlayan mekanizma, iki temel bileşenin kusursuz bir uyum içinde çalışmasına dayanır: "Indexer" (İndeksleyici) adı verilen beyin ve "Scalers" (Ölçeklendiriciler) adı verilen yürütme organları.

Indexer (İndeksleyici) Mekanizması

Indexer, cihazdan alınan karmaşık termal eğilimleri ve darboğaz verilerini sürekli olarak matematiksel bir süzgeçten geçirerek oyunun o anki "Kalite İndeksini" hesaplayan merkezi koordinatördür. 19 Indexer'ın ana görevi, donanımdaki her ufak ısı veya FPS dalgalanmasında oyun kalitesini sürekli değiştirerek görsel bir tutarsızlık (oscillation) yaratılmasını engellemektir. Bu kararlılığı sağlamak için Project Settings içinden Thermal Action Delay (Termal eylem gecikmesi) ve Performance Action Delay (Performans eylem gecikmesi) saniye cinsinden tanımlanabilir. 23 Sistem darboğaz hissetse bile, tanımlanan bu gecikme süresi boyunca durumun kalıcı olduğundan emin olur, ardından bir eylem kararı alır ve bağlı bulunan ölçeklendiricilere kaliteyi düşürmeleri (StateAction.Decrease) yönünde bir sinyal yollar. 23

Ölçeklendiricilerin (Scalers) Matematiksel ve Görsel Etki Analizi

Ölçeklendiriciler, Unity'nin Render Pipeline'ının (İşleme Hattı) veya fizik motorunun spesifik özelliklerini çalışma zamanında (runtime) değiştiren betiklerdir. 19 Her bir ölçeklendiricinin varsayılan seviyesi (Level) sıfırdır. Indexer'dan gelen her "kaliteyi düşür" sinyali ile bu seviye artar; seviye arttıkça ölçeklendiricinin kontrol ettiği özelliğin detayı azalır. 19 Ölçeklendiricilerin ne zaman ve hangi sırayla devreye gireceği, üç boyutlu bir karar matrisi ile belirlenir 19 :

1. Darboğaz Hedefi (Targeting Bottleneck): Eğer analiz sonucunda darboğazın GPU olduğu tespit edilmişse, Indexer CPU'yu optimize eden ölçeklendiricileri pas geçip doğrudan GPU'yu hedefleyen (örneğin çözünürlük) ölçeklendiricileri zorlar.

2. En Düşük Seviye (Lowest Level): Henüz seviyesi artırılmamış (orijinal kalitesini koruyan) özelliklere öncelik verilir.

3. Görsel Etki (Visual Impact): Özelliğin kalitesi düşürüldüğünde oyuncunun bunu fark etme olasılığıdır. Düşük (Low), Orta (Medium) veya Yüksek (High) olarak sınıflandırılır. 19 Sistem her zaman önce Düşük görsel etkiye sahip özellikleri kısmaya başlar.

Sistem, hem standart render hattı hem de Universal Render Pipeline (URP) için son derece geniş bir ölçeklendirici yelpazesi sunar. Aşağıdaki tablo, bu ölçeklendiricilerin donanımsal hedeflerini ve uygulama içindeki teorik etkilerini detaylandırmaktadır.

Ölçeklendirici Sınıfı Darboğaz Hedefi Görsel Etkisi İşleme Hattındaki (Render Pipeline) Teorik ve Pratik Etkisi AdaptiveFramerat e CPU / GPU / Fillrate Yüksek Oyunun Application.targetFr ameRate değişkenini sınırlar arasında modifiye eder. Özellikle VSync kapalıyken etkilidir. 60 FPS'den 30 FPS'ye düşüş, çip üzerindeki tüm bileşenlerin boşta kalma süresini artırarak radikal bir soğuma periyodu yaratır. 19 AdaptiveResolutio n GPU / Fillrate Yüksek Ekran işleme çözünürlüğünün ölçeğini (Resolution Scale) dinamik olarak düşürür. 19

URP projelerinde Render Scale üzerinden çalışır. Piksel doldurma hızını (fillrate) geometrik oranda azalttığı için GPU termal yükünü kırmada en güçlü silahtır, ancak görüntü netliğini direkt bozar. 15 AdaptiveLOD CPU / GPU Orta Sahnedeki üç boyutlu modellerin Detay Seviyesi (Level of Detail - LOD) geçiş mesafelerini (LOD bias) manipüle eder. 18 Kamera modellere yaklaşsa bile düşük poligonlu versiyonların ekranda kalmasını sağlayarak CPU draw call'larını ve GPU vertex hesaplamalarını azaltır. 18 AdaptiveShadow mapResolution GPU Orta/Düşük URP'de gölge haritasının pikselsel çözünürlüğünü düşürür. Ekranda çok fazla hareket varken gölge kenarlarının piksellenmesi bilişsel olarak algılanması zor bir durum olduğundan, kaliteden ödün vermeden GPU bellek bant genişliğini rahatlatır. 19 AdaptiveShadowC ascade CPU / GPU Orta URP yönlü ışıklarında kaskat sayısını azaltır. Gölge kaskatlarının her biri, sahnedeki gölge düşüren objelerin bir kez daha render edilmesini (draw call) gerektirir. Kaskat sayısının düşmesi CPU darboğazını doğrudan hafifletir. 19 AdaptiveViewDist ance CPU / GPU Yüksek Ana kameranın uzak kesim düzlemini (far clip plane) daraltarak uzaktaki objelerin hiçbir şekilde render akışına dahil edilmemesini (frustum culling) sağlar. 19 Özellikle açık dünya oyunlarında en kritik optimizasyon adımlarından biridir. 15 AdaptiveLayerCull ing CPU / GPU Orta Genel görüş mesafesini kısmak yerine, belirli Unity katmanlarının (Layers) görünürlük mesafesini ayarlar. 2

Örneğin çevre detayları (çimen, ufak dekorlar) katmanının renderlanma mesafesi kısılarak oyuncu etrafındaki büyük yapılar korunurken minik detaylar silinerek performans artırılır. 16 AdaptivePhysics CPU Yüksek Unity'nin fizik motorunun (PhysX veya Box2D) güncellenme adımlarını (fixedDeltaTime) veya iterasyon sayılarını modifiye ederek CPU yükünü hafifletir. 2 Fizik hesaplamaları CPU bazlı darboğazların en büyük suçlularındandır. 21 AdaptiveBatching CPU Düşük Dinamik gruplama (Dynamic Batching) süreçlerini kontrol eder. Aşırı vertex hesaplaması gerektirmeyen durumlarda CPU'yu rahatlatır. 19 AdaptiveDecals CPU / GPU Düşük URP sisteminde duvarlardaki mermi izleri, kan lekeleri gibi etiketlerin (decals) render edilme mesafesini veya sayısını kısıtlayarak materyal çizim aşamasındaki overdraw yükünü azaltır. 2

Geliştiricilerin sadece varsayılan ölçeklendiricilere bağlı kalma zorunluluğu yoktur. Oyunun spesifik mekaniklerine uygun "Özel Ölçeklendiriciler" (Custom Scalers) geliştirilmesi şiddetle tavsiye edilen bir pratiktir. 2 Bir özel ölçeklendirici yazmak için AdaptivePerformanceScaler sınıfından kalıtım alınması ve VisualImpact, Target, MaxLevel gibi temel özelliklerin yanı sıra OnLevel() metodunun ezilmesi (override) yeterlidir. 19 Örneğin, sisli bir ortamda geçen bir oyunda, özel bir ölçeklendirici yazılarak ısı arttıkça sisin yoğunluğu artırılabilir (Adaptive Fog). Böylelikle oyuncunun görüş mesafesi doğal bir şekilde daralırken, arka planda kameranın çizim mesafesi kısaltılarak ciddi bir optimizasyon illüzyonu yaratılmış olur. 15

Performans Kontrol Modları ve Saat Frekansı (Clock Frequency) Yönetimi

Adaptive Performance, sadece oyun motoru içindeki grafik özelliklerini kısmakla kalmaz, aynı zamanda işletim sisteminin CPU ve GPU'ya sağladığı elektrik gücüne ve saat frekanslarına dolaylı veya doğrudan müdahale etme yeteneğine sahiptir. İşlemcilerin maksimum saat hızlarında çalışması asimptotik bir verimsizlik yaratır; yani kazanılan az miktarda fazladan işlem gücü karşılığında muazzam miktarda enerji tüketilir ve ısı üretilir. 17

Bu enerji dengesini yönetmek için Adaptive Performance arayüzü üç farklı kontrol modu (PerformanceControlMode) sunar: Sistem, Manuel ve Otomatik. 20

1. Sistem Modu (System Performance Control): Android sağlayıcısı dışındaki sistemlerde (örneğin masaüstü simülasyonu) geçerli olan varsayılan moddur. İşletim sistemi CPU/GPU frekanslarını geleneksel yöntemlerle kendisi belirler, Adaptive Performance donanıma müdahale etmez, sadece uygulama içi grafikleri kısar. 20

2. Manuel Mod (Manual Performance Control): Geliştiricinin Instance.DevicePerformanceControl.CpuLevel ve GpuLevel değişkenlerini 0 ile maksimum seviye arasında doğrudan atayabildiği moddur. 23 Bu kontrol modunun kullanımı çok spesifik benchmark testleri dışında kesinlikle önerilmez. 17 Mobil donanımların termal kısıtlamaları ve batarya deşarj karakteristiği hakkında derinlemesine bilgisi olmayan bir geliştiricinin, CPU seviyesini sürekli yüksekte tutması durumunda cihaz hızla aşırı ısınacak, işletim sistemi savunma mekanizmalarını devreye sokarak oyunu "Throttling" evresine hapsedecek ve batarya anlamsızca tükenecektir. 20

3. Otomatik Mod (Automatic Performance Control): En güvenli, en verimli ve kullanılması şiddetle tavsiye edilen kontrol modudur. 17 Geliştiricinin yapması gereken tek şey Application.targetFrameRate ile oyunun hedef kare hızını (örneğin 30 veya 60) belirlemektir. 23 Otomatik mod, arka planda cihaz ısısını, render süresini ve çalışma ortamını (menüde mi yoksa oyunda mı olunduğunu) analiz eder. 20 Eğer oyun 60 FPS hedefine çok rahat ulaşıyorsa, işlemciyi gereksiz yere tam kapasitede çalıştırmak yerine CPU ve GPU saat hızlarını sessizce aşağıya çeker. Kare hızı hala 60 olarak kalır ancak donanım çok daha az elektrik harcayarak oyunun serin kalmasını ve bataryanın saatlerce dayanmasını (Battery Life Preservation) sağlar. 20

Geçici Güç Yüklemesi: Boost Modu (Takviye Modu)

Mobil oyunların bazı anlarında, sürdürülebilir performanstan ziyade anlık olarak çok büyük bir işlem kapasitesine ihtiyaç duyulur. Bu gibi spesifik senaryolar için Adaptive Performance "Boost" (Takviye) API'sini barındırır. 23 Boost modu çağrıldığında, CPU veya GPU'nun asgari (minimum) çalışma frekansı geçici bir süre için azami (maximum) çalışma frekansına eşitlenerek donanım tam potansiyeliyle çalışmaya zorlanır. 23

Boost modunun stratejik olarak kullanılması gereken yerler şunlardır 23 :

● Oyunun veya bölümlerin açılışındaki bekleme ekranlarında (Loading Screens), belleğe alınacak ağır modellerin yüklenme sürelerini (load time) minimize etmek.

● Ağ (Network) üzerinden indirilen büyük paketlerin açılması veya asenkron veri işleme operasyonları sırasında oluşan bekleme sürelerini ortadan kaldırmak.

● Shader derleme (Shader Compilation) veya prosedürel içerik üretimi aşamalarında oyuncunun yaşayabileceği saniyelik mikro donmaları (hitches) engellemek.

Ancak Boost modunun aktivasyonu cihazın bataryasından muazzam bir akım çeker ve SoC ısısını anında yükseltir. 23 İşletim sistemi Throttling (Darboğaz) evresine zaten girmiş durumdaysa (cihaz aşırı sıcaksa), donanımın zarar görmesini engellemek adına Unity'nin Boost talebi veya Manuel CPU/GPU seviye ayarlama komutları işletim sistemi tarafından doğrudan reddedilerek kontrol "Sistem Moduna" zorla devredilir. 23 Geliştiricilerin bu arayüzü yalnızca oyuncunun pasif durumda beklediği yükleme ekranlarında ve saniyelik sürelerle kullanmaları hayati önem taşır.

Geliştirici Arayüzü: C# API Kullanımı ve Visual Scripting (Görsel Betikleme)

Adaptive Performance paketinin esnekliği, geliştiricilerin dilerlerse tek satır kod yazmadan otonom sistemi kullanabilmelerine, dilerlerse de oyunun kalbine inen özel mantıklar kurgulayabilmelerine olanak tanımasıdır.

C# API Üzerinden Olay Güdümlü (Event-Driven) Programlama

Sistemin termal verilerine programatik olarak erişmek isteyen geliştiriciler, paketle birlikte oluşturulan Singleton nesnesi olan UnityEngine.AdaptivePerformance.Holder.Instance (veya yeni sürümlerde Mobile.AdaptivePerformance.Holder) üzerinden verilere ulaşırlar. 18 Özellikle cihazın darboğaza girmek üzere olduğunu (ThrottlingImminent) yakalamak için IThermalStatus.ThermalStatus.ThermalEvent olayı (delegate) dinlenir. 2

Bir olay tetiklendiğinde (örneğin ısınma alarmı geldiğinde), durum bir switch-case yapısıyla analiz edilerek oyun mekaniklerine müdahale edilir. 2 Eğer uyarı seviyesi Throttling ise kare hızı 60'tan 15'e veya 30'a çekilir; uyarı yoksa tekrar 60 hedefine dönülür. 2 Aynı şekilde darboğaz CPU tarafındaysa, özel bir betik (script) ile haritadaki aktif yapay zeka ajanlarının bazıları deaktif edilerek işlemci anında rahatlatılabilir. 2

Visual Scripting (Görsel Betikleme) Entegrasyonu

Programcı olmayan teknik ressamlar (technical artists) ve oyun tasarımcıları için Unity 5.0 ve sonrası sürümlerde, C# API'sine Visual Scripting paketleri aracılığıyla tam destek getirilmiştir. 29

Projeye Visual Scripting paketi dahil edildikten sonra Edit > Project Settings > Visual Scripting > Node Library > Regenerate Units yolu izlenerek Adaptive Performance düğümlerinin (nodes) Fuzzy Finder arayüzüne eklenmesi sağlanmalıdır. 27

Bu entegrasyon sayesinde bir dizi özel düğüme erişim sağlanır 30 :

● Thermal Düğümleri: On Thermal Metric düğümü, cihazın ısıl uyarı seviyesi, sıcaklık yüzdesi (Temperature Level) ve sıcaklık eğilimi (Trend) değiştiğinde anında tetiklenir. Bu düğümün çıkış ucu, doğrudan sahnedeki ağır bir ışık kaynağını veya partikül sistemini kapatacak mantığa bağlanabilir.

● Performance Düğümleri: On Bottleneck düğümü darboğazın CPU, GPU veya Fillrate olup olmadığını sinyaller; Frame Timing ve FPS düğümleri ise oyun ekranına gerçek zamanlı performans verilerini yazdırmak için idealdir. Cluster Info düğümü sayesinde big.LITTLE mimarisindeki çekirdek yükleri okunabilir.

● Boost ve Levels Düğümleri: Görsel betik grafiğindeki sahne yükleme bloklarının başına Set Boost düğümü eklenerek, kod yazmaksızın yükleme hızları maksimize edilebilir; Get Performance Level ile mevcut işlemci durumu okunabilir.

Test, Profiling ve Optimizasyon Metodolojisi

Adaptive Performance sisteminin projeye eklenmesi tek başına tüm problemleri çözmez; doğru konfigüre edilmeyen bir sistem oyunun grafik kalitesini çok erken bozabilir veya hiçbir işe yaramayabilir. Geliştirme süreci bilimsel bir ölçüm ve kıyaslama metodolojisine (profiling and benchmarking) dayanmalıdır.

Temel Kıyaslama (Baseline) Oluşturma ve A/B Testi

Google ve Unity mühendislerinin ortak optimizasyon pratiklerine göre, atılması gereken ilk adım ADPF veya Adaptive Performance aktif edilmeden önce oyunun performansının ölçülmesidir (Baseline). 6 Oyun hedeflenen en düşük sistem gereksinimlerine (min-spec) sahip fiziki bir mobil cihaza yüklenmeli ve cihaz ısınana kadar yaklaşık yirmi dakika boyunca oynanmalıdır. 21 Bu test sırasında Unity Profiler aracı kablosuz ağ (Wi-Fi) üzerinden cihazla haberleştirilerek (Autoconnect Profiler) FPS'in düşmeye başladığı dakikalar ve Frame Time değerleri kaydedilmelidir. 1

Ardından Adaptive Performance sistemi, varsayılan ölçeklendiriciler ile projede aktif hale getirilir ve aynı test senaryosu baştan koşulur. 6 Profiler modülündeki yeni "Adaptive Performance" sekmesi aracılığıyla, hangi dakikada cihazın ThrottlingImminent uyarısı verdiği, sistemin hangi ölçeklendiriciyi (AdaptiveResolution örneğin) çalıştırdığı ve bunun CPU/GPU sürelerine nasıl etki ettiği ilk test ile yan yana getirilerek incelenmelidir. 2 Geliştirici, "Oyun 10. dakikada hala 60 FPS veriyor ama çözünürlük çok fazla düşüyor" gibi bulgulara ulaşırsa, Indexer'daki ölçeklendirici ağırlıklarıyla oynamalı ve oyuna özgü ince ayar (fine-tuning) yapmalıdır. 6

Masaüstü Ortamında Simülasyon: Device Simulator

Cihaz testleri elzem olsa da, fiziksel bir telefonun ısınıp soğumasını beklemek kodlama aşamasındaki iterasyon hızını düşürür. Bu durumun üstesinden gelmek için Simulator (Desktop) Provider geliştirilmiştir. 2 Masaüstü geliştirme bilgisayarında Window > General > Device Simulator penceresi açılarak, sanal cihazın batarya seviyesi, termal eğilimi ve darboğazları yapay olarak (artificial bottlenecks) tetiklenebilir. 2 Geliştirici tek bir tıklama ile sanal cihazın durumunu Throttling evresine geçirip, yazdığı özel ölçeklendiricilerin (Custom Scalers) oyundaki sis yoğunluğunu veya model detaylarını (LOD) nasıl değiştirdiğini saniyeler içinde anlık olarak test edebilir. 2

Geleneksel Optimizasyon Yaklaşımlarıyla Sinerji

Adaptive Performance bir mucize algoritma değildir; temeli hatalı kurgulanmış bir oyunu tek başına kurtaramaz. Sistem, klasik mobil optimizasyon pratikleri ile birleştirildiğinde devasa bir çarpan etkisi yaratır. 1

● Oyunun dokuları (textures) 2'nin üssü (POT - Power of Two) boyutlarında tasarlanmalı ve ASTC, ETC2 gibi mobil donanım sıkıştırma formatları kullanılmalıdır. 8

● Çalışma zamanında değiştirilmeyecek modellerin ve dokuların Read/Write Enabled seçenekleri kapatılarak CPU ve GPU belleğinde gereksiz kopya tutulması önlenmelidir. 31 Bellek tüketimi (memory bandwidth) ısının en büyük kaynaklarındandır. 1

● Mobil donanım üzerindeki ivmeölçer (accelerometer) sensörü oyun tarafından aktif olarak kullanılmıyorsa (örneğin bir yarış oyunu değilse) Player Settings üzerinden ivmeölçer tarama frekansının düşürülmesi veya kapatılması, işletim sistemini çok büyük bir dertten kurtararak termal zarfı (thermal envelope) genişletir. 31

● Cihaz kameralarının culling matrisleri (Occlusion Culling) dikkatlice fırınlanmalı (baked) ve kameranın görüş açısında olmayan ancak duvarların arkasında kalan on binlerce poligonluk modeller grafik işlemcisine yollanmadan (draw call) CPU üzerinde elenmelidir. 3

Tüm bu geleneksel önlemlerle ısınma süresi 15 dakikaya çıkarılmış bir oyun, son savunma hattı olan Adaptive Performance'ın AdaptiveResolution veya AdaptiveFramerate ölçeklendiricileri ile desteklendiğinde, saatler süren ve 60 FPS'ten 45 FPS'e düşüşün oyuncu tarafından asla fark edilemediği mükemmel ve sürdürülebilir bir mobil başyapıta dönüşür.

Mobil donanımların soğutma fanlarının olmaması, oyun geliştiricilerini silikonun ısıl sınırlarıyla satranç oynamaya mecbur bırakmaktadır. "Adaptive Performance Settings" gibi basit bir sağlayıcı kurulumu uyarısıyla başlayan bu teknik yolculuk; işletim sisteminin güç yönetimi valflerine erişim, termal analiz türevlerini okuma ve render boru hattındaki kalite algoritmalarını gerçek zamanlı olarak manipüle etme ustalığına ulaşmaktadır. Optimizasyon süreci, yüksek tepe

performansına (peak performance) ulaşmaktan ziyade, akıcı kare hızının sürdürülebilirliğine (sustained performance) odaklanıldığında, hem oyuncu memnuniyetini maksimize etmekte hem de mobil platformlarda uzun vadeli başarının kilidini açmaktadır.

*Bilgi : Görseller, Google Gemini Tarafından Üretilmiştir.