2B oyundaki bir nesne kendini göstermeli mi?


16

Kiremit tabanlı olmayan bir 2D sokak dövüşçüsü benzeri oyun yapıyorum. Genellikle insanlar varlıkların kendileri değil, onları oluşturan bir oluşturucuya verilmesini önerir, ancak tersi daha iyi görünüyor,

Neden biri diğerinden daha iyi?

Teşekkürler


Sizce tersi neden daha iyi?

1
@Martin çünkü nesne hangi bitmap'in yine de kullanılacağını ima edecek, bu yüzden neden object-> render ();
jmasterx

Yanıtlar:


11

Birkaç husus:

  • bahsettiğiniz gibi, her hareketli grafik hangi bitmap'in kullanılacağı hakkında "ipucu vermek" zorunda kalır, ancak varlık kendini göstermek zorundaysa. Bu 'ipucu' ne olurdu? Her bir hareketli grafik için farklı bir bitmap, hareketli grafik sayfası vb. Referansıysa, gerekenden daha fazla bellek kullanabilir veya bu belleği yönetmede sorun yaşayabilirsiniz. Ayrı bir oluşturucunun avantajı, herhangi bir varlık yönetiminden sorumlu yalnızca bir sınıfınız olmasıdır. Bununla birlikte, SF2 benzeri bir dövüş oyununda sadece iki sprite olabilir;)

  • başka bir yerde belirtildiği gibi, grafik API'nizi değiştirmek istediğinizde, tüm spritelarınızın kodunu değiştirmeniz gerekir.

  • oluşturma, bazı grafiksel bağlam referansı olmadan nadiren yapılır. Yani ya bu kavramı temsil eden global bir değişken vardır ya da her hareketli grafiğin render (GraphicalContext ctx) ile bir arayüzü vardır. Bu, grafik API'sini ve oyununuzun mantığını (bazı kişilerin belirsiz bulduğu) karıştırır ve derleme sorunlarına neden olabilir.

  • Şahsen, renderın bireysel varlıklardan ayrılmasının, oyununuzu mutlaka grafik gerektirmeyen bir sistem olarak görüntüleme yönünde ilginç bir ilk adım olduğunu görüyorum. Demek istediğim, renderlemeyi yoldan çıkardığınızda, oyunların çoğunun, varlıkların, iç durumlarının vb. Bu otomatik test, daha ayrıştırılmış sistem vb.

Sonuçta, renderlemenin ayrı bir sınıf tarafından yapıldığı sistemleri tercih etme eğilimindeyim. Bu, sprite'larınızın oluşturucuyu yazmayı daha kolay veya daha verimli hale getirirse, "grafiksel olarak ilişkili" (animasyon adı, animasyon çerçevesi, yükseklik x genişlik, sprite kimliği vb.) Gibi bazı niteliklere sahip olamayacağı anlamına gelmez.

Ve bunun 3D için geçerli olup olmadığını bilmiyorum (burada kafes kavramı ve kullanacağınız koordinat değişkeni 3D API'nize bağlı olabilir; x, y, h, w herhangi bir 2D'den neredeyse bağımsızdır API).

Umarım bu yardımcı olur.


11

Oluşturma sisteminin ne zaman çizileceğini kontrol etmesini istiyorsunuz. Bunun yerine spritelar renderlamayı kontrol altında tutuyorsa, çok fazla verimlilik kazancı ve esneklik kaybedersiniz. Ben render sistemi kontrol sahibi olması temiz kod sonuçları olduğunu düşünüyorum.

Merkezi oluşturmanın bazı avantajları:

  • z-sıralaması:
    Oyun nesnelerinin kendileri oluşturma işleminden sorumluysa, bunları doğru sırayla çağırdığınızdan emin olmanız gerekir. Aksi takdirde, arka plan nesneleri ön plandaki nesnelerin üzerine çizilebilir.
    Oluşturma sistemi kontrol altındayken, tüm oluşturma nesnelerini sıralamayı, renderleme zamanında üst üste binmeleri algılamayı ve bunları oluşturmayı veya yalnızca birlikte sipariş vermeyi bırakmayı seçebilir. Mesele şu ki, karar artık kolayca verilebilir.
  • harmanlama:
    Render sisteminin kontrol altında olmasına izin vermenin bir diğer avantajı da harmanlamadır. Burada yine render sistemi, toplu iş grafiğini paylaşarak bir doku oluşturur. Her şeyi tek bir çağrı ile oluşturmak için üçgen dilimleme kullanabilir . Bazı oluşturma hesaplarını önbelleğe alabilir. Ya da her bir sprite'ı o süslü şeylerin hiçbiriyle sırayla oluşturamazdı. (Not: her nesne kendini oluşturduğunda toplu iş mümkündür, ancak sorun daha az verimli ve daha karmaşıktır).

Bunu oyunlarımda uygulama şeklim, oyun nesnelerinin render sistemi ile çizmek istedikleri spriteları kaydetmelerini sağlamak. Nesne artık nesnenin çizilmesini istemediğinde hareketli grafiğin kaydını iptal eder veya etkin olmayan olarak işaretler.

Bütün bunlar söylendi. Oyun nesnelerinizin kendilerini kesinlikle göstermesi daha kolaysa bunu yapın. İlerlemek ve bir şey / her şeyi çizmek, mükemmel bir mimariye sahip olmaktan çok daha önemlidir.


Nesneler kendilerini çiziyorsa z-düzeni hakkında bir sistem çizim yöntemlerini çağırmak için karar veremez mi? Yani merkezileştirilmiş vs merkezileştirilmemiş, z-düzeninde hiçbir fark yaratmıyor gibi görünüyor.
GorillaApe

3

Feragatname: sorunuz çok fazla ayrıntı vermiyor, bu yüzden genel bir prensibe cevap veriyorum. Kullanımınızı yanlış anladıysam veya 'render' yaparsam lütfen affedersiniz.

Genelde harici bir nesneyi bir sahnedeki çeşitli aktörleri, sahne seviyesi özelliklerini ve yöntemlerini bireysel 'aktör nesneleri' dışında kapsüllemenin bir yolu olarak oluşturmak için kullanıyorum. Sahnedeki nesneler yalnızca dahili yöntemleri ve özellikleri içermelidir; sadece kendilerinin ne olduğunu ve ne yaptıklarını bilmelidirler. Muhtemelen, kullanıcı girişinin yanı sıra oyundaki diğer nesnelerden de etkileneceklerdir. Bu, ekranda nasıl görüntülenip görüntülenmeyeceklerini etkiler. Örneğin, bir 'yönetmen nesnesi' atlamak için 'w' tuşa basabilir ve aktör nesnesine .jump () söyleyebilir. Bu tür yönetmen seviyesi mantığı, oyunculara sahneye tamamen girmelerini veya çıkmalarını söyleyebilir.

Şerefe, David


Ama bu anlamda yönetmen sadece acton-> setVisible (false) diyemezdi; ?
jmasterx

SetVisible (false) durumunda bile, aktörün görünür değişkenini kontrol ederek ve yalnızca doğru olduğunda renderleme işlemini gerçekleştiren harici bir varlıktır.
Nav

Bir aktörü görünmez yapmak, sahneden çıkarmaz. Ayrıca çarpışmalara katılmayı da durdurmalıdır.
finnw

3

Bir gün oyununuzu farklı bir çözünürlüğe (örn. İPhone ve arkadaşlar) taşımak istiyorsanız. Bu nedenle, değişiklik oluşturma hakkında küresel bir özellik, kodunuzu nasıl kolayca güncellersiniz?


3

Kullandığım gözlemci tabanlı bir tasarımdı. Oluşturmak istediğim bir sınıfın örneğini oluşturduğumda, bunun için bir işaretçi merkezi Renderer sınıfında saklandı. Aradığınızda RenderFrame(), oluşturucu oluşturması gereken tüm mevcut nesnelere zaten sahiptir ve bunu yapmak için özelliklerine erişmiştir. Sınıfların kendilerinin hiç render edilecekleri hakkında hiçbir fikri yoktu. Bu API güzel ve temiz ve kullanımı kolay.


1
+1 İlginç. Grafik için Ziyaretçi Kalıbı'nı kullanırken ses için bu yaklaşımı kullandım . Bunun ses için daha anlamlı olduğunu düşündüm çünkü grafikler ve AI aynı saatte çalışırken, ses mikseri başka bir saatte çalışıyor, böylece bir olay modeli daha kolay. Ayrıca, bir hareket olayının (bir ses kanalının pan / yankısının değişmesine neden olan) birkaç milisaniye geç gelmesi durumunda kritik değildir, ancak bir hareketli grafik yanlış durumda çizilirse kritiktir.
finnw

2

Genel olarak her zaman kodunuzu korumanın ve genişletmenin ne kadar kolay olduğu ile ilgilidir. Yarın, şu anda kullandığınız grafik API'sını beğenmeyeceğinizi ve geçiş yapmak istediğinizi anlayacaksınız. Şimdi tüm nesne sınıflarınızı gözden geçirmek ve her şeyi değiştirmek zorunda kalacak mısınız yoksa hala projenizin merkezi bir noktasında kodunuzu değiştirmeniz gerekiyor mu?

Render () öğesini çağırdığınızda nesnelerinizin gerçekte ne yaptığına bağlıdır. Yöntem aramalarını grafik motorunuzun etrafına sararlarsa, mantık <-> grafik ayrımı hala verileceğinden, tamamen iyi.

Örneğin, render () yöntemleriniz temel olarak uygunluk yöntemleriyse ve şuna benzerse:

void MyClass::render(const Graphics &g)
{
    g.draw(this);
}

veya

void MyClass::render()
{
   mySprite->render();
}

veya

void MyClass::render()
{
    mySprite->UseShader(thatshader);
    mySprite->render();
}

ya da buna yakın, bunun bir sorun olduğunu düşünmüyorum.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.