Bileşen tabanlı bir oyun mimarisinde davranış nasıl uygulanır?


21

Bir oyunda oyuncu ve düşman AI'yı uygulamaya başlıyorum, ancak bunu bileşen tabanlı bir oyun mimarisinde en iyi şekilde nasıl uygulayacağım konusunda kafam karıştı.

Diyelim ki sabit, hareketli ve kılıcı sallayabilen takip eden bir oyuncu karakterim var. Bir oyuncu, hem hareketli hem de hareketli durumdan salıncak kılıcına geçebilir, ancak oyuncu ayakta durmadan ya da etrafta koşmaya devam etmeden önce salıncak tamamlanmalıdır. Dönüş sırasında, oyuncu dolaşamaz.

Gördüğüm gibi iki uygulama yaklaşımım var:

  • Tüm oynatıcı mantığını içeren tek bir AI bileşeni oluşturun (ya asıl bileşenden ayrıştırılmış ya da bir PlayerAIComponent olarak gömülmüş). Müzikçaların varlığını oluşturan tek tek bileşenler arasında bağlantı oluşturmadan durum kısıtlamalarını nasıl kolayca uygulayabileceğimi kolayca söyleyebilirim. Ancak, AI bileşeni parçalanamaz. Örneğin, yalnızca ayakta durabilen ve dolanabilen veya etrafta dolaşabilen ve zaman zaman bir kılıcı döndüren bir düşmana sahipsem, yeni AI bileşenleri oluşturmam gerekir.
  • Her biri belirli bir durumu tanımlayan bileşenlerin davranışını parçalayın. Daha sonra bir StandComponent, WalkComponent ve SwingComponent alıyorum. Geçiş kurallarını uygulamak için her bir bileşeni birleştirmek zorundayım. SwingComponent, salıncak süresince StandComponent ve WalkComponent'ı devre dışı bırakmalıdır. Sadece etrafta duran, zaman zaman bir kılıcı sallanan bir düşmana sahip olduğumda, SwingComponent'in yalnızca mevcutsa WalkComponent'i devre dışı bıraktığından emin olmalıyım. Bu, daha iyi bir karışım ve eşleştirme bileşenine izin vermesine rağmen, bir bağımlılık her eklendiğinde, bir bakım kabusu ortaya çıkmasına rağmen, mevcut bileşenlerin, karaktere bağımlılığın koyduğu yeni gerekliliklerle güzel bir şekilde oynayacak şekilde güncellenmesi gerekir.

İdeal durum, bir tasarımcının, tek bir motor satırına veya komut dosyası koduna dokunmak zorunda kalmadan, bileşenleri bir kaba sürükleyerek yeni düşmanlar / oyuncular kurabilmesidir. Her ne kadar kod kodlamanın engellenebileceğinden emin olmasam da, mümkün olduğu kadar basit tutmak istiyorum.

Hepsini özetleyin: Varlık değişkenlerini daha kolay oluşturmak için tüm AI mantığını bir bileşene bölmeli miyim yoksa her mantık durumunu ayrı bileşenlere mi bölmeliyim?

düzenleme : Birinci ve ikinci durumla ne kastettiğim konusunda bir karışıklık olduğundan şüpheleniyorum. Aşağıdaki diyagramda açıklamaya çalıştım.

Bileşen şeması

Bireysel devletlerle varlık arasındaki ilişkiyi not edin. İlk durumda, bir AI bileşeni işletmeye alınmadan önce önceden inşa edilmiştir. Bir tasarımcı, yalnızca programcı tarafından sunulan farklı AIComponents kümesi arasından seçim yapabilir. İkinci durum, diğer bileşenlerle aynı düzeyde farklı durumlara sahiptir. Bir tasarımcı artık bir programcının müdahalesi olmadan benzersiz AI ile bir varlık yaratabilir.

Asıl soru, AI'yı bileşen tabanlı bir kuruluşta yapılandırmak için sadece iki seçenek ve eğer öyleyse, maksimum esneklik sağlayacak olan nedir?


Bence iyi bir cevap, eylemlerin münhasırlığını uygulamak istediğiniz yere bağlı olacaktır. Nesnelerin kendisinde olmasını istiyorsanız, tasarım, sürükle ve bırak arabirimiyle zorlamaktan çok farklı olurdu (Bu durum zaten bir harekete sahip, bu yüzden başka bir tane olamaz, bu durum geçiş kabı zaten içeriyor). zamana dayalı bir son durum, vb ya da her neyse).
James,

2 uygun bir seçenek değildir.
Coyote,

Yanıtlar:


6

Şu anda hayal bile edemeyeceğiniz daha fazla düşman veya oyuncuya sahip olmayı düşünüyorsanız, kesinlikle ayrılmalısınız. İkinci noktanda tanımladığınız şey temelde durum modelidir .

Sanırım Gregory ile ayrı durmak ve yürümek durumunda kalmamanız gerektiğine katılıyorum. Bu sadece 0 hızına sahip bir hareket bileşenidir. Öte yandan, hareket edemeyen nesneleriniz varsa, onu ayırmanız veya hareket durumuna sıfır hıza sahip olmayı engelleyen bir tür boole kısıtlaması koymanız gerekir. .

Oyuncu için tamamen ayrı olması gerektiğini sanmıyorum. Bir giriş bileşeninin eklenmesiyle diğer tüm bileşenleri kullanabilir. Bu bileşen, durumlar arasındaki geçişleri yönlendirir, düşmandaki bir varsayılan AI tarafından kontrol edilirse veya isterseniz, düşman tasarımcılarınızın seçebileceği farklı AI alt sınıfları.

düzenleme: aslında, sabit düşmanlarınız için, hareket bileşenini kısıtlamak yerine, onları hareket etmeyi asla seçmeyen sabit bir AI bileşeni vermeniz yeterli.


Bir devlet düzeni ilk durumu ima etmiyor mu? Bu, farklı durum nesneleri içeren bir durum makinesini uygulayan tek bir AIComponent ile sonuçlanır. İkinci seçenekle kastettiğim, WalkComponent ve SwingComponent'in, RenderComponent ve PhysicsComponent ile aynı türde olmasıydı.
hayalet

@ghostonline Fikir gittiği sürece. Uygulamada, gerçekten değil. AIComponent, ikinci diyagramdaki gibi ayrı olacaktır. Diğer bileşenleri içermez. İkinci durumunuz için en önemli soru, tasarımcı sadece programcı olmadan bileşenleri seçerse, Durumun ne zaman değiştirileceğini nasıl bilebilir? Farklı devletler farklı devlet geçişleri anlamına gelir - birisinin hala bunları belirtmesi gerekir.
Tesserex

Stand / Walk / Salıncak Bileşenini kontrol edecek olan, şema 2'deki işletmeye AIComponent eklemek mi istiyorsunuz? Benim fikrim, bileşenlerin belirli koşullar altında blok veya aktivasyon sinyalleri göndermesiydi. Örneğin, SwingComponent jenerik sinyaller yayar; örneğin başlangıçta "bound_feet" sinyali ve dönüşü bitirirken "release_feet". WalkComponent, bu sinyallere dayanarak kendisini devre dışı bırakır ve etkinleştirirdi. 'Durum geçişleri' bileşenlerin içinde bulunduğundan, tasarımcının bileşenleri bir araya getiren bir programcıya ihtiyacı olmayacak.
hayalet

@ghostonline Bu, "sallanırken yürüyemez" gibi sabit kuralları olan şeyler için iyi çalışır, peki durmak ve yürümek arasındaki geçişler? Eğer ayakta durma kontrol altındaysa yürümeyi denemek nasıl bir şeydir? Ayakta durma mantığı, yürüme kabiliyetinin tamamen yokluğundan etkilenen yürüyüş ya da sallanmayı seçmek isteyebilir - bu durumda daima sallanmayı seçmelidir. Ama bence doğru yoldasın.
Tesserex

2

En azından Player AI'yı (veya Player Controller'ı ne diyeceğimi) kendi bileşeni olarak tutardım. Oyunların çoğunda, oyuncu NPC'lerden temel olarak farklıdır; vuruş noktaları gibi temel durumlar dışında birinden diğerine genelleştiremezsiniz.

NPC'ler için, StandComponent ve WalkComponent'i aynı şeyin özellikleri olarak görüyorum. Hiç StandComponent'siz bir WalkComponent'in olacak mı? Şüpheliyim. Aynı şekilde, bir RunComponent sadece daha yüksek hıza ve farklı animasyonlara sahip bir WalkComponent olacaktır. Bir NPCMovementComponent ve ayrı bir NPCSwordFighterComponent'e sahip olmanın değerini görebiliyorum, ancak bu bile bana çok fazla şey hissettiriyor.


NPC hareketini ve oyuncu hareketini bu kadar ayırmam. Animasyonları ve fiziği harekete geçiren hareket eylemleri kesinlikle paylaşılabilir; Farklı olan eylemleri veya geçişleri seçen şey budur (oyuncu AI iken AI giriş yapar ... AI). Bir PlayerController'a sahip olacağınıza katılıyorum, ancak gerçek animasyon / fizik işlerini yapmak için her ikisi de Movement Components / Swing Components'ı kullanabilecek bir AIController'ınız olacaktı.
homebrew

Doğru. Hareket eden tüm nesnelerin hareketlerini idare eden bir Fizik Bileşeni ya da Hareketi Bileşeni olduğunu ve PlayerController ve AIController'ın hareketi işlemek için kullanacağını farz ediyorum. Hareket, AI içermeyen ya da mümkün olan en basit AI'ye sahip olması gereken (kasalar veya hurdalık gibi aptal fizik nesneleri) aptal olması gereken, kesinlikle ayrı bir bileşen olmalıdır.
Gregory Avery-Weir

2

Önce bir Devlet bileşeni yapardım, sonra da geçişleri idare edecek bir devlet makinesi yaratırdım. Bunu oyuncularınız ve AI'nız için kullanabileceğiniz kadar genel yapın. Bu, AI'nın aynı kurallara göre oynamasını ve oyuncu durumlarının AI durumlarına göre çalışma şeklini değiştirirken mantığınızı değiştirmeniz gerekmediğinden emin olmanızı sağlar.

Sonlu Durumlu Makine C ++

Yukarıdakiler, c ++ 'da oyuncular ve AI tarafından kullanılabilecek bir somut örnek örneğidir.


1

İstediğiniz şey karakterlerin hareketini işleyen bir bileşendir (oynatıcı ve NPC'ler). AI bileşeni veya oynatıcı bileşeni, bu hareket bileşenine komutlar gönderir ve eylemin başlatılıp başlatılamayacağını kontrol eder. Bu, hareket kısıtlamalarınızı tek bir bileşende kapsayacak. AI kodunuz ve oyuncu kodunuz, salıncak kılıcının nasıl çalıştırıldığını bilmek zorunda değildir. AI'nın içsel durumları olabilir; örneğin Boşta, Saldırgan, Kaçan.


1
TYPO: "Alacak ..." AI bileşeninden ne haber ?
Pup
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.