Oyun mekaniklerini / kurallarını ana koddan ayrı olarak uygulamaya değer mi?

Bu topluluğun kapsamına uygun olup olmadığından emin değil ya da bunun yerine Stackoverflow'a gitmesi gerekmiyor.

Diyelim ki oyunumun özünde kolayca genişletilebilir olmasını istiyorum, yani iyi bir programlama bilgisine sahip olmasa da birçok insanın sadece mevcut kuralları değiştirmesini değil, aynı zamanda içine tamamen yeni bir oyun mekaniği eklemesini istiyorum. Kendimi iyi bir programcı değilim ama öğrenmeye hazırım, sadece yapılabilecek bazı talimatlara ve güvencelere ihtiyacım var.

Düşündüğüm şey, oyun mekaniklerini bir şekilde ana hizmet kodundan ayrı olarak uygulamak mümkün / mümkün olup olmadığıdır ? Demek istediğim, masa üstü oyunlarda, tüm eylemlerin gerçek algoritmalarını içermeyen, ancak bu tür her bir öğenin içeriğini yoğun biçimde referans alan bazı protokolleri ve limitleri tanımlayan kural kitaplarına sahibiz. PC oyunu için benzer bir şey yapmak mümkün mü, örneğin, daha sonra "tüketilen" ve bir yardımcı program kodu tarafından "tüketilen" bir insan programlama dili tarafından kolayca okunabilen (ve değiştirilebilir) tüm kuralları tanımlayın. oyun mekaniğinin çalışma örneği?

Bu gerçekten kendi dilimi ve bunun için bir derleyici yazmam gerekiyor gibi görünüyor).) Tabii ki yapamayacağım. Ancak soruna daha kolay bir yaklaşım olabilir mi?

Bilginize: yardımcı program kodu için benim seçim dili Python 3.x olacak

Genel olarak, herhangi bir sistemin genişletilebilme kolaylığı, alt sistemlerinin sıkı veya gevşek bir şekilde bağlanma derecesine bağlıdır . Genellikle, alt sistemler ne kadar gevşek bağlanırsa, izole edildiklerinde onları değiştirmek o kadar kolaylaşır ve sistemin bir bütün olarak tam olarak anlaşılmasını gerektirmez.

Yine de hiçbir şey ücretsiz değildir - bu tür bir sistem inşa etmek için genellikle daha fazla kaynak (çeşitli zaman, para ve beceri kombinasyonları) gerektirir. Tanımladığınız genişletilebilirliğin derecesi, kendinize attığınız beceri düzeyine doğrudan bağlı olduğum için beni vurgular. Yapılabilir, ancak tanımladığınız gibi yazılım işçiliği çok zor bir iştir.

Farkında olduğum en yakın varlıklar Vassal (tarif ettiğinizden çok daha programatik) veya Masa Üstü Simülatörü için (çoğunlukla herhangi bir oyun kuralını yorumlamak ve uygulamak için insan etkileşimine bağlı olan) moddur.

Düşündüğüm şey, oyun mekaniğinin bir şekilde ana hizmet kodundan ayrı olarak uygulanmasının mümkün olup olmadığıdır?

Bu kesinlikle mümkün. Oyunlarda sıklıkla kullanılan yöntemlerden biri Lua senaryosu .

Bağlantılı makaleden:

Lua aslen 1993 yılında, artan kişiselleştirme talebini karşılamak için yazılım uygulamalarını genişletmek için bir dil olarak tasarlanmıştır.

Birçok oyun Lua'yı kullanır. (Bağlantı kurardım ama yeni kullanıcı saygınlığı bağlantı sayımı sınırlandırıyor.)

Lua komut dosyaları çalışma zamanında derlenebilir. Bu, (örneğin) oyununuzun "betikleri" dizininde oturan ve bir modder tarafından kolayca düzenlenebilen metin dosyaları olabileceği anlamına gelir. Oyununuz onları dolduruyor ve çalıştırıyor.

Lua senaryolarının oyun içi birimlerin özelliklerini tanımladığını gördüm. İşte TA Spring'den rastgele bir örnek.

Ama "tüm kuralları tanımlamak" istiyorsun. Bu, Lua'nın tam bir dil olduğu teoride mümkün, ancak sorun şu ki, temel oyun kodunun davranışını genişletmek için senaryoları aramayı bilmesi için yeterince ön bilgili olmanız gerekiyor.

Örneğin, bir "script / card" dizinindeki kartları aramayı bilen bir kart oyunu geliştirebilirsiniz. Yeni kartlar eklemek veya mevcut kartları düzenlemek için harika. Fakat daha sonra oyununuzu bir ızgaraya minyatürler içerecek şekilde genişletmek istiyorsanız, temel kodu düzenlemek zorunda kalacaksınız - hiçbir miktar Lua kemanı sizi tek başına oraya götürmez.

Lütfen dikkat: Lua'yı getirdim, çünkü oyunlarda ve yazılımların kişiselleştirilmesinde yaygın olarak kullanıldığını biliyorum. Tek sorunun ne olduğunu, ne de sorgulamanın ihtiyaçları için en iyisi olduğunu söylemiyorum.

Süreklilik gösteren bir yaklaşım var ve bunlardan herhangi birinin buna değip değmeyeceği tam olarak ne yapmaya çalıştığınıza bağlı. Özellikle, tweaker'ı ne kadar kontrol etmek istersiniz?

Kontrolün aşırı ucunda, tweaker'ın oyunun kodunu değiştirmesine izin verebilirsiniz. Bu noktada, temel olarak yardımcı program kodunu ve nasıl kullanılacağına dair en az bir örneği yayınlıyor olacaksınız. Bir tweaker istediği kadar kod kullanabilir ya da çok az kullanabilir.

Biraz daha az kontrol sağlayan bir yaklaşım, yardımcı program kodunuzu bir şekilde "dondurmak" (önceden derleyerek söyleyin) ve yalnızca iki kişinin yapabileceklerini kısıtlayarak belirli işlevleri (geri çağırmalar) doldurmasına izin vermektir. Ne yapmak istediğinize bağlı olarak, bu yaklaşım birçok şekilde olabilir. Yaygın olarak kullanılan bir yöntem, tüm ekran kısmını kullanım / ana koda ve tüm mekaniği de kısılabilir kısımya koymaktır. Veya, bazı tamircileri "donmuş" kısımda tutmak isteyebilirsiniz, çünkü oyuncuların bunları değiştirmek istememesi veya değişken yapması çok karmaşık bir işlemdir.

Sürekliliğin düşük kontrol ucunda, sadece çiftçilerin değerleri sabit bir aralıkta değiştirmelerine izin verilir. Oyun içindeki şeylerin renklerini seçmenize izin veren bir veri dosyası örnek olabilir. Bununla birlikte, bu yaklaşımı kullanabilir ve yine de birçok kişiselleştirme sunabilirsiniz. Bir işlev seçimi tanımlamak ve tweakers'ın bunları önceki yaklaşımdan geri çağrılar oluşturmak için oluşturmalarını sağlamak, ancak yenilerini tanımlamak için izin vermemek mümkün olacaktır. Ya da belki kompozisyon bölümünü atlar ve sonlu bir seçim sunarsınız.

Tüm bu yaklaşımların ve hangisinin kullanım durumunuza uyduğunun ayrıntıları, ne tür temel oyun yapmak istediğinize ve ne kadar kontrol etmekten vazgeçmek istediğinize bağlıdır. Ticari oyunların genellikle yalnızca ikinci ve üçüncü yöntemleri kullandığına dikkat edin, çünkü ilki oyuncuların tamamen ayrı oyunlar yapmasına izin verir, bu da karmaşık lisans sorunları sunar. Bu yaklaşımların bir süreklilik oluşturması nedeniyle, ikinci yaklaşımın da bu sorunları ortaya çıkarabileceğini unutmayın.

Sistem kurallarını bu kuralları uygulayan koddan kesinlikle ayırmak mümkündür. Kodumu karmaşık projeler için bu şekilde yapılandırmayı tercih ederim, çünkü yeni kurallar eklemeyi veya kuralları daha sonra altta yatan sisteme hatalar eklemeden değiştirmeyi kolaylaştırır. Bir kural motorundaki hatalar, kuralların ve diğer kodların birlikte higgledy-piggledy ile karıştırıldığı bir sistemdeki hatalardan daha hızlı bulunur, çünkü aynı kural motoru her kural tarafından tekrar tekrar kullanılır.

Buna değer olup olmadığı sistemin karmaşıklığına bağlıdır. Pac-Man için uğraşmazdım, ama Cüce Kalesi'ni başka bir şekilde yazmayı hayal bile edemezdim.

Kesinlikle mümkün. Eğer değerse, hedeflerinize bağlı.

Bu işi yapmak için kendi dilinizi icat etmeniz veya bir derleyici yazmanız gerekmez.

Oyununuzun kolayca genişletilebilir olmasını istiyorsanız, bunun için iyi bir fikir olabilir.

Muhtemelen sizin için, en azından kısa vadede, anlaşılabilir sistemler oluşturmak ve işleri kolayca değiştirebilmek için daha fazla iş.

Bunu yapan oyunlardan biri Rimworld'dur ( Üyeliğim yok) ve temelde herkesin görmesi için oyun klasörlerinde bulunan XML dosyalarına birçok oyun verisi ve mekaniği koyarak, değiştirin. Oyunun çekirdeği / motoru Unity kullanılarak yapıldı.

Ayrıca gerçek kodlama ile oyunu daha fazla / daha derine uzatma olasılığı da var, bunun hakkında daha az şey biliyorum ama mods forumuna bakarak öğrenebilirsiniz.

Modlama olasılığı oyunu birçok insan için daha ilginç kılıyor ve bence başarısına büyük katkı sağladığını düşünüyorum. Ayrıca, geliştiricilerin, çekirdek oyuna istedikleri herhangi bir mod içeriğini getirmesini ve bir şekilde, birçok kişiden yardım aldıklarından, geliştirmeyi hızlandırarak oyunu geliştirmelerini sağlar ve buna göre bir şeyler almaya karar verebilirler. popüler olan, iş gibi görünen şey, vb.

Ve tabii ki, özellikle küçük bir bağımsız stüdyo için, yüzlerce insanın fikirleri ortaya çıkarıp bunları test ediyorlar; bu, kendileri için yapamayacakları çok fazla iş, ne de muhtemelen insanları işe almak.

Nesneye Dayalı Tasarım'a bakmak isteyebilirsiniz . Python bunun için iyi bir desteğe sahip.

Bu konuda yeniyken korkutucu olabilecek kalın kitaplar yazılır, ancak ana prensipler oldukça kolaydır.

Asıl nokta, sadece ne tür nesnelerle çalıştığınızı tanımlamanızdır. Ne tür bir oyun düşündüğünüzü söylemezsiniz, ancak Oyuncu, Canavar, Eşya, Ekipman, Silah, Zırh vb. Gibi şeyler tipik nesnelerdir.

Farklı oyun türleri istiyorsanız, büyük olasılıkla zafer koşuluyla ilgilenen bir Oyun nesnesi isteyeceksiniz. Belki bir de Harita nesnesi?

Bazen bir şeyin bir nesneyi hak edip etmediğini, mesela, hasarı açık değildir. Bir nesneye zarar vermezseniz, kod daha basit olacaktır, ancak onu bir nesne yapmak özelleştirmeyi kolaylaştırır.

Alt sınıflandırma: Hem Silahlar hem de Armours Ekipmandır. Ekipmanlar Öğelerdir. Muhtemelen başka çeşit Öğeler vardır. Muhtemelen hem Oyuncular hem de Canavarların alt sınıfları olan bir Sınıf Savaşçısı tanımlamanız yararlı olacaktır.

Buradaki fikir, örneğin Silahların, diğer tüm Eşya türleri ile ortak olarak birçok şeye sahip olacağı, ağırlık, boyut ve bunun gibi başka özelliklere sahip olacağıdır.

Bu yüzden, alt sınıflandırma size "Silahlar diğer Öğeler gibi, ancak ek olarak bunları kaldırabilirsiniz, yaptıklarınız zararı vb.

Alt sınıflama aynı zamanda mod kurucularınızın "Yeni tür silahım, bunun haricindeki standart silahlar gibidir ..." demelerini sağlar.

O zaman hangi nesnenin neyin sorumlu olduğuna karar vermelisin. Bu göründüğü kadar kolay değil ve biraz düşünmelisin. Yanlış seçimler yapmak temel oyunu çok fazla etkilemeyecek, ancak özelleştirmeyi zorlaştıracak.

Sadece kendi başınıza düştüğünüz sürece işleri değiştirebilirsiniz ancak halka bir şey bıraktığınız an, değişiklik yapmak çok daha zor hale gelir! İnsanlar, şimdi olduğu gibi olan şeylere bağlı modları yapacaklar. Hata bile. İnsanlar kodda kalan hatalara bağlı olarak mod yazacaklar. Bir şeyleri değiştirirseniz, bu modlar kırılacak ve linç çeteleri evinizde görünecek.

Örneğin:

Silah kullanan bir oyuncu, birden fazla Armour giyen bir Canavar'a saldırır. Bu, belirli bir Oyun modunda ve belirli bir Harita üzerinde gerçekleşir.

Her iki savaşçının da Kritik Vuruş ve Yakarma gibi Becerileri olabilir.

Şimdi, hangi nesne ne için sorumlu?

Buna tek bir doğru cevap yok. Çok ne tür özelleştirme izin vermek istediğinize bağlıdır.

Asla bir nesne (örneğin Harita) olarak çağırmazsanız, bu nesne saldırıyı hiçbir şekilde değiştiremez.

Tüm bu kararları verdikten sonra bunları belgeleyin . Her nesnenin tam olarak hangi moddable yöntemine sahip olduğunu, hangi parametreleri aldıklarını, ne döndürmeleri gerektiğini, vb. Listeleyen bir "Modders el kitabı" yazın.

İyi şanslar!

Bunun için bir miktar temel destek almanın basit bir yolu, ilgilenen bireylerin dikkatini çekmelerini sağlamak için çoğu sayısal değeri bir veya daha fazla ayrı metin dosyasına ayırmak olacaktır.

Örneğin, masa üstü oyunlardan bahsettiniz; D & D'ye dayalı bir oyununuz varsa weapon_damage, satırları içeren bir dosyaya sahip olabilirsiniz Battleaxe: 1d12. Yardımcı program kodunuz bu dosyayı okur ve ne zaman bir hasar verilmişse Battleaxekodunuzu generate a number from 1-12, 1 time(s)ekler ve ekler. Okumak için satırın ince ayarlanması Battleaxe: 4d6yerine generate a number from 1-6, 4 time(s)bunları ekler. Benzer şekilde, bir klasöre sahip olabilirsiniz Creaturesve içinde de dahil olmak üzere her bir yaratık için bir dosya vardır AC: 12; o zaman bu klasöre yeni dosyalar eklemek yeni yaratıklar yaratacaktır. Karakter sınıfları, arazi tipleri, bir sürü şey için bile yapılabilir.

Bu kod dışı özelleştirme stili hala çok güçlü olabilir ve oyununuzun bir çok parçasını kapsayabilir. Ancak, bu, bir kullanıcının açıkça belirtmediğiniz değişiklikleri yapmasına gerçekten izin vermez. Örneğin, bir Sinsi Saldırı koşullarını karşılayan herhangi bir saldırıya Sneak Attack: [damage]eklemek [damage]için herhangi bir Yaratık veya Sınıf'a verilebilir . "Ne zaman gizlice saldırırsan" ya da "ne zaman yanılıyorsan" ya da "ne zaman avantaj elde edersen" gibi koşulların ne olduğunu değiştirmenin yollarını bile sağlayabilirsin. Bununla birlikte, bir kullanıcı gizli saldırıların "istediği bir saldırı yaptığında, hedefin algısına da gizli tutabilirsin. Her iki rulo da başarılı olursa, Sneak Attack hasarını ekle" diyebilir.

Eğer bir kullanıcının, geliştiriciyle aynı seviyede kodlama becerisine ihtiyaç duymadan oyuna tamamen yeni davranışlar ekleyebilmesini istiyorsanız, o zaman bahsettiğiniz insanlar esasen bir oyun motoru veya ayrı bir programlama dili oluşturmayı düşündüğünüz gibi. Kodlama bilgisi gerektirmeyen değişiklikler için, metin tabanlı veri dosyaları ve klasör yapıları hala birçok seçenek sunabilir. Kullanıcıların bundan daha fazlasını değiştirmesini istiyorsanız, bir programlama dilini öğrenmelerini veya bilmelerini istemeniz gerekir.

[Yıllardır süren bir yazılım geliştiricisiyim, ancak oyun geliştirme tecrübesi olmadan, belki de oyun endüstrisi farklı yaklaşımlar kullanıyor, belki de iyi sebeplerle ...

Yaklaşımınız kesinlikle bana mantıklı geliyor. Çekirdek, mekaniğin ve kuralların dayandığı temel işlevleri sağlar, bu yüzden daha üst düzey bileşenler tarafından kullanılacak olan bir API'dir.

Ve bir API tasarlarken, en sevdiğim kılavuz, üst seviye kodunuzu ifade etmek istediğiniz dili oluşturmaktır (elbette, programlama dilinizin sözdizimi sınırlamalarıyla birlikte).

Bu nedenle, iyi bir yaklaşım, bazı varsayımsal kurallar ve mekaniği, anlatılmasını istediğiniz şekilde yazmak (tabii ki Python'un sözdizimini kullanarak) ve böylece çekirdek API'nin kurallara ve mekaniklere ne sağlamasını istediğinizi bulmak olacaktır. katmanlar.

Ve elbette, ne yaptıkları hakkında bir fikir edinmek için mevcut oyunların komut dosyası oluşturma olanaklarına bir göz atmanızı tavsiye ederim.