Varlık / Bileşen Sistemi ve UI “Varlıklar”

Varlık / bileşen sistemlerine hala yeşilim. Sprite (veya sprite sayfası) çizmek ve girişi (fare / dokunma tıklamaları) işlemek için yararlı bileşenlere sahip olduğum için, doğal olarak bunları UI bileşenleri (düğmeler gibi, örneğin seviye seçme ekranı) oluşturmak için yeniden kullanmak istiyorum.

Bu bana çok tuhaf geliyor. Varlıkları her zaman oyuncular, düşmanlar, güçlendirmeler, vb. Gibi "oyun modeli" olarak anladım. Öte yandan, kodu yeniden kullanma perspektifinden, kullanıcı arayüzünün bileşenlerini tekrar kullanmak mükemmel bir mantıklı.

UI / GUI endişeleri bir varlık / bileşen sistemine nasıl (ve nerede) uygundur?

(Not: Bu soru, birden fazla platform / dil için geçerli olduğundan platformdan bağımsızdır)

2d component-based gui

— ashes999
kaynak

Bence sadece 2d oyun yaptığınız için sizin için mantıklı görünüyor. 3B oyun (2d gui ile) neredeyse hiç render mantığı yeniden kullanılacağını ve 3d dünyadaki 2d gui bileşenlerinin çok mantıklı olmayacağını hayal edin. Bileşen sisteminin üstünde GUI oluşturmalısınız. Tıpkı GameplayScreen'inizin bileşenlerle varlık dünyası yaratmasını sağlayın ve bileşenlerden biri, oluşturucunuzun çizeceği "tuval" ile kamera olacaktır. Ve o tuval o ekranın arka planı olacak.

— Kikaimaru

@Kikaimaru 2D hakkında bir noktanız var. Belki MVC çok fazla, ama bir "model" (oyun varlıkları) ve görünüm / denetleyici (UI bileşenleri) bir karışımı gibi görünüyor. Elbette işe yarıyor, ama bu böyle olmalı mı? Daha iyi yollar var mı? Diğerleri nasıl yapıyor?

— ashes999

@ ashes999 Yorum ve ilk soru kalbimin derinliklerinden :)

— Narek

@Ermen Buna hiç tatmin edici bir cevap alamadım.

— ashes999

@ ashes999 beni. Her yerde insanlar MVC'yi ECS ile karıştırmamalısınız diyorlar, ama neden? Kim güzel olmaz ki? Farklı görevler için farklı silah, katılmıyor musunuz?

— Narek

Yanıtlar:

Birkaç varlık bileşeni sistemi, özellikle CraftyJS kullandıktan sonra, sorumun cevabını az ya da çok aldım: evet, GUI için bileşenleri (özellikle spritelar, görüntüler ve fare tıklama işleyicileri) yeniden kullanabilirsiniz.

Çoğu zaman, sadece ECS'ye erişiminiz vardır, altta yatan sistemlere değil (örn. Çizim sistemi). Bu durumda, başka seçeneğiniz olmadığı için bileşenleri kullanmak iyidir.

Altta yatan sisteme erişiminiz varsa (örneğin, doğrudan Curses'a erişime sahip Ruby roguelike), doğrudan bu sistem üzerinde çizim / oluşturma işleminin bir demet kullanmaktan daha etkili (daha az kod, daha az kırılgan, daha doğal) olduğunu görebilirsiniz. varlıklar ve bileşenler.

— ashes999
kaynak

Gelişmiş kullanıcı arayüzü öğelerinin mantığını nereye koyarsınız? Yani. oyuncunun ne zaman vurulduğunu ve çıtayı ne kadar düşüreceğini bilmesi gereken bir sağlık çubuğu. Belirli bir sisteme, bir senaryoya ya da başka bir şeye ihtiyacı olup olmadığını

— Emir Lima

@EmirLima böyle bir şey için, UI mantığının çoğunu sağlık çubuğuna koyarım (sağlık çubuğu boyutunu değiştiririm) ve oyuncunun vurulduğunda yeni / değişen sağlık değerinin ne olduğunu belirten bir etkinlik oluşturmasını sağlardım. (Sağlık çubuğu bu olayı yakalayabilir ve uygun şekilde tepki verebilir.)

— ashes999

Peki bu mimarideki sağlık çubuğu nesnesi nedir? "Sağlık çubuğu" bileşeni olan bir varlık mı? Varlıktan miras alan bir sınıf mı? Güncelleme çağrıları olan normal bir nesne sabit kodlanmış mı?

— Emir Lima

@EmirLima Sağlık çubuğunu bir varlık olarak ve oyuncuyu bir varlık olarak modelleyeceğim. Sizin için anlamlı olan her şeyi yapabilirsiniz.

— 16:55

2D veya 3D'de, bir varlık bileşen sistemi (ECS), aynı ECS'nin bir parçası değilse, en azından GUI sistemine erişebilmelidir.

Şahsen ben ikisini karıştırmam. Kodun bir GUI için tekrar kullanılabilirliği gerçekten en üst düzeyde gerçekleşir. Fare / klavyeye yanıt verme, oluşturma vb. Farklı düğmelerin aldığı işlevler veya belirli listelerin görüntülediği bilgiler gerçekten yeniden kullanılacak kadar genel hale getirilebilecek bir şey değildir.

Örneğin, GUI varlıklarının bileşenlerinin position, renderve gibi bir şey olacağını hayal ediyorum gui. GUI bileşeninin GUI öğesinin gerçekleştireceği eylem türünü tanımlayacağı yer. Bununla birlikte, bu eylem oldukça benzersiz ve bağlama özgü olacaktır. Bu, GUI bileşenlerinin çok büyük olduğu ve GUI işlevlerinin (yük oyunu, oyunu kaydet, sunucu bul, vb.) Dağınık geliyor.

Her GUI "ekranı" için standart bir sınıf dosyası yapmayı tercih ederim. Bu ekran için tüm işlevleri tek bir yerde bulundurun (ortak bir işlevsellik sınıfına referanslarla). Çok daha temiz ve yönetilmesi daha kolay.

Bununla birlikte, dediğim gibi, ECS'nin GUI sistemine erişimi olmalıdır. Sistemlerindeki varlıklara dayanarak GUI'ye bilgi sağlayabilmelidir. Örneğin, müttefik bir birimin üzerine gelmek, o birim hakkındaki tüm bilgileri içeren bir GUI penceresi açar. Bir düşman birliğinin üzerine gelindiğinde sınırlı bilgi içeren bir GUI penceresi açılır. Muhtemelen GUI'yi ikisi arasındaki farkı bilmesi için programlamak istemezsiniz, kuruluştan bilgilerini görüntülemesini istersiniz.

Dolayısıyla, varlıkların hala bir çeşit GUI bileşeni olacaktır, ancak GUI varlıkları değil, "oyun içi" varlıklar olacaktır. Bu bileşen, GUI arabirimlerini oluşturmak için harici GUI sistemini kullanır.

— MichaelHouse
kaynak

Sahip olduğum sistem gibi tanımladığınız sistemden oldukça farklı. Ben TouchButtonbir spritesheet ve bir dokunma-dinleyici oluşan varlık sınıfları var . Birim pop-up için, muhtemelen bunu sprite bileşeni + fare dinleyici bileşeninin bir kombinasyonu olarak uygulayacağım. Hmm.

— ashes999