Bahasa scripting apa yang harus saya pilih untuk game saya? [Tutup]


53

Dalam kasus apa bahasa scripting apa yang lebih baik dari yang lain?

Semua jawaban dihargai, berikan deskripsi, dan jelaskan dalam hal apa bahasa tersebut unggul.

(Ingat, satu bahasa per jawaban)

Jawaban:


39

Lua banyak digunakan di industri game . Dari game independen ( Aquaria ) ke judul AAA (Peradaban).

Alasan intinya? Saya akan mengatakannya karena mudah dipelajari dan mudah dimasukkan ke dalam gim Anda. Tapi hal yang sama bisa dikatakan untuk Python, saya yakin. Scripting, secara umum, tidak sulit. Saya pikir alasan sebenarnya Anda harus pergi dengan Lua adalah karena terbukti yang menghasilkan lebih banyak sumber daya di luar sana untuk Anda pelajari. Jika Anda merasa ingin bereksperimen dengan sesuatu di luar norma maka saya akan mulai mengotak-atik bahasa lain.


8
Lua sangat populer karena menyediakan fitur "bahasa meta". Anda dapat mengimplementasikan struktur berorientasi objek, atau fungsi prosedural murni, dll. Ia memiliki antarmuka C yang sangat sederhana, dan memberi pengembang mesin banyak fleksibilitas dalam bahasa itu sendiri.
Karantza

3
Saya tidak yakin python akan membuat pilihan yang baik. Binding C untuk python jauh lebih diarahkan untuk memperluas python dengan C, kemudian menanamkan python dalam C.
SpoonMeiser

5
Dari apa yang saya dengar, Ĺua juga memiliki kinerja runtime yang baik bila dibandingkan dengan bahasa skrip lain seperti Python. (dan memiliki dukungan penuh untuk penutupan - fitur yang sangat bagus jika Anda bertanya kepada saya ..)
thbusch

2
Sebenarnya Civilization IV menggunakan python ...
Emiliano

2
@happy_emi Memang, sementara Civ V menggunakan Lua
Tobias Kienzler

23

Tupai

Tupai memiliki sejarah yang menarik. Itu dibangun setelah seorang arsitek permainan memiliki masalah dengan pengumpulan sampah Lua yang tidak dapat diprediksi, dan gila semuanya nol bahkan jika itu tidak ada .

Squirrel adalah bahasa sripting yang digunakan dalam Left 4 Dead 2 . API sangat mirip lua (penulis Squirrel menyukai desain Lua ).

Jadi Squirrel adalah bahasa yang luar biasa karena Lua generasi ke-2. Butuh ide-ide bagus dan menghilangkan eksentrisitas yang menjengkelkan.

Sama dari Lua:

  • coroutine
  • tabel dan metatables
  • diketik dinamis
  • lebih banyak

Baru di Tupai:

  • kelas
  • array
  • regex bukannya sintaksis pertandingan Lua.
  • Bahasa gaya C / C ++ / Java / C # alih-alih gaya Pascal / Delphi.
  • lebih banyak

Kerugian utama tupai adalah itu bukan Lua. Lua jauh lebih banyak digunakan. Tetapi jika itu bukan masalah, Tupai adalah kemenangan yang mudah. Namun, seringkali popularitas bahasa adalah fitur yang berguna dalam dirinya sendiri, sehingga keputusannya tidak begitu jelas.


9

V8 Javascript dari google.

PRO:

Cukup mudah digunakan

Terus membaik

Kuat dan fleksibel

Lainnya Seperti banyak yang disebutkan, javascript adalah alat programmer yang umum. Menambahkannya ke permainan saya telah membuka lebih banyak orang yang merasa mampu daripada bahasa lain. Ini juga mendukung sejumlah besar casting dan konversi untuk menghemat pekerjaan untuk programmer, juga membuatnya sangat mudah digunakan, bekerja dengan baik dengan STL.

Kemungkinan CON:

Dokumentasi bisa membingungkan. Ini benar-benar bukan yang terbaik.

Contoh Seringkali web keanehan. Kurang dalam kesederhanaan yang solid, itu tampil sebagai tingkat yang jauh lebih tinggi dari itu.

Templat Terkadang ini dibenci, atau dihindari.

Ukuran kode SDK SDK Ukuran kode yang dihasilkan dapat mempertimbangkan mengasapi.


Satu con untuk saya adalah ukurannya. Jika Anda membangun gim sederhana / kasual maka mesin v8 cukup besar, dan bahkan mungkin berkali-kali lebih besar dari seluruh gim Anda.
Zack The Human

Benar, tetapi sebagai file .lib mandiri apakah itu merupakan masalah besar? Itu hanya slot di sebelah SDL Anda, atau lua Anda. Jika Anda berarti ukuran kode yang dihasilkan, baik saya belum menguji seberapa besar itu tapi itu bukan poin yang buruk.
underscorediscovery

Maksud saya ukuran kode yang dihasilkan. Saya kira itu tidak besar mengingat ukuran sebagian besar game saat ini.
Zack The Human

1
Diuji, Default shell.cc dengan jam SVN terbaru di di 1.441 MB bit.ly/9DNn8J . Walaupun ini kelihatannya cukup besar, sebagian besar perpustakaan perlu melakukan hal lain (jaringan, grafik) akan menambahnya secara dramatis. Sebuah proyek sampingan saya dengan v8, phoenixGL, ENet, banyak dorongan, dan kode lebih banyak di dalam solusi (seperti kompresi, enkripsi, perpustakaan gui, awesomium) jam 2,5 MB di visual studio 2008 - Dan zip di " rilis "build weight in pada 861 KB. Bagi saya, itu tidak terlalu buruk. Pada platform tertentu aku bisa melihatnya merepotkan - bukan untuk sebagian besar :)
underscorediscovery

1
Ive menggunakan V8 beberapa kali sebelumnya dalam proyek saya. IMO Javascript adalah bahasa yang paling ideal untuk digunakan untuk skrip game. Objek berbasis alam dan objek berbasis prototipe membuat semuanya jadi mudah. :)
Stephen Belanger

7

Itu tergantung pada game dan platform targetnya.

Gim yang menjalankan 100 karakter non-pemain (gim RTS) memiliki kebutuhan berbeda dari gim yang berjalan hanya 2 (Street Fighter). Gim yang berjalan di PC memiliki kebutuhan yang berbeda dari gim yang berjalan di konsol.

Lua populer

GameMonkey digunakan oleh beberapa tim. Lebih cepat dari Lua dan lebih baik dalam threading.

Python telah digunakan di beberapa gim.

JavaScript adalah opsi yang memungkinkan karena Anda dapat mengunduh mesin JavaScript. Ada lebih banyak programmer JavaScript daripada programer tipe lainnya.

Ada juga bahasa khusus.

SCUMM telah digunakan di beberapa game petualangan dan sangat cocok untuk game-game tersebut.


Javascript adalah ide yang sangat bagus. Saya bertanya-tanya mengapa tampaknya tidak memiliki daya tarik di ruang ini? Ada ide?
cflewis

JavaScript memang memiliki daya tarik. Unity menggunakannya. Begitu juga dengan Wolfire Games untuk mesin mereka.
AA Grapsas

Dua mesin benar-benar tidak membuat daya tarik. Saya kira alasan mengapa ini hanya pengembangan baru-baru ini adalah bahwa belum ada banyak penerjemah JavaScript yang baik sebelum Mono dan V8. SpiderMonkey bukanlah sesuatu yang Anda lihat dan katakan, "Ya, saya ingin permainan saya secepat itu, ramping, dan stabil!"

4

Demi kelengkapan, opsi lain adalah mono-script , yang memungkinkan Anda untuk menggunakan implementasi Novell dari .NET framework untuk skrip. Itulah yang digunakan Unity . Berikut halaman lain tentang menanamkan mono di aplikasi Anda.

Kerangka kerja Mono lebih cepat daripada kebanyakan (mungkin semua?) Bahasa skrip di luar sana karena tidak ditafsirkan, dan karena ada lapisan antara kompiler dan set instruksi, ini memungkinkan Anda untuk memprogram dalam berbagai bahasa termasuk C # dan dialek dari Python, Lua dan Javascript.

Saya tidak yakin apakah itu gratis di semua platform.


4
Perhatikan bahwa jika Anda melakukan pengembangan konsol, kode JITing tampaknya keluar dari pertanyaan karena Anda tidak dapat menandai halaman data sebagai executable. IL itu harus dikompilasi sebelumnya ke platform target.
Jeff

3
Masalah JIT juga berlaku untuk iOS. Juga Mono memiliki batasan lisensi. Anda memerlukan lisensi komersial jika Anda ingin menggunakannya di lingkungan di mana pengguna akhir tidak diizinkan / dapat meningkatkan runtime Mono.
Sam

4

Secara pribadi, saya menemukan AngelScript (lihat tautan di bawah) jauh lebih mudah untuk diikat ke C ++ daripada Lua ketika saya memilih bahasa scripting untuk proyek saya sendiri. (Saya benar-benar menulis perpustakaan pembungkus kecil untuk membuatnya lebih mudah digunakan, dengan mengorbankan beberapa fleksibilitas.)

http://www.angelcode.com/angelscript/

Karena itu, saya menduga Lua memiliki beberapa keunggulan yang membuatnya menarik bagi pengembang game komersial:

(a) Ini lebih dewasa dan luas daripada AngelScript

(B) Sintaksnya lebih mudah untuk non-programmer (AngelScript sangat C ++ - seperti)

(c) Memiliki jejak yang lebih kecil dari AngelScript (setidaknya sejauh yang saya ingat)

Jika Anda hanya menulis proyek hobi, saya akan mengatakan bahwa AngelScript setidaknya layak untuk dilihat.


2

Anda harus memilih bahasa skrip yang memiliki binding yang stabil dan didukung dengan baik untuk bahasa pengembangan utama game Anda. Jika Anda menulis game dalam C atau C ++, maka ada binding yang cukup solid untuk Python dan Lua. Jika Anda menulis game untuk platform .NET (menggunakan C # atau bahasa lain), maka saya sangat merekomendasikan menggunakan IronPython atau IronRuby. Keduanya adalah implementasi bahasa lengkap yang memanfaatkan Microsoft Dynamic Language Runtime (DLR), yang memberikan kinerja luar biasa dan integrasi yang sangat ketat dengan .NET Framework. Interoperabilitas antara C # dan IronPython / IronRuby cukup lancar hari ini, terutama dengan pengenalan ikatan situs dinamis di C # 4.0.


2

Skema

Yah, tipu muslihat khusus.

Dengan tipu daya, Anda dapat memiliki DSL (Bahasa Khusus Domain) Anda sendiri hanya untuk gim Anda. Setelah Anda terbiasa dengan tanda kurung dan notasi awalan, skema adalah surga untuk bekerja dengannya.

Jika Anda akan menggunakan tipu muslihat dalam permainan yang serius, saya akan menunggu beberapa bulan sampai rilis 2.0 seperti yang akan mencakup, IIRC, penerjemah Ecmascript serta skema saat ini. Anda juga dapat berharap untuk melihat peningkatan kecepatan besar.


1

Ini tergantung pada apa yang sebenarnya Anda butuhkan. Seperti yang ditunjukkan David, Lua sangat populer, meskipun salah satu pengembang game memberi tahu saya bahwa dia tidak sepenuhnya yakin mengapa. Saya pikir ringannya adalah alasan umum, tetapi pada titik ini, saya berharap banyak orang menggunakan Lua karena itu menjadi standar de facto. Tampaknya terbaik untuk modifikasi yang sangat ringan.

Untuk pendekatan yang lebih lengkap, saya akan mengatakan Python adalah pilihan yang tepat. Civ IV menggunakannya untuk efek yang layak.


0

Memilih satu bahasa skrip di atas yang lain tergantung pada persyaratan spesifik Anda.

Beberapa opsi yang harus Anda pilih adalah:

Kecepatan interpreter - jika fitur scripting semata-mata digunakan yaitu oleh pengembang untuk skrip perilaku statis, maka kecepatan dan API yang lengkap dan dapat diperluas mungkin merupakan aspek yang paling penting. Saya memiliki beberapa pengalaman bagus dengan LUA di sana.

Mudah dipelajari, aksesibilitas - untuk perancang konten / level mungkin sulit untuk mempelajari bahasa skrip yang lebih kompleks (tergantung pada latar belakang) untuk menghasilkan perilaku dinamis. Dalam hal ini, penggunaan bahasa yang mudah dipelajari (yaitu yang umum digunakan) dan didokumentasikan dengan baik bisa lebih tepat di sini. JavaScript atau Python bisa menjadi solusi yang bagus di sini.

Integrasi alur kerja - jika Anda memiliki jalur produksi khusus dengan alat yang sudah ada, mungkin ide yang buruk untuk menggunakan bahasa yang tampaknya paling cocok untuk kasus tertentu jika alat lain bekerja dengan yang sama sekali berbeda. Ini terutama berlaku jika Anda memiliki beberapa programmer yang mengerjakan alat yang berbeda. Dalam hal ini, akan lebih efisien untuk menggunakan bahasa "tidak cukup pas".


0

Jika Anda sedang mengerjakan judul untuk Windows dan menulis kode terkelola yang berjalan di atas Common Language Runtime (CLR) - misalkan dalam C # - Saya sarankan Anda melihat mengintegrasikan (Besi) Python sebagai bahasa scripting.

Dalam pengalaman saya, Python sangat mudah untuk diajarkan kepada non-programmer / desainer. Bahkan lebih mudah untuk mengambil bagi pengembang karena pada dasarnya dibaca seperti pseudocode. Mengetik secara dinamis hanyalah salah satu aspek yang membantu membuat orang dengan sedikit atau tanpa pengalaman pengkodean sebelumnya dan berlari cepat dengan bahasa.

Selain bahasa yang mudah dipelajari dan kuat, CLR dan tim bahasa di Microsoft (Anders Hejlsberg, Eric Lippert, Mads Torgersen, Jim Hugunin et al.) Telah melakukan beberapa pekerjaan besar dalam mengekspos fitur kompiler dan runtime melalui Dynamic baru Language Runtime (DLR) dalam .NET 4, membuat interoperabilitas antara kode yang diketik secara statis dan kode yang diketik secara dinamis jauh lebih mudah. Dari apa yang saya lihat dan coba sejauh ini, kode boilerplate dikurangi seminimal mungkin. Ini akan menjaga basis kode Anda tetap bersih dan terpelihara.

Anda dapat memanfaatkan ini untuk menjaga agar gesekan antara bagian skrip permainan Anda dan mesin sangat rendah. Setelah keduanya berjalan dalam VM yang sama juga akan memungkinkan runtime untuk mengoptimalkan lebih banyak kode Anda selama eksekusi.


0

Jawabannya sangat tergantung pada lingkungan Anda. Saat ini saya bekerja dengan Unity, jadi saya menggunakan bahasa berbasis mono (dalam kasus saya C #, tetapi Javascript dan Boo juga pilihan). Jawabannya sepenuhnya tergantung pada keadaan spesifik Anda.


-2

ActionScript adalah bahasa yang diketik dinamis / statis hibrida yang digunakan untuk membuat game Flash, yang dapat didistribusikan secara luas di web. Ini didukung dengan cukup baik dengan perpustakaan seperti Flixel, FlashPunk dan Box2d.


-2

Jika Anda memiliki tim yang sudah ada yang akan menggunakan bahasa skrip atau perancang (tingkat) pemimpin yang akan menggunakan skrip, maka gunakan apa pun bahasa pilihan mereka. Mereka akan menghabiskan waktu mereka dengan itu, jadi mereka harus dipenuhi.

[butiran garam] Jika Anda tidak memiliki orang atau rencana jangka panjang, maka roll sendiri . ya, menulis kompiler dan / atau penerjemah untuk bahasa scripting mungkin memakan waktu satu atau dua minggu, tetapi dalam jangka panjang fleksibilitas akan membayar berkali-kali. Hanya saja, jangan jauh-jauh tersesat dan menemukan kembali brainfuck. [/ butiran garam]


Saya akan menulis interpreter atau jit-compiler di haskell untuk sth seperti lisp / skema atau bash atau python atau lua atau erlang (apa pun tanpa lib standar) dalam satu atau dua hari. Saya tidak akan menyarankan untuk menulis juru bahasa di yaitu C ++ atau Java, asalkan bukan untuk menafsirkan seperti sth lisp. Tapi toh itu bukan pertanyaannya.
comonad

Saya pikir pertanyaannya lebih diarahkan pada pro dan kontra bahasa scripting, tidak benar-benar bagaimana memutuskan mana yang akan digunakan. Saya kira masih membantu.
Michael Coleman
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.