Kendi kodlama dilinizi uygulamak geçerli mi?

C ++ 'da bir ritim oyunu kodluyorum ve olaylar, tetikleyiciler, kesik kesimler, vb. İçin komut dosyası oluşturma zamanı geldi. İnternette okudum ve biraz bilgi aldım. İlk tercihim olan çözüm , Cave Story'deki gibi kendi senaryo dilimi uygulamak olacaktır . Bunu önerdim ama çoğu kişi Lua'yı önerdi ama bu benim programlama tipime uymuyor.

Kendi kodlama dilinizi yaptınız mı? Neden var olanı kullanmak yerine kendi tercihini yapmayı seçtin? Geliştirme sırasında hangi kaynaklara başvurdunuz?

Hayır. En azından, muhtemelen değil.

Bu, tekerleği yeniden icat etmenin çok sık rastlanan bir durumudur, oyun geliştirme, hala oldukça popüler bir hatadır.

Bu soruyu soruyorsanız, diğerlerinin yaptıklarından etkilenme olasılığınız çok yüksek, bu yüzden Unic Engine ile Epic Games'in yaptıklarına bir bakın:

• UE3'ün özel, garip, optimize edilemeyen, hata ayıklaması zor bir UnrealScript özelliği vardı,
• Söylenti doğruysa, desteği , yeniden yüklenebilir C ++ DLL'lerin lehine UE4'te kaldırılıyor .

Epic'ten daha iyisini yapabileceğini düşünüyor musun?

Program oluşturma dilleri oluşturmak , oyun mühendislerine değil, programlama dili yaratıcılarına aittir .

Bir dilin tamamen olgunlaşması yıllar ve yıllar alır ve beraberindeki araç seti (derleyici, bağlayıcı, tercüman, hata ayıklayıcı ..) kullanılabilir. Günümüzde elinizde birçok çözüm bulunmakta, bu nedenle sıfırdan yeni bir şeye başlamak için kesinlikle hiçbir neden yok, en azından amaç sadece bir oyun yapmak değilse. Dönemi.

Yan sorularınızı yanıtlamak için, hayır, bu sebeplerden dolayı hiçbir zaman kendi senaryo dilimi oluşturmadım. Ama bazı yarı pişmiş olanlar ile çok acı çektim. Akılda tutulan çok dar bir özellik ile oluşturuldukları için, her zaman sizi deli kılan bu küçük tuhaflıklar vardı. Sık sık, sadece oyununuzu yapmak yerine sadece dilin sınırlarını aşmaya çalışmak için çok fazla zaman harcıyorsunuz.

Dil oluşturmak istemenizin nedeni, programlamayı çok iyi bilmeyen insanlar tarafından kullanılması amaçlanmışsa veya çok etki alanına özgü bir şey istediğiniz için ihtiyaç duyduğunuza inanıyorsanız, bunların da size Kötü sebepler. Fonksiyonlarını do_what_they_say_and_say_what_they_do()ve temel kullanımlarını ortaya koyan bazı basit kazan kodlarını içeren çok üst düzey bir API yazabilirsiniz . Teknik olmayan kullanıcılarınız biraz programlama öğrenmekten memnun olacak ve kötü uygulanmış bazı dillerle sınırlı olmamaktan memnun olacaksınız.

Yani, bu biraz ani ve hatta sert görünecek gibi , mantıklı gelebilecek bir durum olduğunu söyleyeceğim : Eğer bir betik dilinin nasıl yapıldığını öğrenmek istiyorsanız. Ama lütfen, lütfen, eğer öyleyseniz: başkalarını kullanmaya zorlamayın.

Düzenle

Bağladığın Mağara Hikayesi komut listesine bir baktım. ah:

<ECJx:y      [EC?] Jump           @ Jump to event Y if any npc with ID X is present

Cave Story'nin arkasındaki geliştiriciye saygısızlık etmek istemem ama bu, kontrol edilemeyen özel bir betik dilinde değiştirilen basit bir komut listesine mükemmel bir örnek. Bu, tek bir geliştirici veya çok küçük bir ekip için hala kullanılabilir, ancak bu aşamada, yapabileceğiniz uygun bir Turing-eksiksiz ve iyi denenmiş bir dile (örneğin Lua) geçmenizi öneririm:

if (npc.id == x) then
    jump_to_event(y)
end

Bu, örneğin daha karmaşık bir duruma ihtiyaç duyduğunuzda, işleri daha da kolaylaştıracaktır:

if (npc.id == x) or (npc.type == "enemy") then
    jump_to_event(y)
end

Kendi kodlama dilinizi yaptınız ve neden mevcut bir dili kullanmak yerine kendi dilinizi seçtiniz?

Diğer dillerden sözdizimini ödünç almama rağmen. Sonuçta harika bir öğrenme deneyimi oldu ve benim durumumda zor değildi çünkü dil basitti.

Bunu esas olarak yaptım çünkü senaryolarım için düzenli bir C tarzı sözdizimi kullanmak istedim, çünkü takımdaki herkes buna aşinaydı.

Programlama dillerini uygulama hakkında biraz bilgi edinmekle de ilgilenmiştim ve çok basit bir özellik alt kümesine (değişkenler, aritmetik, koşullu ifadeler, döngüler ve oyun içi işlevler veya coroutinler çağırma) ihtiyaç duyduğum için denemeye karar verdim.

Geliştirme sırasında hangi kaynaklara başvurdunuz?

Ana kaynağım bu kitaptı:

Uygulamak için bu kitaptan yeterince öğrenmeyi başardım:

• Bir lexer: normal ifadeleri kullanmak neredeyse önemsizdi, sadece belirteçleri tanımlamak ve bölmek için sadece Regex.Match'i kullanmak.
• Özyinelemeli bir iniş çözümleyici: temel olarak dilbilgisindeki her kural için bir işlev ve belirteçleri almak ve tüketmek için bazı yardımcı yöntemler. İlham için C # dilbilgisi şartnamesine baktım. En zor kısım, sonsuz özyinelemeye girmeden aritmetik ve ilişkiler operatörünün öncelikleriyle uğraşıyordu.
• Bir AST yorumlayıcısı: ziyaretçi tasarım modelini kullanarak, ayrıştırıcıdan oluşturulan ağacı travers ettim ve her bir talimat düğümünü yinelemeli olarak çalıştırdım.

Orada durmak isterdim, çünkü ihtiyaç duyduğum neredeyse her şey zaten çalışıyordu, tek bir şey dışında - özyinelemeli tercümanın derinliklerinden Unity3D koroutinlerini çağırmak ve üretmek. Bu sorunu çözmek için özyinelemeden kurtulmak zorunda kaldım ve bir kez daha kitaba döndüm. Bu sefer ekleyerek sona erdi:

• Bir derleyici: başka bir ziyaretçi, ancak kod yürütmek yerine, AST'nin her bir düğümünden (yani basit bir yığın tabanlı özel derleme dili) küçük, atomik komutların bir listesini oluşturur. Bir süre döngüsü veya bir if koşulu gibi işlemler etiketlere ve genel talimatlara dönüştürülür. Bu noktada derlenmiş betiği diske bir ikili dosya olarak da yazıyorum.
• Bir bytecode tercümanı: basit bir talimat listesinde basitçe yinelenir. Özyineleme olmadan Unity3D koroutinleri ile entegrasyon artık kolaydı.

Tüm süreç sıfır bilgiden 2 hafta sürdü ve çok eğlenceliydi :)

Not: Sonunda, araçlarımızdaki özel dilim için sözdizimi vurgulaması ve zekice bir şeyler eklemek istedim. Scintilla bu konuda hayat kurtarıcıydı. Aşağıdaki ambalajı kullandım:

http://scintillanet.codeplex.com/

Bunu önerdim ama çoğu kişi Lua'yı önerdi ama bu benim programlama tipime uymuyor.

Tamam, hadi farklı bir açıdan deneyelim: Lua hakkında sevmediğiniz şey nedir? Kolayca tamir edilebilir bir şey mi, yoksa temel bir şey mi?

Örneğin, then/do/endiyi bir C / C ++ tarzı kaşlı ayraçlar yerine kod bloğunu belirtmek gibi anahtar sözcükleri kullanın . Eğer bu senin probleminse ... düzeltebileceğin bir şey . Yapmanız gereken tek şey, kendi küçük Lua lehçenizi tanımlamak ve küme ayraç söz diziminizi gerçek Lua'ya dönüştürecek basit bir dönüştürme aracı yazmak.

Bir şekilde + = istiyor musunuz? Bu aynı zamanda bir ön işleme sisteminde yapabileceğiniz bir şeydir. Sadece formun ifadelerini expr1 += expr2içeri çevirin expr1 = expr1 + expr2.

Verilen, bir küme parantezinin bir masayı mı yoksa bir çifti mi temsil ettiğini saptamanın bir yolunu bulmanız gerekecek do/end. Ve geçersiz kılarak Lua içine ön işleme sistemi kanca olurdu dofile, loadstringve diğer standart Lua kütüphane fonksiyonları. Ama sonuçta hepsi yapılabilir.

Bunun gibi küçük sorunlarınız sizin endişenizse ve yalnızca kodlama biçiminizi değiştirmek için tek bir programlama stiline bağlıysanız (not: bu genellikle bir programcı olarak sahip olmak için korkunç bir niteliktir), bu basitten çok daha uygun bir alternatif kendi dilini yazıyor. Bu belki de en fazla birkaç hafta alır . Bunu, zengin hata ayıklama desteği ve benzerleriyle, uygun bir dilde geçirilecek yılları karşılaştırın .

Sorunlarınız bundan daha büyükse (globals varsayılandır, bu nedenle localher yerde kullanmanızı gerektirir ), bunlardan bazıları yönetilebilir (yalnızca değiştirilmiş ortamlar ve etiketler kullanarak yeni global bir hata yapabilir). Birinci sınıf nesneler, coroutinler, çöp toplama veya Lua'nın diğer temel unsurları olarak işlev görmekten nefret ediyorsanız ... o zaman, kendi yapımınızı cehennemdesiniz;)

Ve eğer gerçekten, gerçekten sert olmak istiyorsan , Lua'da derlediğin dili yazabilirsin . Böylece en azından çok iyi test edilmiş Lua çalışma zamanını, istisnai Lua API'sini ve diğer temel Lua olanaklarını, hepsi sizin Lua dilinizden kaldırabilirsiniz. Bu zaman alacak, ama yine de başka bir şeye harcayacağın yıllar olmayacak.

Diğer cevapları tamamlamak için, bu kesinlikle ikili bir seçenek değildir. Mevcut bir betik dili içinde kendi Etki Alanına özgü_ dilinizi de oluşturabilirsiniz . Bu yaklaşımın avantajları:

• Aslında resmi dilbilgileri, ayrıştırıcılar, özel düzenleyiciler uygulamak vb. İle uğraşmanıza gerek yok.
• Oyununuza özel bir komut dosyası dili, yani ek bir soyutlama uygulamanın avantajlarından faydalanıyorsunuz.
• ve homebrew: Seçtiğiniz kodlama dili ile tanışan kullanıcılar DSL'nizi hemen kullanabilecekler.
• varolan düz dilin aksine: betik dili ile tanınmayan kullanıcılar sadece oyununuzu değiştirmek için DSL bilgisine ihtiyaç duyacaklar.

Birincil dezavantajı DSL'yi "temel" dilinizin kısıtlamaları ile tasarlamanızdır.

Bu belki oyunun mekaniği bağlı mantıklı. Yeterince basit bir mekanik olan bazı oyunlar, kendilerini aşırı karmaşık Lua / Python kodlamalarından kurtarmak için yorumlanmış bir dil kullanabilir, ancak karmaşıklık tasarrufu çok fazla bir değere sahip olmayabilir. Örneğin, bu İnteraktif Roman oyunlarından biri kolayca yazılmış bir komut dosyası çalıştırma motorunu kullanabilirdi.

Oyununuz bir fizik motoru, çeşitli oyun bileşenleri ve değişken karakter ve yeteneklerin karmaşıklığını içeriyorsa, kesinlikle mevcut olan diğer betik dillerine bakmayı da düşünmelisiniz, bu yüzden özel dilinize gerekli özellikleri eklemek veya hataları düzeltmek için çabalıyorsunuz o. Lua büyük olasılıkla en hızlı olmasına rağmen, sözdizimleri için daha fazlasını isteyebileceğiniz pek çok kişi var ve birçoğu C. Python, Ruby ve Angelscript ile ne kadar kolay bütünleşebildikleri konusunda övünüyorlar. (Yorumlarda diğerlerinden bahsetmekten çekinmeyin)

Bu tür dillerin yalnızca "mantık kontrolü" için kullanıldığından emin olursanız (yani belirli bir nesne tipinde, bir buz bloğuna dokunan alev patlayıcı gibi belirli bir çarpışma vakasını ele almak için) kullanılırsa, performans hiç sorun olmaz. Elbette, diğer yandan, onları daha fazla rutin kod için kullanıyorsanız (her kareyi çalıştıran özel bir çarpışma kontrol algoritması yaparsanız), aşağı inme olasılığınız daha yüksektir.

Ben bunun için gidin diyorum. Bir özgeçmiş üzerinde ekstra bir yetenek gösterisi olacaktır. Yine de, aklınızda bulundurun, önce bu yeteneğe ihtiyacınız var. Kolay olmayacak, oldukça zor olacak. Konuyla ilgili kitap ve çevrimiçi öğreticiler de var, ama sonuçta, size ve bir derleyicinin nasıl çalıştığını ve kodun nasıl ayrıştırılıp çevrildiğine dair bir anlayışınız olacak.

Basit bir şekilde başladığınızdan, sık sık test ettiğinizden ve idealinizi koruduğunuzdan emin olun. Ama her zaman hatırla, LUA senin için orada.