Unity Geliştiricilerinin Yaptığı En Yaygın 10 Hata

Unity, çok platformlu geliştirme için kullanmak için harika ve basit bir araçtır. İlkelerini anlamak kolaydır ve sezgisel olarak ürünlerinizi oluşturmaya başlayabilirsiniz. Bununla birlikte, bazı şeyler göz önünde bulundurulmazsa, ilk prototip aşamasından geçerken veya son sürüme yaklaşırken, işinizde bir sonraki seviyeye ilerlediğinizde ilerlemenizi yavaşlatırlar. Bu makale, en yaygın sorunların nasıl üstesinden gelineceği ve yeni veya mevcut projelerinizde temel hatalardan nasıl kaçınılacağı konusunda tavsiyeler sağlayacaktır. Lütfen bu makalenin bakış açısının daha çok 3B uygulama geliştirmeye odaklandığını, ancak bahsedilen her şeyin 2B geliştirme için de geçerli olduğunu unutmayın.

Ortak Birlik Hatası #1: Proje Planlama Aşamasını Küçümseme

Her proje için, projenin uygulama tasarımı ve programlama kısmı başlamadan önce birkaç şeyi belirlemek çok önemlidir. Ürün pazarlamanın tüm sürecin önemli bir parçası olduğu bu günlerde, uygulanan uygulamanın iş modelinin ne olacağına dair net bir fikre sahip olmak da önemlidir. Hangi platformlar için ürün yayınlayacağınızdan ve planınızda hangi platformların bulunduğundan emin olmalısınız. Hangi performans ve görselleri karşılayabileceğiniz konusunda fikir sahibi olmak için minimum desteklenen cihaz özelliklerini (eski düşük kaliteli cihazları mı yoksa sadece daha yeni modelleri mi destekleyeceksiniz?) ayarlamak da gereklidir. Bu makaledeki her konu bu gerçeğin etkisindedir.

Daha teknik bir bakış açısından, varlıkları ve modelleri yaratırken tüm iş akışını programcıya sunarken, modellerin biraz daha değişiklik ve iyileştirmeye ihtiyaç duyacağı yineleme sürecine özellikle dikkat ederek önceden ayarlamak gerekli olmalıdır. İstenen kare hızı ve tepe noktası bütçesi hakkında net bir fikre sahip olmalısınız, böylece 3D sanatçısı modellerin hangi maksimum çözünürlükte olması gerektiğini ve kaç LOD varyasyonu yapması gerektiğini bilebilir. Tutarlı bir ölçeğe sahip olmak için tüm ölçümlerin nasıl birleştirileceği ve tüm uygulama boyunca içe aktarma işlemi de belirtilmelidir.

Seviyelerin nasıl tasarlanacağı, gelecekteki çalışmalar için çok önemlidir çünkü seviyelerin bölünmesi performansı çok etkiler. Yeni seviyeler tasarlarken performans endişeleri her zaman aklınızda olmalıdır. Gerçekçi olmayan vizyonlarla gitmeyin. Kendinize “makul bir şekilde başarılabilir mi?” Sorusunu sormak her zaman önemlidir. Aksi takdirde, elde edilmesi zor olan bir şey için değerli kaynaklarınızı boşa harcamamalısınız (tabii ki bunu ana rekabet avantajınız olarak görmek iş stratejinizin bir parçası değilse).

Yaygın Birlik Hatası #2: Optimize Edilmemiş Modellerle Çalışmak

Daha fazla değişiklik yapmadan sahnelerinizde kullanabilmek için tüm modellerinizin iyi hazırlanmış olması çok önemlidir. İyi modelin yerine getirmesi gereken birkaç şey var.

Teraziyi doğru ayarlamak önemlidir. Bazen, bu uygulamaların kullandığı farklı birimler nedeniyle, 3B modelleme yazılımınızdan bunu doğru şekilde ayarlamak mümkün olmayabilir. Her şeyi doğru yapmak için, model içe aktarma ayarlarında ölçek faktörünü ayarlayın (3dsMax ve Modo için 0.01 bırakın, Maya için 1.0 olarak ayarlayın) ve bazen ölçek ayarını değiştirdikten sonra nesneleri yeniden içe aktarmanız gerekeceğini unutmayın. Bu ayarlar, tutarlı davranış ve hiçbir fizik problemi elde etmek için sahnelerinizde yalnızca 1,1,1 temel ölçeğini kullanabilmenizi sağlamalıdır. Dinamik gruplama da daha doğru bir şekilde çalışacaktır. Bu kural, sadece ana nesneye değil, modeldeki her alt nesneye de uygulanmalıdır. Nesne boyutlarında ince ayar yapmanız gerektiğinde, bunu Unity yerine 3B modelleme uygulamasındaki diğer nesnelerle ilgili olarak yapın. Bununla birlikte, uygun değerleri bulmak için Unity'de ölçekle denemeler yapabilirsiniz, ancak son uygulama ve tutarlı iş akışı için Unity'ye aktarmadan önce her şeyin iyi hazırlanmış olması iyidir.

Nesnenin işlevselliği ve dinamik parçaları ile ilgili olarak - modellerinizi iyi bir şekilde bölün. Ne kadar az alt nesne olursa o kadar iyidir. Örneğin, animasyon amacıyla veya diğer etkileşimler için dinamik olarak hareket etmek veya döndürmek için ihtiyaç duymanız durumunda nesnenin ayrı parçalarını ayırın. Her nesne ve alt nesnelerinin ekseni, ana işlevine göre uygun şekilde hizalanmalı ve döndürülmelidir. Ana nesnenin Z ekseni ileriye dönük olmalı ve sahneye daha iyi yerleştirme için pivot nesnenin altında olmalıdır. Nesneler üzerinde mümkün olduğunca az malzeme kullanın (daha fazlası aşağıda).

Tüm varlıklar, türünü ve işlevselliğini kolayca tanımlayacak uygun adlara sahip olmalıdır. Tüm projelerinizde bu tutarlılığı koruyun.

Ortak Birlik Hatası #3: Birbirine Bağlı Kod Mimarisi Oluşturma

Unity'de işlevselliğin prototiplenmesi ve uygulanması oldukça kolaydır. Diğer nesnelere herhangi bir referansı kolayca sürükleyip bırakabilir, sahnedeki her bir nesneyi adresleyebilir ve sahip olduğu her bileşene erişebilirsiniz. Ancak bu aynı zamanda potansiyel olarak tehlikeli olabilir. Göze çarpan performans sorunlarının yanı sıra (hiyerarşide bir nesne bulma ve bileşenlere erişimin ek yükü vardır), kodunuzun parçalarını tamamen birbirine bağımlı hale getirmenin de büyük bir tehlikesi vardır. Veya uygulamanıza özgü diğer sistemlere ve komut dosyalarına, hatta mevcut sahneye veya mevcut senaryoya bağımlı olmak. Daha modüler bir yaklaşım benimsemeye ve uygulamanızın diğer bölümlerinde kullanılabilecek, hatta tüm uygulama portföyünüzde paylaşılabilecek yeniden kullanılabilir parçalar oluşturmaya çalışın. Çerçevenizi ve kitaplıklarınızı, tıpkı bilgi tabanınızı oluştururken yaptığınız gibi Unity API'si üzerinde oluşturun.

Bunu sağlamak için birçok farklı yaklaşım var. Unity bileşen sisteminin kendisi iyi bir başlangıç ​​noktasıdır. Belirli bileşenlerin uygulamanın diğer sistemleriyle iletişim kurması gerektiğinde komplikasyonlar ortaya çıkabilir. Bunun için sisteminizin parçalarını daha soyut ve tekrar kullanılabilir hale getirmek için arayüzleri kullanabilirsiniz. Alternatif olarak, bir mesajlaşma sistemi oluşturarak veya doğrudan diğer sistemin parçalarına dinleyici olarak kaydolarak, kapsam dışından belirli olaylara tepki vermek için olay odaklı bir yaklaşım kullanabilirsiniz. Doğru yaklaşım, gameObject özelliklerini program mantığından (en azından model-denetleyici ilkesi gibi bir şey) ayırmaya çalışmak olacaktır, çünkü hangi nesnelerin konum ve döndürme gibi dönüşüm özelliklerini değiştirdiğini belirlemek zordur. Yalnızca kontrolörünün sorumluluğunda olmalıdır.

Her şeyi iyi belgelenmiş hale getirmeye çalışın. Her zaman, uzun bir süre sonra kodunuza geri dönmeniz gerektiği gibi davranın ve kodun bu bölümünün tam olarak ne yaptığını hızlı bir şekilde anlamanız gerekir. Çünkü gerçekte, bir süre sonra uygulamanızın bazı bölümlerine oldukça sık ulaşırsınız ve bu, soruna hızlı bir şekilde atlamak için gereksiz bir engeldir. Ama bunu aşırıya kaçmayın. Bazen uygun bir sınıf, yöntem veya özellik adı oldukça yeterlidir.

Ortak Birlik Hatası #4: Performansınızı Boşa Harcamak

Cep telefonlarından, konsollardan veya masaüstü bilgisayarlardan oluşan en son ürün grubu, hiçbir zaman performansı önemsemeye gerek kalmayacak kadar gelişmiş olmayacak. Performans optimizasyonlarına her zaman ihtiyaç duyulur ve bunlar, oyununuzun veya uygulamanızın piyasadaki diğerlerine kıyasla nasıl göründüğü konusunda fark yaratmanız için temel sağlar. Çünkü bir bölümdeki performansın bir kısmını kaydettiğinizde, bunu uygulamanızın diğer bölümlerini cilalamak için kullanabilirsiniz.

Optimizasyon için birçok alan var. Tüm makale, bu konuyla ilgili yüzeyi çizmek için gerekli olacaktır. En azından bu alanı bazı temel alanlara bölmeye çalışacağım.

Döngüleri Güncelle

Güncelleme döngülerinde performans açısından yoğun şeyler kullanmayın, bunun yerine önbelleğe almayı kullanın. Tipik bir örnek, bir sahnedeki bileşenlere veya diğer nesnelere erişim veya komut dosyalarınızdaki yoğun hesaplamalardır. Mümkünse, her şeyi Awake() yöntemlerinde önbelleğe alın veya mimarinizi, tam ihtiyaç duyuldukları anda tetiklemek için daha olay odaklı bir yaklaşımla değiştirin.

Örneklemeler

Oldukça sık somutlaştırılan nesneler için (örneğin, bir FPS oyunundaki madde işaretleri), bunların önceden başlatılmış bir havuzunu yapın ve ihtiyacınız olduğunda halihazırda başlatılmış bir tanesini seçin ve etkinleştirin. Daha sonra artık gerekmediğinde yok etmek yerine devre dışı bırakıp havuza geri koyun.

işleme

Sahnenin işlenmiş kısımlarını sınırlamak için kapama ayırma veya LOD tekniklerini kullanın. Sahnede köşe sayısını kontrol altında tutabilmek için optimize edilmiş modeller kullanmaya çalışın. Dikkat edin, köşe sayısı sadece modelin kendi üzerindeki köşe sayısı değildir, normaller (sert kenarlar), UV koordinatları (UV dikişleri) ve köşe renkleri gibi diğer şeylerden etkilenir. Ayrıca, sahnedeki bir dizi dinamik ışık, genel performansı önemli ölçüde etkileyecektir, bu nedenle mümkün olduğunda her şeyi önceden pişirmeye çalışın.

Çağrıları Çiz

Beraberlik çağrıları sayısını azaltmaya çalışın. Unity'de, hareketsiz nesneler için statik gruplama ve hareketli nesneler için dinamik gruplama kullanarak beraberlik çağrılarını azaltabilirsiniz. Ancak, önce sahnelerinizi ve modellerinizi hazırlamanız gerekir (toplu nesnelerin aynı malzemeleri paylaşması gerekir) ve dinamik nesnelerin toplulaştırılması yalnızca düşük çözünürlüklü modeller için çalışır. Alternatif olarak, toplu işlem kullanmak yerine komut dosyasındaki ağları tek bir dosyada ( Mesh.CombineMeshes ) birleştirebilirsiniz, ancak bazı platformlarda görüntü kesintisinden yararlanamayan çok büyük nesneler oluşturmamaya dikkat etmelisiniz. Genel olarak, anahtar mümkün olduğunca az malzeme kullanmak ve bunları sahnede paylaşmaktır. Tek bir malzemeyi farklı nesneler arasında paylaşabilmek için bazen dokulardan atlaslar oluşturmanız gerekecektir. İyi bir ipucu, daha büyük ortamlarda ışık pişirirken sayılarını azaltmak için daha yüksek çözünürlüklü sahne ışık haritaları dokuları (oluşturulan çözünürlük değil, doku çıktı çözünürlüğü) kullanmaktır.

Aşırı Çekme Sorunları

Doldurma hızı sorunlarına neden olacağından, gerekli olmadığında şeffaf dokular kullanmayın. Ağaçlar veya çalılar gibi karmaşık ve daha uzak geometriler için kullanmakta bir sakınca yoktur. Kullanmanız gerektiğinde, alfa testli shader'lar veya mobil platformlar için cutout shader'lar yerine alfa harmanlanmış shader'ları tercih edin. Bu sorunları genel olarak belirlemek için uygulamanızın çözünürlüğünü düşürmeyi deneyin. Yardımcı olacaksa, bu doluluk oranı sorunlarınız olabilir veya gölgelendiricilerinizi daha fazla optimize etmeniz gerekebilir. Aksi takdirde, daha fazla bellek sorunu olabilir.

gölgelendiriciler

Daha iyi performans için gölgelendiricilerinizi optimize edin. Geçiş sayısını azaltın, değişkenleri daha düşük hassasiyetle kullanın, karmaşık matematik hesaplamalarını önceden oluşturulmuş arama dokularıyla değiştirin.

Darboğazları belirlemek için her zaman bir profil oluşturucu kullanın. Bu harika bir araçtır. Oluşturma için, oluşturma işlemlerini onunla ayrıştırırken genel olarak işlerin nasıl yürüdüğü hakkında çok şey öğrenmenize yardımcı olacak harika Çerçeve Hata Ayıklayıcı'yı da kullanabilirsiniz.

Ortak Birlik Hatası #5: Çöp Toplama sorunlarını görmezden gelme

Garbage Collector'ın (GC) kendisinin gerçekten verimli olmamıza ve programlamada önemli şeylere odaklanmamıza yardımcı olmasına rağmen, açıkça farkında olmamız gereken birkaç şey olduğunu anlamak gerekir. GC kullanımı ücretsiz değildir. Genel olarak, GC'nin kendisini çok sık tetiklemesini ve dolayısıyla kare hızı artışlarıyla performansı bozmasını önlemek için gereksiz bellek tahsislerinden kaçınmalıyız. İdeal olarak, her karede düzenli olarak gerçekleşen yeni bellek tahsisleri olmamalıdır. Ancak, bu hedefe nasıl ulaşabiliriz? Gerçekten uygulama mimarisi tarafından belirlenir, ancak izleyebileceğiniz ve yardımcı olacak bazı kurallar vardır:

• Güncelleme döngülerinde gereksiz ayırmalardan kaçının.
• Yığın üzerinde ayrılmadıklarından, basit özellik kapsayıcıları için yapıları kullanın.
• Güncelleme döngüleri içinde oluşturmak yerine dizileri, listeleri veya diğer nesne koleksiyonlarını önceden tahsis etmeye çalışın.
• Unity, Mono'nun daha eski, ideal olarak optimize edilmemiş bir sürümünü kullandığından (örneğin, LINQ ifadeleri veya foreach döngüleri gibi) mono sorunlu şeyler kullanmaktan kaçının (yazma sırasında, yol haritasında yükseltme ile değiştirilmiş sürüm 2.6'dır).
• Awake() yöntemlerinde veya olaylarda dizeleri önbelleğe alın.
• Güncelleme döngüsünde string özelliğinin güncellenmesi gerekiyorsa, string yerine StringBuilder nesnesini kullanın.
• Olası sorunları belirlemek için profil oluşturucuyu kullanın.

Ortak Birlik Hatası #6: Son Bellek ve Alan Kullanımını Optimize Etme

Yayın öncesi aşaması için optimizasyondan çıktığınızda yapmak daha karmaşık olduğundan, projenin başlangıcından itibaren uygulamanın en düşük bellek ve alan kullanımına dikkat etmek gerekir. Mobil cihazlarda bu daha da önemli çünkü oradaki kaynaklar oldukça kısıtlı. Ayrıca kurulumun 100MB boyutunu aşarak önemli miktarda müşterimizi kaybedebiliriz. Bunun nedeni, hücresel ağ indirmeleri için 100MB sınırı ve ayrıca psikolojik sebeplerdir. Uygulamanız müşterinin değerli telefon kaynaklarını boşa harcamadığında her zaman daha iyidir ve uygulamanızın boyutu küçüldüğünde uygulamanızı indirme veya satın alma olasılıkları daha yüksektir.

Kaynak gidericileri bulmak için, ses, dokular ve DLL'ler gibi ayrı kategorilere ayrılmış kaynakların boyutunu (her yeni derlemeden sonra) görebileceğiniz düzenleyici günlüğünü kullanabilirsiniz. Daha iyi yönlendirme için Unity Asset Store'da, dosya sisteminizdeki başvurulan kaynaklar ve dosyalar ile size ayrıntılı bir özet sağlayacak düzenleyici uzantıları vardır. Gerçek bellek tüketimi profil oluşturucuda da görülebilir, ancak bir düzenleyicide veya hedef platformunuz dışında herhangi bir şeyde test ederken çok fazla tutarsızlık olduğundan, hedef platformunuzda derlemek için bağlandığında test etmeniz önerilir.

En büyük bellek tüketicileri genellikle dokulardır. Tercihen, çok daha az yer ve bellek kapladığından sıkıştırılmış dokuları kullanın. Tüm dokuları kare yapın, ideal olarak her iki tarafın uzunluğunu ikinin kuvveti yapın (POT), ancak Unity'nin NPOT dokularını otomatik olarak POT'a ölçekleyebileceğini unutmayın. POT formundayken dokular sıkıştırılabilir. Atlas dokuları, tüm dokuyu doldurmak için bir araya getirir. Bazen gölgelendiricileriniz için ek alan ve performans tasarrufu sağlamak amacıyla bazı ek bilgiler için doku alfa kanalını bile kullanabilirsiniz. Ve elbette, sahneleriniz için dokuları mümkün olduğunca yeniden kullanmaya çalışın ve iyi bir görsel görünümü korumak mümkün olduğunda tekrar eden dokular kullanın. Düşük kaliteli cihazlar için, Kalite Ayarlarında dokuların çözünürlüğünü düşürebilirsiniz. Arka plan müziği gibi daha uzun ses klipleri için sıkıştırılmış ses biçimini kullanın.

Farklı platformlar, çözünürlükler veya yerelleştirmelerle uğraşırken, farklı cihazlar veya kullanıcılar için farklı doku kümeleri kullanmak için varlık paketlerini kullanabilirsiniz. Bu varlık paketleri, uygulama yüklendikten sonra internetten dinamik olarak yüklenebilir. Bu sayede oyun sırasında kaynak indirerek 100MB sınırını aşabilirsiniz.

Ortak Birlik Hatası #7: Yaygın Fizik Hataları

Bazen, sahnedeki nesneleri hareket ettirirken, nesnenin üzerinde bir çarpıştırıcı olduğunu ve konumunu değiştirmenin motoru tüm fiziksel dünyayı yeniden hesaplamaya zorladığını fark etmeyiz. Bu durumda, buna Rigidbody bileşeni eklemelisiniz (dış kuvvetlerin dahil olmasını istemiyorsanız kinematik olmayan olarak ayarlayabilirsiniz).

Üzerinde Rigidbody olan nesnenin konumunu değiştirmek için, yeni bir konum öncekini takip etmiyorsa her zaman Rigidbody.position veya interpolasyonu da hesaba katan sürekli bir hareket olduğunda Rigidbody.MovePosition . Bunu değiştirirken, Update işlevlerinde değil, her zaman FixedUpdate işlemleri uygulayın. Tutarlı fizik davranışları sağlayacaktır.

Mümkünse, oyun nesnelerinde küre, kutu veya silindir gibi ilkel çarpıştırıcılar kullanın ve kafes çarpıştırıcıları kullanmayın. Bu çarpıştırıcıların birden fazlasından nihai çarpıştırıcınızı oluşturabilirsiniz. Fizik, CPU yükü nedeniyle uygulamanızın performans darboğazı olabilir ve ilkel çarpıştırıcılar arasındaki çarpışmaların hesaplanması çok daha hızlıdır. Fizik etkileşiminin doğruluğu çok gerekli olmadığında, fizik sabit güncellemelerinin sıklığını azaltmak için Zaman yöneticisinde Sabit Zaman Adımı ayarını da ayarlayabilirsiniz.

Ortak Birlik Hatası #8: Tüm İşlevselliği Manuel Olarak Test Etme

Bazen oyun modunda denemeler yaparak işlevselliği manuel olarak test etme eğilimi olabilir çünkü oldukça eğlencelidir ve her şey doğrudan kontrolünüz altındadır. Ancak bu havalı faktör oldukça hızlı bir şekilde azalabilir. Uygulama ne kadar karmaşık hale gelirse, programcının uygulamanın başlangıçta amaçlandığı gibi davrandığından emin olmak için tekrar etmesi ve düşünmesi gereken sıkıcı görevler o kadar fazla olur. Tekrarlayan ve pasif karakteri nedeniyle kolayca tüm geliştirme sürecinin en kötü parçası haline gelebilir. Ayrıca, test senaryolarının manuel olarak tekrarı o kadar eğlenceli olmadığından, bazı hataların tüm test sürecini tamamlama olasılığı daha yüksektir.

Unity'nin bunu otomatikleştirmek için harika test araçları var. Uygun mimari ve kod tasarımıyla, yalıtılmış işlevselliği test etmek için birim testlerini ve hatta daha karmaşık senaryoları test etmek için entegrasyon testlerini kullanabilirsiniz. Gerçek verileri günlüğe kaydettiğiniz ve bunları istenen durumla karşılaştırdığınız deneme ve kontrol yaklaşımını önemli ölçüde azaltabilirsiniz.

Manuel test, şüphesiz geliştirmenin kritik bir parçasıdır. Ancak miktarı azaltılabilir ve tüm süreç daha sağlam ve daha hızlı olabilir. Bunu otomatikleştirmenin mümkün bir yolu olmadığında, çözmeye çalıştığınız soruna mümkün olduğunca çabuk girebilmek için test sahnelerinizi hazırlayın. İdeal olarak, oynat düğmesine bastıktan birkaç kare sonra. Test için istenen durumu ayarlamak için kısayollar veya hileler uygulayın. Ayrıca, soruna neyin neden olduğundan emin olmak için test durumunu izole edin. Test sırasında oyun modundaki gereksiz her saniye toplanır ve sorunu test etmenin ilk önyargısı ne kadar büyük olursa, sorunu hiç test etmeme olasılığınız o kadar yüksek olur ve her şeyin yolunda gitmesini umarsınız. Ama muhtemelen olmayacak.

Yaygın Unity Hatası #9: Unity Asset Store Eklentilerinin Tüm Sorunlarınızı Çözeceğini Düşünmek

Güven Bana; yapmayacaklar. Bazı müşterilerle çalışırken, bazen her küçük şey için varlık mağazası eklentileri kullanma eğilimi veya geçmişten gelen kalıntılarla karşılaştım. Unity Asset Store'da kullanışlı Unity uzantıları olmadığını kastetmiyorum. Birçoğu var ve bazen hangisini seçeceğinize karar vermek bile zor. Ancak her proje için, birbirine tam olarak uymayan farklı parçalar akıllıca kullanılmadan bozulabilecek tutarlılığı korumak önemlidir.

Öte yandan, uygulamanız uzun zaman alacak işlevsellik için Unity Asset Store'un iyi test edilmiş ürünlerini kullanmak her zaman yararlıdır, bu da geliştirme sürenizden büyük ölçüde tasarruf etmenizi sağlayabilir. Bununla birlikte, dikkatli bir şekilde seçin, nihai ürününüze çok fazla kontrol edilemez ve garip hata getirmeyecek kanıtlanmış olanları kullanın. Beş yıldızlı incelemeler, başlangıç ​​için iyi bir ölçüdür.

İstediğiniz işlevselliği uygulamak zor değilse, daha sonra tüm projelerinizde kullanılabilecek sürekli büyüyen kişisel (veya şirket) kitaplıklarınıza eklemeniz yeterlidir. Bu şekilde bilginizi ve araç setinizi aynı anda geliştiriyorsunuz.

Yaygın Unity Hatası #10: Unity Temel İşlevselliğini Genişletmeye Gerek Olmama

Bazen Unity Editor ortamı, temel oyun testleri ve seviye tasarımı için oldukça yeterli görünebilir ve bunu genişletmek zaman kaybıdır. Ama inan bana, öyle değil. Unity'nin büyük genişleme potansiyeli, onu çeşitli projelerde çözülmesi gereken belirli sorunlara uyarlayabilmesinden gelir. Bu, Unity'de çalışırken kullanıcı deneyimini iyileştirebilir veya tüm geliştirme ve seviye tasarımı iş akışını önemli ölçüde hızlandırabilir. Yerleşik veya özel Özellik Çekmeceleri, Dekoratör Çekmeceleri, özel bileşen denetçi ayarları gibi yerleşik özellikleri kullanmamak ve hatta kendi Düzenleyici Windows'u ile tüm eklentileri oluşturmamak talihsizlik olur.

Çözüm

Unity projelerinizi daha ileriye taşırken bu konuların sizin için yararlı olacağını umuyorum. Projeye özel birçok şey vardır, bu nedenle uygulanamazlar, ancak daha zor ve spesifik problemleri çözmeye çalışırken bazı temel kuralları göz önünde bulundurmak her zaman yararlıdır. Projelerinizde bu sorunları nasıl çözeceğiniz konusunda farklı görüşleriniz veya prosedürleriniz olabilir. En önemlisi, ekibinizdeki herkesin belirli bir alanın nasıl doğru bir şekilde çözülmesi gerektiğini açıkça anlayabilmesi için deyimlerinizi projeniz boyunca tutarlı tutmaktır.

Toptal Mühendislik Blogunda Daha Fazla Okuma:

• Unity AI Geliştirme: Sonlu Durumlu Makine Eğitimi