Apa pro dan kontra dari menggabungkan Lua ke dalam game C ++?


37

Saya memiliki buku pemrograman game C ++ dan memiliki bagian Lua di dalamnya. Saya sudah mulai membaca bagian Lua, dan kedengarannya menarik, tapi saya tidak bisa menentukan pro dan kontra menggunakan Lua di game C ++ saya. Satu-satunya keuntungan yang saya pikirkan saat ini adalah Anda dapat membuat beberapa pembaruan pengkodean, melalui Lua, tanpa harus melakukan kompilasi ulang. Selain itu, saya tidak bisa memikirkan apa pun. Jadi apa pro dan kontra dari menambahkan Lua ke game C ++?

Contohnya akan dihargai.




Setuju bahwa itu mirip dengan pertanyaan-pertanyaan itu, tetapi yang penting di sini adalah 'kontra'.
Jonathan Dickinson

@ JonathanDickinson jawaban tidak menunjuk ke arah itu, meskipun ... mereka pada dasarnya menyatakan sama seperti dalam pertanyaan terkait.
bummzack

Jawaban:


33

Satu-satunya keuntungan yang saya pikirkan saat ini adalah bahwa Anda dapat membuat beberapa pembaruan pengkodean, melalui Lua, tanpa harus mengkompilasi ulang.

Jangan mengabaikan utilitas ini dengan mudah. Kamu tidak akan pernah mengerti seberapa produktif Anda sampai Anda mengambil langkah kompilasi.

The "mengalir" adalah sebuah konsep psikologis yang cukup dipahami dengan baik ketika datang ke pekerjaan. Alurnya adalah perasaan yang Anda dapatkan ketika Anda fokus pada suatu kegiatan, ketika Anda menganalisis dan memecahkan masalah hampir tanpa berpikir, dll. Anda paling produktif saat Anda "mengalir".

Waktu kompilasi mengacaukan semua itu. Sulit untuk tetap mengikuti arus jika Anda memiliki kompilasi 10 detik antara pengujian sesuatu.

Ketika Anda mengembangkan gameplay, apa yang biasanya Anda miliki adalah "lingkaran ketat". Anda punya ide, Anda membuat kode tes untuk melihat apakah itu berhasil, dan kemudian Anda mencobanya. Jika tidak berhasil, Anda memodifikasinya dan coba lagi. Waktu "code-to-test" sangat penting untuk menjaga aliran. Mendapatkannya sekecil mungkin sangat penting.

Apa yang Lua (atau bahasa skrip tertanam apa pun) memungkinkan Anda lakukan adalah menguji perubahan, tidak hanya tanpa "kompilasi", tetapi hidup dalam gim . Bergantung pada bagaimana Anda membangun game, Anda dapat menjalankan perintah yang akan memulai kembali game dengan skrip baru tanpa harus berhenti dan memuat ulang data dan sebagainya. Anda tidak hanya harus melakukan kompilasi ulang, Anda tidak harus menjalankan ulang.

Kemampuan untuk melakukan ini, mengingat dukungan engine yang tepat, dapat secara dramatis meningkatkan produktivitas.


Manfaat utama lain dari scripting adalah kemampuan untuk tidak peduli. Jika Anda telah menghabiskan waktu lama menulis C ++, Anda akan kagum dengan berapa banyak waktu yang Anda habiskan untuk minutae. Di mana memori dihapus. Di mana ini dibebaskan. Bahkan jika Anda menggunakan di shared_ptrmana - mana, tindakan mengetik semua nama variabel itu akan memperlambat Anda.

Dalam bahasa skrip yang diketik secara dinamis, Anda tidak perlu peduli. Pelingkupan itu sederhana. Fungsi adalah objek kelas satu; Anda tidak perlu membangun functors secara manual. Sangat mudah untuk melakukan beberapa hal.

Nah, itu memang punya negatif, jika Anda bukan seorang programmer disiplin. Sangat mudah untuk menggunakan global di Lua (meskipun ada cara untuk mencegahnya). Tidak peduli berarti Anda bisa sangat ceroboh ketika Anda membuat kode.

Tetapi sekali lagi, menjadi sangat ceroboh dapat memiliki keuntungan .


Kelebihan lain dari Lua adalah membuat bahasa deskripsi data yang bagus. Sama seperti JSON hanyalah file JavaScript yang membangun dan mengembalikan array / tabel, Anda dapat membuat skrip Lua yang mengembalikan tabel.

Ini berguna untuk file konfigurasi; Format tabel Lua jauh lebih baik daripada format .ini. Formatnya masih agak bersih, kompak, dan dapat diperpanjang.

Oh, dan itu masih berupa skrip Lua, sehingga bisa melakukan logika yang sebenarnya. Kelemahan dari itu adalah ... yah, itu adalah skrip Lua, sehingga dapat melakukan logika yang sebenarnya . Itu bisa menjadi bencana dalam game, karena pengguna berpotensi mulai mengacaukan segalanya.

Namun sebenarnya, ini mudah ditangani. Lua dirancang untuk ditempelkan, yang berarti isolasi sebenarnya cukup mudah. Memang, keadaan Lua yang segar tidak memberikan apa-apa secara default; Anda harus benar-benar melakukan sesuatu untuk mengekspos bahkan perpustakaan Lua standar yang paling dasar. Akses file, akses kondisi permainan, dll., Semuanya merupakan penyertaan, bukan penyisihan. Dan setiap negara Lua terpisah satu sama lain. Status Lua yang Anda gunakan untuk skrip AI tidak harus status Lua yang Anda gunakan untuk file konfigurasi.

Saya sebenarnya memiliki beberapa kode yang memungkinkan Anda untuk mendaftarkan banyak perpustakaan standar Lua, tetapi melewati dan menghapus semua file IO. Pada akhirnya, hal terburuk yang dapat dilakukan file konfigurasi berbasis script Lua adalah menyebabkan game Anda langsung crash saat dijalankan, dengan kehabisan memori. Dan karena Anda tidak membagikan file konfigurasi ini secara manual, itu tidak akan menyenangkan bagi peretas.


Saya akan mengatakan bahwa kelemahan terbesar dari bahasa scripting adalah debugging. Sebagian besar bahasa skrip tidak memiliki debugger, dan Lua tidak berbeda. Lua memang memiliki semua alat yang diperlukan untuk membangun alat debugging. Tetapi sebenarnya tidak memiliki debugger built-in. Anda harus menyatukannya. Dan itu akan membutuhkan tingkat pekerjaan yang masuk akal.

Atau Anda dapat membuat karena dengan "printf debugging". Itu benar-benar tergantung pada seberapa banyak kode Lua yang Anda tulis.


1
mengalir tidak selalu merupakan hal yang baik; melakukan sesuatu secara otomatis kadang-kadang berarti tidak meluangkan waktu untuk membahas alternatif desain.
lurscher

10
@ Lurscher: Desain adalah apa yang Anda lakukan sebelum Anda duduk ke kode. Anda harus mengerjakan semua alternatif desain itu sebelum mulai menulis, menguji, dan men-debug kode Anda.
Nicol Bolas

23

Dimana saya bekerja:

Pro:

  • perbaikan waktu iterasi . Game kami diatur untuk melakukan polling sistem file host untuk perubahan dan secara otomatis "menyeruput" perubahan. (Mereka hanya berlaku pada pembukaan file berikutnya, tetapi dalam praktiknya, itu merupakan peningkatan besar: memuat ulang level, dan perubahan lua baru Anda segera masuk.)
  • integrasi konsol . Fungsionalitas debug apa pun dapat dihubungkan ke konsol bergaya Gempa tradisional dengan REPL. Untuk build internal, kami bahkan dapat menghubungkan lua REPL ke soket sederhana yang menggunakan telnet, dan kami memiliki kontrol jaringan atas game kami.
  • mengurangi api dan kurva belajar yang lebih rendah . Seniman dan desainer nonteknis dapat bergabung dalam beberapa tugas yang biasanya akan menjadi penghambat programer.
  • analisis kode statis khusus . Sangat mudah untuk mem-parsing output luac -ldan mengintip bytecode untuk melakukan beberapa analisis; itu juga cukup mudah untuk mem-parsing sebagian besar file sumber lua, terutama jika Anda memiliki konvensi pengkodean. Kami dapat menegakkan konvensi lokal. Anda juga dapat melihat metalua untuk mendapatkan lebih banyak kekuatan di sini.
  • penanganan kesalahan . Jika API kami bebas dari gangguan, meskipun lua melakukan sesuatu yang konyol, kami dapat menangkapnya dan memulihkannya dengan menggunakan lua_pcall.
  • ekstensi API mudah . Menulis fungsi baru untuk Lua <-> C ++ API tidak terlalu sulit. Ada juga paket yang akan membantu mengotomatisasi ini.
  • sumber sederhana . Membuat perubahan misalnya menghindari matematika floating point dalam lua interpreter (penting pada beberapa platform tertanam) atau untuk mengoptimalkan sistem tertentu tidak terlalu sulit!
  • metatables . Ini luar biasa. Begitu banyak potensi untuk melakukan hal-hal menarik saat runtime. Kami memiliki "tabel virtual" yang sebenarnya tidak memiliki konten dan melakukan pencarian ke dalam struktur data yang rumit di C ++ - di sisi permainan kami.
  • coroutine . Mampu berhenti dan melanjutkan misalnya skrip perilaku AI sangat mengagumkan. Meskipun demikian, dibutuhkan sedikit pengetahuan lebih lanjut tentang lua scripter - kami masih berusaha membuat ini lebih "aman" dengan mesin kami.

Cons:

  • GC yang tidak dapat diprediksi . Menyesuaikan apa yang stepharus kita ubah secara drastis per game. Beberapa bekerja lebih baik dengan GC penuh setiap frame (set kerja kecil). Beberapa bekerja lebih baik dengan operan yang jauh lebih kecil. Perhatikan ada banyak pekerjaan dalam meningkatkan GC pada versi lua yang lebih baru dan di beberapa tambalan (yang Anda tidak perlu takut untuk menggunakannya!)
  • overhead yang lebih tinggi . Kami menyimpan banyak struktur data C-side kami yang besar untuk menghindari overhead memori per-tabel-entri. C ++, C, dan assembly umumnya menghasilkan kode yang lebih cepat. Jadi itu disimpan ke 90% dari mesin permainan yang tidak kritis terhadap kinerja, dan kadang-kadang kita melakukan migrasi dari lua ke C (atau sebaliknya).
  • fragmentasi . Mungkin masalah terbesar pada sistem memori kecil. Kami biasanya menggunakan kolam objek kecil dan tumpukan objek besar yang benar-benar terpisah untuk lua. Kami menempatkan umpan penuh GC di poin-poin strategis dalam permainan. Kami membongkar skrip atau membuang lua_Stateseluruhnya dalam beberapa kasus. Dan terkadang kita masih memiliki masalah. Menyetel ukuran kumpulan objek kecil (mereka diperbaiki, untuk kesederhanaan dan overhead yang lebih rendah) dan ukuran tumpukan objek besar khusus lua bisa menyebalkan. Tetapi pada sistem yang lebih besar dari sekitar 4MB, kami belum peduli dengan tumpukan dan kumpulan khusus.
  • kurangnya keamanan jenis . Jika Anda tidak memiliki toolset analisis kode statis yang baik, Anda akan kembali ke banyak pengecekan error runtime (mungkin menggunakan __indexdan __newindex). Lebih baik jika Anda dapat menangkap kesalahan pada waktu kompilasi. Ada berbagai hal yang dapat Anda lakukan untuk meringankan ini.

Lua sangat direkomendasikan, hanya bersedia bekerja sedikit dengannya! Anda mungkin juga ingin memeriksa Tupai , meskipun saya percaya ini memiliki basis pengguna yang lebih kecil.


Saya berharap saya bisa memilih ini beberapa kali. Sangat komprehensif, sangat berwawasan luas, terstruktur dengan jelas. +1
Koarl

5

Sebenarnya ada 3 keuntungan besar:

Faktor-faktor ini memungkinkan Anda sebagai pengembang game untuk mengaktifkan fitur yang akan mempercepat pengembangan dan meningkatkan kualitas game Anda.

Sebagai contoh:

  • Anda akan dapat mengubah logika game Anda hanya dengan memperbarui game Anda dari file atau soket jaringan.
  • Anda dapat mengizinkan pengguna untuk membuat skrip mereka sendiri (untuk bot atau mod)
  • Desainer dan artis gim Anda akan dapat memperbarui dan menguji bagian-bagian gim tanpa harus menggunakan perangkat kompilasi Anda.
  • Anda tidak perlu mengkompilasi ulang setiap kali Anda mengubah beberapa skrip.
  • Anda tidak perlu menulis ulang seluruh permainan jika Anda mengubah platform / mesin / bahasa.

1
"Anda tidak perlu menulis ulang seluruh permainan jika Anda mengubah platform / mesin / bahasa." Kecuali jika Anda mengubah dari Lua ke bahasa lain. Dan jika Anda menulis "seluruh permainan" di Lua, jika Anda mengganti mesin, maka perubahan itu harus diekspos ke Lua (atau Anda perlu abstraksi antara Lua dan mesin untuk menyembunyikan detailnya). Jadi saya tidak melihat bagaimana Lua membantu dalam kasus-kasus itu.
Nicol Bolas

3

Dari pengalaman saya, rebus sedikit.

Pro

  • Integrasi awal sangat mudah. Alat ada untuk membantu menghasilkan binding, tetapi mekanisme pengikatannya sangat sederhana sehingga Anda dapat menulis versi Anda sendiri, dengan fitur kustom Anda sendiri, dalam waktu singkat
  • Anda mendapatkan iterasi yang jauh lebih cepat pada logika game (dengan asumsi Anda menerapkan reload runtime)
  • Anda akan mendapatkan lingkungan yang membebaskan untuk bereksperimen: Anda akan mencoba lebih banyak hal karena overhead untuk melakukannya turun secara signifikan
  • Sintaks yang umum: untuk semua perbedaannya, Anda akan sulit ditekan sebagai programmer C untuk tidak nyaman di dalamnya dalam beberapa jam
  • Pemisahan logika gim yang lebih baik menjadi "engine": engine Anda menjadi penyedia layanan yang harus mengekspos API yang layak ke klien Lua. Hambatan bahasa membuat Anda lebih memikirkan hal itu, alih-alih hanya menjangkau di sana dan mengutak-atik variabel anggota

Cons

  • Manajemen memori Lua tidak ideal untuk game. Anda mengatasinya, Anda tidak menyukainya
  • Lua debugging sangat buruk. Anda harus bekerja untuk meningkatkan pengalaman
  • Menyimpan data di Lua berarti Anda harus melakukan debug di Lua: memeriksanya dari C pada awalnya akan sulit
  • Lua memiliki jumlah pemotretan yang bagus dalam sintaksis kaki, seperti semua variabel menjadi global secara default
  • Lua adalah bahasa pemrograman, sama seperti bahasa lainnya. Jangan berharap non programmer berubah secara ajaib menjadi programmer hanya karena Anda menghapus kompiler
  • Menjadi ahli dalam mengintegrasikan dan mendukung Lua adalah pekerjaan besar. Jangan berharap itu langsung keluar dari kotak. Adalah adil untuk berasumsi bahwa Anda benar-benar harus mengamortisasi biaya ini selama beberapa permainan

Final, personal, vonis: jika Anda membangun gim berukuran layak dan belum memiliki bahasa scripting, dapatkan Lua. Itu akan sia-sia.


1

Garry's Mod adalah salah satu contoh game yang menggunakan Lua dan C ++. Mereka menggunakan Lua untuk semua mod, yang membuatnya lebih mudah bagi orang untuk membuatnya. C ++ digunakan untuk semua internal. Satu-satunya con yang bisa saya pikirkan adalah fakta bahwa Lua tidak secepat C ++.

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.