Bir RPG oyununda çoklu hikaye konuları nasıl ele alınmalı?


26

Birden fazla hikaye dizisine sahip bir RPG oyunu tasarladım, yani kullanıcının tercihine bağlı olarak bazı şeyler olabilir veya olmayabilir, aynı şeyi birkaç şekilde başarabilirsin, bitiş farklı olabilir.

İyi çalışan ancak çok büyük bir kusuru olan basit bir karar motoru uyguladım, karar verdiğiniz anda hikayenin kararınızdan derhal etkilendiği anlamına gelir; . Bunun nedeni, hikayenin bir ağaç yapısındaki bir dal gibi ortaya çıkması ve hangi düğümün daha sonra olduğunu bilmesi gerektiğidir. Başlık altında, kararlar bir sıra kullanılarak uygulanır: her düğüm önceki düğümü ve bir sonraki düğümü bilir (ya da bir karar düğümü ise kullanıcı girişinin bir sonraki düğümü ayarlamasını bekler)

Karmaşık karar motorlarına sahip birçok oyun gördüm ve merak ediyorum, nasıl yapıldılar? İşleri gerçekten kolaylaştıran özel bir tasarım var mı? Birisi benzer bir şey yaptı mı ve bana bununla nasıl başa çıkılacağı konusunda ipucu verebilir mi?

GÜNCELLEME 1:

Önemli bir özellik, hikaye kodunu bir şekilde bağımsız tutmayı, böylece harici bir dosyadan değiştirilebilmeyi yönetmektir. Bunu motor olarak kullanmayı planlıyorum, bu yüzden olası seçimler bile harici bir dosyadan gelmek zorunda. Kod tamamen soyut olmalı.

Ayrıca, bir tasarım çözümüyle, bunu yapmanın iyi bir yoluyla, başkalarının nasıl yaptığını veya yaptığını merak ediyorum.


1
Önemli kararlar alındığında, onları global olarak erişilebilir bir değişkende takip edin (bu değişkenlerin bir dizisini yönetmek daha kolay olacaktır). Bu değişkenler daha sonra bir şeyleri uygun şekilde davranması veya göstermesi için oyun programınızın sonraki bölümleri tarafından gösterilebilir. Örneğin, oyuncu küçük bir ağaç dikmeye karar verir ve daha sonra bu ağaç çok büyük görünür - eğer ağacı dikilemezse, o zaman o ağaç oyunda aynı noktada olamazdı.
Randolf Richardson

Evet, başlangıçta bunu yapmak zorunda olduğum şeydi, ancak kod bağımsız olması için buna ihtiyacım var. Bu, hikayenin tamamen harici bir dosyadan manipüle edilebileceği anlamına gelir. Bu yüzden, az önce söylediklerinizi genelleştirmenin ve bu şekilde yapmanın bir yolunu bulmalıyım ki proje üzerinde kontrolümü kaybetmemeliyim (çok az karar var). Soruyu güncelleyecektir. Teşekkürler!
Valentin Radu

Bu yüzden daha spesifik olmak gerekirse, dünyadaki bir değişkeni kontrol edemiyorum if (isTree)veya tutamıyorum isTreeçünkü hikaye bu seçeneğe sahip olabilir veya olmayabilir. Ne demek istediğimi biliyorsun? Daha çok hikayeye hizmet edecek bir seçim motoru gibi.
Valentin Radu

Ayrıca, bunun başka bir sorunu var, diyelim ki kullanıcı bir ağaç ekmeye karar verirse, isTree=trueancak daha sonra, daha sonra ağaç hala küçükken bir okul arkadaşıyla dövüşmek, karşılığında da ağacını kesmek gibi bir şey yapar. çünkü kıçını tekmeledi. Şimdi, ağacın varlığını etkileyen 2 değişkenimiz var. isTree==true' and DidFightBrat == false`. Ne demek istediğimi biliyorsun? Zincir sonsuza kadar devam edebilir, ağacın varlığı bilinmeyen sayıda faktörden etkilenebilir. Ne demek istediğimi biliyorsun?
Valentin Radu

Sonra bu verileri diskteki bir dosyada saklayın. Bilgileri yüklemek ve kaydetmek için iki alt yordam oluşturmanız ve ardından gerektiğinde kodun her bir bölümündeki bu yordamları kullanmanız gerekir.
Randolf Richardson

Yanıtlar:


18

Ayrıca kuyruğu yönlendirilmiş bir asiklik grafiğe (DAG) genelleştirebilirsiniz. Bunları Wikipedia'da okuyabilirsiniz. Temel olarak, her düğüm "bağımlı" olduğu bir veya daha fazla üst düğüme sahip olabilir. Döngülere izin verilmez, yani A, B'ye bağlıysa, B, A'ya bağlı olamaz (doğrudan veya diğer düğümlerin herhangi bir dolaylı zinciri aracılığıyla).

Her düğüm "etkin" veya "etkin değil" durumundadır ve yalnızca tüm ebeveynleri zaten etkinse etkin hale gelmesine izin verilir. Grafiğin yapısı (hangi düğümlerin var ve nasıl bağlandıkları) oyun verilerinin bir parçasıdır, fakat aktif / aktif olmayan durum oyuncunun kaydetme verilerinin bir parçasıdır.

Bu şekilde, şu gibi şeyleri modelleyebilirsiniz: bir ağaç diktiğinizde, "plantedTree" görevini etkin olarak işaretlersiniz; daha sonra oyunun ilerleyen bölümlerinde "treeGrown" adlı başka bir görev, hem "plantedTree" hem de başka bir düğümü (hikayenin bir parçası) ebeveynleri olarak adlandırır. Ardından, "treeGrown" yalnızca oyuncu hikayede bu noktaya geldiğinde etkin hale gelir ve ayrıca "plantedTree" etkindir.

Ebeveynlerinden herhangi biri etkinleştiğinde etkinleşen düğümler veya bir ebeveyn tarafından etkinleştirilen ve başkaları tarafından devre dışı bırakılan düğümler gibi diğer özellikleri ekleyebilirsiniz. Birden fazla, birbirine bağlı konuya sahip hikayeler oluşturmak için oldukça genel bir çerçeve.


Çok güzel bir cevap, teşekkür ederim. Aslında, kullanıcı ilerlemesini kaydetmek gibi benim de sahip olduğum diğer sorunları çözüyor. İhtiyacım olan bu.
Valentin Radu

@NathanReed Bu neden döngüsel olamıyor? Asiklik olmak tipik olarak bir özellik değil, grafik tasarımının bir yan ürünüdür. Bu niyetle onu yaratmam. Örneğin, ağacınızın mevsimleri tanımasını isteyip istemediğinizi düşünün. Doğası gereği çevrimseldirler ve hikayeniz bir mevsimde geçerli olan seçeneklere bağlı olarak aynı olabilir.

Asik olmak zorundadır çünkü bir döngü varsa, döngüdeki bir düğümün aktif olup olmadığını anlamaya çalışırken sonsuz bir döngüye girersiniz, çünkü düğümü içeren tüm atalarını yinelemeli olarak kontrol edersiniz. Mevsimler gibi bir şey modellemek isteseydiniz, bunu bu grafik bağlamında yapmazdım.
Nathan Reed

@NathanReed Ah, üzgünüm, özyinelemeli kısmı özledim.

3

Anladığım kadarıyla, istediğin şey sadece bir karar motoru değil, aynı zamanda bir kural motoru. Her karar için bu karar tarafından tanımlanan bir kurallar alt dizini uygularsınız. Bu kuralların yerine getirilmesi, genellikle ağaç örneğiniz gibi belirli varlıkların durumuna bağlıdır.

Temel olarak, oynatıcınız bir karar verdiğinde, o kararı ararsınız, kuralları uygular ve ardından normal gibi bir sonraki kullanılabilir kararları verirsiniz. Ancak, kurallarınız, bazılarının yalnızca daha önce uygulamış olduğunuz diğer kurallara göre yürütüleceği için dinamiktir.

Wikipedia'da biraz daha .

Gönderen onların zaman için kullanın Kural Motorlar alt pozisyonuna (vurgu benim olduğunu):

  • Sorun, geleneksel kod için çok karmaşık.
  • Sorun karmaşık olmayabilir, ancak sağlam bir yapı oluşturulamıyor.
  • Sorun, bariz bir algoritma tabanlı çözümün ötesinde.
  • Çözülmesi karmaşık bir sorundur. Belirgin bir geleneksel çözüm yoktur veya sorun tam olarak anlaşılmamıştır.
  • Mantık sık sık değişir
  • Mantığın kendisi basit olabilir ama kurallar oldukça sık değişir. Birçok organizasyonda yazılım sürümleri nadirdir ve kurallar makul ve güvenli bir şekilde ihtiyaç duyulan ve beklenen "çevikliği" sağlamaya yardımcı olabilir.
  • Etki alanı uzmanları ve iş analistleri hazır. Ancak teknik olmayan.
  • Etki alanı uzmanları genellikle iş kuralları ve süreçleri hakkında bilgi hazinesidir. Genellikle teknik değildir, ancak çok mantıklı olabilirler. Kurallar, mantığı kendi terimleriyle ifade etmelerini sağlar. Tabii ki, yine de eleştirel düşünmeleri ve mantıklı düşünebilmeleri gerekiyor. Teknik olmayan pozisyonlarda birçok kişi resmi mantık eğitimi almaz, bu yüzden dikkatli olun ve onlarla çalışın. İş bilgisini kurallar içinde kodlayarak, genellikle iş kuralları ve süreçlerinin halihazırda anlaşıldığı şekilde delikler açacaksınız.

Unutulmaması gereken bir şey, zaman zaman bir kural motorunun en iyi basitleştirilmiş bir alana özgü "dil" veya YAML gibi bir şey kullanılarak gerçekleştirildiğidir. XML önermem.


1

Bir etkinliğin yalnızca kullanıcı kararına dayanmadığını göz önünde bulundurmalısınız. Sizin de belirttiğiniz gibi, bazı olayların bir dizi karar dizisi alındığında ve sonra başka bir şey eklendiğinde (iki gün sonra olduğu gibi) eklenmesi gerekir .

İhtiyacınız olduğunu düşündüğüm şey olayları modellemenin ve tetiklemenin bir yoludur. İlki sizin durumunuza daha sınırlı olsa da, ikincisi, etkinliklerinizi doğrudan veya dolaylı olarak tetikleyen hiyerarşik bir durum makinesi (HSM) ile modellenebilir.

Bir devlet makinesinin yalnızca hiyerarşik bir yapıyla hafifletilen bir boyutluluk laneti yaşadığını unutmayın. Yakında, bir HMS kullanarak statünün karmaşık anlamını modellemeniz gerektiğini, ancak bunu sorgulamanın bir yolunu da anlamanız gerektiğini anlayacaksınız.

Bu senaryoda, hem HSM hem de temel olay geri aramaları tarafından işlenen temel olaylara (kullanıcı kararları, zaman, hava koşullarındaki vb.) Sahip olursunuz. HSM, "hafıza" için bir model sağlar ve geri aramalar, kararların / harici olayların bir dizisinin sonuçlarını hesaplamak için bu hafızanın nasıl kullanılması gerektiğini açıklamanın bir yolunu sağlar.

Ayrıca, hesaplamak zorunda olduğunuz statünün her "yönü" için HMS'nin bir diktonerini (veya başka bir koleksiyon yapısını) kullanmanız da mümkündür. Bir örnek, olayları tetiklemek için geri aramaların aldığı kararlarda ilgili ve HMS olayını kullanmak olabilir.

Tüm bu altyapı bir insan zindanının davranışını taklit etme amacına hizmet ediyor: oyuncu kararları ve çevresel koşullar nedeniyle genellikle mevcut durumun (HMS ["dış"]) zihinsel bir kaydını tutuyor; Bir şey eklendiğinde, zihinsel kaydını kullanarak karar alabilir ve bazı durumlar örneğin eklerse, benzer şekilde tepki vermekten kaçınmak için bazı iç strateji durumlarını da (HSM ["iç"]) kaydedebilir.

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.