C # gibi yönetilen bir Dil ile oyun yazarken tipik tuzaklar nelerdir? [kapalı]

PC için C # gibi yönetilen bir dil ile oyun yazarken hangi zorluklarla karşılaştınız ve bunları nasıl çözdünüz?

Java hakkında pek bir şey bilmiyorum, bu yüzden bir .net dev.

Şimdiye kadar en büyüğü çöp. .net çöp toplayıcıları pencerelerde harika bir iş çıkarır ve çoğunlukla oturan bebek olmadan kurtulabilirsiniz. Xbox / winPhone7'de bu farklı bir konu. Her birkaç çerçevede bir tezgah varsa, çöp toplama işlemi sorunlara neden olabilir. Şu anda her 1mb tahsisi sonrasında tetiklenir.

Heres çöp ile başa çıkmak için bazı ipuçları. Gerçekte bunların çoğu için endişelenmenize gerek olmamalı, ancak bir gün kullanışlı olabilirler.

• İçeriğini GC.GetTotalMemory()ekrana çizin . Bu size oyununuzun kullandığı tahsis edilmiş bayt miktarının yaklaşık bir değerini verir. Neredeyse hareket ederse, tamam yapıyorsunuz. Hızlı gidiyorsa, sorunların var.
• tüm öbek nesnelerinizi ön tarafa ayırmaya çalışın . Oyun başlamadan önce her şeyi tahsis edemezseniz, her defasında bir miktar tahsis edersiniz, durur. Tahsis yok, koleksiyon yok. Kadar basit.
• Yüklemeden sonra GC.Collect () öğesini arayın. Büyük tahsisatlarınızın çoğunun yolun dışında olduğunu biliyorsanız, yalnızca sistemi bilmeniz güzel olur.
• GC.Collect()Her kareyi ARAYMAYIN . Çöpün ve her şeyin üstünde tutmak iyi bir fikir gibi görünebilir, ancak çöp toplamanın bittiğinden daha kötüsü olanları sadece unutma.
• Çöpünüzün nereden geldiğine bakın. Kullanmak yerine dizeleri birleştirmek gibi bazı ortak nedenler vardır StringBuilder(dikkat, StringBuildersihirli bir mermi değildir ve yine de tahsislere neden olabilir! ) kullanarak foreachkullanmak koleksiyonları üzerinde döngüler IEnumerableda bilmeden çöp oluşturabilir arabirimini (örneğin, foreach (EffectPass pass in effect.CurrentTechnique.Passes)ortak bir tanesidir)
• Belleğin nerede tahsis edildiğini bulmak için CLR bellek profili oluşturucu gibi araçlar kullanın . Bu aracın nasıl kullanılacağına dair bir sürü ders var.
• Oyun sırasındaki tahsisatınızın nerede olduğunu biliyorsanız, bu tahsisat sayısını düşürmek için nesneleri birleştirmek gibi hileler kullanıp kullanamayacağınıza bakın.
• Her şey başarısız olursa, koleksiyonlarınızı daha hızlı çalıştırın! Kompakt çerçeve üzerindeki GC, hangi nesnelerin kullanılmadığını anlamak için kodunuzdaki tüm referansları takip eder. Refactor kodunuzu daha az referans kullanın!
• IDisposableYönetilmeyen kaynaklar içeren sınıflarda kullanmayı unutmayın . Bunları, GC'yi kendi kendine bırakamayan belleği temizlemek için kullanabilirsiniz.

Düşünülmesi gereken bir diğer şey ise kayan nokta performansı. Net JITer, işlemciye özgü optimizasyonları adil bir miktarda yaparken, kayan nokta matematiğinizi hızlandırmak için SSE veya başka bir SIMD komut setini kullanamaz. Bu, oyunlar için C ++ ve C # arasında oldukça büyük bir hız farkına neden olabilir. Mono kullanıyorsanız, yararlanabileceğiniz bazı özel SIMD matematik kütüphaneleri vardır.

Tipik bir performans düşüşü, çöp toplayıcıyı oyunun tasarımında / geliştirilmesinde dikkate almaz. Çok fazla çöp üretmek, GC uzun bir süre çalıştığında gerçekleşen oyunda "hıçkırık" a yol açabilir.

C # için değer nesnelerini ve "using" ifadesini kullanmak, GC'deki basıncı hafifletebilir.

C # 'da oyun yazarken karşılaştığım en büyük problemin düzgün kütüphanelerin eksikliği olduğunu söyleyebilirim. Bulduğum çoğu, doğrudan bağlantı noktaları, ancak tamamlanmamış ya da bir C ++ kitaplığı üzerindeki sarmalayıcılar, marshalling için ağır bir performans cezası gerektiren. (OGRE kütüphanesi için özellikle MOgre ve Axiom ve Bullet fizik kütüphanesi için BulletSharp hakkında konuşuyorum)

Yönetilen diller (Yorumlananlardan farklı olarak - ne Java ne de C # artık yorumlanmıyor), gerçekte neyin yavaşladığını (marshaling, çöp toplama) iyi bir şekilde anladıysanız, yerel diller kadar hızlı olabilir. Bence asıl sorun, kütüphane geliştiricilerin henüz bunu anlamadığıdır.

Diğerlerinin de söylediği gibi, GC koleksiyonu duraklamaları en büyük konudur. Nesne havuzlarını kullanmak tipik bir çözümdür.

C # ve Java yorumlanmadı. Onlar sonra, bir ara baytkoduna derlenmiş ediyoruz JIT , yerli kod (veya önemsiz olacak kadar yakın) kadar hızlı olur

Bulduğum en büyük sorun, kullanıcı deneyimini doğrudan etkileyen kaynakları serbest bırakmak. Bu diller C ++ gibi deterministik sonlandırmayı otomatik olarak desteklememektedir , eğer beklemiyorsanız, tahrip olduklarını düşündükten sonra sahnede kayan kafesler gibi şeylere yol açabilir. (C #, IDisposable ile deterministic sonlandırmayı gerçekleştirir , Java'nın ne yaptığından emin değilim.)

Bunun dışında, yönetilen diller, oyunların kredi alacağından daha fazla performans gösterme yeteneğine sahipler. İyi yazılmış yönetilen kod, kötü yazılmış yerel koddan çok daha hızlıdır.

Ne Java ne de C # yorumlanmaz. İkisi de yerel makine kodunda derlendi.

Hem oyunlarda hem de oyunlarda ortaya çıkan en büyük sorun, oyun sırasında hiçbir zaman çöp toplamayacak şekilde kodlamak zorunda kalmaktır. Bunu başarmak için atlamanız gereken halka sayısı, ilk etapta bunları kullanmanın yararlarından neredeyse ağır basar. Bu dili uygulama veya sunucu programlaması için kullanmayı eğlenceli kılan özelliklerin çoğunun oyun programlaması için kullanılması önlenmelidir, aksi halde oyun oynama sırasında gider ve çöp topladıkça uzun duraklamalar alırsınız.

Bunun gibi dillerle (ya da XNA, TorqueX motoru, vb. Araçlarla) oyun oynayarak gördüğüm büyük bir tuzak, neye eşdeğer bir oyun oluşturmak için gerekli uzmanlığa sahip iyi bir insan ekibi bulmak için zorlanmanız. C ++ ve OpenGL / DirectX'te insanları bulmak oldukça kolay olurdu.

Oyun endüstrisi, C ++ 'ta büyük ve sadece iyi cilalanmış küçük oyunları itmek için kullanılan araçların ve boru hatlarının çoğu C ++' ta yazıldığı için hala çok ağır bir biçimde sarsıldı. XBox, PS3 ve Wii için yalnızca C ++ ile uyumlulukla yayınlandı (XBox araç takımı bugünlerde daha iyi yönetilebilir, herkes daha fazlasını biliyor mu?)

Şu anda konsollar için oyunlar geliştirmek istiyorsanız, hemen hemen XBox'ta XNA ve C # ve ardından yalnızca XBox Live Indie Games adlı oyun kütüphanesinin bir tarafında olsun. Yarışmalar vb. Kazananları, oyunlarını gerçek XBox Live Arcade'e taşımak için seçildi. PC için bir oyun yapma planından başka.