Performansı artırma

Bu sayfa, yaygın performans sorunlarını ve bunları hafifletmek için en iyi uygulamaları açıklar.

Script hesaplaması

Luau kodundaki pahalı işlemler, işlenmesi daha uzun sürdüğü için kare hızını etkileyebilir. Paralel olarak çalıştırılmadığı sürece, Luau kodu senkronize olarak çalışır ve bir iş parçacığını bekleten bir işlevle karşılaşana kadar ana iş parçacığını engeller.

Yaygın sorunlar

• Tablo yapıları üzerinde yoğun işlemler - Serileştirme, serileştirmeden çıkarma ve derin kopyalama gibi karmaşık işlemler, özellikle büyük tablo yapıları üzerinde yüksek performans maliyeti taşır. Bu, bu işlemler özyinelemeli olduğunda veya çok büyük veri yapıları üzerinde yineleme içerdiğinde özellikle doğrudur.
• Yüksek frekanslı olaylar - Pahalı işlemleri RunService'in kare tabanlı olaylarına bağlamak, frekansı sınırlamadığınızda, bu işlemlerin her karede tekrarlandığı anlamına gelir ve bu genellikle gereksiz bir hesaplama süresi artışına yol açar. Bu olaylar şunları içerir:

  • RunService.PreAnimation
  • RunService.PreRender
  • RunService.PreSimulation
  • RunService.PostSimulation
  • RunService.Heartbeat

Hafifletme

• RunService olaylarında kodu dikkatli bir şekilde çağırın, yüksek frekanslı çağrının gerekli olduğu durumlarla sınırlayın (örneğin, kamerayı güncelleme). Diğer kodların çoğunu diğer olaylarda veya daha az sıklıkta bir döngü içinde çalıştırabilirsiniz.
• task.wait() kullanarak büyük veya pahalı görevleri parçalara ayırın ve işi birden fazla kareye yayarak dağıtın.
• Gereksiz yere pahalı işlemleri tanımlayın ve veri modeline erişmesi gerekmeyen hesaplama açısından pahalı görevler için çoklu iş parçacığı kullanın.
• Belirli sunucu tarafı betikleri, bir betiği bayt kodu yerine makine koduna derleyen yerel kod üretiminden fayda sağlayabilir.
• Sunucularınız hala CPU'dan yetersiz kalıyorsa, Genişletilmiş Hesaplama Hizmetleri ile daha fazla rezerve edebilirsiniz.

MicroProfiler kapsamları

MicroProfiler kullanarak betikleri hata ayıklama hakkında daha fazla bilgi için, belirli kodları etiketlemek ve debug.profilebegin ve debug.profileend gibi daha fazla özgüllük artıran işlevler içeren debug kütüphanesine bakın. Betikler tarafından çağrılan birçok Roblox API yöntemi de yararlı sinyaller sağlayabilecek kendi ilişkili MicroProfiler etiketlerine sahiptir.

Script bellek kullanımı

Bellek sızıntıları, bellek tüketen ve çöp toplayıcının artık kullanılmadığında düzgün bir şekilde serbest bırakamadığı betikler yazdığınızda meydana gelebilir. Sızıntılar, sunucuda özellikle yaygındır çünkü birçok gün boyunca çevrimiçi kalabilirler, oysa bir istemci oturumu çok daha kısadır.

Geliştirici Konsolu'ndaki aşağıdaki bellek değerleri, daha fazla araştırma gerektiren bir sorunu gösterebilir:

• LuaHeap - Yüksek veya artan tüketim, bir bellek sızıntısını gösterir.
• InstanceCount - Sürekli artan örnek sayıları, kodunuzda bazı örneklere yapılan referansların çöp toplayıcı tarafından temizlenmediğini gösterir.
• PlaceScriptMemory - Bellek kullanımının betik bazında dökümünü sağlar.

Yaygın sorunlar

• Bağlantıları bağlı bırakma - Motor, bir örneğe bağlı olayları ve bağlı geri çağrıda referans verilen herhangi bir değeri asla çöp toplamaz. Bu nedenle, etkin bağlantılar, olaylar ateşlendiğinde bile bellek çöp toplayıcısının kapsamından çıkar.

  Olaylar, ait oldukları örnek yok edildiğinde bağlantıları kesilir, ancak Player nesneleri için bunun geçerli olduğunu varsayamak yaygın bir hatadır. Bir kullanıcı oyundan ayrıldığında, motor otomatik olarak temsilci Player nesnesini ve karakter modelini yok etmez, bu nedenle Player nesnesine ve karakter modelinin altındaki örneklere, örneğin CharacterAdded, bağlantılar kesilmezse bellek tüketmeye devam eder. Bu, sunucuda yüzlerce kullanıcının oyuna katılıp ayrılmasıyla zamanla çok önemli bellek sızıntılarına yol açabilir.

• Tablolar - Nesneleri tablolara eklemek ancak artık ihtiyaç duyulmadığında kaldırmamak, özellikle kullanıcı verilerini takip eden tablolarda gereksiz bellek tüketimine neden olur. Örneğin, aşağıdaki kod örneği, her kullanıcı katıldığında kullanıcı bilgilerini ekleyen bir tablo oluşturur:

  Örnek

  local playerInfo = {}
  Players.PlayerAdded:Connect(function(player)
    playerInfo[player] = {} -- bazı bilgiler
  end)

  Bu girişleri artık ihtiyaç duyulmadığında kaldırmazsanız, tablo boyutu büyümeye devam eder ve daha fazla kullanıcı oturuma katıldıkça daha fazla bellek tüketir. Bu tabloyu yineleyen herhangi bir kod da tablo büyüdükçe daha hesaplama açısından pahalı hale gelir.

Hafifletme

Bellek sızıntılarını önlemek için kullanılan tüm değerleri temizlemek için:

• Tüm bağlantıları kesin - Kod tabanınızı gözden geçirin ve her bağlantının aşağıdaki yollardan biriyle temizlendiğinden emin olun:

  • Disconnect() işlevini kullanarak manuel olarak bağlantıyı kesmek.
  • Olayın ait olduğu örneği Destroy() işleviyle yok etmek.
  • Bağlantının geri izlediği betik nesnesini yok etmek.

• Oyuncu nesnelerini ve karakterleri ayrıldıktan sonra kaldırın - Kullanıcı ayrıldığında oyuncu nesnelerini ve karakter modellerini otomatik olarak yok etmek için Workspace.PlayerCharacterDestroyBehavior'ı etkinleştirin. İsterseniz, bunları manuel olarak temizleyebilirsiniz:

  Örnek oyuncu ve karakter temizleme

  local Players = game:GetService("Players")
  Players.PlayerAdded:Connect(function(player)
    player.CharacterRemoving:Connect(function(character)
      task.defer(character.Destroy, character)
    end)
  end)
  
  Players.PlayerRemoving:Connect(function(player)
    task.defer(player.Destroy, player)
  end)

Fizik hesaplaması

Aşırı fizik simülasyonu, hem sunucuda hem de istemcide her karede artan hesaplama süresinin ana nedenlerinden biri olabilir.

Yaygın sorunlar

• Aşırı fizik zaman adımı frekansı - Varsayılan olarak, adım davranışı, fizik mekanizmasının karmaşıklığına bağlı olarak 60 Hz, 120 Hz veya 240 Hz'de adım atan uyumlu modda çalışır.

  Tüm fizik montajlarının 240 Hz'de (her karede dört kez) adım atmasını zorlayan, fizik açısından daha iyi bir doğruluk sağlayan sabit bir mod da mevcuttur. Bu, her karede önemli ölçüde daha fazla hesaplama gerektirir.

• Simüle edilen nesnelerin aşırı sayısı veya karmaşıklığı - Simüle edilen 3D montajlarının sayısı arttıkça, fizik hesaplamaları her karede daha uzun sürer. Genellikle, oyunlar simüle edilmesi gerekmeyen nesneler içerir veya gereğinden fazla kısıtlama ve eklem içeren mekanizmalara sahip olur.

• Aşırı hassas çarpışma tespiti - Mesh parçaları, çarpışmayı tespit etmek için CollisionFidelity özelliğine sahiptir ve bu, farklı performans etkisi seviyelerine sahip çeşitli modlar sunar. Mesh parçaları için hassas çarpışma tespiti modu, en pahalı performans maliyetine sahiptir ve motorun hesaplaması daha uzun sürer.

Hafifletme

• Simülasyona ihtiyaç duymayan parçaları sabitleyin - Fizik tarafından yönlendirilmesi gerekmeyen tüm parçaları sabitleyin, örneğin statik NPC'ler için.

• Uyumlu fizik adımlama kullanın - Uyumlu adımlama, fizik mekanizmaları için fizik hesaplamalarının oranını dinamik olarak ayarlayarak, bazı durumlarda fizik güncellemelerinin daha az sıklıkta yapılmasına olanak tanır.

• Mekanizma karmaşıklığını azaltın

  • Mümkünse, bir montajdaki fizik kısıtlamalarının veya eklemlerinin sayısını en aza indirin.
  • Bir mekanizma içindeki kendi kendine çarpışmayı azaltın, örneğin, ragdoll uzuvlarının birbirleriyle çarpışmasını önlemek için sınırlamalar veya çarpışmasız kısıtlamalar uygulayarak.

• Meshler için hassas çarpışma sadakatinin kullanımını azaltın

  • Kullanıcıların fark etmeyeceği küçük veya etkileşimde bulunmayan nesneler için kutu sadakatini kullanın.

  • Küçük-orta boyutlu nesneler için, şekline bağlı olarak kutu veya kabuk sadakatlerini kullanın.

  • Büyük ve çok karmaşık nesneler için, mümkünse görünmez parçalar kullanarak özel çarpışmalar oluşturun.

  • Çarpışma gerektirmeyen nesneler için, çarpışmaları devre dışı bırakın ve kutu veya kabuk sadakati kullanın, çünkü çarpışma geometrisi hala bellekte saklanır.

  • Studio'da hata ayıklama amaçları için çarpışma geometrisini görüntülemek için 3D görünüm alanının sağ üst köşesindeki Görselleştirme Seçenekleri widget'ından Çarpışma sadakati'ni açabilirsiniz.

    Alternatif olarak, Keşfedicinin CollisionFidelity=PreciseConvexDecomposition filtresini uygulayarak, hassas sadakatle tüm mesh parçalarının sayısını gösterir ve bunları kolayca seçmenizi sağlar.

  • Hassasiyet ve performans gereksinimlerinizi dengeleyen bir çarpışma sadakati seçme konusunda derinlemesine bir rehber için Fizik ve render parametrelerini ayarlama sayfasına bakın.

MicroProfiler kapsamları

Fizik bellek kullanımı

Fizik hareketi ve çarpışma tespiti bellek tüketir. Mesh parçaları, çarpışma sınırlarını değerlendirmek için kullanılan CollisionFidelity özelliğine sahiptir.

Yaygın sorun

Varsayılan ve hassas çarpışma tespit modları, daha düşük sadakat çarpışma şekillerine sahip iki diğer moddan önemli ölçüde daha fazla bellek tüketir.

PhysicsParts altında yüksek bellek tüketimi seviyeleri görüyorsanız, oyununuzdaki nesnelerin çarpışma sadakatini azaltmayı düşünmeniz gerekebilir.

Nasıl hafifletilir

Çarpışma sadakati için kullanılan belleği azaltmak için:

• Çarpışmalara ihtiyaç duymayan parçalar için, BasePart.CanCollide, BasePart.CanTouch ve BasePart.CanQuery'yi false olarak ayarlayarak çarpışmalarını devre dışı bırakın.
• Çarpışmaların sadakatini CollisionFidelity ayarıyla azaltın. Box en düşük bellek yüküne sahiptir ve Default ve Precise genellikle daha pahalıdır.

  • Küçük sabit parçaların çarpışma sadakatini Box olarak ayarlamak genellikle güvenlidir.
  • Çok karmaşık büyük meshler için, kutu çarpışma sadakati ile daha küçük nesnelerden kendi çarpışma mesh'inizi oluşturmayı düşünebilirsiniz.

Humanoidler

Humanoid, oyuncu ve oyuncu olmayan karakterler (NPC'ler) için geniş bir işlevsellik yelpazesi sunan bir sınıftır. Güçlü olmasına rağmen, bir Humanoid önemli bir hesaplama maliyeti ile gelir.

Yaygın sorunlar

• NPC'lerde tüm HumanoidStateTypes'ı etkin bırakma - Belirli HumanoidStateTypes'ların etkin bırakılmasının bir performans maliyeti vardır. NPC'leriniz için gerekli olmayanları devre dışı bırakın. Örneğin, NPC'niz merdiven çıkmayacaksa, Climbing durumunu devre dışı bırakmak güvenlidir.
• Humanoids veya skinli MeshParts ile modelleri sık sık oluşturma, değiştirme ve yeniden canlandırma - Bu, motorun işlemesi için yoğun olabilir, özellikle bu modeller katmanlı giysiler kullanıyorsa. Bu, avatarların sık sık yeniden canlandığı oyunlarda özellikle sorunlu olabilir.

  • MicroProfiler'da uzun updateInvalidatedFastClusters etiketleri (4 ms'den fazla) genellikle avatar oluşturma/değiştirme işleminin aşırı geçersiz kılmalara neden olduğunu gösterir.
• Gerekmediği durumlarda Humanoid kullanma - Hareket etmeyen statik NPC'lerin genellikle Humanoid sınıfına ihtiyacı yoktur.
• Sunucudan büyük sayıda NPC'de animasyon oynatma - Sunucuda çalışan NPC animasyonları, sunucuda simüle edilmeli ve istemciye çoğaltılmalıdır. Bu gereksiz bir yük oluşturabilir.
• Gereksiz boyut ve ölçek değişiklikleri yapma - Boyut/ölçek değişiklikleri FastCluster'ın yeniden inşa edilmesine neden olur. Eğer FastCluster ile ilgili performans sorunları yaşıyorsanız, bunu oyun sırasında azaltmaya çalışın. Benzer şekilde, diğer özellik değişiklikleri de FastCluster'ın yeniden inşa edilmesine neden olabilir, bu nedenle genel olarak bu değişiklikleri mümkün olduğunca azaltın.

Hafifletme

• NPC animasyonlarını istemcide oynatın - Çok sayıda NPC bulunan oyunlarda, Animator'ı istemcide oluşturmayı ve animasyonları yerel olarak çalıştırmayı düşünün. Bu, sunucudaki yükü azaltır ve gereksiz çoğaltma ihtiyacını ortadan kaldırır. Ayrıca, NPC'ler karaktere yakın olduğunda yalnızca animasyonları oynatma gibi ek optimizasyonlar yapmayı mümkün kılar.
• Humanoidler için performans dostu alternatifler kullanın - NPC modellerinin mutlaka bir humanoid nesnesi içermesi gerekmez.

  • Statik NPC'ler için, hareket etmeleri gerekmeyen basit bir AnimationController kullanın, çünkü sadece animasyon oynamaları yeterlidir.
  • Hareket eden NPC'ler için, NPC'lerinizin karmaşıklığına bağlı olarak kendi hareket kontrol cihazınızı uygulamayı ve animasyonlar için bir AnimationController kullanmayı düşünün.
• Kullanılmayan humanoid durumlarını devre dışı bırakın - Her humanoid için yalnızca gerekli durumları etkinleştirmek için Humanoid:SetStateEnabled() kullanın.
• Sık yeniden canlanan NPC modellerini havuzlayın - Bir NPC'yi tamamen yok etmek yerine, onu etkin olmayan NPC'ler havuzuna gönderin. Bu şekilde, yeni bir NPC yeniden canlandırılması gerektiğinde, havuzdan bir NPC'yi yeniden etkinleştirebilirsiniz. Bu işlem havuzlama olarak adlandırılır ve karakterlerin yeniden oluşturulma sayısını en aza indirir.
• NPC'leri yalnızca kullanıcılar yakın olduğunda oluşturun - Kullanıcılar menzil dışındayken NPC'leri oluşturmayın ve kullanıcılar menzil dışına çıktığında onları kaldırın.
• Avatar hiyerarşisinde oluşturulduktan sonra değişiklik yapmaktan kaçının - Bir avatar hiyerarşisindeki belirli değişikliklerin önemli performans etkileri vardır. Bazı optimizasyonlar mevcuttur:

  • Özel prosedürel animasyonlar için, JointInstance.C0 ve JointInstance.C1 özelliklerini güncellemeyin. Bunun yerine, Motor6D.Transform özelliğini güncelleyin.
  • Herhangi bir BasePart nesnesini avatare eklemeniz gerekiyorsa, bunu avatar Model hiyerarşisinin dışında yapın.

MicroProfiler kapsamları

Renderleme

İstemcinin her karede harcadığı zamanın önemli bir kısmı, mevcut karede sahneyi renderlemeye harcanır. Sunucu herhangi bir renderleme yapmaz, bu nedenle bu bölüm yalnızca istemciye özeldir.

Çizim çağrıları

Bir çizim çağrısı, motorun GPU'ya bir şeyi renderlemesi için verdiği bir dizi talimattır. Çizim çağrılarının önemli bir yükü vardır. Genel olarak, her karede daha az çizim çağrısı varsa, bir kareyi renderlemek için harcanan hesaplama süresi de daha az olur.

Studio'da Render İstatistikleri ⟩ Zamanlama öğesi ile şu anda kaç çizim çağrısının gerçekleştiğini görebilirsiniz. İstemcide Render İstatistikleri'ni görüntülemek için ShiftF2 tuşlarına basabilirsiniz.

Belirli bir karede sahnenizde çizilmesi gereken daha fazla nesne varsa, GPU'ya daha fazla çizim çağrısı yapılır. Ancak, Roblox Motoru, aynı doku özelliklerine sahip özdeş meshleri tek bir çizim çağrısında birleştirmek için örnekleme adı verilen bir süreç kullanır. Özellikle, aynı MeshContent'e sahip birden fazla mesh, aşağıdaki durumlarda tek bir çizim çağrısında işlenir:

• SurfaceAppearances mevcutsa aynıysa, aksi takdirde TextureContents aynıysa.
• SurfaceAppearance ve MeshPart.TextureID mevcut olmadığında malzemeler aynıysa.

Diğer yaygın sorunlar

• Aşırı nesne yoğunluğu - Eğer çok sayıda nesne yüksek yoğunlukta toplanmışsa, bu durumda sahnenin bu alanını renderlemek daha fazla çizim çağrısı gerektirir. Haritanın belirli bir bölümüne baktığınızda kare hızınızın düştüğünü buluyorsanız, bu, bu alandaki nesne yoğunluğunun çok yüksek olduğuna dair iyi bir sinyal olabilir.

  Dekorlar, dokular ve parçacıklar gibi nesneler iyi bir şekilde gruplandırılmaz ve ek çizim çağrıları ekler. Bu nesne türlerine sahnede ekstra dikkat edin. Özellikle, ParticleEmitters üzerindeki özellik değişiklikleri performans üzerinde dramatik bir etki yapabilir.

• Kaçırılan örnekleme fırsatları - Genellikle, bir sahne, birden fazla kez çoğaltılan aynı mesh'i içerir, ancak her kopya farklı mesh veya doku varlık kimliklerine sahiptir. Bu, örneklemeyi engeller ve gereksiz çizim çağrılarına yol açabilir.

  Bu sorunun yaygın bir nedeni, tüm bir sahnenin bir seferde içe aktarılmasıdır, bunun yerine bireysel varlıkların Roblox'a içe aktarılması ve ardından sahneyi oluşturmak için içe aktarımdan sonra çoğaltılmasıdır.

  Aşağıdaki basit bir betik, aynı adı taşıyan ve farklı mesh kimlikleri kullanan mesh parçalarını tanımlamanıza yardımcı olabilir:

  for _,descendant in workspace:GetDescendants() do
    if descendant:IsA("MeshPart") then
      print(descendant.Name .. ", " .. descendant.MeshId)
    end
  end

  Çıktı ( Yığın Satırları etkinleştirildiğinde) aşağıdaki gibi görünebilir. Tekrarlanan satırlar, aynı mesh'in yeniden kullanımını gösterir, bu iyidir. Eşsiz satırlar mutlaka kötü değildir, ancak adlandırma şemanıza bağlı olarak, oyununuzda kopya mesh'lerin olduğunu gösterebilir:

  LargeRock, rbxassetid://106420009602747 (x144) -- iyi
  LargeRock, rbxassetid://120109824668127
  LargeRock, rbxassetid://134460273008628
  LargeRock, rbxassetid://139288987285823
  LargeRock, rbxassetid://71302144984955
  LargeRock, rbxassetid://90621205713698
  LargeRock, rbxassetid://113160939160788
  LargeRock, rbxassetid://135944592365226 -- tüm olası kopyalar

• Aşırı nesne karmaşıklığı - Çizim çağrılarının sayısından daha önemli olmasa da, bir sahnedeki üçgen sayısı, bir karenin renderlenme süresini etkiler. Çok sayıda çok karmaşık mesh içeren sahneler yaygın bir sorundur, ayrıca MeshPart.RenderFidelity özelliği çok fazla mesh üzerinde Precise olarak ayarlandığında da sorun olabilir.

• Aşırı gölge oluşturma - Gölge işleme pahalı bir süreçtir ve gölge oluşturan ışık nesnelerinin yüksek sayıda ve yoğunlukta olduğu haritalar (veya gölgelerden etkilenen küçük parçaların yüksek sayıda ve yoğunlukta olduğu haritalar) performans sorunları yaşayabilir.

• Yüksek saydamlık aşırı çizimi - Kısmi saydamlığa sahip nesneleri birbirine yakın yerleştirmek, motorun üst üste binen pikselleri birden fazla kez renderlemesine neden olur, bu da performansı olumsuz etkileyebilir. Bu sorunu tanımlama ve düzeltme hakkında daha fazla bilgi için Katmanlı saydamlıkları silin sayfasına bakın.

• Gereksiz skinli MeshPart hareketi - Bir Humanoid içermeyen bir Modelin parçası olan skinli MeshPart'lar, mekansal olarak organize edilmiş FastCluster'lar kullanılarak gruplandırılır. Bu MeshPart'lar hareket ettiğinde, sürekli olarak bu mekansal kümelere eklenmeleri ve çıkarılmaları gerekir, bu da kümelerin yeniden inşa edilmesine neden olur ve performansı etkiler.

  • Son derece etkili bir çözüm, Modelin içine bir Humanoid yerleştirmektir. Bir Humanoid'in varlığı, varsayılan mekansal kümeleme davranışını geçersiz kılarak, tüm Model için tek bir birleşik FastCluster kullanmayı zorunlu kılar. Sonuç olarak, konum güncellemeleri artık küme yeniden inşasını gerektirmediğinden, performans darboğazını hafifletir. Bu teknik, beklenen hareketi olan MeshPart'lar için özel olarak ayrılmalıdır, çünkü bellek yükü getirebilir ve mekansal optimizasyonun faydalarını ortadan kaldırabilir. Bu tür değişiklikler yaptıktan sonra oyununuzu her zaman profil çıkarmanızı öneririz. Daha fazla bilgi için Humanoid performans ipuçları sayfasına bakın.

• Model içinde çok fazla parça - Bir Modelde çok fazla parça, bir parçanın özelliğinin değişmesi durumunda tam bir yeniden inşa gerektirebileceğinden daha sık yeniden inşaya neden olabilir. FastCluster kullanırken bir Modelde parçaların doğru dengesini bulmak önemlidir.

Hafifletme

• Özdeş meshleri örnekleme ve benzersiz mesh sayısını azaltma - Tüm özdeş meshlerin aynı temel varlık kimliklerine sahip olmasını sağlarsanız, motor bunları tanıyabilir ve tek bir çizim çağrısında renderleyebilir. Her mesh'i bir haritada yalnızca bir kez yüklediğinizden ve ardından Studio'da yeniden kullanmak için çoğalttığınızdan emin olun, büyük haritaları bir bütün olarak içe aktarmak, özdeş meshlerin ayrı içerik kimliklerine sahip olmasına ve motor tarafından benzersiz varlıklar olarak tanınmasına neden olabilir. Paketler nesne yeniden kullanımında yardımcı bir mekanizmadır.
• Kaldırma - Kaldırma, son renderlenen karede yer almayan nesneler için çizim çağrılarını ortadan kaldırma sürecini tanımlar. Varsayılan olarak, motor, kameranın görüş alanının (frustum kaldırma) dışındaki nesneler için çizim çağrılarını atlar ve diğer nesneler tarafından görünümden engellenen parçalar, meshler ve arazi (engelleme kaldırma) için de aynı şekilde davranır. Belirli senaryolar, örneğin kapalı ortamlar gibi, bir oda veya portal sistemi uygulamanıza ve nesneleri manuel olarak kaldırmanıza olanak tanıyabilir, böylece çizim çağrılarını veya genel hesaplama yükünü daha da azaltabilirsiniz.
• Modeller için detay seviyesini azaltma - Örnek akışı etkinleştirin ve dünya modellerinizin LevelOfDetail özelliğini, kameradan uzaklaştıkça optimize edilmiş hafif SLIM mesh'leri renderlemek için SLIM olarak ayarlayın.
• Avatarlar için detay seviyesini azaltma - Örnek akışını etkinleştirin ve Workspace.EnableSLIMAvatars'ı, kameradan uzaklaştıkça platform avatarlarını optimize edilmiş hafif SLIM temsilleri olarak renderlemek için ayarlayın.
• Render sadakatini azaltma - MeshPart.RenderFidelity'yi Automatic veya Performance olarak ayarlayın. Bu, meshlerin daha az karmaşık alternatiflere geri dönmesine izin verir, bu da çizilmesi gereken poligon sayısını azaltabilir.
• Uygun parçalarda ve ışık nesnelerinde gölge oluşturmayı devre dışı bırakma - Roblox motoru, istemci grafik kalitesi seviyesi düştükçe gölge kalitesini otomatik olarak düşürür ve 4'ün altındaki kalite seviyelerinde gölgeleri tamamen devre dışı bırakır. Ancak, gölgeler etkinken performansı artırmak ve gölgelerin etkin kalma olasılığını artırmak için ışık nesneleri ve parçalardaki gölge oluşturma özelliklerini seçici olarak devre dışı bırakabilirsiniz. Edit zamanında veya çalışma zamanında yapabileceğiniz bazı optimizasyon örnekleri:

  • Küçük parçaların gölge oluşturmasını devre dışı bırakmak için BasePart.CastShadow özelliğini kullanın, bu gölgelerin görünmesi pek olası değildir. Bu strateji, kullanıcının kamerasından uzakta olan parçalara uygulandığında özellikle etkilidir.

    Bu, gölgelerde görsel bozulmalara neden olabilir.

  • Mümkünse hareket eden nesnelerde gölgeleri devre dışı bırakın.

  • Gölge oluşturmaya ihtiyaç duymayan ışık örneklerinde Light.Shadows'ı devre dışı bırakın.

  • Işık örneklerinin aralığını ve açısını sınırlayın.

  • Daha az ışık örneği kullanın.

  • Kapalı ortamlar için belirli bir aralığın dışındaki ışıkları devre dışı bırakmayı veya oda bazında düşünmeyi değerlendirin.

MicroProfiler kapsamları

Ağ ve çoğaltma

Ağ ve çoğaltma, verilerin sunucu ile bağlı istemciler arasında nasıl gönderildiğini tanımlar. Her karede istemci ile sunucu arasında bilgi gönderilir, ancak daha büyük miktarda bilgi daha fazla hesaplama süresi gerektirir.

Yaygın sorunlar

• Aşırı uzaktan trafik - RemoteEvent veya RemoteFunction nesneleri aracılığıyla büyük miktarda veri göndermek veya bunları çok sık çağırmak, her karede gelen paketleri işlemek için büyük miktarda CPU süresi harcanmasına neden olabilir. Yaygın hatalar şunlardır:

  • Çoğaltılması gerekmeyen verileri her karede çoğaltmak.
  • Kullanıcı girişi üzerine verileri çoğaltmak, herhangi bir sınırlama mekanizması olmadan.
  • Gereğinden fazla veri göndermek. Örneğin, bir oyuncu bir öğe satın aldığında, satın alınan öğenin ayrıntılarını göndermek yerine oyuncunun tüm envanterini göndermek.

• Karmaşık örnek ağaçlarının oluşturulması veya kaldırılması - Sunucuda veri modelinde bir değişiklik yapıldığında, bu bağlı istemcilere çoğaltılır. Bu, çalışma zamanında haritalar gibi büyük örnek hiyerarşilerini oluşturmanın ve yok etmenin çok ağ yoğun olabileceği anlamına gelir.

  Buradaki yaygın bir suçlu, Animasyon Editörü eklentileri tarafından riglerde kaydedilen karmaşık animasyon verileridir. Bunlar, oyun yayımlanmadan önce kaldırılmazsa ve animasyonlu model düzenli olarak kopyalanırsa, gereksiz yere büyük miktarda veri çoğaltılacaktır.

• Sunucu tarafı TweenService - TweenService bir nesneyi sunucu tarafında tweenlemek için kullanılıyorsa, tweenlenen özellik her karede her istemciye çoğaltılır. Bu, istemcilerin gecikmesi dalgalandıkça tweenin titrek olmasına neden olur ve gereksiz ağ trafiği oluşturur.

Hafifletme

Gereksiz çoğaltmayı azaltmak için aşağıdaki taktikleri uygulayabilirsiniz:

• Uzaktan olaylar aracılığıyla büyük miktarda veri göndermekten kaçının. Bunun yerine, yalnızca gerekli verileri daha düşük bir sıklıkta gönderin. Örneğin, bir karakterin durumunu, her karede değil, değiştiğinde çoğaltın.
• Karmaşık örnek ağaçlarını (haritalar gibi) parçalara ayırın ve bunları parça parça yükleyin, böylece bu işin çoğaltılmasını birden fazla kareye dağıtabilirsiniz.
• Animasyon meta verilerini temizleyin, özellikle riglerin animasyon dizinini, içe aktardıktan sonra.
• Gereksiz örnek çoğaltmasını sınırlayın, özellikle sunucunun oluşturulan örnekler hakkında bilgiye ihtiyaç duymadığı durumlarda. Bu, şunları içerir:

  • Bir patlama veya sihirli bir büyü patlaması gibi görsel efektler. Sunucunun yalnızca sonucu belirlemek için konumu bilmesi gerekirken, istemciler görselleri yerel olarak oluşturabilir.
  • Birinci şahıs öğe görünüm modelleri.
  • Nesneleri istemcide tweenlemek yerine sunucuda tweenlemek.

MicroProfiler kapsamları

Varlık bellek kullanımı

Yaratıcıların istemci bellek kullanımını artırmak için en yüksek etkiye sahip mekanizma, örnek akışını etkinleştirmektir.

Örnek akışı

Örnek akışı, gerekli olmayan veri modelinin parçalarını seçici olarak yükler, bu da yükleme sürelerini önemli ölçüde azaltabilir ve istemcinin bellek baskısı altında çökmesini önleme yeteneğini artırabilir.

Bellek sorunları yaşıyorsanız ve örnek akışı devre dışıysa, oyununuzu destekleyecek şekilde güncellemeyi düşünün, özellikle 3D dünyanız büyükse. Örnek akışı, 3D uzaydaki mesafeye dayalıdır, bu nedenle daha büyük dünyalar doğal olarak bundan daha fazla fayda sağlar.

Örnek akışı etkinse, agresifliğini artırabilirsiniz. Örneğin, şunları düşünün:

• Mümkünse Enum.ModelStreamingMode.Persistent kullanımını azaltın. Bunu bir uyumluluk önlemi olarak kullanıyorsanız, betiklerinizi güncellemeniz gerekebilir.
• Workspace.StreamingMinRadius ve Workspace.StreamingTargetRadius'ı azaltın.

Akış seçenekleri ve bunların faydaları hakkında daha fazla bilgi için akış özellikleri sayfasına bakın.

Diğer yaygın sorunlar

• Varlık çoğaltma - Yaygın bir hata, aynı varlığı birden fazla kez yüklemek ve farklı varlık kimlikleri elde etmektir. Bu, aynı içeriğin belleğe birden fazla kez yüklenmesine neden olabilir.

• Aşırı varlık hacmi - Varlıklar aynı olmasa bile, aynı varlığı yeniden kullanma ve bellek tasarrufu fırsatlarının kaçırıldığı durumlar vardır.

• Ses dosyaları - Ses dosyaları, tümünü istemciye bir kerede yüklemek yerine yalnızca oyunun bir kısmı için gerekenleri yüklediğinizde bellek kullanımına beklenmedik bir katkıda bulunabilir. Stratejiler için Yükleme süreleri sayfasına bakın.

• Yüksek çözünürlüklü dokular - Bir dokunun grafik bellek tüketimi, diskteki boyutuyla ilgili değildir; dokudaki piksel sayısı bellek kullanımını belirler. Örneğin, 1024x1024 piksel dokusu, 512x512 dokunun grafik belleğinin dört katını tüketir.

  Roblox'a yüklenen görüntüler, sabit bir formata dönüştürülür, bu nedenle daha az bayt içeren bir renk modelinde görüntü yüklemenin bellek avantajı yoktur. Benzer şekilde, yüklemeden önce görüntüleri sıkıştırmak veya ihtiyaç duymayan görüntülerden alfa kanalını kaldırmak, diskteki görüntü boyutunu azaltabilir, ancak bellek kullanımını artırmaz.

  Bir oyun yüklendiğinde, motor otomatik olarak daha düşük kaliteli dokularla başlar ve ardından mevcut cihaz belleğine, kameradan uzaklığa, dokunun kapladığı ekran alanına ve diğer faktörlere bağlı olarak kaliteyi artırır. Yine de, dokularınızı stratejik olarak boyutlandırmak, oyununuzdaki bellek kullanımını artırabilir.

Hafifletme

• Varlıkları yalnızca bir kez yükleyin - Nesneler arasında aynı varlık kimliğini yeniden kullanın ve aynı varlıkların, özellikle meshlerin ve görüntülerin, birden fazla kez ayrı ayrı yüklenmediğinden emin olun.

• Çoğaltılmış varlıkları bulun ve düzeltin - Farklı kimliklerle birden fazla kez yüklenen özdeş mesh parçaları ve dokular arayın.

  • Varlıkların benzerliğini otomatik olarak tespit etmek için bir API olmasa da, yerinizdeki tüm görüntü varlık kimliklerini (ya manuel olarak ya da bir betik ile) toplayabilir, bunları indirebilir ve dışarıdan karşılaştırma araçları kullanarak karşılaştırabilirsiniz.
  • Mesh parçaları için en iyi strateji, benzersiz mesh kimliklerini alıp boyutlarına göre düzenlemektir, böylece kopyaları manuel olarak tanımlayabilirsiniz.
  • Farklı renkler için ayrı dokular kullanmak yerine, tek bir doku yükleyin ve SurfaceAppearance.Color özelliğini kullanarak çeşitli tonlar uygulayın.

• Haritaları ayrı varlıklar olarak içe aktarın - Tüm bir haritayı bir seferde içe aktarmak yerine, haritadaki varlıkları ayrı ayrı içe aktarın ve yeniden inşa edin. İçe aktarıcı, meshlerin herhangi bir yeniden çoğaltmasını yapmaz, bu nedenle çok sayıda ayrı zemin karosuna sahip büyük bir harita içe aktarırsanız, her bir karo ayrı bir varlık olarak içe aktarılır (kopyalar olsa bile). Bu, her bir mesh'in ayrı olarak ele alınmasına ve bellek ve çizim çağrıları almasına neden olabilir.

• Görüntülerin piksellerini gerekli miktardan fazlasına sınırlayın. Bir görüntü ekranın büyük bir fiziksel alanını kaplamıyorsa, genellikle en fazla 512x512 piksel gereklidir. Çoğu küçük görüntü 256x256 pikselden daha küçük olmalıdır.

• Trim sheet'leri kullanarak 3D haritalarda maksimum doku yeniden kullanımını sağlayın. Trim sheet'leri oluşturma adımları ve örnekleri için Trim sheet'leri oluşturun sayfasına bakın.

  Ayrıca, birçok daha küçük UI görüntüsünü tek bir görüntü olarak yüklemek için sprite sheet'leri kullanmayı düşünebilirsiniz. Ardından, ImageLabel.ImageRectOffset ve ImageLabel.ImageRectSize'yi kullanarak sheet'in bölümlerini görüntüleyebilirsiniz.

Yükleme süreleri

Bir oyuncu oynamaya başlamadan önce, istemcinin ReplicatedFirst ve ReplicatedStorage'daki her şeyi, Workspace'ın başlangıç içeriklerini ve betiklerinizin önceden yüklediği varlıkları alması gerekir. İstemcinin bu süre zarfında indirmesi ve işlemesi gereken daha fazla içerik varsa, oyuncuların bekleme süresi daha uzun olur. Katılma sürecindeki her adımın ayrıntılı bir dökümü için Performans sorunlarını tanımlayın sayfasına bakın.

Yaygın sorunlar

• Örnek akışı devre dışı - Örnek akışı olmadan, tüm Workspace oyuncu girmeden önce istemciye çoğaltılmalıdır, bu nedenle birçok parça, model ve varlık içeren oyunların yükleme süreleri orantılı olarak daha uzun olur.

• ReplicatedStorage'da aşırı içerik - ReplicatedStorage'daki her şey, oyuncu bir şey görmeden veya etkileşime girmeden önce her istemciye çoğaltılır, istemcinin hemen ihtiyaç duyup duymadığına bakılmaksızın. Ücretsiz modeller ve miras alınan varlıklar, sessizce önemli bir yük ekleyebilir.

• Ağır ReplicatedFirst içeriği - ReplicatedFirst, her şeyden önce çoğaltılır ve esasen özel bir yükleme ekranı tutmak için vardır. İçinde her ek varlık veya betik, ana çoğaltma aşamasının başlamasını geciktirir.

• PreloadAsync()'ı aşırı kullanma - Birçok oyun özel yükleme ekranları uygular ve ContentProvider:PreloadAsync()'ı, görüntülerin, seslerin ve meshlerin arka planda indirilmesi için varlıkları talep etmek amacıyla kullanır. Bu yaklaşım, oyununuzun önemli bölümlerinin tamamen yüklenmesini sağlar, ancak yaygın bir hata, gerçekten gerekli olandan daha fazla varlık önceden yüklemektir.

  Kötü bir uygulama örneği, tüm Workspace'ı yüklemektir. Bu, doku pop-in'ini önleyebilir, ancak yükleme sürelerini önemli ölçüde artırır.

  Benzer bir uygulama, tüm talep edilen varlıkların yüklenmeyi tamamladığından emin olmak için ContentProvider.RequestQueueSize'ı kullanmaktır. Ancak, bu, önemli ölçüde artan yükleme süreleri ile aynı sorunu ortaya çıkarır ve dalgalanan doğası nedeniyle güvenilir bir yöntem değildir.

• Pahalı başlangıç betikleri - Katılma sürecinde çalışan LocalScripts içindeki ağır betik yürütmeleri, büyük veri yapılarını senkronize bir şekilde yüklemek gibi, çoğaltmadan oynanabilir bir duruma geçişi geciktirir.

Hafifletme

• Örnek akışını etkinleştirin - Akış, oyuncunun başlangıç noktasına yakın olan dünya bölümünü yalnızca başlangıçta gönderir, ardından oyuncu oyununuzda hareket ettikçe geri kalanını kademeli olarak akıtır. Zaten kullanmayan oyunlar için akış, yükleme sürelerini azaltmanın en etkili yollarından biridir. Yeni yerler için akış varsayılan olarak etkinleştirilmiştir. Kurulum adımları, özellik referansı ve geçiş rehberi için Örnek akışı sayfasına bakın.

  Akışın etkinleştirilmesi, oyununuzun istemcilere veri çoğaltma şeklini değiştirir. Bunu etkinleştirdikten sonra, bir oyuncu katıldığında Workspace içeriğine erişen herhangi bir betiği dikkatlice test edin, çünkü bu örnekler istemcide henüz mevcut olmayabilir.

• ReplicatedStorage'ı sade tutun - İstemcilerin katıldıkları anda ihtiyaç duydukları şeyleri saklayın, örneğin LocalScripts'in ihtiyaç duyduğu paylaşılan ModuleScripts. Hemen ihtiyaç duyulmayan büyük modelleri, sesleri ve diğer varlıkları ServerStorage'a taşıyın ve yalnızca bir oyuncu bunlara ihtiyaç duyduğunda istemciye taşıyın. ReplicatedStorage'ı düzenli olarak kullanmadığınız içerikler için denetleyin.

• ReplicatedFirst'ı sade tutun - ReplicatedFirst'ı, yükleme ekranınızın ihtiyaç duyduğu şeylerle sınırlayın, örneğin büyük dokular veya 3D modeller yerine temel UI öğeleri ve betiklerin çalıştığı zaman ağır hesaplamalardan kaçının. Özel bir yükleme ekranı oluşturma süreci için, ReplicatedFirst:RemoveDefaultLoadingScreen()'i ne zaman çağıracağınızı da içeren Yükleme ekranları sayfasına bakın.

• Yalnızca gerekli varlıkları önceden yükleyin - ContentProvider:PreloadAsync()'ı yalnızca gerekli durumlarda kullanın, bunlar şunları içerir:

  • Yükleme ekranındaki görüntüler.
  • Oyun menünüzdeki önemli görüntüler, örneğin düğme arka planları ve simgeleri.
  • Başlangıç veya doğma alanındaki önemli varlıklar.

  Eğer çok sayıda varlık yüklemeniz gerekiyorsa, bir Yüklemeyi Atla düğmesi sağlamanızı öneririz.

• Önemsiz başlangıç işlerini erteleyin - Bir oyuncunun henüz ulaşmadığı içeriği, örneğin henüz açmadıkları UI panellerini yalnızca ilk ihtiyaç duyulduğunda yükleyin. Erken gerçekleşmesi gereken başlatma işlerini, hepsini bir seferde çalıştırmak yerine birden fazla kareye yayarak dağıtın. Teknikler için Script hesaplaması sayfasına bakın.