Godot: Skrip visual gaya Lembar Acara

Tidak bisakah banyak dari ini dikurangi dengan memberdayakan Visual Scripting saat ini dengan fungsi yang lebih banyak dan lebih baik?

Banyak contoh sepele dalam cetak biru UE4. "Saat menekan tombol W, gerakkan aktor ini ke depan".
Anda dapat membangun sebagian besar dari ini dengan cara yang sangat mirip dalam cetak biru dan bahkan perbedaan visual (yang akan menjadi satu-satunya) akan minimal.

Kita harus fokus membuat Skrip Visual yang kita miliki dapat digunakan dan bekerja dengan cara yang intuitif dan lancar, IMO. Seperti apa adanya, Visual Script yang sudah kita miliki terasa sedikit terlupakan dan sepertinya tidak mendapatkan banyak cinta. Bagaimana memiliki dua sistem Visual Scripting memperbaiki situasi ini sama sekali?

Ide bagus untuk sebuah plugin. Tetapi secara resmi mempertahankan dua sistem skrip visual akan menyusahkan, dan untuk sedikit keuntungan.

@mhilbrunner sayangnya tidak, Cetak Biru adalah pendekatan yang sama sekali berbeda untuk skrip visual. Bagi Anda itu sepele, tetapi saya berani Anda mengatakannya di forum clickteam atau di forum konstruk. Orang-orang itu terjebak dengan mesin yang mereka gunakan karena betapa mereka menyukai pendekatan ini dan percayalah - banyak dari mereka telah mencoba cetak biru di Unity , unreal dan mesin lainnya - termasuk godot. Mereka masih terjebak dengan fusi konstruk2 atau clickteam karena mereka lebih memilih lembar acara daripada Cetak Biru. Mereka masih meminta pendekatan event sheet di forum unity.
Skrip visual Godot disebutkan di forum mereka dan pengguna di sana masih lebih suka lembar acara. Saya pribadi beralih ke gdscript dan lebih suka menggunakan gdscript daripada cetak biru - karena gdscript lebih dekat dalam keuntungannya dengan lembar acara daripada cetak biru.

Ini seperti memberi tahu seseorang yang suka pisang untuk makan tomat - ini masalah selera :)

@groud Saya memikirkan hal yang sama untuk sementara waktu, tetapi saya bahkan tidak yakin harus mulai dari mana - dan bahkan sebagai plugin- seseorang harus memelihara plugin.

@reduz tampaknya merasa lebih hangat terhadap gagasan di facebook, tetapi saya mengerti bahwa dia memiliki banyak hal yang lebih penting

Bagaimanapun, saya memposting ini di sini untuk dokumentasi - untuk menguraikan sistem lembar acara - apa yang dilakukannya dan bagaimana perbedaannya dari cetak biru. Jika ada orang lain yang tertarik untuk menerapkannya di godot atau sebagai addon, beri tahu kami. Saya pasti akan menyingsingkan lengan baju saya dan membantu, menyebarkan berita dan mendapatkan umpan balik dari pengguna clickteam/construct.

Sejauh ini saya bahkan tidak tahu bagaimana mengimplementasikan antarmuka dengan kelas GUI godot dengan benar. Anda harus dapat menyeret blok logika di antara sel-sel dari kolom yang sama. Salin/tempel blok/baris juga - baris bersarang dan
hal unik lainnya. Saya tidak berpikir itu tugas kecil

@blurymind Ya, dan terima kasih pasti telah menunjukkan ini dan meluangkan waktu untuk penulisan terperinci. Masih berpikir ini mungkin akan lebih baik sebagai plugin.

devs: Apa cara terbaik untuk menambahkan ini dengan kompleksitas minimal? Mungkin saya akan mencari waktu untuk melihat cara kerja skrip visual saat ini. Bertanya-tanya apakah mungkin sebagian besar hanya mengganti Visual Scripting UI atau menghasilkan GDScript atau cara lain untuk melakukan ini secara dinamis.

Belum melihat semua ini, jadi petunjuk diterima. :) Tidak ada petunjuk nihil, tolong!

@mhilbrunner kita mungkin dapat membuka masalah lain di pelacak dengan daftar hal-hal yang dibutuhkan sistem cetak biru di godot agar lebih intuitif. Tolong tautkan jika Anda membuatnya

Posting saya di sini adalah proposal untuk pendekatan alternatif, bukan untuk perubahan yang saat ini diterapkan. Lembaran acara terlalu berbeda

Saya percaya lembar acara seperti itu dapat diimplementasikan melalui Nativescript, tetapi saya tidak melihat alasan mengapa itu harus bergantung pada basis kode yang sama dengan visualscripting.

@groud itu sebenarnya poin yang bagus. Berapa banyak basis kode visualscripting saat ini yang dapat digunakan kembali? Seberapa spesifik untuk antarmuka nodegraph?

@blurymind Ya mengerti, mengerjakan daftar seperti itu untuk VS dan akan melakukannya, tetapi akan memakan waktu.

Perlu menyelidiki NativeScript :)

Kami sekarang memiliki banyak pilihan untuk bahasa skrip (C++, C#, bahkan python). Mengapa tidak juga memiliki lebih dari satu pilihan untuk skrip visual :)

Saya kira ini juga bisa bergantung pada seberapa fleksibel api godot untuk membangun antarmuka skrip visual.
Haruskah basis kode visualscripting digunakan kembali - atau haruskah yang sepenuhnya alternatif ditulis dengan Nativescript (c++)?
Bisakah ini diimplementasikan sebagai addon gdscript?

Mengapa tidak juga memiliki lebih dari satu pilihan untuk skrip visual :)

Karena kami sudah mendukung terlalu banyak bahasa sebagai bawaan. Sebagian besar kasus penggunaan sudah tercakup, jadi tidak ada banyak alasan untuk menambahkan bahasa baru untuk dipertahankan. Kami memiliki bahasa untuk pemrograman dasar (GDscript), dua untuk pertunjukan (C# dan C/C++) dan satu untuk seniman/perancang game (skrip visual). Tidak ada alasan untuk menambahkan bahasa lain sebagai built-in hanya karena beberapa orang tidak dapat menangani belajar bahasa baru.

Sejujurnya, saya benar-benar tidak berpikir ini harus ditambahkan ke inti. Akan lebih baik ditambahkan melalui plugin seperti pengikatan bahasa lainnya. Kami sudah memiliki cukup pekerjaan untuk mempertahankan bahasa saat ini.

Dan tidak, saya tidak berpikir kita dapat menggunakan kembali kode visualscripting.

@groud Itu poin yang bagus, tetapi pertimbangkan rasio programmer dengan artis di gamedev. Beberapa game retro 2d terbaik dan terindah telah dibuat dengan fusion 2 oleh seniman yang ingin membuat game dengan cara intuitif yang sesuai dengan cara berpikir mereka. Berikut adalah showreel game buatan Fusion yang agak ketinggalan jaman:
https://www.youtube.com/watch?v=3Zq1yo0lxOU

Mereka memiliki banyak proyek dan game kickstarter yang sukses di steam - game di banyak platform. Orang suka menggunakan pendekatan ini dalam pemrograman visual - bahkan tim profesional. Saya tidak akan mempresentasikannya di sini jika saya tidak melihat potensi untuk memperluas basis pengguna

Yah mungkin, tapi berapa banyak dari mereka yang bisa memahami Lembar Acara tetapi tidak VisualScripting? Anda mengatakan bahwa "orang-orang itu terjebak dengan mesin yang mereka gunakan karena mereka sangat menyukai pendekatan ini dan percayalah - banyak dari mereka telah mencoba cetak biru di Unity , unreal dan mesin lainnya- termasuk godot", tetapi Anda sebenarnya yang pertama menanyakan itu.

Jika ini adalah permintaan yang populer, ya kita bisa menambahkannya ke inti. Tapi sampai sekarang tidak.

Bagi saya, kami sudah membahas semua kasus penggunaan. Setidaknya untuk mesin game yang canggih dan profesional. Dan karena kami tidak menargetkan anak-anak atau penggemar tetapi perusahaan, tidak ada gunanya menghabiskan waktu untuk itu. Fusion 2, Membangun atau bahkan RPGMaker fokus pada audiens lain, bahkan jika permainan indah telah dibuat dengan mereka hanya sebagian kecil dari mereka adalah proyek profesional.

@groud statistik ini sulit didapat. Berapa banyak yang menggunakan skrip visual saat ini?

Saya juga menjelaskan mengapa pendekatan lembar acara memiliki keunggulan dibandingkan cetak biru - seperti lebih sedikit klik untuk membuat semuanya berfungsi, presentasi yang lebih jelas, dan transisi pembelajaran yang lebih baik ke gdscript.

Mesin pembuat rpg benar-benar editor level jika Anda bertanya kepada saya. Itu tidak memiliki tingkat fleksibilitas yang sama seperti Fusion dan konstruksi2

Lebih mudah menjelaskan kepada seseorang cara kerja lembar acara, daripada menjelaskan contoh yang sama dalam cetak biru - mereka harus belajar lebih sedikit konsep - tidak perlu diajari jenis koneksi antara node, jenis input dan output - cara mengatur aliran.
Sebaliknya peristiwa mengalir dari atas ke bawah, kiri adalah kondisi dan kanan adalah tindakan. Anda harus menghubungkan apa-apa.

Melakukan hal ini

terlihat sesulit ini untuk dipahami?

Tentu, godot akan menggunakan lebih banyak blok acara untuk dicapai, tetapi itu masih akan lebih jelas daripada grafik simpul.
Bahkan gdscript terlihat lebih jelas bagi saya dari itu. Sistem skrip visual kami saat ini terlihat rumit pada pandangan pertama

Saya berbicara sebagai seseorang yang telah menggunakan kedua sistem dan sekarang membandingkannya - keduanya sama kuatnya, yang satu jelas lebih mudah dipelajari dan dipelajari
Silahkan dicoba. Anda dapat mencoba construct3 di browser web Anda secara gratis di sini:
https://www.scirra.com/
Jika Anda memiliki putra atau adik, minta mereka untuk mencobanya, lalu coba godot - lihat apa yang dapat mereka lakukan dan berapa lama mereka melakukannya tanpa diberi instruksi - ada pasar potensial bagi lebih banyak sekolah untuk mengadopsi godot di sini - membuat skrip visual lebih baik untuk mempelajari konsep pemrograman dan kami akan mendapatkan demografi yang lebih muda menggunakan mesin

Berapa banyak yang menggunakan skrip visual saat ini?

Saya tidak tahu, tapi saya percaya tidak banyak untuk saat ini. Kebanyakan orang tampaknya menggunakan GDScript untuk saat ini, karena saya tidak melihat banyak pertanyaan/konten tentang VisualScripting di Facebook atau Youtube. Menambahkan Lembar Acara sebelum memastikan bahwa VisualScripting tidak menjawab semua kasus penggunaan akan menjadi taruhan yang berani. Mari kita lihat untuk saat ini apakah VisualScripting sudah cukup, dan jika orang-orang secara besar-besaran meminta sistem lain, kami mungkin menambahkannya nanti.

@groud akan sangat bagus jika kita dapat menguji skrip visual godot di lingkungan sekolah - dengan anak-anak mempelajari konsep pengkodean dasar.
Salah satu nilai jual terbesar construct2 adalah mengajari anak-anak coding dan mereka telah menjual lisensi pendidikan khusus selama bertahun-tahun.

Argumen saya adalah bahwa skrip visual di godot saat ini tidak terlalu mengundang untuk non-coder dan tidak benar-benar membantu orang belajar cara membuat kode - karena pendekatannya murni state machine centric dan konsep pemrograman dasar menjadi lebih rumit dengan nodegraph tambahan aturan sentris di atas.

Pemrogram berpengalaman benar-benar bukan audiens terbaik untuk menjual ini - karena mereka akan melihat lembar acara sebagai penyederhanaan dari apa yang sudah kita miliki - gdscript dan akan melihat cetak biru sebagai alat baru yang dapat digunakan sebagai mesin negara oleh desainer.

Saya ingin mencoba menulis addon lembar acara dasar di gdscript, saya benar-benar tidak cukup berpengalaman untuk membuat addon skrip asli. Jika itu mungkin dan Anda memiliki beberapa petunjuk untuk memulai - saya akan senang mendengarnya
Mungkin jika ada minat yang cukup, seseorang mungkin membuatnya dalam skrip asli

karena pendekatannya murni state machine centric

Apa ? Saya tidak tahu mengapa Anda akan berpikir seperti itu. VisualScripting tidak ada hubungannya dengan mesin negara.

Mana yang lebih sederhana untuk digunakan saat ini - Cetak Biru atau Gdscript? Apa tujuan dari skrip visual dan siapa pengguna targetnya

VisualScripting harus lebih sederhana daripada GDscript untuk artis/pengembang game. Saya harus mengakui itu tidak benar-benar untuk saat ini, mungkin sekelompok node mungkin disederhanakan/dibuat lebih menarik. Tapi sejujurnya, Anda salah berpikir bahwa Lembar Acara lebih mudah dipahami daripada VisualScript, bagi saya tidak.

Satu-satunya hal yang benar-benar membuat perbedaan dalam contoh yang Anda tampilkan adalah teks dan ikon yang membuat segalanya lebih mudah dipahami. Teks dan ikonlah yang membuat segalanya lebih eksplisit dan lugas, bukan organisasi vertikal. VisualScripting akan dapat dimengerti jika kami menambahkan ikon seperti itu, jika kami membuat GUI yang lebih baik untuk sebagian besar tindakan umum, dan mengelompokkan fungsi ke dalam kategori yang sesuai.

@groud juga urutan eksekusi dan jenis koneksi. Ada lebih banyak konsep yang harus diperhatikan dalam nodegraph daripada lembar acara. Bahkan jika Anda menambahkan ikon ke node, Anda masih harus menjelaskan bahwa urutan acara ditentukan oleh garis putih, juga apa arti warna lainnya. Anda masih berakhir dengan grafik spageti yang lebih sulit dibaca - mata Anda harus menjelajah ke mana-mana untuk mencari tahu apa yang terjadi di grafik orang lain

Anda bukan audiens target yang tepat - Anda adalah programmer c++ berpengalaman. Silakan uji ini dengan orang-orang yang bukan programmer dan Anda akan mulai melihat apa yang saya maksud.

Ayo itu tidak terlalu sulit untuk dipahami, sekali lagi kami tidak menargetkan anak-anak.
Dan mengenai organisasi kode, masalahnya sama untuk lembar acara. Jika Anda tidak repot-repot mengelompokkan node dan mengatur kode Anda, Anda akan berakhir dengan kode yang tidak dapat dibaca, apakah itu karena lembar kejadian yang panjang atau grafik node yang besar.

@groud bisakah kita mengelompokkan node visualscript seperti di blender? Saya tidak ingat melihat itu. Mungkin @mhilbrunner harus menambahkannya ke daftarnya
https://github.com/godotengine/godot/issues/12418
Poin penting lainnya adalah kemampuan untuk membuat blok logika tindakan/kondisi tingkat tinggi yang dapat digunakan kembali melalui gdscript akan sangat bermanfaat untuk sistem lembar peristiwa atau sistem cetak biru. Sistem cetak biru sudah memilikinya - tetapi saya tidak melihat ada plugin yang dibuat untuk itu..

Sekali lagi - construct2 jauh di depan kita. Komunitas mereka telah membuat banyak banyak plugin yang mudah dipasang yang menambahkan kondisi dan tindakan khusus - dan api mereka untuk mendaftarkan tindakan dan kondisinya sangat sederhana
https://www.scirra.com/forum/completed-addons_f153
https://www.scirra.com/manual/19/actions-conditions-and-expressions

Sangat sesuai dengan blurymind
Bagi saya, jauh lebih mudah untuk memahami sistem peristiwa Membangun dan Penggabungan, yang juga menawarkan lebih cepat untuk mengembangkan game apa pun daripada sistem yang penuh garis.

lol bagaimana ini lebih mudah dibaca daripada gdscript

@groud bisakah kita mengelompokkan node visualscript seperti di blender? Saya tidak ingat melihat itu

Saya tidak tahu. Tapi jika tidak diterapkan, saya pikir itu harus.

lol bagaimana ini lebih mudah dibaca daripada gdscript

Ini bukan poinnya di sini.

@groud ya itu. mengapa pengembang game ingin menggunakan lembar acara ketika jauh lebih tidak teratur/membingungkan untuk dibaca daripada kode gdscript sederhana? itulah inti dari saran fitur ini bukan

@groud ya itu. mengapa pengembang game ingin menggunakan lembar acara ketika itu jauh lebih tidak teratur daripada kode gdscript sederhana?

Tidak, VisualScripting (atau Lembar Acara) dan GDscript tidak menargetkan orang yang sama. VisualScripting (atau lembar acara) adalah untuk seniman atau desainer game/level sementara gdscript membutuhkan pengalaman pemrograman.

Membandingkan Lembar Acara dan GDscript tidak masuk akal.

Membandingkan Lembar Acara dan GDscript tidak masuk akal.

Nah, di situlah kita berbeda :P karena saya pikir itu lebih masuk akal untuk membandingkan mereka. terutama karena gdscript melakukan semua yang mereka lakukan, pada tingkat yang jauh lebih sederhana.

juga, saya tidak setuju tentang "membutuhkan pengalaman pemrograman". jika seorang desainer level membuat blok tindakan _dalam lembar acara atau skrip visual_, mereka _sudah memiliki blok pembangun dasar_ untuk menggunakan gdscript.

dengan mengatakan: gdscript yang dikompilasi JIT ada di peta jalan, dan akan jauh lebih bermanfaat daripada lembar acara atau penambahan skrip visual (karena sebagian besar pengembang godot sudah bisa mendapat manfaat besar darinya). dan kasus penggunaan potensial VS/Lembar Acara saat ini cukup rendah. jadi semua yang saya minta harap berhati-hati tentang lead dev time, karena posting terbaru Anda telah disinggung

@girng pada titik apa Anda memutuskan bahwa saya mencoba mencuri prioritas fitur penting lainnya di peta jalan? Posting ini mengeksplorasi manfaat skrip visual melalui metode alternatif yang kami miliki saat ini.
Itu bahkan tidak ada di peta jalan, namun Anda melompat ke sana seolah-olah ada di sini untuk makan sarapan Anda. :P
Menjelajahi sebuah ide tidak sama dengan menuntut waktu.

Anda jelas tidak pernah menyentuh construct atau clickteam fusion , jika Anda ingin berdiskusi tentangnya - setidaknya gunakan lembar acara untuk sementara - buat platformer dengannya.
Saya menautkan ke demo online construct3, yang tidak mengharuskan Anda untuk mendaftarkan akun atau masuk.
https://www.scirra.com/
itu benar-benar tiga klik saja

Coba lembar acara, buat sesuatu dengannya. Kemudian gunakan cetak biru skrip visual yang dimiliki godot

Gdscript sederhana- ya saya setuju dan menyukainya juga. Gdscript yang dikompilasi jit akan luar biasa! Setuju itu lebih penting juga.
Tapi diskusi ini sama sekali bukan tentang hal-hal itu

Nah, di situlah kita berbeda :P karena saya pikir itu lebih masuk akal untuk membandingkan mereka. terutama karena gdscript melakukan semua yang mereka lakukan, pada tingkat yang jauh lebih sederhana.

Apa yang tidak Anda pahami adalah bahwa bagi banyak orang ada penghalang pikiran antara pengkodean dan bukan pengkodean. Saya harus mengakui bahwa VS agak sulit untuk masuk untuk saat ini, tetapi di masa depan itu harus lebih mudah daripada GDScript karena banyak materi pembelajaran mungkin telah dibuat dan beberapa perbaikan VS harus dilakukan.

juga, saya tidak setuju tentang "membutuhkan pengalaman pemrograman". jika seorang desainer level sedang membuat blok tindakan dalam lembar acara atau skrip visual, mereka sudah memiliki blok pembangun dasar untuk menggunakan gdscript.

Ya, saya juga cukup setuju sebagai seorang programmer, tapi ini bukan yang ditunjukkan oleh pengalaman.
Unreal adalah contoh sempurna: banyak orang menggunakan cetak biru dengan Unreal, terutama di bidang profesional, karena mereka mengizinkan non-programmer menulis kode dengan cara yang lebih ramah. Meskipun tidak jauh berbeda dari kode sebenarnya (menurut saya), itu membuat perbedaan dalam pikiran orang. Jika profesional menggunakannya, itu berarti itu adalah kebutuhan nyata, bukan gadget yang harus kita jatuhkan karena kita menganggapnya sama. Itu sebabnya tidak masuk akal untuk membandingkannya, keduanya harus tersedia dan berfungsi dengan benar.

Bagaimanapun, saya akan menghentikan diskusi ini di sini. Bikeshedding tentang VS atau tidak VS telah ditangani.

@blurymind saya mengagumi energi Anda dan Anda membuat poin bagus. Saya sudah mencoba lembar acara dalam konstruksi sebelumnya dan awalnya keren, tetapi semakin maju permainan saya, saya langsung ingin kembali ke kode. jadi ya, saya sudah mencobanya di masa lalu.

@groud membuat argumen yang bagus tentang mereka, karena Marvel Heroes adalah AAA aRPG dan mereka menggunakan cetak biru w/ Unreal .

saya tidak setuju mereka memiliki kasus penggunaannya, saya hanya berpikir itu akan sulit untuk dibenarkan, berdasarkan kriteria berikut:

• tenaga pengembang terbatas
• jumlah masalah saat ini sudah
• disorganisasi / sulit dibaca (lihat di sini )
• saya merasa sebagian besar pengembang godot lebih suka menggunakan gdscript
• gdscript sudah sangat baik dengan godot
• jika ditambahkan ke inti , masalah baru dapat muncul di sekitar lembar acara, yang dapat menghilangkan masalah gdscript
• tidak adil untuk 90% pengembang godot saat ini yang sudah menggunakan gdscript (jika waktu dev dapat digunakan untuk gdscript yang dikompilasi jit, yang memenuhi kasus penggunaan aktif)

sebagai plugin saya dapat sepenuhnya mendukung, tetapi hati saya mengatakan itu mungkin bukan ide yang baik jika itu didukung secara resmi

@girng terima kasih. Sekali lagi - ini bukan permintaan untuk mengganti gdscript atau skrip visual.
Ini lebih merupakan pengamatan pada skrip visual secara umum dan bagaimana skrip visual godot saat ini benar-benar tidak ramah pengguna untuk non-coders.

Gdscript dapat menyatu dengan indah dengan sistem skrip visual apa pun - lembar acara atau cetak biru.
Seperti disebutkan dalam posting pertama saya - pendekatan lembar acara juga menggunakan ekspresi - yang gdscript sudah dapat digunakan. Blok logika tingkat yang lebih tinggi dapat dibuat melalui gdscript dan sistem plugin godot juga- ini terkait dengan indah dengan sistem skrip visual.

Faktanya, sistem lembar peristiwa bisa lebih baik digabungkan dengan gdscript daripada sistem cetak biru saat ini - di mana ekspresi dilakukan dengan satu miliar grafik simpul daripada input bidang teks sederhana. Jika Anda ingin lakukan 1+1- gunakan node.js. Jika Anda ingin menangani variabel sederhana dalam ekspresi- gunakan node lain. Anda berakhir dengan kekacauan spageti dari satu miliar simpul dasar untuk ekspresi sederhana yang dapat dengan mudah dan lebih jelas ditulis dalam bidang teks kecil dengan lebih sedikit usaha dan verbositas.

Skrip visual saat ini yang kami miliki membutuhkan terlalu banyak klik, simpul, dan verbositas untuk melakukan hal-hal yang paling sederhana. Itulah alasan lain gdscript lebih lugas - sebaris kode alih-alih 10 node dan 100 koneksi.

Itu pada dasarnya adalah keuntungan lain dari sistem lembar acara - Anda bisa menulis ekspresi Anda di dalam bidang input blok kode. Baik construct2 dan fusion bahkan memiliki autocomplete dan editor ekspresi dengan akses mudah ke semua metode yang dimiliki node dengan daftar semua node yang dapat diakses sheet dalam cakupan.

Godot dapat dengan mudah menggunakan gdscript untuk ekspresi ketika melakukan hal yang sama - tetapi ekspresi tersebut diletakkan dalam struktur spreadsheet sederhana.

Bayangkan sebuah metode di godot- sebagai blok logika. Sama seperti metodenya - blok itu mengambil parameter yang sama - tetapi Anda tidak perlu menghubungkannya ke node. Anda cukup mengetikkan beberapa gdscript di bidang inputnya.
Node di godot dapat bertindak sebagai perilaku di konstruk2 dan lembar acara di godot akan jauh lebih fleksibel dan kuat daripada konstruk2. Itu tidak akan memiliki kekurangan yang dimiliki mesin mereka

Pendekatan konstruk untuk memasangkan objek mengerikan - antara lain - tetapi itu tidak ada hubungannya dengan desain lembar acara

Skrip visual saat ini yang kami miliki membutuhkan terlalu banyak klik, simpul, dan verbositas untuk melakukan hal-hal yang paling sederhana.

Itu bukan cacat bawaan dari VS, tetapi dari implementasinya yang saat ini terbatas. Ini harus diperbaiki, tidak digunakan sebagai argumen untuk menerapkan metode skrip visual lain di sebelahnya. Jika tidak, VS saat ini harus dihapus.

Juga, membahas JIT untuk GDscript adalah di luar topik. Keunggulan suatu fitur hanya dapat diukur dengan:

• kegunaannya versus fitur serupa lainnya yang mungkin berguna untuk kasus penggunaan yang sama
• kegunaannya versus kerumitannya, utang teknis tambahan, dan beban pemeliharaan untuk Godot

Jadi apakah ini harus dilakukan atau tidak tidak ada hubungannya dengan apakah kita menerapkan JIT untuk GDScript atau tidak. Jika tidak, kami harus menutup 99% dari semua permintaan fitur sampai semua bug utama diperbaiki, yaitu selamanya. Itu bahkan lebih penting daripada JIT untuk GDScript.

@mhilbrunner JIT untuk GDScript sebenarnya akan terjadi, itu sudah ada di peta jalan resmi: P. saya hanya mengatakan ini bisa mengambil waktu pengembangan dari itu. dan sulit untuk membenarkan bahwa karena 90% dari pengembang godot sudah menggunakan gdscript (dan banyak orang berpikir itu lebih baik daripada lembar acara, dan memiliki perasaan mereka sendiri). maaf jika saya tidak menyampaikan diri saya dengan benar. ya, saya tahu ini tidak menggantikannya, tetapi saya mengatakan lebih banyak tentang waktu pengembangan.

dengan itu, @blurymind saya tidak setuju dengan apa pun yang Anda katakan karena itu adalah poin yang sangat bagus. apakah memiliki lembar acara di Godot _menjadi fitur yang bagus untuk dimiliki_? tentu, tetapi apakah itu sesuatu yang akan segera terjadi dalam kenyataan? saya tidak begitu yakin. (hanya pengguna avid sejak 2014, dan ini hanya pendapat saya)

Setelah menggunakan lembar acara Action Game Maker dan Game Maker sebelumnya, saya setuju bahwa ini lebih mudah digunakan dan dipahami daripada VisualScript (Anda membaca dari atas ke bawah, tidak mengikuti baris), tidak memakan banyak ruang layar, dan dapat mengimplementasikan secara terbatas state machine dengan lebih mudah (dengan memfilter peristiwa mana yang dapat dipicu setelah peristiwa selesai).

Itu akan menjadi tambahan yang sangat bagus. Saya mungkin tidak akan menggunakannya sendiri karena GDScript sudah cukup bagi saya, tetapi saya dapat membayangkan diri saya menggunakannya dengan baik jika GDScript bukan pilihan (yang mungkin dialami oleh pemula dan non-programmer).

Yah, saya pengguna Godot selama sekitar satu tahun. Saya suka GDScript dan sintaksnya sederhana.
Tetapi saya telah menggunakan Konstruksi selama lebih dari 8 tahun dan saya dapat mengatakan bahwa saya tidak pernah melihat Skrip Visual yang lebih mudah daripada Lembar Acara. Saya tidak suka Blueprint dan saya menggunakan beberapa gaya VS Blue Prints lainnya, seperti blender dan Unity, dan saya tidak 'tidak mengerti bagaimana orang bisa mengatakan Blue Print lebih mudah daripada Lembar Acara. Mungkin karena seniman terbiasa menggunakan node untuk mengatur shader dan grafik, mereka terbiasa dengan estetika ini. Tapi saya yakin jika Anda menempatkan sistem lembar acara di mesin seperti Unreal, orang akan menjatuhkan Cetak Biru.

Saya bekerja di sekolah yang mengajarkan logika pemrograman kepada anak-anak dan remaja. Untuk anak-anak, kami menggunakan Construct 2 karena sangat mudah bagi mereka untuk membuat sesuatu dengan Lembar Acara. Untuk remaja kami menggunakan GDScript dan kami mendapatkan hasil yang baik dengannya. Ketika Godot 3.0 keluar, kami mempelajari ide untuk menjatuhkan Construct 2 untuk menggunakan Godot VS, tetapi kami meninggalkan ide tersebut karena saat ini VS lebih sulit daripada GDScript, sangat rumit untuk dipahami dan digunakan. Jika Godot memiliki sesuatu seperti Lembar Acara, kami akan membuat kursus kami sepenuhnya berbasis di Godot, karena kami cenderung menyukai solusi Open Source di sekolah.

Manfaat lain yang saya pikir akan dibawa oleh Lembar Acara, itu akan meningkatkan basis pengguna Godot, karena di GDC kami melihat studio menengah hingga besar lebih memilih Godot, tetapi yang kecil lebih suka Unity dan solusi lainnya. Saya pikir pengguna dari Construct, Fusion, dan Game Maker akan mulai bermigrasi ke Godot.

Yah, sebagai guru saya melihat nilai yang besar di Lembar Acara, karena sangat mudah untuk dipahami dan ketika siswa pindah ke GDscript, mereka sudah mengembangkan pemikiran logis dan struktur Lembar peristiwa lebih seperti kode daripada Cetak Biru.

Bagaimanapun, saya suka apa yang dilakukan Godot dan menyukai GDscript, saya hanya ingin membuang pengalaman saya, karena saya menggunakan Lembar Acara dan GDscript untuk mengajar. Pertahankan pekerjaan hebat!

Ketika Godot 3.0 keluar, kami mempelajari ide untuk menjatuhkan Construct 2 untuk menggunakan Godot VS, tetapi kami meninggalkan ide tersebut karena saat ini VS lebih sulit daripada GDScript, sangat rumit untuk dipahami dan digunakan

Itu masukan yang cukup menarik. :)
Faktanya adalah bahwa Lembar Acara, dalam bentuk Construct2, jauh lebih rendah daripada VS atau GDscript. Memang mereka bisa membantu anak-anak untuk masuk ke pemrograman game tapi itu bukan target Godot. Saya percaya sistem seperti itu tidak boleh dikirimkan sebagai bawaan, tetapi tersedia melalui plugin. Saya kira komentar dari reduz ini juga mengungkapkan hal ini.

@DrZanuff terima kasih telah mengemukakan poin yang sangat penting ini - sesuatu yang serupa juga telah dicatat oleh saluran youtube kidscancode dan

Mungkin Godot dapat mendekati ini seperti yang dilakukan pembuat game - kode visual drag and drop mereka langsung diterjemahkan ke dalam kode gml yang bahkan dapat dipratinjau secara real time. Dengan cara itu non-coder dapat mempelajari gml saat mereka menggunakan sistem skrip visual mesin - ini adalah strategi tepat yang digunakan game yoyo untuk memperkenalkan non-coder secara bertahap ke gml
https://docs2.yoyogames.com/source/_build/3_scripting/1_drag_and_drop_overview/changing_dnd.html

Baik saat menggunakan beberapa gml untuk ekspresi dan saat mereka melihat pratinjau apa yang dilakukan pemrograman visual mereka

Bahkan sebagai tambahan - saya terus berpikir bahwa objek lembar acara godot pada akhirnya harus diterjemahkan ke gdscript. Lembar acara dapat menjadi alat untuk mengajari non-coder cara menggunakan gdscript- dengan memberi mereka antarmuka yang mudah yang masih memungkinkan penggunaan gdscript untuk ekspresi dan pada akhirnya menghasilkan dan mempratinjau gdscript.

API Godot memiliki metode untuk menghasilkan file gdscript dan melampirkannya ke node. Jadi lembar acara dapat diterjemahkan ke gdscript saat menjalankan game, atau bahkan saat mengedit lembar acara seperti pembuat game.

Alat bantu belajar tambahan yang digunakan oleh clickteam fusion dan construct2 adalah daftar menu berbasis klik dari metode/anggota node bawaan

Saat siswa mengklik salah satu item dalam daftar, sintaks yang sesuai ditambahkan ke bidang input. Ketika mereka mulai belajar, mereka mengklik, tetapi ketika mereka mengklik, mereka belajar dan menghafal sintaks dan metode. Kemudian alih-alih mengklik, mereka mengetik dengan pelengkapan otomatis dan tanpa menyadari telah mempelajari api

Dalam pengertian itu- implementasi Godot dari sistem Lembar Acara dapat memiliki tujuan utama untuk memperkenalkan non-coders ke gdscript dan konsep pemrograman dasar tanpa membingungkan mereka dengan sintaks apa pun - kemudian akan menempatkan Godot di lebih banyak sekolah yang mengajar pemrograman untuk pra-remaja. Saat mereka maju, mereka akan mempelajari gdscript dan api godot, bukan construct2 atau pembuat game

Saya pikir saya tidak menjelaskan dengan baik ... :(

Ketika saya mengatakan garis, saya mengacu pada skrip visual, ke garis yang menghubungkan node

Sistem acara konstruk dan fusi jauh lebih intuitif, mudah, dan cepat untuk membuat game, daripada skrip visual Godot

Akan lebih baik untuk mengeksplorasi alternatif jenis ini

@groud fitur tingkat yang lebih tinggi dalam cetak biru skrip visual godot juga dapat ditulis sebagai plugin - tetapi cetak biru masih akan memiliki kompleksitas desain tambahan yang kami bahas.
Dibutuhkan lebih sedikit pekerjaan untuk membuat dan memelihara fungsi tingkat yang lebih tinggi untuk sistem cetak biru saat ini, daripada menulis fungsi tingkat yang lebih tinggi fungsi lembar acara DAN sistem dasar Lembar Acara yang sama sekali baru dari awal sebagai plugin.

Jika kita memiliki implementasi tingkat rendah dari sistem lembar kejadian, akan jauh lebih mudah untuk membuat dan memelihara tindakan/kondisi tingkat yang lebih tinggi untuk itu.
Saya kira bahkan sebagai addon - pertama-tama saya akan membuat addon Lembar Acara dasar hanya dengan akses tingkat rendah dan antarmuka - yang mengikuti arsitektur godot tanpa membengkak dengan metode baru apa pun. Kemudian add-on opsional yang terpisah untuk hal-hal tingkat yang lebih tinggi dapat ditulis di atas di plugin lain.

Repositori aset dapat memiliki bagian khusus untuk tambahan skrip visual

Saya mengajar pemrograman untuk anak-anak berusia antara 7 tahun hingga 17 tahun. Saat ini siswa yang lebih muda menggunakan Cosntruct dan yang lebih tua menggunakan Godot, tetapi jika semua siswa saya dapat menggunakan Godot akan sangat berterima kasih kepada anak-anak yang menggunakan Godot dari awal perjalanan mereka di dunia pengembang game ini.

Tidak hanya sistem lembar acara. Juga bagaimana plugins/behaviours/families , UID dan properti objek bekerja.

Misalnya di C2 dalam satu objek sprite saya dapat memiliki semua seni permainan, termasuk statis/animasi dekorasi, pemain, musuh, dll... semua dengan tabrakannya, dll... dan menggunakan variabel instan pada objek yang disebut "type=" untuk mengetahui apakah musuh, pemain, objek, mudah pecah, dll... untuk mengatur perilakunya. Juga untuk setiap sprite Anda memiliki beberapa program cat dasar, properti animator, dll...

Di Godot saya mencoba contoh Pong dalam skrip visual dan ketika saya melihatnya menggunakan satu sprite untuk pemain dan objek sprite lainnya untuk tabrakan, dan saya seperti , APA!? . Juga C2 memiliki "tebak bentuk poligon" yang dengan satu klik membuat tabrakan sprite Anda menggunakan 8 poin. Setelah itu Anda dapat menambahkan lebih banyak titik dan menyesuaikan agar lebih presisi atau menggunakan beberapa plugin atau trik untuk mendapatkan presisi piksel.

Maksud saya, jika godot menerapkan sistem lembar acara seperti di C2, tetapi tidak mengikuti filosofi yang sama untuk membuat semuanya mudah digunakan, akan membuang-buang waktu karena tidak akan berhasil. Dan yah, melakukan semua ini di mesin Godot sebenarnya bisa menjadi pekerjaan yang sangat gila.

Untuk melanjutkan, mungkin mereka harus meminta/menyewa kepada orang-orang besar C2 seperti RexRainbow, R0j0hound, dll... . Tapi seperti yang saya katakan, itu berarti banyak pekerjaan dan uang.

@matriax Saya tidak berpikir Anda benar di sini.
Godot memiliki arsitektur yang jauh lebih fleksibel dan lugas daripada Construct2.
Seperti yang dicatat, pasangan objek adalah masalah dalam konstruk, di antara banyak hal lainnya - misalnya, kita dapat memiliki urutan peristiwa yang lebih jelas daripada konstruk. Kami dapat melampirkan lembar acara ke simpul mana pun - memungkinkan organisasi yang lebih baik daripada konstruksi'2.
Untuk tipe/keluarga- di godot kami memiliki "grup" - implementasi grup godot sebenarnya lebih baik daripada konstruksi.
Untuk melampirkan perilaku ke objek - Anda bisa melampirkan simpul anak dan menggunakannya sebagai perilaku simpul induk akar yang berisi lembar acara terlampir. Ini sebenarnya lebih baik daripada Membangun lagi.
Di godot, Anda harus membuat simpul bentuk tabrakan menjadi anak dari simpul yang memiliki tabrakan. Ini bukan ilmu roket dan sebenarnya lebih baik untuk mengajar anak-anak tentang pemrograman

Beberapa hal yang Anda minta harus dilakukan sebagai tambahan dan telah dibuat sebagai tambahan (tebak bentuk poligon misalnya)

Menerapkan sistem lembar peristiwa di godot yang sesuai dengan arsitektur godot saat ini akan menghasilkan sistem/platform pembelajaran lembar peristiwa yang lebih baik daripada konstruksi - karena godot memungkinkan lebih banyak fleksibilitas dalam gaya pengkodean dan memiliki arsitektur yang lebih baik. Memperluas sistem itu dengan fungsionalitas tingkat yang lebih tinggi melalui plugin akan membuatnya ramah pengguna seperti konstruksi2

Menjadikan godot sebagai user friendly seperti Construct 2 perlu menjadi upaya bersama - dari kedua pengembang inti godot dan komunitasnya. Komunitas perlu membuat fungsionalitas tingkat yang lebih tinggi melalui add-on lembar acara. Tolong jangan mencoba membuat godot persis sama dengan construct2. Hal ini dalam banyak hal lebih baik.

@blurymind Saya tidak mengatakan tentang menerapkan arsitektur yang sama daripada di C2, itu tidak masuk akal, saya juga tidak tahu semua hal yang sudah dimiliki Godot seperti grup, simpul anak, dll. Anda bilang.

Maksud saya menambahkan sistem event sheet di Godot tanpa mengikuti filosofi yang sama untuk mencapai semua pekerjaan dengan cara yang mudah seperti di C2/C3 akan membuang-buang waktu. Seperti yang saya katakan, memiliki satu objek untuk sprite/tabrakan atau semua gameart, bukan satu objek untuk setiap hal.

Mungkin mereka harus bertanya kepada komunitas berapa banyak orang yang menggunakan skrip visual yang sebenarnya, dan berapa banyak orang yang akan memilih sistem lembar acara kemudian mengambil keputusan.

@matriax Anda perlu belajar Godot sebelum membuat klaim seperti itu :)

Proposal di sini adalah untuk lembar acara, bukan untuk seluruh salinan mesin konstruksi2.

Mengetahui kedua mesin - Saya sangat percaya bahwa lembar acara dapat dilakukan dengan cara yang berpusat pada godot dan itu akan menjadikan godot sebagai alat yang lebih baik jika tidak lebih baik untuk mengajar anak-anak yang lebih muda tentang pemrograman.

Dalam pengertian itu, entitas lembar acara akan sama dengan file skrip - mirip dengan apa yang dilakukan DND di pembuat game, tidak ada apa pun di mesin atau cara kerjanya yang perlu diubah. Jika Anda menginginkan fitur konstruk2 lainnya, Anda dapat membuat beberapa tambahan

Bahkan sebagai implementasi addon- lembar acara di godot tidak boleh melakukan apa pun selain hanya membuat antarmuka lain untuk menghasilkan file gdscript imo

@blurymind Dan lagi dengan hal yang sama, ok lupa.

@matriax umpan baliknya adalah ide yang bagus. Anda benar pada titik itu.
Akan lebih baik untuk bertanya kepada sekelompok orang yang menjadi sasaran - bukan sembarang orang di internet. Kelompok sasaran dapat berupa siswa dan guru muda - yang sebenarnya akan menjadi target sempurna untuk sistem lembar acara.
guru akan tahu betul apa yang sedang diperjuangkan siswa mereka, dan pada saat yang sama akan tahu Godot dan Construct. Siswa dan non-coders dapat memberikan umpan balik yang baik

Jika Anda hanya bertanya pada pelacak godot di sini- Anda akan mendapatkan sebagian besar berpengalaman untuk programmer menengah- orang yang sudah tahu dan menyukai gdscript, api mesin dan bahkan c++
Mereka akan bereaksi secara protektif - seperti yang Anda lihat di awal posting- berpikir bahwa apa yang Anda usulkan bukanlah yang mereka butuhkan dan mesin butuhkan- tentu saja karena kita sudah tahu cara menulis kode di gdscript dan melihat tujuan yang lebih penting untuk mesin dari ini. Memang benar bahwa ada tujuan yang lebih penting.
Jika Anda beruntung, beberapa dari mereka akan mulai dengan konstruksi/pembuat game/clickteam fusion sebelum datang ke godot, dan akan tahu di mana nilainya bagi orang-orang yang belum tahu bahasa pemrograman apa pun.

Seseorang mengatakan bahwa seniman 3d menyukai cetak biru, karena mereka sudah tahu cara membuat shader. Itu adalah poin yang sangat bagus -seorang seniman 3d bukanlah seorang programmer- tetapi masih seorang individu teknis yang telah mempelajari konsep sistem grafik simpul.

Kembali ke nilai dalam hal ini- bukankah sangat bagus jika Godot , mungkin suatu hari nanti menjadi mesin pertama dari lebih banyak anak?
Mengapa tidak mencoba mengganti Construct di sekolah :) Pengembang Scirra terlalu mudah melakukannya sekarang. Lihatlah bagaimana mereka membual tentang berkolaborasi dengan sekolah
https://www.construct.net/gb/blogs/construct-official-blog-1/construct-3-a-year-in-review-947?utm_campaign=blog1postemailsub&utm_medium=email&utm_source=947&utm_term=txt4-read-laura_d% 2527s-post&utm_campaign=pemasaran&utm_source=sendgrid&utm_medium=email

Dalam hal mencoba ide sebagai addon, saya membuat bukti konsep gui WIP. Itu tidak melakukan apa-apa saat ini - itu hanya untuk mencari tahu bagaimana antarmuka dapat bekerja dan terikat dengan arsitektur godot. Belum yakin bagaimana cara menyeret untuk mengacak elemen di dalam sel dan membuat indentasi

Alangkah kerennya jika node richtextlabel di godot bisa menggunakan icon editor godot internal

Saya akan membuat maket lain untuk editor kondisi/tindakan ketika saya punya waktu :)
Editor tindakan/kondisi akan menjadi alat untuk mengedit sel/blok logika. Saya memikirkan sesuatu yang mirip dengan pendekatan Construct2 dengan editor kode internal godot sebagai editor ekspresi.
Mungkin beberapa bantuan pembantu dapat ditambahkan nanti - seperti yang ada di construct2 atau fusion

Setelah antarmuka dibuat, sisanya hanya membuatnya untuk menyimpan/menyimpan data di dalam adegan dan dapat menghasilkan gdscript yang bersih- tetapi saya mungkin kehilangan sesuatu

@blurymind Bagus, saya suka konsepnya.
Mungkin tombol untuk menambahkan tindakan dan kondisi harus tanpa tombol latar belakang, seperti di konstruksi 2

Dan saya pikir akan lebih baik untuk memisahkan kondisi dari tindakan

Saya suka cara ini berubah.

Itu mockup yang sangat rapi. Pada awalnya saya tidak benar-benar mengerti apa yang Anda maksudkan. Sekarang sudah sangat jelas... semacam langkah peralihan antara pemrograman dan jenis skrip visual yang sudah kita miliki?

@DrZanuff Terima kasih atas umpan baliknya
@Zireael07 Terima kasih :)
Ya persis - alat yang akan membantu kami mengganti Construct2 sepenuhnya dengan Godot di Sekolah yang menggunakan kedua mesin untuk mengajar pemrograman.
Di bawahnya hanya antarmuka visual untuk menghasilkan file gdscript - mirip dengan bagaimana DnD digunakan di pembuat Game 2. Saya tidak meminta perubahan apa pun pada arsitektur godot yang luar biasa.
Lembar acara dapat menjadi opsi skrip visual di Godot yang ramah pengguna untuk non coders (cetak biru tidak) dan anak-anak kecil yang mempelajari konsep pemrograman - memudahkan mereka menjadi gdscript

Godot sudah memiliki banyak elemen untuk membuat ini berfungsi, tetapi tidak bisa sama persis seperti di Construct2. Dengan cara godot akan lebih baik dalam beberapa hal jika itu terjadi. Lembar acara Construct2 memungkinkan beberapa praktik organisasi kode yang sangat buruk dan memiliki beberapa batasan/keanehan yang mengerikan. Kami benar-benar dapat membuat lembar acara yang lebih baik daripada mereka yang ramah pengguna dan mengajarkan pemrograman dengan lebih baik - tanpa kebiasaan.

Seperti yang saya lihat - banyak pekerjaan dalam membuat antarmuka untuk mengedit lembar acara - Saya punya beberapa ide lagi bagaimana membuat ini lebih baik dalam memanfaatkan fasilitas godot- tetapi saya perlu waktu untuk mengembangkan bukti konsep yang menjelaskannya. Terkadang sebuah gambar lebih berharga daripada kata-kata. Addon - lebih dari sekadar gambar

Cintai pekerjaan Anda dalam hal ini. Apakah Anda bersedia membuatnya tersedia dalam repo saat Anda mengerjakannya (jika Anda melakukannya)? Ingin melihat-lihat dan menyodoknya dan bermain-main.

@mhilbrunner Tentu saja Anda bisa - dan saya benar-benar akan menyukainya jika kalian

Saya sedang dalam proses mengintegrasikan gui ke editor godot sebagai plugin gdscript - belum cukup interaktif :)

Akan menerbitkannya di github ketika saya membuat GUI dasar bekerja secara interaktif untuk mengomunikasikan ide-ide desain :) Hari ini saya mendapatkan gui lembar acara untuk dimuat sebagai tab - mengambil beberapa inspirasi dari plugin sketchfab:

Mungkin lembar acara harus diakses dari tempat lain?

Akan memposting lebih banyak tangkapan layar pembaruan dan akhirnya tautan ke github- memperbarui posting pertama saya dengan beberapa catatan perencanaan dan tautan ke demo online dari mesin lembar acara lainnya

• Apakah kalian tahu cara mudah untuk menampilkan ikon simpul godot di dalam simpul label teks kaya melalui bbcode?
  Dalam mockup saya sebelumnya, saya menggunakan tag [img] - tetapi itu adalah pendekatan yang sangat buruk karena saya harus mengunduh semua ikon simpul yang digunakan editor godot dan menyimpannya dengan addon

• Saya juga kesulitan mencari cara untuk mendaftarkan sumber daya jenis skrip eventsheet baru melalui addon api

@blurymind sangat bagus! Sekarang lebih enak dibaca. Kita perlu memikirkan bagaimana daftar tindakan akan ditampilkan kepada pengguna.

Satu hal yang saya suka dari Construct Classic lama adalah opsi untuk mengedit nilai dari lembar acara tanpa membuka tindakan atau kondisi, tetapi klik dua kali pada nilai untuk mengeditnya:

Jika seseorang ingin menambahkan ini (sendiri melalui plugin, addon, gdnative, dll.) maka, tidak ada salahnya, tidak ada pelanggaran. Jika tidak, saya setuju bahwa scripting visual dapat ditingkatkan membuat ini berlebihan. GDscript itu mudah, sangat mudah. Dan mungkin lebih berguna untuk mengajar anak-anak daripada beberapa skrip visual janky (bahkan berbasis cetak biru) Jika seseorang membutuhkan konstruksi, maka saya katakan, dorong mereka untuk terus menggunakan konstruksi. Godot tidak perlu meniru setiap sistem lain di luar sana di intinya. Biarkan perangkat lunak tetap fokus dan tidak menjadi "jack of all trades, master of none" karena fokus yang tersebar.

@spyres tergantung pada apakah @reduz dan tim godot ingin menargetkan siswa yang lebih muda di sekolah.
Saya pribadi berpikir kita bisa mengganti konstruksi di sekolah dengan godot sepenuhnya.
Sistem cetak biru saat ini tidak akan bekerja untuk itu. Ini lebih rumit untuk digunakan daripada gdscript dan seperti yang disebutkan sebelumnya- bukan cara terbaik untuk memperkenalkan seseorang pada paradigma pemrograman- karena ia memiliki seperangkat aturannya sendiri.
Tujuannya bukan untuk menggantikan gdscript atau sistem cetak biru saat ini - tetapi sebaliknya - memberi anak-anak cara untuk mempelajari gdscript dengan membantu mereka. Ini adalah bagaimana game yoyo menggunakan sistem skrip visual DnD mereka untuk secara bertahap memperkenalkan non-programmer ke Gml btw.
Saya tidak berpikir ada salahnya memiliki sistem skrip visual yang lebih mudah diakses oleh non-programmer dan dirancang lebih baik untuk mentransisikannya ke gdscript. Mengapa Anda?

Saya mencoba menjadikannya sebagai addon, tetapi saya menemukan beberapa batasan dalam hal kurangnya dokumentasi atau api. Saya ingin mendaftarkan jenis sumber daya skrip baru dan saya ingin menyuntikkan editor lembar acara saya di dalam tab skrip - untuk mengedit file myscript.es.
Adakah yang tahu bagaimana ini bisa dilakukan - atau ada contoh yang sedang dilakukan?
Memiliki tab sendiri adalah imo yang jelek, dan tidak mengikuti desain asli editor- Saya ingin addon saya diintegrasikan dengan cara yang mulus dengan desain godot.

@DrZanuff Godot memiliki cara untuk membuat daftar semua metode yang ada di sebuah node, tetapi saya belum yakin bagaimana memfilternya ke tindakan atau kondisi. Mungkin harus menemukan cara yang lebih godot sentris untuk melakukan itu. Masih menjelajahinya dan terbuka untuk ide :)

Bagaimanapun, kami mungkin tidak akan pernah memiliki addon yang berfungsi penuh. Ini hanya untuk mengeksplorasi gagasan tentang bagaimana hal itu dapat dilakukan dengan cara yang berpusat pada dewa di sini - setidaknya untuk saat ini

Asumsi bahwa skrip visual tidak dapat (atau tidak akan) sangat ditingkatkan atau bahwa anak-anak yang lebih muda tidak akan dapat menggunakannya, atau tumbuh menjadi gdscript dari konstruksi) tampaknya benar-benar bodoh. Terutama karena skrip visualnya cukup baru.

Jika solusi untuk anak-anak yang sangat muda _(yang saya belum pernah melihat para pengembang menyebutkan sebagai demografi utama untuk Godot)_ sebesar itu, biarkan mereka menggunakan konstruksi atau solusi anak terfokus lainnya dan kemudian beralih ke pemrograman aktual melalui GDscript ketika mereka siap.

Jika Anda ingin membuatnya sebagai add-on dan mendukung add-on itu, maka intimidasi untuk Anda. Tetapi sebagai sesuatu yang duplikasi, membengkakkan inti dan (kemungkinan) membuang-buang waktu dev resmi terbatas dengan dukungan di masa mendatang, integrasi, dll., _ tidak, terima kasih. _

@spyres apakah Anda sendiri seorang pengembang? Atau seorang guru? Sudahkah Anda benar-benar menggunakan skrip visual godot di proyek Anda sendiri? Jika demikian, bagaimana itu dapat ditingkatkan menjadi alat yang lebih baik untuk mengajar orang tentang pemrograman?

@blurymind Saya pikir ide Anda bagus. Plus, Anda tampaknya sudah memiliki visi yang cukup kuat tentang itu.

Tapi, saya pikir "mengganti konstruksi di sekolah dengan Godot" bukan alasan yang sah untuk memiliki fitur ini. Saya tidak ingat Godot memiliki visi untuk mengganti mesin lain seperti Unity, Unreal, dll. Godot tidak mencoba menghancurkan alat lain. Jika alasannya untuk meningkatkan produktivitas, saya setuju.

Saya juga setuju dengan @spyres bahwa Godot tidak harus menyasar segmen pendidikan. Jika Godot tidak cocok untuk menjadi alat pengajaran pemrograman (bahkan pengembang game), biarlah. Itu tidak pernah dimaksudkan untuk menjadi yang pertama. Tetapi jika seseorang entah bagaimana dapat menggunakan/mengubah godot menjadi alat pengajaran pemrograman, saya tidak punya masalah dengan itu.

Namun, saya pikir lembar acara ini adalah ide yang menarik untuk dilihat.

@blurymind Saya pikir Anda lupa bahwa godot bukanlah alat pengajaran, godot adalah mesin permainan. Jika Anda ingin mengimplementasikan sesuatu seperti konstruksi sebagai modul eksternal, itu baik-baik saja dan terserah Anda, tetapi tolong jangan mencoba mengubah sesuatu yang dimaksudkan untuk pengembang game menjadi mainan untuk anak-anak. Mengapa mencoba mengubah godot menjadi konstruksi jika yang Anda inginkan adalah konstruksi? mengapa tidak menggunakannya sebagai pengganti godot?

@zaniar @ni-code Anda benar. Memang benar bahwa saya pribadi lebih tertarik untuk membuat alat skrip visual yang lebih efisien dan jelas daripada pendekatan cetak biru kami saat ini - yang lebih menyenangkan untuk digunakan. Saya tidak suka Construct2- jadi tidak benar saya ingin mengubah Godot menjadi itu. Seperti yang saya sebutkan sebelumnya - saya menemukan desain dan kebiasaannya sangat buruk. Itulah mengapa saya sangat frustasi karena satu-satunya tempat untuk menemukan lembar acara tidak sebagus Godot.

Sejujurnya saya berpikir bahwa bahkan jika cetak biru ditingkatkan, mereka tidak akan pernah sejelas dan secepat untuk membangun sebagai lembar acara - dalam hal lembar acara adalah alat yang hebat untuk prototyping cepat yang sering diremehkan. Tapi judul yang dibuat oleh fusi Clickteam harus berbicara sendiri. Beberapa orang mungkin melihatnya sebagai mainan - tetapi bagi saya membangun logika permainan dengan cara ini sangat menyenangkan :)

Sebagai seseorang yang telah menggunakan construct2 dan Fusion, saya menyukai pendekatan lembar acara dan melihat di api godot kandidat yang cantik untuk sistem lembar acara - tanpa kekurangan mesin yang menginspirasinya.
Desain sarang node Godot akan bekerja sangat baik dengan itu, dikombinasikan dengan kejelasan ekspresi gdscript.
Saya tidak mengharapkannya untuk diimplementasikan di godot, tetapi saya akan terus membagikan kemajuan plugin di sini, dengan harapan mendapatkan umpan balik yang bermanfaat dan bantuan dengan api. Beberapa pengembang di sini telah menggunakan Construct2 dan mengenal Godot dengan sangat baik, jadi ide bagus mungkin muncul dari diskusi.

Saya sebenarnya memiliki ide untuk sistem lembar acara yang akan memberi kita sedikit keunggulan hanya dengan menggunakan gdscript - bahkan untuk pengguna berpengalaman. Seharusnya digunakan dengan gdscript, bukan gdscript- jangan lupa itu

Saya menantikan peningkatan Visual Scripting yang tak terelakkan yang akan (karena sepenuhnya terintegrasi/didukung) menjadi lebih berguna (dan kemungkinan lebih populer) daripada plugin kiddie-centric "construct-lite" janky mana pun.

@spyres Harap menjaga nada sipil. Anda tidak perlu memberi tahu orang lain bahwa asumsi mereka " bodoh " atau bahwa plugin potensial yang mereka investasikan (gratis!) bekerja hanya akan menjadi " janky construct-lite kiddie-centric ".

Tentu, orang-orang bebas untuk menghabiskan waktu mereka (tidak berguna menurut saya pada akhirnya) seperti yang mereka inginkan, betapapun tidak kondusifnya desain inti Godot seperti itu.

Demi kesopanan (meskipun "kiddie centric" adalah _ persis_ apa yang diminta OP di sini!) mari kita mulai dengan menggambarkan lembar desain gaya konstruksi sebagai canggung , tidak fokus pada demografi inti Godot, sesuatu yang diharapkan tidak akan membuang waktu pengembang inti , dll.

Mengapa repot-repot membuat ulang konstruksi di dalam Godot _ketika mesin konstruksi yang sebenarnya sudah menyediakan fungsionalitas itu dengan cara yang kuat?_

Apakah demografi anak-anak berusia 7 tahun benar-benar berteriak untuk duplikasi semacam itu?

@mhilbrunner menjawab postingannya terasa seperti membalas troll berusia 7 tahun :D
Dia membolak-balik sebagian besar posting saya di sini- semua jempol ke bawah sebenarnya adalah miliknya.
Sepertinya tidak ada gunanya berdebat dengannya, karena dia tidak benar-benar menjawab pertanyaan - saya memang menanyakan beberapa pertanyaan valid yang dapat membantu saya mendapatkan umpan balik. Apa yang saya dapatkan sebagai balasannya lebih sama

Apakah github memiliki cara memblokir orang agar tidak memposting jika mereka kasar?

Wow, sementara saya pasti mempertanyakan beberapa ide, saya _tidak pernah_ benar-benar memanggil nama seseorang. _Itu_ menurut saya cukup kasar.

Apa yang akan menduplikasi fungsionalitas konstruk dalam Godot menyediakan yang belum disediakan dengan baik oleh er... Konstruk.

Apakah ada keuntungan yang sah untuk menduplikasi set fitur Construct (mungkin dengan cara yang lebih rendah) menjadi godot hanya untuk menarik anak berusia 7 tahun?

Mengapa Anda tidak menggunakan konstruksi saja? Apakah pengaturan mereka (yang tampaknya ingin ditiru oleh beberapa orang) benar-benar kurang?

Apakah ada alasan yang sah untuk berasumsi bahwa anak-anak tidak dapat pindah ke gdscript atau skrip visual setelah mereka melampaui konstruksi?

@spyres Anda menggunakan istilah yang umumnya menyinggung untuk menggambarkan orang yang menggunakan lembar acara dan lembar acara.
Mereka bukan "kiddies" dan sistemnya tidak "janky". Hormatilah komunitas itu demi tuhan. Dari mana datangnya sikap elitis ini?

Construct2 memiliki banyak pemrogram javascript yang sangat berpengalaman- yang seharusnya menjadi bukti bagi Anda jika Anda mengalami kesulitan untuk benar-benar membaca apa yang saya tulis dan mengikuti tautan yang saya berikan. Beberapa add-on yang mereka buat mengintegrasikannya dengan mesin 3d seperti babylon dan three.js bahkan - jadi ya - pengembang berpengalaman juga menikmati menggunakan lembar acara dan membuat game dengan itu.

Clickteam fusion membuat game jauh lebih banyak daripada game buatan Godot di steam, kickstarter, dan bahkan toko aplikasi dalam hal jumlah dan pendapatan yang mereka hasilkan. Itu adalah mesin berbasis lembar acara sepenuhnya, digunakan oleh anak-anak berusia 10-80 tahun. Ini adalah campuran dari segala usia. Beberapa pengguna adalah pembuat film, yang lain adalah seniman - orang dengan pekerjaan yang menghabiskan uang untuk lisensi, eksportir, dan sebagainya. Heck, saya menghasilkan lebih banyak uang dengan menjual barang-barang di toko aset mereka daripada apa pun yang berkaitan dengan godot sejauh ini.
Berikut beberapa contoh - Alonso Martin, pembuat film memutuskan untuk membuat game:
https://www.kickstarter.com/projects/alonsomartin/heart-forth-alicia
Sekelompok anak berusia 7 tahun membuat game
https://www.kickstarter.com/projects/galaxytrail/freedom-planet-high-speed-platform-game

lihat disini
http://indiegames.clickteam.com/
Anak-anak berusia tujuh tahun itu pasti tahu cara membuat game dan menghasilkan uang eh
https://thinkgaming.com/app-sales-data/publisher/3107/scott-cawthon/

Sudut pandang saya untuk menjual ini sebagai alat yang lebih baik untuk mengajar pemrograman seharusnya tidak menjadi alasan untuk salah memberi label seperti itu. Dengan demografi pengguna yang lebih luas - Anda berakhir dengan lebih banyak orang membuat game dengan mesin. Bukankah itu sudah jelas? kok ga jelas ya :D

Berapa kali Anda perlu saya ulangi bahwa saya tidak meminta salinan dari Construct2? Ini seperti Anda mengulangi pesan yang sama tanpa benar-benar membaca apa pun. Apa yang saya usulkan adalah lembar acara Godot centric, bukan salinan yang ada di konstruk2

Sekarang bagaimana membaca posting Anda tentang sistem yang "janky" akan memotivasi saya untuk membuat addon gratis untuk godot? Pikirkan tentang ini sedikit

Wah! Menggeser tiang gawang meskipun...

Biarkan saya mengklarifikasi.

Konstruksi cukup berhasil dalam apa yang dilakukannya. Jadi kebutuhan(?!) untuk mencangkok / menggandakan set fiturnya (seluruhnya atau sebagian) di mesin yang sama sekali berbeda (tanpa manfaat yang terlihat) luput dari saya.

Pertanyaan mengenai manfaat sebenarnya tetap sama, meskipun beberapa mungkin (tidak dapat dijelaskan) menganggapnya "menyerang".

Apakah saran bahwa add-on yang dicangkokkan ke mesin yang sama sekali berbeda akan lebih baik daripada menggunakan konstruksi? Dari itu memiliki sesuatu yang tergabung (bahkan melalui add-on) adalah sesuatu yang kami harapkan banyak orang untuk menggunakan solusi yang kuat (yaitu membangun)? Saya meragukan itu.

Tapi hei, mengapa berhenti di situ? Alat yang sangat baik (di luar konstruksi) ada untuk mengajar pemrograman anak-anak (misalnya Scratch , Styncl , code.org dll.) Mengapa tidak memasukkannya ke dalam Godot juga!

Atau mungkin tidak... ;-)

Adakah yang pernah menggunakan Visual Scripting Godot dan sepertinya dia hanya menggunakan Visual Scripting Godot?

@Zonacas Saya tidak berpikir bahwa Godot's Visual Scripting cukup matang untuk itu, tapi saya mungkin salah. Perlu diingat VS baru dirilis selama dua bulan saat ini. :)

@Zonacas coba lihat saluran VS di server perselisihan, saya telah melihat satu atau 2 non programmer yang menyatakan diri menyukainya (tetapi juga penuh dengan programmer yang mengatakan bahwa itu tidak baik untuk non programmer).

Hai semuanya, saya memiliki pembaruan kemajuan pada bukti konsep addon saya.

Ini adalah gif segar untuk Anda:

Beberapa latar belakang dalam apa yang dilakukannya - Pada dasarnya lembar acara terbuat dari sel. Sebuah sel dapat berupa kondisi (getter/ekspresi) atau tindakan (setter yang dapat diumpankan dengan getter/ekspresi).
Di sisi GUI, sel acara dibuat melalui node richtextlabel dan bbcode yang dihasilkan dari gdscript. Saat Anda mengklik dua kali padanya, richtextlabel berubah menjadi node kotak edit yang berisi ekspresi gdscript yang sebenarnya.

Jadi sel lembar acara memiliki 2 mode:

• mode edit - simpul textEdit yang dapat diketik dengan gdscript.
  Satu-satunya perbedaan adalah bahwa pengguna tidak perlu mengetikkan If/else/sementara - yang peka konteks terhadap wadah induk seperti yang terlihat pada tangkapan layar. Setiap baris adalah kondisi baru, jadi jika pengguna belum memulai baris dengan "atau" atau yang lainnya, pengurai secara otomatis mengetahui bahwa baris baru memiliki dalih "dan"

Saat diklik, beralih ke mode tampilan.

• mode tampilan - label richtext - Saat beralih ke mode tampilan, bbCode diurai dari gdscript yang ada dalam mode edit dan disajikan melalui label richtext interaktif. Selain interaktif dan mudah diubah, tujuannya adalah untuk menyajikan kode gdscript dengan cara yang lebih jelas. Ini berarti menunjukkan nama dan ikon simpul saja (bukan seluruh jalur) dan menghilangkan beberapa kata, jika sudah jelas (seperti get_ dan set_). Karena setiap bagian yang dapat diklik sebenarnya adalah tag url, ketika mengarahkan kursor ke nama node misalnya - pengguna bisa mendapatkan beberapa informasi, seperti path lengkap dari node.

Tentang menu Tambahkan kondisi/Tindakan baru:
Inilah yang membuat baris kode gdscript baru untuk suatu kondisi atau tindakan. Apa yang hebat tentang itu adalah memungkinkan Anda dengan mudah menelusuri semua node di dalam adegan dan metodenya - ini bekerja dengan cara terbalik dengan cara pelengkapan otomatis bekerja di editor gdscript. Ini menunjukkan semua node dan semua setter, getter atau keduanya metode. Anda kemudian dapat mempersempit ke apa yang Anda inginkan melalui filter.
Jika panggilan dari sel kondisi, menu ini hanya menampilkan pengambil, jika dipanggil dari sel tindakan, menu ini menunjukkan metode penyetel dan pengambil.

Apa yang harus dilakukan selanjutnya agar ini berfungsi:

• Saya perlu mencari cara untuk melakukan menyeret sel - untuk dapat dengan mudah mengubah urutan acara.
• Juga menyalin dan menempel dalam mode pratinjau.
• Selanjutnya saya harus membuat editor ekspresi yang muncul ketika jenis tertentu dari url sel mode pratinjau diklik
• mencari tahu bagaimana menangani item placeholder. Saya berpikir untuk memberikan komentar, tetapi sayangnya godot tidak mendukung komentar sebaris: https://github.com/godotengine/godot/pull/18258 jadi saya mungkin harus kembali ke papan gambar yang itu

Idenya berkembang menjadi sesuatu yang lebih dari sekedar alat pengajaran. Saya pikir saya dapat menawarkan beberapa fungsionalitas yang benar-benar menghemat waktu kepada orang-orang yang sudah mengenal dan menyukai gdscript, tetapi saya akan membutuhkan lebih banyak waktu untuk mengembangkan ini ke titik di mana saya dapat menyajikan kepada Anda caranya.

Terima kasih untuk semua orang atas dukungannya

Ide bagus untuk sebuah plugin. Tetapi secara resmi mempertahankan dua sistem skrip visual akan menyusahkan, dan untuk sedikit keuntungan.

XKCD:Standar

Saya tidak mengerti mengapa ini bukan addon/plugin yang sebenarnya daripada hanya bukti konsep. Tidak semuanya harus dibundel dengan mesin secara default. Maksud saya, bukankah itu sebabnya GDNative dikembangkan?

@Megalomaniak Itu benar dan percayalah ketika saya mengatakan bahwa jika saya memiliki pengetahuan yang cukup tentang api godot, saya akan menulis ulang ini sebagai tambahan gdnative. Tetapi bahkan sampai sejauh ini saya telah berjuang dan saya benar-benar kehilangan beberapa elemen kunci untuk mengubahnya menjadi alat yang sebenarnya dapat digunakan. Saya telah mengajukan pertanyaan di sini, tetapi sejauh ini tidak ada yang benar-benar memberi tahu saya jawaban atau menunjukkan contoh:

• Bagaimana cara mendaftarkan jenis sumber daya skrip baru di editor godot dan mengizinkan pengguna untuk melampirkannya ke simpul mana pun? Saat ini addon beroperasi dari root of the scene dan hacky-nya.
• Bagaimana kita kemudian membuatnya sehingga godot membuka gui lembar acara saya - terintegrasi dengan sistem cetak biru saat ini
• Bagaimana kita membuat simpul editText bertindak seperti editor gdscript godot - mengaktifkan pewarnaan sintaks dan pelengkapan otomatis. Selain itu, bagaimana kami memberikan konteks khusus?

Seseorang dengan pengetahuan API yang sangat rendah dapat melakukan ini. Hal-hal semacam itu tidak ada dalam dokumentasi - tidak ada contoh yang ada juga.
Saya memiliki ide desain, tetapi belum memiliki gambaran yang lengkap untuk melakukannya

Sejauh ini saya hanya dapat terus mendorong konsep desain dan mempelajari lebih lanjut tentang api, tetapi tidak dapat dengan tegas menjamin bahwa ini dapat diubah menjadi addon yang benar-benar berfungsi sepenuhnya. Orang-orang sepertinya sangat menyukainya sejauh ini

Untuk hal-hal seperti ini, saya lebih suka menghormati keinginan para pengembang:

https://godot.readthedocs.io/en/3.0/about/faq.html

Aku punya ide bagus yang akan membuat Godot lebih baik.

Ide Anda pasti akan diabaikan.

Ayo lakukan ini karena itu akan membuat Godot lebih baik
Ayo lakukan ini di Godot karena mesin game lain melakukannya
Mari kita hapus ini karena saya pikir itu tidak diperlukan
Mari kita hilangkan kekacauan dan kembung dan membuat Godot terlihat lebih bagus
Mari tambahkan alur kerja alternatif untuk orang yang menyukainya

@spyres Saya sebenarnya membuat ini dan mencari dukungan dari pengguna godot lain di API tentang hal-hal yang tidak dapat saya temukan di dokumentasi - mencoba memberikan kontribusi kepada godot.
Apa yang kamu lakukan di sini?

Anda adalah satu-satunya orang yang membolak-balik semuanya dan mengulangi hal yang sama di setiap posting. Itu sangat buruk seperti yang dilakukan troll, setujukah Anda? Anda berada di samping melacak percakapan dari mendiskusikan ide-ide desain

@blurymind "Kontribusi" satu orang adalah gangguan orang lain (atau mesin). Maaf bahwa konsep pendapat yang berbeda (bahkan dari para pengembang yang mereka rasa cukup penting untuk diposting sebagai bagian dari dokumen resmi) tampaknya sangat tidak menyenangkan bagi Anda.

Semoga berhasil dengan add-on Anda. :menyeringai:

@spyres tetapi apakah Anda benar-benar membuat sesuatu? Apakah Anda pernah membuat addon untuk godot? Apakah Anda menggunakan godot?

Mengapa kamu di sini? Anda tidak mencoba berkontribusi pada diskusi

@blurymind Wow, pendapat yang berbeda benar-benar mengganggu Anda? Betapa menyedihkan untukmu.

@spyres semua orang di sini dapat melihat pendapat Anda - Anda mengirim spam ke utas dengannya. Setiap jempol di sini adalah milikmu. Ini bukan opini - ini adalah spam. Setidaknya nitpick pada desain dan hal-hal tertentu? Saya menanyakan beberapa pertanyaan sebelumnya - Anda tidak pernah menjawab apa pun

Untuk lebih jelasnya, saya benar-benar mendukung siapa pun yang menggunakan waktu mereka namun mereka ingin membuat sesuatu seperti ini sebagai add-on yang dapat diabaikan dengan tenang oleh orang-orang seperti saya yang tidak menemukan nilai di dalamnya.

Sebagai alur kerja alternatif yang benar-benar terintegrasi ke dalam inti godot? Ugh, tolong, tidak. Saya dengan pendapat devs hal semacam itu.

@spyres ya, Anda sudah mengatakannya. Gulir ke atas dan baca 5 kali lagi. Ada salah satu dari kalian .. tapi berkali-kali

@blurymind Dan entah bagaimana sepertinya mengganggu Anda? Wow, pendapat alternatif dan semacamnya.

Saya kira _you_ belum mengulangi apa pun benar? (Siapa kamu, Kenapa kamu di sini, Justify your dagnabbit!). :nyengir:

Saya kira sedikit komentar dokumentasi resmi yang ditulis oleh para pengembang menyebabkan sedikit gangguan pencernaan ya?

ya, itu sangat mengharukan

@blurymind Terima kasih, peluk semuanya!

Saya benar-benar dengan Anda yang terbaik dari keberuntungan menerapkan ini melalui gdnative, di mana itu akan ada untuk mereka (sangat sedikit yang saya curigai) yang menginginkan sesuatu yang tidak resmi seperti itu.

Namun, jika Anda tidak dapat memperoleh informasi, bantuan yang Anda perlukan untuk mewujudkannya, mungkin ini saatnya untuk mengevaluasi kembali seberapa besar arti ketersediaan bahasa alternatif ini bagi Anda.

@spyres Tolong hentikan spamming. Saya tidak membutuhkan email dan notifikasi ini. Anda menyuarakan pendapat Anda, itu bagus, tetapi Anda tidak perlu terus mengulanginya.

@mhilbrunner Jika pendapat saya yang berbeda membuat Anda sedih, silakan klik avatar saya lalu pilih "blokir pengguna". Setiap rasa sakit yang disebabkan oleh membaca komentar saya akan segera berhenti. :senyum:

@spyres Saya telah mencatat di posting sebelumnya bahwa addon ini bertujuan untuk menggunakan gdscript, bukan sebagai bahasa alternatif. Dan ya, sepertinya tidak ada yang memoderasi pelacak ini

Nah, semakin cepat Anda selesai, semakin bahagia kita semua, bukan ? Saya yakin ini akan bagus untuk beberapa orang yang benar-benar menginginkannya, seperti banyak pengaya lainnya. Sulit untuk melihat ini menyebabkan Anda terlalu banyak rasa sakit yang tidak semestinya, jadi tolong jaga diri Anda dan jangan biarkan kurangnya informasi/kemajuan membuat Anda kecewa. Saya yakin jika ada gelombang besar dukungan publik, Anda akan segera mendapatkan semua informasi/bantuan yang Anda butuhkan.

Dalam kata-kata orang bijak, "Jangan khawatir, Berbahagialah". :nyengir:

Atau "Semuanya menyenangkan dan permainan sampai seseorang menembak mata mereka!" (um, tunggu, saya rasa bukan itu kutipan yang saya cari...)

WOW. Jujur saja, ini luar biasa!

Ketika saya pertama kali membaca posting Anda, saya setuju tetapi sedikit khawatir akan ada pertengkaran besar tetapi ketika Anda datang dan menunjukkan bahwa Anda tidak menggonggong dan tidak menggigit dan benar-benar mulai mengembangkan addon, saya terkesan.

Saya MENYUKAI interaksi dengan GDScript karena itu adalah fitur besar di studio pembuat game (Kemampuan pertukaran visual dan skrip yang tepat) yang tidak benar-benar layak dengan sistem berbasis simpul.

Setelah ini selesai, ini akan membantu BANYAK orang

Saya telah menjadi pengguna Construct selama 6 tahun terakhir dan saya dapat dengan pasti mengatakan itu adalah cara terbaik untuk mendekati skrip visual tercepat dan paling sederhana.

Ide bagus!

Ini akan sangat berguna. Saya tidak sabar menunggu sampai dirilis!

Ide brilian, berkolaborasi dengan SnailOn.

1. Dia jenius.
2. Dia menggunakan Godot sekitar 3 tahun.
3. Dia menggunakan mesin Clickteam sejak TGF
4. calon yang ideal.

@boruok Saya telah menjadi penggemar saluran yt snailon sejak awal. Tutorialnya telah membantu saya belajar fusion sejak lama. Apakah dia memiliki akun github? Saya akan senang untuk mengambil pikirannya pada beberapa hal.

Btw saya harus mengakui bahwa saya lebih condong ke menu klik seperti Fusion daripada apa yang digunakan Construct2 untuk memutuskan cara mengisi sel. Menu pembantu yang disajikan dalam pembaruan 1 pasti dipengaruhi oleh desain Clickteam. Dalam addon ini Anda akan melihat bahwa saya tidak membuat salinan karbon dari mesin apa pun, melainkan meminjam ide yang akan bekerja lebih baik untuk pendekatan yang bagus dari lembar acara. Ada sedikit pembuat Game juga - dalam cara skrip visual dapat dengan mulus beralih ke skrip aktual - sesuatu yang mungkin dihargai oleh pengguna yang lebih mahir

Terima kasih kepada semua orang untuk mengikuti kemajuan pada addon ini. Reaksi awal sangat positif
Ini sangat memotivasi saya untuk terus mendorong ide tersebut lebih jauh, sambil juga berusaha membuatnya tetap sederhana dan elegan.

Tanpa komentar sebaris, sulit untuk tetap mudah beralih antara gdscript dan visualscript, tetapi saya punya beberapa ide tentang cara mengatasinya dan bereksperimen - jadi saya sedang mengerjakan atm itu.
Saya perlu beberapa cara untuk mendefinisikan dalam gdscript placeholder kosong tempat ekspresi diharapkan.
Karena ekspresi akan mengembalikan jenis nilai, saya berpikir untuk menggunakan metode konversi nilai di godot untuk menandai placeholder:
float() ## this will turn into a bbcode item that expects an expression resulting in a float
Tapi itu bisa agak jelek karena akan menghasilkan banyak metode konversi tipe variabel yang tidak perlu di dalam gdscript yang dihasilkan akhir

Jika godot dapat melakukan komentar sebaris, saya akan dapat menguraikannya ke metode yang membuat bbcode dari gdscript sebagai gantinya. Ini akan memungkinkan saya untuk memberinya makan dengan beberapa informasi tambahan

Pendekatan terbaik sebenarnya adalah membuat gdscript saya ke metode parser bbcode lebih pintar - itulah yang saya coba lakukan sekarang

@blurymind saya tidak tahu tentang akun git. btw, dia membuka video lagi. Saya telah mengirim beberapa pm kepadanya melalui, youtube dan facebook. Mari berharap dia akan muncul di sini.

@blurymind saya mendukung ini 100%!
(Maaf sebelumnya untuk bahasa Inggris)

Jika kita memberikan tampilan yang tepat pada halaman tentang di luar apa yang dapat digunakan untuk menjebak orang, inilah yang dapat kita lihat:

Pengembang tertarik (misalnya):

Pengalaman Anda menggunakan perangkat lunak dan masalah yang Anda miliki (kami lebih peduli tentang ini daripada ide tentang cara memperbaikinya).
Fitur yang ingin Anda lihat diimplementasikan karena Anda membutuhkannya untuk proyek Anda.
Konsep-konsep yang sulit dipahami untuk mempelajari perangkat lunak.
Bagian dari alur kerja Anda yang ingin Anda lihat dioptimalkan.
Bagian di mana Anda melewatkan tutorial yang jelas atau di mana dokumentasinya tidak sesuai standar.

Dengan mengingat hal ini:

• Skrip visual saat ini hanya dapat digunakan jika Anda tahu cara membuat kode secara nyata. Dan menjadi lebih cepat berantakan daripada kode keras. Siapa yang membantu itu? Dan cetak biru juga tidak terlalu membantu, kecuali Anda memiliki latar belakang teknis yang sangat spesifik.

• Lembar acara tingkat tinggi berfungsi dengan baik. Seperti yang terlihat dengan keberhasilan semua aplikasi yang disebutkan di atas. Jika dilakukan dengan baik, mereka benar-benar lebih mudah dipahami dan digunakan untuk non-coders.

• Mengapa Godot melayani non-coders?
  Saya melihat banyak kegunaan untuk ini bagi banyak orang yang mengerjakan proyek profesional.
  Dalam banyak proyek, kecil, menengah & besar, sebagian dari tim akan melakukan pengkodean, dan sebagian lagi akan mengerjakannya sendiri. Musik & suara, visual/animasi/SFX/UI, desain game, penulis, dll...
  Kadang-kadang bahkan tim satu orang, atau orang-orang dari luar industri seperti pembuat film ini melakukan permainan yang cukup sukses.
  Beberapa orang bahkan ingin melakukan pemrograman tetapi tidak coding karena berbagai alasan.
  Misalnya masalah seperti disleksia membuat kode menjadi mimpi buruk, namun pemrograman masih dimungkinkan melalui pendekatan yang lebih visual seperti lembar acara.
  Sebagian besar waktu orang-orang ini memiliki hal lain yang harus dilakukan selain coding saat mereka menghasilkan hal-hal yang dibutuhkan dalam permainan.
  Lembar acara akan memungkinkan seorang pembuat grafik, perancang suara atau game untuk menguji atau mengimplementasikan karyanya dengan sangat mudah tanpa menyelami kode mentah.
  Itu juga akan memungkinkan beberapa pembuatan prototipe super cepat, untuk menguji bukti konsep seseorang. Lempar banyak gambar stok, klik di sana-sini sedikit dan Anda dapat memeriksa apakah ide Anda menyenangkan sekarang. Bahkan pembuat kode dan nama besar/studio yang baik menggunakan hal-hal paling sederhana yang mungkin untuk diulang di awal proyek.
  Lebih banyak umpan balik dan diskusi tentang semua itu di sini , dan saya sangat setuju dengan OP.
  (Github bukan tempat terbaik untuk umpan balik tentang ini, orang-orang yang datang ke sini biasanya mendalami pengkodean dan tidak dapat 'melihat kebutuhan, meskipun sebenarnya minoritas.)

• Kesimpulan: Memberi orang alat yang sederhana namun efisien untuk berinteraksi dengan Godot akan menjadi anugerah di berbagai tingkatan bagi sejumlah besar orang dewasa serius yang bekerja pada proyek profesional.
  (Bukan hanya anak-anak & sekolah, bahkan jika itu memang akan membantu mereka juga.)

• Omong-omong, ada alat lain yang disebut GDevelop yang menggunakan lembar acara jika Anda ingin melihat lebih banyak contoh. Antarmuka sebelumnya (versi 4) cukup bagus, yang saat ini (v 5) agak buruk, aplikasi ini memiliki beberapa ide bagus, tetapi beberapa kelemahan, dan arahnya agak tidak jelas juga tetapi mungkin memberi Anda beberapa ide, atau setidaknya titik perbandingan lain.

Selamat atas pekerjaan yang telah dilakukan, untuk tetap positif dan termotivasi meskipun ada reaksi tertentu, dan untuk mempercayai ide Anda. Saya juga mengonfirmasi bahwa itu memang akan sangat berguna dan akan memperbaiki masalah besar bagi saya.

@TheGoklayeh Terima kasih atas kata-kata penyemangat yang baik. Saya tahu persis apa yang Anda maksud. Seperti disebutkan sebelumnya di sini- game sukses indie Clickteam fusion membuat jauh lebih banyak daripada game sukses buatan Godot.
Game yang diterbitkan, jumlah penjualan di steam dan mobile dan kickstarter memenuhi tujuan mereka.
Itu harus menjadi bukti yang cukup bahwa seniman dan desainer profesional menggunakannya - bukan hanya "anak-anak"

Pada topik IDE baru Gdevelop, saya pikir itu hebat, tetapi fiturnya tidak lengkap. Satu langkah cerdas yang dilakukan pengembang utama adalah mem-porting ide ke javascript- membuatnya sangat mudah diakses oleh pengembang non c++ untuk berkontribusi. Saya telah benar-benar berkontribusi untuk itu dengan perbaikan kecil sejauh ini - hanya untuk bermain dan belajar. Akhir pekan ini saya akan mencoba membuat beberapa langkah untuk mengintegrasikan piskel ke dalamnya - jika semuanya baik-baik saja, mungkin akan mendapatkan editor piksel bawaan.
Pengembang utama baru-baru ini menggabungkan kontribusi dengan pengembang lain yang menambahkan dukungan dragonbones di luar kotak. Jika Anda mau, coba rilis terbaru dari github- bukan demo online. Ada barangnya
https://github.com/4ian/GD/releases

Saya juga masih membuat kemajuan yang lambat pada addon ini. Beberapa hal perlu difaktorkan ulang sebelum saya dapat melangkah lebih jauh dengannya.

Mungkin ide yang bagus untuk mendapatkan semua pengguna fusion dan pengguna construct2 yang juga menggunakan godot di sini. Tunjukkan pada mereka utas ini dan dapatkan mereka untuk umpan balik tentang desain.
Snailon belum menghubungi saya - tapi ya - dia adalah programmer yang sangat berpengalaman dalam hal lembar acara. Saya tidak tahu bahwa dia adalah pengguna godot juga.

Ini terlihat luar biasa! Terima kasih telah mengembangkan/mendorong ini, blurymind.
Saya telah melakukan gamedev selama 23 tahun atau lebih, pada dasarnya mencoba segalanya- semua alat/mesin gamedev populer, bahasa program, dll. dan saya lebih suka lembar acara di penghujung hari karena memungkinkan saya menyelesaikan game. :)
Memilikinya dalam pendekatan daftar top-down yang terbagi antara kondisi dan tindakan membuatnya lebih teratur dan ringkas daripada sistem lainnya. Karena saya lebih berorientasi visual, memiliki struktur kaku yang vertikal/horizontal memungkinkan saya untuk mengalir melalui program/acara dengan nyaman.
Script visual lain yang membutuhkan koneksi spaghetti sangat berantakan dan mengganggu- detail visual tersebar dalam estetika yang bising yang memecah konsentrasi untuk orang yang berpikiran visual (orang yang sama seharusnya script visual ditujukan).
Lembar acara adalah yang terbaik untuk saya. Saya telah menghabiskan 23 tahun, menggunakan segalanya - blitzbasic, gamesfactory, unity, c ++, javascript, dll, dan saya yakin akan hal ini - saya suka lembar acara!!

Hanya ingin ikut campur, pengeditan gaya cetak biru / simpul sangat sulit untuk diatur / dihindari "Kode spageti". Bagi siapa pun yang menganggapnya sama dengan acara gaya Clickteam/Construct/GDevelop maka saya minta maaf tetapi mereka sangat berbeda, dan lembar acara secara objektif lebih baik (permainan berbasis aturan IF/THEN di alam, dan Anda dapat lebih mudah bertransisi dari peristiwa ke kode, tetapi peristiwa pada umumnya lebih cepat daripada pengkodean logika permainan).

Saya yakin ada saat-saat di mana pengeditan berbasis simpul berguna, tetapi pengeditan berbasis acara akan dengan cepat menjadi opsi yang lebih disukai jika disertakan dalam Basis Godot Visual Scripting.

@bigelod @prominentdetail terima kasih telah memberikan lebih banyak umpan balik tentang apa yang membuat lembar acara begitu bagus - tidak hanya untuk mereka yang belajar kode- tetapi juga untuk programmer yang lebih berpengalaman.

Saya pikir Anda benar sekali. Sama seperti @prominentdetail, saya mulai dengan lembar acara yang

Saya juga memperhatikan tren di atm komunitas mesin permainan lembar acara, yang benar-benar dapat dimanfaatkan oleh godot untuk memperluas basis penggunanya:

• Komunitas pengembang yang menggunakan lembar acara sangat menginginkan mesin 3d yang menggunakan lembar acara. Kedua komunitas clickteam fusion mencoba mengintegrasikannya sebagai addon (kunang-kunang) dan Construct (banyak plugin dicoba) - tetapi add-on tersebut tidak menyediakan kemampuan pengeditan adegan 3d- mereka adalah peretasan untuk membuat lembar acara bekerja dengan mesin 3d - letakkan di atas 2d editor mesin tidak dirancang untuk game 3d. Anda hanya dapat membuat adegan 3d dengan logika peristiwa di dalamnya - membuatnya sulit untuk meletakkan objek, mengatur materi, dll.
• Baik pemrogram yang belajar maupun yang berpengalaman masih menyukai lembar acara dan menggunakannya untuk membuat prototipe - bukan hanya mengajar.
• Banyak tim indie telah berhasil menggunakan (dan masih menggunakan) lembar acara untuk membuat judul yang sukses - kicktarter, steam, dan platform lainnya - tetapi sangat sedikit yang merupakan proyek 3d karena poin pertama

Sekarang membuat ini berfungsi sebagai addon di godot itu rumit, karena beberapa hal di mesin yang saya tidak yakin bagaimana cara mengaksesnya. Implementasi saat ini yang saya miliki cepat dan berantakan dan tidak melakukan apa pun selain menunjukkan bagian bagaimana gui dapat dilakukan. Saya akan mencoba membuatnya lebih rapi dan akan mempostingnya di sini

Sebagai tambahan, saya berhasil membuat Piskel dibundel dan terintegrasi dengan Gdevelop. Ini membuat saya sibuk dalam beberapa minggu terakhir. Anda dapat mencobanya jika Anda mau :)
Saya telah melihat bagaimana lembar acara dilakukan di gdevelop juga

@blurymind Ok katakan saja saya mencoba mengabaikan posting ini di sini, karena saya tidak menyukai gagasan dua Skrip Visual.

Tapi akhirnya sudah cukup saya pikir itu akhirnya waktu untuk memulai beberapa diskusi. Saya Percaya Anda pasti telah menggunakan dokumen untuk membangun GUI. Mockup adalah pekerjaan yang cukup bagus, saya ingin bertanya apakah ada repo saya mungkin bisa melihat kodenya sedikit. Mungkin bisa melakukan sesuatu untuk membuatnya lebih seperti EventSystem, dan lebih bisa diterapkan.

Saya berencana melakukan beberapa pekerjaan pada sistem Visual Scripting saat ini. Dan ketika saya bertemu GDevelop dan menyukainya, saya datang ke sini untuk bertanya. Setelah satu jam membaca, kesimpulannya jelas, kita perlu menemukan jalan tengah.

Mempertahankan dua sistem Visual Scripting yang berbeda tidak mungkin, salah satunya harus mati. Tetapi tidak seorang pun termasuk saya yang ingin berpisah dengan struktur simpul Blueprints.
Tapi EventSystem ini terlalu enak (setidaknya untuk prototipe dasar) untuk tidak dimakan.

Saya ingin VisualScripting menjadi lebih dari alat prototyping. Keterbatasan fitur tidak masalah jika benar-benar dapat meningkatkan basis pengguna.
Lebih banyak pengguna juga sama dengan lebih banyak donasi jika tidak ada yang memperhatikan ini sebelumnya, maka itu harus dipertimbangkan.

Tapi Blueprints adalah alat tingkat industri sehingga memiliki kegunaan dan mungkin membawa ikan yang lebih besar untuk Godot yang penting untuk Godot juga. Dan saya katakan mungkin tidak tahu banyak tentang itu juga.

Jadi pertanyaannya sederhana, apa yang harus dilakukan? - Memilih keduanya bukanlah suatu kemungkinan.
Tapi hibrida mungkin membuat Godot lebih populer.
Karena Anda berpengalaman dengan kedua gaya Visual Scripting setidaknya lebih dari saya. (Saya lebih dari seorang pembuat kode daripada artis jadi suka membuat kode dengan cara saya) Mengapa tidak mencoba mencari solusi.

Ini kemungkinan akan membawa lebih banyak orang daripada yang bisa dilakukan oleh EventSystem saja. Dan menjaga sistem node tetap hidup juga akan menjadi langkah yang baik.

Jadi bagaimana jika tidak ada jalan tengah yang bisa dicapai. Sesuatu akan mati begitu saja. Tidak peduli apa itu.

Secara pribadi saya mungkin memilih Cetak Biru karena saya memiliki pengalaman sebelumnya dengan itu, dan saya ingin ikan yang lebih besar untuk dibandingkan dengan Unreal.
Tapi sebagai perbandingan, saya mengambil GDevelop dalam waktu kurang dari 15 menit. GDScript di bawah beberapa jam pada hari yang terpisah dan Blueprint dua kali lipat dari GDScript pasti.
Meskipun itu juga menunjukkan tingkat pengalaman saya sebagai seorang programmer.

Aku hanya tidak bisa memutuskan. Di sini lihat.

1. kesatuan: 4011
2. Tidak nyata: 316
3. Pembuat game: 274
4. Konstruksi: 223
5. Godot: 75
   _Daftar dari tweet Reduz jumlah game per mesin di Global Jam._

Saya ingin Godot di atas. Jadi semoga beberapa cinta VS akan membantu mencapai itu.
Tapi Unreal + Godot + GameMaker + Construct masih belum berhasil. Tapi menjadikannya nomor 2 setidaknya.

Saya bingung sekali apa yang harus direncanakan untuk masa depan Visual Scripting Godot. Karena menunggu di sistem saat ini atau tanpa berpikir mencoba memperbaiki sesuatu yang rusak tidak akan membantu.

"EventSystem seperti pemrograman dengan Scratch sampai tingkat tertentu. Sedangkan Blueprint benar-benar unik tetapi lebih kuat daripada EventSystem menyebabkan EventSystems menjadi lebih membingungkan dengan kedalaman dan memiliki keterbacaan yang lebih rendah."

Apa?? Ini kebalikannya jika Anda mencoba sistem acara Construct, terutama termasuk lembar acara lain dan menggunakan grup.

Sistem simpul terbaik akan selalu menjadi spageti kode dibandingkan dengan Sistem Acara rata-rata.

@bigelod Benar tidak boleh dikatakan seperti itu. Saya pikir itu mirip. Saya menulis komentar itu selama 2 jam sambil mempelajari EventSystems. Maaf tentang itu akan memperbaikinya.

Ya saya tahu yang terbaik adalah cetak biru dan itu luar biasa untuk memiliki sesuatu seperti itu tetapi sistem acara menambahkan lebih banyak hal ramah pemula. Dan juga membantu dalam belajar Pemrograman.

@swarnimarun bertahun-tahun yang lalu saya melempar lembar acara ke pengembang godot di pelacak yang sama ini. Tapi saya tidak melakukan pekerjaan dengan baik saat itu dan sudah ada lebih banyak dukungan untuk cetak biru, karena banyak pengguna godot juga mantan pengguna unity/Unreal. Cetak biru sudah menang dan sekarang ada di Godot.

Sekarang banyak pengguna yang sebenarnya berasal dari mesin seperti clickteam fusion, pembuat game, dan konstruksi mendukung lembar acara dan sangat tidak suka menggunakan cetak biru. Mereka akan mengatakan kebalikan dari apa yang Anda katakan dan menjelaskan apa yang sudah dijelaskan - mengapa cetak biru membingungkan jika dibandingkan dengan lembar acara dan bahkan skrip. Saya sudah melakukannya juga.

Neraka bahkan ketika melihat forum mesin pemrograman visual lainnya, Anda dapat melihat reaksi negatif terhadap mesin sistem cetak biru apa pun:
https://rpgmaker.net/forums/topics/23922/?post=857285#post857285

Sekarang pada akhirnya saya tidak melihat alasan mengapa kedua sistem tidak bisa ada. Mereka dapat bekerja bersama - cara cetak biru dapat bekerja sama dengan node gdscript.

Bahkan di dunia yang ideal, Anda ingin lembar acara untuk membangun dan prototipe cepat dengan logika granular dan cetak biru untuk mengaturnya di mesin negara.
Mengapa? Karena kedua sistem memiliki pro dan kontra.

Cetak biru Godot dapat dengan cepat menjadi berantakan ketika Anda mulai membuat ekspresi sederhana dengan node. Ekspresi yang sama ini bisa lebih jelas dalam lembar acara atau skrip.

Proyek open source bersifat demokratis- semakin komunitas mendukung sebuah ide, semakin besar kemungkinan itu akan menjadi nyata. Tapi itu tidak berarti bahwa ide lain harus dibunuh. Kedua ide tersebut disukai atau tidak disukai secara luas.

Semua orang di sini harus menyadari bahwa dengan lembar acara dan cetak biru- mereka akan memprogram dari awal. Yang paling penting adalah seberapa jelas sistem memungkinkan mereka untuk menyusun logika mereka. Dengan cetak biru, urutan eksekusi bisa menjadi masalah debug yang membuat sulit. Ini juga membutuhkan lebih banyak klik dan langkah untuk menyiapkan jika dibandingkan dengan lembar acara. Ini adalah nada utama saya di sini- baik untuk pengembang pro dan penggemar pemrograman visual. Tetapi juga jangan lupa bahwa ini adalah masalah selera pribadi. Saya tidak akan mencoba dan membuat pengembang cetak biru menjadi penggemar ini. Saya malah akan menunjukkan bahwa banyak pengembang pemrograman visual tidak menyukai cetak biru dan lebih memilih lembar acara.

Lembar acara dapat menggunakan gdscript untuk ekspresinya dan dengan cara itu benar-benar membantu mereka yang berasal dari mesin jenis lembar acara mempelajarinya dengan sangat cepat

Mungkin sistem acara dapat digunakan sebagai alat pembuat simpul khusus.

Hanya ingin mengemukakan pendapat tentang sesuatu - jujur, saya tidak merasa bahwa lembar acara hanya untuk prototipe. Saya pikir bagian dari masalah dengan pola pikir bahwa genap hanya untuk pembuatan prototipe adalah karena banyak alat yang menggunakannya mendorong konsep yang membuatnya lebih mudah untuk membuat barang tanpa mengetahui cara memprogram. Siapa pun yang benar-benar menggunakan lembar acara untuk waktu yang cukup lama tahu bahwa ini adalah cara nyata untuk memprogram yang memerlukan pemahaman konsep pemrograman dasar, dan Anda dapat membuat game yang lengkap dan kaya fitur dengannya.
Sebagian dari masalahnya adalah bahwa alat yang menggunakan lembar acara mencoba untuk mengecilkan sifat teknisnya dalam upaya untuk menarik para amatir dan orang-orang yang tidak memiliki banyak pengalaman dalam mengembangkan game. Ini pada dasarnya merusak citra lembar acara dan membuatnya tampak tidak mampu bagi orang lain yang memiliki lebih banyak pengalaman menggunakan alat lain. Anda juga kemudian memiliki banyak orang yang menggunakan lembar acara yang tidak yakin apa yang mereka lakukan karena mereka diberi tahu bahwa mereka tidak memerlukan pemahaman tentang pemrograman - jadi contoh yang dibuat orang dengannya tidak mewakilinya dengan baik. Itu tidak berarti tidak ada contoh yang bagus. Hanya saja ia telah mengembangkan prasangka tertentu.

..Hibrida mungkin menjadi cara untuk mematahkan prasangka itu - memungkinkan orang untuk menafsirkannya dengan cara baru yang mungkin memiliki nada yang lebih serius. Anda mungkin memiliki kesempatan untuk memecahkan masalah sistem sebelumnya, dan membuat hibrida tampak lebih baik daripada sistem yang terinspirasi darinya.

@prominentdetail memunculkan
Untuk menambahkannya saya hanya akan mengatakan ini:
Godot berpeluang menjadi game engine 3d pertama yang tepat untuk mendukung event sheets. Ini menurut definisi akan meningkatkannya di atas semua mesin lembar acara lainnya saat ini.
Seperti yang saya sebutkan sebelumnya, ini telah dicoba sebelumnya di fusi Clickteam dan di Construct - sebagai plugin, bahkan di pembuat game. Dan itu adalah kekacauan yang kikuk di sana karena editor mesin tersebut tidak memiliki kemampuan 3d.

Clickteam fusion - Mesin Firefly:
http://clickstore.clickteam.com/firefly
https://store.steampowered.com/app/267655/Firefly/
Ini digeser di Steam - karena ini adalah addon buggy yang mengerikan

konstruksi2 - q3d
https://www.scirra.com/tutorials/9456/building-your-first-3d-game-with-the-q3d-plugin

Lihat saja betapa repotnya menyiapkan adegan 3d sederhana tanpa editor adegan 3d
https://youtu.be/VUGsTdBpRCQ?t=6m17s

IMHO a hybrid terdengar seperti cara yang bagus untuk mendapatkan kerugian dari keduanya.

Pendekatan harus membuat prototipe lembar acara untuk menunjukkan nilainya dan mendapatkan umpan balik.

Setelah menguji sistem selama lebih dari satu jam, tampaknya cukup mampu. Dan bagian yang menarik adalah, mungkin pengetahuan pemrograman sama banyaknya dengan GDscript untuk membuat banyak hal, selain gerakan atau hal paling dasar yang fitur pembantunya telah ditambahkan.

Saya percaya bahwa orang yang terlalu takut untuk mencoba pemrograman mungkin adalah satu-satunya yang mungkin membutuhkannya dengan adanya GDScript.

Eventsheet dapat dengan mudah menjadi alat untuk belajar pemrograman, terutama dengan API Godot. Karena Godot sudah memiliki banyak fungsi pembantu yang sama. Jadi mengimplementasikan EventSheet mungkin sebenarnya bisa menggunakan GDScript.
Karena pada dasarnya Anda dapat membuat sistem yang mengubah EventSheet ke GDScript dan menyimpannya di folder tersembunyi yang terpisah, yang diperbarui pada waktu kompilasi dan dapat digunakan oleh mesin. Setidaknya itu yang saya pikirkan. Ini bisa menjadi solusi paling sederhana.

Meskipun saya dapat melihat bahwa itu tidak dapat menggantikan Visual Scripting/Cetak Biru karena benar, itu tidak terlalu visual sebagian besar kode ke kolom membuat hal itu lebih mudah dipahami.

Saya tidak mengerti mengapa ini dipublikasikan seperti itu, kecuali seseorang yang memiliki pengetahuan dasar tentang pemrograman menggunakan EventSheet mungkin terbukti lebih merepotkan.

Saat ini sambil menunggu sisi Visual Scripting diperbaiki, saya mungkin mencoba membuat sesuatu dengan ini jika saya punya waktu. Mungkin menyenangkan (akan membantu saya mempelajari Godot API), mencoba mengimplementasikan versi dasar dari EventSheet. Jika saya membuat kemajuan, pastikan untuk memperbarui di sini.

Bagaimana lembar acara berbeda dari bahasa gdscript/scripting?

Untuk pemula (hal-hal yang membuatnya lebih menarik daripada coding):

• Ada beberapa representasi visual dari logika - menggunakan ikon, warna, dan teks sesedikit mungkin
• Kondisi digambarkan di kolom kiri, tindakan di kanan - Dalam pengkodean kondisi dan tindakan berada di satu kolom- membuat beberapa orang sulit membedakan keduanya saat membaca logika orang lain.
• Alih-alih string teks yang panjang, metode ditampilkan sebagai kata-kata sederhana- dalam bahasa Inggris dan tanda-tanda sintaks dilucuti jika memungkinkan- menghilangkan kebisingan sintaks membuatnya lebih jelas untuk dibaca
• Intelisense/pelengkapan otomatis memberi pengguna seluruh API- sehingga mereka dapat melihat semua penyetel atau pengambil yang tersedia dan memfilter yang mereka inginkan - terbalik dengan cara kerjanya dalam pengkodean IDE- di mana pelengkapan otomatis ditampilkan setelah Anda mulai mengetik dan seluruh api masih tersembunyi di dokumentasi mesin. Ini juga memiliki petunjuk visual untuk menemukan sesuatu (ikon). Ini menunjukkan secara langsung jenis variabel yang dikembalikan atau diharapkan
• Logika pengelompokan memungkinkan Anda membuat folder sendiri yang dapat diciutkan/dibatalkan dan dipindahkan. Kemampuan untuk menciutkan blok logika yang Anda putuskan harus dapat dilipat sangat bagus untuk dimiliki ketika Anda mengatur kode Anda dan ingin menyembunyikan bagian yang tidak Anda kerjakan.

Untuk pengguna yang lebih berpengalaman:

• Anda memiliki kemampuan untuk mengubah urutan eksekusi acara dengan sangat mudah dengan menyeret dan menjatuhkan sel yang terisi. Apa artinya ini? Saat mengkodekan sebuah ide- kita dapat melakukannya dengan ctrl+x dan ctrl+v. Dalam sistem lembar acara, Anda dapat menyusun ulang hanya dengan menyeret dan melepas baris logika atau sel dari satu baris ke baris lainnya.
• Logika yang sudah mapan secara visual lebih jelas untuk ditemukan dan dibaca daripada kode- lagi-lagi karena petunjuk visual dan tata letak kolom kiri dan kanan - di atas kode warna. Ini sangat bagus ketika Anda membuat prototipe sesuatu
• Lembar acara dapat menangani jalur simpul untuk pengguna secara otomatis secara default- jadi ketika menyusun dan lembar acara Anda tidak perlu mengakses simpul lain (induk atau anak-anak) dengan mencari tahu jalur mereka relatif terhadap sesuatu. Anda masih memiliki opsi untuk fleksibilitas kode, tetapi sistem menangani ini untuk Anda jika node tidak akan mengubah hubungan induk-anak secara dinamis.
  Yang Anda lakukan untuk sampai ke sebuah simpul adalah Anda memilihnya dari menu pembantu. Ini mempercepat segalanya
• Ini masih sangat mirip gdscript - karena semua ekspresi ada di gdscript, tetapi ini memberi Anda beberapa fasilitas produktivitas ekstra. Saya pikir jika dilakukan dengan baik, ini adalah sesuatu yang akan disukai pengguna gdscript- berpengalaman atau tidak.

Saya kira jika saya harus meringkas fasilitasnya:
untuk pemula- kodenya jauh lebih jelas pada pandangan pertama, lebih mengundang karena bagaimana api mesin disajikan kepada mereka dan logika yang mereka letakkan memiliki petunjuk visual (ikon node)

untuk lebih berpengalaman- Anda masih dapat menulis gdscript di semua bidang ekspresi, tetapi sekarang Anda juga dapat membuat beberapa bagian proses menjadi lebih cepat (seperti tidak perlu menavigasi ke node lain dengan mengetik kode), kemampuan untuk menyeret logika untuk mengubah eksekusinya pesanan atau persyaratan (tidak perlu dipotong dan ditempel)

Saya agak teralihkan dengan beberapa hal javascript dan akan senang jika orang lain mencobanya :) Tetapi akan kembali ke sana

Saya setuju dengan @mhilbrunner bahwa itu harus menjadi sistemnya sendiri, tetapi akan lebih bagus jika mungkin untuk menggabungkannya dengan sistem cetak biru - cara Anda dapat menggabungkan gdscript dengan cetak biru dalam sebuah proyek

@blurmind
jadi, Anda bilang sedang mengerjakan plugin seperti itu?
apa nama reponya? sudah ada di github anda?

saya dapat memastikan bahwa peristiwa itu lebih mudah dipahami, saya mempelajarinya ketika saya berusia sekitar 10~11 tahun dan memiliki bahasa Inggris yang buruk (saya bukan penutur asli) sementara itu saya membutuhkan lebih banyak waktu dan pengetahuan bahasa Inggris untuk belajar bagaimana kode.

beberapa kali bisa lebih cepat daripada menulis kode, ketika Anda terbiasa Anda bisa mengklik secepat yang Anda bisa pikirkan.

satu-satunya kekurangan yang saya lihat adalah Anda menjadi malas ketika harus mempelajari kode tradisional.

saya mulai mengerjakan ini, tetapi kode Anda tampaknya lebih maju daripada milik saya, saya khawatir saya tidak dapat membantu, tetapi saya tetap ingin mencobanya

@Elmapul Saya tidak berpikir bahwa repo-nya akan banyak membantu.
Dan pengkodean jauh lebih cepat pada kenyataannya jika Anda memiliki pemikiran seperti itu, maka itu berarti Anda bukan programmer yang baik yang telah bekerja dengan bahasa seperti Python.
Meskipun EventSheet lebih membantu dan lunak untuk pemula, begitulah.

Hanya berpikir saya akan menyebutkan sesuatu- karena saya telah mencoba-coba berbagai alat selama bertahun-tahun..
Saya seorang seniman terkemuka, jadi saya menghabiskan sebagian besar waktu saya menciptakan seni. Ini adalah apa yang saya lakukan sebagian besar waktu saya dan apa yang pikiran saya telah diperkuat untuk mendukung. Ada banyak contoh di mana saya mengambil istirahat panjang dari coding, sementara saya melakukan hal-hal artistik lainnya, seperti freelance, dll.
Sebagai seorang seniman, ini membuat sulit untuk tetap tajam pada alat gamedev tertentu yang memerlukan pola sintaksis tertentu - pola yang harus Anda lakukan secara konsisten untuk mempertahankan pemahaman.
Jadi sebagai seniman- diharapkan seniman kemungkinan besar tidak memiliki konsistensi dan prioritas yang sama dengan gaya pengkodean berbasis sintaksis.
Lembar acara adalah cara untuk menyiasati punuk itu setiap kali Anda mengambil cuti dari pemrograman (karena sebagai seniman diharapkan Anda tidak akan menghabiskan waktu terus menerus hanya untuk coding).. Lembar acara lebih mudah untuk digunakan kembali karena itu membutuhkan lebih sedikit memori tentang struktur dan pola sintaks yang Anda kenal dalam pengkodean.
Karena itu, saya menyukai eventsheeting karena saya bisa lebih produktif daripada harus belajar kembali terus-menerus.. Saya baru saja melompat kembali setelah menggunakan pikiran saya pada tugas dan proyek yang lebih artistik - ini adalah aliran yang lebih mudah secara mental.

..Jadi pada dasarnya, apa yang ingin saya tekankan, adalah bahwa pengkodean ya lebih cepat jika Anda mendedikasikan seluruh waktu Anda untuk pekerjaan itu dan membangun kemampuan mental yang mendukung pemikiran itu. Mereka hanya cukup mengetiknya dan pergi - mereka tidak pernah benar-benar terhindar dari gaya hidup/perilaku ini. Bagi yang lain, ini tidak akan pernah menjadi pilihan yang realistis, karena mereka telah mendedikasikan hidup mereka melakukan pekerjaan lain yang telah memperkuat pola perilaku dan praktik yang berbeda.
Jadi ya.. Anda bisa saja seperti.. oh apa pun- menyebalkan menjadi Anda.. sayang sekali Anda tidak mendedikasikan waktu Anda untuk menjadi programmer penuh waktu, dll. yang akan mengasingkan banyak orang yang tidak akan pernah penuh- programmer waktu atau secara teknis berpikiran. Dan tentu itu adalah hak pengembang untuk melakukannya..
Tetapi jika Anda ingin mengundang jenis individu lain dan membuat lebih banyak orang benar-benar menggunakan alat ini, terlepas dari potensi teknis mereka, maka ada baiknya menjadi lebih terbuka terhadap berbagai hal dan mencoba membantu mereka yang tidak mampu mencocokkan sistem/alur kerja pilihan Anda. , dll..
Saya hanya terus merespons, karena saya merasa eventsheeting sangat membantu dalam membuat kemajuan dalam mengembangkan game, tanpa efek putus-putus yang terjadi setiap kali seseorang pergi dan kembali, dll. Tidak banyak yang mencegah orang seperti saya untuk menyerah , dan kembali ke pekerjaan normalnya. Jadi pada akhirnya, saya benar-benar mencapai lebih banyak, bahkan jika itu memakan waktu sedikit lebih lama atau sedikit kurang mengesankan pada tingkat teknis.

@prominentdetail Untuk semua maksud dan tujuan Visual Scripting dapat melakukan hal itu sehingga tidak perlu khawatir setelah implementasi lebih lengkap itu akan memecahkan sebagian besar masalah artistik mengingat sintaks.

Saya menggunakan Blueprints setelah meninggalkan coding untuk seluruh air mata dan masih terasa alami dan tepat dalam beberapa menit. Jadi saya pikir kebanyakan orang akan baik-baik saja dengan itu.

Apa pun bahasa yang Anda ketahui, skrip visual dengan opsi peristiwa dan tindakan yang dikelompokkan dengan benar akan lebih cepat daripada waktu yang diperlukan kecuali Anda mengetikkan nama variabel dan tipe data yang sangat singkat.

Yang mengatakan, jika peristiwa dipetakan ke pintasan keyboard, maka memang akan lebih cepat untuk "mengetik" lagi, tetapi tetap saja peristiwa/tindakan yang lebih cepat daripada kode standar dari awal (karena tindakan dan ketentuan sering kali mewakili fungsi yang sangat kompleks , pra-dibuat dan fleksibel untuk sebagian besar penggunaan).

Argumen saya tetap bahwa lembar acara lebih mudah dipelajari daripada
cetak biru dan lebih cepat untuk mengatur.

Selain itu lebih baik dalam transisi
orang baru ke bahasa scripting yang sebenarnya.

Jika dirancang dengan baik, sistem lembar acara bisa secepat menulis
gdscript. Jika Anda melihat gif mockup saya - ini sangat mirip dengan hanya mengetik
Kode dengan pelengkapan otomatis saat menggunakan pemfilteran menu pembantu.

Bagaimanapun, saya masih mencari cara untuk melakukan ini dan untungnya godot
gdscript akan mendapatkan skrip yang diketik, yang lebih cocok
untuk menghasilkan bbcode untuk lembar acara saya.
Misalnya salah satu basa-basi
bidang ekspresi dalam sistem lembar acara adalah bahwa ia memberi Anda a
indikasi yang jelas tentang jenis variabel yang diharapkan dan bahkan menyala
hijau saat valid (lihat clickteam fusion's).
Saat ini saya mencoba mencari cara untuk melakukan bidang ekspresi yang dapat
ambil gdscript tetapi juga gunakan menu pembantu yang saya buat. Sekali lagi ini hanya bereksperimen bagaimana itu bisa bekerja. Ini jauh dari sesuatu yang bisa digunakan atm..

Pada Rabu, 30 Mei 2018 22:59 Daven Bigelow, [email protected] menulis:

Tidak masalah bahasa apa yang Anda ketahui, skrip visual dengan benar
opsi acara dan tindakan yang dikelompokkan akan lebih cepat daripada waktu yang dibutuhkan
kecuali Anda mengetik nama variabel dan tipe data yang sangat pendek.

Yang mengatakan, jika acara dipetakan ke pintasan keyboard, maka itu akan
memang lebih cepat untuk "mengetik" lagi, tetapi tetap saja peristiwa/tindakan itu
lebih cepat dari kode standar dari awal (sebagai tindakan dan kondisi sering
mewakili seluruh fungsi yang kompleks, dibuat sebelumnya dan fleksibel untuk sebagian besar penggunaan).

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

@blurymind Saya merekomendasikan melakukannya dengan C++, keduanya akan lebih cocok dan lebih lengkap menggunakan metode itu. Bahkan saya yang memulai C++ beberapa minggu yang lalu sekarang dapat menggunakannya, membuat perbaikan bug dan fitur baru. Jadi tidak terlalu sulit, mungkin sedikit. Saya masih perlu menggunakan stackoverflow sekalipun.

Tetapi jika Anda ingin tetap tinggal dan menggunakan GDScript dan hanya membuat prototipe untuk diubah menjadi alat lengkap, saya pikir Anda harus membagikan repositori di sini tidak peduli seberapa lengkapnya.
Saya akan dengan senang hati membantu. Saya sangat menyukai ide EventSystem. Dan VisualScripting saat ini rusak jadi tidak banyak yang bisa saya lakukan.

Masalahnya adalah sistem acara dapat merepotkan untuk diterapkan, di Godot Anda kemungkinan besar mengimplementasikannya sebagai Bahasa Scripting. Tapi bukan itu maksudnya, itu pengelola acara jadi itu harus global atau harus bisa menangani seluruh adegan sendirian, dan kemudian menggunakan grup untuk memisahkan pekerjaan menjadi beberapa bagian.
Semua ini mungkin, dan seharusnya tidak menjadi masalah untuk diterapkan juga.

@swarnimarun apakah ada modul hello world yang membuat ui baru atau mengubah yang sudah ada?
Bisakah Anda merekomendasikan tutorial memulai yang bagus yang membantu Anda?

Bagaimanapun saya sekarang berpikir untuk mengubah sintaks gdscript yang akan dihasilkan oleh menu pembantu menjadi gdscript yang diketik:
https://github.com/godotengine/godot/pull/19264
Kemudian itu akan dikonversi ke bbcode yang membuat antarmuka sel lembar acara interaktif

Saya membuat diagram alur ini untuk menjelaskan cara kerjanya saat ini
https://www.draw.io/#Hblurymind %2FGodot-eventSheetPrototype%2Fmaster%2FEventSheetDiagramPlan.xml

@blurymind Saya sarankan untuk tidak memotret untuk tutorial tetapi belajar dari praktik aktual atau pengembang lain.
Tidak ada yang benar-benar membantu saya. Saya juga tidak membutuhkan banyak bantuan. Saya agak pandai mengambil barang, jadi semuanya bekerja dengan baik. Masih saya baru memulai, itu dibandingkan dengan pengembang berpengalaman.

Dan saya percaya bahwa Anda menggunakan GDScript untuk melakukan semua pemrograman, atau Anda menggunakan C++.
Karena tidak ada modul yang memungkinkan Anda melakukan apa pun secara default atau saat memulai. Anda harus belajar dari apa yang sudah ada. Dan buat sendiri.

Mengonversi ke GDScript yang Diketik seharusnya sederhana jika Anda menggunakan GDScript dan jika Anda menggunakan C++ sedikit porting akan diperlukan. Dan sejauh yang saya tahu, PR harus digabung kapan saja sekarang. Sudah ditinjau dan tampaknya baik-baik saja. Belum dicoba tapi seru banget.

Dan biarkan saya menebak saat ini, Anda menggunakan GDScript dengan get_method_list() dan get_property_list() kemungkinan. Tapi saya akan merekomendasikan Anda untuk menggunakan sinyal dan grup juga, sinyal adalah mekanisme penembakan acara Godot. Saya tidak begitu tahu tentang EventSystem tetapi jika Anda ingin membuat sesuatu seperti itu di Godot. Pastikan Anda menggunakan Godot secara maksimal.

Dan terakhir jika Anda ingin bantuan, cukup pesan saya di Twitter atau Discord. Saya akan bebas selama beberapa hari sekarang.

@swarnimarun Saya menggunakan gdscript untuk menulis addon, sudah ada beberapa penggunaan sinyal di dalamnya untuk hal-hal seperti memicu peristiwa.
Ya, saya menggunakan get_method_list() dan get_property_list() untuk merender menu pembantu juga

Apakah Anda memiliki pegangan yang sama di twitter dan discord?

Untuk saat ini rencana saya adalah membuat prototipe gui di gdscript karena itu yang saya ketahui lebih dari c++.
Saya juga memiliki beberapa pengalaman dalam javascript, tetapi itu tidak akan banyak membantu di sini

Gdscript yang diketik adalah apa yang akan dihasilkan oleh menu pembantu untuk mode ekspresi - hanya lebih baik untuk mengonversi ke bbcode untuk merender ui dengan label teks kaya

@blurymind Itu sangat bagus kalau begitu. Saya tidak melihatnya di gif di atas. Jadi saya berasumsi beberapa hal.

Adapun pegangan saya yang ada di Discord adalah Swarnim. Dan saya pikir Anda sudah tahu twitter saya.

@blurymind - Kerja bagus. Saya benar-benar baru mulai belajar C++ karena peningkatan kinerja di Godot jika dibandingkan dengan GDScript (3 hingga 4 kali lebih cepat, tergantung pada metrik Anda - lihat bunnymark ). Jika memungkinkan, saya akan merekomendasikan langsung untuk emas dan menggunakan C++ untuk ini, bahkan jika itu berarti belajar sambil bekerja - itu akan sia-sia. Beri saya beberapa minggu untuk merasakan C++ dan saya juga siap membantu jika Anda mau.

@colludium Kecepatan 3 hingga 4 kali lebih cepat tidak sebanding dengan upaya mempelajari C++. Jika Anda ingin belajar membuat game yang lebih optimal, pelajari C# sebagai gantinya (akan menjadi lebih cepat saat matang di Godot). Dan juga sekarang GDScript yang diketik akan membuat GDScript lebih cepat dari sebelumnya. Dekat dengan C # adalah percaya.

C++ adalah rasa sakit. Percaya padaku. Pointer dan Ref dan kode kompilasi hanyalah rasa sakit. Kecuali jika Anda ingin membuat masa depan sebagai pengembang game untuk perusahaan besar atau sedang kuliah mempelajarinya atau Anda sangat pintar sehingga Anda mengetahui GDScript sepenuhnya atau berada di level pro sebagai programmer.

Jika Anda masih ingin terus mencoba belajar membuat kode GDScript secara dinamis saat Anda melakukannya karena seperti yang kita ketahui membuat sistem ekspor untuk suatu bahasa itu sulit sehingga menghasilkan kode GDScript secara langsung akan membuat semuanya lebih mudah dilakukan.
Dan sebagai bonus tambahan Anda akan dapat melakukan tampilan untuk melihat kode dan membantu pemula belajar coding lebih cepat.

@blurymind Ingin bertanya versi EventSystem mana yang Anda gunakan sebagai basis karena saya ingin membuat prototipe sistem sebagai modul C++ jadi saya ingin menyinkronkannya dengan milik Anda setidaknya di tingkat dasar.

@swarnimarun - terima kasih atas sarannya: C++. Saya hanya seorang programmer hobi yang datang dari JavaScript, jadi transisi dengan rasa sakit minimum/kinerja maksimum adalah yang saya cari. Saya tidak mengetahui perbaikan yang direncanakan untuk membuat GDScript lebih cepat - bagus untuk diketahui. Sekarang saya memiliki kebingungan - C# atau yang lebih mudah untuk mempelajari GDScript...

@colludium Katakanlah apa pun yang Anda temukan lebih mudah, melihat latar belakang Anda menjadi Javascript, saya sarankan GDScript karena itu juga memiliki pengetikan dinamis, dan dengan pengetikan statis yang masuk itu harus menjadi pendamping yang sempurna.
Dan izinkan saya memberi tahu Anda jika Anda pernah berpikir bahwa C++ adalah bahasa yang harus Anda pelajari, pergi dan periksa halaman Rust vs C++ dari beberapa forum.

@swarnimarun saya menggunakan godot 3.0.2
Ini adalah repo pengujian yang saya tambahkan proyeknya
https://github.com/blurymind/Godot-eventSheetPrototype
Setiap orang bebas melakukan fork atau pull request 👍

Silakan mulai menulis modul c++. Apa yang saya fungsikan sejauh ini hanyalah blok bangunan inti dari antarmuka - wadah sel logika.

Pengurai bbcode (hanya menggunakan ekspresi reguler) dan rendering menu pembantu adalah hal-hal yang mungkin paling berguna bagi Anda, meskipun saya pribadi berpikir untuk mengubah cara kerjanya - mereka dihancurkan bersama di waktu luang saya antara pekerjaan dan proyek lainnya . Masalahnya adalah kode atm yang berantakan, jadi memiliki programmer yang lebih berpengalaman akan sangat membantu saya.

Sisanya hanya antarmuka statis yang dipasang untuk keperluan tangkapan layar

Satu hal yang sangat penting untuk dilakukan adalah membuat semacam kamus yang dapat diedit yang melacak semua node dalam adegan dan jalurnya, jadi alih-alih jalur node statis- menu pembantu harus menghasilkan gdscript yang menggunakan jalur dari kamus yang secara otomatis memperbaruinya dan jika sebuah node dihapus oleh pengguna dan tidak ditemukan oleh logika lembar acara - itu dapat ditautkan kembali

Bagaimanapun, tolong bagikan jika Anda memiliki sesuatu - bahkan jika itu dasar. Saya akan mencoba belajar lebih banyak C++ dan bergabung dengan Anda dalam menulisnya sebagai modul :)

@blurymind Akhirnya! seseorang yang sangat mengerti bahwa visual scripting Godot Engine 3.x tidak berguna (terlalu rumit untuk pemula, tidak berguna untuk ahli).

Sistem acara GDevelop luar biasa! itu sangat berguna terutama untuk membuat template game 2D lengkap, dan kemudian menambahkan lebih banyak fitur canggih melalui GDScript. Ini akan membuat Godot Game Engine jauh lebih menarik, populer, dan tersebar luas!

Saya sangat menyukai Godot Engine tetapi membuat game 2D untuk perangkat seluler bukanlah solusi termudah dan paling cepat. Itu bisa menawarkan lebih banyak dengan sistem / sistem acara yang disederhanakan). Godot memiliki editor animasi yang sangat baik, sangat bagus dan fungsional, hanya membutuhkan sistem yang lebih ramah pengguna jika saya ingin membuat platformer 2D tanpa harus menulis ribuan baris kode (yang menurut saya tidak berguna untuk membuat super- dasar) template gaya mario bros untuk NES).

Saya menemukan bahwa ide @blurymind fantastis! komunitas Godot telah berkembang pesat dan saya senang dengan itu. Saya tidak ragu bahwa sistem acara diimplementasikan dengan rilis berikutnya. Visual Scripting (saya ulangi) sama sekali tidak berguna saat ini (saya bahkan tidak dapat menemukan tutorial, dan tidak ada yang menggunakannya dari apa yang saya lihat di web).

Salam, dan terima kasih atas pekerjaan Anda yang luar biasa!

@XenonCoder Anda membuat poin yang menarik di akhir

Visual Scripting (saya ulangi) sama sekali tidak berguna saat ini (saya bahkan tidak dapat menemukan tutorial, dan tidak ada yang menggunakannya dari apa yang saya lihat di web).

Ini adalah contoh yang baik di mana sesuatu sulit untuk digunakan oleh alam, kemudian akan digunakan sebagai self-fulfilling prophecy untuk menjelaskan mengapa hal itu tidak boleh dilakukan (misalnya: "LIHAT! Tidak ada yang mau visual scripting!"), daripada mengakui bahwa itu tidak dilakukan dengan cara yang menarik atau ramah bagi pemula.

Ini seperti hadiah setengah, karena tanpa tindak lanjut, memang tidak ada gunanya.

Hal yang sama berlaku untuk setiap penambahan mesin yang tidak didokumentasikan dengan baik atau diberikan contoh.

@bigelod Sangat setuju dengan Anda. Saya senang Anda tidak salah memahami maksud saya, dan Anda memahami dengan sempurna apa yang saya maksud.

Godot Game Engine benar-benar fantastis! Ini memiliki potensi yang luar biasa. Untuk membuat game 2D, itu nomor 1! Selama bertahun-tahun saya telah bereksperimen dengan semua Game Engine dan kerangka kerja yang ada dan saya dapat mengatakan dengan pasti bahwa Godot adalah proyek yang menjanjikan hal-hal besar.

Misalnya, Visual Shader baru terlihat sangat bagus dan menjanjikan hal-hal hebat untuk masa depan. Saya melakukan beberapa tes dan saya sangat menyukainya sebagai sebuah ide. Namun untuk mewujudkan logika sebuah videogame, Visual Scripting adalah jebakan.

Kami membutuhkan tutorial, dokumentasi secara umum, dan terutama sistem yang disederhanakan dalam gaya Build 3, GDevelop, Game Maker Studio 2. Awalnya sebagai tambahan untuk mencapai game 2D, di masa depan ditingkatkan dan diimplementasikan secara resmi. Saya menyadari bahwa ini bukanlah tugas yang mudah, ini hanya sebuah ide untuk membuat Godot Game Engine sebagai solusi ideal bagi para antusias, pelajar, dan profesional videogame.

Terima kasih semua.

Di sekitar mesin permainan membentuk toko. Itu menjadi normal - untuk menulis add-on secara komersial. Untuk Konstruksi termasuk. Semua plug-in C2 signifikan terakhir bersifat komersial. Ini tidak hanya disebabkan oleh pembentukan pasar, tetapi juga karena kerumitan produk, pengeluaran waktu yang besar untuk menguji dan memperbaiki kesalahan kompatibilitas.
Saya pikir... Godot ada di ceruk lain, dan jika Juan tidak menulis dan mendukung aplikasi pemrograman yang disederhanakan, kecil kemungkinan orang lain akan menyelesaikan pekerjaan ini.

Saya tumbuh dengan Klik 'n Play, The Games Factory dan Multimedia Fusion, dan menggunakan Construct 2 hari ini. Skrip visual dengan lembar acara benar-benar berbeda dengan menggunakan node mesin negara bergaya cetak biru yang terhubung satu sama lain, dan bagi orang yang terbiasa dengan lembar acara, ini adalah cara pemrograman yang paling mudah dan efisien. Saya akan dengan senang hati menyambut cara membuat skrip di GoDot dengan lembar acara.

Saya telah mencapai beberapa batasan dalam gdscript, dokumentasi dan plugin api yang mencegah saya untuk sepenuhnya menjalankan visi saya tentang ini sebagai addon. Bahkan jika saya membuatnya ke status fungsional - itu mungkin akan memiliki keterbatasan.

Satu hal yang akan sangat membantu saya sampai di sana adalah gdscript yang diketik opsional - itulah sebabnya saya berhenti mengerjakan ini sampai ada di godot. Sekarang sudah digabung - saya akan kembali mengerjakan ini sebagai bukti addon konsep kapan pun ada waktu.

Idenya adalah bahwa gdscript yang dihasilkan dari lembar acara akan diketik. Data yang diketik kemudian akan memberikan data kontekstual tambahan kepada lembar kejadian gui mengenai jenis parameter yang diharapkan.

Jika ada minat dalam hal ini sebagai modul c++ yang tepat atau addon gdnative - semua orang bebas untuk mencoba mengimplementasikan ini.

Melihat berapa banyak orang yang menginginkannya, tidak ada yang membuat saya lebih bahagia daripada mendapatkan ini menjadi bagian dari godot - atau setidaknya bekerja sebagai bagian dari godot.

Sayangnya saya memiliki pekerjaan penuh waktu yang menghabiskan sebagian besar waktu saya saat ini :(
Maaf untuk pembaruan yang lambat

Untuk menambah diskusi ini, saya ingin menyajikan kepada semua orang di sini contoh fantastis dari mesin skrip visual menggunakan pendekatan pemrograman visual berbasis koneksi simpul yang saat ini gagal menargetkan demografisnya.
https://youtu.be/b8GZ21YCh50?t=4m12s
Ini agak mirip dengan https://www.reddit.com/r/unrealengine/comments/4nt0up/need_help_debugging_this_blueprint/

Perhatikan alternatif hadiah Gamesfromscratch

Satu hal yang ingin saya hindari di sini dalam proposisi desain ini adalah mendefinisikan perilaku yang berada di luar apa yang sudah dilakukan node di godot - juga membuat banyak tab dan gui .
Lembar acara godot harus berfungsi persis seperti kode gdscript- hanya dengan cara yang lebih taktil/visual
Seharusnya tidak mencoba membangun mesin permainan yang mudah digunakan di atas godot, melainkan membuat apa yang dimiliki godot lebih mudah diakses dan lebih cepat untuk disatukan

mungkin dengan skrip visual itu bisa diakses bahkan di layar sentuh?

Memang, skrip visual gaya lembar acara sangat cocok untuk sentuhan
layar

Pada Rabu, 1 Agustus 2018 06:46 Elmapul, [email protected] menulis:

mungkin dengan skrip visual itu bisa diakses bahkan di layar sentuh?

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

@blurymind jika sistem plugin membutuhkan perbaikan untuk ini, buka masalah, itu sudah dimodifikasi karena plugin lain membutuhkan sesuatu yang khusus.

Ini adalah ide bagus! Saya tidak pernah benar-benar memahami cetak biru ini, tetapi pendekatan berbasis acara terkenal, terutama di komunitas modding, seperti Warcraft III World Editor.

Contoh layar:


Kategori dan daftar pemicu yang bersih tampak hebat, setidaknya bagi saya. Lebih mudah untuk melihatnya daripada layar dari posting pertama.

Ini sebagian besar sama seperti yang Anda katakan, tetapi dengan kemungkinan untuk menambahkan kondisi sebagai tindakan dan membuat sarang tindakan lebih lanjut di dalamnya.

@Wiadomy
gambar ini terlalu kecil untuk dilihat/dibaca

@Elmapul
Maaf, ada yang salah dengan itu. Diperbarui.

@Elmapul sementara addon konsep saya belum dapat melakukan bersarang, lembar acara yang saya usulkan termasuk bersarang. Baik gdevelop maupun build support row nesting - Anda dapat mencobanya sekarang jika mau :)

@blurymind akhirnya mulai mengerjakan implementasi Lembar Acara, apakah Anda tahu sumber daya apa pun yang membahas implementasinya secara detail seperti makalah penelitian atau artikel tentang cara kerja dan implementasinya?
Itu akan sangat membantu. Untuk membantu saya memulai merancang Sistem Lembar Acara untuk Godot.
Karena itu tidak akan akurat untuk menggunakan metode Construct atau GDevelop karena cara kerja Godot sangat berbeda dan kami memiliki hal-hal yang disebut sinyal yang juga perlu diintegrasikan dan kemudian beberapa lagi.

ada beberapa info tentang terpal acara konstruk di sini jika Anda memerlukan informasi umum: https://www.scirra.com/manual/74/events
perusahaan yang berbeda menerapkan lembar acara mereka sedikit berbeda satu sama lain, sehingga mereka masing-masing memiliki kebiasaan sendiri..
Mungkin saya bisa membuat video yang merangkum berbagai bagian dari metode konstruksi (karena itu mungkin cara terbaik saat ini) .. Saya tidak tahu makalah penelitian apa pun - meskipun itu akan menarik untuk ditemukan.

@prominentdetail Terima kasih atas tautannya, sepertinya saya harus melihat bagaimana membuat acara lebih mudah digunakan seperti sistem konstruksi.
Ide pertama saya adalah memiliki sesuatu yang mirip dengan addon dari @blurymind tetapi sekarang lebih mungkin kita harus memiliki API yang berbeda untuk Lembar Acara yang membuatnya lebih mudah untuk dikodekan dan bukan versi GDScript dalam bentuk visual.

Jadi bagaimana menurut kalian Sistem Acara harus memiliki API yang berbeda untuk menambah kemudahan penggunaan atau hanya menjadi pembungkus GDScript.

@swarnimarun benar-benar hal terbaik yang harus dilakukan adalah menggunakan mesin untuk sementara waktu dan memikirkan bagaimana ini dapat dilakukan dengan cara yang lebih baik. Membangun klasik dan gdevelop adalah contoh yang bagus imo.

Dari sudut pandang saya, sinyal di godot sama seperti acara fungsi bawaan. Menghubungkan sinyal sudah visual di godot :)

Mengatur sinyal dari lembar acara hanyalah tindakan yang tersedia di menu pembantu - di bawah tenda itu hanyalah metode penyetel. Jadi itu akan sama dengan gdscript.

Jika sebuah node berisi metode bawaan, itu harus tersedia di menu yang Anda dapatkan saat mengklik 'Tambahkan fungsi bawaan'

Saya sangat berpikir kita harus membuatnya tetap sederhana dan menjadi pembungkus untuk gdscript yang diketik , tetapi jika itu tidak mungkin atau praktis - bisa menjadi API yang berbeda. Perlu diselidiki bagaimana skrip visual saat ini yang diimplementasikan di godot berfungsi sebagai abstraksi.

Jika Anda bertanya-tanya bagaimana fungsi kustom dibuat dalam konstruksi, berikut ini tautan ke dokumennya
https://www.scirra.com/tutorials/823/creating-function
:)

@blurymind Sebenarnya jauh lebih mudah dan lebih sedikit pekerjaan untuk menyimpannya sebagai pembungkus untuk GDScript tetapi masalahnya adalah banyak fitur dari Lembar Acara akan menjadi lebih membosankan seperti itu setidaknya itulah yang saya pahami.
Jadi saya pikir saya akan tetap sama untuk permulaan dan kemudian menambahkan hal-hal jika perlu.

@swarnimarun terima kasih telah meluangkan waktu untuk mencoba ini

Saya pikir masalah terbesar adalah VisualScript, karena semua bahasa lain yang dapat Anda gunakan untuk skrip Godot, mencoba sedekat mungkin dengan fungsionalitas GDscript, dengan fungsi, variabel, sinyal, dan yang lainnya. Anda tidak dapat mencapai ini dengan sistem lembar acara, karena Anda akan kehilangan banyak fungsi. (Saya tahu itu mungkin, tetapi itu akan cepat membengkak)

@Jummit kecuali Anda benar-benar bisa, coba Construct 2. Itu tidak lebih membengkak daripada kode standar.

Dan itu bisa memiliki semua fungsi GDscript? Lalu apa yang kita tunggu? Ayo dapatkan lembar acara di Godot!

@Jummit godot memiliki semua fungsi yang Anda inginkan dalam bentuk 'Node'

'Node' di godot seperti 'Perilaku' di konstruk2
Perilaku platformer di construct2 seperti simpul kintematicbody2d yang kurang kuat :)
Anda tidak harus membuat skrip semuanya dari awal.

Yang lebih keren lagi adalah Anda dapat membuat sarang node ini dalam hubungan induk anak, sementara perilaku dibatasi untuk dilampirkan seperti modul ke satu objek game.

Saya sangat percaya bahwa godot dengan kemampuan lembar acara bawaan dan beberapa plugin tambahan dari komunitas dapat menjadi mesin yang lebih cepat untuk pembuatan prototipe daripada konstruk2 atau 3.
Memiliki banyak potensi yang belum tergarap.

Kecepatan pembuatan prototipe dalam C2 sangat ditentukan oleh interaktivitas sel - mereka dapat diseret, disalin, dan diubah dengan hotkey, termasuk objek kondisi, sementara daftar drop-down hampir sepenuhnya menghilangkan kesalahan.

@swarnimarun , saya membuat ikhtisar umum tentang berbagai hal konstruksi: https://www.youtube.com/watch?v=ioz3gHtA-Lg
Ini pada dasarnya untuk siapa saja yang tidak terlalu akrab dengan konstruksi untuk merasakannya. Saya mungkin mengabaikan berbagai hal karena saya tidak merencanakan semuanya, tetapi mungkin memberikan beberapa pemahaman dasar. Saya mungkin harus membuat beberapa video di mana saya benar-benar melakukan lebih banyak pengembangan di dalamnya, untuk memamerkan sisi alur kerja daripada mengoceh tentang berbagai hal. Beri tahu saya jika Anda ingin sesuatu yang dibahas atau dieksplorasi.

Itu jelek sekali bagi saya. Maksud saya, skrip dalam video.

@Wiadomy itu jauh lebih baik digunakan daripada di video itu. Lembar acara pada akhirnya selalu terlihat lebih bersih dan lebih mudah dibaca daripada sistem berbasis simpul mana pun

@Wiadomy , karena perekaman layar, saya harus menggunakan satu monitor dan juga menjaga ukuran teks relatif besar. Bangun memformat teks sehingga beberapa hal dapat menjadi bertumpuk karena ruang layar jika Anda mengetik ekspresi berkelanjutan yang panjang.
Untuk mengatasinya, Anda dapat memperkecil teks dan juga menggunakan monitor lain untuk mengosongkan beberapa ruang untuk membuat daftar acara dengan lebih baik.
Saya juga dapat membagi ekspresi sedikit untuk membuatnya lebih rapi juga, tetapi ini adalah proyek saya yang lebih tua dan juga sedikit lebih eksperimental.
Selain itu, Anda akan terbiasa dengan isyarat dan pola visual dalam struktur lembar peristiwa, sehingga menjadi lebih mudah untuk melacak semua bagian yang berbeda dalam peristiwa tersebut. Memiliki struktur standar seperti ini sangat berguna dalam hal dapat beradaptasi dengan proyek apapun dan membuat alur kerja menjadi sangat cepat.

Apakah proyek ini mati sekarang?

@ Amr512 Saya tidak berpikir itu sudah mati. Pasti ada banyak keinginan untuk membawa fungsi ini ke godot.
@reduz bahkan tertarik pada gdevelop baru-baru ini di twitter
https://twitter.com/reduzio/status/1085206844275081218

Sementara saya tidak mengerjakan addon untuk sementara waktu, saya memutuskan untuk benar-benar pergi dan mulai berkontribusi untuk gdevelop itu sendiri- untuk mempelajari lebih lanjut tentang bagaimana lembar acara itu diprogram- serta membantu menjadikannya alternatif yang lebih baik daripada yang berbayar pilihan.
https://github.com/4ian/GDevelop/

Beberapa universitas telah mulai mengambil gdevelop untuk mengajar kursus pemrograman
https://github.com/4ian/GDevelop/issues/882

Addon buggy godot saya saat ini hanya untuk tujuan presentasi dan membutuhkan banyak pekerjaan sebelum dapat berfungsi. Siapa pun bebas untuk memotongnya dan mencoba mendorongnya lebih jauh tentu saja.
Satu hal besar yang saat ini hilang dari addon saya adalah elemen gui pohon yang dapat diurutkan untuk baris acara. Juga tidak ada fungsi untuk benar-benar merender lembar acara ke gdscript, juga tidak ada editor teks ekspresi yang tepat dengan pelengkapan otomatis dan pewarnaan sintaks (idenya adalah menggunakan gdscript standar untuk sintaks). Itu kehilangan banyak elemen kunci yang akan membuat lembar acara, tetapi tujuan utamanya adalah untuk menyajikan bagaimana lembar acara dapat digunakan dalam kombinasi dengan gdscript untuk sintaks ekspresi. Saya pikir keduanya akan menjadi kombinasi yang sangat kuat untuk membuat prototipe game - bahkan untuk pengembang berpengalaman

@blurymind Saya meninggalkan tiket di proyek Anda (kesalahan pada Godot 3.1beta3).
Saya sangat menyukai ide itu.

Tersandung pada masalah ini secara tidak sengaja, saya sama sekali tidak menyadari bahwa hal ini sudah umum digunakan di mesin/kerangka lain jadi saya harus menulis sendiri, terlihat sangat mirip bukan? 👀.

Aturan = Kejadian
Lembar Acara = Skema

Implementasi sebelumnya memang menggunakan pemeriksaan properti "tingkat rendah" yang cukup dan tindakan masing-masing, tetapi saya pikir sistem semacam ini sebenarnya lebih berguna untuk mendefinisikan "blok bangunan" gameplay dengan memperluas skrip dasar kondisi/tindakan yang lebih "tinggi- tingkat" dalam abstraksi. Jadi itulah sebenarnya alasan mengapa saya memilih terminologi "Aturan" sejak awal.

Anda harus memiliki gameplay dan kerangka kerja game yang sudah ditetapkan untuk memanfaatkan ini sepenuhnya, sehingga tidak memberikan pengalaman out-of-the-box untuk menulis game tanpa coding, tetapi benar-benar melengkapinya dengan cara yang memungkinkan Anda untuk menggabungkan fungsionalitas yang ada dalam berbagai cara dan mengaturnya secara efisien, cukup buat aturan baru dengan kondisi dan tindakan yang berbeda menggunakan GDScript biasa Anda.

Dan ya, mengizinkan pemain untuk membuat mode/misi/tantangan permainan mereka sendiri melalui modding adalah alasan lain untuk menggunakan sistem seperti itu.

@Xrayez dapatkah Anda membagikan git repo? Saya pikir Anda benar bahwa implementasi saya terlalu granular, tetapi memang benar cara kerja gdscript dan godot's api.
Juga hanya dengan melihat tangkapan layar, saya pikir Anda kehilangan intinya - seharusnya hanya dua kolom, bukan tiga. Kiri= kondisi, kanan= tindakan. Anda juga harus dapat menarik dan melepas acara di antara sel, dan juga menyeret dan melepaskan baris dan menumpuknya. Untuk membangun ini kita perlu menggunakan pohon yang dapat diurutkan. Bermainlah dengan gdevelop dan buat, Anda akan mendapatkan ide yang lebih baik tentang apa yang membuat lembar acara ini begitu bagus

Mungkin implementasi saya dapat dianggap sebagai sesuatu yang mirip dengan DSL sehingga di situlah perbedaannya. Banyak aturan hanyalah implementasi kotak pasir dari fungsi yang disesuaikan untuk persyaratan bermain game tertentu. Pada dasarnya kondisi dan tindakan hanya mewarisi skrip kecil ini dengan metode yang harus diterapkan di kelas anak:

class_name SchemeCondition extends Node

func is_met(object): # override
    return true

class_name SchemeAction extends Node

func perform(object): # override
    pass

Aturan hanyalah kumpulan dari kondisi dan tindakan itu dan dijalankan berdasarkan apakah semua atau kondisi apa pun terpenuhi, tidak ada yang terlalu mewah sebenarnya.

Saya mengerti bahwa orang-orang yang berkontribusi dan mengimplementasikan hal-hal suka membuat kode dan tidak semua melihat daya tarik pemrograman tanpa kode, tetapi banyak orang lain sebenarnya tertarik dengannya.

Bangun, Gdevelop, Stencyl, Game Maker, Playmaker, Bolt, Fungus for Unity, Blueprints in Unreal, Flow Graph and Schematyc in CryEngine, dll...

Banyak alat untuk non-coder sedang dibuat dan digunakan. Banyak game bagus dibuat berkat ini.
Hollow Knight dilakukan dengan playmaker misalnya.

Anda bahkan memiliki hal-hal seperti Dreams yang membuat beberapa kebisingan.

Alat semacam ini akan membawa banyak daya tarik dan aksesibilitas, dan oleh karena itu orang baru di Godot.

Saya baru-baru ini menerapkan cara di gdevelop untuk menambahkan instruksi baru ke lembar acaranya melalui dropdown seperti ini

Ini adalah jenis apa yang saya pikir bisa bekerja dengan baik untuk godot.

Anda menggunakan richtextlabel untuk merender setiap sel, sel-sel ini bersarang di kolom kiri dan kanan, yang kemudian merupakan anak dari baris. Baris dikelola oleh pohon yang dapat diurutkan. Setiap baris berisi gdscript aktual yang diterjemahkan oleh juru bahasa menjadi deskripsi singkat sederhana dengan gambar mini dan area yang dapat diklik untuk memasukkan ekspresi.
Inilah yang sebenarnya dilakukan oleh pembuat game. Data pemrograman visual mereka disimpan sebagai gml yang sebenarnya.

Bagian rumit yang saya temukan ketika saya mulai melakukannya sebagai ekstensi gdscript adalah melakukan bidang ekspresi. Bagaimana cara kita menempatkan editor kode di bidang input dan membiarkannya melakukan pelengkapan otomatis untuk kita? Bagaimana kita memberikan konteks penyelesaian dan validasi? Tanpa bidang ekspresi pelengkapan otomatis yang divalidasi, ini sudah mati.

Kami memiliki semua bagian UI untuk membangun ini di godot, tetapi kami benar-benar tidak memiliki satu pun pengembang berpengalaman yang melakukan apa pun di dalamnya. Saya belum melihat ada pekerjaan yang dilakukan sejauh ini

Bagaimanapun, jika pengetahuan c++ saya lebih baik, saya akan mencobanya :) Tapi saya tahu javascript, jadi kontribusi saya pergi ke gdevelop sebagai gantinya

Akan senang melihat solusi berbasis acara di godot. Saya mencoba godot di masa lalu, tetapi saya tidak bisa merasa nyaman dengan alur kerjanya. Pikiran saya lebih cocok untuk lembar acara jika saya akan mengembangkan game.

Saya seorang programmer sekarang, dan saya bahkan mulai masuk ke pengembangan mesin. Tapi saya masih bisa dengan percaya diri menjamin lembar acara.

Construct 2 sebenarnya adalah paparan pertama saya terhadap banyak konsep pemrograman dasar, melalui kelas yang saya ambil di sekolah menengah. Saya merasa itu menyederhanakan dan mempercepat proses pembelajaran secara besar-besaran untuk saya--baik mesin secara khusus maupun pemrograman secara umum--sementara juga menerjemahkan cukup dekat ke kode aktual sehingga saya tidak merasa benar-benar tersesat dalam transisi dari lembar acara untuk skrip teks lama biasa. Meskipun saya tidak bisa 100% yakin akan hal ini, saya benar-benar tidak berpikir saya bisa mendapatkan salah satu dari manfaat itu pada tingkat yang sama, apakah itu jenis skrip visual spageti.

Tetapi saya setuju bahwa mempertahankan dua sistem skrip visual yang berbeda mungkin merupakan ide yang buruk. Yang mengatakan, saya tidak berpikir kita harus tetap dengan sistem saat ini hanya karena apa yang sudah kita dapatkan. Saya pikir kita harus benar-benar mempertimbangkan untuk beralih ke sistem lain, jika data menjaminnya. Artinya, saya pikir kita harus mencoba dan mendapatkan ide yang lebih baik tentang seberapa jauh lebih mudah didekati sistem lembar acara vs sistem kita saat ini. Tujuan dari skrip visual seharusnya membuat mesin lebih ramah kepada orang yang tidak terbiasa atau tidak percaya diri dengan skrip biasa. Sistem skrip visual yang solid dapat membuat perbedaan besar dalam seberapa mudah didekati Godot, dan dapat berarti mendapatkan dukungan dan adopsi lebih banyak orang, yang jika tidak, tidak akan mempertimbangkan Godot.

Sebenarnya, alasan utama saya beralih dari Construct 2 hanyalah karena saya sudah ingin masuk ke 3D. Saya akhirnya mencoba Unity, Unreal, Godot, dan Amazon Lumberyard, dan akhirnya menggunakan Godot cukup banyak hanya karena terasa lebih cepat untuk dibuka dan digunakan dan proses impor terasa lebih baik. Tetapi jika Godot memiliki sistem gaya lembar acara, saya mungkin akan langsung menggunakan Godot. Memang, itu benar-benar tidak membuat perbedaan bagi saya sekarang secara pribadi, tetapi sekali lagi, ini tentang membuat Godot seramah mungkin kepada non-programmer (yaitu sebagian besar pengembang game baru / calon) mungkin.

Saya belum membaca 112 posting yang sekarang disembunyikan, jadi saya minta maaf jika saya mengulangi atau melewatkan sesuatu, tetapi saya benar-benar tertarik untuk membuat prototipe ide, atau membantu menguji dan mempertimbangkannya.

Saya pikir kita harus benar-benar mempertimbangkan untuk beralih ke sistem lain, jika data menjaminnya. Artinya, saya pikir kita harus mencoba dan mendapatkan ide yang lebih baik tentang seberapa jauh lebih mudah didekati sistem lembar acara vs sistem kita saat ini.

Kami sudah memiliki sangat sedikit pengelola untuk sistem skrip visual saat ini. Saya tidak berpikir peralihan lengkap akan pernah selesai dalam hidup kita :slightly_smiling_face:

Kami sudah memiliki sangat sedikit pengelola untuk sistem skrip visual saat ini. Saya tidak berpikir saklar lengkap akan pernah selesai dalam hidup kita

Nah dengan asumsi kita mendapatkan prototipe yang berfungsi dari lembar acara terlebih dahulu, maka kodenya sudah sebagian besar selesai, dan itu hanya akan menjadi pertanyaan apakah kita ingin beralih ke sistem itu, bukan?

Saya juga mulai dengan Membangun 2 dan menemukan lembar acara bagus untuk dipecahkan 2
masalah:

• Seperti skrip visual apa pun, Anda mengekspos semua kemungkinan apa pun
  modul/plugin/add-on/fungsi, ini sangat berguna untuk mempelajari kode baru.
  Node visual beralih ke kode spageti cukup cepat (saya seorang pria blender,
  Saya tahu tentang spageti di compositor dan shader).
• Lembar acara seperti kesombongan untuk API Istirahat, Anda mulai dengan didokumentasikan dengan baik
  kode yang mengisi menu tarik-turun lembar acara dan Anda mendapatkan GUI yang bersih
  cara untuk menggunakan kode Anda, Anda dapat memperpanjang dengan menjadi berantakan, dan, Anda mungkin
  hasilkan kode darinya (JS dari Construct2), maka pertanyaan saya: Bisakah kita
  menghasilkan kode dari itu?

Jika ya, saya pikir lembar acara harus menjadi prioritas, untuk kemudahan penggunaan untuk
semua orang dan generasi kode tingkat rendah yang dioptimalkan.
Jika Godot dapat digunakan untuk mengubah python/C#/... API menjadi set yang bersih dari
acara, lalu acara pembuatan pengguna, lalu Godot menghasilkan kode darinya, Anda
memecahkan masalah pengguna yang sangat sangat sulit: pelajari cara membuat kode dari UI sederhana.

Saya tahu lembar acara tidak menyelesaikan semua masalah tetapi setidaknya Anda dapat membuat kode 500
acara seperti yang Anda lakukan di spreadsheet tanpa hilang dalam visual
link di mana-mana.

Pada Rabu, 8 April 2020 pukul 19:44, Jay [email protected] menulis:

Kami sudah memiliki sangat sedikit pengelola untuk skrip visual saat ini
sistem. Saya tidak berpikir saklar lengkap akan pernah selesai di kami
seumur hidup

Nah dengan asumsi kita mendapatkan prototipe yang berfungsi dari lembar acara, maka kodenya
sebagian besar sudah selesai, itu hanya akan menjadi pertanyaan apakah kita
ingin beralih ke itu, bukan?

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/godotengine/godot/issues/17795#issuecomment-611096608 ,
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AAAP6LM4PU6RYLO5NK5IL23RLSZWHANCNFSM4EXTBSVQ
.

Saya mulai menggunakan Construct 2 dan akhirnya beralih ke pengembangan plugin menggunakan JavaScript, jadi lembar acara memiliki tempat di hati saya. Mereka mudah dan intuitif untuk yang belum tahu, dengan sebagian besar keajaiban dari visualisasi mudah dari metode yang tersedia (tindakan dan kondisi) untuk setiap kelas (plugin). Sejujurnya, GDScript di VSCode sama baiknya sekarang, dengan intellisense penuh dan pelengkapan otomatis membuat hidup menjadi mudah. Meskipun saya adalah penggemar berat ide ini 2 tahun yang lalu, sekarang saya berubah pikiran. Saya lebih suka para pahlawan pengembang Godot memfokuskan waktu dan upaya mereka untuk menambahkan peningkatan mesin lainnya.

Bisakah kita menghasilkan kode darinya?

Saya harus memeriksanya lebih dalam, tetapi sejujurnya saya pikir itu akan sangat sepele untuk dilakukan, dan sebenarnya itu mungkin cara terbaik untuk melakukannya. Artinya, saya pikir cara terbaik untuk menangani hal gaya lembar acara adalah pada dasarnya bertindak sebagai front-end grafis untuk file gdscript biasa. Tindakan yang diambil di editor lembar acara hanya akan mengedit file gdscript. Misalnya, memindahkan blok dari satu tempat ke tempat lain di editor lembar acara pada dasarnya akan dilakukan seperti memotong+tempel virtual ke file gdscript. Dan file gdscript apa pun dapat dilihat dan diedit baik di editor skrip atau di editor lembar acara. Ini sepertinya cara terbaik untuk melakukannya, baik dari sudut pandang kegunaan dan dari sudut pandang implementasi. Yang mengatakan saya belum terlalu tahu tentang pengembangan mesin, jadi saya mungkin salah.

Saya lebih suka para pahlawan pengembang Godot memfokuskan waktu dan upaya mereka untuk menambahkan peningkatan mesin lainnya.

Saya cukup setuju. Saya pikir cara ideal untuk melakukan ini adalah bagi siapa saja yang tertarik untuk mencoba dan mendapatkan prototipe yang berfungsi bersama, dan kemudian dari sana komunitas dapat mencoba dan mencari tahu apakah layak beralih ke itu sebagai sistem skrip visual utama atau tidak. Saya tidak akan meminta waktu pengembangan utama untuk ide ini sampai keputusan dibuat atau setidaknya mendekati.

Saya juga tidak cukup dalam Gdscript atau Godot.
Tapi apa yang saya kembangkan sebagai ekstensi Kode VS juga berjalan dengan cara yang luas ini
(https://github.com/j2l/blocklight).
Memahami kode secara visual dengan memainkannya dan secara visual
menghubungkan variabel dan hasil (simpul di sebagian besar skrip visual, atau warna
di ekstensi saya) adalah batu penjuru yang hilang bagi banyak orang.
Sebenarnya, kami memahami kode ketika kami selesai mempelajarinya, sementara kami seharusnya
lihat variabel dan tautan potongan sebelum mendapatkan semua
kode.
Desain sebelum coding :)

Pada hari Rabu, 8 April 2020 jam 20:08, Jay [email protected] menulis:

Bisakah kita menghasilkan kode darinya?

Saya harus melihat lebih dalam, tapi sejujurnya saya pikir itu akan cantik
sepele untuk melakukannya, dan sebenarnya itu mungkin cara terbaik untuk melakukannya. Itu adalah,
Saya pikir cara terbaik untuk menangani hal gaya lembar acara adalah pada dasarnya
membuatnya bertindak sebagai front-end grafis untuk file gdscript biasa. tindakan
diambil di editor lembar acara hanya akan mengedit file gdscript. Bergerak
blok dari satu tempat ke tempat lain di editor lembar acara pada dasarnya
di bawah tenda dilakukan seperti virtual cut+paste ke file gdscript. Dan
file gdscript apa pun dapat dilihat dan diedit baik di editor skrip atau di
editor lembar acara. Ini sepertinya cara terbaik untuk melakukannya, baik dari
sudut pandang kegunaan dan dari sudut pandang implementasi. Yang mengatakan aku
belum terlalu paham tentang pengembangan mesin, jadi saya mungkin salah.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/godotengine/godot/issues/17795#issuecomment-611108712 ,
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AAAP6LN7GFGSBDZ537XXA6DRLS4Q5ANCNFSM4EXTBSVQ
.

Saya suka gagasan bahwa itu akan menghasilkan file Gdscript biasa. Akan sangat bagus untuk belajar

Ketika saya mulai membuat game, sistem acara Klik & Play adalah cara yang sangat bagus bagi saya untuk memahami logika pemrograman, dan saya masih suka kembali ke sana.

Saya suka gagasan bahwa itu akan menghasilkan file Gdscript biasa. Akan sangat bagus untuk belajar

Ketika saya mulai membuat game, sistem acara Klik & Play adalah cara yang sangat bagus bagi saya untuk memahami logika pemrograman, dan saya masih suka kembali ke sana.

Saya pikir itu berpotensi menjadi salah satu keuntungan terbesarnya dibandingkan sistem spaghetti saat ini - karena desainnya akan memudahkan orang untuk belajar pemrograman dan api gdscript/godot.

Beberapa orang di sini berkomentar - tetapi mengapa repot-repot melakukannya - terlalu mirip dengan skrip dalam presentasi.
Jawaban saya untuk itu adalah - tepatnya. Anda belajar spageti, Anda tinggal dengan spageti. Anda mempelajari lembar acara, Anda akan mengetahui gdscript dengan melihat apa yang dihasilkannya dan menggunakan bidang ekspresi tersebut.

Ini akan mengajari Anda tentang perintah eksekusi dan cara membaca kode.

Lihat apa yang dilakukan konversi ke GML di pembuat game
https://docs2.yoyogames.com/source/_build/3_scripting/1_drag_and_drop_overview/changing_dnd.html

blurymind yang sangat menarik! Saya memiliki ide yang sama dan saya sepenuhnya mendukung ini.
Saya masih membuat ekstensi untuk Clickteam Fusion 2.5 tetapi semua yang ingin saya tambahkan di Fusion ada di Godot.
Yang saya butuhkan hanyalah meletakkan satu lapisan abstraksi (lembar acara) di Godot untuk membuat pengembangan lebih mudah.
Saya tidak membaca seluruh utas tetapi perbedaan utama dari sudut pandang saya antara skrip visual di Godot dan lembar acara di mesin game lain adalah bahwa skrip visual "hanya" tampilan visual kode dan lembar acara adalah abstraksi dari kode dengan tampilan yang disederhanakan. Ini lebih mudah dibaca manusia, memfaktorkan hal-hal yang membutuhkan beberapa baris kode dalam satu baris dan tautan sinyal/slot dilakukan secara otomatis.
Sebenarnya, menambahkan beberapa templat (adegan yang telah ditentukan sebelumnya) ke objek bawaan CF2.5 abstrak dan masih menggunakan GDScript akan melakukan sebagian besar pekerjaan untuk saya tetapi lembar acara pasti akan membuat saya lebih efisien di Godot daripada apa yang saya lakukan di CF2.5 sekarang.

blurymind yang sangat menarik! Saya memiliki ide yang sama dan saya sepenuhnya mendukung ini.
Saya masih membuat ekstensi untuk Clickteam Fusion 2.5 tetapi semua yang ingin saya tambahkan di Fusion ada di Godot.
Yang saya butuhkan hanyalah meletakkan satu lapisan abstraksi (lembar acara) di Godot untuk membuat pengembangan lebih mudah.
Saya tidak membaca seluruh utas tetapi perbedaan utama dari sudut pandang saya antara skrip visual di Godot dan lembar acara di mesin game lain adalah bahwa skrip visual "hanya" tampilan visual kode dan lembar acara adalah abstraksi dari kode dengan tampilan yang disederhanakan. Ini lebih mudah dibaca manusia, memfaktorkan hal-hal yang membutuhkan beberapa baris kode dalam satu baris dan tautan sinyal/slot dilakukan secara otomatis.
Sebenarnya, menambahkan beberapa templat (adegan yang telah ditentukan sebelumnya) ke objek bawaan CF2.5 abstrak dan masih menggunakan GDScript akan melakukan sebagian besar pekerjaan untuk saya tetapi lembar acara pasti akan membuat saya lebih efisien di Godot daripada apa yang saya lakukan di CF2.5 sekarang.

saya dulu menggunakan CF pada masa itu disebut multimedia fusion, itu cukup mudah untuk dipelajari sebagai seorang anak yang tidak berbicara bahasa Inggris, dan setelah berlatih dengannya, Anda bisa sangat cepat, tergantung pada apa yang Anda lakukan itu bisa lebih cepat daripada mengetik.
konstruksi dan CF adalah referensi seperti apa tampilan skrip visual yang baik (gdevelop sedang menuju ke sana)

Terima kasih
Saya mendukung ide bagus ini
Mereka mengatakan konstruksi 2 akan pensiun!
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505

Saya ingin tahu apakah mungkin untuk bernegosiasi dengan pengembang konstruksi 2 untuk membuka sumber sistem acara, dan menggunakannya di godot, unity, dll.
Merupakan kerugian yang membangun 2 sistem acara diabaikan di rak-rak yang tidak digunakan

Terima kasih
Saya mendukung ide bagus ini
Mereka mengatakan konstruksi 2 akan pensiun!
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505

Saya ingin tahu apakah mungkin untuk bernegosiasi dengan pengembang konstruksi 2 untuk membuka sumber sistem acara, dan menggunakannya di godot, unity, dll.
Merupakan kerugian yang membangun 2 sistem acara diabaikan di rak-rak yang tidak digunakan

Saya ragu kita dapat menggunakan kode apa pun dari construct2 di godot - mereka adalah basis kode yang sama sekali berbeda.

Taruhan terbaik Anda untuk alternatif sumber terbuka adalah pindah ke gdevelop
https://github.com/4ian/GDevelop

Tiket edisi ini kemungkinan akan segera ditutup, jadi jika ada minat pada lembar acara ini di godot - kami mungkin akan segera memindahkannya ke tempat lain :) (atau ke gdevelop)

Tiket edisi ini kemungkinan akan segera ditutup, jadi jika ada minat dalam lembar acara ini di godot - kami mungkin akan segera memindahkannya ke tempat lain :)

Apa? Mengapa?

@TheGoklayeh Mungkin ditutup karena kami memigrasikan proposal fitur ke godot-proposals .

Yang mengatakan, @blurymind dapat mengedit posting pertama agar sesuai dengan template proposal . Kami kemudian dapat memindahkan masalah ini ke repositori proposal.

Kami sangat membutuhkan mesin 3d yang memanfaatkan lembar acara.

Terima kasih
Saya mendukung ide bagus ini
Mereka mengatakan konstruksi 2 akan pensiun!
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505

Saya ingin tahu apakah mungkin untuk bernegosiasi dengan pengembang konstruksi 2 untuk membuka sumber sistem acara, dan menggunakannya di godot, unity, dll.
Merupakan kerugian yang membangun 2 sistem acara diabaikan di rak-rak yang tidak digunakan

Itu mungkin merusak bisnis mereka. dan clickteam sebagai tambahan.

Terima kasih
Saya mendukung ide bagus ini
Mereka mengatakan konstruksi 2 akan pensiun!
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505
Saya ingin tahu apakah mungkin untuk bernegosiasi dengan pengembang konstruksi 2 untuk membuka sumber sistem acara, dan menggunakannya di godot, unity, dll.
Merupakan kerugian yang membangun 2 sistem acara diabaikan di rak-rak yang tidak digunakan

Itu mungkin merusak bisnis mereka. dan clickteam sebagai tambahan.

Jika ada yang membunuh mereka - clickteam akan disebabkan oleh kurangnya pembaruan pada perangkat lunak mereka (terakhir pada tahun 2019), Scirra akan memaksa pengguna mereka untuk beralih ke lisensi sewa perangkat lunak yang memaksa mereka untuk membayar setiap tahun atau mendapatkan dikunci. Kedua perusahaan memiliki kekurangan dan komunitas mereka tidak memiliki kendali atas apa yang terjadi pada perangkat lunak. Di sinilah open source bersinar

@TheGoklayeh Mungkin ditutup karena kami memigrasikan proposal fitur ke godot-proposals .

Yang mengatakan, @blurymind dapat mengedit posting pertama agar sesuai dengan template proposal . Kami kemudian dapat memindahkan masalah ini ke repositori proposal.

Bisakah seseorang melakukan itu, bukan saya? :)
Saya agak kehilangan harapan agar fitur ini dapat menjangkau godot secara asli (bukan ekstensi). Pendekatan spageti telah memenangkan pengguna dan pengembang godot

@blurymind Jika Anda tidak lagi mendukung proposal ini, maka saya pikir lebih baik untuk menutupnya. Orang lain yang tertarik untuk mengerjakan pendekatan lembar acara kemudian dapat membuka proposal baru di godot-proposals . (Karena banyaknya pekerjaan yang diperlukan, saya pikir tidak masuk akal untuk membuka proposal jika tidak ada yang secara teknis dapat memenuhinya.)

Namun, utas ini berisi banyak diskusi yang berharga, jadi terima kasih juga :slightly_smiling_face:

Saya pikir proposal ini sangat konyol :)
Tapi bisakah kita membuat sistem acara dengan mesin konstruk 3?!
Saya pikir game dapat menghasilkan kode dan mengirimkannya dalam file teks ke mesin godot melalui node.js

Ini konyol.. tapi menurut saya konstruksi 3 cukup kuat untuk membuat sistem acara
Ini lebih baik daripada tidak sama sekali saat ini

Ya mudah-mudahan setidaknya kami berhasil mencapai ide tentang sistem seperti itu di godot, kelebihannya dibandingkan sistem pengkodean visual saat ini dan pendapat tentang mesin lain yang menggunakannya

Sejujurnya saya suka, bagaimana GDevelop melakukannya, tetapi Godot melakukan skrip acara bukanlah sesuatu yang saya sukai sekarang (hari-hari ini).
Saya mencoba mengimplementasikannya sekali, dan saya menyadari bahwa Godot memiliki API yang sangat granular/tingkat rendah untuk diekspos langsung dari sistem Visual Scripting.
Sistem skrip visual saat ini disertakan dan mengapa saya lebih suka memiliki lapisan abstraksi khusus tetapi tetap kuat.
Implementasi seperti itu sangat sulit untuk ditulis untuk skrip acara kecuali Anda menggunakan beberapa DSL seperti bahasa sub-skrip acara, di mana masing-masing digunakan untuk bagian tertentu dari mesin.

Sistem skrip visual umum yang sederhana dan mudah digunakan akan sangat sulit dicapai dan itulah yang saya anggap sebagai "Proyek Unicorn".
Karena peningkatan generalisasi kemungkinan besar akan menyebabkan peningkatan yang jauh lebih besar dalam kompleksitas sistem tersebut.

Saya berencana untuk mengambil Visual Scripting secara bertahap menuju arah di mana ia dapat memiliki antarmuka khusus untuk semua bagian Mesin.
Bayangkan cara pengeditan yang berbeda untuk setiap jenis simpul kompleks primitif, seperti dalam Cetak Biru, yang memiliki simpul ekspresi.
https://docs.unrealengine.com/en-US/Engine/Blueprints/UserGuide/MathNode/index.html

Tapi untuk memperjelas, saya tidak menentang Event Scripting, saya ingin melihat seseorang datang dengan proposal yang dapat mencakup beberapa sistem tertentu dari Godot, dan mengapa dan bagaimana hal itu dapat berguna. Secara pribadi saya merasa cukup bagus untuk perilaku pemrograman, bagaimana GDevelop melakukannya.
http://wiki.compilgames.net/doku.php/gdevelop5/behaviors
http://wiki.compilgames.net/doku.php/gdevelop5/behaviors/events-based-behaviors

Saya tidak akan menggunakannya untuk menulis game yang tepat, tetapi jika kita memiliki perilaku sederhana yang dapat kita gunakan untuk drop down dan bermain, saya melihatnya sebagai cara yang cukup menyenangkan untuk mengoptimalkan proyek bagi anak-anak yang belajar membuat game.
Atau seseorang yang tidak terbiasa memprogram menggunakannya untuk game jam.

Meskipun hal yang sama dapat dikatakan tentang VisualScript dan modularitas mungkin akan lebih mudah dicapai dengannya. Masalahnya adalah penyatuan dan konsistensi (Visual Shader dan VisualScript menggunakan basis kode yang sama sekali berbeda, hanya kesamaan yang digunakan Node UI).
Namun, kita pasti bisa mencoba untuk memiliki sistem Event Script sebagai Plugin (C++ Plugin, mudah-mudahan menjadi mudah dilakukan setelah 4.0) yang dapat dipertahankan oleh komunitas dan ditambahkan ke Godot saat dibutuhkan. (Saya agak bias terhadap Mesin Game modular)

Bagaimanapun itu hanya 2 sen saya.

Mengapa komentar saya ditandai sebagai di luar topik? Apakah seseorang menyensor komunitas, dan siapa? Itu bukan pertanda baik. Ada komentar lain selain saya yang lebih di luar topik.

@prominentdetail Ini pesan anti bump saya, saya lupa paste :slightly_smiling_face:

Tolong jangan menabrak masalah tanpa memberikan informasi baru yang signifikan. Gunakan tombol :+1: reaksi pada posting pertama sebagai gantinya.

(Saya berharap GitHub memiliki cara untuk mengirim pesan pribadi, atau setidaknya menentukan alasan khusus untuk bersembunyi, jadi saya tidak perlu mengotori utas komentar dengan ini.)

PS: Ini adalah etiket khas di GitHub; itu tidak khusus untuk repositori ini.

Saya mendukung proposal ini, hanya saja tidak berpikir siapa pun akan meluangkan waktu untuk mengimplementasikannya.
Itu tidak memiliki dukungan yang cukup kuat dari pengembang yang benar-benar dapat mewujudkannya.

Patut dicoba dan diskusinya menarik pasti :)

@blurymind jika Anda masih mendukung proposal dan bersedia meluangkan waktu untuk menuliskannya dalam format yang diperlukan untuk GIP. Layak melakukan IMO.

Cara sesuatu ditambahkan di Godot adalah ketika seseorang yang tertarik dengan suatu fitur meluangkan waktu untuk mengimplementasikannya. Ini sangat acak dan sporadis. Tetapi kami hampir sepenuhnya mengandalkan kontributor yang memutuskan untuk menambahkan fitur secara acak.

Jadi hanya karena kumpulan pengembang aktif saat ini belum tertarik dengan proposal Anda, bukan berarti seseorang tidak akan datang dan mengimplementasikannya.