Apakah menerapkan bahasa skrip Anda sendiri layak?


21

Saya mengkodekan permainan beat 'up mereka di C ++ dan sudah tiba saatnya untuk mengimplementasikan scripting untuk acara, pemicu, cutscenes dll. Saya telah membaca di internet dan mendapatkan sedikit informasi. Solusi pilihan pertama saya adalah mengimplementasikan bahasa skrip saya sendiri seperti yang ada di Cave Story . Saya telah melihat ini disarankan tetapi kebanyakan poaple menyarankan lua tetapi sepertinya tidak cocok dengan jenis pemrograman saya.

Sudahkah Anda membuat bahasa skrip Anda sendiri? Mengapa Anda memilih untuk menggulung sendiri daripada menggunakan yang sudah ada? Sumber daya apa yang Anda konsultasikan selama pengembangan?


43
Aturan praktis saya adalah: jika Anda perlu bertanya kepada orang lain apakah itu ide yang baik untuk memutar _____ Anda sendiri, maka itu bukan ide yang baik.
Hocevar sam

2
Perhatikan bahwa jika Anda menerapkan bahasa Anda sendiri, orang-orang harus mempelajarinya dan berharap tidak ada bug dalam juru bahasa Anda, sedangkan bahasa seperti Lua lebih populer dan kecil kemungkinannya memiliki bug.
Nick Caplinger

2
@NickCaplinger memukulnya di kepala. Menggulir sendiri berarti tidak ada dokumentasi, tidak ada komunitas, tidak ada tutorial pihak ketiga, tidak ada StackExchange, dll. Apa pun kemajuan kecil yang Anda dapatkan dalam sintaks atau integrasi akan kalah dengan kurangnya dukungan kecuali jika Anda adalah pengembang yang benar-benar terkenal dengan jutaan penggemar.
Sean Middleditch

4
Juga perlu diingat perkakas. Ini masalah saya dengan D, Rust, Dart, dll. Sintaks Anda tidak ada gunanya sendiri. Anda memerlukan editor yang tepat, menyoroti, "Intellisense" (penyelesaian kode), diagnostik yang baik, dukungan refactoring, dukungan dokumentasi inline, dll. Untuk benar-benar bernilai apa pun. Belum lagi semua fitur bahasa yang sebenarnya, integrasi, efisiensi, dan sebagainya.
Sean Middleditch

1
Jika Anda seorang C ++ programmer, dan Anda tidak suka LUA, cobalah JavaScript gantinya.
zeel

Jawaban:


42

No Setidaknya, mungkin tidak.

Ini adalah kasus yang sangat sering ditemukan menciptakan kembali pengembangan game, kesalahan yang masih cukup populer.

Jika Anda mengajukan pertanyaan ini, kemungkinan besar Anda akan dipengaruhi oleh apa yang dilakukan orang lain, jadi lihat saja apa yang baru saja dilakukan Epic Games dengan Unreal Engine:

  • UE3 memiliki hal UnrealScript kustom, aneh, tidak dioptimalkan, sulit untuk debug,
  • Jika desas-desus itu benar, dukungannya sedang dihapus di UE4 , mendukung C ++ DLL hot-reloadeable.

Apakah Anda pikir Anda bisa melakukan lebih baik daripada Epic?

Membuat bahasa pemrograman adalah milik pembuat bahasa pemrograman , bukan insinyur game.

Butuh bertahun-tahun untuk sebuah bahasa menjadi sepenuhnya matang, dan toolset yang menyertainya (compiler, linker, interpreter, debugger ..) dapat digunakan. Saat ini Anda memiliki banyak solusi yang tersedia sehingga sama sekali tidak ada alasan nyata untuk memulai hal baru dari awal, setidaknya tidak jika tujuannya hanya untuk membuat permainan. Periode.

Untuk menjawab pertanyaan sampingan Anda, tidak, karena alasan ini saya tidak pernah menerapkan bahasa skrip saya sendiri. Tapi saya sudah banyak menderita dengan yang setengah matang. Karena mereka diciptakan dengan fitur yang sangat sempit dalam pikiran, mereka selalu memiliki kebiasaan aneh kecil yang membuat Anda gila. Seringkali, Anda akan menghabiskan banyak waktu hanya untuk mengatasi keterbatasan bahasa alih-alih membuat game saja.

Jika alasan Anda ingin membuat bahasa adalah karena itu dimaksudkan untuk digunakan oleh orang-orang yang tidak mengerti pemrograman dengan baik, atau jika Anda yakin Anda membutuhkannya karena Anda menginginkan sesuatu yang sangat spesifik untuk domain, izinkan saya memberi tahu Anda bahwa ini juga alasan buruk. Anda dapat menulis API tingkat sangat tinggi dengan fungsi-fungsi itu do_what_they_say_and_say_what_they_do(), dan beberapa kode boilerplate yang sangat sederhana yang memperlihatkan penggunaan dasarnya. Pengguna yang tidak terlalu teknis akan senang mempelajari sedikit pemrograman, dan Anda akan senang tidak dibatasi oleh beberapa bahasa yang diimplementasikan dengan buruk.

Jadi, karena ini akan terdengar tiba-tiba sedikit atau bahkan kasar, saya akan mengatakan bahwa ada satu kasus di mana itu bisa masuk akal: jika Anda ingin belajar bagaimana bahasa scripting dibuat. Tapi tolong, tolong, jika Anda melakukannya: jangan memaksa orang lain untuk menggunakannya.

Edit

Saya baru saja melihat daftar perintah Cave Story yang telah Anda tautkan. Aduh:

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

Saya tidak ingin menunjukkan rasa tidak hormat kepada pengembang di balik Cave Story, tetapi ini adalah contoh sempurna dari daftar perintah sederhana yang bermutasi dalam bahasa skrip kustom yang tidak terkendali. Ini mungkin masih dapat digunakan untuk pengembang tunggal atau tim yang sangat kecil, tetapi pada tahap ini saya menyarankan untuk beralih ke bahasa Turing-lengkap dan dicoba dengan baik (misalnya Lua), di mana Anda dapat melakukan:

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

Ini akan membuat segalanya jauh lebih mudah ketika, misalnya, Anda akan memerlukan kondisi yang lebih kompleks:

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

21
+1 "Membuat bahasa pemrograman adalah milik pembuat bahasa pemrograman, bukan insinyur game." Kutipan ini tidak mungkin lebih benar. Setelah mengambil kelas konsep bahasa pemrograman yang diajarkan oleh seorang pria yang jagoan dengan bahasa pemrograman, orang-orang ini adalah jenis yang berbeda. Satu kelas membuat saya menyadari jumlah teori CS dan matematika yang digunakan untuk menciptakan bahasa pemrograman yang nyata. Ini membuat saya lebih menghargai orang-orang ini dan keahlian mereka. Mereka membiarkan saya membuat game, saya menyingkir dan membiarkan mereka membuat bahasa.
Dean Knight

+1, saya tidak tahu bahasa lua atau bahasa skrip kustom, tetapi jelas apa yang sedang terjadi di lua dan di situlah kegunaannya penting
RhysW

1
Tidak ada yang ajaib tentang satu atau yang lain sehingga tidak mungkin untuk mempelajari keduanya. Unreal mungkin menghapus UnrealScript tetapi mereka sangat meningkatkan dan mengisi Kismet menjadi bahasa scripting visual yang mampu dan lengkap. Mereka tidak menghapus UnrealScript karena gagal, mereka menghapusnya karena sudah ketinggalan zaman dengan fitur yang jauh lebih sulit (hot-reload C ++, diperbarui Kismit). Jangan menganggap ini berarti saya tidak setuju dengan poin Anda: menulis bahasa Anda sendiri adalah buang-buang waktu, sumber bug, dan penyebab kurva belajar yang besar, dll.
Sean Middleditch

2
@ ott - Saya juga tidak takut, maksud saya adalah memperluas notasi ini akan membuatnya semakin rumit, sedangkan menggunakan bahasa yang tepat di tempat pertama akan membantu dalam jangka panjang. Overhead tidak relevan dibandingkan dengan kemudahan penggunaan dalam kasus itu, IMHO.
Laurent Couvidou

1
Perhatikan bahwa UnrealScript digantikan oleh Blueprints (tapi saya berani bertaruh kolega saya akan kembali). DLL hotload adalah fitur ortogonal.
sam hocevar

9

Sudahkah Anda membuat bahasa skrip Anda sendiri dan mengapa Anda memilih untuk roll bahasa Anda sendiri daripada menggunakan yang sudah ada?

Saya sudah, meskipun saya meminjam sintaks dari bahasa lain. Semua dalam semua itu adalah pengalaman belajar yang hebat dan dalam kasus saya tidak terlalu sulit karena bahasanya sederhana.

Saya melakukannya terutama karena saya ingin menggunakan sintaks C-style biasa untuk skrip saya, karena semua orang di tim terbiasa dengan itu.

Saya juga tertarik untuk belajar sedikit tentang menerapkan bahasa pemrograman, dan karena saya hanya membutuhkan subset fitur yang sangat sederhana (variabel, aritmatika, kondisional, loop, dan memanggil fungsi-fungsi permainan atau coroutine), saya memutuskan untuk mencobanya.

Sumber daya apa yang Anda konsultasikan selama pengembangan?

Sumber utama saya adalah buku ini:

masukkan deskripsi gambar di sini

Saya berhasil belajar cukup banyak dari buku ini untuk diimplementasikan:

  • Lexer: yang hampir sepele menggunakan ekspresi reguler, hanya menggunakan Regex.Match untuk mengidentifikasi dan membagi token.
  • Parser keturunan rekursif: pada dasarnya satu fungsi untuk setiap aturan dalam tata bahasa dan beberapa metode pembantu untuk mencari di muka dan mengkonsumsi token. Saya melihat spesifikasi tata bahasa C # untuk inspirasi. Bagian tersulit adalah berurusan dengan prioritas operator aritmatika dan hubungan tanpa masuk ke rekursi tak terbatas.
  • Seorang juru bahasa AST: menggunakan pola desain pengunjung, saya melintasi pohon yang dihasilkan dari pengurai, dan mengeksekusi setiap simpul instruksi secara rekursif.

Saya akan berhenti di sana karena hampir semua yang saya butuhkan sudah berfungsi, kecuali untuk satu hal - memanggil dan menghasilkan coroutine Unity3D jauh dari dalam interpreter rekursif. Untuk mengatasi masalah itu, saya harus menyingkirkan rekursi, dan sekali lagi beralih ke buku. Kali ini saya akhirnya menambahkan:

  • Kompiler: pengunjung lain, tetapi alih-alih mengeksekusi kode, ia menghasilkan daftar instruksi atomik kecil dari setiap node AST (yaitu bahasa rakitan kustom berbasis stack sederhana). Operasi seperti loop sementara atau kondisi if, dikonversi menjadi label dan instruksi tipe goto. Pada titik ini saya juga menulis skrip yang dikompilasi ke disk sebagai file biner.
  • Seorang penerjemah bytecode: cukup beralih di atas daftar instruksi datar. Tanpa rekursi itu sekarang mudah untuk diintegrasikan dengan coroutine Unity3D.

Seluruh proses memakan waktu sekitar 2 minggu dari nol pengetahuan, dan sangat menyenangkan :)

PS: Pada akhirnya saya juga ingin menambahkan highlight sintaksis dan intellisense untuk bahasa kustom saya pada alat kami. Scintilla adalah penyelamat dalam hal ini. Saya menggunakan pembungkus berikut:

http://scintillanet.codeplex.com/


5

Saya telah melihat ini disarankan tetapi kebanyakan poaple menyarankan lua tetapi sepertinya tidak cocok dengan jenis pemrograman saya.

OK, mari kita coba ini dari sudut yang berbeda: ada apa dengan Lua yang tidak kamu sukai? Apakah itu sesuatu yang mudah diperbaiki, atau itu sesuatu yang mendasar?

Misalnya, gunakan kata kunci seperti then/do/enduntuk menunjukkan blok kode daripada kurung kurawal gaya C / C ++ yang bagus. Jika itu masalah Anda ... itu sesuatu yang bisa Anda perbaiki. Yang perlu Anda lakukan adalah mendefinisikan dialek kecil Lua Anda sendiri, dan menulis alat transformasi sederhana yang akan mengubah sintaks kurung kurawal menjadi Lua yang sebenarnya.

Apakah Anda ingin + = dalam beberapa bentuk? Itu juga hal mudah yang dapat Anda lakukan dalam sistem pra-pemrosesan. Cukup ubah pernyataan formulir expr1 += expr2menjadi expr1 = expr1 + expr2.

Memang, Anda harus menemukan cara untuk mendeteksi apakah sepasang kurung kurawal mewakili sebuah tabel atau do/endpasangan. Dan Anda harus menghubungkan sistem pre-processing Anda ke Lua dengan menimpa dofile, loadstringdan fungsi perpustakaan Lua standar lainnya. Tapi itu semua akhirnya bisa dilakukan.

Jika masalah kecil seperti itu menjadi perhatian Anda, dan Anda terlalu terikat pada satu gaya pemrograman untuk hanya mengubah cara Anda kode (catatan: ini umumnya kualitas yang buruk untuk dimiliki sebagai seorang programmer), ini adalah alternatif yang jauh lebih layak daripada sekadar menulis bahasa Anda sendiri. Ini akan mengambil mungkin beberapa minggu paling banyak . Bandingkan dengan tahun - tahun yang akan dihabiskan pada bahasa yang tepat, dengan dukungan debug yang kaya dan sejenisnya.

Jika masalah Anda lebih besar dari ini (global adalah standarnya, sehingga mengharuskan Anda untuk menggunakannya di localmana saja), beberapa di antaranya dapat dikelola (cukup membuat menyatakan kesalahan global baru, melalui penggunaan lingkungan dan metatabel yang diubah). Jika Anda membenci fungsi sebagai objek kelas satu, coroutine, pengumpulan sampah, atau elemen dasar Lua lainnya ... yah, Anda sedang berada di neraka buatan Anda sendiri;)

Dan jika Anda benar- benar ingin menjadi hardcore tentang hal itu, Anda dapat menulis bahasa Anda sendiri yang Anda kompilasi ke dalam Lua. Jadi Anda setidaknya dapat memanfaatkan runtime Lua yang sangat teruji, API Lua yang luar biasa, dan fasilitas Lua dasar lainnya, semuanya dari bahasa Lua Anda! Ini akan memakan waktu, tetapi itu masih belum bertahun - tahun bahwa Anda akan menghabiskan sesuatu yang lain.


Bagi saya, sepertinya saya hanya bisa membuat kode fungsi jika saya menggunakan Lua. Rasanya seperti saya hanya memindahkan kode.
skiperic,

1
@skiperic: Saya tidak tahu apa yang Anda maksud dengan itu. Bisakah Anda memberi contoh?
Nicol Bolas

Lihat jawaban Laurent di atas.
skiperic,

2
@skiperic: Itu tidak menjelaskan apa yang Anda khawatirkan. Bisakah Anda kode dalam Lua? Iya nih. Dan masalahnya adalah ...?
Nicol Bolas

1
@ BartekBanachewicz: Bahkan menerima bahwa itu adalah API C, itu masih lebih unggul daripada banyak C ++ - skrip berbasis API yang pernah saya lihat. Ini satu-satunya API scripting yang akan saya pertimbangkan menggunakan raw , tanpa semacam pengikat otomatis.
Nicol Bolas

3

Untuk melengkapi jawaban lain, ini bukan opsi biner. Dalam bahasa skrip yang ada, Anda juga dapat membuat Domain-specific_language Anda sendiri . Keuntungan dari pendekatan ini adalah:

  • Anda tidak benar-benar harus mengacaukan tata bahasa formal, pengurai, menerapkan editor khusus, dll.
  • Anda mendapatkan sebagian besar manfaat menerapkan bahasa skrip khusus, yaitu abstraksi tambahan, khusus untuk gim Anda.
  • vs. homebrew: pengguna yang terbiasa dengan bahasa skrip pilihan Anda akan segera dapat menggunakan DSL Anda.
  • vs. bahasa yang sudah ada: pengguna yang tidak mengenal bahasa scripting hanya perlu pengetahuan tentang DSL untuk memodifikasi game Anda.

Kerugian utama adalah bahwa Anda akan merancang DSL dengan kendala bahasa "dasar" Anda.


2

Ini mungkin masuk akal tergantung pada mekanisme permainan Anda. Beberapa game dengan mekanisme yang cukup sederhana dapat menggunakan bahasa yang ditafsirkan untuk menyelamatkan diri dari beberapa pengkodean Lua / Python yang terlalu rumit, tetapi penghematan kompleksitas mungkin tidak terlalu berharga. Misalnya, salah satu game Interactive Novel itu dapat dengan mudah menggunakan mesin skrip yang ditulis khusus.

Jika gim Anda melibatkan mesin fisika, berbagai komponen gim, dan beragam kompleksitas karakter dan kemampuan, Anda harus mempertimbangkan untuk melihat bahasa skrip lain yang ada, sehingga Anda tidak terburu-buru untuk menambahkan fitur-fitur yang diperlukan ke kustom Anda, atau memperbaiki bug dengan saya t. Walaupun Lua kemungkinan besar adalah yang tercepat, ada banyak lainnya yang mungkin Anda sukai untuk sintaksanya, dan banyak dari mereka yang membual tentang betapa mudahnya mereka berintegrasi dengan C. Python, Ruby, dan Angelscript. (Jangan ragu untuk menyebutkan orang lain di komentar)

Jika Anda memastikan bahasa tersebut hanya digunakan untuk "kontrol logika" (yaitu menangani kasus tabrakan spesifik untuk jenis objek tertentu, seperti nyala api yang menyentuh balok es) maka kinerja hampir tidak akan pernah menjadi masalah. Tentu saja, di sisi lain, jika Anda menggunakannya untuk lebih banyak kode rutin (membuat algoritme pemeriksaan tabrakan khusus yang menjalankan setiap frame), kemungkinan besar akan menghambat Anda.


1
Lua juga merupakan bahasa scripting yang sangat populer dalam pengembangan game.
Philipp

Yup, Lua digunakan di semua tempat, tetapi OP mencatat bahwa dia tidak terlalu menyukainya. Preferensi gaya pengkodean bisa menjadi penting.
Katana314

1
" Misalnya, salah satu game Interactive Novel itu dapat dengan mudah menggunakan mesin skrip yang ditulis khusus. " Kamu jelas belum melihat Inform . Sungguh, bahkan untuk petualangan teks, tidak ada gunanya mengarang bahasa Anda sendiri.
Nicol Bolas

1
@ Katana314: " Preferensi gaya pengkodean bisa penting. " Jujur, dunia akan lebih baik jika programmer turun kuda tinggi mereka tentang "gaya pengkodean". Kita semua akan menjadi programmer yang lebih baik jika kami berhenti berpikir bahwa <masukkan bahasa pilihan di sini> pada dasarnya lebih baik daripada <masukkan bahasa preferensi orang lain di sini>. Menggunakan bahasa yang Anda mungkin tidak suka sintaks karakter build dan membantu menghindari pemikiran bug semacam ini.
Nicol Bolas

1

Saya katakan, lakukanlah. Pada resume itu akan menunjukkan kemampuan ekstra. Padahal, perlu diingat, Anda membutuhkan kemampuan itu terlebih dahulu. Itu tidak akan mudah, itu akan sangat sulit. Ada buku tentang hal itu, dan tutorial online juga, tetapi pada akhirnya itu akan turun kepada Anda dan pemahaman Anda tentang bagaimana kompiler bekerja, dan bagaimana kode diurai dan diterjemahkan.

Pastikan Anda memulai dengan sederhana, uji sering, dan pertahankan cita-cita Anda. Tapi selalu ingat, LUA ada untuk Anda.


1
Saya kira pertanyaannya di sini adalah apakah tujuannya adalah untuk membuat permainan, atau untuk membuat sesuatu yang terlihat bagus di resume.
Tridus
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.