Godot: C# sebagai bahasa skrip

Menambahkan lebih banyak fitur ke GDscript akan menjadi cara yang lebih baik untuk mendekati skrip menurut saya

Bagi saya, alasan utama memilih Godot daripada mesin game lain adalah skema skrip yang disederhanakan. Godot tidak menawarkan untuk belajar bahasa pemrograman baru. Ia menawarkan untuk mempelajari Godot dan bahasa skripnya sebagai alat gabungan untuk pengembangan game. Ini adalah pendekatan yang tidak terlalu mengintimidasi daripada menawarkan pendatang baru untuk belajar C++ atau bahasa pemrograman lain untuk skrip.

Terima kasih telah membuka masalah ini, saya pikir ini adalah topik di mana ada perbedaan besar antara pilihan terbaik yang rasional dan apa yang akan diminta oleh mayoritas.

Alasan terpenting mengapa ada lebih dari satu mesin adalah karena selain faktor satu dimensi seperti kinerja dalam tugas tujuan umum atau aksesibilitas antarmuka, ada faktor multidimensi seperti kinerja untuk situasi tertentu (tidak ada pemenang yang jelas jika Anda membandingkan mesin dioptimalkan untuk game 3d dan satu dioptimalkan untuk game 2d) atau kegunaan untuk kelompok pengguna tertentu (antarmuka yang ramah pemula biasanya harus menyembunyikan fungsi lanjutan).
Jadi untuk menemukan tempat di antara mesin lain, mesin harus memilih "filsafat".

Sekarang bahasa scripting adalah bagian integral dari mesin, jadi filosofi bahasa harus sesuai dengan filosofi mesin, atau setidaknya tidak boleh bertentangan.

Jadi apa filosofi Godot? Mari kita lihat beberapa faktanya:

• Dibandingkan dengan Godot, setiap mesin utama lainnya membengkak.
  Unduhan Godot lebih kecil dari 20MB, seluruh "instalasi" adalah satu yang dapat dieksekusi yang ukurannya kurang dari 50MB. Lumberyard di sisi lain memiliki ukuran unduhan awal sekitar 5,5GB, saat ini folder instalasi saya berukuran besar 15,3GB. Alasan utamanya adalah filosofi Amazon tentang dependensi. Unduhan awal itu berisi 10,5 GB gambar bawaan dari 42 dependensi, dan jika Anda telah bekerja dengan layanan web Amazon sebelum Anda mengetahui bahwa AWS SDK tidak jauh berbeda dalam aspek itu, jadi ini bukan masalah kebutuhan atau kemampuan, ini masalah pilihan. Misalnya sementara Lumberyard menyertakan boost dan Lua, Godot berisi versinya sendiri dari container STL yang paling penting dan menggunakan GDScript daripada lua, yang menjaga ukurannya tetap kecil, menghilangkan dependensi dan membuat kode lebih mudah dibaca dan diakses.
• Kode sumber Godot sangat mudah diakses.
  Itu dimulai dengan pilihan sistem build (SCons) yang menggunakan python sebagai bahasa build. Sebagian besar proyek lain menggunakan sistem build yang ada dengan bahasa build berpemilik atau menulis sistem build miliknya sendiri, yang keduanya berdampak negatif pada keterbacaan kode build.
  Kode sumber itu sendiri juga di atas rata-rata dalam aspek itu. Saya membutuhkan waktu yang hampir bersamaan untuk mengetahui cara menulis satu simpul Unreal Blueprint di C++ karena saya perlu menulis kode untuk permintaan tarik pertama saya ke Godot. Itu tidak berarti bahwa kode C++ Unreal tidak dapat dibaca, hanya saja tidak sebersih Godot karena menggunakan lebih banyak makro dan mengharuskan pengguna untuk memahami lebih banyak kode proyek default Unreal daripada Godot.
• Godot mempromosikan prinsip KISS dan OO.
  Untuk mengilustrasikannya, mari kita lihat beberapa objek sederhana di Unity. Konsep pertama yang Anda hadapi di Unity adalah GameObjects dengan komponen yang terpasang. "komposisi daripada pewarisan" seperti yang sering disebut (saya lebih suka formulasi Michael J. Dickheiser "Penahanan versus Warisan" dari "C++ untuk Pengembang Game" yang tidak terdengar seperti seruan perang dan mempromosikan refleksi pada topik) adalah pola yang sukses karena fleksibilitas yang ditawarkannya. Fleksibilitas itu ada harganya. Jika semua yang ada di game Anda adalah GameObject, Anda tidak bisa benar-benar mendapatkan referensi ke "pemain", karena tidak ada pemain, hanya ada GameObject yang mungkin atau mungkin tidak memiliki komponen pemain yang terpasang (atau lebih tepatnya beberapa komponen yang membuat naik pemain).
  Pengembang Unity melihat masalah yang sama, terkadang Anda hanya ingin membuat Button, bukan GameObject dengan komponen Button. Jadi yang mereka lakukan adalah: mereka mengizinkan Anda membuat "Tombol" melalui antarmuka editor yang sebenarnya membuat GameObject dengan komponen Button yang terpasang. Selain itu, mereka mengarahkan anggota GameObject yang paling penting melalui setiap Komponen, sehingga sekarang Anda dapat menggunakan referensi ke Tombol sama seperti Anda menggunakan referensi ke GameObject. Anda dapat meminta Button untuk posisinya, Anda dapat menanyakan daftar komponennya - meskipun Button sebenarnya adalah sebuah komponen, bukan objek yang dilampirkannya.
  Jadi sekarang kita memiliki campuran dari dua cara paling populer untuk menggambarkan dunia game - berdasarkan komposisi dan objek biasa. Tetapi ketika Anda melihat proyek pemula (dan bahkan beberapa proyek lanjutan), Anda akan menemukan bahwa Unity juga memfasilitasi cara ketiga untuk menafsirkan dunia game: pemrograman prosedural.
  Dalam Unity, setiap objek selalu menjadi bagian dari "adegan". Tidak seperti di Godot istilah itu menggambarkan bagian atas permainan (disclaimer: sekarang Unity memiliki SceneManager yang duduk di atas layar, tapi poin saya masih valid), artinya jika musuh ingin menembak pemain itu bisa saja cari adegan saat ini untuk pemain dan berinteraksi dengannya. Itulah ide inti dari pemrograman prosedural - Anda memiliki urutan perintah yang mengubah keadaan lingkungan tanpa memperhatikan kepemilikan. Tentu saja secara teknis itu masih pemrograman berorientasi objek, tetapi karena setiap objek dapat diharapkan menjadi bagian dari adegan yang sama, Anda dimungkinkan untuk menulis kode yang berperilaku seperti kode global. Misalnya jika Anda ingin membuat instance objek, yang harus Anda lakukan adalah memanggil "Instantiate(templateObject)" dan salinan templateObject akan dipakai dan ditambahkan ke TKP. Tidak perlu menanyakan adegan mana yang akan ditambahkan objek karena selalu ada satu adegan di mana semuanya saat ini menjadi bagiannya.
  Jadi Unity mempromosikan campuran komposisi, pemikiran berorientasi objek dan pemrograman prosedural.

Godot di sisi lain mempromosikan pemikiran berorientasi objek seperti misalnya setiap objek dalam game Anda dapat dibangun sebagai adegannya sendiri. Adegan-adegan itu dapat dimulai sendiri, memungkinkan Anda untuk mengujinya, mengubahnya sendiri, dll. Itu pada gilirannya mengharuskan Anda untuk membangun adegan itu dengan cara yang tidak memerlukan akses lingkungan. Misalnya, jika musuh ingin berinteraksi dengan pemain, akan lebih memungkinkan untuk menggunakan sinyal untuk memberi tahu adegan yang mendasari bahwa interaksi diminta atau hanya meminta adegan untuk memberi musuh referensi ke pemain. Anda masih dapat mencari adegan permainan untuk pemain, tetapi jika Anda melakukan itu, adegan musuh tidak akan dapat berjalan sendiri, sehingga desainnya juga tidak sesuai dengan alatnya.

Jadi bagaimana ini membuat perbedaan mengenai pilihan bahasa scripting?
C# adalah untuk bahasa apa Unity adalah untuk mesin. Filosofi C# selalu bahwa jika beberapa fitur akan lebih baik jika ditambahkan ke dalam bahasa. Lihat saja daftar fitur yang ditambahkan pada setiap versi: https://en.wikipedia.org/wiki/C_Sharp_ (bahasa_pemrograman)#Features_added_in_versions
Sekarang Anda mungkin berpendapat bahwa memiliki fitur bukanlah sesuatu yang buruk, bukan? Anda tidak harus menggunakannya, tinggalkan saja jika Anda tidak menyukainya. Sayangnya itu tidak berlaku untuk sebuah bahasa. Dengan pentingnya internet saat ini, bahasa bukan lagi alat, melainkan budaya. Cepat atau lambat Anda harus mencari bantuan di Google, Anda akan menggunakan modul atau objek yang dibuat oleh orang lain, Anda akan menggunakan fitur baru yang dibuat oleh komunitas ke dalam mesin, dan cepat atau lambat itu akan mengharuskan Anda untuk menggunakan fitur bahasa yang tidak pernah Anda maksudkan. menggunakan.
Juga jika Anda bekerja dalam tim, Anda akan belajar menghargai penggunaan bahasa yang mempromosikan gaya pengkodean umum dan tidak menawarkan lusinan cara untuk menulis kode yang sama.

Sekarang Anda mungkin bertanya-tanya apakah saya bermaksud mengatakan bahwa bahasa dengan lebih sedikit fitur selalu lebih baik daripada bahasa dengan lebih banyak fitur. Tentu saja tidak demikian. Mari kita bandingkan bagaimana Java memecahkan masalah.
C# memungkinkan Anda untuk menulis kode yang tidak dikelola. Cukup gunakan kata kunci yang sesuai dan Anda dapat menggunakannya langsung di file yang sama. Ini juga memungkinkan Anda untuk menulis kode fungsional menggunakan LINQ, yang berbunyi seperti kode SQL dan berperilaku seperti kode fungsional. Untuk memahami sepenuhnya apa satu file yang Anda mungkin perlu tahu cukup banyak tentang paradigma pemrograman.
Jika Anda menulis Java, Anda juga dapat menggunakan pemrograman fungsional, Anda hanya perlu menulisnya ke file terpisah, menggunakan kompiler yang berbeda dan menyebutnya "pemrograman Clojure". Jika Anda lebih suka menggabungkan pemrograman berorientasi objek dan fungsional, Anda dapat menyebutnya "pemrograman Scala". Bagian yang penting adalah Anda masih menulis kode untuk JVM yang dapat dengan mudah berinteraksi dengan kode dari bahasa JVM lain.
Bahasa .NET memiliki kemampuan yang sama, hanya saja tidak digunakan dalam filosofi C#. Mereka bisa saja memutuskan untuk tetap berpegang pada satu atau dua paradigma pemrograman di C# dan membuat bahasa baru untuk menambahkan paradigma baru, tetapi sebaliknya mereka menggunakan "satu bahasa untuk menaklukkan semuanya" - yang benar-benar baik-baik saja, sangat bagus untuk dimiliki bahasa seperti itu. Anda hanya harus menyadari filosofi itu dan pilihan yang Anda miliki sebagai seorang programmer.

Singkat cerita: dari semua bahasa yang kami miliki, saya pikir C# paling cocok untuk Godot. Ini cocok secara alami untuk Unity, tetapi jika Anda memiliki semua opsi itu, lalu mengapa memilih bahasa yang mempromosikan pencampuran-dan-pencocokan paradigma dalam mesin yang mempromosikan prinsip-prinsip OO yang bersih dan pemrograman KISS di setiap bagiannya?

Jadi jika Anda berpikir bahwa C# akan menjadi tambahan yang bagus untuk Godot maka saya TIDAK setuju dengan Anda - saya hanya mengatakan bahwa ada alternatif yang lebih baik, yang harus dievaluasi terlebih dahulu dan akan segera dilupakan begitu C# diimplementasikan.

@hubbyist

Menambahkan lebih banyak fitur ke GDscript akan menjadi cara yang lebih baik untuk mendekati skrip menurut saya

Itu bisa terjadi pasti, saya tidak berpikir itu tidak sesuai dengan proposal lain.

Bagi saya, alasan utama memilih Godot daripada mesin game lain adalah skema skrip yang disederhanakan. Godot tidak menawarkan untuk belajar bahasa pemrograman baru. Ia menawarkan untuk mempelajari Godot dan bahasa skripnya sebagai alat gabungan untuk pengembangan game. Ini adalah pendekatan yang tidak terlalu mengintimidasi daripada menawarkan pendatang baru untuk belajar C++ atau bahasa pemrograman lain untuk skrip.

Tapi Godot sudah bisa digunakan dari C++, jadi tidak ada yang benar-benar berubah (asalkan GDScript disimpan) kecuali coding di C++ akan dipermudah bagi mereka yang ingin melakukannya (saat ini menulis modul membutuhkan kompilasi semua Godot, dan itu tidak terintegrasi ke dalam alur kerja).

@Warlaan analisis yang bagus. Jika Anda membaca posting saya, saya juga tidak setuju dengan C# menjadi pilihan yang baik untuk Godot, itu sebabnya saya mengusulkan untuk memperluas kemampuan C++ yang sudah ada untuk memungkinkan penggunaannya sebagai bahasa skrip, dengan GDScript tetap menjadi bahasa default untuk sebagian besar pengguna.

Pengguna seharusnya dapat menulis cukup banyak dalam GDScript, namun tidak masuk akal untuk berpikir bahwa game besar akan ditulis dalam GDScript. Menurut saya, tidak ada yang menghalangi Godot cocok untuk game-game besar kecuali performa GDScript, karena engine-nya didesain dengan sangat baik dan performanya sudah cukup bagus (dan Vulkan mungkin akan membuatnya lebih baik lagi).

Menurut pendapat saya, kinerja tidak menarik bagi sebagian besar pengguna Godot, tetapi dapat membawa lebih banyak profesional ke Godot, yang berarti lebih banyak kontribusi yang berarti Godot lebih baik untuk semua orang.

@paper-pauper Saya mengerti bahwa kita berada di pihak yang sama. Ketika saya menulis "jika Anda berpikir bahwa C# akan menjadi tambahan yang bagus" saya sedang berbicara "Anda, pembaca anonim", bukan Anda secara pribadi. ;-)
Dan ya, bahasa skrip baru apa pun akan menguras perhatian dari GDScript. Saya ragu komunitas akan menangani lebih dari satu bahasa, cepat atau lambat beberapa fitur tidak akan tersedia atau rusak dari salah satu dari mereka bahkan mungkin sampai salah satu bahasa dihapus.

Saya juga setuju bahwa satu-satunya masalah nyata di sini adalah waktu kompilasi C++ dan kinerja GDScript.
Argumen bahwa orang sudah tahu C # benar-benar salah. Saya telah bekerja secara profesional dengan C# selama sekitar 4 tahun sekarang (terutama bekerja dengan C++ dan SQL) dan satu hal yang saya pelajari saat itu adalah kemungkinan besar saya tidak akan pernah bisa mengatakan bahwa saya benar-benar tahu bahasa itu. Lagi pula dengan C# 6 dan proposisi untuk 7 jumlah fitur masih bertambah.
Jadi ketika kita berbicara tentang "mengetahui C#" yang sebenarnya bisa kita rujuk adalah mengetahui sintaks paling dasar yang bahkan pemula terburuk sekalipun harus dapat mempelajarinya kembali dalam beberapa hari. Saya baru-baru ini mengadakan kuliah tentang mesin permainan yang berbeda untuk kelas desainer game yang secara eksklusif menggunakan Unity sebelumnya dan tidak ada dari mereka yang berkomentar buruk tentang sintaks GDScript sementara sebenarnya beberapa yang telah menyerah pada pemrograman sekarang termotivasi lagi.

Jadi ya, solusi yang mempercepat GDScript dan membuat C++ tidak terlalu rumit untuk dikompilasi dan digunakan akan menjadi favorit saya juga.

Banyak orang yang "tahu" C# tidak menggunakan banyak fitur yang membuatnya berbeda dari Java. Lihat saja segudang skrip Unity yang tidak jauh dari subclass.

Untuk alasan ini saja, saya sangat skeptis tentang keuntungan praktis yang akan diberikan C#. Mereka bagus dalam banyak konteks, hanya saja bukan pengembangan game. Selain itu, C++1x sudah menawarkan banyak hal (termasuk inferensi tipe, iterator, dan beberapa alat fungsional dasar) tanpa biaya tambahan.

Juga, mungkinkah overhead yang dibawa oleh CLR (atau bahkan JVM) dapat membuat Godot melakukan _lebih buruk_, meskipun saya melihat beberapa keuntungan dalam menggunakan pengumpul sampah JVM (adakah yang tahu lebih banyak tentang manajemen memori Godot)?

Saya membaca di forum tentang orang yang tidak menggunakan Godot karena GDScript. Saya pikir itu berpikiran tertutup, karena tidak ada yang salah tentang itu kecuali kenyataan bahwa ia memiliki pilihan perpustakaan yang buruk, yang saya coba atasi di tiket lain, #3943, dengan menyarankan solusi yang tidak memiliki overhead dan lintas platform mendukung.

Tanpa harus mengimplementasikan C++ JIT melalui LLVM, ada solusi yang berjalan pada kode asli dan tidak memerlukan mengutak-atik sumber Godot: tautan dinamis.

Yang pertama akan memungkinkan kode asli tanpa harus mengkompilasi ulang Godot dari awal: Anda cukup mengompilasinya sebagai file .so dan kemudian menambahkannya ke jalur pemuatan Anda, lalu menggunakannya dari GDScript tanpa overhead (karena itu semua panggilan fungsi).

Ini seharusnya sangat mudah dilakukan (melalui libdl?) Tetapi sejauh yang saya mengerti itu tidak dilakukan karena masalah lintas platform.

Juga, ada ide untuk mengkompilasi GDScript ke C++, seperti yang dilakukan ENIGMA dengan bahasanya. Ini tidak mudah, tetapi jelas menawarkan kinerja terbaik.

adakah yang tahu lebih banyak tentang manajemen memori Godot?

Dari dokumen :

Jika sebuah kelas mewarisi dari Referensi, maka instance akan dibebaskan saat tidak lagi digunakan. Tidak ada pengumpul sampah, hanya penghitungan referensi sederhana. Secara default, semua kelas yang tidak mendefinisikan pewarisan memperluas Referensi. Jika ini tidak diinginkan, maka sebuah kelas harus mewarisi Object secara manual dan harus memanggil instance.free(). Untuk menghindari siklus referensi yang tidak dapat dibebaskan, fungsi referensi lemah disediakan untuk membuat referensi lemah.

Hanya untuk dicatat...

Keuntungan utama dari GDscript adalah bahwa itu adalah bahasa yang sepenuhnya di bawah kendali Reduz dan pengembang lainnya, cara kerjanya untuk pengembang Godot tidak bergantung pada tim eksternal dan karena itu dapat dikembangkan dengan cara yang khusus untuk desain mesin dan memiliki apa yang diminta pengguna.

Hal lain adalah bahwa sementara GDscript bukan bahasa kinerja tinggi yang nyata saat ini, kemungkinan ada banyak area di mana kinerja dapat sangat ditingkatkan sambil mempertahankan kesederhanaan dan sifat pengetikan dinamisnya.

Lalu ada fakta bahwa GDscript tidak memerlukan pengetahuan kompilasi apa pun dan bahwa Anda tidak memerlukan apa pun di luar editor bawaan Godot (yang membuat alur kerja bagus dan rapi, belum lagi mudah dan cepat).

Sekedar pertanyaan, bagaimana cara kerja juru bahasa GDscript secara internal? Parsing setiap baris saat runtime seperti bahasa Basic lama atau apakah itu mengubah seluruh skrip menjadi tabel bytecode kemudian menjalankan bytecode?

@RebelliousX

https://github.com/godotengine/godot/blob/master/modules/gdscript/gd_compiler.cpp
https://github.com/godotengine/godot/blob/master/modules/gdscript/gd_parser.cpp

Saya tidak berpikir ada bahasa serius yang berfungsi seperti BASIC lagi! :)

Hai!
Berikut adalah sejarah GDScript:
//////////////////////////////////////
Sejarah
Awalnya, Godot dirancang untuk mendukung beberapa bahasa scripting (kemampuan ini masih ada sampai sekarang). Namun, hanya GDScript yang digunakan saat ini. Ada sedikit sejarah di balik ini.

Pada hari-hari awal, mesin menggunakan bahasa scripting Lua. Lua cepat, tetapi membuat binding ke sistem berorientasi objek (dengan menggunakan fallback) rumit dan lambat dan membutuhkan sejumlah besar kode. Setelah beberapa percobaan dengan Python, ternyata juga sulit untuk disematkan.

Bahasa scripting pihak ketiga terakhir yang digunakan untuk game yang dikirimkan adalah Squirrel, tetapi juga dihapus. Pada saat itu, menjadi jelas bahwa Godot akan bekerja lebih optimal dengan menggunakan bahasa skrip bawaan, karena hambatan berikut terpenuhi:

• Godot menyematkan skrip di node, sebagian besar bahasa tidak dirancang dengan pemikiran ini.
• Godot menggunakan beberapa tipe data bawaan untuk matematika 2D dan 3D, bahasa skrip tidak menyediakan ini, dan mengikatnya tidak efisien.
• Godot banyak menggunakan utas untuk mengangkat dan menginisialisasi data dari internet atau disk, juru bahasa skrip untuk bahasa umum tidak cocok untuk ini.
• Godot sudah memiliki model manajemen memori untuk sumber daya, sebagian besar bahasa skrip menyediakannya sendiri, yang mengakibatkan upaya duplikat dan bug.
• Kode pengikatan selalu berantakan dan menghasilkan beberapa titik kegagalan, bug yang tidak terduga, dan tidak dapat dipelihara secara umum.

Akhirnya, GDScript ditulis sebagai solusi khusus. Bahasa dan penerjemah untuk itu akhirnya menjadi lebih kecil dari kode pengikat itu sendiri untuk Lua dan Squirrel, dan sama-sama berfungsi. Seiring waktu, memiliki bahasa bawaan telah terbukti menjadi keuntungan besar
////////////////////////////////////

Menurut pendapat saya, c++ bisa menjadi yang terbaik. Ada beberapa solusi seperti:
https://github.com/RuntimeCompiledCPlusPlus/RuntimeCompiledCPlusPlus
Bahkan skrip Angel biasanya bisa seperti runtime yang dikompilasi.
Dalam scripting, saya suka python karena saya selalu menyukai solusi yang menggabungkan permainan dan simulasi ilmiah (python memiliki banyak perpustakaan ilmiah). Jadi saya mengeluh! dalam masalah lain mengapa godot memiliki perpustakaan fisikanya sendiri: https://github.com/godotengine/godot/issues/4217
Ada beberapa masalah tentang bahasa seperti C#: https://github.com/godotengine/godot/issues/2790

Temuan yang bagus, @ alabd14313 - itu akan menyelesaikan hampir sebagian besar masalah, sambil membiarkan GDScript sendirian.

Tentang RCCPP, itu adalah ide yang sangat bagus. Saya pikir jika Godot mendukungnya dalam mode editor dan kemudian menonaktifkannya di build, akan ada kinerja maksimum dan waktu iterasi akan cukup cepat. Saya pernah mendengar mesin lain seperti Unreal Engine melakukan sesuatu yang mirip dengan C++, dan saya pikir itu akan cukup rapi jika Godot mengizinkan pengkodean C++ seperti skrip yang mulus.

Tampaknya penulis tahu barang-barang mereka, karena di halaman ini mereka mencantumkan sebagian besar alternatif untuk pendekatan mereka (termasuk yang saya sebutkan, LLVM JIT).

Saya pikir pendekatan ini paling masuk akal, karena Godot ditulis dalam C++ (dan saya tidak berpikir itu akan pernah berubah, mengingat C++ akan menjadi lebih baik dalam beberapa tahun), ia sudah memiliki C++ API dan C++ yang berfungsi memiliki cukup banyak kinerja maksimum yang diinginkan dengan nol overhead dan tidak akan ada runtime tambahan atau manajer memori. Saya harap para dev akan melihatnya.

Saya agak terkejut menemukan bahwa utas yang afaik ini dimulai sebagai reaksi terhadap proposal untuk menambahkan C# sebagai bahasa skrip belum mengandung satu argumen UNTUK C#, bahkan setelah enam orang menyatakan pendapat mereka.
Mungkin keputusan untuk menambahkan C# tidak direncanakan seperti yang saya duga dari rumor yang saya dengar.

@Warlaan apa yang akan terjadi jika memposting URL ini ke grup facebook? :)

Harap ubah judul menjadi sesuatu seperti "C++ sebagai bahasa skrip".
C++17 memiliki lebih banyak fitur:
http://blog.mattnewport.com/why-c17-is-the-new-programming-language-for-games-i-want/
Saya mengagumi pengembang godot dan berterima kasih atas karya mereka. tapi saya menolak pustaka Box2D/LiquidFun/Bullet. Dengan cara ini pengembang dapat fokus pada pipeline, bukan pada komponen seperti fisika. Dengan C++ mereka dapat fokus pada kinerja, tidak memelihara dan memperbarui gdscript. Secara teoritis RCCPP dapat mengimplementasikan beberapa fitur baru seperti mode alat dengan cara yang lebih baik. Mungkin...

@reduz menyebutkan beberapa bulan yang lalu bahwa dia ingin menerapkan skrip visual, seperti cetak biru yang tidak nyata. Dengan RCCPP alur kerja antara C++ (untuk programmer) dan Visualscripting (untuk desainer level dan seniman) dapat diimplementasikan seperti:
Pengantar Pemrograman C++ di UE4
C++ dan Cetak Biru
Jadi dalam sebuah grup, programmer dapat mengembangkan kelas cetak biru baru untuk seniman dan seniman menggunakan ini daripada langsung coding.

@Warlaan IMHO itu karena banyak pembicaraan C# didorong oleh orang-orang yang ingin Godot menjadi ripoff Unity, tetapi untungnya banyak di sini yang menyadari bahwa Godot adalah miliknya sendiri dan sudah di depan Unity dalam banyak hal dan itu tidak adil untuk membiarkannya terpengaruh oleh masalah yang sama.

@ alabd14313 Saya akan mengubah judul tetapi mungkin lebih baik untuk membuat masalah terpisah dan menyimpan ini demi anak cucu sehingga dapat ditautkan ketika seseorang mengusulkan C # (seperti yang sering terjadi).

Sejujurnya saya ragu dengan visual scriptingnya, tapi kalau bisa diimplementasikan sebagai modul kenapa tidak? Tentu saja, saya pikir memiliki skrip visual (desainer dan pemula), GDScript (orang yang dapat memprogram atau mau belajar) dan C++ (programmer) akan membuat Godot menjadi program yang cukup seimbang yang cocok untuk semua tingkat keahlian, tetapi membuat pengkodean C++ lebih sedikit rumit dan memungkinkan antarmuka yang lebih mudah dengan perpustakaan pihak ketiga harus memiliki prioritas yang lebih tinggi, IMHO, karena dapat membawa banyak pengguna profesional (dan akibatnya, kontributor).

Script visual imho sama sekali tidak cukup halus untuk masuk akal. Ini bagus untuk pemasaran dan berbicara pemula ke dalam pemrograman, tetapi dari pengalaman saya fase pembelajaran di mana pemula lebih suka flowgraphs sangat singkat.
Untuk apa pun kecuali urutan panggilan paling dasar, sistem yang saya tahu (Unreal, Cryengine, Fungus, Stingray) sama sekali tidak membantu. Maksud saya tangkapan layar ini misalnya dari video iklan resmi mesin Stingray. Nah itu yang saya sebut kode spaghetti. Dan contoh resmi di mesin Cry tidak terlihat lebih baik, meskipun Anda dapat mengetahui dari jumlah elemen komentar bahwa banyak upaya dilakukan untuk membuat grafik dapat dibaca, atau lebih tepatnya mencoba.
Jika menurut Anda itu tidak terlalu buruk, izinkan saya mengingatkan Anda bahwa jika Anda melihat kode itu dalam bahasa berbasis teks, setiap baris penghubung yang dimulai di luar layar akan menjadi variabel dengan nama yang (semoga) bermakna.

Grafik aliran agak membantu dalam hal shader / bahan, karena hasil antara dapat ditampilkan, tetapi bahkan di sana sistem sangat menderita dari kenyataan bahwa persamaan pendek seperti
float x = (ab)*(a+b)/(1-(a+b))
dengan mudah mengisi seluruh layar ketika dilakukan sebagai grafik, karena setiap perkalian, jumlah, atau perbedaan adalah simpul dengan dua input dan output. Itu setidaknya 10 node untuk rumus di atas, dan jika Anda tidak ingin menyebabkan kekacauan koneksi, Anda harus menduplikasi a- dan b-node.

Sistem grafik aliran yang kita miliki saat ini (setidaknya yang saya tahu) menghilangkan opsi untuk memberi nilai nama yang bermakna, karena alih-alih memasukkan hasil ke dalam variabel bernama perantara, Anda cukup menghubungkannya ke simpul berikutnya. Itu membuat kode yang mendokumentasikan diri hampir tidak mungkin dan mengharuskan Anda untuk berusaha lebih keras dalam dokumentasi.
Apa yang ditambahkan oleh sistem tersebut adalah opsi untuk menempatkan node di mana pun Anda inginkan, yang menurut pengalaman saya menghasilkan kode yang kurang dapat dibaca lebih sering daripada tidak daripada kode yang lebih mudah dibaca.

Dan tolong jangan bicara tentang grafik aliran seolah-olah itu bukan pengkodean. Mereka sama banyaknya dengan coding seperti bahasa pemrograman lainnya. Mereka tidak sedang mengetik, itu saja.

Skrip visual adalah untuk desainer dan seniman untuk membuat perubahan tanpa harus belajar cara membuat kode. Beberapa seniman juga dapat membuat game interaktif sederhana dengannya. Ini memiliki target di mana itu pasti berguna, hanya saja tidak untuk programmer.

@Warlaan Yah, itu tergantung pada bagaimana Anda mendefinisikan "pemrograman". Tentunya visual scripting mirip dengan mendefinisikan algoritma, jadi tidak jauh dari pemrograman, tetapi pemrograman juga tentang hal-hal lain.

Ada beberapa implementasi yang baik dari pemrograman visual. PureData adalah satu dan juga ada GDevelop , program pembuatan game FLOSS yang cukup bagus (sayangnya tidak lebih populer). Singkatnya, meskipun saya pribadi tidak menyukainya (untuk beberapa alasan yang Anda sebutkan), juga benar bahwa kami berdua dapat memprogram, jadi bagi kami pemrograman visual adalah lambat dan rumit untuk mencapai hasil yang relatif buruk.

Tetap saja, saya setuju dengan @reduz bahwa beberapa orang melihat daya tarik di dalamnya. Mereka bukan orang-orang yang akan berkeliaran di thread seperti ini, tapi mereka juga membuat game. Saya pikir mereka bisa membawa sesuatu ke Godot.

Alasan mengapa diagram alur bekerja dengan baik untuk pengeditan shader adalah karena sangat visual (Anda memiliki node yang memungkinkan Anda memuat gambar, memilih warna, dll... tanpa mengetik jalur file dan nilai secara manual). Anda juga sama sekali tidak takut untuk memastikan sintaksnya benar dan fungsi-fungsinya dieja dengan benar. Juga tidak perlu memikirkan tugas-tugas rumit seperti bagaimana bekerja dengan matriks (semuanya dihitung untuk Anda).

Metodologi Godot untuk pengeditan shader akhirnya menjadi pendekatan yang baik karena memisahkan vertex, fragmen, dan komponen ringan dengan rapi dan juga memberikan panduan yang jelas tentang jenis data apa yang sedang Anda kerjakan (apakah itu informasi normal atau informasi kamera).

Sekarang dengan skrip visual, saya pikir itu bisa berguna bahkan untuk hal-hal yang cukup rumit jika node berada pada level yang cukup tinggi dalam hal mekanisme permainan (mereka melakukan hal-hal yang lebih kompleks dan memiliki beberapa input) dan jika ada node yang memungkinkan Anda untuk menjalankan skrip atau membuat ekspresi/persamaan (yang pada gilirannya dapat digunakan untuk memanipulasi nilai dengan cara yang kompleks). Masalah yang saya lihat dengan sistem node visual lain dari jenis ini adalah bahwa mereka mencoba untuk sedekat mungkin dengan pemrograman literal (yaitu memiliki banyak fungsi tingkat rendah sebagai node yang bertentangan dengan versi nodal dari Batu bata logika Blender atau drag & drop GameMaker).

Tentu, itu masih tidak akan mengizinkan sesuatu yang berbutir halus dan secanggih apa yang dapat Anda lakukan dengan skrip murni, tetapi itu masih dapat digunakan untuk hal-hal seperti jenis objek sederhana dalam permainan (yang tidak memerlukan logika yang sangat kompleks ) atau jika Anda perlu dengan cepat mengeluarkan sesuatu.

Saya setuju bahwa beberapa orang melihat daya tarik di dalamnya, dan saya juga setuju bahwa itu bukan untuk programmer (hanya definisi kami tentang "programmer" yang berbeda ;-) ), jadi saya sarankan kita tinggalkan diskusi di situ karena agak di luar topik.

Fitur lain yang berguna dari C++ adalah tipe statis. Fasilitas "auto" dan "decltype" dapat mendeteksi jenis suatu objek. Editor dan penyelesaian kode bisa lebih mudah. Alih-alih berfokus pada editor kode internal, kita dapat menggunakan IDE eksternal lain. Untuk saat ini saya pikir codelite dan qtcreator memiliki status yang lebih baik dalam penyelesaian kode. Codeblocks memiliki beberapa masalah dengan kata kunci c++11. Eclipse-cdt juga memiliki penyelesaian kode yang baik. Plugin untuk qtcreator adalah ide yang bagus (seperti studio visual tidak nyata dan Unity-Monodevelop). IDE eksternal dapat diidentifikasi dengan jalur sistem dalam pengaturan godot (seperti /use/bin/qtcreator), tidak perlu dikompilasi dan dikemas dengan godot (Tidak seperti paket Unity yang memiliki monodevelop bawaan).
Ada alat lain seperti cppcheck dan valgrind yang memiliki plugin di qtcreator.
Jika Anda ingin melihat pratinjau apa itu RCCPP:
demo

Saya ingin sekali melihat bahasa skrip berbasis C++ untuk Godot, tetapi mengimplementasikan semua fitur C++ akan merepotkan seperti pemrograman template. Harus ada beberapa batasan untuk bahasa skrip (STL) semacam ini dan templat tidak boleh digunakan. Juga RTTI dapat menyebabkan masalah kinerja.

Saya suka GDscript, satu-satunya keluhan saya adalah polusi namespace variabel, ketika berhadapan dengan skrip besar, definisi variabel sebelum ready() bisa menjadi sangat berantakan, dan rentan terhadap bug dalam kode karena berbagi variabel antar fungsi dari file skrip yang sama .

3 sen saya. (uh... akhirnya 20, tapi biarlah...)

Seperti @alabd14313 disebutkan sebelumnya "itu adalah pada titik di mana itu" karena evolusi selama bertahun-tahun yang memimpin godot menjadi bentuk seperti sekarang ini.
Tidak peduli apakah alam melakukan ini atau kita manusia, mengoreksi hal-hal pada saat penciptaan tampaknya menjadi cara terbaik untuk berkembang, dan harus saya akui, berkat ini, saya sangat menikmati Godot apa adanya dan ke mana evolusi membawanya.

Itu memiliki semua bagian yang dibutuhkan.

Node yang dapat digabungkan menjadi objek yang lebih kompleks, disimpan sebagai adegan, kemudian digunakan kembali sebagai objek "sederhana" dalam adegan lain yang mengagumkan dan fitur mega fleksibel, sungguh, hanya dibatasi oleh batas imajinasi dan kreativitas pengguna sendiri.

Mudah digunakan dan dipelajari GDScript, cukup kuat untuk mengontrol semua node dengan cara yang biasa dilakukan oleh para pembuat kode - dengan mengetikkan baris kode.
Selain melakukannya dengan cara yang cepat dan mudah (penyelesaian kode / dokumentasi buildin / tooltips yang berguna di sana-sini) tanpa perlu mengkompilasi, cukup ketik, coba, sesuaikan, dan lagi, poles hingga sempurna.

Menyebarkan ke beberapa platform dengan BENAR-BENAR satu klik (belum lagi ini menyebarkan ke Android melalui wifi/adb, pengeditan hidup, debugging, dll hanyalah sebuah mahakarya seni, tidak ... Lebih dari itu, ini adalah keajaiban!)

Selain itu semua keakraban dengan alat yang biasa digunakan seperti blender dll.
(impor barang dan berfungsi di luar kotak, semuanya ada di mana dan bagaimana seharusnya)

Dan akhirnya, saya akui bahwa kadang-kadang bahkan kreativitas ultra mungkin tidak cukup untuk melakukan sesuatu jutaan kali dalam satu lingkaran dan cocok dalam 1 bingkai. Di situlah hal-hal C masuk. Jika Anda tahu C, membutuhkannya, tidak ada yang menghentikan Anda dari membuat plugin, memiliki simpul kustom dll, yang melakukan persis apa yang diinginkan.

Ia memiliki hampir segalanya, dan pada waktunya, saya yakin akan memiliki semuanya.
(Artinya, hal-hal yang hari ini "belum dilaksanakan" dan seseorang harus melakukannya 'entah bagaimana' atau 'tangan kosong' (baca: gunakan alat eksternal untuk itu) misalnya menyesuaikan sesuatu yang dicurangi 3D dengan cara yang mudah (harus menggunakan blender )

Godot luar biasa dan hal ajaib, sempurna sempurna di jalannya ke mana pun ia pergi.Perlu penyesuaian dan menambahkan hal-hal di sana-sini tapi itu saja.

Skrip visual?
eh. Itu bisa memaksa kita pembuat kode untuk mengubah cara berpikir "sedikit" dengan cara yang tidak biasa, ditambah saya tidak percaya itu bisa sefleksibel dan mudah dibaca seperti kode normal.
Bayangkan Anda coding dan memiliki satu baris sederhana seperti ini ( abc / def ) * ghi
kemudian cara cepat, seperti biasa (?) untuk menyimpan pengetikan, Anda menandai bagian dari sesuatu, tempel di sini, potong di sana, tempel lagi dan dalam 5 detik dan beberapa kali penekanan tombol, berakhir dengan "sederhana" (karena Anda tahu apa yang dilakukannya) satu liner seperti ((((abc/def+((abc/def)_ghi^4))_ghi)+(abc/def_(100))_ghi)+abc)
Sudah biasa, mungkin banyak dari kita yang melakukannya dengan cara yang super cepat.
Sekarang bayangkan melakukannya dengan cara Visual...
Itu bisa mengambil seluruh layar, banyak pekerjaan mouse, dan itu tidak akan terlihat mudah dibaca sebagaimana mestinya.
(tentu saja, liner seperti itu juga tidak terlihat mudah setelah satu tahun tetapi itulah gunanya komentar)

Bagaimana jika seseorang memiliki 100 baris seperti itu satu di bawah yang lain?
Visualy dia bisa mendapatkan lapangan sepak bola untuk menampilkannya. Bagaimana dengan menganalisisnya, mengubahnya, itu berantakan dan sakit kepala yang besar.
Tentu saja pembuat kode dapat melakukan ini karena, ini bukan bahasa yang digunakan, menjadikan seseorang pembuat kode, tetapi cara berpikir tertentu, membuat algoritme, memanipulasi data sebagai bagian kecil dan secara keseluruhan.
Bahasa tidak peduli apakah skrip C, Python, PHP, Java atau Visual hanyalah alat untuk menuliskan pemikiran.
Dan di sini, Imho, pengetikan normal dengan keyboard adalah bentuk paling cepat dan mudah dibaca untuk menuliskannya.
Di sisi lain Jika seseorang tidak dapat membuat kode, apakah Anda mengharapkannya untuk tiba-tiba mengungkapkan kejeniusan algoritmik dan persepsi agar tidak tersesat dalam ide dan representasi visualnya sendiri, mengingat ketika kita memikirkan permainan - kita berbicara tentang sesuatu yang lebih kompleks daripada bashing dua bola satu sama lain dengan fisika.

Jadi untuk siapa sebenarnya Visual Scripting itu?
Untuk membuat hidup coders lebih sulit atau membatasi godot ke level - engine untuk "permainan sederhana" untuk pemula?

Teman-teman, ada diskusi panjang tentang Visual Scripting di #1220. Tolong jangan membahas topik yang sama lagi di sini.

Teman-teman, ada diskusi panjang tentang Visual Scripting di #1220. Tolong jangan membahas topik yang sama lagi di sini.

Sebagian besar posting di sini begitu panjang, mungkin membuat saya tersesat saat membaca.
maaf :santai:

@RebelliousX Bahkan dengan RTTI, C++ masih memiliki kinerja yang jauh lebih baik daripada GDScript. Meskipun memang benar bahwa template bisa menjadi masalah.

Solusi yang diusulkan oleh @reduz di #3936 sudah akan membuat pengkodean dalam C++ cukup sepele - Anda cukup melakukannya dengan editor dan kompiler pilihan Anda dan menautkan ke API Godot. Jika ini diterapkan, bahkan jika skrip dalam C++ akan menyenangkan, itu tidak akan jauh berbeda dari menulis kode dalam C++ dan kemudian memanggilnya dari GDScript, dalam hal kinerja. Singkatnya, saya pikir fokus pada #3936 (yang merupakan solusi sederhana) akan sangat meningkatkan:

• Kinerja (karena menulis bagian dalam C++ akan sangat mudah)
• Ketersediaan perpustakaan pihak ketiga (karena pembungkus dapat didistribusikan dengan lebih mudah, tetapi tidak semudah #3943)
• Userbase dan kontributor (banyak programmer C++ akan mengadopsi Godot)

Kemudian mungkin ada fokus pada pengetikan statis di GDScript dan mengoptimalkan penerjemah (melalui JIT atau dengan mengkompilasi GDScript ke C++), tetapi ini bisa terjadi nanti jika modul penulisan dibuat lebih mudah.

Saya hanya ingin menyebutkan beberapa poin yang telah menyelinap ke dalam diskusi ini tetapi belum dibahas:

• Beberapa dari kita berbicara tentang meningkatkan sistem yang ada (GDScript sebagai bahasa scripting, C++ sebagai bahasa backend) dengan memfasilitasi pengembangan C++ dan meningkatkan kinerja GDScript. Yang lain berbicara tentang menggunakan C++ (atau Java / C# / ...) sebagai bahasa skrip. Tampaknya tidak ada perbedaan nyata antara mengaktifkan pengembangan C++ yang cepat dan menjadikannya bahasa skrip, tetapi saya dengan senang hati akan menjelaskan bagaimana saya telah mengalami dan mengamati efek negatif dari bahasa skrip yang kuat pada kualitas desain game. Dan kecuali ini menjadi topik diskusi, saya akan dengan senang hati melakukannya di forum atau di tempat lain yang tidak membajak utas ini.
• @RebelliousX : Ketika Anda berbicara tentang "ruang nama variabel", "skrip besar" dan "berbagi variabel antar fungsi" sepertinya Anda belum sepenuhnya memahami sifat berorientasi objek dari GDScript (jangan tersinggung). Setiap file GDScript adalah sebuah kelas, jadi bentrokan nama antara variabel (anggota) harus terjadi sesering dalam bahasa berorientasi objek lainnya. Anda tidak berbagi variabel antar skrip, Anda menulis beberapa fungsi yang dapat mengakses status objek yang melingkupinya.

@Warlaan Tentang poin pertama, saya pikir Anda bisa memposting di sini, karena ini terkait dengan topik.

@Warlaan jangan tersinggung. Saya tahu bahwa GDscript adalah kelasnya sendiri dan saya tahu bahwa variabel seperti variabel anggota normal di kelas C++, tetapi sepertinya Anda melewatkan poin saya sepenuhnya. Anda akan memahaminya ketika Anda memiliki skrip dengan lebih dari 1000 baris kode. Yang saya inginkan adalah referensi atau pointer, alih-alih membuat banyak sekali variabel anggota, cukup berikan mereka di antara fungsi anggota. Lebih aman seperti itu.

Saya suka C#, tapi saya melihat pro dan kontra.

Kelebihan:

• Dukungan perkakas yang baik (akui saja, apakah Anda akan membuat kode dalam C # tanpa Visual Studio atau MonoDevelop?)
• Cocok untuk proyek skala besar
• Banyak digunakan dan matang, ada banyak utas dukungan di internet.
• Performa bagus, tradeoff antara C++ dan bahasa skrip saat menjadi lintas platform
• Relatif mudah untuk mengikat ke C++

Kontra:

• Sampah dikumpulkan: proyek game skala besar juga perlu menerapkan strategi alokasi untuk mencegah tendangan GC terjadi terlalu sering, ini bisa buruk
• Tidak terintegrasi seperti GDScript (penyelesaian jalur node? Variabel anggota skrip pada node? Model alokasi memori?)
• Runtimenya berat, dan .NET framework bahkan lebih. Seperti di Unity, perpustakaan standar harus dipetakan ulang ke Godot.
• Bukan yang paling cocok untuk skrip yang sebenarnya, dalam arti menyelesaikan pekerjaan dengan cepat dan kotor. C# lebih bertele-tele dan membatasi daripada GDScript.
• Belum ada pedoman mengenai pengembangan Godot. Bahasanya generik dan dapat melakukan banyak hal, dan seperti yang dikatakan Warlaan, pengembang memiliki budaya yang berbeda (Anda bisa saja memiliki pembuat kode WPF yang mencoba Godot dan bertanya-tanya mengapa tidak ada cara MVVM untuk membuat GUI :p)

Sebagian besar ini juga berlaku untuk Jawa.
Mungkin saya lupa hal-hal lain karena sudah larut di sini.

Ok, ini pengalaman saya tentang bahasa scripting kaya fitur resp. kurangnya bahasa scripting tergantung pada definisi Anda tentang "bahasa scripting". Saya akan mencoba untuk tetap pendek. ;-)

Saya telah bekerja sebagai dekan untuk teknik di School4Games di Berlin, Jerman selama beberapa tahun sekarang. Di sekolah itu kami tidak memiliki fakultas untuk desain game "murni", tetapi kursus desain game kami disebut "pengembangan game" dan mencakup pelajaran pemrograman yang cukup untuk mengajari desainer game cara mengembangkan prototipe mereka sendiri dan untuk memahami kemungkinan dan batasannya. dari arsitektur perangkat keras dan perangkat lunak umum.
Jadi siswa yang saya ajar adalah orang-orang yang terkadang memiliki minat yang tinggi dalam pemrograman tetapi tidak ada yang melamar menjadi seorang programmer.
Setiap semester mereka harus membentuk tim dan mengembangkan satu permainan. Karena hampir semua calon pemberi kerja calon siswa kami menggunakan Unity, telah menjadi persyaratan untuk dua semester pertama untuk bekerja dengan mesin itu.

Sekarang mari kita langsung ke poin mengenai efek bahasa scripting:
Para siswa ini dibagi menjadi dua kelompok. Salah satu yang mencoba untuk menghindari pemrograman atau kehilangan harapan (artinya mereka akan menghadiri kelas pemrograman tetapi tidak akan meminta bantuan jika mereka mengalami masalah tetapi diam-diam menyerah) dan yang menyelam ke dalam pemrograman begitu dalam sehingga mereka langsung melompat ke topik yang biasanya Anda tidak akan khawatir saat menulis prototipe game. Misalnya salah satu siswa saya dari semester pertama baru-baru ini menerbitkan tutorial tentang cara menulis Singleton di C# menggunakan generik sehingga Anda dapat mengubah kelas komponen Unity menjadi tunggal dengan mewarisi dari kelas generik dari tutorial. Hal yang menarik bukanlah karena ia mampu menulis artikel itu, lagi pula ia tentu saja mendapat bantuan dari guru-gurunya dan ada cukup banyak sumber tentang topik tersebut di internet. Hal yang menarik adalah bahwa seorang siswa yang mendaftar untuk kursus yang sebagian besar berfokus pada desain game daripada pemrograman akan tertarik pada topik pemrograman tertentu. Kode dari tutorial itu tidak akan pernah berubah karena perubahan desain game, ini adalah konstruksi pemrograman murni.
Hal serupa terjadi dengan siswa yang berbeda yang menggunakan kelas yang sama untuk mengangkut informasi dari satu adegan permainan ke yang lain. Dia cukup terkejut ketika saya menunjukkan kepadanya bahwa dia dapat melakukan hal yang sama dengan anggota statis publik, yang menunjukkan bahwa dia mencari solusi yang lengkap dan rumit sebelum dia benar-benar memahami semua elemen dasar di dalamnya.

Jadi, jika Anda melewatkannya, ini meringkas teks sejauh ini: meskipun dimungkinkan untuk menulis kode sederhana dalam bahasa yang kaya fitur, saya telah mengamati beberapa kali bahwa orang cenderung mengabaikan solusi sederhana di mana ada alternatif yang rumit.

Ini bukan hanya karena prasangka. Tentu, itu mungkin salah satu faktornya. Jika Anda melihat bahwa kode dalam tutorial, contoh, atau kelas lain dalam proyek Anda terlihat rumit, Anda mungkin menyimpulkan bahwa milik Anda juga akan terlihat rumit. Tapi saya pikir alasan sebenarnya adalah bahwa dalam pemrograman masuk akal untuk mencoba membuat kode yang tahan kesalahan. Merupakan keinginan alami untuk menulis kode yang tidak rusak segera setelah digunakan di tempat yang berbeda atau segera setelah menerima masukan yang berbeda. Dan itu mengharuskan Anda untuk mencari tahu opsi apa yang mungkin harus Anda persiapkan.
Saya pikir perasaan harus memeriksa setiap kemungkinan inilah yang membagi siswa saya menjadi mereka yang tenggelam dalam sejumlah besar fitur C# dan mereka yang langsung terjun dan kehilangan fokus dalam bahasa.

Zylann menyebut frasa "cepat dan kotor". Kita sering menggunakan kedua istilah tersebut sebagai sebuah frase, tetapi jika dipikir-pikir itu sebenarnya adalah dua faktor yang berbeda. Apakah mungkin atau tidak untuk membuat kode dengan cepat cukup terukur. Di sisi lain apakah kode yang dihasilkan kotor atau tidak tergantung pada banyak faktor, yang paling penting adalah jumlah fitur yang dimiliki bahasa yang digunakan.
Misalnya membuat node tingkat atas dan menggunakannya sebagai singleton di Godot benar-benar baik-baik saja karena GDScript tidak menawarkan fitur yang diperlukan untuk mengimplementasikan pola dengan cara yang sama seperti yang Anda lakukan dalam bahasa seperti C#. Tentu, menggunakan fitur autoload akan lebih baik karena itulah tempat pertama pengembang lain akan mencari lajang (dan itu membuat sintaksnya sedikit lebih bagus), tetapi jika sebuah tim memutuskan untuk mengimplementasikannya seperti itu, saya ragu akan ada banyak argumen. Bayangkan di sisi lain bahwa seseorang mengimplementasikan singleton di Unity hanya dengan menambahkan anggota statis publik ke kelas. Ini sama cepatnya, dengan cara bahkan hal yang sama (keduanya adalah instance kelas di tempat paling umum), tetapi karena C# memang menawarkan opsi untuk menjadikan konstruktor pribadi, akses singleton melalui properti dengan inisialisasi malas dll. diharapkan Anda melakukannya, jika tidak, kode akan dianggap sangat kotor jika tidak rusak.

Sekarang fakta bahwa siswa desain game mendalami topik seperti ini mungkin merupakan petunjuk yang tidak jelas tentang maksud saya, tetapi saya pikir saya dapat menggambarkannya dengan lebih baik lagi dengan membicarakan situasi di pekerjaan pertama saya di pengembang MMO F2P besar. Tim yang saya ikuti adalah salah satu pengembang game paling berpengalaman di Jerman. Kepala pengembangan mereka telah menciptakan mesin internalnya sendiri sejak 1995 dan meskipun mereka baru saja dibeli oleh perusahaan lain, mereka masih merupakan salah satu pengembang paling sukses saat itu.
Pada saat saya bergabung dengan tim, mereka menggunakan versi ketiga dari mesin internal, yang tidak memiliki bahasa skrip. Mereka telah menerapkannya sebelumnya tetapi dalam versi mesin itu mereka kembali ke tidak memiliki bahasa skrip karena ada masalah dengan kualitas kode yang diberikan oleh perancang game. Dengan kata lain karena bahasa skrip terlalu kuat, keputusan dibuat untuk menggeser penghalang antara programmer dan desainer game ke titik di mana desainer game hanya akan mengedit level dan mengubah pengaturan di lembar konfigurasi sementara programmer melakukan semua pemrograman - dalam retrospeksi saya memperhatikan bahwa ini adalah situasi yang hampir sama dengan siswa saya (dan tampaknya banyak studio profesional yang bekerja dengan Unity berakhir).
Sekarang mengapa saya peduli? Jika ini terjadi berulang kali, bukankah itu membuktikan bahwa itu adalah cara yang berhasil untuk bekerja? Jawaban saya adalah tidak, karena ada masalah, baik teknis maupun dalam desain game, yang dapat dengan mudah dijelaskan oleh fakta bahwa komunikasi antara programmer dan desainer game direduksi menjadi tugas menulis di satu arah dan mengekspos pengaturan di sisi lain. Dari sudut pandang desainer game, fitur-fitur tersebut menjadi kotak hitam yang dapat diaktifkan dan dinonaktifkan, tetapi di sisi tim itu tidak ada orang yang dapat mendiskusikan atau bahkan membuat prototipe alternatif.
Para programmer di sisi lain didorong hampir secara alami ke dalam mentalitas backend. Mentalitas KISS "cepat dan kotor" telah hilang, karena tidak seorang pun dari kita yang bisa meramalkan bagaimana fitur yang kita buat akan digunakan. Saya ingat dengan jelas bagaimana database rusak karena seorang desainer game telah menerapkan perburuan telur paskah yang menyebabkan inventaris tumbuh jauh lebih besar daripada sebelumnya. Itu adalah terakhir kalinya saya berasumsi bahwa persyaratan fitur mungkin akan tetap sama.

Itu sebabnya saya berpikir bahwa memiliki bahasa scripting berfitur rendah sebagai area yang ditentukan untuk kode game sangat penting dan mengapa saya berpikir bahwa tidak memilikinya memiliki efek buruk pada desain game.

• Menulis kode cepat berarti mengabaikan fitur yang mengubahnya menjadi kode "cepat dan kotor".
• Keinginan untuk menulis kode yang bersih membagi para pengembang menjadi mereka yang tidak membuat kode dan mereka yang menghabiskan lebih banyak waktu untuk memikirkan pengkodean dan lebih sedikit waktu tentang permainan.
• Itu pada gilirannya membagi seluruh tim menjadi satu bagian yang bekerja pada desain game tanpa mengetahui basis kode dan satu yang bekerja pada fitur tanpa mengetahui bagaimana mereka akan digunakan, tidak meninggalkan siapa pun yang dapat membuat fitur mesin berdasarkan game merancang atau menyarankan desain game berdasarkan fitur yang dapat dengan mudah diimplementasikan.

Tidak mungkin membayangkan pengembangan game hari ini tanpa menggunakan perpustakaan kelas yang telah dibuat sebelumnya, lagipula itulah yang membuat mesin dengan perangkat seperti Godot, Unity, Unreal dll. begitu sukses. Tetapi perbedaan antara semua mesin ini adalah di mana garis antara pemrograman dan desain game ditarik dan seberapa banyak celah yang dibuat antara kedua belah pihak.
Dan berdasarkan pengamatan saya, saya pikir pilihan bahasa scripting adalah salah satu faktor terpenting yang dapat menciptakan celah atau menutupnya.

Omong-omong, alasan mengapa saya begitu terlibat di Godot adalah karena saya sedang berusaha menjadikannya sebagai mesin wajib untuk semester pertama. Agar Anda tahu bahwa saya tidak hanya berbicara tetapi juga menggambar konsekuensi saya. ;-)

@RebelliousX Saya harus mengakui bahwa saya masih tidak begitu mengerti apa yang Anda maksud. Tetapi karena Anda mengatakan bahwa yang Anda inginkan adalah referensi atau petunjuk, dapatkah Anda membuka permintaan fitur baru dan memposting contoh kode untuk masalah Anda di sana? Sejujurnya itu masih terdengar seperti masalah Anda adalah salah satu arsitektur kode daripada salah satu fitur bahasa yang hilang.

Saya seharusnya menambahkan bahwa KISS sebagian besar bermanfaat untuk tim kecil. Godot sangat penuh fitur sehingga satu pengembang dapat membuat game. Tetapi segera setelah sebuah proyek memiliki lebih banyak pengembang, hal-hal "cepat dan kotor" menjadi lebih kecil kemungkinannya, dan dibiarkan untuk pembuatan prototipe atau perbaikan sementara, maka aturan/pedoman harus disiapkan. Jadi, sangat tergantung siapa yang menggunakan mesin tersebut, dan untuk apa.

Godot secara umum juga memiliki kendala lebih dari yang kita kira. Anda tidak dapat membuat lajang "c-static-style" atau variabel global karena suatu alasan: kebocoran memori dan keramahan utas. GDScript tidak ditampilkan seperti Python karena suatu alasan: fokus pada tugas dan kinerja pengembang game. Sistem pemandangan juga berorientasi objek karena suatu alasan: Anda dapat membuat "kotak" independen yang dapat diuji dan digunakan kembali :)

Topik ini tentang menambahkan dukungan modul C# (atau Java), tetapi saya tidak melihat kode contoh. Mari kita coba sesuatu dengan cepat :)

using GodotEngine;

// Inherit a node type
public class Spikeball : RigidBody2D {

    // Exported variables
    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

    // Notice the naming convention. Should Godot API follow languages or should languages follow Godot?

    void _Ready() {
        SetProcess(true);
        // Should we use the generic system?
        Connect("BodyEnter", this, "_OnBodyEnter")
        // Or use C# features?
        this.bodyEnterEvent += _OnBodyEnter;
    }

    void _Process(delta) {
        var sprite = (Sprite)GetNode("Sprite");
        sprite.SetRot(sprite.GetRot() + delta*rotationSpeed);
        // Or we can have properties
        sprite.rot = sprite.rot + delta*rotationSpeed;
    }

    public void _OnBodyEnter(PhysicsBody2D body) {
        // We cannot invent C# members on the fly, so we can do this if the other script is in C# too.
        // ScriptInstance GetScript();
        var health = body.GetScriptInstance() as IHaveHealth;
        if(health != null) {
            health.TakeDamage(damage);
        }
        // But what if the other is GDScript?

        // A generic approach would look like this, a bit like SendMessage in Unity3D
        // object Call(string funcname, object arg1, ...); // where object can be seen as Variant
        body.GetScriptInstance().Call("TakeDamage", damage);

        // Same thing if we want to get a script variable
        var category = (string)body.GetScriptInstance().Get("category")
        Console.Print(category);
    }

}

Bagaimana menurut anda?
File ini kemudian dapat dikompilasi sebagai aset DLL (atau dijalankan dengan cepat). Tetapi berbicara tentang ini, apakah kita perlu membuat csproj seperti Unity?

@Warlaan terima kasih telah berbagi pengalaman Anda. Perbaiki saya jika saya salah (itu adalah posting yang panjang), tetapi apakah Anda mengatakan bahwa menawarkan bahasa dengan fitur yang lebih sedikit lebih baik demi programmer, sehingga mereka dapat fokus pada pengembangan game mereka daripada overcoding?

Jika demikian, ini adalah pengamatan yang sangat halus. Saya pikir para pengembang Godot harus melakukan yang terbaik untuk basis pengguna mereka - mereka tahu apa yang terbaik.

Dan saya sendiri hari ini bertanya-tanya apakah beberapa orang di sini (termasuk saya sendiri) tidak hanya secara halus meminta Urho3D , sementara yang lain meminta GDevelop . Godot jelas merupakan alat tengah jalan di antara keduanya (tetapi sangat cocok untuk pro, lebih seperti Urho3D), dan saya pikir itu harus tetap demikian, tetapi Unity akan selalu membayangi hal itu karena banyak orang di sini datang dari itu.

Saya tidak berpikir adil untuk mengharapkan Godot menjadi ripoff Unity - Godot jelas memiliki desain yang lebih baik dan sejauh yang saya tahu, kinerja yang lebih baik. Tetapi beberapa orang berpikir GDScript tidak cocok untuk pengembangan "serius" dan tidak akan pernah cocok karena ini adalah runtime khusus, terlepas dari kenyataan bahwa versi lama Mono yang digunakan Unity juga merupakan runtime "kustom". Selain itu, ketika Anda menulis C# di Unity, Anda menulis kode yang hanya berfungsi di Unity untuk sebagian besar dan mengikuti pola desainnya, jadi sebaiknya Anda menggunakan bahasa lain.

Saya pikir orang-orang yang menginginkan C # salah, tetapi kompromi yang baik menurut saya adalah menawarkan:

1) Performa yang lebih baik (pengetikan statis, mungkin JIT)
2) Dukungan yang lebih baik untuk perpustakaan pihak ketiga (melalui FFI dan integrasi C++ yang lebih mudah)

untuk GDScript. Sisanya dapat dilakukan dalam C++, termasuk modul penulisan yang mengimplementasikan bahasa skrip lain (yang tidak perlu menjadi pihak pertama - semua orang dapat menulis modul C#, jika mereka mau).

@Zylann Saya tidak melihat keuntungan dalam menulis kode itu daripada C++ yang setara, jujur, dan kode C++ akan memiliki kinerja yang lebih baik.

@paper-pauper keuntungan menulis kode ini sama dengan GDScript: Anda tidak perlu mengkompilasi ulang mesin untuk setiap platform yang ingin Anda ekspor, dan... bukan satu-satunya poin, seperti yang saya sebutkan sebelumnya). Saya setuju bahwa saat ini, pengalaman GDScript lebih unggul, dan C++ adalah pilihan terbaik untuk kinerja murni. Tapi, ada orang yang tidak mau menggunakan C++, apa pun bagusnya.
Saya pribadi tidak tertarik dengan Godot+C#, hanya mengevaluasi apa yang terjadi jika Anda menambahkannya ke Godot. Dan tidak semudah itu :p

Setelah membaca buku hebat Game Scripting Mastery (Anda tidak dapat menemukan banyak buku tentang subjek tersebut, kecuali buku non-game tentang kompiler Naga Merah). Kesimpulan saya adalah, GDscript sudah memadai, sangat mudah untuk terus menambahkan fitur ke bahasa scripting yang membuatnya kehilangan kekuatannya. Yang paling penting adalah menerapkan bahasa skrip yang tidak membengkak dan seumum mungkin untuk membuatnya cocok untuk proyek yang berbeda. Dari buku yang sama, dikatakan bahwa Unreal menggunakan C++ dengan LLVM.

Ide lain yang mungkin lebih ringan daripada mengimplementasikan runtime terpisah: bagaimana dengan mengadaptasi transpiler seperti TypeScript (yang sangat mirip dengan C#, tanpa runtime) untuk memancarkan GDScript alih-alih JavaScript? Ini tidak harus disertakan dalam Godot, bahkan mungkin modul pihak ketiga. Setidaknya akan menawarkan pengetikan statis (pada waktu kompilasi) dan sejumlah perpustakaan, dengan kinerja yang sama dengan GDScript (karena itu adalah GDScript).

Saya suka TypeScript, tetapi saya tidak melihat gunanya menambahkan komplikasi seperti itu. Jika seseorang melakukan itu, mereka harus mempertahankannya agar kompatibel dengan versi TS yang lebih baru. Juga, TS adalah superset dari JS, jadi apakah ini dapat mengubah JS ke GDScript? Dan kemudian, beberapa orang dengan bug di transpiler berpikir itu bug di mesin.

Saya masih berpikir ide yang lebih baik adalah memiliki GDScript versi statis yang dapat lebih mudah digunakan di JIT dan masih terkait erat dengan mesin dan dengan GDScript saat ini itu sendiri.

Inti dari C# adalah menggunakan bahasa mapan yang dapat digunakan di luar Godot juga. TypeScript mungkin cocok dengan ini, tetapi saya tidak yakin bahwa lebih mudah membuat transpiler TS daripada menyematkan runtime Mono.

Bagi saya, seperti yang saya katakan di IRC, opsi terbaik adalah kemampuan untuk membuat modul yang terhubung secara dinamis. Jadi Anda dapat bekerja di C++ dengan lebih mudah dan juga mungkin ada modul pihak ketiga dengan bahasa yang berbeda, seperti satu untuk C# dan satu untuk C++ sebagai bahasa skrip. Itu akan meningkatkan kemampuan menumbuhkan sumber daya Godot tanpa harus mengasapi biner mesin utama.

@vnen

Bagi saya, seperti yang saya katakan di IRC, opsi terbaik adalah kemampuan untuk membuat modul yang terhubung secara dinamis. Jadi Anda dapat bekerja di C++ dengan lebih mudah dan juga mungkin ada modul pihak ketiga dengan bahasa yang berbeda, seperti satu untuk C# dan satu untuk C++ sebagai bahasa skrip. Itu akan meningkatkan kemampuan menumbuhkan sumber daya Godot tanpa harus mengasapi biner mesin utama.

Oh, saya 100% setuju - sebenarnya saya menyatakan pandangan serupa di #3936. Saya baru saja membuangnya karena kami menyebutkan runtime C # sebagai kelemahan :)

Bagi saya, contoh modul C# oleh @Zylann itu indah, saya akan beralih dari Unity sekarang jika tersedia - ini bukan tentang kinerja C++ yang lebih tinggi atau 'kemudahan' GDScript, ini tentang kenyamanan.

Saya masih sangat baru di Godot dan saya hampir tidak punya kesempatan untuk membuat game uji jadi kalian mungkin tidak menganggap pendapat saya valid, tetapi bagi saya GDScript adalah rintangan terbesar, bukan bagaimana seharusnya bekerja dengan Node dan Adegan - Saya mengerti itu (dan itu cukup rapi!).

Tetapi bagi saya, ini adalah sintaks GDScript yang benar-benar mengecewakan, belum lagi editor kodenya sangat kurang - saya ingin menggunakan VS karena saya sudah mengetahui semua pintasannya.
Saya sudah bertahun-tahun menulis C # di tangan saya dan sejujurnya saya merasa seperti anak kecil yang mencoba menulis dalam GDScript.

Apa yang akan hilang dengan membiarkan pengembang menulis dengan nyaman? Saya tidak membutuhkan kebanyakan Mono atau fantasi seperti Linq, saya hanya ingin merasa nyaman saat saya menulis kode saya.
Saya akan menerima sintaks seperti C # untuk GDScript, setidaknya opsi untuk menggunakan kurung kurawal, titik koma, dan tipe eksplisit - Saya tidak tahan dengan tipe implisit secara pribadi, mereka membuat saya gila.
Saya pikir GameMaker memungkinkan variasi sintaks untuk mengakomodasi demografi yang berbeda.

Ini tentu saja, hanya 2 sen saya dari beberapa jam dengan Godot - jangan ragu untuk tidak setuju (karena saya yakin sebagian besar dari Anda akan setuju).

Juga, saya pikir saya kehilangan sesuatu - apa sebenarnya tentang GDScript yang sangat disukai semua orang?
Saya tidak mencoba menyinggung, saya hanya belum melihatnya.
Saya cukup akrab dengan Perl jadi saya tahu kekuatan tipe implisit dan yang lainnya tapi pasti ada lebih dari itu, kan?

@Pikl :

Juga, saya pikir saya kehilangan sesuatu - apa sebenarnya tentang GDScript yang sangat disukai semua orang?
Saya tidak mencoba menyinggung, saya hanya belum melihatnya.

Intinya tentang GDScript bukan tentang sintaks (yang Pythonesque) tetapi lebih tentang bagaimana terintegrasi dengan mesin. Ini mungkin terdengar bertele-tele, tetapi sintaks adalah yang paling tidak menjadi perhatian ketika pindah ke sistem lain. Yang paling penting adalah API. Bahkan jika kita menambahkan C# sekarang, Anda mungkin merasa tidak nyaman dengan paradigma baru, karena cara Anda melakukannya di Unity tidak sama dengan yang Anda lakukan di Godot.

Maaf, tetapi jika kami menambahkan bahasa untuk menghadiri zona nyaman setiap programmer, kami akan menghabiskan waktu selamanya untuk melakukan hal itu. Meskipun mungkin masuk akal untuk membawa pengguna Unity dengan stres paling sedikit (saat ini kami mencoba membuat panduan Godot untuk pengguna Unity), saya tidak berpikir Godot harus menyesuaikan diri untuk bekerja seperti Unity. Jika tidak, kami harus melakukan hal yang sama untuk pengguna Unreal, Urho3D, GameMaker, dll.

Ini bukan untuk mengatakan C # tidak terjadi (mungkin jika itu layak dan untuk kepentingan mesin), hanya saja argumen ini akan berlaku untuk banyak bahasa dan mesin lain juga.

@Pikl Pertama-tama terima kasih telah memberikan argumen pertama yang mendukung C#. Sekarang izinkan saya menjelaskan mengapa menurut saya pendapat Anda tidak valid. ;-P

Mari kita lihat lebih dekat awal dari contoh kode oleh Zylann:

    using GodotEngine;

    public class Spikeball : RigidBody2D {

    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

Sebagai aturan praktis, setiap kata kunci dan setiap karakter non-kata kunci memiliki arti. Jika tidak, seharusnya tidak ada.
Ini dimulai dengan
using GodotEngine;
yang berarti bahwa kode ini mengacu pada fungsi yang diimpor dari paket "GodotEngine". Karena setiap skrip di Godot mengacu pada fungsi-fungsi itu dan tidak ada paket lain untuk diimpor dari itu, tidak ada gunanya menambahkan baris itu, jadi mari kita hapus.

Selanjutnya kita punya
public class Spikeball : RigidBody2D {
Semua yang ada di GDScript bersifat publik, jadi mengapa menyebutkannya?
class Spikeball : RigidBody2D {
Setiap file GDScript berisi kelas dengan nama yang sama dengan skrip. Itu bukan hanya konvensi pengkodean seperti dalam bahasa lain, itu didefinisikan seperti itu, jadi apa gunanya mengulang nama kelas?
: RigidBody2D {
Sekarang karena : adalah satu-satunya "kata kunci" yang berarti di baris ini, mari kita ganti dengan sesuatu yang sedikit lebih mudah dibaca.
extends RigidBody2D {
Setiap pembuat kode dengan sedikit pengalaman akan menggunakan lekukan untuk menandai area kode yang berbeda. Itu berarti bahwa kode di dalam kelas dapat diidentifikasi oleh kurung kurawal di sekitarnya DAN oleh lekukan, itulah sebabnya pengembang Python memutuskan untuk membuat lekukan wajib dan menyingkirkan kurung kurawal yang sekarang berlebihan.
Dalam kasus kami, lekukan bahkan tidak diperlukan pada tingkat kelas karena setiap file skrip didefinisikan sebagai satu kelas (kecuali jika Anda menggunakan subkelas yang ditandai dengan lekukan).
extends RigidBody2D

Selanjutnya kita memiliki jalur ekspor.

    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

[]-karakter menandai atribut yang didefinisikan dalam kelas dengan nama yang sama, yang merupakan mekanisme yang tidak ada di Godot, jadi hanya menggunakan kata kunci saja.

    export public float damage = 60f;
    export public float rotationSpeed = 2f;

Sekali lagi, semuanya bersifat publik:

    export float damage = 60f;
    export float rotationSpeed = 2f;

dan Anda tidak perlu menentukan tipe data.

    export var damage = 60f;
    export var rotationSpeed = 2f;

Ekspor merupakan pengecualian karena pemeriksa perlu mengetahui widget mana yang akan ditampilkan kepada Anda, jadi jenisnya sebenarnya hanyalah informasi tambahan untuk kata kunci ekspor.

    export(float) var damage = 60f;
    export(float) var rotationSpeed = 2f;

Jadi perbedaan antara kode C# ini

    using GodotEngine;

    public class Spikeball : RigidBody2D {

    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

dan kode GDScript ini

extends RigidBody2D

export(float) var damage = 60f;
export(float) var rotationSpeed = 2f;

hanya saja setiap karakter dan kata kunci telah dihapus yang tidak menjelaskan opsi yang Anda miliki di Godot.
Saya berasumsi bahwa sekarang cukup jelas apa yang disukai orang tentang GDScript. Anda tidak dipaksa untuk mengetik hal-hal yang tidak berarti atau berlebihan dan sintaksnya mencerminkan opsi yang Anda miliki alih-alih mengisyaratkan opsi atau fitur bahasa yang tidak ada di Godot.

Berasal dari latar belakang C++/C#/TorqueScript Saya harus mengatakan bahwa paradigma Godot membutuhkan beberapa hari untuk membiasakan diri, tetapi begitu "klik" kesederhanaannya, Anda dapat berpindah dari ide ke eksekusi secepat yang Anda bisa ketik.

@vnen :

hanya saja argumen ini akan berlaku untuk banyak bahasa dan mesin lain juga

Cukup adil, saya tidak menahan napas saya juga tidak berharap untuk ditampung - ini bukan wilayah saya.

saat ini kami sedang mencoba membuat panduan Godot untuk pengguna Unity

Mungkin saya bisa membantu dengan itu? Saya telah menggunakan Unity selama beberapa tahun dan mengetahuinya dengan cukup baik dibandingkan dengan mesin lain - saya akan menjadi tikus lab yang baik untuk panduan ini.

@Warlan :

Saya berasumsi bahwa sekarang cukup jelas apa yang disukai orang tentang GDScript. Anda tidak dipaksa untuk mengetik hal-hal yang tidak berarti atau berlebihan dan sintaksnya mencerminkan opsi yang Anda miliki alih-alih mengisyaratkan opsi atau fitur bahasa yang tidak ada di Godot.

Itu masuk akal - ini sejalan dengan ideologi Perl untuk mengurangi jumlah penekanan tombol yang diperlukan untuk mengetik skrip. Tapi sungguh, jumlah penekanan tombol yang akan saya ketik untuk contoh itu akan sama - saya menggunakan pelengkapan otomatis VS secara maksimal dan jarang harus mengetik lebih dari 3 karakter untuk kata kunci, jenis, atau nama variabel apa pun sebelum saya menekan spasi atau membuka kurung untuk menyelesaikannya. Dan untuk karakter tambahan yang 'tidak dibutuhkan' di sana, saya lebih suka memilikinya di sana, itu hanya preferensi gula sintaksis.
Godot memiliki pelengkapan otomatis tetapi lambat, butuh waktu lama sehingga saya sering mengetik seluruh baris kode saya bahkan sebelum itu muncul hampir sepanjang waktu.

Jadi apa yang disukai orang tentang GDScript adalah bahwa itu dipreteli menjadi seminimal mungkin menyediakan fungsionalitas yang tepat yang tersedia untuk digunakan dan tidak lebih, serta mengurangi penekanan tombol.

Saya mengerti, tetapi itu tidak membantu saya menikmatinya lagi - saya hanya tidak nyaman mengetik GDScript, saya dapat membacanya dengan baik. Saya tidak berjuang untuk mempelajarinya, saya hanya tidak menyukainya, sepertinya.
Mungkin beberapa jam lagi membuat klon Space Invaders akan membantu meyakinkan saya - saya ingin lebih menyukai GDScript daripada saya.

Renungan:
Apakah mungkin hanya menggunakan C++ di Godot? Sejujurnya saya pikir saya lebih suka belajar C++ dan menggunakannya daripada GDScript.

Mungkin saya bisa membantu dengan itu? Saya telah menggunakan Unity selama beberapa tahun dan mengetahuinya dengan cukup baik dibandingkan dengan mesin lain - saya akan menjadi tikus lab yang baik untuk panduan ini.

@StraToN membuat posting di grup facebook meminta bantuan semacam ini. Hubungi dia (saya tidak yakin apakah ada orang lain yang mengerjakannya juga).

@neikeq Terima kasih, selesai!

@Warlaan Saya mengerti perbandingan kode Anda, tetapi bagi saya itu terutama membuktikan bahwa C# memiliki lebih banyak fitur, dan karenanya, lebih bertele-tele.

Anda memerlukan using karena ada ruang nama untuk menghindari tabrakan nama dengan banyak kelas (yang sudah terjadi pada saya di proyek permainan saya sendiri).
Anda memerlukan public karena ada gagasan enkapsulasi untuk mencegah kesalahan pembuat kode dari waktu ke waktu.
Anda memiliki [SomeClass] karena kami dapat memperluas anotasi bawaan agar sesuai dengan kebutuhan proyek yang berbeda dan meningkatkan perkakas.
Adapun kawat gigi... Saya tidak melihat keuntungan, kecuali untuk mendefinisikan cakupan.

Fitur-fitur ini ada di sini karena suatu alasan. Di antara mereka, saya akan mengatakan skalabilitas. Apakah Anda akan mengembangkan game 3D lintas platform yang besar dengan semua basis kode di GDScript? Anda bisa. Tetapi banyak pengguna akan lebih memilih C++, C# atau Java, karena pro yang saya sebutkan (dan saya berbicara murni tentang bahasa, bukan kerangka kerja).

Tetapi pada saat yang sama, tidak ada proyek game "besar" yang saya tahu sedang dikembangkan dengan Godot, jadi tidak banyak contohnya :p
Juga, saya melihat beberapa fitur buruk di C# (peringatan: pendapat pribadi ke depan):

Anda dapat memiliki variabel statis. Ini salah, begitu banyak kesalahan datang dari negara bagian/lajang global. Tidak seperti pemuatan otomatis, mereka tidak terikat pada lingkup adegan apa pun.
Anda dapat salah mengetik titik koma di akhir while() dari pernyataan if(), membuatnya tidak berguna dan sulit ditemukan.
Anda bisa overcode. Saya setuju bahwa, ketika digunakan dengan cara yang salah, kode C# dapat menjadi sangat berbelit-belit sementara kode lain yang lebih sederhana akan melakukan hal yang sama. Tapi tergantung orang/pengalamannya.

Oh. Saya tidak menyebutkan preload() . Ini tidak bisa sampai ke C#/Java, kecuali jika Anda mengandalkan trik kompiler :p

Apakah ada yang sudah mulai bereksperimen dengan modul Mono?

Untuk menambahkan pendapat saya yang paling sederhana, sebagai seseorang yang merupakan pengembang C#, untuk ini...

Saya tidak berpikir ada banyak nilai dalam menambahkan C# ke Godot, karena Anda masih harus mempelajari kelas Godot untuk menyelesaikan sesuatu dan satu-satunya hal yang benar-benar akan Anda peroleh dari menambahkan C#, adalah gaya C yang lebih familiar (bagi banyak orang) sintaks dan pengetikan statis.
Hal sintaks masih bisa diperdebatkan, Python memiliki reputasi mudah dipelajari untuk pemula dan karena GDScript sangat mirip dengan Python, saya pikir hal yang sama berlaku untuk itu.
Pemrogram yang agak berpengalaman seharusnya tidak kesulitan memahami sintaks itu, ini konsisten dan memiliki perangkap yang jauh lebih sedikit daripada sintaks gaya bentuk C yang lebih bebas.

Sekarang pengetikan statis di sisi lain dapat memiliki beberapa nilai, selain membantu kinerja, juga dapat membantu kecepatan pengembangan dalam beberapa hal. Alat pelengkapan otomatis senang diberi tahu jenis apa yang diharapkan dan dikembalikan oleh fungsi/metode pemberian, tetapi petunjuk ketik saja dapat mencapainya.
Ini dapat ditambahkan ke GDScript, tidak perlu bahasa tambahan apa pun.

Juga mengimplementasikan C# mungkin tidak akan semudah itu dan banyak waktu dan usaha akan dihabiskan hanya untuk mendapatkan mesin ke keadaan saat ini tetapi sekarang dengan C# di atas atau bukan GDScript.

Sebagai komentar penutup, yang saya tahu beberapa orang akan mengambil jalan yang salah, saya ingin mengatakan ini:

Telah pengamatan saya bahwa beberapa programmer yang mungkin tidak kokoh seperti seharusnya dalam kerajinan kami memiliki kecenderungan untuk berpegang teguh pada hal-hal yang mereka tahu dengan semua kekuatan yang tersedia untuk mereka.
Fenomena ini bagi saya tampaknya tersebar luas di komunitas pengembang C#, meskipun ini mungkin hanya bias saya.
Jika ada orang yang membaca ini berpikir mereka mungkin cocok dengan deskripsi itu, saya hanya dapat merekomendasikan untuk melangkah keluar dari kotak yang sudah dikenal ini dan mulai mempelajari sesuatu yang baru, itu bukan tugas yang menakutkan seperti yang Anda bayangkan dan begitu Anda memiliki perusahaan memahami hal baru itu, Anda mungkin juga akan meningkatkan pemahaman Anda tentang apa yang sudah Anda ketahui. Ini hanya layak.

Saya akan menyukai tipe statis, tetapi jika itu terjadi, bagaimana Anda menangani obat generik? Apakah Anda cukup menggunakan tipe dinamis dalam contoh itu atau Anda ingin dapat menggunakan batasan? - hanya izinkan int dan bool misalnya.

Namespaces akan sangat diterima, saya terkejut bahwa mereka belum ada di GDScript.

Pilihan untuk menggunakan kurung kurawal daripada titik dua untuk metode akan menyenangkan juga, saya tahu itu tidak dibutuhkan tetapi saya suka memilikinya di sana - ini seperti membaca buku tanpa berhenti, itu menggelegar.

Petunjuk ketik dapat menutup celah yang mencegah penyelesaian kode berfungsi sepenuhnya. Saya pernah mengerjakan sebuah proyek menggunakan Lua, dan mereka juga ingin memilikinya. Penelitian membawa saya ke sini: https://github.com/andremm/typedlua/blob/master/examples/http-digest/http-digest.tl#L48
Inilah yang bisa menjadi parameter fungsi, jika Anda menyelam terlalu jauh dalam mengetik petunjuk xD
Tapi saya pikir harus ada tradeoff. Lihat saja bagaimana TypeScript atau Haxe melakukannya (keduanya memungkinkan pencampuran varian dan diketik). Juga, petunjuk ketik sudah ada di Godot. Ini hanya digunakan di export() :)

Apakah ada yang sudah mulai bereksperimen dengan modul Mono?
@Zylann

Lihat GodotSharp . Status saat ini dalam repositori belum dapat digunakan. Di repo lokal saya, saya berhasil mengimplementasikan cukup banyak hal (hanya Vector2 dan Matrix32 yang tersedia sebagai tipe dasar) untuk menerjemahkan demo 2d/platformer ke C#, kecuali untuk musuh dan peluru instan yang dilakukan dari GDScript karena referensi belum berfungsi.
Ini adalah contoh kelas pemain: https://github.com/neikeq/GodotSharp/blob/master/platformer_cs/Player.cs

@Pikl

Renungan:
Apakah mungkin hanya menggunakan C++ di Godot? Sejujurnya saya pikir saya lebih suka belajar C++ dan menggunakannya daripada GDScript.

Ya, itu mungkin, tetapi saat ini tidak semudah dan/atau nyaman dan Anda harus mengkompilasi ulang Godot dari awal. Tolong tunjukkan beberapa dukungan untuk #3936 jika Anda tertarik C++ menjadi warga negara kelas satu, sehingga dapat digunakan bersama dengan GDScript (atau secara eksklusif) tanpa banyak pekerjaan.

@Zylann Pikl bertanya tentang mengubah sintaks GDScript agar menyerupai C# sehingga menjadi lebih mudah dibaca untuk pengembang Unity. Itu yang saya komentari. Ya, C# memang memiliki lebih banyak fitur, itulah satu-satunya alasan mengapa kata kunci dan karakter yang saya hapus ada di sana sejak awal. Dan itulah mengapa menambahkan mereka hanya demi memiliki kode GDScript yang terlihat seperti kode C# tidak hanya tidak perlu, itu salah, karena Anda akan menggunakan sintaks yang mengisyaratkan fitur bahasa yang tidak dimiliki GDScript.

@Pikl Ini bukan tentang jumlah keytoke, ini tentang jumlah pilihan dan makna tersirat dari karakter tambahan. GDScript tidak memiliki beberapa fitur yang akan melegitimasi kata kunci tambahan. Misalnya setiap variabel, kelas, dan fungsi harus didahului oleh kata kunci "publik", karena pengubah visibilitas default C# tidak bersifat publik (kecuali untuk ruang nama - ini berubah berdasarkan kasus penggunaan... situasi lain di mana Microsoft memutuskan bahwa KISS hanyalah sebuah band dari tahun 80-an) dan karena di GDScript semuanya bersifat publik.

Jadi mengapa tidak menambahkan C# dengan semua fiturnya?
Seperti yang telah Zylann sebutkan, efek menambahkan C# ke Godot tidak mudah diprediksi. Jika Anda belum melakukannya, saya akan sangat menghargai jika Anda membaca posting panjang saya di utas ini (https://github.com/godotengine/godot/issues/5081#issuecomment-225226235). Sebagai pengembang, saya akan selalu meminta bahasa yang lebih kuat. Di waktu luang saya, saya saat ini melihat Kotlin hanya karena kertas-pauper disebutkan di posting pertama.
Tetapi karena saya memiliki kesempatan untuk melihat pengaruh bahasa pemrograman pada hasil dan perilaku pengembang game, saya menyadari betapa pentingnya memilih bahasa yang memadai daripada bahasa yang kuat.
Seperti yang saya jelaskan di posting tertaut, saya yakin bahwa C # memiliki pengaruh nyata pada budaya di komunitas Unity yang melihat programmer sebagai orang yang

• menulis barang untuk toko aset
• menulis tutorial
• memperbaiki bug.

Dalam pengalaman saya, tidak banyak budaya pemrograman gameplay di Unity. Segera setelah Anda mengalami masalah apa pun, Anda mulai mencari pola atau aset yang telah dibuat sebelumnya untuk menyelesaikannya. Sebenarnya ada sejumlah besar orang yang memilih pola mereka bahkan sebelum mereka tahu apa-apa tentang sebuah proyek, dan ketidakfleksibelan mental semacam itu mempengaruhi hasil gameplay.

Dan itu hanya kontra-argumen favorit saya, ada beberapa argumen bagus lainnya di posting pertama. ;-)

Masalah dengan JVM adalah terlalu berat. Apakah ada yang melihat Avian ? Seberapa kompatibel dengan dunia Java?

@neikeq Itu tidak berarti kinerjanya lebih buruk - AFAIK JVM memiliki kinerja yang lebih baik daripada CLR, dan juga Pengumpul Sampah yang jauh lebih cocok untuk pengembangan game. Itu juga diinstal di sebagian besar komputer, terlepas dari apakah itu Windows atau Mac atau GNU/Linux.

Ini juga memiliki banyak perpustakaan FLOSS berkualitas lebih tinggi dan, terlepas dari apa yang dikatakan beberapa orang, dukungan lintas platform yang lebih baik.

Saya akan mengatakan bahwa di antara keduanya, JVM jelas lebih baik untuk pengembangan game (tapi saya akan menghindari keduanya dan CLR sama saja).

Avian memang terlihat menarik. Saya tidak memiliki pengalaman dengan itu, jadi saya tidak dapat menjawab pertanyaan Anda, dan saya khawatir kompatibilitasnya akan menjadi bermasalah seperti versi Mono Unity, yang membuatnya sangat canggung untuk menggunakan perpustakaan pihak ketiga kecuali Anda kebetulan menemukan satu untuk salah satu .NET-Versi yang disediakan.

Tetapi memiliki implementasi Java yang ringan sebagai opsi tambahan selain GDScript & C++ untuk kasus-kasus di mana Anda memerlukan waktu penyelesaian yang cepat dan dapat mengorbankan kualitas kode (seperti kemacetan game atau pembuatan prototipe cepat dari ide-ide backend baru) akan menyenangkan.

@neikeq Avian dibuat dalam pikiran untuk menyediakan java-scripting untuk proyek c++ jadi itu benar-benar kandidat yang baik. Ini bisa sangat kecil (sekitar 100kb jika saya ingat dengan benar). Mendengar tentang beberapa game libGDX yang menggunakan Avian untuk merilis port iOS... mesin jMonkey juga menggunakan Avian di iOS). Secara umum Avian hadir tanpa seluruh kemasan yang biasanya hadir dengan JVM seperti kelas matahari/oracle. Namun saya tidak berpikir itu masalah karena kelas java 'asli' tidak cocok untuk game sama sekali, inilah mengapa perpustakaan seperti libGDX menyediakan implementasinya sendiri pada vektor, atau struktur data.. dan pada akhirnya saya pikir kami akan melakukannya perlu mengimplementasikan kembali kelas-kelas itu juga. (Namun mudah untuk menyematkan berbagai bagian dari kelas java asli, tetapi semakin banyak kita memasukkan Avian akan menjadi lebih besar)

@paper-pauper Maksud saya ukurannya berat, seandainya itu akan dibundel dengan permainan. Tapi seperti yang Anda katakan, itu diinstal di sebagian besar komputer, dan mengingat popularitas kerangka kerja seperti libGDX, itu bisa menjadi pilihan terbaik.
Masalah saya dengan C++ sebagai alternatif GDScript adalah sintaksnya mengerikan. Itu pembunuh produktivitas. Ini bagus untuk pengembangan mesin dan modul, tetapi saya tidak akan menulis seluruh game dengannya. Karena itu, saya mendukung #3936 dan memiliki sesuatu seperti yang dilakukan Unreal, tetapi saya tidak akan melihatnya sebagai bahasa "scripting" alternatif.

@kubecz3k Apakah ini mendukung bahasa JVM lainnya? misalnya: Kotlin

@neikeq ya sejauh yang saya tahu itu sepenuhnya kompatibel dengan Java bytecode sehingga mendukung bahasa siap jvm (kotlin, scala, jpython dan sebagainya)
Saya pikir kami mungkin mengajukan beberapa pertanyaan di grup google avian: https://groups.google.com/forum/#!forum/avian
sepertinya cukup aktif

+1 untuk tidak melihat C++ sebagai bahasa skrip alternatif. Seperti yang saya katakan sebelumnya, adalah hal yang baik bahwa Godot memiliki satu bahasa yang dioptimalkan untuk skrip dan satu untuk pengembangan backend sebagai lawan memiliki satu bahasa yang "meh" di kedua area.

Itu tidak berarti bahwa dukungan lib dinamis dan pengembangan C++ yang lebih cepat bukanlah sesuatu yang ingin saya lihat.

Tetapi agar tidak terlalu antusias tentang Avian, berikut adalah posting blog dari pengembang utama libGDX di mana ia menjelaskan mengapa libGDX tidak menggunakan Avian untuk port ios. http://www.badlogicgames.com/wordpress/?p=3925 (scroll ke bawah ke bagian Avian)
Saya bukan programmer/peretas jvm (tetapi penulisnya - karena dia juga mengerjakan RoboVm (jvm lain yang dibeli dan ditutup oleh Microsoft)) jadi saya tidak tahu seberapa banyak dari ini akan benar-benar berubah menjadi situasi di mana Avian hanya digunakan sebagai bahasa scripting (tidak menyalakan mesin inti)

Sebagian besar dari Anda mungkin programmer dengan pengalaman lebih dari yang saya miliki, tetapi ada 2 sen saya. Setahun yang lalu, saya akan melakukan root untuk C#. Tapi saya belajar sintaks GDScript dengan sangat cepat. Pada akhirnya, Anda masih perlu mempelajari API dan itu mungkin hal yang paling memakan waktu untuk dipelajari. Jadi ya, saya tidak perlu C#. @Warlaan mengeluarkan banyak alasan bagus terhadap C#. Menerapkan C# juga akan memakan banyak waktu. Itu juga berarti lebih banyak bug. Ya, kami memiliki komunitas hebat yang berkontribusi pada basis kode tetapi kami masih hanya memiliki satu @reduz Saya pikir waktu yang dibutuhkan untuk mengimplementasikan C# harus diinvestasikan ke fitur yang benar-benar kami butuhkan. Berapa banyak pengembang Godot yang puas dengan GDScript? Ya, itu bisa lebih cepat, tetapi saya tidak punya masalah lain dengannya. Saya lebih suka memiliki satu bahasa skrip yang luar biasa daripada dua yang tidak begitu bagus. Bahkan Unity tertinggal dengan Mono lama.

Yang ingin saya miliki adalah mengetik statis di GDScript. Bukan C++ sebagai bahasa skrip, bukan C#. Mari kita fokus pada GDScript dan membuatnya lebih baik dari sekarang.

Karena mesin yang saya pimpin pengembangannya selama 14 tahun disebutkan di utas Visual Scripting, saya pikir saya akan menambahkan 2 sen saya di sini karena kami sedang mengembangkan mesin baru yang ditulis sepenuhnya dalam bahasa seperti C# kami sendiri.

Kami menulis kompiler kami sendiri (juga ditulis dalam bahasa kami sendiri setelah mem-bootstrapnya dalam C++) yang dikompilasi ke kode C++ (hampir murni C) yang kemudian dimasukkan ke dalam kompiler semua platform yang kami dukung (XBox/PS/PC/Wii/ dll). Kami menulis pengumpul sampah generasi kami sendiri untuk dapat menyetel kinerjanya sesuai kebutuhan - melakukannya dengan cara ini berarti digunakan di seluruh mesin yang berarti telah diuji dan diprofilkan dengan baik. Dan karena kami melakukan kompilasi silang ke C++, kami dapat dengan mudah menulis kode C++ dalam fungsi 'asli' yang dapat memanggil API sistem sesuai kebutuhan atau menyertakan operasi khusus platform (SIMD).

Saya tidak dapat membayangkan betapa frustasinya Unity karena harus menggabungkan banyak kode C++ dengan Mono -- yang mungkin menjelaskan mengapa ia tertinggal seperti yang ditunjukkan oleh @GlaDOSik . Itu jelas bukan sesuatu yang kami tertarik untuk lakukan.

Tujuan utama kami adalah untuk menyatukan bahasa yang digunakan antara mesin, editor dan alat, dan kode gameplay ke dalam satu bahasa. Sebelumnya, mesin dan alat sepenuhnya C++ dan bahasa skrip visual-ish (setidaknya terlihat seperti kode C) digunakan untuk semua gameplay yang disukai oleh desainer level, tetapi mengganggu sebagian besar programmer gameplay yang menulis mayoritas dari kode. Itu juga memungkinkan kami untuk menyesuaikan bahasa dengan hal-hal yang mungkin kami perlukan untuk pengembangan gameplay (seperti dukungan mesin negara).

_Anda tidak bisa menyenangkan semua orang._ Jika saya harus mengerjakan atau mencoba membantu seseorang men-debug kekacauan buruk dari "kode" berbasis simpul spaghetti/etc, saya ingin mencongkel mata saya sebagai pembalasan. Saya mengharapkan seorang seniman yang mencoba membaca kode C++ untuk melakukan hal yang sama. Yang dapat Anda lakukan adalah membuang _banyak_ waktu untuk berdebat tentang apa itu solusi _terbaik_ dan bahkan lebih berusaha untuk menyenangkan semua orang. Pada titik tertentu Anda hanya perlu fokus untuk membuat alat yang paling produktif yang Anda bisa untuk orang yang tepat - dan terkadang itu berarti beberapa orang mungkin harus mempelajari sesuatu yang baru.

"Jika bukan C++, itu lambat" tampaknya sering menjadi mantra, tetapi saya akan mengatakan sebagian besar game _shipped_ ditulis dengan sesuatu selain C++ untuk kode gameplay hari ini. Saya belum pernah melihat seseorang memposting masalah kinerja secara khusus dari GDScript, meskipun saya pasti penasaran untuk mendengar dari mereka apa yang lambat.

Sejauh pengenalan saya ke GDScript, kurang lebih seperti ini:

• OMG seperti Python!? Itu gila, spasi seharusnya tidak masalah!
• Hmm, bukan penggemar gaya "huruf kecil" (lihat Anda tidak bisa menyenangkan semua orang).
• Oke, ini sebenarnya agak keren dan dipikirkan dengan baik.
• Ya, ini terintegrasi dengan baik dengan editor, saya pasti bisa melihat menjadi sangat produktif dengan ini untuk kode gameplay dan beberapa plugin editor!

Sepertinya banyak usaha dan waktu telah dimasukkan ke dalam GDScript, dan sepertinya alat yang tepat. Jadi saya benar-benar hanya ingin mengucapkan pujian kepada mereka yang bekerja untuk membuatnya!

@Ziflin Hei! senang bertemu dengan Anda di sini, Vicious adalah salah satu mesin game pertama yang kami gunakan secara profesional (meskipun kami disewa dengan @punto- untuk meretasnya dan memperbaiki masalah dengannya lebih dari benar-benar menggunakannya).

Bahasa skrip visual benar-benar mimpi buruk, tetapi kode sumbernya dibuat dengan sangat baik, bersih, dan terorganisir. Setelah bekerja dengan Torque, itu adalah sebuah kebahagiaan. Saya belajar banyak bekerja dengannya. Sony melakukan pekerjaan yang hebat dengan menjualnya di Amerika Latin karena semua orang menggunakannya di sini satu dekade yang lalu..

Saya pikir momen paling menakjubkan yang saya ingat dari bekerja dengannya adalah secara tidak sengaja menemukan sepotong kode yang mencantumkan bahasa, dan ada komentar "Bahasa Portugis tidak didukung"

Kami benar-benar tertawa terbahak-bahak dan membuat lelucon, dan produser game (yang berada di belakang kami dan kami tidak memperhatikannya) gemetar ketakutan dan berkata: "Tunggu apa? yang tersisa sekarang adalah menerjemahkan game ke dalam bahasa Portugis , ini lelucon kan?"

Tapi kami hanya menggunakan bahasa Cina untuk bahasa Portugis, semuanya bekerja dengan baik dan permainan telah dikirim. Senang mengetahui kalian masih mengembangkannya!

(kutipan dari @Ziflin ) Saya belum pernah melihat seseorang memposting masalah kinerja secara khusus dari GDScript, meskipun saya pasti ingin tahu dari mereka apa yang lambat.

Saya pribadi telah mencapai hambatan CPU/Gdscript dalam proyek ini: http://godotdevelopers.org/index.php?topic=15519.0

Saya menulis beberapa AI dasar dan fisika semu sekolah tua dasar di GDscript untuk mengontrol masing-masing dari 8 mobil.
Saya tidak menangis keras di depan umum tentang masalah kinerja ini karena masih ada beberapa ruang kecil untuk pengoptimalan.
Tetapi jika saya ingin menambahkan lebih banyak mobil, saya terpaksa membuang Gdscript untuk C++ ( edit : yang ingin saya hindari karena saya tidak benar-benar ingin harus mengkompilasi lagi dan lagi).

Juga, saya pikir saya mengalami hambatan CPU/Gdscript yang sama tahun lalu dengan proyek lain ini yang menggunakan GDscript untuk AI dasar untuk setiap bug (hewan): http://ludumdare.com/compo/ludum-dare-32/? tindakan=pratinjau&uid=50893
Semakin banyak saya menambahkan bug (hewan), semakin rendah kinerjanya.

Saya bisa berbagi pengalaman saya di atasnya jika seseorang ingin.

@SuperUserNameMan Silakan, tapi saya pikir tiket lain yang saya buka #5049 (yang berbicara secara khusus tentang kinerja GDScript) lebih cocok untuk itu.

@paper-pauper : tidak yakin saya bisa berkontribusi #5049 (yang lebih tentang menambahkan JIT, tentang apa yang saya bisa menambahkan jempol). Pengalaman yang bisa saya bagikan lebih banyak tentang bottlneck seperti apa yang saya capai, apa gejala spesifiknya, bagaimana saya harus menyiasatinya, bagaimana saya mengoptimalkan, dan apa "manfaat desain godot" yang harus saya korbankan.

@SuperUserNameMan Saya belum terlalu memikirkan implementasi JIT melalui inferensi tipe, tetapi untuk itu VM harus mendukung pengetikan statis terlebih dahulu

Saya akan sangat tertarik untuk mendengar jenis kode AI yang Anda maksud.
Prakonsepsi saya adalah bahwa kode apa pun yang dapat menyebabkan masalah kinerja ketika dijalankan hanya pada 8 entitas mungkin bukan kode game yang sebenarnya dan karena itu harus dimasukkan ke dalam kelas C++, itu sebabnya saya bertanya.

@reduz Haha, rupanya dunia ini kecil! Dan yah, jenis skrip visual tumbuh di luar kendali (itu benar-benar dimaksudkan hanya untuk berurusan dengan pemicu dan sedikit logika peristiwa). Vicious sebenarnya menutup pintunya awal tahun ini, tetapi sangat menyenangkan bekerja di sana.

@paper-pauper Saya akan memeriksa topik lain yang Anda sebutkan. Saya tidak bermaksud agar orang-orang mulai memposting masalah kinerja di utas ini.

Jika GDScript ingin menambahkan pengetikan statis, _mungkin_ lebih mudah untuk hanya memiliki opsi untuk mengonversinya secara langsung ke C++ yang akan menghindari overhead tambahan dari transisi IL->C++ dan menjaga runtime tetap kecil (tidak ada kompiler JIT, dll). Anda kemudian dapat membuat prototipe di GDScript atau membuat mod dengannya, tetapi kemudian Anda juga dapat mengonversinya secara otomatis ke C++ untuk kecepatan ekstra saat diperlukan untuk pembuatan akhir.

Melakukan hal itu juga akan mempertahankan IDE yang ada (VC++, dll. & editor Godot) yang biasa digunakan orang. Kami sebenarnya hanya menggunakan VC++ untuk men-debug bahasa kami dan kompiler kami menghasilkan arahan #LINE dalam file .cpp sehingga Anda dapat dengan mudah menelusuri kode asli dan menyetel breakpoint. Jadi secara teori Anda akan dapat membuat prototipe dan men-debug dengan GDScript normal di editor, tetapi selama build yang diaktifkan 'GDScript->C++' Anda masih dapat menggunakan C++ IDE/Debugger dan menyetel breakpoint/debug di file gdscript. Bagi kami, file C++ yang dihasilkan bersifat sementara dan kami hanya pernah melihatnya jika ada masalah pembuatan kode.

Bagaimanapun, hanya sebuah pemikiran. Fakta bahwa Anda memiliki bahasa skrip yang bagus sekarang jelas merupakan nilai tambah dan tentu saja membuat melakukan hal-hal seperti mod yang dibuat pengguna, pembuatan prototipe cepat, dan menambahkan fitur baru ke bahasa menjadi mungkin.

Memang saya tidak mengerti bahwa saya seharusnya memposting masalah kinerja saya ke utas ini juga. Di sini lebih cocok: https://github.com/SuperUserNameMan/kart-zero/issues/1

@Ziflin Sebenarnya apa yang kami diskusikan dalam masalah lain adalah pertama, menambahkan API C minimum untuk menulis modul/skrip godot menggunakan C biasa melalui API minimal yang memaparkan seluruh API refleksi Godot, ini akan menyelesaikan masalah umum yang kami miliki terkait distribusi binding ke berbagai jenis perpustakaan tanpa harus mengkompilasi ulang Godot

Contohnya adalah teman-teman yang ingin mengikat steam API, ODBC, SQLite, Kinect, dll. Semuanya membutuhkan modul penulisan dalam C++. Melakukan ini dengan C API memecahkan masalah penautan dinamis terhadap C++ (yang sangat terbatas karena setiap kompiler, atau versi kompiler memiliki ABI mereka sendiri, dan masalah ketidakcocokan ukuran simbol yang mungkin terjadi di antara versi Godot). C tidak memiliki masalah tersebut.

Setelah berhasil, akan sangat mudah untuk mengompilasi GDScript ke dalam C dan memuatnya saat run-time saat game berjalan atau diekspor.

@reduz Ah keren. Jadi pada dasarnya Anda berbicara tentang kemampuan untuk menulis DLL 'plugin' yang dapat mengekspos apa yang diinginkannya ke GDScript? (atau saya salah paham?)

Setelah berhasil, akan sangat mudah untuk mengompilasi GDScript ke dalam C dan memuatnya saat run-time saat game berjalan atau diekspor.

Apakah ini berfungsi untuk seseorang yang ingin menulis dll yang mengatakan beberapa tipe turunan C++ Node baru di dalamnya?

Agak menyedihkan bahwa dukungan 'modul' C++ yang baru tampaknya cukup untuk memperbaiki beberapa masalah dengan DLL.

Mengapa tidak menggunakan bahasa skrip yang dapat disematkan seperti lua atau Ruby?

@jersten karena membaca dokumen - http://docs.godotengine.org/en/latest/reference/gdscript.html

@Ziflin ya, tetapi Anda harus menggunakan C API melalui refleksi (meskipun Anda dapat meminta penunjuk fungsi melalui refleksi sehingga harus cukup cepat ..). Tujuannya sebagian besar memiliki cara mudah untuk memuat DLL yang menghindari masalah ABI, dan juga cara sederhana untuk mengkompilasi GDScript ke C dan memuatnya sebagai .so.

Saya akan memasukkan 2 sen saya di sini untuk apa yang layak. Saya tidak pernah membuat kode dalam C # tetapi hanya di Jawa. Meskipun saya pribadi lebih suka Java karena telah menggunakannya dan menyukainya, saya sebenarnya mendukung C# daripada Java. C# adalah apa yang digunakan oleh pengembang game Unity sehingga memilikinya akan membuat Godot menjadi bagian dari ekosistem pengembang indie yang dibuat oleh Unity. Juga Java bahkan bukan pilihan yang baik jika Anda menginginkan bahasa JVM. Ada bahasa lain yang lebih baik yang dikompilasi ke JVM.

Saya pikir orang-orang kehilangan intinya. C#/Java != bahasa skrip. GDScript sudah cukup; cukup mudah untuk dipelajari, dll.

Menambahkan bahasa seperti Java (membuat JVM untuk tujuan apa?! Sintaks?! Memerlukan JVM dengan versi tertentu agar berfungsi?!?) atau C# (Implementasikan mono dan kludge mesin; atau buat sendiri?) akan meracuni mesin .

Jika ada masalah dengan GDScript, itu harus ditunjukkan; dan kemudian berusaha untuk diperbaiki.

saya tidak setuju. Saya merasa C # akan menarik banyak pengembang Unity atau pengembang yang akrab dengan bahasa seperti C yang menyediakan alternatif yang bagus untuk python seperti GDScript. Bagian terakhir dari teka-teki akan menjadi skrip visual yang akan menarik seniman yang tidak terbiasa dengan pengkodean. Ini harus mencakup hampir semua orang.
Juga, apa pun kode yang Anda gunakan, Anda masih perlu mempelajari kelas dan fungsi Godot yang akan sama dalam bahasa apa pun.

Untuk semua orang yang berpendapat C# karena pengembang Unity mengetahuinya, pertimbangkan ini: banyak pengembang Unity tidak tahu omong kosong tentang cara memprogram dalam C#. Apa yang mereka ketahui adalah bagaimana menggunakan Unity API, yang kebetulan memiliki ikatan C#. Anda membawa mereka ke Godot, bahkan jika itu C#, mereka tidak akan tahu apa yang mereka lakukan dan akan sama tersesatnya dengan memberi mereka bahasa pemrograman yang berbeda.

Menyertakan bahasa tambahan apa pun hanyalah lebih banyak overhead dan lebih dari itu proyek harus mempertahankan bahwa itu tidak harus.

Saya banyak berpikir tentang ini, dan perhatian utama saya tentang mendukung sesuatu seperti C# adalah bahwa sebagian besar orang yang akan menggunakannya adalah pengguna Unity yang datang ke Godot. Jelas, kami tidak akan menyertakan C# dengan templat resmi, dan saya sangat ragu mereka akan membuat modul itu sendiri...
Itu bisa menjadi upaya besar untuk mendukung bahasa yang hanya akan digunakan oleh beberapa orang.

Saya pikir ada kesalahpahaman:

• Mereka melihat GDScript dan berpikir bahwa GDScript setara dengan C#; kehilangan poin mendasar bahwa C # bukan bahasa skrip.
• Karena fakta di atas, ketika seseorang mengatakan "Java atau C#"; apa yang sebenarnya mereka minta adalah penulisan ulang mesin ke C#/Java atau menambahkan beberapa ikatan untuk mendukung bahasa tersebut (lol tidak).

Karena saya berasumsi yang terakhir; debugging di C#/Java adalah mimpi buruk di berbagai platform; karena kedua bahasa tersebut tidak independen terhadap platform (inb4 ada runtime di hampir semua OS); itu berubah menjadi "Tulis sekali, debug di mana-mana" (inilah sebabnya game yang ditulis ke Monogame keluar di Windows terlebih dahulu; dan akhirnya Linux/Mac karena para pengembang harus men-debug untuk platform tersebut). Inilah sebabnya mengapa pembaruan JVM merusak aplikasi.

Menambahkan dukungan untuk bahasa tersebut tidak menambah nilai pada mesin.

Jika argumennya adalah "moar Unity devs"; maka dokumentasi harus dibuat untuk membantu transisi pengembang Unity; perbedaan tata letak, dll.

Itulah mengapa saya mengatakan pada akhirnya, tidak masalah bahasa apa yang Anda gunakan, Anda masih perlu mempelajari kelas Godot API dan semuanya. Bukankah pengembang Unity akan menjadi ahli insta karena mereka tahu C#. Saya kira lebih merupakan "aura kebaikan" untuk Godot jika mendukung C#. Orang-orang merasa seperti mereka tahu lebih banyak dan tiba-tiba Godot lebih mudah diakses dan tidak begitu menakutkan lagi. Hal negatif no 1 tentang Godot dari pengguna non Godot adalah ia memiliki bahasa skrip sendiri. Sebagai pengguna Godot tahu bahwa BS karena GDScript adalah bahasa yang menyenangkan dan sederhana tetapi bagi orang luar mungkin tampak tidak menarik.
Saya tidak dapat berbicara dari sudut pandang dev tetapi mungkin lebih banyak usaha daripada yang layak kecuali devs mendapatkan sesuatu dari mengimplementasikan C # maka itu sepadan. Pada akhirnya adalah keputusan pemimpin pengembang dan apa pun yang mereka putuskan, saya akan mengikutinya. Saya yakin itu akan menjadi keputusan yang baik.

Saya setuju dengan Anda tentang GDScript yang sedikit mengecewakan karena ini sebenarnya bahasa yang tidak dikenal. Namun, setelah saya membaca mengapa Lua dan Python dihapus dan keuntungan menambahkan GDScript, saya tidak terlalu khawatir.

Hal lain yang mungkin relevan: ada mesin berlisensi MIT lain yang sudah mendukung C# dan lebih mirip dengan Unity, Atomic Game Engine . Saya menyarankan agar semua orang yang sangat membutuhkan sesuatu yang sedekat mungkin dengan Unity mencobanya.

Saya hanya akan menambahkan 2 sen saya di sini. Bagi saya, keuntungan besar dari C# adalah kinerja, sementara masih lebih mudah digunakan daripada C++. GDScript, diketik secara dinamis dan semuanya, sangat cepat untuk ditulis, tetapi tidak akan pernah menjadi sangat cepat untuk dijalankan (meskipun dapat dioptimalkan cukup banyak, yang direncanakan). Modul C++ sangat cepat, tetapi agak canggung untuk digunakan; C++ bukan bahasa yang ramah, dan harus mengkompilasi ulang mesin untuk menggunakannya tidak terlalu optimal. Bagi saya, C# adalah semacam kompromi: jauh lebih cepat daripada GDScript, dan dengan dukungan yang tepat, jauh lebih mudah untuk digunakan daripada modul C++.

Semua itu dikatakan, tidak harus C#. Apa pun yang memiliki efek serupa akan baik-baik saja, sejauh yang saya ketahui, baik itu kompilasi yang diketik secara statis/JIT GDScript, atau sesuatu yang lain seperti Swift atau sesuatu. C# mungkin yang terbaik untuk 'tujuan pemasaran'; bahkan tanpa API serupa, pengembang dari mesin/kerangka kerja lain mungkin akan lebih nyaman dengannya. GDScript yang dimodifikasi mungkin lebih mudah diterapkan, dan mungkin akan terintegrasi jauh lebih baik.

Saya tahu bahwa utasnya sangat panjang sekarang, tetapi harap baca semua posting di atas sebelum memposting sesuatu sendiri. Argumen bahwa C# akan menarik orang dan sangat nyaman bagi pengguna Unity tidak lagi valid jika disebutkan belasan kali lebih banyak.

Lihat di sini mengapa imho C# bagus untuk Unity dan buruk untuk Godot, lihat di sini mengapa imho menambahkan C# akan menyebabkan kode kotor, tidak hanya di proyek Anda sendiri tetapi juga di tutorial online, toko aset yang akan datang, dll. dan lihat di sini mengapa imho argumen bahwa orang harus belajar banyak hal baru ketika mengubah dari C# ke GDScript tidak valid.

Izinkan saya menambahkan komentar pada argumen bahwa C# akan membawa orang baru.
Mengapa kita ingin lebih banyak orang menggunakan Godot? Saya benar-benar mengerti bahwa proyek open source membutuhkan komunitas yang

• menambahkan fitur
• memperbaiki bug
• menciptakan aset yang dapat digunakan kembali
• membuat saran untuk fitur baru
• menemukan bug atau masalah dengan alur kerja
• menulis tutorial

tetapi semua hal di atas membutuhkan orang yang mengerti dan menghargai ide inti dari mesin. Orang-orang yang menambahkan fitur yang tidak perlu ke perpustakaan tidak membantu dan ada lebih dari satu proyek yang menderita fitur tersebut, terkadang sampai pada titik di mana proyek ditinggalkan atau dipecah.
Unity terutama menderita dari orang-orang yang menulis tutorial meskipun mereka tidak benar-benar mengerti apa yang mereka lakukan, yang sebagian besar adalah kesalahan C#.

Jika orang bahkan tidak mau atau tidak mampu belajar bahasa sesederhana GDScript maka sangat dipertanyakan apakah mereka akan meluangkan waktu untuk sepenuhnya memahami filosofi desain di balik Godot sebelum mereka mulai berkontribusi secara aktif kepada komunitas. ("Berkontribusi secara aktif" berarti apa saja mulai dari mengirim permintaan penarikan hingga memposting pendapat mereka tentang Godot di Facebook.)

Godot bukan mesin komersial. Unity memiliki kepentingan untuk mendatangkan orang sebanyak-banyaknya karena mereka semua adalah calon pelanggan dan pengiklan untuk mesin tersebut. Pasti menyenangkan memiliki komunitas besar pengguna yang menghargai Godot apa adanya, tetapi tidak ada gunanya mengorbankan beberapa kualitas Godot untuk melayani komunitas yang lebih besar.

@Warlaan orang umumnya tidak ingin membuang waktu dan mereka akan menggunakan potongan kode apa pun yang mereka temukan ketika membangun proyek mereka terutama di awal ketika Anda sedang belajar. Untuk pemula, poin Anda agak relevan karena mereka pada akhirnya akan mempelajari bahasa apa pun yang digunakan untuk menulis cuplikan kode. Saya tahu ini karena itulah cara saya belajar melihat contoh dan saya tidak tahu Skrip GD tetapi saya mempelajarinya. Masalahnya bukan apa yang terbaik atau bagaimana ini akan berdampak atau memperumit tutorial dll. Masalahnya (bagi saya) adalah C# lebih dari bahasa lain akan membuat Godot bagian dari ekosistem dev indie Unity adalah bagian dari. Ini bahkan bukan tentang Unity, ini tentang Godot.

EDIT: menghapus beberapa bahasa kasar yang tidak perlu ;-)

@trollworkout Jangan tersinggung, tetapi Anda tidak benar-benar memahami maksud saya dan saya merasa bahwa Anda juga tidak benar-benar memikirkan apa yang Anda katakan.

1. Ya, orang tidak ingin membuang waktu. Spesifikasi lengkap GDScript: beberapa layar. Buku yang menjelaskan C#: biasanya minimal 500 halaman. Saya telah menghabiskan beberapa hari mempelajari GDScript dan saya cukup yakin bahwa itu tidak memiliki satu fitur pun yang saya tidak tahu. Saya telah bekerja baik secara profesional maupun di waktu luang saya dengan C# selama bertahun-tahun sekarang (menggunakan Formulir Jendela, WPF, XNA, dan Unity) dan saya masih menemukan potongan kode yang menggunakan fitur yang belum sepenuhnya saya pahami. Meminta C # karena tidak membuang-buang waktu tidak masuk akal.
2. "pemula akhirnya akan mempelajari bahasa apa pun yang digunakan untuk menulis cuplikan kode" - lihat poin 1. Gagasan bahwa Anda dapat mempelajari C# dari cuplikan kode jauh dari kebenaran. Hal-hal yang dapat Anda pelajari dengan cara itu sangat mendasar sehingga tidak perlu lebih dari beberapa hari untuk "mempelajari" bahasa yang berbeda. Anda sendiri yang mengatakan bahwa Anda mempelajari GDScript seperti itu.
3. "C# akan menjadikan Godot bagian dari ekosistem pengembang indie ini". Dan apa artinya itu?
   Bisakah Anda menggunakan cuplikan kode Unity di C#-Godot? Tidak.
   Bisakah Anda menggunakan kembali aset Unity di C#-Godot? Tidak.
   Bisakah Anda membaca tutorial Unity dan menerapkannya kata demi kata ke C#-Godot? Tidak.
   Jadi apa "ekosistem pengembang indie" yang Anda maksud?

Seperti yang dikatakan pengemis kertas, ada banyak mesin dan perpustakaan untuk dipilih.
Apakah Anda menginginkan sistem komponen seperti Unity? Lihatlah Mesin Game Atom.
Apakah Anda ingin tetap menggunakan C# di mesin tetapi ingin membuang sistem komponen? Lihatlah CryEngine / Luberyard.
Apakah Anda ingin tetap menggunakan C# tetapi ingin membuang mesinnya? Lihat MonoGame.

Pemikiran bahwa menambahkan C# ke Godot membantu pemula adalah salah, karena Anda sendiri yang mengatakan bahwa Anda belajar scripting di Godot dengan melihat potongan kode. Jika itu cara Anda belajar bekerja dengan mesin, tidakkah Anda menginginkan bahasa yang secara implisit memberi tahu Anda cara kerja mesin daripada bahasa yang dirancang untuk ribuan kasus penggunaan yang berbeda?

Saya hanya akan menambahkan 2 sen saya di sini. Bagi saya, keuntungan besar dari C# adalah kinerja, sementara masih lebih mudah digunakan daripada C++. GDScript, diketik secara dinamis dan semuanya, sangat cepat untuk ditulis, tetapi tidak akan pernah menjadi sangat cepat untuk dijalankan (meskipun dapat dioptimalkan cukup banyak, yang direncanakan). Modul C++ sangat cepat, tetapi agak canggung untuk digunakan; C++ bukan bahasa yang ramah, dan harus mengkompilasi ulang mesin untuk menggunakannya tidak terlalu optimal. Bagi saya, C# adalah semacam kompromi: jauh lebih cepat daripada GDScript, dan dengan dukungan yang tepat, jauh lebih mudah untuk digunakan daripada modul C++.

Semua masalah yang Anda sebutkan dengan C++ yang Anda sebutkan adalah valid dan dapat diperbaiki melalui #3936. Kami telah membahas ini berkali-kali, tetapi hanya untuk kejelasan, berikut adalah masalah dengan GDScript yang dapat kami kenali secara objektif:

1. Dukungan yang buruk untuk perpustakaan pihak ketiga
2. Penampilan buruk

Mampu menulis bagian dalam C++ dengan mudah memperbaiki keduanya. C# (atau bahasa lain) juga akan memperbaikinya, tetapi dengan runtime tambahan, kinerja yang lebih buruk dan dukungan lintas platform dan banyak pekerjaan tambahan yang diperlukan (sedangkan Godot sudah ditulis dalam C++). Jadi pilihan rasional adalah menggunakan apa yang sudah ada (C++) dan membuatnya lebih baik, dan tentu saja memperbaiki masalah tersebut dengan GDScript.

Saya dengan cepat membaca utas ini, dan melihat bahwa GDScript ke C telah dibayangkan.

Jika ini cara yang dipilih, sebaiknya pertimbangkan untuk menyematkan kompiler tcc C di editor untuk mengkompilasi C yang dihasilkan. Ini memiliki waktu kompilasi yang sangat cepat, sangat kecil dan mudah disematkan. Mungkin ini cara terbaik untuk mempercepat.

TCC didistribusikan di bawah GNU Lesser General Public License.

(sumber)

Ini membuatnya mungkin tidak cocok untuk dimasukkan ke dalam Godot. Itu juga sepertinya tidak dipertahankan lagi.

@Warlaan Saya tidak perlu berpikir terlalu banyak. Pada titik ini kami semua mengatakan hal yang sama sekitar 10 kali. Saya pikir kami cukup tahu apakah kami semua berdiri. Selain 2 sen saya dan beberapa ide, saya tidak punya banyak kontribusi lagi karena saya bukan pengembang dan saya tidak tahu mesin luar dalam dengan baik. Aku akan membiarkan mereka yang tahu lebih baik berbicara. Saya hanya ingin menyuarakan dukungan saya dan itu saja.
Keluar topik:
Tapi ya dalam hal poin 2. yang membuat Anda banyak ribut tentang itu Anda harus mengedit komentar Anda. JADI Anda mengatakan Anda tidak bisa belajar bahasa berdasarkan contoh? Saya pikir Anda MENANGGUNG orang tidak dapat mempelajarinya kecuali mereka membaca manual 500 halaman yang C# dikenal karena Anda mengatakan alasan 1 untuk menolaknya. Yah, saya adalah bukti hidup bahwa Anda salah. Menurut Anda bagaimana saya belajar GDScript? Dengan API dan contoh demo dan bertanya-tanya. Ingat, saya memiliki 0 pengetahuan Python sebelum saya memulai, jadi segala sesuatu tentangnya sangat asing. Sebagai catatan tambahan, saya bertanya-tanya berapa banyak orang yang membeli manual libGDX vs berapa banyak orang yang benar-benar google "bagaimana melakukan X di libGDX" mungkin mengapa toko aset sangat buruk di Unity. Dan dengan itu saya sudah selesai untuk saat ini karena saya tidak punya apa-apa lagi untuk dikatakan.

( @Calinou : Bellard mengizinkan fork TCC menjadi BSD atau MIT. Tapi terakhir kali saya periksa, pengembang fork tersebut tidak merilis sourcecode. Jadi, mungkin Bellard akan menerima untuk membiarkan komunitas Godot melisensikan TCC juga ?)

Saya tidak yakin TCC sebagus GCC atau Dentang sebagai kompiler - ukurannya mendukung banyak arsitektur dan untuk pembuatan kode yang cukup optimal (kinerja lebih baik).

Bagaimana dengan Godot secara opsional tergantung pada GCC atau Dentang untuk mengkompilasi C? Mereka diinstal pada mesin kebanyakan orang yang akan membangun game (jadi ukuran tidak terlalu menjadi perhatian), dan itu adalah cara bahasa lain yang dikompilasi ke C (seperti Chicken ) melakukannya. Mereka juga mendukung C++, jika diperlukan.

Jika mereka dijadikan dependensi opsional, mereka yang tidak menginstal GCC atau Dentang (yang aneh bagi pengembang yang seharusnya membuat game untuk distribusi, tapi bagaimanapun) bisa menggunakan penerjemah GDScript seperti sekarang.

Saya menyarankan menggunakan TCC sebagai JIT untuk GDScripts. Jadi fitur yang paling penting adalah kecepatan kompilasi. Dan saya pikir hasilnya sudah bisa jauh lebih cepat daripada solusi saat ini.

Kebanyakan orang menginginkan C / C++ untuk kinerja dan Lua / Javascript agar lebih mudah dan lebih cepat untuk menulis, jadi mengapa tidak memiliki yang terbaik dari kedua dunia?

Nim - http://nim-lang.org/

Efisien seperti C, ekspresif seperti Python dan fleksibel seperti Lisp

Kelebihan:

• Kompilasi menjadi C, C++, Obj-C atau JS ( http://nim-lang.org/docs/backends.html )
• (Python / Pascal) suka ( https://learnxinyminutes.com/docs/nim/ )
• GC atau Manual ( http://nim-lang.org/docs/gc.html )
• Dapat digunakan di tempat lain selain godot
• Lintas Platform (windows, linux, osx, seluler)
• Membantu mengubah kode C menjadi Nim
• Mendukung C lib
• Kompiler yang dapat di-tweak
• Berlisensi MIT
• Sumber terbuka
• Jenis-aman

Kontra:

• Membutuhkan kompiler C/C++ di komputer pengembang -> gcc , vcc , llvm_gcc , icc , clang atau ucc _(tidak benar-benar penipu, menurut saya)_
• Komunitas kecil
• Belum 1.0

Daftar TODO Nim kecil, mendekati 1.0:
https://github.com/nim-lang/Nim/blob/devel/todo.txt

seperti yang dikatakan orang miskin kertas (tentang memiliki kompiler di komputer pengembang):

Mereka dipasang di mesin kebanyakan orang yang akan membangun game
https://github.com/godotengine/godot/issues/5081#issuecomment -227706106

https://hookrace.net/blog/what-is-special-about-nim/
https://hookrace.net/blog/what-makes-nim-practical/

https://github.com/nim-lang/Nim/wiki/Nim-for-C-programmers
https://github.com/nim-lang/Nim/wiki/Nim-for-Python-Programmers

Ini bukan solusi favorit saya, tetapi jika Anda harus menempuh jalan itu, saya sangat menyarankan Anda menggunakan Haxe ( haxe.org ) daripada Nim.

Saya tidak dapat mengomentari lisensi Haxe (kompiler itu sendiri menggunakan "GPLv2+", perpustakaan standar menggunakan MIT), tetapi semua faktor lain menjadikannya pilihan yang lebih baik.
Ini adalah platform yang diuji (saat ini dalam versi 3.2.1) dibandingkan dengan Nim yang bahkan belum versi 1.0, tetapi yang bagi saya jauh lebih penting sintaksnya jauh lebih dekat dengan bahasa terkenal lainnya. Membaca contoh Nim, bagi saya tampaknya pengembang di balik bahasa itu mencoba menemukan solusi yang tidak biasa dan/atau jelek.

Tetapi seperti yang saya sebutkan itu bukan solusi favorit saya dan inilah alasannya:
Bahasa perantara seperti Nim atau Haxe memiliki banyak "ketergantungan semantik". Maksud saya bukan ketergantungan pada perpustakaan atau executable yang perlu ada, maksud saya mereka berhubungan dengan bahasa lain. Sekarang seperti yang saya katakan sebelumnya, bahasa bukan lagi alat, melainkan budaya. Dan bahkan jika Anda hanya melihatnya sebagai alat, mereka memiliki domain inti yang berbeda tempat mereka dibuat. Misalnya, benar-benar masuk akal bahwa perintah "echo" mencetak teks ke output standar ketika dimasukkan pada input standar. Ini hanya konsekuensial untuk menggunakan perintah yang sama dalam skrip batch. Mengikuti logika itu dapat dimengerti bahwa PHP menggunakan perintah yang sama. Menggunakannya dalam bahasa tujuan umum seperti Nim tidak masuk akal, karena pada dasarnya semua bahasa tujuan umum lainnya memiliki metode yang disebut sesuatu dengan "tulis" atau "cetak" dalam namanya.
Saya tidak tahu mengapa Nim masih menggunakan "echo" sebagai nama untuk perintah itu, tetapi ini adalah hal yang dapat Anda amati banyak dengan Haxe dan yang saya harapkan dari Nim di masa depan jika belum di rilis pertama . Misalnya perpustakaan standar Haxe berisi metode substr(int, int) dan substring(int, int)-metode. Salah satu dari keduanya mengembalikan substring dari indeks pertama ke indeks kedua, yang lain mengembalikan substring dari indeks pertama dengan panjang argumen kedua. Alasan mengapa keduanya ada adalah karena bahasa tersebut dapat digunakan untuk menggantikan bahasa dari jenis yang berbeda, ia memiliki pengguna yang berasal dari platform yang berbeda, dan kecuali jika ada seseorang dengan tangan yang sangat kuat memutuskan apa yang masuk ke perpustakaan sumber terbuka itu dan apa yang tidak. Anda akan dengan mudah berakhir dengan campuran gaya pengkodean seperti itu.

Sangat penting untuk memilih alat yang tepat untuk pekerjaan yang tepat. Bahasa seperti Haxe (atau C# dalam hal ini) mencoba memberi Anda satu bahasa yang cocok untuk semua, jadi lebih sering daripada tidak, Anda akhirnya menggunakan "hanya satu alat" yang sayangnya terlihat seperti ini .

Saya ingin menambahkan 2 sen saya setelah bekerja dengan Godot untuk sementara waktu.
Apa yang ingin saya lihat (dan juga telah saya lihat, dengan... keberhasilan terbatas) adalah C++ sebagai bahasa kelas satu di Godot.
Menulis logika komputasi-berat (pemecahan tabrakan, fisika, transformasi, dan AI) dalam C++ dan membuat skrip node menggunakan GDScript (pemicu, kondisi, animasi, dan suara).

GDScript IS cukup mudah dipelajari, menempatkan Godot sedikit lebih dekat dengan Gamemaker daripada Unity dalam hal itu.
Tapi setelah menulis 3 game kecil dan bermain-main dengan banyak demo, saya harus mengatakan bahwa GDScript kurang untuk apa pun di luar game yang sangat mendasar.

File kode menjadi terlalu panjang dan editor kode tidak memiliki banyak fitur berguna yang ditemukan di IDE lain seperti: cakupan runtuh, wilayah, melompat ke awal/akhir cakupan saat ini.

GDScript juga tidak memiliki banyak fitur dasar bahasa prosedural seperti: _ yang tepat untuk _ loop, tepat _ do... while _ loop (mendukung _ while _ loop), _ switch...case _, _ operator ternary _ , _ pencacahan _.
_ Tidak ada kesadaran hubungan kelas-adegan _ jadi jika tidak dibuat sebelumnya, itu adalah kelas "eksternal" dan harus dimuat sebelumnya.

Juga, mengingat sifat GDScript, tidak ada referensi fungsi dan tidak ada templating.
Tidak ada pertunjukan-menghentikan tapi itu sangat menjengkelkan.

mata776; GDscript hanya tidak dapat digunakan untuk lebih dari game sederhana jika Anda memutuskan untuk mengabaikan fitur lain (seperti menggunakan node dan callback jika memungkinkan) alih-alih hanya menggunakan fungsi seperti _get_overlapping_bodies()_

Alasan mengapa panggilan balik dan penggunaan node tersebut jauh lebih cepat daripada mencoba melakukan semuanya dengan satu skrip besar dan sangat sedikit node. Pohonnya menjadi lebih besar, tetapi itu bukan masalah dengan sistem instance adegan Godot.

Misalnya, objek yang membutuhkan kecepatan rotasi konstan dapat menggunakan animasi untuk itu daripada mengatur rotasi secara manual menggunakan GDscript, hal-hal yang bergantung pada waktu dapat menggunakan node timer dan sebagainya. Saya pikir satu cara langsung (dan langsung) untuk memungkinkan permainan yang lebih cepat adalah lebih banyak jenis simpul untuk dipilih (masing-masing dengan panggilan balik dan koneksi mereka sendiri).

File kode terlalu panjang

Apakah maksud Anda skrip seperti ini? https://github.com/Algorithmus/CastlevaniaClone/blob/master/game/players/player.gd
Apakah menurut Anda C# dapat mencegah hal ini terjadi? Secara pribadi saya tidak. Sebenarnya lebih mudah untuk memfaktorkan ulang dan mendeteksi kesalahan lebih awal dalam skrip panjang ini karena perkakas (ya, ketika orang-orang bermaksud C#, mereka sering berarti VS secara implisit) dan pengetikan statis, meskipun kesalahan jalur simpul tidak akan terdeteksi sampai permainan berjalan. Namun selain itu, desain dan penggunaan node yang baik dapat sangat menyederhanakan skrip.

editor kode tidak memiliki banyak fitur berguna yang ditemukan di IDE lain seperti: cakupan runtuh, wilayah, melompat ke awal/akhir cakupan saat ini.

Ini dapat ditambahkan di masa mendatang jika Anda memintanya, meskipun Anda dapat menggunakan editor eksternal tanpa masalah (https://atom.io/packages/lang-gdscript), Godot bahkan memiliki layanan pelengkapan otomatis.

Jika Anda benar-benar membuat game BESAR, kemungkinan besar Anda ingin memperluas Godot menggunakan C++.
Sebenarnya, saya merasa ini agak menakutkan saat ini karena proses pembuatan ulang mesin, tetapi ada alasan untuk itu .

Tidak ada kesadaran hubungan kelas-adegan

Maksud kamu apa? Anda tahu Anda bisa meletakkan skrip di akar sebuah adegan, bukan? Juga editor C# tidak dapat menebak apa yang ada di adegan di mana mereka digunakan, sementara GDScript bisa.

Juga, mengingat sifat GDScript, tidak ada referensi fungsi dan tidak ada templating.

Ada funcref dan signal jika Anda mencari sesuatu yang mirip dengan lambda dan acara, dan templating bukan masalah karena bahasanya dinamis. Bahasa dinamis sering kali lebih suka menggunakan pengetikan bebek daripada antarmuka dan generik. Juga, komposisi atas pewarisan bermain sangat baik jika Anda ingin hal-hal yang dapat digunakan kembali.

GDScript juga tidak memiliki banyak fitur dasar bahasa prosedural

Saya setuju sedikit. Beberapa dari mereka telah diminta tetapi saya tidak ingat masalahnya, Anda harus mencari. Misalnya saya ingin melihat for yang dapat beralih pada sesuatu selain rentang integer dan wadah (float?), jadi saya menggunakan while . Itu memang agak mengganggu tapi tidak ada yang terlalu serius.

Apakah maksud Anda skrip seperti ini? https://github.com/Algorithmus/CastlevaniaClone/blob/master/game/players/player.gd

Saya harus mengatakan bahwa meskipun filenya panjang, saya telah melihat yang jauh lebih buruk dan masih cukup mudah dibaca meskipun kodenya cukup prosedural. Sekarang saya akhirnya mengerti mengapa sintaks sederhana lebih baik untuk GDScript: ini yang terbaik untuk logika permainan rata-rata, yang sebagian besar if s dan panggilan fungsi.

Saya ingin melihat siapa pun berpendapat bahwa file yang sama yang ditulis dalam C # lebih mudah dibaca atau ditulis, atau menawarkan keuntungan praktis selain kinerja (yang lebih buruk daripada C++). Saya pikir C# akan berlebihan untuk jenis skrip ini, yang lebih rumit daripada skrip yang ada di beberapa game 2D profesional.

Saya setuju sedikit. Beberapa dari mereka telah diminta tetapi saya tidak ingat masalahnya, Anda harus mencari. Misalnya saya ingin melihat for yang dapat beralih pada sesuatu selain rentang integer dan wadah (float?), jadi saya menggunakan while. Itu memang agak mengganggu tapi tidak ada yang terlalu serius.

Bisakah Anda menjelaskan lebih dalam pada bagian for dan beberapa contoh dari apa yang Anda maksud di pseudo-GDScript?

@paper-pauper hal-hal yang tidak dimiliki GDScript tidak terkait dengan C#, tetapi misalnya for i in range(-PI, PI) tidak berfungsi di GDScript, serta for i=0, i < size and stuff, ++i . Saya juga ingin menulis ternary daripada harus menulis tiga baris-jika. Tapi seperti yang saya katakan, sudah ada masalah di pelacak untuk itu dan itu tidak akan menghentikan saya menggunakan GDScript :p

Tetapi bahkan jika Anda semua skrip Anda adalah 200 baris maks dan dirancang dengan relatif baik, jika Anda memiliki ribuan skrip di game Anda, Anda akan kesulitan mempertahankan dan memfaktorkan ulang basis kode itu: dan ini bukan karena bahasanya, tetapi karena alat : Sebagian besar popularitas C# adalah karena Visual Studio adalah IDE yang bagus untuk itu. Saya cukup yakin jika Godot mengintegrasikan alat yang sesuai (definisi goto, penggantian nama kelas/fungsi/anggota yang andal, temukan semua referensi, dll), mengerjakan basis kode GDScript yang besar akan menjadi jauh lebih mudah. Secara umum, inilah yang ingin saya lihat di Godot, bagaimana skalanya dengan baik untuk game BESAR, karena sejauh ini saya belum melihatnya (termasuk proyek saya sendiri).

for i in range(-PI, PI)

Itu membuat kepalaku berputar pada porosnya hingga mencapai pembagian nol dan mulai menghancurkan entropi. Saya harap tidak ada bahasa yang mengimplementasikan pernyataan yang tidak terduga seperti itu. Apa fungsinya? Ulangi bilangan bulat antara -PI dan PI (yaitu -3, -2, ..., 2, 3), atau di antara kelipatan PI (yaitu -PI dan 0), atau apakah iterate over float yang seperti langkah default voodoo 0.176 atau ln(2) yang menurut beberapa programmer bahasa paling tepat?

@akien-mga maaf. Saya seharusnya menambahkan argumen langkah memang xD tetapi masih tidak berhasil. Inilah masalah yang saya buat untuk itu https://github.com/godotengine/godot/issues/4164

Saya setuju bahwa yang dirindukan Godot adalah perkakas. Masalah utama adalah sifat mengetik bebek dari GDScript, yang membuatnya lebih sulit untuk mengetahui apa itu dan dengan demikian mempersulit untuk melakukan beberapa tindakan seperti "menemukan referensi" atau "menuju definisi".

Direncanakan untuk menambahkan petunjuk jenis ke GDScript, tetapi karena ini opsional, saya tidak yakin seberapa banyak yang dapat ditingkatkan. Ini pasti akan melakukan banyak hal untuk penyelesaian kode dan dapat memudahkan pekerjaan pada perkakas yang lebih baik.

@vnen Mode EMACS untuk GDScript di (M)ELPA sudah akan menjadi langkah ke arah yang benar, dalam buku saya :)

Oh ya hampir lupa tentang dua masalah ini yang, cukup lucu, sebenarnya memperlambat saya dalam latihan:

• Argumen bukan bagian dari tanda tangan fungsi. Itu berarti Anda tidak dapat mengganti fungsi.
  Dalam praktiknya memiliki function doFoo(a,b,c,d) dan function doFoo(a,b) di kelas yang sama akan mengakibatkan kegagalan kompilasi. Saya akhirnya mengganti nama mereka menjadi doFoo4(a,b,c,d) dan doFoo2(a,b) dan memfaktorkan ulang banyak file skrip.
• Karena tidak ada dukungan untuk enumerasi, semua flag dan kode pengembalian, karena kebutuhan, adalah int sehingga Anda harus menebaknya dan banyak yang masih belum terdokumentasi saat ini.

PS: Jelas fungsinya tidak secara harfiah bernama doFoo . ;)

EDIT: @Ace-Dragon: Mesin lain telah mengajari saya bahwa simpul/komponen bawaan yang rumit/dll. bisa dan akan berubah, merusak permainan dalam prosesnya. Itu sebabnya selain panggilan balik pemicu dasar (tabrakan, nilai, penghitung waktu), saya lebih suka menghindari terlalu mengandalkannya.
Saya juga bukan penggemar paradigma slot sinyal, jadi saya cenderung menghindarinya jika memungkinkan. Kemudian lagi saya juga lebih suka utas daripada coroutine, panggil saya luddite :)

@Zylann : ~1200 LOC?... pffft Tidak, saya sedang berbicara tentang real deal... 20k+ LOC per file. Pengembang RPG yang menggunakan Unity, yang akan tetap tidak disebutkan namanya (tidak, saya tidak bekerja untuk mereka), secara rutin memiliki kelas dengan 25k+ loc. Kemudian lagi mereka membuat semua fungsinya statis dan menggunakan C# seolah-olah C. :takut:

Maaf untuk di luar topik.

@ eye776 Saya tidak dapat memikirkan bahasa dinamis apa pun yang memungkinkan penggantian (dalam beberapa kasus dapat dipalsukan dengan argumen default), tetapi akan lebih baik untuk memilikinya di GDScript.

Dan perubahan game-breaking pada mesin dapat dengan mudah dideteksi dan dikembalikan dalam program gratis seperti Godot, jadi tidak perlu khawatir.

@ eye776 Saya juga tidak pernah melihat bahasa dinamis dengan fungsi utama. GDScript memiliki parameter default, sehingga dapat digunakan sebagai gantinya.

Juga, siapa yang gila melakukan 20K+ LOC dalam satu file? Masalahnya di sini bukan pada alatnya... Di seluruh sumber Godot tidak ada satu file pun yang dapat saya temukan dengan 10K LOC.

Yang saya setujui adalah memberi C++ sedikit lebih banyak cinta. Tetapi untuk penggunaan yang Anda sebutkan sebelumnya, saya hanya setuju dengan AI. Dan juga generasi prosedural, untuk mengutip satu lagi. Sekarang jika Anda membuat ulang fisika mesin, rendering, dll. maka saya katakan Anda bahkan tidak menggunakan Godot lagi, Anda hanya melakukan fork. Jika Anda tidak dapat mengandalkan tipe bawaan, untuk apa Anda membutuhkan mesin?

Tentu saja, GDScript tidak sempurna (tidak ada bahasa). Itu juga tidak diukir di batu. Enumerasi, operasi switch/case dan ternary adalah beberapa kemungkinan tambahan di masa depan (sudah ada masalah terbuka tentang itu). Hanya karena ia tidak memiliki sesuatu saat ini, bukan berarti ia tidak akan pernah memilikinya.

Akhirnya, "keraguan" tidak terlalu membantu. Yang kita butuhkan adalah benchmark dan use case. Sudah ada game yang cukup rumit yang ditulis dalam GDScript, jadi saya tidak melihat apa yang sebenarnya hilang.

@vnen hanya untuk bersenang-senang: godot/drivers/gles2/rasterizer_gles2.cpp adalah 11K LOC :p (ini yang terbesar yang saya temukan, tapi ini pengecualian yang jarang terjadi).

@vnen

Jika Anda tidak dapat mengandalkan tipe bawaan, untuk apa Anda membutuhkan mesin?
Nah, sebagai konteks lintas platform yang berkualitas sebagai permulaan. Tapi itu tidak berarti saya akan menulis sprite atau kelas model saya sendiri.

Godot memang membakar saya sekali di bulan Maret (v 2.0.1). Saya bermain-main dengan kamera & karakter orang ke-3 dan mencoba menggunakan fisika Godot sendiri untuk gerakan (seret dan kekuatan) dan membuatnya bekerja.
Pembaruan versi minor berikutnya (v 2.0.2) pada dasarnya mematahkan kecepatan karakter (2-3x lebih cepat) untuk nilai yang sama persis.
Saya pikir lebih baik menyimpannya sebagai Kinematic dan melakukan "fisika" saya sendiri.

Juga, tidak terkait dengan Godot, saya sering terbakar mengandalkan hal-hal otomatis seperti storyboard XCode.
Saya agak berhenti dirayu oleh yang mengkilap dan berdoa kode apa pun yang dibuat secara otomatis oleh IDE di belakang saya tidak mengacaukan milik saya.

Pokoknya, saya benar-benar minta maaf karena menggagalkan utas.

@eye776 Apakah Anda memeriksa perbedaan komit dari 2.0.1 ke 2.0.2 untuk melihat apa yang merusak permainan Anda? Itu bisa jadi bug dan melaporkannya bisa bermanfaat bagi seluruh komunitas.

Mono atau CoreCLR? Dan mengapa?

Mono:

• berlisensi MIT
• stabil
• kemungkinan ditinggalkan
• dokumentasi yang bagus

IntiCLR:

• berlisensi MIT
• masih belum 1.0 (saat ini RC2)
• kecil
• dokumentasi yang buruk

Kami menggunakan Mono karena itu menyebar ke seluler dan web. Saya pikir di sini adalah
tidak ada kemungkinan ditinggalkan karena jauh lebih portabel. firasatku
adalah bahwa kedua basis kode pada akhirnya akan bergabung.

Pada Thu, 4 Agustus 2016 di 13:45, Hubert Jarosz [email protected]
menulis:

Mono atau CoreCLR? Dan mengapa?

Mono:

• berlisensi MIT
• stabil
• kemungkinan ditinggalkan
• dokumentasi yang bagus

IntiCLR:

• berlisensi MIT
• masih belum 1.0 (saat ini RC2)
• kecil
• dokumentasi yang buruk

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/godotengine/godot/issues/5081#issuecomment -237611905,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AF-Z2zRjC8u_owFzCCyeqIhF8W5XqCtLks5qchchgaJpZM4Ivn7R
.

Selain apa yang @reduz sebutkan di atas, API dienkapsulasi sehingga tidak terlalu sulit untuk diubah ke CoreCLR nanti jika diperlukan.

CoreCLR: masih belum 1.0 (saat ini RC2)

Mencapai 1,0 stabil pada 14 Juni.

Mono: kemungkinan ditinggalkan

Berdasarkan apa?

Mono: dokumentasi yang bagus

ahahah

Berdasarkan apa?

Mengapa Microsoft akan mengembangkan tiga tumpukan .NET? Ini tidak baik dari segi sumber daya. (.NET Framework, Mono, .NET Core)

ahahah

Saya telah memeriksa kedua dokumen tentang interop C++/C# (apa yang kami butuhkan untuk godot) dan cukup baik didokumentasikan dalam Mono. Di coreCLR saya harus menggali beberapa kode mereka dan meminta bantuan pengembang agar aplikasi saya berfungsi.

Panduan referensi memiliki terlalu banyak fungsi yang tidak terdokumentasi, tautan rusak...

Secara teori saya bias di sini ... Tapi saya harap argumen saya objektif ...

• Saya tidak melihat adanya penurunan dalam pengembangan Mono: https://github.com/mono/mono/graphs/contributors
• Pengembangan untuk Mono di Windows tidak pernah sekuat sekarang (agak bukti (tanpa menghubungkan banyak komitmen) https://github.com/mono/mono/pull/3231 Miguel mengatakan "karena kami sekarang memiliki pengelola nyata") Membuat poin sebelumnya lebih jelas
• Menyematkan API di Mono diuji dalam pertempuran (bukan hanya Unity, ada banyak pengguna pribadi lainnya)
• Mono TODAY berjalan di PS4, Android, Windows, iOS BITCODE (bertahun-tahun bekerja untuk ini), AppleTV dan banyak lagi platform...

Jadi, jika Anda ingin mewujudkannya dalam waktu dekat (kurang dari 3 tahun) di masa depan dan di sebagian besar platform game... Gunakan Mono.

Halo,

Beberapa komentar:

• Selain platform yang terdaftar oleh David Karlas, kami juga menambahkan dukungan asli WebAssembly, XboxOne, UWP, dan Win64.
• Sampel yang dibagikan dapat dilakukan juga dengan metode virtual (pengiriman lebih cepat) atau dapat dilakukan dengan acara C#.
• C# secara historis berada di depan banyak inovasi bahasa, menarik ide-ide bagus dari mana saja. Ini telah mempopulerkan dan membawa ke pasar massal banyak ide dari penelitian bahasa dan yang sekarang kita terima begitu saja, hal-hal seperti iterator, obat generik yang tidak terhapus, lambdas, pemrograman asinkron, properti, permintaan platform, tetapi merupakan salah satu bahasa yang paling aktif dikembangkan di depan umum . Misalnya, versi yang akan datang menambahkan banyak fitur baru, termasuk pencocokan pola favorit saya.
• Secara umum, Unity tidak menampilkan C# modern karena mereka menggunakan runtime yang lebih lama. Ini mudah-mudahan akan segera berubah. Yang mengatakan, Mono saat ini mendukung semua fitur C # baru, di antara pemrograman "async" yang ideal untuk kode game, karena Anda dapat menulisnya secara linier, dan kompiler secara otomatis menulis ulang kode Anda sebagai mesin negara - seperti coroutine atau lanjutan versi "hasil" seperti yang digunakan dalam Unity.
• Konteks sinkronisasi berarti Anda dapat menulis kode asinkron yang dijalankan dalam konteks tertentu. Misalnya, Anda mungkin memiliki eksekusi terikat game, atau eksekusi terikat IO, atau eksekusi terikat utas utama vs latar belakang, semuanya adalah bagian dari sistem.
• Saat menyebarkan, Anda memiliki pilihan kompilasi JIT, atau kompilasi statis (AOT) dengan atau tanpa LLVM, jadi Anda mendapatkan secepat C++ bisa, modulo fakta bahwa C# melakukan pemeriksaan batas array (yang mengatakan, jika Anda menggunakan asli buffer, Anda mendapatkan kembali kinerja Anda, dengan mengorbankan keselamatan)
• Selama beberapa tahun terakhir, mengingat fokus kuat Mono pada seluler, GC Mono telah disetel bukan untuk server, tetapi untuk beban kerja interaktif. GC baru kami bersifat generasi dengan pembibitan kecil yang dapat dikumpulkan dengan sangat cepat dan tidak perlu memindai seluruh tumpukan.

Adapun mengapa Microsoft mengembangkan beberapa CLR (kami memiliki tiga: CoreCLR untuk beban kerja JIT; Keluarga CoreRT, untuk kompilasi statis di UWP; Mono untuk beban kerja seluler) itu karena mereka semua tujuan server yang sedikit berbeda. Internal konvergen jika memungkinkan, misalnya, Mono kini telah menggantikan sekitar 60% dari kode inti dengan kode yang dibagikan secara langsung dengan sisa .NET. Ini hanya masalah untuk mengetahui beban kerja mana yang lebih cocok untuk Anda.

Anda dapat memulai dengan satu VM hari ini, dan beralih ke VM lain di masa mendatang. Saat ini Mono memiliki permukaan API yang lebih besar, berfungsi di seluler, telah dioptimalkan untuk beban kerja interaktif dan mendukung lebih banyak arsitektur (seperti ARM64).

Kabar baiknya adalah bahwa menukar satu VM dengan yang lain, atau mendukung keduanya membutuhkan beberapa hari kerja, jadi Anda tidak mengunci diri ke dalam satu implementasi tertentu.

@migueldeicaza Selamat datang! Luar biasa bahwa Anda memutuskan untuk berpartisipasi dalam diskusi kami dan bahwa Anda tertarik pada Godot :+1: Semoga Anda akan tinggal bersama kami untuk sementara waktu :)

Terima kasih atas perincian yang bagus @migueldeicaza! Saya punya dua pertanyaan singkat untuk Anda atau pengembang Mono lainnya.

1) Apa pengaturan saat ini untuk men-debug Mono tertanam di Windows dengan Visual Studio? Unity memiliki plugin mereka, tetapi saya belum dapat menemukan apa pun selain plugin yang terhubung ke mesin Linux/OSX.

2) Apa cara yang disarankan untuk menangani kompilasi ulang runtime (mengkompilasi, membongkar, dan memuat ulang, katakanlah perakitan untuk gameplay atau plugin alat di editor)? Sayangnya C# (sangat) tidak mengekspos metode Assembly.Unload() dan menangani AppDomains dan masalah lintas AppDomain tampaknya terlalu mengganggu untuk situasi ini.

Untuk referensi, Unity tidak hanya menggunakan Mono - https://github.com/xamarin/urho (C#/Mono bindings untuk mesin Urho3D) - yang ada di lisensi MIT, jadi kami dapat dengan mudah mencari solusinya.

Dua sen saya:

C# jauh lebih unggul untuk pemrograman game daripada bahasa tingkat serupa lainnya karena mendukung jenis nilai khusus. Ini adalah fitur yang sangat penting untuk kinerja, yang Java (dan JVM secara umum) secara harfiah memiliki _no_ alternatif untuk itu.

Anda mendapatkan:

• Jenis matematika yang dialokasikan dengan tumpukan, yang mendukung operasi matematika dan objek sementara tanpa alokasi tumpukan.
• Koleksi berkelanjutan yang dioptimalkan dan ramah cache.
• Generik menggunakan tipe nilai (termasuk tipe primitif)

Selain itu, C# memiliki fitur lain yang membuat hidup Anda lebih mudah. Saya melihat tidak ada gunanya menggunakan Java sebagai pengganti C# ketika C# hanya mengalahkan Java di hampir semua hal yang penting dalam pemrograman _game_.

Halo semua,
saya belum membaca semua hal di atas (terlalu banyak :))
tetapi saya memiliki beberapa hari libur jadi saya membuat modul prototipe untuk godot yang bertindak sebagai msDotNetHost, jadi saya dapat memberikan beberapa temuan yang telah saya lalui, mungkin itu membantu. sayangnya liburan saya berakhir dan saya harus mengkode uang lagi :), tapi itu menyenangkan :)

keadaan saat ini adalah:
o) modul memperluas Kelas Node untuk mengekspos peristiwa node ke netCode
(init, tree_entered, ready, process, fixedprocess....)),
o) "modul net host/wrapper" selesai (menggunakan mekanisme host Microsoft dotNet)
itu dienkapsulasi dalam perpustakaan dinamis, jadi beralih ke Mono akan mudah nanti
o) metode dotNet terikat dan dipanggil (init, tree_entered, ready, process, fixedprocess....)
o) kelas simpul dibungkus dan diikat ke netAssembly (kode tertulis manual untuk pembuatan prototipe)
o) panggilan ke godot (dari netCode) bekerja melalui mekanisme pengikatan yang ditulis sendiri
(dari dll ke godot-exe ) jadi exe tidak perlu mengekspor fungsi.
o) karena penggunaan msDotNet terikat ke windows untuk waktu dekat..

peta jalan saya untuk memasukkan .Net adalah:

1. modul untuk Godot menggunakan mekanisme hosting microsoft .Net (selesai)
2. bungkus godotClasses
   (keadaan saya saat ini: menulis generator pembungkus, yang mem-parsing kode godot c++,
   parsing selesai, generasi sedang berlangsung)
3. keluarkan proyek dari status prototipe (selesaikan tepinya, ujilah ...)
4. tulis mekanisme hosting Mono, untuk menghilangkan ikatan windows
5. entah bagaimana aktifkan Visual Studio untuk men-debug mono, untuk menyingkirkan xamarin/monodev (seperti unity vs-plugin )
6. bersenang-senanglah ratusan pengembang godot .net baru :)

beberapa pertanyaan:

1. saya ingin tahu apakah saya dapat menggunakan kembali mekanisme pengikatan yang digunakan untuk gdscript. tetapi saya tidak punya waktu untuk mengevaluasi semuanya, apakah ada pelajaran yang bagus atau petunjuk level tinggi di luar sana untuk saya?

2.
saat ini saya membuat pembungkus yang membungkus semua metode godot menjadi fungsi sehingga mereka dapat dipanggil melalui batas dll dan batas c++/netCode dengan mudah. (mekanisme pengikatan tertulis sendiri untuk netCode)
saya tidak ingin mengubah kode godot (kecuali kode modul saya) agar tetap kompatibel.
juga statis, nonstatis, virtual nonvirtual membuat saya menangis, itu sebabnya saya memilih cara ini.
ada solusi yang lebih baik untuk ini?

beberapa pemikiran tambahan:

Microsoft .Net vs Mono:

saya pikir tidak masalah jika Anda menggunakan mono atau msDotNet, karena dalam kebanyakan kasus kode dotNet berjalan tidak berubah pada keduanya. Satu-satunya upaya untuk mendukung keduanya adalah menulis "host" untuk masing-masing dari mereka (ini adalah bagian terkecil dari "GodotDotNet"). Saya memilih msDotNet untuk membuat prototipe.
baik, mono mendukung banyak platform hanya msDotNet windows, jadi mengapa mendukung/menggunakan msDotNet?
Jawabannya: produktivitas, debugging

msDotNet:
Terutama ketika menulis/membuat prototipe DotNetModule saya perlu/ingin kompilasi CEPAT dan debugthrough, berarti debugger Anda harus melompat ke netCode dari c++ dan sebaliknya.
saya memilih VisualStudio, karena dapat men-debug keduanya. TAPI hanya jika Anda menggunakan msDotNet.
Melakukannya, Anda mengubah sepotong netCode, tekan run dan dalam 1 detik! dikompilasi dan dijalankan!!! termasuk kemungkinan untuk men-debug ke godot. (jika Anda tidak mengubah sesuatu di godot, maka Anda harus menunggu biasanya 30 detik hingga 1 menit ... sialan Anda lambat scon! :))

Mono:
Mono harus menjadi target akhir tidak ada diskusi tentang itu (kemerdekaan platform), tetapi:
jika seseorang menggunakan mono, Anda memiliki masalah besar ketika saya datang ke debugging: mono memiliki mekanisme debugging sendiri!
bagi saya ini adalah hit besar bagi produktivitas, karena kecuali jika Anda menulis plugin monodebug untuk visualstudio (unity melakukan ini), Anda tidak dapat men-debug netcode yang dihosting mono di visual studio dan men-debug ke kode c++ (ada solusi peretasan tapi ...).
Saya mencoba mengatur solusi berbasis Mono, tetapi saya akhirnya menggunakan keduanya secara paralel, VisualStudio (untuk c++) dan xamarin/monodev (netcode).

Kesimpulan:
status prototipe: msDotNet
lateron: mono, untuk pengguna yang tidak tertarik untuk men-debug ke godot/c++ dan independensi platform
setelah itu: buat vs-plugin untuk men-debug mono

c# vs java:
jawabannya jelas c#! java adalah untuk scritpkids! (oh apa pendapat c++ coder tentang c# devs :))
tidak, ini hanya lelucon :)
saya tidak mengerti diskusi ... ketika sistem .net diimplementasikan, Anda dapat menggunakan setiap bahasa yang mendukung dotNet termasuk kedua bahasa dan lebih banyak lagi.
ini tidak terjadi jika sistem java didukung ...

@Ziflin :
pertanyaan 1:
melakukan pencarian itu juga ... hanya monoRemotedebugger yang (bukan) solusi atm :(
rekomendasi saya adalah, seperti yang dinyatakan di atas: gunakan hosting microsoft dotNet untuk pembuatan prototipe
kemudian di beberapa titik kemudian beralih ke mono.
alternatif:
mulai xamarin dalam mode retasnya, biarkan ia mendengarkan localhost, atur breakpoints, lalu mulai proyek Anda vs. saya telah mengujinya, itu berhasil, tapi...
bagi saya itu bukan solusi! saya ingin "hit run dan debug dalam 1 detik" - mekanisme dan ini dengan 1 klik!
saya tidak punya banyak waktu di waktu luang saya, jadi produktivitas adalah target utama saya.

pertanyaan2:
belum tahu mono dengan baik, tetapi saya pikir Anda harus melakukannya di c ++, menerapkan hosting mono, mengelolanya dari "luar" di c ++.

@CharlesWoodhill resmi C#-bindings sudah WIP dan dapat dilihat di sini https://github.com/neikeq/GodotSharp/

keren tnx, maka saya tahu bagaimana saya menghabiskan beberapa hari libur saya berikutnya;)

Hai, saya baru saja menemukan godotSharp tetapi ini jatuh.

ini dijatuhkan.

Versi resmi yang saya dengar di IRC adalah seperti:

@neikeq tidak suka mendorong kode yang belum selesai, jadi dia bekerja di cabang lokalnya

Nah itu bagus untuk diketahui, saya akan melakukan modul saya sendiri tetapi saya rasa mungkin juga untuk Godot 2.2 atau 3.0

Tidak akan ada rilis 2.2, pengembang Godot memindahkan semua fitur 2.2 ke 3.0.

Ini pertama kalinya saya berkomentar. Saya datang dari Unity dan pindah ke GDscript adalah mimpi. Saya mempelajari bahasa itu dalam waktu kurang dari sehari. Saya suka seberapa baik bahasa diimplementasikan ke dalam mesin dan produktivitas saya meningkat pesat.

Perhatian utama saya adalah bahwa dengan menambahkan dukungan C#, GDscript akan tertinggal atau melihat lebih sedikit pengembangan setelah membanjirnya pengembang Unity. C# adalah bahasa yang bagus tetapi bukan favorit pribadi saya

Saya juga prihatin melihat Godot mencoba menjadi lebih seperti mesin lain daripada berdiri sendiri. Unity adalah kisah sukses yang luar biasa tetapi bukan mesin terbaik yang pernah saya gunakan. Ini kembung dan buggy. Setelah itu menghapus seluruh proyek saya tanpa konfirmasi. Berurusan dengan bug dan hal-hal yang tidak berfungsi sebagaimana mestinya adalah perjuangan yang terus-menerus. Saya tidak dapat menghitung berapa kali saya harus benar-benar membangun kembali adegan yang sedang saya kerjakan karena semuanya tidak berjalan dengan benar. Saya pernah menyalin dan menempelkan semua konten dari adegan kereta lama ke adegan baru agar tiba-tiba berfungsi meskipun kedua adegan itu identik. Saya kehilangan minggu berburu bug fisika yang secara ajaib akan muncul dan menghilang secara ajaib.

Saya sangat suka Godot itu ramping dan mudah dimengerti. Bekerja dengan Godot seperti menggunakan alat musik yang disetel dengan baik. Setelah hampir satu tahun bekerja di dalamnya, saya baru tahu bagaimana melakukan apa pun yang perlu saya lakukan, bahkan jika saya belum pernah melakukannya sebelumnya. Saya hanya berharap masuknya pengguna Unity tidak akan mengarahkan arah mesin lebih ke Unity. Jika saya ingin Unity maka saya akan menggunakan Unity.

@zaywolfe Kekhawatiran Anda telah diungkapkan beberapa kali oleh pengguna lain. Anda tidak perlu khawatir. GDScript akan terus menjadi bahasa utama di Godot.

Saya tidak suka GDScript . Saya mengerti itu dimodelkan setelah Python, tetapi saya merasa sangat lemah. C++ atau Java termasuk (di luar kotak) akan menjadi ide bagus menurut saya. Saya pribadi merasa jijik menggunakan GDScript dalam pengembangan, sampai mempertanyakan apakah akan meninggalkan Godot dan kembali lagi ketika bahasa baru (atau alternatif) telah diterapkan. Maaf, tetapi jika Anda menginginkan fakta nyata dari seorang programmer, Anda mendapatkannya.

Juga, saya ingin menyebutkan bahwa kadang-kadang saya bahkan menggunakan Godot untuk beberapa pembuatan prototipe perangkat lunak sederhana. Dengan demikian, bahasa pemrograman yang terintegrasi secara mendalam mungkin akan membuka pintu untuk pengembangan perangkat lunak di dalam mesin. Itu benar-benar akan menjadi pembunuh Unity. (Jika, tentu saja, Java atau C++ dipilih)

Terima kasih pengembang setia atas kerja keras Anda, saya menantikan Anda semua, dan saya menantikan rilis terbaru di masa mendatang!

@VenHayz Saya tidak tahu apakah Anda membaca dokumentasi Godot, tetapi Anda sudah dapat menulis game Anda di C++, sejak Godot versi pertama - http://docs.godotengine.org/en/stable/reference/custom_modules_in_c++.html

bagaimana dengan menggunakan microsoft .net core? itu lintas platform dan fokus pada kinerja, serta juga open source dan dikembangkan secara aktif

Halo hanya seorang pria acak yang lewat

Saya ingin memberi tahu Anda bahwa saya tidak menggunakan Godot karena saya tidak suka bahasa skrip yang Anda gunakan

Jika Anda menambahkan Java atau C#, maka saya akan menginstal dan menggunakan godot tepat setelah pengumuman Anda :)

@RUSshy selamat tinggal kalau begitu, ini adalah kerugian Anda, godot luar biasa, GDScript hebat, jika Anda seorang programmer sejati, itu akan membawa Anda secara harfiah dua jam untuk mengetahui lebih dari cukup untuk memulai proyek apa pun. Pemrogram sejati harus menguasai banyak bahasa, Anda dapat tetap menggunakan Java/C# Anda dan menjadi orang "acak" yang lewat sebagai penghobi selamanya. Saya tidak bermaksud kasar, hanya menyatakan fakta. Jika Anda tidak menyukai sesuatu tentang mesin ini, maka berkontribusilah dengan beberapa kode, ini gratis tidak seperti kebanyakan mesin lainnya.

Dewa Pemasaran menyukai C#. :tertawa:

@RebelliousX Memilih Java atau C# berarti Anda akan memiliki BANYAK perpustakaan untuk digunakan

Membatasi diri Anda pada bahasa skrip buatan sendiri tidak berguna, pengetahuan baru Anda tidak akan berlaku di tempat lain, dan Anda tidak akan dapat menemukan banyak perpustakaan, atau tidak akan dapat menggunakan kembali pengetahuan Anda atau sumber belajar yang ada

Pilihan itu gila saat ini jangan berpikiran tertutup

@RUSshy Apakah Anda bercanda? Saya (dan beberapa lainnya) menulis secara harfiah halaman penjelasan tentang manfaat GDscript atas C# dan Anda pikir Anda bisa menyelesaikan diskusi dengan satu paragraf pendek tanpa membaca apa pun yang dikatakan sebelumnya?

"Jangan berpikiran sempit" - ide bagus, bagaimana kalau Anda mulai dengan berpikiran terbuka tentang GDscript?
"pengetahuan baru Anda tidak akan berlaku di tempat lain" - itu salah. Anda tidak akan dapat mengimbangi kurangnya pengetahuan dengan menyalin-menempelkan kode yang tidak Anda pahami.
"Anda tidak akan dapat menemukan banyak perpustakaan" - pelajari perbedaan antara bahasa skrip dan bahasa backend. Atau - ide gila - baca apa yang saya tulis tentangnya.

Serius, keberanian beberapa orang ...

Telah dikatakan beberapa kali di berbagai tempat bahwa modul integrasi C# sedang dikerjakan. Ini berjalan secepat jumlah waktu yang dimiliki orang untuk melakukannya. Satu-satunya cara untuk membuatnya lebih cepat adalah dengan berkontribusi pada integrasi itu :)

@Warlaan tentang poin kedua: jika Anda menulis banyak kode dalam C# sebelumnya, Anda tidak dapat menggunakannya kembali kecuali Anda mem-port semuanya. Anda juga tidak perlu memahami kode sebuah library untuk dapat menggunakannya. Intinya adalah, jika Anda memerlukan sesuatu yang ada di C# sebelumnya (satu file atau satu set pustaka, berpotensi sumber tertutup), Anda perlu mem-port semuanya, menyematkan runtime C# atau menemukan implementasi C. Itu bukan tidak mungkin, tapi memakan waktu.
Itu tidak berarti Godot tidak dapat menggunakan banyak lib yang ada... C/C++ juga memiliki banyak lib.

Ini berisiko menjadi perang api.
Lognya sangat panjang sehingga orang akan mengulangi pertanyaan atau topik yang sama alih-alih membacanya.
Tidak banyak hal teknis yang tersisa untuk didiskusikan juga.

Masa depan Godot dalam hal scripting sudah cukup jelas:

• GDScript akan tetap sebagai bahasa utama dan ada rencana atau ide untuk mengoptimalkannya (tetapi ini bukan tempat yang tepat untuk membahasnya).
• Dari 3.0, C# akan didukung sebagai alternatif skrip. Kami akan menyediakan binari terpisah untuk menghindari pemaksaan ukuran ekstra yang disebabkan oleh runtime mono pada orang yang tidak akan menggunakannya.
• DLScript juga sedang bekerja. Ini akan memungkinkan orang untuk menggunakan perpustakaan bersama untuk skrip. Pustaka ini dapat ditulis dalam bahasa apa pun yang mendukung tautan c dan pustaka bersama (mengharapkan bahasa seperti Rust dan D). Belum jelas apakah itu akan siap untuk 3.0 (kecuali saya sudah ketinggalan zaman).
• Jangan lupa akan ada Visual Scripting di 3.0 juga!

Jika seseorang berencana untuk menyumbangkan sesuatu yang lain, ini juga bukan tempat yang tepat untuk mendiskusikannya.

Saya pikir masalah ini dapat dan harus ditutup.

Sepakat.

Bisakah tolong berikan tautan ke kode sumber integrasi C#?

https://github.com/neikeq/GodotSharp

Seberapa fungsional Integrasi GodotSharp? Apakah siap digunakan untuk pengujian?
Bisakah digunakan dengan build sumber dari godot master?

@nictayr Saat ini tidak dibangun dengan master. Jika Anda ingin mengujinya, Anda perlu menggunakan 2.2-legacy. Ini bekerja dengan versi itu dengan sangat baik

Saya sedang mempersiapkannya untuk alpha 3.0 pada bulan April.

Ide acak, tetapi setelah berpikir mendalam tentang C++ dengan Godot, saya memikirkan sesuatu yang mungkin lebih baik. bahasa D. Itu termasuk dalam kuota bahasa "tingkat rendah", dengan antarmuka ke C dan (beberapa) dukungan C++. Ini memiliki kelas, dan sangat modern. Meskipun kedengarannya menakutkan, ini sangat mirip dengan GDScript , dan saya dapat melihatnya digunakan untuk menjalankan proyek yang sangat besar. Cukup kuat untuk bersaing dengan C dan C++ (gcc/g++) dengan kompiler bernama GDC. (DMC juga dapat digunakan untuk mengkompilasi, tetapi GDC mengkompilasi langsung ke gcc) lihat lebih lanjut tentang GDC di sini

Bagaimanapun, hanya saran singkat atau mungkin untuk ide.

@VenHayz Saya sedang mengerjakan modul yang memungkinkan penggunaan pustaka bersama untuk skrip. Saya sudah berusaha untuk membuat C++ lebih mudah digunakan dengannya. Anda dapat menggunakan D untuk membuat pustaka tersebut juga. Jika Anda tertarik untuk membuat ikatan D, hubungi saya di IRC atau Discord.

@karroffel itu sangat keren. Saya tidak punya pengalaman dengan menulis perpustakaan dan API (referensi penyebutan Anda tentang "binding") meskipun, saya mungkin bisa menelitinya selama sehari dan melakukannya; Saya bangga belajar cepat. Saya ingin menghubungi Anda di Discord, jika Anda tidak keberatan? Perselisihan saya: _hasCat#3941

@VenHayz Saya tidak dapat menambahkan Anda, Anda tidak mengizinkan orang lain untuk menambahkan Anda. Karroffel#8409 atau bergabung dengan server Godot

@neikeq Apakah repo GodotSharp Anda adalah basis kode yang digunakan untuk dukungan C# di Godot 3.0? Hanya bertanya karena saya mencoba mendapatkan gambaran kasar tentang fitur apa yang akan tersedia dan akan melihat-lihat basis kode itu jika demikian. Terima kasih!

saya melihat godotsharp, sudah ketinggalan zaman? fitur baru ? atau sudah siap pakai di develop build?

bagaimana saya bisa mengkompilasi godosarp dari soruce untuk saya?

@nictayr Anda harus menggunakan cabang 2.2-legacy sebagai build build.

Saya pikir saya cukup membaca untuk mencari tahu apakah orang lain menyebutkan ini.

Saya pribadi hanya tidak ingin belajar bahasa lain yang tidak bisa saya gunakan di tempat lain. Saya tidak berencana melakukan banyak pemrograman 3D, hanya beberapa hal di sana-sini.

Ya, ada banyak kontra-argumen menentang ini tapi ... ini adalah proyek open-source. Tidak perlu membenci seseorang yang menyumbangkan bahasa pemrograman baru.

Bayangkan membawa bir ke pesta anak-anak. Apakah Anda akan mengatakan bahwa "tidak perlu membenci seseorang yang menyumbangkan minuman baru"? Ada kemungkinan besar bahwa menambahkan C# akan membahayakan pengembangan GDscript. Saya tahu bahwa setiap orang bertekad untuk menjaga GDscript sebagai bahasa utama untuk Godot, tetapi masih mengganggu saya ketika telah dijelaskan beberapa kali mengapa menambahkan fitur baru memiliki kelemahan dan orang-orang masih bertanya "apa salahnya?".

Juga meminta C# alih-alih GDscript karena "Anda tidak ingin belajar" adalah argumen yang sangat bodoh. Dari semua bahasa yang saya tahu dalam pengembangan game, GDscript memiliki fitur paling sedikit dan C# sejauh ini paling banyak. Jika Anda tidak ingin belajar, Anda harus berterima kasih atas GDscript.

Saya sebenarnya tidak ingin memanaskan diskusi ini berulang-ulang, jadi silahkan jika ada yang mau berkomentar di thread ini, HARAP BACA DARI ATAS.

Juga meminta C# alih-alih GDscript karena "Anda tidak ingin belajar" adalah argumen yang sangat bodoh.

Saya tidak keberatan belajar C# karena saya mungkin bisa menggunakannya di tempat lain.

Kunci saja utasnya, itu menjadi jahat.

Memang benar bahwa utas ini telah memenuhi tujuannya, mari kita kunci.