Godot: Desainer game yang mudah digunakan untuk non programer

skrip visual direncanakan di beberapa titik

Pada Rabu, 14 Januari 2015 pukul 06:20, RyanBram [email protected] menulis:

Hai, Pengembang Godot.

Pertama-tama saya ingin mengucapkan terima kasih kepada Anda semua karena telah menciptakan mesin game yang hebat
dengan lisensi yang sangat permisif. Upaya Anda akan membantu banyak pengembang dan
siswa dengan anggaran yang ketat untuk memenuhi impian mereka.

Dengan status Godot saat ini, game open source akan memiliki masa depan yang lebih cerah.
Sayangnya sebagian besar mesin game open source dirancang dengan canggih
pengguna dalam pikiran dengan sedikit pengetahuan tentang pemrograman. Itu masih tidak bisa mencapai
pembuat game pemula.

Saran saya adalah untuk menyediakan desainer/editor game yang mudah digunakan dengan
GUI intuitif dan kelas yang telah ditentukan untuk memudahkan tugas programmer baru. Lagi
programmer berarti lebih banyak pengguna (karena pengguna Godot adalah programmer game).

Saya tahu satu mesin permainan yang melakukan pekerjaan ini dengan baik. Itu ditulis dari Ruby,
berasal dari Jepang, dan diterjemahkan ke dalam bahasa Inggris di seluruh dunia. Ini disebut RPG
Pembuat VX Ace
http://www.rpgmakerweb.com/products/programs/rpg-maker-vx-ace. Meskipun
kata RPG di depan namanya, itu cukup mampu untuk membuat non-RPG
game dengan Ruby Game Scripting System (RGSS) bawaannya.

https://camo.githubusercontent.com/72746b38bc6f990eb5f1b9bb242bdce347af3c72/687474703a2f2f67616d6573617265576696c2e636f6d2f77702d636f6e746656e742f75706c6f6164716

Berikut daftar contoh game yang dibuat dengan engine RPG Maker:

1. Aleph (Petualangan RPG) http://www.pioneervalleygames.com/
2. Tidak Ada Manatee yang Dijanjikan (Arcade) http://rpgmaker.net/games/5102/
3. Ragarokk - Bestiarium (Permainan Kartu) http://rpgmaker.net/games/5808/
4. Bumi Diserang! (Penembak) http://rpgmaker.net/games/6561/
5. Terra (VisualNovel) http://rpgmaker.net/games/3956/
6. Memories of Mana (RPG Aksi)
   http://www.atelier-rgss.com/Project/Mana/Project_Mana_Story.html
7. Myhos - Awal (Horor) http://rpgmaker.net/games/6493/

Saya berharap mesin Godot menjadi sepopuler RPG Maker, karena memiliki banyak
lebih banyak fitur daripada RPG Maker. Pemrogram pemula hanya perlu mudah digunakan
antarmuka. Jika sukses, studio Okam dapat menjadi GOG atau Steam berikutnya
yang menerbitkan ribuan game yang dibuat oleh pengembang inde.

Salam, Ryan

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/okamstudio/godot/issues/1220.

@RyanBram - Sama sekali tidak mencoba untuk menurunkan ide, di sini - mungkin bisa berguna di masa depan, tapi saya tidak yakin skrip visual adalah cara skrip yang efektif. Saya tidak bisa mengatakan dengan pasti, tetapi saya membayangkan game yang lebih kompleks yang Anda posting kemungkinan besar ditulis dalam teks, bukan secara visual. Sepertinya skrip visual adalah sesuatu yang digunakan pengguna baru, tentu saja, tetapi itu menunda mereka dalam mempelajari alat yang sebenarnya mereka perlukan untuk menyelesaikan proyek mereka dengan benar. Tapi itu bisa membuat mesin lebih mudah didekati, jadi saya tidak tahu.

Seharusnya juga memungkinkan bagi pengguna untuk membuat sistem pemrograman visual semuanya di Godot dengan GDScript sebagai lawan dari sesuatu yang perlu dibangun ke dalam mesin, bukan? Aku tidak yakin tentang itu.

Pembuat RPG tampaknya mengambil lebih dari pendekatan "Modding", dan jika Godot akan terlihat lebih seperti pembuat RPG - orang yang memiliki niat untuk membuat berbagai jenis permainan akan berpaling. Jadi yang pada dasarnya Anda sarankan adalah membuat godot lebih mirip GameMaker (yang dapat dimengerti, banyak orang ingin membuat game tetapi tidak tahu pemrograman) tetapi ada batasannya :)
Yang mungkin terjadi adalah Godot akan mendapatkan editor Nodal Behavior Graph, seperti yang dimiliki Leadwerks dan BGE. Ini bekerja sangat baik dengan elemen GUI, sisanya akan memerlukan beberapa penelitian dan banyak umpan balik komunitas, untuk membuatnya semudah dan sekuat mungkin.

@SolarLune , dimungkinkan untuk membuat game di Godot dan menambahkan editor di atasnya yang memungkinkan modding game ke setiap detail kecil (dengan menggunakan GraphNodes dan UI lainnya, sangat menyenangkan untuk dimainkan), dan bahkan memungkinkan untuk menulis beberapa kode GDscript tambahan di atas, saya pikir ini adalah pendekatan terbaik, untuk mengirimkan game game lengkap (RPG, FPS, RTS) secara terpisah dan memungkinkan mengutak-atik setiap aspeknya. Konstruktor dibuat di Godot.

@SolarLune : Skrip visual berguna saat Anda bekerja sama dengan a
programmer, yang dapat membuat blok untuk Anda mainkan. Ini
pendekatan di Unreal berguna. Saya tidak berpikir itu mungkin untuk menggantikan
pemrograman sepenuhnya (kecuali Anda seorang masokis), tetapi itu bisa berhasil untuk
beberapa orang membuat blok template untuk non-programmer juga.

Pada hari Rabu, 14 Januari 2015 pukul 16.23, TheoXD [email protected] menulis:

Pembuat RPG tampaknya mengambil lebih banyak pendekatan "Modding", dan jika godot mau
lebih mirip pembuat RPG - orang yang memiliki niat untuk membuat berbeda
jenis permainan akan berpaling. Jadi apa yang pada dasarnya Anda sarankan adalah untuk
membuat godot terlihat lebih seperti GameMaker (yang dapat dimengerti, banyak orang
pengen bikin game tapi gak ngerti programming) tapi ada batasannya :)
Apa yang mungkin terjadi adalah Godot akan mendapatkan Grafik Perilaku Nodal
editor, mirip dengan apa yang dimiliki Leadwerks dan BGE. Ini bekerja sangat baik dengan
elemen GUI, sisanya akan membutuhkan beberapa penelitian dan banyak komunitas
umpan balik, untuk membuatnya semudah dan sekuat mungkin.

@SolarLune https://github.com/SolarLune , mungkin untuk membuat game
di Godot dan tambahkan editor di atas yang memungkinkan modding game ke setiap
sedikit detail (dengan menggunakan GraphNodes dan UI lainnya), dan bahkan memungkinkan untuk
tulis beberapa kode GDscript tambahan di atas, saya pikir ini adalah pendekatan terbaik,
untuk mengirimkan game game lengkap (RPG, FPS, RTS) secara terpisah dan memungkinkan penyesuaian
setiap aspeknya.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -69974733.

Nah, dari yang saya tahu, Godot sudah memiliki kode UI berbasis node (untuk pohon animasi dan sekarang editor visual shader) yang di masa depan dapat digunakan untuk membuat jenis pohon 'logika'.

Namun, kita harus mencatat bahwa GDscript akan tetap jalan jika Anda menginginkan fleksibilitas maksimum dan membuat logika node berguna akan memerlukan script node untuk eksekusi GDscript (untuk hal-hal yang lebih kompleks dan lebih maju).

UE4 saat ini tidak dapat melakukan semuanya dalam Cetak Biru tanpa kerumitan yang gila, GameMaker mengharapkan Anda menggunakan GML untuk fleksibilitas maksimum (melalui penggunaan blok kode), dan BGE memerlukan skrip dalam Python untuk daya maksimum (melalui penggunaan kode bata). Seseorang tidak dapat mengabaikan kegunaan pengeditan visual untuk pembuatan prototipe cepat dan situasi logika yang tidak terlalu rumit, tetapi seringkali tidak dapat melakukan semua yang dapat dilakukan dalam kode.

skrip visual direncanakan di beberapa titik

Terima kasih atas tanggapan yang sederhana dan positif.

Semuanya, terima kasih telah mengomentari saran ini. Saya percaya editor yang mudah dan visual tidak pernah cukup mampu untuk menggantikan pengkodean dengan tangan. Saya menyarankan fitur ini sebagai pelengkap untuk pengkodean biasa bukan untuk menggantikan posisinya.

Di RPG Maker VX Ace, sebagian besar fitur canggih dikodekan dengan tangan. Seorang programmer tingkat lanjut biasanya menyediakan skrip modding tingkat lanjut yang nilainya dapat diedit di Editor GUI oleh pengguna biasa (Nama karakter, keterampilan, potret, sprite, dll). Sistem Scripting Game Ruby memungkinkan untuk patching monyet. Inilah sebabnya mengapa sebagian besar skrip yang disediakan oleh pengguna tingkat lanjut tidak akan menggantikan kelas standar asli oleh pengembang RPG Maker untuk menghindari masalah kompatibilitas.

Untuk perbandingan:
Proyek KDE dan GNOME tidak pernah bermaksud untuk menggantikan Perintah Shell yang kuat di Linux, melainkan proyek hanya mencoba untuk mengisi kesenjangan antara kemudahan penggunaan dan kekuatan Linux.

Saya tersenyum tentang gagasan studio Okam menjadi seperti Steam... :))

Pada 14/1/2015 17:20, RyanBram menulis:

Hai, Pengembang Godot.

Pertama-tama saya ingin mengucapkan terima kasih kepada Anda semua karena telah membuat game yang hebat
mesin dengan lisensi yang sangat permisif. Upaya Anda akan membantu banyak orang
pengembang dan siswa dengan anggaran yang ketat untuk memenuhi impian mereka.

Dengan status Godot saat ini, game open source akan lebih cerah
masa depan. Sayangnya sebagian besar mesin game open source dirancang
dengan mempertimbangkan pengguna tingkat lanjut dengan sedikit pengetahuan tentang pemrograman. Dia
masih belum bisa menjangkau pembuat game pemula.

Saran saya adalah untuk menyediakan desainer/editor game yang mudah digunakan dengan
GUI intuitif dan kelas yang telah ditentukan untuk memudahkan tugas programmer baru.
Lebih banyak programmer berarti lebih banyak pengguna (karena pengguna Godot adalah programmer game).

Saya tahu satu mesin permainan yang melakukan pekerjaan ini dengan baik. Itu ditulis dari Ruby,
berasal dari Jepang, dan diterjemahkan ke dalam bahasa Inggris di seluruh dunia. Dia
disebut RPG Maker VX Ace
http://www.rpgmakerweb.com/products/programs/rpg-maker-vx-ace.
Terlepas dari kata RPG di depan namanya, itu cukup mampu untuk
buat game non-RPG dengan Ruby Game Scripting System (RGSS) bawaannya.

https://camo.githubusercontent.com/72746b38bc6f990eb5f1b9bb242bdce347af3c72/687474703a2f2f67616d6573617265576696c2e636f6d2f77702d636f6e746656e742f75706c6f6164716

Berikut daftar contoh game yang dibuat dengan engine RPG Maker:

1. Aleph (Petualangan RPG) http://www.pioneervalleygames.com/
2. Tidak Ada Manatee yang Dijanjikan (Arcade) http://rpgmaker.net/games/5102/
3. Ragarokk - Bestiarium (Permainan Kartu) http://rpgmaker.net/games/5808/
4. Bumi Diserang! (Penembak) http://rpgmaker.net/games/6561/
5. Terra (VisualNovel) http://rpgmaker.net/games/3956/
6. Memories of Mana (RPG Aksi)
   http://www.atelier-rgss.com/Project/Mana/Project_Mana_Story.html
7. Myhos - Awal (Horor) http://rpgmaker.net/games/6493/

Saya berharap mesin Godot menjadi sepopuler RPG Maker, karena memiliki
lebih banyak fitur daripada RPG Maker. Pemrogram pemula hanya perlu
antarmuka yang mudah digunakan. Jika sukses, studio Okam bisa menjadi yang berikutnya
GOG atau Steam yang menerbitkan ribuan game yang dibuat oleh pengembang inde.

Salam, Ryan

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/okamstudio/godot/issues/1220.

Unreal sebenarnya memiliki template untuk proyek apakah Anda ingin melakukannya
skrip visual atau jenis alur kerja skrip lengkap...
blok kode untuk pengeditan visual dapat diakses melalui studio visual dan menjadi
disesuaikan... :)

Pada 15/1/2015 3:44, Juan Linietsky menulis:

@SolarLune : Skrip visual berguna saat Anda bekerja sama dengan a
programmer, yang dapat membuat blok untuk Anda mainkan.
Ini
pendekatan di Unreal berguna. Saya tidak berpikir itu mungkin untuk menggantikan
pemrograman sepenuhnya (kecuali Anda seorang masokis), tetapi itu bisa berhasil untuk
beberapa orang membuat blok template untuk non-programmer juga.

Pada hari Rabu, 14 Januari 2015 pukul 16.23, TheoXD [email protected] menulis:

Pembuat RPG tampaknya mengambil lebih banyak pendekatan "Modding", dan jika godot mau
lebih mirip pembuat RPG - orang yang memiliki niat untuk membuat berbeda
jenis permainan akan berpaling. Jadi apa yang pada dasarnya Anda sarankan adalah untuk
membuat godot terlihat lebih seperti GameMaker (yang bisa dimengerti, banyak
rakyat
pengen bikin game tapi gak ngerti programming) tapi ada batasannya :)
Apa yang mungkin terjadi adalah Godot akan mendapatkan Grafik Perilaku Nodal
editor, mirip dengan apa yang dimiliki Leadwerks dan BGE. Ini bekerja dengan sangat baik
dengan
elemen GUI, sisanya akan memerlukan beberapa penelitian dan banyak lagi
masyarakat
umpan balik, untuk membuatnya semudah dan sekuat mungkin.

@SolarLune https://github.com/SolarLune , mungkin untuk membuat game
di Godot dan tambahkan editor di atas yang memungkinkan modding game ke setiap
sedikit detail (dengan menggunakan GraphNodes dan UI lainnya), dan bahkan akan
mengijinkan untuk
tulis beberapa kode GDscript tambahan di atas, saya pikir ini yang terbaik
mendekati,
untuk mengirimkan game game lengkap (RPG, FPS, RTS) secara terpisah dan izinkan
mengutak-atik
setiap aspeknya.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -69974733.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -69978224.

Saya tersenyum tentang gagasan studio Okam menjadi seperti Steam... :))

Saya pun tersenyum positif.
Karena akan sangat bagus bagi saya sebagai seorang gamer jika ada perusahaan sebesar Steam dengan banyak katalog game, open, dan DRM Free, yang dibuat oleh ribuan developer game hebat.

Unreal sebenarnya memiliki template untuk proyek apakah Anda ingin melakukannya
skrip visual atau jenis alur kerja skrip lengkap...
blok kode untuk pengeditan visual dapat diakses melalui studio visual dan menjadi
disesuaikan... :)

Hebat jika itu akan tersedia di Godot.

Salam,
Ryan

Hai Ryan

Sudahkah Anda memeriksa Construct 2? Ini adalah salah satu desainer game visual favorit saya dan sangat mudah digunakan.

Pemrograman visual di Godot, saya pikir akan agak sulit dilakukan (karena Godot melakukan 2d dan 3d sehingga cakupannya jauh lebih besar.)
Juga kemungkinan besar akan dibangun di kemudian hari ketika semua blok dasar untuk mesin sudah terpasang.

Saya tahu reduz memiliki peta jalannya sendiri untuk ini, tetapi saya harap dia tidak memprioritaskan ini di atas pembaruan editor/mesin lainnya. Saya lebih suka Godot digunakan oleh programmer pemula atau semi mahir daripada non programmer. Tapi itu hanya aku.

Hai Ryan

Sudahkah Anda memeriksa Construct 2? Ini adalah salah satu desainer game visual favorit saya dan sangat mudah digunakan.

Saya mencoba Construct 2. Ini bagus dan luar biasa. Game yang dihasilkan juga lintas platform, jadi ini merupakan nilai tambah yang besar. Sayangnya saya masih belum menemukan tutorial untuk membuat game RPG dengan mudah. Untuk saat ini saya mungkin tetap menggunakan RPG Maker VX Ace dan mencoba mem-porting game saya ke banyak platform (termasuk Android) dengan bantuan MKXP Project .

Terima kasih telah berbagi. Saya menantikan pemrograman visual di Godot.

Salam,
Ryan

Untuk pendekatan skrip visual - Anda dapat membuat catatan dari gdevelop, fusi multimedia, dan konstruksi 2. Mesin tersebut mengandalkan 100% skrip visual. Anda masih perlu mempelajari beberapa sintaks di mana ekspresi diperlukan, tetapi editor ekspresi membuatnya sangat mudah untuk menemukan perintah yang tepat. Ketiga engine ini memberi Anda kebebasan untuk membuat semua jenis game dengan skrip visual - berbeda dengan pembuat game dan pembuat rpg.

Pembuat Rpg bukanlah contoh yang baik, karena sangat terbatas.
Skrip berbasis simpul sangat tidak efisien dalam hal penggunaan ruang - Anda akan menggeser dan memperbesar dan memperkecil melalui grafik simpul raksasa. Bandingkan dengan konstruksi 2, di mana semuanya ditata dengan jelas dan ketat serta mudah dibaca - dan Anda mendapatkan pemenangnya.

BGE mungkin adalah contoh terburuk di sini, karena mencoba menggabungkan pendekatan berbasis simpul dengan blok logika. Saya menulis tentang mengapa ini buruk:
http://blenderartists.org/forum/showthread.php?323905-comparing-BGE-logic-bricks-with-Scirra-Construct-event-sheet-for-prototyping

Jika Anda melakukan skrip visual, tolong jangan setengah-setengah dengan editor berbasis simpul generik. Jika Anda ingin lebih banyak orang non-programmer menggunakan mesin Anda, lakukan sesuatu dengan desain yang lebih baik - seperti konstruksi2 atau fusi multimedia.

Saya ingin melihat sesuatu seperti ini diimplementasikan _only_ sebagai cara pemrograman sekunder. Skrip visual, sebagai lawan dari kode, memperlambat produktivitas dengan urutan besarnya yang cukup besar. Itu juga cenderung membuat debugging dan refactoring jauh lebih sulit. Satu-satunya keuntungan besar yang dapat saya pikirkan (selain karena menarik bagi non-programmer) adalah bahwa skrip visual cenderung menjadi alat pengajaran yang hebat jika ia dapat menghasilkan, atau setidaknya menunjukkan, kode GDScript aktual (kode IE. org). Saya tidak berpikir itu perlu sebaliknya (IE. GDScript ke Visual). Saya pikir ini akan menjadi cara yang bagus bagi sekolah untuk mengadopsi Godot ke dalam kelas mereka.

Berikut adalah dua perbedaan utama antara kode dan skrip visual yang menurut saya paling penting sejauh dapat didekati. Ini datang dari seseorang yang tidak akan menyentuh skrip visual dengan tiang sepuluh kaki, tapi saya mengerti itu menarik bagi sebagian orang :)

Kode: Kode cenderung memiliki aturan sintaksis khusus yang harus diikuti. Dugaan saya adalah ini cenderung menjadi hal utama yang mematikan non-programmer. YAITU. di GDScript Anda harus memiliki titik dua di akhir deklarasi fungsi, if, for, while loop dll. Anda harus membuat indentasi dengan benar. Anda harus menggunakan kata kunci var saat mendeklarasikan variabel seperti "var myInteger = 1". Untuk sebagian besar bahasa, cenderung ada sekitar 3 atau 4 aturan sintaks utama yang cenderung perlu diikuti dan menurut saya tidak terlalu sulit untuk dipelajari. Setelah menulis beberapa skrip kecil, bahkan seorang seniman dapat mempelajarinya. Saya mengatakan ini karena saya bekerja dengan dua seniman yang sangat berbakat yang mengerjakan ketiga game Age of Empires dengan Ensemble Studios. Yang satu telah menulis cukup banyak kode dalam UnityScript dan yang lainnya sekarang telah menulis banyak sekali kode dalam C#.

Visual: Anda cenderung mendapatkan menu dropdown untuk metode, variabel, pernyataan, dll. Namun, Anda masih harus mengetahui fungsi, properti, dll yang Anda cari dan apa yang mereka lakukan dan bahkan terkadang cara kerjanya. Anda masih harus memecahkan masalah. Anda masih harus menggunakan variabel dan melacak apa yang mereka lakukan di seluruh skrip Anda. Anda masih dapat memiliki kesalahan logis semudah menulis kode.

Saya pikir kemampuan untuk benar-benar menulis kode pada akhirnya adalah cara yang jauh lebih unggul dari sudut pandang produktivitas. Namun, keduanya tidak akan membuat Anda menjadi programmer yang lebih baik/lebih buruk. Saya pikir skrip visual adalah alat pengajaran yang sangat bagus, tetapi jika Anda tidak tahu (atau ingin belajar) bagaimana menyusun sesuatu dengan benar dan terutama bagaimana memecahkan masalah, skrip visual tidak akan membantu Anda sedikit pun.

Saya akan mengambil pendekatan yang sedikit berbeda. Karena editor godot digerakkan sendiri - mudah untuk membuat ulang antarmuka editor serupa dalam skrip GD murni.

Jadi proposal saya adalah membuat skrip konstruktor sepenuhnya di godot dan mengirimkannya secara terpisah. Ini akan memungkinkan programmer dan non-programmer untuk bekerja pada proyek yang sama saat menggunakan alat yang berbeda. Satu-satunya masalah adalah bahwa non-programmer terkadang harus berurusan dengan kedua alat secara bersamaan, tapi hei, saya telah melihat editor xD Gridmap yang lebih buruk, editor shader, editor animasi, editor kode - dapat dibuat ulang, sementara pengimpor collada, cembung generator, eksportir - tidak semudah itu. Masih terasa seperti menemukan kembali roda, tetapi dapat menyederhanakan banyak hal.

Inti konstruktor dapat diadopsi ke genre game apa pun (FPS, RTS, GPS....) dengan konten dan hal-hal yang dapat diunduh, dan jika komunitas itu dipelihara - akan lebih mudah untuk berkontribusi, karena semuanya adalah GDscript
Sepertinya tidak akan ada skrip visual di godot dalam waktu dekat, tetapi itu tidak menghentikan orang lain untuk membuat konstruktor di atasnya. Saya pernah melihat seseorang menggunakan Blender 2.5 dan membuat alat untuk mendesain interior.

Saya pikir memiliki banyak editor dapat memecah pengembangan Godot. Perlu ada satu proyek pusat yang dirancang dengan baik untuk alat skrip visual yang dibangun di atas gdscript.

Jangan malas dan lakukan penelitian Anda. Lihatlah mesin skrip visual murni lainnya. Bandingkan basis pengguna mereka (seberapa populer mereka), bandingkan seberapa fleksibel mereka - jenis game yang dibuat dengan mereka - baik itu di kickstarter, steam, atau platform lainnya.
Lihatlah pendekatan desain mereka.

Kemudian desain di atas kertas. Jangan hanya menyalin pendekatan simpul. Menggunakan node untuk shader tidak apa-apa, tetapi ketika sampai pada logika, Anda berakhir dengan kekacauan untuk menggulir dan mencoba mencari tahu.

percayalah, saya mencoba segalanya. Playmaker Unity, Kismet Unreal, pembuat rpg, stencyl, dll dll.
Construct2 hadir di atas, bersama dengan perpaduan multimedia. Itu adalah yang paling populer, dengan pendekatan paling fleksibel. Dan mereka berdua memiliki toko pasar aset.
Mereka sangat fleksibel dan jika Anda melihat ke dalam game yang dibuat dengan mereka - ada banyak variasi genre.

Jika Anda menjadi lebih pintar tentang ini, Anda dapat bekerja sama dengan Gdevelop- proyek open source lain yang telah memiliki editor skrip visual yang membuat game html5.
Lihatlah desain dan kode sumbernya..

Jika kita mengambil suara di utas ini, saya cukup yakin itu akan menjadi tempat yang sepenuhnya salah karena sebagian besar programmer akan muncul untuk memberikan suara.

Sistem skrip visual harus dirancang untuk seniman, bukan pemrogram. Sebanyak yang saya bisa mengeluh tentang ketidaksukaan saya terhadap hal-hal seperti PlayMaker di Unity, kenyataannya adalah para seniman menyukainya. Itu sebabnya ia memiliki hampir 2000 ulasan dan 5 bintang. Jika pemungutan suara adalah untuk memiliki sesuatu yang lebih seperti skrip Construct 2 maka suara saya adalah untuk tidak memiliki skrip visual sama sekali karena saya tidak percaya itu akan menjadi manfaat nyata karena A) Programmer dapat memprogram langsung di GDScript dan B) Banyak artis akan langsung dimatikan olehnya dan pergi ke tempat lain. Saya tahu, karena dua teman seniman saya, yang sama-sama dapat membuat kode, sedang melihat Construct 2 dan mengolok-olok antarmuka pemrograman yang dimilikinya karena hampir sama dengan hanya menulis kode.

Bahasa scripting visual harus sangat visual, tidak banyak kata. Seharusnya tidak terlihat seperti kode pada pandangan pertama. Itu harus disesuaikan dengan "orang visual", jika tidak, tidak ada gunanya membuatnya sejak awal. Artis terbiasa, dan cenderung menyukai, grafik simpul karena memberi Anda gambaran visual tentang apa yang sedang dilakukan program Anda. Sekali lagi, saya sendiri tidak suka grafik simpul karena saya tidak tahan, tetapi saya seorang programmer dan suara saya seharusnya tidak dihitung di area ini.

Saya setuju dengan Anda bahwa itu harus dirancang untuk seniman/desainer.
Tetapi tidak setuju pada logika bahwa kata-kata = kompleksitas.

Jika Anda mendudukkan seseorang untuk mengajari mereka menggunakan salah satu dari keduanya - construct2 akan muncul sebagai yang lebih mudah dari keduanya. Mengapa?
Karena lebih jelas dari node. Jauh lebih jelas. Anda memiliki kondisi dan tindakan. Anda meletakkan yang pertama di sisi kiri dan yang lainnya di sisi kanan.
Untuk menambahkan salah satu dari keduanya, Anda tidak perlu tahu perintah. Mereka semua terdaftar di sana untuk Anda tambahkan - jelas sehari. Masing-masing dilengkapi dengan ikon - yang merupakan petunjuk visual.

Playmaker dan sistem berbasis node lainnya membutuhkan lebih banyak pembelajaran, karena menghubungkan sebuah node ke node lain mengharuskan Anda untuk terlebih dahulu memahami jika Anda dapat menghubungkan keduanya. Ini bukan hanya kondisi--> tindakan. Node jauh lebih kompleks dan kurang petunjuk visual. Di mana Anda melihat ikon di playmaker??
Jauh lebih mudah untuk membuat kesalahan di dalamnya. Jauh lebih sulit untuk membaca logika di dalamnya.
https://www.scirra.com/tutorials/top
Saya juga berpendapat bahwa karena C2 adalah alat pemrograman visual yang dirancang lebih baik, ia memiliki komunitas pengguna aktif yang jauh lebih besar daripada playmaker - meskipun saat ini terbatas pada game 2d. Jumlah video tutorial yang jauh lebih banyak di web (lebih banyak orang yang memahami cara menggunakannya daripada playmaker), proyek yang jauh lebih selesai, pasar dan forum aktif yang sehat, dan yang terpenting, komunikasi aktif antara pengembang dan pengguna. Jadi pengembang tahu apa yang diinginkan pengguna artis.

Pengguna konstruksi dapat dengan mudah mengambil tangkapan layar dari lembar acara mereka dan jelas bagaimana mereka melakukannya. Pergi ke forum lihat sendiri. Saya berpendapat bahwa ia memiliki lebih banyak pengguna daripada playmaker.

Saya berpendapat bahwa dibutuhkan lebih sedikit pekerjaan untuk mengatur logika di dalamnya daripada di sistem berbasis simpul mana pun.

Saya dapat melihat bahwa Anda menyukainya, tetapi setidaknya coba construct2 sebelum menyatakan bahwa itu adalah mesin pemrogram.
Lihatlah forum dan basis pengguna mereka. Ia memiliki rep yang lebih baik daripada playmaker. Itu berhasil mendapatkan reputasi yang baik dengan dirancang dengan baik - sendiri - bukan dengan menjadi plugin untuk mesin yang sudah sukses. Ini adalah alat pemrograman visual murni yang dapat digunakan oleh seniman mana pun. Saya seorang seniman dan saya mencoba playmaker- lebih sulit daripada membangun2. Buka forum C2 dan coba yakinkan mereka bahwa playmaker lebih mudah digunakan - hanya untuk tertawa. :D
Bukankah Anda sendiri seorang programmer? Anda telah berkontribusi pada proyek github lebih dari saya. Bukankah itu berarti Anda tidak boleh membuat pernyataan yang lebih mudah dipelajari?

Saya memahami poin Anda dari sudut pandang seorang programmer. Jika saya harus memilih di antara keduanya, saya akan menggunakan model Construct juga. Namun, seperti yang saya katakan, ini adalah tempat terburuk untuk membuat keputusan ini karena mungkin sebagian besar jika tidak semua orang yang membaca milis GitHub adalah programmer.

Saya telah menghabiskan lebih banyak karir saya di sekitar artis daripada di sekitar programmer. Meskipun saya telah melakukan keduanya secara teratur selama 18 tahun terakhir (dan sangat menyukai keduanya), saya adalah seorang seniman profesional sebelum saya menjadi seorang programmer profesional. Bukannya saya peduli bahwa saya bahkan memiliki gelar, gelar saya adalah Animasi Digital dan Efek Visual. Sejauh pengetahuan saya, iklan yang saya kerjakan masih diputar setelah beberapa tahun di Kansas City. Saya telah mengerjakan pemotretan untuk Hallmark, Sprint, Radio Shack, Honda, dan beberapa lainnya yang mungkin saya lupakan. Saya juga bersenang-senang mengerjakan beberapa bidikan di "World Builder" bersama Bruce Branit.

https://www.youtube.com/watch?v=QP3YywgRx5A
Nathan Warden dalam kredit adalah saya

Saya tidak mengatakan ini untuk menyombongkan diri, saya mengatakan ini untuk menegaskan. Saya bisa saja salah, tetapi sebagai seorang seniman yang telah menghabiskan banyak waktu di sekitar seniman, saya pikir saya tahu apa yang disukai seniman. Mereka cenderung tidak terlalu menyukai hal-hal seperti Konstruktor. Mereka cenderung merasa terintimidasi dan memilih aplikasi yang sama sekali berbeda. Artis pada umumnya memiliki pola pikir yang sangat berbeda dari programmer. Ini seperti ketika saya berbicara dengan teman saya Erik tentang hal-hal teknis yang saya coba ajarkan kepadanya, kata-kata ini sering keluar dari mulutnya, "Nate, saya orang yang sangat visual, jika Anda tidak dapat menunjukkannya kepada saya. secara visual Anda mungkin juga berbicara dengan dinding".

Ada alasan mengapa seniman menikmati hal-hal seperti grafik shader berbasis simpul yang bertentangan dengan sistem shader linier. Mereka dapat memvisualisasikan apa yang terjadi. Saya tidak berpikir saya pernah mendengar seorang seniman mengeluh tentang tidak memiliki sistem shader linier dalam aplikasi 3D favorit mereka, tetapi mereka mengeluh secara teratur ketika mereka tidak memiliki sistem shader berbasis node.

Ada alasan mengapa seniman lebih memilih aplikasi seperti Fusion daripada After Effects. Dalam hampir setiap kasus, mereka akan memilih sesuatu berdasarkan simpul daripada linier karena lebih visual.

Jadi, 2 alasan lagi mengapa sistem berbasis simpul akan menarik bagi seniman:

1) Mereka secara visual terlihat jauh lebih menarik.
2) Ini cocok dengan paradigma desain yang sudah biasa mereka gunakan. IE Shading dan Compositing

Itu benar-benar apa yang terjadi. Jika artis akan melihat dan beralih ke mesin permainan berikutnya karena yang lain memiliki pemrograman berbasis simpul, maka Godot seharusnya tidak memiliki skrip visual sama sekali, karena mungkin tidak akan ada lebih dari segelintir orang. siapa yang akan menggunakannya dan itu berarti lebih banyak pemeliharaan kode sejak saat itu.

Apakah Anda yakin Anda tahu apa itu Construct2? Anda bahkan tidak mengeja namanya dengan benar.
Itu tidak disebut "Konstruktor".

Saya sepenuhnya tidak setuju bahwa kita harus menggunakan node karena "Seharusnya tidak terlihat seperti kode pada pandangan pertama."

Lebih penting seberapa jelas itu daripada tampilannya. Kejelasan apa yang dilakukan logika lebih penting daripada bagaimana tampilan editor pada pandangan pertama. Construct2 tidak terlihat seperti kode- teks ditulis dalam bahasa Inggris dan jelas apa yang dilakukan Tindakan atau Kondisi. Orang yang menggunakan C2 cenderung kebanyakan orang visual juga.

Lembar acara akan selalu menang melawan node- bagaimanapun Anda mencoba membuatnya terlihat. Itu dapat mengemas lebih banyak informasi di layar dengan lebih sedikit menggeser - lebih jelas apa yang dilakukan logika. Dan isyarat visual (ikon) jauh lebih mudah ditemukan oleh mata seniman.
Node tidak memiliki ikon dan batasan teks yang sangat besar.
Jadi dalam banyak kasus, sebuah simpul bahkan tidak menjelaskan apa yang dilakukannya dengan jelas, karena ukurannya yang terbatas - memaksa desain untuk menggunakan terminologi yang tidak jelas alih-alih bahasa Inggris biasa.

Poin lain:
Lembar acara dibaca dan dieksekusi dari atas ke bawah. Ini jelas dan dapat diprediksi.
Dengan jaringan simpul, mata Anda akan melakukan perjalanan ke mana-mana, mereka terpecah menjadi cabang-cabang. Ini menjadi jauh lebih rumit.

Cerita opini orang ketiga pada pandangan pertama dan bukan pengalaman pengguna yang sebenarnya tidak boleh terlalu berat di sini. Saya juga orang yang sangat visual, tetapi yang telah menggunakan banyak mesin skrip visual. Sungguh menyakitkan melihat orang membuat argumen tanpa menggunakan mesin yang sebenarnya untuk sementara waktu - dengan proyek kecil misalnya.

Saya mendorong desainer/pengembang/orang visual godot untuk benar-benar mencoba mesin ini pada proyek skala kecil dan kemudian sampai pada kesimpulan. Cukup cerita pihak ketiga ini. Kami membutuhkan penelitian langsung dan kasus yang dinyatakan secara logis mengapa yang satu lebih baik dari yang lain. Percaya atau tidak, orang visual juga punya akal sehat.

Keluar topik:
Pada contoh Fusion vs After Effects - orang lebih memilih pendekatan berbasis node untuk compositing, karena menggunakan lapisan bisa menjadi sangat rumit pada adegan yang rumit di mana efek yang sama dapat diduplikasi pada banyak lapisan. Dengan node, Anda dapat memiliki lebih banyak fleksibilitas dalam hal pengomposisian dan hanya menghubungkan satu efek ke banyak lapisan. Tetapi node lebih rumit daripada layer.

Saya setuju dengan Anda di hampir semua poin, tetapi poin-poin itu masih dari sudut pandang seorang programmer. Jika saya harus menggunakan sistem skrip visual sepanjang hari, saya akan memilih yang paling mirip dengan kode biasa. Itu sebabnya saya penggemar berat mengajar anak-anak yang ingin belajar cara memprogram menggunakan code.org. Saya benar-benar penggemar gaya. Ini bagus untuk mengajar orang yang "ingin" memprogram cara memprogram.

Dan ya, saya mengatakan Membangun salah, maaf. Tidak, saya tidak menggunakannya secara pribadi. Tapi, itu tidak masalah karena paradigma scripting yang digunakannya bukanlah konsep baru, jadi argumen saya bahkan bukan tentang Construct itu sendiri. Ini tentang gaya skrip yang berkaitan dengan seniman, bukan programmer.

Dalam sistem berbasis node Anda dapat memiliki beberapa kondisi dan peristiwa dan fungsi yang terkandung dalam setiap node. Anda kemudian dapat memberi nama node seperti Input, misalnya. Di dalamnya akan berisi semua input joystick dan pengguna akan memberi tahu acara apa yang akan digunakan. YAITU. mereka akan menentukan acara seperti "Api". Peristiwa itu akan menyebabkan transisi ke simpul mana pun yang mereka kaitkan.

Berikut adalah contoh sederhana yang bisa Anda miliki pada senjata yang hanya akan menangani penembakan. Perhatikan bahwa meskipun sederhana, ini juga kuat dan tidak terlihat seperti kode:

Pada catatan terakhir, Anda dapat membuat skrip berbasis blok atau skrip berbasis simpul keduanya terlihat cukup bagus dari sudut pandang antarmuka, jadi saya tidak akan membuang waktu untuk berdebat tentang hal itu.

Namun, ketika saya mengatakan "Seharusnya tidak terlihat seperti kode pada pandangan pertama." Banyak seniman peduli tentang apa yang akan mereka lihat sepanjang hari setiap hari untuk waktu yang tidak terbatas. Mereka akan menolak seluruh aplikasi jika tidak terlihat menarik atau terlihat menakutkan. Saya akan mengatakan blok berbasis terlihat mengintimidasi dan membingungkan artis khas. Sepertinya sesuatu untuk programmer, dan memang begitu.

@blurmind ,

Node grafik sebenarnya berasal dari UML konseptual. Anda membuat representasi grafis dari kode dengan cara yang dapat dipahami oleh audiens non-pemrograman (manajer proyek, konsumen, artis). Inilah yang digunakan UE4/Unity. Ini adalah sesuatu yang semua orang di industri ini sadari. Konstruktor biasanya mengambil pendekatan yang berbeda, dan seberapa bagus pendekatan ini - tidak ditentukan oleh jumlah pengguna yang menggunakannya.

Selalu ada kurva belajar di mana-mana, dan Construct2 tidak terkecuali. Tapi jangan memaksakan hal-hal C2 ke Godot tanpa mendukung argumen. Lembar acara akan menjadi lebih panjang dengan permainan yang lebih kompleks, dan akhirnya membuang lebih banyak ruang daripada simpul grafik. Hanya tombol "Tambahkan tindakan" yang memiliki barisnya sendiri. Ini pada dasarnya bagaimana seorang programmer akan menafsirkan blok kode. Jadi itu tidak terlalu buruk.

Saya pribadi tidak mengerti mengapa kami tidak dapat memiliki keduanya, tetapi para pengembang sudah memiliki cukup untuk melakukannya sehingga itu tidak akan terjadi dalam waktu dekat. Inilah mengapa saya mengusulkan pendekatan berbeda yang akan berkembang lebih cepat, cukup banyak didorong oleh non-programmer yang bekerja sama dengan programmer.

Berikut adalah contoh yang lebih baik untuk menunjukkan bahwa Anda dapat memiliki lebih dari satu peristiwa per node. Perhatikan juga bahwa setiap node (atau status) adalah non-blocking, sehingga akan memungkinkan grafik node lain untuk berjalan secara bersamaan:

Tapi lihat, hanya dengan melihat tangkapan layar Anda, saya tidak tahu apa yang dilakukan logika itu. Apa itu "firePrimary" dan "fireSecondary" ??
Sekarang gulir ke atas ke tangkapan layar yang saya posting dari construct2.
Pada construct2 kondisi di sebelah kiri akan terbaca "di tekan "R" atau sesuatu yang dalam bahasa Inggris sederhana - dengan ikon keyboard di sebelahnya!

Tunjukkan keduanya kepada seorang seniman dan tanyakan kepada mereka mana yang lebih jelas.

Tunjukkan pada kami penyiapan simpul yang lebih rumit juga :) Tangkapan layar C2 menunjukkan seluruh logika permainan. Acara Anda hanya satu. Bisakah Anda memasukkan logika yang sama dalam satu tangkapan layar dengan node? Saya tidak berpikir begitu.

Lihat contoh simpul yang mengaburkan informasi.
Anda harus memilih simpul untuk melihat apa yang ada di dalamnya.
Itu menggunakan terminologi programmer yang tidak jelas daripada bahasa manusia ("Kirim acara", "Simpan hasil" apa-apaan ini?).
Construct2 menunjukkan semuanya di satu tempat dan dapat dimengerti oleh orang-orang yang bukan programmer. Inti dari pemrograman visual adalah untuk menghilangkan kebutuhan untuk mempelajari terminologi.

Saya bukan seorang pemrogram. Saya tidak punya pengalaman dalam menulis kode yang sebenarnya. Namun saya dapat membuat game dengan construct2 dengan mudah dan bagi saya menggunakan node jauh lebih sulit - jika menyangkut game yang lengkap.

Saya mengerti bahwa setiap orang akan selalu memilih apa pun yang mereka sudah tahu bagaimana melakukannya dengan baik. Tetapi seperti yang Anda akui- Anda adalah seorang programmer dan belum pernah menggunakan C2. Dan saya tetap menyatakan bahwa saya adalah seorang seniman tanpa pengalaman pengkodean- yang telah menggunakan pendekatan node dan C2.

Saya memberi Anda argumen logis yang bagus tentang mengapa menggunakan satu di atas yang lain.
Anda memberi saya pernyataan seperti "node lebih visual" dan "tidak nyata menggunakan node". Itu adalah pernyataan beropini. Dan Anda berdua mengaku sebagai programmer.

Memberitahu saya bahwa saya tidak mendukung argumen saya hanyalah konfirmasi bahwa Anda tidak memiliki keinginan untuk melihat ke construct2 atau mempertimbangkan desainnya sebagai alternatif untuk node. Sayangnya membuang-buang waktu saya untuk meyakinkan Anda sebaliknya.

@TheoXD
Saya cukup setuju dengan Anda jika saya membaca Anda dengan benar. Akan lebih baik jika keduanya sebagai plugin/modul terpisah. Jadi, di bawahnya adalah GDScript yang sebenarnya, tetapi Anda dapat memvisualisasikannya menggunakan apa pun yang Anda inginkan. Saya pikir ini mungkin. Pendekatan berbasis node mungkin memerlukan beberapa tanda seperti komentar khusus untuk memisahkan node (IE. #node name="Input" dan #endnode), tetapi bukan masalah besar karena akan otomatis jika Anda memulai dengan grafik node. Saya pikir pendekatan blok akan lurus ke depan.

Apakah hal seperti itu yang Anda maksud?

Seperti yang saya katakan di atas, saya sangat menyukai metode block/Construct/code.org karena bekerja dengan sangat baik untuk mengajar pemrograman. Saya hanya tidak berpikir itu cocok untuk orang yang melihat pemrograman sebagai kejahatan yang perlu.

@blurmind
Alasan mengapa itu tidak masuk akal adalah karena Anda tidak terbiasa dengannya. Ketika saya melihat gambar Konstruksi di atas, saya sama-sama tidak tahu apa yang terjadi, bukan karena itu buruk, tetapi karena saya tidak terbiasa dengannya.

Sejauh tidak dapat melihat apa yang ada di bawah sebuah simpul sampai Anda mengkliknya, setelah Anda menyiapkan sebuah simpul, tidak ada gunanya memilah-milah apa yang sudah Anda ketahui ada di sana. Saya sudah tahu bahwa saya memiliki klik kiri dan kanan dan mereka menembakkan amunisi primer dan sekunder. Saya sudah tahu apa yang dilakukan node api primer dan sekunder. Itu tidak berubah sejak saya membuatnya, mengapa saya harus melihat detailnya setiap kali saya melihatnya? Jadi, sekarang logika yang mendasarinya hanyalah kekacauan. Ini adalah alasan lain mengapa node lebih ramah artis dan non-programmer. Mereka dapat memecah logika spesifik mereka menjadi potongan yang lebih umum. Itu membuatnya agar mereka bisa mendapatkan tampilan gambar besar dan hanya khawatir tentang detail ketika mereka benar-benar membutuhkannya.

Saya sedang melihat proyek aktual untuk game seluler aktual yang diterbitkan sekarang dan hampir setiap grafik simpul paling banyak 2 hingga 4 simpul, jadi sulit untuk menunjukkan kepada Anda pengaturan yang lebih rumit ketika Anda biasanya tidak memerlukan pengaturan yang rumit.

Jika Anda ingin menguraikannya, ini dari aplikasi yang sama yang ditulis oleh orang yang sama-sama non-programmer. Ini adalah salah satu grafik paling kompleks dalam game. Ini mengontrol gerakan pemain utama:

(Hal lain yang tidak dapat Anda lakukan dengan balok adalah membuatnya terlihat seperti kapal Samus, haha)

Tanpa disuruh, saya hanya memasang gambar Construct2 Anda di satu layar dan meletakkan grafik simpul di atas di sisi lain dan bertanya kepada istri saya (yang jelas bukan seorang programmer), "Yang mana yang ingin Anda gunakan jika Anda harus menggunakannya? setiap hari?", Dan dia menunjuk ke grafik simpul dan berkata, "Yang ini". Saya tahu itu tidak pasti, tetapi fakta bahwa itu tidak terlalu mengintimidasi berarti saya memiliki lebih banyak kesempatan untuk mulai membuatnya mempelajarinya. Jika itu terlihat mengintimidasi, dia mungkin akan mematikan otaknya bahkan sebelum saya membuatnya duduk untuk mempelajari dasar-dasarnya.

Tanpa mendorongnya ke satu atau yang lain, saya juga bertanya kepada teman artis saya kemarin (orang yang sama yang mengerjakan ketiga game Age of Empires), yang telah berkecimpung di industri game selama hampir 20 tahun sekarang, (dan yang telah menggunakan Construct2) apa yang dia pikir akan disukai artis lain dan dia juga mengatakan grafik simpul.

Pokoknya, saya sangat menikmati diskusi tetapi tidak ada gunanya mengalahkan kuda mati, haha ​​:)

Ya saya juga menikmatinya. Tidak ada firasat buruk :)

Kapal Samus yang Luar Biasa btw. Semakin banyak gambar yang Anda posting, semakin Anda mendukung kasus saya bahwa node secara visual lebih sulit untuk diikuti karena mereka dapat membelah cabang dan menuju ke arah yang gila.
Bagi saya, kerumitan tambahan karena harus mengikuti garis dan panah di antara balok selalu terasa seperti pekerjaan ekstra. Saya kira saya harus mencoba node lagi suatu hari nanti. Jika itu di mana godot akan menuju.

Sekali lagi Anda memberi kami cerita orang ketiga yang tidak benar-benar didukung oleh bukti. Dapatkan pria di sini dan minta dia memberi tahu kami MENGAPA dia lebih suka satu untuk yang lain :)
Maka Anda akan memiliki kasus yang lebih kuat. Saya tidak mendapatkan poin logis yang mendukung tesis bahwa node lebih mudah sejauh ini.

ya itu terlihat kurang menakutkan pada pandangan pertama karena menyembunyikan banyak informasi. Contoh Anda jauh lebih sederhana daripada yang ditunjukkan pada tangkapan layar yang saya posting. Ini menyesatkan.
Berikut adalah video yang menunjukkan panas untuk mengatur logika untuk platformer di C2.
https://www.youtube.com/watch?v=5RlSmkSbleI
lewati menit pertama :P

Jangan membandingkan apel dengan jeruk.
Code.org adalah pendekatan yang sangat berbeda dari Construct2 - lebih mirip Stencyl dan memiliki salah satu kelemahan node: Kondisi dan tindakan Anda tidak dipisahkan dengan jelas - jadi lebih sulit untuk mengetahui apa yang dapat Anda lampirkan ke apa. Alat pemrograman visual yang dirancang dengan baik (Multimedia fusion, construct2, gamedevelop) semua kondisi terpisah dari tindakan dengan jelas bagi pengguna. Ini membuatnya lebih mudah untuk membangun logika karena mereka diatur untuk Anda oleh perangkat lunak yang menebak apa yang mungkin Anda butuhkan dan menunjukkannya kepada Anda pada waktu yang tepat. itu juga mencegah Anda membuat kesalahan konyol.

Dengan node/stencyl/code.org Anda harus mencari tahu bagian mana yang merupakan kondisi, mana yang merupakan tindakan. Dibutuhkan lebih banyak pemikiran untuk mengatur kondisi Anda dengan cara yang benar. Jenis informasi apa yang keluar dari sebuah simpul? Dibutuhkan lebih banyak node untuk mengatur kondisi beberapa kali - lebih banyak belajar bagaimana menghubungkannya.
Ayo, lakukan riset Anda dan gunakan alat lain sebentar. Melihat semua yang bukan simpul sebagai lebih sama tidak membantu.

@blurymind , kasus Anda sejauh ini didukung oleh jumlah pengguna yang menggunakan Construct2, yang biasanya merupakan hasil dari model bisnis perangkat lunak dan seberapa baik mereka dalam pemasaran. Preferensi pribadi (argumen logis Anda) tidak cukup untuk memaksa alur kerja C2 ke Godot. Tapi itu referensi yang bagus.

Jika Anda akan menunjukkan kepada seseorang bagaimana Anda ingin membangun permainan Anda (hubungan objek-objek) di atas kertas atau papan tulis, bagaimana Anda akan menunjukkannya? Dengan menulis pohon acara? Tidak. Anda akan menggambar tampilan konseptual dengan simpul dan garis, lalu menganggapnya sebagai kelas, menambahkan fungsi, anggota..
Saya setuju bahwa tabel acara lebih mirip kode, hanya ditafsirkan oleh seorang programmer, dan itu dapat membuat pengguna ingin mempelajari pemrograman yang sebenarnya saat mereka maju. Saya perhatikan itu memiliki beberapa terminologi dan kurva pembelajaran juga, Anda tidak dapat menyangkalnya. Tapi pengenalan bentuk dan pengelompokan objek sebenarnya adalah hal yang nyata. Saya mempelajari kursus tentang visualisasi data, dan selain itu mungkin membosankan - itu benar-benar membuat poin bagus.

Meskipun saya ingin melihat masalah ini mencetak lebih dari 100 komentar, pengembang tidak akan membaca semuanya, hal terbaik yang dapat kita lakukan adalah membuat PDF dengan proposal, dan membagikannya di milis. Saya tidak mengerti mengapa kita tidak dapat memiliki level abstraksi yang berbeda, Graph node sebagai level teratas, yang dapat direpresentasikan dalam bentuk pohon peristiwa. Jika ini berhasil maka tidak perlu berkompromi.

" @blurymind -- || -- Dan kalian berdua mengaku sebagai programmer." - Saya tidak menganggap diri saya hanya seorang programmer, melakukan seni juga lho. Saya menggunakan pengalaman saya untuk melihat sesuatu dari sudut pandang objektif.

Saya tidak yakin apakah itu terlewatkan, tetapi saya juga bukan hanya seorang programmer, tetapi juga seorang seniman profesional. Saya pikir sebagian besar programmer akan benar-benar mendapat manfaat dengan terjun ke seni untuk sementara waktu. Itu membuat pemrograman hal-hal tertentu lebih masuk akal dan juga membantu menjembatani persaingan programmer/artis, haha ​​:) Saya tahu ini lebih ideal, dan tidak begitu praktis bagi kebanyakan orang.

Berikut adalah beberapa tautan ke beberapa pekerjaan saya (cari Nathan Warden di kredit)

World Builder (terlibat dalam sekitar setengah dari tembakan)
https://www.youtube.com/watch?v=VzFpg271sm8

Teddy Scares (terlibat dalam sebagian besar pemotretan)
https://www.youtube.com/watch?v=qCXIzS_iY0k

Hallmark Crown Center (Tembakan ketiga dengan Santa)
https://www.youtube.com/watch?v=biqBq3_Whqk

Berikut adalah render dari bangunan Louie saya. Jika Anda menonton World Builder, Anda akan melihat beberapa karya seni yang saya sobek dan masukkan ke dalam film.

Dan inilah render yang belum selesai dari HK Tank gaya Terminator 1 yang menghancurkan Christine Stephen King. Kedua model itu dibuat oleh saya, tapi saya rasa tidak ada hal lain dalam bidikan itu.

Dan banyak lagi yang bisa saya sebutkan, tapi saya pikir intinya sudah dibuat. :)

Itu adalah gambar diam yang luar biasa - tetapi sekali lagi Anda melakukan ini untuk memberi diri Anda lebih banyak otoritas. Ini tidak membantu secara logis mendukung gagasan bahwa Node lebih baik daripada lembar Acara :)

Jika Anda menggunakan node, Anda akan seperti mesin game 3d sialan lainnya di luar sana yang menggunakan pemrograman visual.

Saya pikir ini bukan ide bagus karena beberapa alasan.

-Baru-baru ini Unreal membuat mesin mereka gratis - ini juga multiplatform. Ini adalah mesin yang jauh lebih matang daripada BGE/Godot. Jadi, Anda bersaing dengan mereka secara langsung saat menyalin pendekatan mereka terhadap pemrograman visual.

-Node jauh kurang efisien layar daripada lembar logika. Mereka lebih sulit untuk dibaca/diikuti.

-Scirra mengumumkan bahwa construct3 akan multiplatform - editor akan bekerja pada windows, linux dan mac.
Namun mereka bukan open source.
https://www.construct3.com/

Ini menciptakan gelombang komentar di komunitas scira. Banyak pengguna menginginkan sejumlah hal yang dapat ditawarkan godot tanpa pemrograman visual:
-File exe asli alih-alih wadah html5 - untuk kinerja yang lebih baik
-dukungan untuk pengembangan game 3d, menggunakan gaya lembar acara dalam konstruksi untuk memprogramnya:
https://www.scirra.com/forum/construct-3_t90881

jika mereka membuat editor 3D yang sederhana dan mudah dipahami seperti alat 2D di dalam C2, saya akan benar-benar menggunakannya

saya mencoba unity, blender, torsi 3D, UDK, karena mereka lebih banyak diiklankan dan yang paling banyak digunakan oleh pengembang terkenal ... dan mereka berbagi masalah yang sama: mereka tidak ramah pengguna (sama sekali) dan jika Anda tidak pernah menggunakan api pembuatan game 3D sebelumnya ... yah, Anda 3Doomed (bad joke ikno)

masalahnya, konstruksi sangat intuitif setelah Anda menutupi dasar dan memberi Anda kebebasan untuk membuat game 2D yang kompleks, itu memberi Anda berbagai jalur untuk melakukan hasil yang sama (belum lagi sistem acara MAKE SENSE bagi saya); yang merupakan detail sebagian besar alat lain ini gagal menutupi atau membuatnya buruk

jika mereka membuat mesin 3D dengan aliran dan perasaan yang sama seperti saya menggunakan C2; lalu mengapa tidak mencobanya?

Mereka memiliki basis pengguna yang besar saat ini (yang menyukai gaya lembar acara untuk pemrograman visual, tetapi menginginkan fitur ini) dan beberapa di antaranya siap untuk melompat ke mesin lain. Ada potensi besar di sini bagi Godot untuk mendapatkan banyak pengembang indie baru - yang lebih suka ini daripada node- yang tidak menggunakan mesin Unreal- yang sekarang gratis dan jauh lebih matang daripada godot.

Jika Anda menggunakannya sebagai ganti node, Anda akan menjadi mesin pertama yang mendukung pengembangan game 3d penuh dengan desain pemrograman tersebut. Anda akan memasuki basis pengguna baru, alih-alih bersaing dengan Unreal (gratis), Unity (versi gratis tersedia)

Itu adalah gambar diam yang luar biasa - tetapi sekali lagi Anda melakukan ini untuk memberi diri Anda lebih banyak otoritas.

Gambar dan tautan bukan bukti otoritas saya, tetapi orang-orang yang pernah bekerja dengan saya dan saya tidak hanya mengada-ada :) Ini termasuk beberapa teman baik saya yang mengerjakan beberapa film yang mungkin pernah Anda dengar Avatar, King Kong, Serenity, dan acara seperti Lost, Revolution, dll... Dan beberapa teman saya yang telah bekerja di industri game selama lebih dari 15 tahun. Semuanya lebih memilih alur kerja berbasis simpul daripada alur kerja linier berbasis lembar. Saya mungkin bisa mendapatkan kutipan dari 3-4 dari mereka yang memberi tahu Anda bahwa mereka lebih suka grafik simpul daripada lembar logika jika Anda mau?

Baru-baru ini Unreal membuat mesin mereka gratis - ini juga multiplatform. Ini adalah mesin yang jauh lebih matang daripada BGE/Godot. Jadi, Anda bersaing dengan mereka secara langsung saat menyalin pendekatan mereka terhadap pemrograman visual.

Alur kerja skrip visual adalah hal terakhir yang akan dilihat orang ketika membandingkan Godot dengan mesin tersebut. Hal pertama yang akan mereka perhatikan adalah bahwa Unreal mendukung DirectX 12 dan OpenGL 4 dan demo serta contoh mereka terlihat menakjubkan, kemudian mereka akan mulai melihat hal-hal lain. Hal utama yang dimiliki Godot atas perusahaan-perusahaan itu adalah perangkat lunak FLOSS dan siapa pun yang menggunakannya sama-sama pemilik penuh perangkat lunak tersebut.

Node jauh kurang efisien layar daripada lembar logika. Mereka lebih sulit untuk dibaca/diikuti.

Meskipun jelas dengan pernyataan Anda bahwa Anda belum menggunakan pengaturan berbasis simpul yang baik, jika Anda khawatir tentang hal-hal seperti efisiensi layar maka Anda tidak boleh menggunakan skrip visual, Anda harus menggunakan skrip asli yang sudah tersedia :) Saya menjamin Anda bahwa skrip visual apa pun dapat menawarkan Anda dalam hal ruang layar, skrip biasa juga dapat melakukannya, seperti menciutkan wilayah kode.

Jika Anda menggunakannya sebagai ganti node, Anda akan menjadi mesin pertama yang mendukung pengembangan game 3d penuh dengan desain pemrograman tersebut.

Ada alasan mengapa mesin seperti Unreal yang menghabiskan banyak waktu, uang, dan penelitian tentang kebutuhan pelanggan mereka tidak menggunakan bentuk skrip visual dan memilih node sebagai gantinya.

Pandangan saya tentang ini adalah bahwa itu semua tergantung pada pendekatan yang ingin dilakukan
terpecahkan.

Blok aksi seperti Game Maker memang menarik, tapi menurut saya lebih dari itu
dirancang untuk menggantikan pemrograman.

Pendekatan Unreal lebih seperti pelengkap pemrograman jadi
desainer dapat bekerja dalam game sendiri dan mengambil pekerjaan dari
programmer. Ini jauh lebih berguna dalam tim (Artis dan desainer Game
dapat menggunakannya dengan baik) dan jelas merupakan pendekatan yang ingin saya tambahkan
Godot karena untuk ini.

Karena arsitektur Godot, itu juga akan sangat mudah untuk ditambahkan jadi saya akan memberikan
itu tembakan di 1.2

Pada Selasa, 3 Maret 2015 pukul 16.37, [email protected] menulis:

Yah, itu adalah gambar diam yang luar biasa - tetapi sekali lagi Anda melakukan ini untuk memberi
diri Anda lebih otoritas.

Gambar diam dan tautan bukanlah bukti otoritas saya tetapi orang-orang yang saya miliki
bekerja dengan dan bahwa saya tidak hanya mengada-ada :) Ini termasuk beberapa dari saya
teman baik yang mengerjakan beberapa film yang mungkin pernah Anda dengar seperti
Avatar, King Kong, Serenity, dan acara seperti Lost, Revolution, dll... Dan
beberapa teman saya yang lain yang telah bekerja di industri game selama lebih dari 15
bertahun-tahun. Semuanya lebih memilih alur kerja berbasis simpul daripada linier, berbasis lembar
alur kerja. Saya mungkin bisa mendapatkan kutipan dari 3-4 dari mereka yang memberi tahu Anda itu
mereka lebih suka grafik simpul daripada lembar logika jika Anda mau?

Baru-baru ini Unreal membuat mesin mereka gratis - ini juga multiplatform. Ini adalah sebuah
mesin jauh lebih matang dari BGE/Godot. Jadi Anda bersaing dengan mereka
langsung ketika menyalin pendekatan mereka ke pemrograman visual.

Alur kerja skrip visual adalah hal terakhir yang akan dilakukan orang
melihat ketika membandingkan Godot dengan mesin-mesin itu. Hal pertama yang akan mereka lakukan
perhatikan adalah bahwa Unreal mendukung DirectX 12 dan OpenGL 4 dan demo mereka
dan contoh terlihat menakjubkan, maka mereka akan mulai melihat hal-hal lain.
Hal utama yang dimiliki Godot atas perusahaan-perusahaan itu adalah FLOSS
perangkat lunak dan bahwa siapa pun yang menggunakannya sama-sama pemilik penuh dari
perangkat lunak.

Node jauh lebih hemat layar daripada lembar logika. Mereka lebih sulit untuk
baca/ikuti.

Meskipun jelas dari pernyataan Anda bahwa Anda belum menggunakan simpul yang baik
pengaturan berbasis, jika Anda khawatir tentang hal-hal seperti efisiensi layar maka Anda
seharusnya tidak menggunakan skrip visual, Anda harus menggunakan yang asli
scripting yang sudah tersedia :) Saya jamin apa saja
skrip visual dapat menawarkan Anda dalam hal ruang layar skrip reguler
dapat melakukannya juga, seperti menciutkan wilayah kode.

Jika Anda melakukannya alih-alih node, Anda akan menjadi mesin pertama yang
mendukung pengembangan game 3d penuh dengan desain pemrograman vis itu.

Ada alasan kenapa mesin seperti Unreal yang menghabiskan banyak waktu, uang
dan penelitian tentang kebutuhan pelanggan mereka tidak sesuai dengan bentuk
scripting visual dan memilih node sebagai gantinya.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -77017857.

Saya mencoba Playmaker dengan baik dan harus mengatakan bahwa saya menyukainya - lebih dari kismet/blueprint yang tidak nyata.

Di playmaker node adalah semacam wadah tempat Anda menempatkan tindakan. Beberapa tindakan adalah Memeriksa kondisi yang dapat mengarah ke node lain.

Karena Anda membuat wadah simpul sendiri dan dapat menamainya, tindakan di dalamnya dieksekusi dengan cara yang dapat diprediksi (atas ke bawah) - itu adalah sesuatu yang dapat saya jalani. :)

Juga tindakan yang Anda tempatkan di dalam simpul sebenarnya adalah skrip kesatuan standar dengan input visual. Jadi orang akan dapat menulis skrip mereka sendiri dan menambahkannya sebagai tindakan khusus.

Silakan lihat playmaker dan implementasikan sistem berbasis node yang lebih mirip dengannya, daripada Unreal.
Keuntungannya tentu saja kita dapat melakukan lebih banyak dengan lebih sedikit node, mereka lebih mudah dibaca dan di-debug, dan lebih dapat diprediksi.

Berikut adalah pengenalan cara kerjanya:
https://www.youtube.com/watch?v=I9VwsVtbgFU&index=2&list=PLC759306A1E692A10

Ini sangat fleksibel dan memungkinkan pengguna untuk menambahkan dan berbagi fungsionalitas game dengan mudah - mudah digunakan kembali.

Diskusi yang menarik. Hanya ingin menunjukkan jenis/bentuk lain dari skrip visual selain node dan lembar acara C2 tetapi blok skrip yang cocok bersama seperti potongan puzzle. Digunakan dalam mesin 2d Stencyl http://www.stencyl.com/

berdasarkan MIT Scratch http://wiki.scratch.mit.edu/wiki/Wait_Until_ ()_(block)

dan di Unity saya pribadi menggunakan, Blox http://www.plyoung.com/blox/

Saya pribadi tidak yakin dengan pemrograman "visual" seperti awal. Saya
pikir itu cukup banyak seperti pemrograman.
Cara Unreal melakukan ini menurut saya ramah untuk desainer game/level

Pada Sabtu, 21 Maret 2015 pukul 23.57, todheil [email protected] menulis:

Diskusi yang menarik. Hanya ingin menunjukkan jenis/bentuk visual lainnya
skrip selain node tetapi blok skrip yang cocok bersama seperti
potongan teka-teki. Digunakan dalam mesin 2d Stencyl http://www.stencyl.com/
[gambar: stencyl_blocks]
https://cloud.githubusercontent.com/assets/8675463/6767767/d52e7b16-d013-11e4-878c-29002dc04f8e.PNG
berdasarkan MIT Scratch
http://wiki.scratch.mit.edu/wiki/Wait_Until_ ()_(blok)
[gambar: awal_contoh]
https://cloud.githubusercontent.com/assets/8675463/6767792/57f50e5c-d014-11e4-8015-9228bb6001d8.PNG
dan di Unity saya pribadi menggunakan, Blox http://www.plyoung.com/blox/
[gambar: hello_blox]
https://cloud.githubusercontent.com/assets/8675463/6767796/7849f46a-d014-11e4-9244-9e45c601f883.PNG

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -84508001.

_OkamStudio_

Poin bagus. Bagi saya blok adalah jalan tengah antara baris kode dan diagram alur.

Saya tidak suka cara awal/stencyl pemrograman visual. Tata letaknya adalah
secara visual lebih sulit untuk diikuti daripada blok construct2 dan bahkan node. Dia
benar-benar menyusun potongan puzzle dan itu menderita masalah
mencari tahu bagian mana yang cocok di mana. Mereka tidak mudah untuk menempatkan
bersama

Pada hari Minggu, 22 Maret 2015 pukul 05.46, todheil [email protected] menulis:

Poin bagus. Bagi saya blok adalah jalan tengah antara baris kode dan aliran
grafik.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -84511415.

ok, saya tidak akan membaca semuanya sekarang, tetapi hanya 2 sen saya tentang topik ini.

mesin berbasis acara dibuat untuk membuat prototipe dan proyek game kecil
mesin seperti godot diciptakan untuk membuat semua jenis proyek

Jadi mereka adalah dua hal yang berbeda dengan dua pendekatan yang berbeda, mereka adalah dua
tol berbeda

sejujurnya, saya tidak bisa menggunakannya dengan baik. (biaya berdasarkan acara)

Bagi saya pendekatan yang lebih baik adalah dua tol paralel.

2015-03-22 6:49 GMT-03:00 Todor Imreorov [email protected] :

Saya tidak suka cara awal/stencyl pemrograman visual. Tata letaknya adalah
secara visual lebih sulit untuk diikuti daripada blok construct2 dan bahkan node. Dia
benar-benar menyusun potongan puzzle dan itu menderita masalah
mencari tahu bagian mana yang cocok di mana. Mereka tidak mudah untuk menempatkan
bersama

Pada hari Minggu, 22 Maret 2015 pukul 05.46, todheil [email protected] menulis:

Poin bagus. Bagi saya blok adalah jalan tengah antara baris kode dan aliran
grafik.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -84511415.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -84575752.

David Aguiar de Aquino Paiva

satu-satunya hal yang akan berguna adalah "perilaku" sistem kesatuan,
pada dasarnya ini adalah skrip yang membuat sesuatu, jadi ini di godot akan
translate sebagai kemungkinan untuk menambahkan lebih dari satu skrip per node.
Tentu saja, saya dapat membuat simpul dan hanya mengkloningnya, tetapi skrip akan menjadi
sumber daya dan kemudian hanya memuatnya ke simpul dan menambahkan perilaku (untuk
contoh, skrip lompat)
Di editor kita bisa melihat ekspor yang dikategorikan di bawah nama skrip.

2015-03-26 13:15 GMT-03:00 David Paiva [email protected] :

ok, saya tidak akan membaca semuanya sekarang, tetapi hanya 2 sen saya tentang topik ini.

mesin berbasis acara dibuat untuk membuat prototipe dan proyek game kecil
mesin seperti godot diciptakan untuk membuat semua jenis proyek

Jadi mereka adalah dua hal yang berbeda dengan dua pendekatan yang berbeda, mereka adalah dua
tol berbeda

sejujurnya, saya tidak bisa menggunakannya dengan baik.

Bagi saya pendekatan yang lebih baik adalah dua tol paralel.

2015-03-22 6:49 GMT-03:00 Todor Imreorov [email protected] :

Saya tidak suka cara awal/stencyl pemrograman visual. Tata letaknya adalah

secara visual lebih sulit untuk diikuti daripada blok construct2 dan bahkan node. Dia
benar-benar menyusun potongan puzzle dan itu menderita masalah
mencari tahu bagian mana yang cocok di mana. Mereka tidak mudah untuk menempatkan
bersama

Pada hari Minggu, 22 Mar 2015 jam 05.46, todheil [email protected]
menulis:

Poin bagus. Bagi saya blok adalah jalan tengah antara baris kode dan aliran
grafik.

—
Balas email ini secara langsung atau lihat di GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment -84511415
.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -84575752.

David Aguiar de Aquino Paiva

David Aguiar de Aquino Paiva

Hai teman-teman! Diskusi yang bagus ada di sini :) Saya ingin menambahkan sesuatu.

Hal pertama: Saya mahasiswa seni tetapi pemrograman adalah hobi saya. Saya tahu Java, Python dan (favorit saya) Golang. Tetapi sebelum saya mempelajari cara membuat kode (sekitar 3 tahun yang lalu) saya mencoba hampir setiap program yang mengklaim dapat "membuat game tanpa pemrograman". Semua klaim ini adalah omong kosong.

Saya mencoba (tanpa urutan tertentu): Click & Play, GameMaker, The Games Factory, Multimedia Fusion, Construct 1, RPG Maker, Stencyl, BGE dan beberapa lainnya yang bahkan saya tidak ingat. Dan pendapat saya adalah: Anda dapat membuat game tanpa _writing_ code tetapi tidak tanpa _programming_. Bahkan jika Anda menggunakan lembar acara atau node, Anda masih perlu memahami _logika pemrograman_. Anda harus tahu apa itu conditional, event, variabel, string dll. Jadi tidak mungkin membuat game tanpa pemrograman. Semua metode visual pengkodean itu hanyalah cara berbeda untuk mengekspresikan logika yang ada dalam bahasa pemrograman tradisional. Seluruh argumen ini mungkin tampak jelas tetapi saya yakinkan Anda, saya tidak jelas bagi saya di awal petualangan saya dengan pemrograman.

Dari sini mengikuti pertimbangan saya berikutnya:

Bahasa pemrograman visual terbaik dan paling intuitif yang pernah saya temukan sebelum saya mempelajari cara membuat kode adalah cara Scrach/Stencyl puzzle/blocks. Inilah alasannya:

• solusi ini paling dekat dengan pemrograman tradisional. Sebenarnya itu hanya sesuatu seperti gula sintaksis untuk kode yang mendasarinya (pada dasarnya begitulah cara kerja Stencyl) Bagi saya ini lebih bersih dan lebih mudah untuk mengikuti atau membuat sesuatu yang terlihat seperti kode mewah yang berwarna-warni daripada grafik simpul atau lembar acara yang berantakan yang tidak dapat Anda letakkan menjadi struktur yang bagus seperti fungsi. Bagi saya _ini_ berantakan
  Ingat ini hanya pendapat saya

*Saya pikir blok Scrach/Stencyl adalah metode yang paling visual dan mudah diikuti. Mereka menggunakan warna secara ekstensif (dan orang yang berpikiran visual menyukai warna) Sangat mudah untuk diingat bahwa kuning = kondisional dan loop, hijau = matematika, biru = variabel dll. Juga terlihat seperti kode nyata (berbeda dengan node) tetapi lebih ramah.

Akhirnya saya tidak berpikir pemrograman visual harus menjadi prioritas dalam waktu dekat. Ada banyak hal yang lebih penting untuk dilakukan (seluruh peta jalan + dokumentasi) dan saya kira menerapkan salah satu dari sistem ini tidak akan cepat dan mudah. Godot IMHO sangat mudah untuk bekerja seperti sekarang. Ini berisi banyak alat yang dapat digunakan oleh seniman bekerja sama dengan pengembang game (editor shader visual, editor animasi, node tilemap).

OMONG-OMONG. Saya ingin mengambil kesempatan ini dan terima kasih kepada semua pencipta dan kontributor Godot. Anda melakukan pekerjaan yang sangat baik :+1:

BTW2. Saya minta maaf untuk bahasa Inggris saya. Saya melakukan yang terbaik tetapi saya masih membuat kesalahan konyol :cry:

baik itu construct2 atau blox - keduanya lebih baik bagi saya daripada grafik simpul itu.

Jika sistem menggunakan node hanya sebagai wadah untuk tindakan (sebagai status) - seperti yang ada di Playmaker, maka saya akan baik-baik saja dengan itu.

Hal yang menyenangkan tentang blox dan construct2 adalah editor menunjukkan kepada Anda semua kondisi dan tindakan yang tersedia. Ini memisahkan mereka untuk Anda dan menempatkan mereka dalam kategori. Itu adalah perubahan dramatis dalam presentasi yang memungkinkan non coder untuk melakukan banyak hal dengan mesin secara langsung - tanpa perlu mengetahui nama-nama perintah untuk melakukan sesuatu.

jika Anda menggunakan node untuk pemrograman visual - tantangan terbesar adalah mengomunikasikan kepada pengguna dalam urutan acara apa yang sedang dieksekusi. Di Unity - playmaker dan blox melakukannya dengan sangat bersih.

Di playmaker dengan menumpuk tindakan di dalam wadah simpul (status - berisi tindakan). Di blox - di mana Anda memiliki status yang berisi fungsi.

Mereka memberikan akses lengkap ke sebagian besar fitur unity. Ini sangat bagus untuk non programmer.
blox telah dikembangkan lebih lanjut menjadi "plygame" - addon kesatuan lain yang memiliki blox+ beberapa skrip yang dibuat khusus yang dapat diakses blox untuk membuat seluruh permainan gaya hack dan slash rpg.

Blox in unity sama dengan blok Skrach/Stencyl. Sepertinya ada banyak orang di sini yang menyukai gaya pemrograman itu :)
https://www.youtube.com/watch?v=Nd6Qy5ZipSs&list=PLuaBtUXEKcdIAA7_yjFNcLXM5YOf3WE9k

Semoga godot devs mencobanya.
Btw teknologi Skratch (https://scratch.mit.edu/) adalah open source! Dan yang lain telah mengadopsinya - tidak hanya stencyl. Google juga sangat tertarik dengannya:
https://developers.google.com/blockly/

proposal - Mengapa tidak mencoba yang terbaik dari kedua dunia! Node untuk mesin negara - blox/skratch/stencyl untuk ekspresi.
Di dunia yang ideal Anda akan memiliki node yang digunakan sebagai wadah Negara - seperti di Playmaker. Tetapi wadah negara akan memiliki blox/stencyl/skratch seperti sistem lego yang memungkinkan pengguna untuk dengan mudah mengatur logika - tidak perlu belajar menulis ekspresi seperti itu - mereka hanya siap untuk diseret dan dijatuhkan.

http://wiki.scratch.mit.edu/wiki/Scratch_1.4_Source_Code

Salah satu pengembang iCanScript mengatakan ini tentang aset VS mereka:

Kemajuan teknis iCS2 memisahkannya dari produk satu-satunya Unity yang secara signifikan meningkatkan peluang pasar. Visi akhirnya adalah bahwa iCS2 akan menjadi bantuan pengembangan yang dapat digunakan untuk membuat skrip untuk mesin game lain serta aplikasi standar Windows/OSX/iOS/Android.
http://forum.unity3d.com/threads/icanscript-visual-script-modeling-engine-for-unity.280847/#post -2124402

apa itu iCanScript kekacauan simpul!

Bagaimanapun, patut dicoba sebelum saya menilainya. Mungkin seseorang bisa masuk
berhubungan dengan pengembangnya?
Jika godot memiliki pasar dengan peluang untung - seperti itu
kesatuan tidak - mungkin itu akan menarik pengembang kesatuan untuk membuat aset untuk
Godot juga.

Pada Sabtu, 23 Mei 2015 pukul 16:24, todheil [email protected] menulis:

Salah satu pengembang iCanScript mengatakan ini tentang aset VS mereka:

Kemajuan teknis iCS2 memisahkannya dari hanya Unity
produk secara signifikan > meningkatkan peluang pasar. Visi akhir
adalah bahwa iCS2 akan menjadi alat bantu pengembangan yang >dapat digunakan untuk membuat skrip
untuk mesin game lainnya serta standar >Windows/OSX/iOS/Android
aplikasi.

http://forum.unity3d.com/threads/icanscript-visual-script-modeling-engine-for-unity.280847/#post -2124402

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -104895405.

Saya pikir lembar acara konstruksi 2 sangat mudah dipahami dan diprogram.

Sebagai seorang seniman yang menghabiskan sebagian besar waktu membuat grafik untuk hidup saya, belajar bahasa baru sangat sulit dan memakan waktu. Orang mengatakan Anda dapat mempelajarinya dalam beberapa bulan tetapi ketika Anda hanya memiliki waktu 2 jam sehari untuk diri sendiri, Anda dapat memilih untuk belajar dari awal atau berkreasi menggunakan bahasa yang sederhana. Juga, menjadi orang visual scripting visual lebih masuk akal.

Saya telah melakukan pemrograman di sekolah dan saya dapat membaca dan memahami kode dengan mudah tetapi menulisnya membutuhkan waktu. Saya juga mencoba mempelajari python yang lebih mudah tetapi masih membutuhkan waktu berbulan-bulan untuk membuat sesuatu dengannya.

Pendekatan Construct 2 tampaknya sederhana. Bagi saya itu terlihat seperti:

1 Acara: Aksi;

2 Acara: Aksi;
: Tindakan;

Ini pada dasarnya pemrograman tetapi dengan cara yang sangat mudah dipahami. Jika mereka hanya menggunakan bahasa alih-alih blok, saya tidak akan keberatan. Menggunakan pola ini mudah untuk membuat logika bagi saya.

Menggunakan node dapat menjadi tidak terkendali dengan sangat cepat karena hal-hal mulai menyebar dan Anda menghabiskan lebih banyak waktu untuk mencari node kemudian benar-benar membuat kode (Seperti yang saya pahami dari unity dan playmaker).

Jadi, Jika Anda mencoba menerapkan skrip visual, harap pikirkan dengan serius untuk membangun sistem acara.

Anda juga dapat membuat sistem skrip visual sebagai ekstensi yang dapat diunduh untuk orang-orang seperti kami sehingga mereka yang lebih menyukai pemrograman tidak perlu mengunduh muatan tambahan itu.

Kerja bagus dengan Godot menantikan untuk membuat game hebat di dalamnya.

Masalah saya dengan pendekatan Construct adalah rasanya seperti pemrograman, itu
sepertinya tidak jauh berbeda
Dari perspektif tim, saya lebih menyukai pendekatan cetak biru Unreal karena
itu lebih ramah untuk desainer yang tidak tahu tentang pemrograman

Pada hari Minggu, 24 Mei 2015 pukul 03.58, whoisda [email protected] menulis:

Saya pikir lembar acara konstruksi 2 sangat mudah dimengerti dan
program di.

Sebagai seorang seniman yang menghabiskan sebagian besar waktunya membuat grafik untuk hidup saya,
belajar bahasa baru sangat sulit dan memakan waktu. Orang bilang kamu bisa
pelajari dalam beberapa bulan tetapi ketika Anda hanya memiliki 2 jam sehari untuk
sendiri, Anda dapat memilih untuk belajar dari awal atau berkreasi menggunakan a
bahasa sederhana. Selain itu, menjadi visual person visual scripting membuat lebih banyak
nalar.

Saya telah melakukan pemrograman di sekolah dan saya dapat membaca dan memahami kode dengan mudah
tapi menulis butuh waktu. Saya juga mencoba belajar python yang lebih mudah
tapi masih butuh waktu berbulan-bulan untuk membuat sesuatu dengannya.

Pendekatan Construct 2 tampaknya sederhana. Bagi saya sepertinya:

1 Acara: Aksi;

2 Acara: Aksi;
: Tindakan;

Ini pada dasarnya pemrograman tetapi dengan cara yang sangat mudah dipahami. Jika mereka
hanya menggunakan bahasa alih-alih blok, saya tidak akan keberatan. Menggunakan ini
polanya mudah untuk membuat logika bagi saya.

Menggunakan node dapat menjadi tidak terkendali dengan sangat cepat karena hal-hal mulai menyebar dan
Anda menghabiskan lebih banyak waktu untuk mencari node daripada benar-benar membuat kode (Seperti saya
dipahami dari kesatuan dan playmaker).

Jadi, Jika Anda mencoba menerapkan skrip visual, berikan saran yang sangat
pemikiran serius untuk membangun sistem acara.

Anda juga dapat membuat sistem skrip visual sebagai yang dapat diunduh
ekstensi untuk orang-orang seperti kami sehingga mereka yang lebih suka pemrograman tidak perlu
unduh muatan ekstra itu.

Kerja bagus dengan Godot menantikan untuk membuat game hebat di dalamnya.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -104985159.

Tapi Anda adalah perspektif seorang programmer - seseorang yang sudah tahu caranya
untuk kode.
Lebih baik melihat statistik dalam hal ini - jumlah
pengguna non-programmer yang dimiliki construct2 dibandingkan pemrograman visual lainnya
editor harus berbicara sendiri.

itu juga layak untuk melihat berbagai permainan yang dibuat dalam satu gaya pemrograman visual di atas yang lain.

Unreal memang memiliki sejumlah besar proyek yang dilakukan di kismet memang - tetapi ini adalah mesin yang jauh lebih tua daripada construct2 dan banyak dari mereka hanyalah penembak orang pertama

Pada hari Minggu, 24 Mei 2015 pukul 10:15, Juan Linietsky [email protected]
menulis:

Masalah saya dengan pendekatan Construct adalah rasanya seperti pemrograman, itu
sepertinya tidak jauh berbeda
Dari perspektif tim, saya lebih menyukai pendekatan cetak biru Unreal karena
itu lebih ramah untuk desainer yang tidak tahu tentang pemrograman

Pada hari Minggu, 24 Mei 2015 pukul 03.58, whoisda [email protected] menulis:

Saya pikir lembar acara konstruksi 2 sangat mudah dimengerti dan
program di.

Sebagai seorang seniman yang menghabiskan sebagian besar waktunya membuat grafik untuk hidup saya,
belajar bahasa baru sangat sulit dan memakan waktu. Orang bilang kamu
bisa
pelajari dalam beberapa bulan tetapi ketika Anda hanya memiliki 2 jam sehari untuk
sendiri, Anda dapat memilih untuk belajar dari awal atau berkreasi menggunakan a
bahasa sederhana. Selain itu, menjadi visual person visual scripting membuat lebih banyak
nalar.

Saya telah melakukan pemrograman di sekolah dan saya dapat membaca dan memahami kode dengan mudah
tapi menulis butuh waktu. Saya juga mencoba belajar python yang
lebih mudah
tapi masih butuh waktu berbulan-bulan untuk membuat sesuatu dengannya.

Pendekatan Construct 2 tampaknya sederhana. Bagi saya sepertinya:

1 Acara: Aksi;

2 Acara: Aksi;
: Tindakan;

Ini pada dasarnya pemrograman tetapi dengan cara yang sangat mudah dipahami. Jika
mereka
hanya menggunakan bahasa alih-alih blok, saya tidak akan keberatan. Menggunakan
ini
polanya mudah untuk membuat logika bagi saya.

Menggunakan node dapat menjadi tidak terkendali dengan sangat cepat karena hal-hal mulai menyebar dan
Anda menghabiskan lebih banyak waktu untuk mencari node daripada benar-benar membuat kode (Seperti saya
dipahami dari kesatuan dan playmaker).

Jadi, Jika Anda mencoba menerapkan skrip visual, berikan saran yang sangat
pemikiran serius untuk membangun sistem acara.

Anda juga dapat membuat sistem skrip visual sebagai yang dapat diunduh
ekstensi untuk orang-orang seperti kami sehingga mereka yang lebih suka pemrograman tidak memiliki
ke
unduh muatan ekstra itu.

Kerja bagus dengan Godot menantikan untuk membuat game hebat di dalamnya.

—
Balas email ini secara langsung atau lihat di GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment -104985159
.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -104985669.

Pendekatan Construct2 untuk pemrograman sangat mirip dengan yang ada di
Clickteam fusion, yang juga memiliki banyak pengguna. Kemudahan untuk itu berasal dari
beberapa hal, meskipun mirip dengan pemrograman:

• Memiliki semua KONDISI yang mungkin terdaftar dan tersedia bagi pengguna untuk dipilih
  untuk menambahkan dengan mengklik/menyeret dalam bahasa Inggris sederhana - ini sangat berharga
  karena mereka tidak perlu mempelajari kata-kata ajaib. Mereka hanya bisa menyeret dan
  turunkan mereka.
• Memiliki semua TINDAKAN yang mungkin terdaftar dan tersedia bagi pengguna untuk dipilih
  tambahkan dengan mengklik/menyeret dalam bahasa Inggris sederhana - ini sangat berharga
  karena mereka tidak perlu mempelajari kata-kata ajaib. Mereka hanya bisa menyeret dan
  turunkan mereka.
• hal yang sama berlaku ketika melakukan ekspresi apa pun dalam pengaturan dan
  tindakan atau kondisi. Saat Anda menulis ekspresi, editor membantu Anda
  dengan daftar tarik-turun yang mudah didapat dari objek yang ada di
  pemandangan. Anda tidak perlu belajar bagaimana menuju ke properti itu karena mereka
  sudah tersedia dalam beberapa klik.

Mungkin aspek terbaiknya adalah mengajarkan non-programmer tentang
teori pemrograman tanpa kurva belajar mempelajari pemrograman baru
bahasa.

Pada Minggu, 24 Mei 2015 pukul 10:17, Todor Imreorov [email protected]
menulis:

Tapi Anda adalah perspektif seorang programmer - seseorang yang sudah tahu
cara membuat kode.
Lebih baik melihat statistik dalam hal ini - jumlah
pengguna non-programmer yang dimiliki construct2 dibandingkan pemrograman visual lainnya
editor harus berbicara sendiri.

Pada hari Minggu, 24 Mei 2015 pukul 10:15, Juan Linietsky < [email protected]

menulis:

Masalah saya dengan pendekatan Construct adalah rasanya seperti pemrograman, itu
sepertinya tidak jauh berbeda
Dari perspektif tim, saya lebih menyukai pendekatan cetak biru Unreal karena
itu lebih ramah untuk desainer yang tidak tahu tentang pemrograman

Pada hari Minggu, 24 Mei 2015 pukul 03.58, whoisda [email protected]
menulis:

Saya pikir lembar acara konstruksi 2 sangat mudah dimengerti dan
program di.

Sebagai seorang seniman yang menghabiskan sebagian besar waktunya membuat grafik untuk hidup saya,
belajar bahasa baru sangat sulit dan memakan waktu. Orang bilang kamu
bisa
pelajari dalam beberapa bulan tetapi ketika Anda hanya memiliki 2 jam sehari untuk
sendiri, Anda dapat memilih untuk belajar dari awal atau berkreasi menggunakan a
bahasa sederhana. Selain itu, menjadi visual person visual scripting membuat lebih banyak
nalar.

Saya telah melakukan pemrograman di sekolah dan saya dapat membaca dan memahami kode
dengan mudah
tapi menulis butuh waktu. Saya juga mencoba belajar python yang
lebih mudah
tapi masih butuh waktu berbulan-bulan untuk membuat sesuatu dengannya.

Pendekatan Construct 2 tampaknya sederhana. Bagi saya sepertinya:

1 Acara: Aksi;

2 Acara: Aksi;
: Tindakan;

Ini pada dasarnya pemrograman tetapi dengan cara yang sangat mudah dipahami. Jika
mereka
hanya menggunakan bahasa alih-alih blok, saya tidak akan keberatan. Menggunakan
ini
polanya mudah untuk membuat logika bagi saya.

Menggunakan node dapat menjadi tidak terkendali dengan sangat cepat karena hal-hal mulai menyebar
dan
Anda menghabiskan lebih banyak waktu untuk mencari node daripada benar-benar membuat kode (Seperti saya
dipahami dari kesatuan dan playmaker).

Jadi, Jika Anda mencoba menerapkan skrip visual, berikan saran yang sangat
pemikiran serius untuk membangun sistem acara.

Anda juga dapat membuat sistem skrip visual sebagai yang dapat diunduh
ekstensi untuk orang-orang seperti kami sehingga mereka yang lebih suka pemrograman tidak memiliki
ke
unduh muatan ekstra itu.

Kerja bagus dengan Godot menantikan untuk membuat game hebat di dalamnya.

—
Balas email ini secara langsung atau lihat di GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment -104985159
.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -104985669.

Lihat juga dari sudut pandang seorang desainer yang ingin belajar coding logika yang kompleks dan akhirnya cukup percaya diri untuk belajar coding. Saya melihat dari mana Anda berasal karena Anda melihat sistem akan digunakan oleh tim desainer dan pemrogram. Saya pribadi ingin menggunakan Godot sebagai pengguna tunggal dan tidak dalam tim dengan programmer seperti kebanyakan pengembang game indie. Sistem acara memaafkan dan terasa lebih terorganisir menggunakan grup saat Anda memiliki 1000+ acara.

Selain ini, saya tidak punya masalah dengan sistem simpul dan jika godot berhasil membuat sistem yang lebih baik daripada saat ini, saya akan menggunakannya.

Juga, Jika memungkinkan, buat fitur pencarian untuk menemukan blok/node kode dengan mudah.

Perhatikan bahwa lembar Acara di construct2/clickteam menghilangkan kebutuhan untuk belajar
sintaks- sehingga pengguna tidak perlu tahu di mana harus meletakkan sesuatu - yaitu
sangat jelas. Kondisi di sebelah kiri, tindakan di sebelah kanan. urutan dari
eksekusi acara juga sangat jelas.
Potongan Lego di awal/stencyl/unity blox tidak begitu jelas, tapi tetap saja
jauh lebih baik daripada mimpi buruk node yang disajikan dalam "iCanScript". Apakah kamu melihat?
di video tutorial mereka. Ini adalah desain pemrograman visual yang sangat berbelit-belit
dengan kurva belajar yang cukup curam. Saya pikir bahkan jika Anda memberikannya kepada
programmer mereka akan kesulitan mencari tahu

Pada hari Minggu, 24 Mei 2015 pukul 10:33, whoisda [email protected] menulis:

Lihat juga dari sudut pandang seorang desainer yang ingin belajar
untuk membuat kode logika yang kompleks dan akhirnya cukup percaya diri untuk belajar membuat kode.
Saya melihat dari mana Anda berasal karena Anda melihat sistem akan digunakan oleh
tim desainer dan programmer. Saya pribadi ingin menggunakan Godot sebagai
satu pengguna dan tidak dalam tim dengan programmer seperti banyak game indie
pengembang. Sistem acara memaafkan dan terasa lebih terorganisir menggunakan
grup ketika Anda memiliki 1000+ acara.

Selain ini, saya tidak punya masalah dengan sistem simpul dan jika godot berhasil
buat sistem yang lebih baik dari saat ini, saya akan menggunakan omong kosong itu
dia.

Juga, Jika memungkinkan, buat fitur pencarian untuk menemukan blok/simpul kode
dengan mudah.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -104988595.

Mereka bahkan tidak lagi menjual "icanscript" di toko aset unity.
Lihat angka penjualan di sana - salah satu program visual yang tersedia
sistem yang paling banyak digunakan - dan memiliki proyek yang lengkap.

Saya hanya akan meninggalkan Anda dengan video ini:
https://www.youtube.com/watch?v=3Zq1yo0lxOU
Ini memiliki 167 game yang dibuat dengan perpaduan clickteam - oleh orang-orang yang tidak memiliki
pengalaman pemrograman.

Lihat juga game kickstarter yang sukses dibuat dalam fusion.
https://www.kickstarter.com/projects/alonsomartin/heart-forth-alicia/description
https://www.kickstarter.com/projects/galaxytrail/freedom-planet-high-speed-platform-game/description
https://www.kickstarter.com/projects/20640221040/tiny-trek

perlu saya juga menyebutkan Five Nights at Freddy's (dibuat di clickteam fusion):
http://en.wikipedia.org/wiki/Five_Nights_at_Freddy%27s_%28video_game%29
game itu best seller. Berikut adalah beberapa angka untuk Anda:
https://thinkgaming.com/app-sales-data/8779/five-nights-at-freddys/

Ide kerangka kerja pemrograman visual harus memberdayakan seorang seniman untuk membuat permainan tanpa perlu programmer - dalam proses belajar sedikit tentang pemrograman.

Jika Anda membuatnya di mana programmer masih diperlukan - maka Anda belum benar-benar membuat kerangka kerja pemrograman visual - Anda baru saja membuat mesin negara yang dapat diatur oleh programmer untuk digunakan oleh desainer - untuk hal-hal sederhana dalam permainan - tetapi tidak untuk logika inti dari permainan. Jadi, Anda tidak benar-benar akan membuat sesuatu yang sebagus dan selengkap alat pemrograman visual lainnya yang disebutkan di sini. Anda tidak memberdayakan seniman untuk mengatur logika dan mengundang mereka untuk mempelajari konsep dasar pemrograman. Anda membuat mereka bergantung pada pemrogram dan dalam kegelapan konsep-konsep itu.

Pada hari Minggu, 24 Mei 2015 pukul 10:42, Todor Imreorov [email protected]
menulis:

Perhatikan bahwa lembar Acara di construct2/clickteam menghilangkan kebutuhan untuk belajar
sintaks- sehingga pengguna tidak perlu tahu di mana harus meletakkan sesuatu - yaitu
sangat jelas. Kondisi di sebelah kiri, tindakan di sebelah kanan. urutan dari
eksekusi acara juga sangat jelas.
Potongan Lego di awal/stencyl/unity blox tidak begitu jelas, tetapi
masih jauh lebih baik daripada mimpi buruk node yang disajikan di "iCanScript". Telah melakukan
Anda melihat tutorial video mereka. Ini adalah visual yang sangat berbelit-belit
desain pemrograman dengan kurva belajar yang cukup curam. Saya pikir bahkan jika
Anda memberikannya kepada seorang programmer, mereka akan kesulitan mencari tahu

Pada hari Minggu, 24 Mei 2015 pukul 10:33, whoisda [email protected]
menulis:

Lihat juga dari sudut pandang seorang desainer yang ingin
belajar membuat kode logika yang kompleks dan akhirnya cukup percaya diri untuk belajar
kode. Saya melihat dari mana Anda berasal karena Anda melihat sistem akan digunakan oleh
tim desainer dan programmer. Saya pribadi ingin menggunakan Godot
sebagai pengguna tunggal dan tidak dalam tim dengan programmer seperti banyak indie
pengembang game. Sistem acaranya memaafkan dan terasa lebih terorganisir
menggunakan grup saat Anda memiliki 1000+ acara.

Selain ini, saya tidak punya masalah dengan sistem simpul dan jika godot berhasil
buat sistem yang lebih baik dari saat ini, saya akan menggunakan omong kosong itu
dia.

Juga, Jika memungkinkan, buat fitur pencarian untuk menemukan blok/simpul kode
dengan mudah.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -104988595.

Saya pikir tidak bijaksana untuk mendorong Anda menggunakan sistem yang bekerja sangat baik untuk mesin permainan lain jika itu bukan arah yang ingin Anda ambil.

Pada catatan yang sama saya ingin melihat beberapa cara yang lebih intuitif bahwa skrip visual diimplementasikan. Tidak menggunakan node yang berantakan atau blok yang memakan waktu (pembuat aplikasi Android) atau sistem acara yang tampak terlalu pemrograman (yang saya lebih suka daripada yang lainnya). Sesuatu yang mengambil yang terbaik dari semuanya.

Mungkin berkonsultasi dengan perancang kegunaan untuk menghapus beberapa jalur dan melihat beberapa angka.

Pada akhirnya akan sangat bagus untuk melihat metode unik Godot yang menjadikan Godot mesin hebat yang memungkinkan satu orang pemula mendesain game pertamanya dalam seminggu dan tim pengembangan berkolaborasi bersama untuk membuat game AAA.

Saya akan senang melihat sistem yang akan membantu saya membuat game yang luar biasa tanpa mengubah mesin dan mempelajari bahasa terlalu sering.

Bersulang.

Saya tidak keberatan node jika dilakukan seperti yang ada di playmaker - as
wadah tindakan (negara).
Node di sana sebenarnya tidak digunakan untuk mengatur tindakan atau kondisi.

Namun jika Anda membuatnya seperti "iCanScript", Anda benar-benar berantakan.

1. sulit untuk mengatakan di mana urutan acara dijalankan
2. Sulit untuk mengetahui simpul mana yang dapat dihubungkan ke simpul mana
3. dibutuhkan banyak node dan langkah untuk menyiapkan satu tindakan daripada yang dilakukannya
   drag dan drop dan atur ekspresi di dalamnya (construct2/clickteam style
4. di mana Anda dibantu dengan sintaks - itu adalah cara yang bagus untuk memperkenalkan
   seseorang untuk memprogram tanpa mengharuskan mereka membaca banyak
   dokumentasi - semuanya tersedia untuk mereka di menu tarik-turun
   obyek).

Pada hari Minggu, 24 Mei 2015 pukul 11:20, whoisda [email protected] menulis:

Saya pikir tidak bijaksana untuk mendorong Anda menggunakan sistem yang berfungsi
sangat baik untuk mesin game lain jika itu bukan arah yang Anda inginkan
ingin mengambil.

Pada catatan yang sama saya ingin melihat beberapa cara yang lebih intuitif daripada visual
skrip diimplementasikan. Tidak menggunakan simpul yang berantakan atau memakan waktu
blok (pembuat aplikasi Android) atau sistem acara yang tampak terlalu pemrograman (yang saya)
lebih suka daripada yang lainnya). Sesuatu yang mengambil yang terbaik dari semuanya.

Mungkin berkonsultasi dengan perancang kegunaan untuk menghapus beberapa jalur dan melihat beberapa
angka.

Pada akhirnya akan sangat bagus untuk melihat metode unik Godot yang membuat
Godot mesin hebat yang memungkinkan kedua orang pemula mendesainnya
game pertama dalam seminggu dan tim pengembangan berkolaborasi bersama untuk
buat game AAA

Saya akan senang melihat sistem yang akan membantu saya membuat game yang luar biasa
tanpa mengubah mesin dan mempelajari bahasa terlalu sering.

Bersulang.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -104990083.

Saya memilih @whoisda sehubungan dengan sesuatu yang diinovasi untuk/di Godot. Namun tampaknya ada tiga sekolah Visual Scripting: 1) node, 2) lembar acara, 3) blok. Dari ketiga node ini tampaknya menjadi yang terdepan dalam lingkungan 3d. Omong-omong, saya telah membaca di suatu tempat sebuah ide yang menyarankan skrip/pemrograman keluar dari format dan program linier (teks, blok, lembar acara), atau horizontal (simpul) dalam 3D menggunakan struktur. Tidak yakin bagaimana itu akan berhasil tetapi kedengarannya menarik.

Sekolah skrip visual yang disebutkan telah diuji dalam praktik dan
sudah memiliki pengguna. Saya menyarankan untuk menggabungkan desain Playmaker dan
blok dalam kesatuan.

Node untuk membuat mesin negara.
Blok atau lembar acara untuk membuat tindakan di dalam setiap node (status).

Pada hari Minggu, 24 Mei 2015 pukul 13.56, todheil [email protected] menulis:

Saya memilih @whoisda https://github.com/whoisda sehubungan dengan sesuatu
sedang diinovasi untuk/di Godot. Namun tampaknya ada tiga Visual
Sekolah skrip: 1) simpul, 2) lembar acara, 3) blok. Dari ketiganya
node tampaknya menjadi yang terdepan dalam lingkungan 3d. Ngomong-ngomong soal
Saya telah membaca di suatu tempat sebuah ide yang menyarankan skrip/pemrograman keluar dari a
format linier (teks, blok, lembar acara), atau horizontal (simpul) dan
program dalam 3D menggunakan struktur. Tidak yakin bagaimana itu akan berhasil tetapi terdengar
memukau.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -105001411.

Akan sangat bagus jika kita bisa menggunakan node dan event bersama-sama. Node dapat menyatakan yang jika mengikuti logika sederhana dapat dicolokkan ke node lain atau dapat menjadi wadah untuk skrip/ blok/ lembar acara dengan cara ini kita tidak akan memiliki node yang sangat besar dan juga dapat berkolaborasi sebagai sebuah tim. Tapi ini mungkin terlalu banyak untuk pengembang. Masih idenya tampaknya sangat rapi.

Seperti itulah di Playmaker - orang-orang sepertinya sangat menyukainya.
Banyak orang di sini tampaknya juga menyukai stencyl - teknologinya
open source dan tersedia di situs web github awal. Saya membagikannya di
posting sebelumnya.

Saya pribadi akan senang melihat APAPUN langkah pertama dalam pemrograman visual
arah. Bahkan jika pengembang membuat mesin negara yang bekerja dengan gd
skrip - itu akan menjadi awal yang luar biasa yang bahkan programmer tingkat lanjut
Akan menghargai.

Kemudian mungkin setelah itu kita dapat memiliki sesuatu yang visual seperti stencyl atau
construct2 - itu seperti kode - tetapi jauh lebih mudah daripada kode - di dalam
negara bagian.

Jadi sebenarnya ini adalah dua permintaan fitur!

• Satu untuk mesin negara (node)
• lain untuk kerangka kerja skrip visual yang menggantikan pembelajaran gdscript
  dengan drag and drop coding. Tetapi juga merupakan langkah yang bagus untuk belajar
  gdscript.

Pada akhirnya pengembang utama tahu apa yang terbaik untuk desain godot.

Pada Selasa, 26 Mei 2015 pukul 11:43, whoisda [email protected] menulis:

Akan sangat bagus jika kita bisa menggunakan node dan event bersama-sama. Node dapat
menyatakan yang jika mengikuti logika sederhana dapat dicolokkan ke node lain atau
dapat menjadi wadah untuk skrip/ blok/ lembar acara dengan cara ini yang tidak akan kita miliki
node yang sangat besar dan juga dapat berkolaborasi sebagai sebuah tim. Tapi ini mungkin juga
banyak untuk pengembang. Masih idenya tampaknya sangat rapi.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -105446984.

saya akan segera memeriksa styencyl karena saya tidak terbiasa dengannya.
pada titik ini dari semua yang saya lihat/baca, saya dapat menyimpulkan bahwa:

1) Cetak Biru: Sangat bagus untuk desainer game/level, tetapi tidak terlalu bagus untuk
pemrograman visual
2) Stencyl: Jauh lebih baik untuk pemrograman visual, tetapi tidak dapat digunakan untuk
desainer game/level

Pengalaman saya membuat game selalu dalam tim, jadi saya bisa melihat 1) sebagai makhluk
sangat berguna, tetapi itu juga membuat saya bias. Apakah ada banyak orang?
tertarik dengan pemrograman visual seperti di Stencyl?

Pada Selasa, 26 Mei 2015 pukul 06:10, Todor Imreorov [email protected]
menulis:

Seperti itulah di Playmaker - orang-orang sepertinya sangat menyukainya.
Banyak orang di sini tampaknya juga menyukai stencyl - teknologinya
open source dan tersedia di situs web github awal. Saya membagikannya di
posting sebelumnya.

Saya pribadi akan senang melihat APAPUN langkah pertama dalam pemrograman visual
arah. Bahkan jika pengembang membuat mesin negara yang bekerja dengan gd
skrip - itu akan menjadi awal yang luar biasa yang bahkan programmer tingkat lanjut
Akan menghargai.

Kemudian mungkin setelah itu kita dapat memiliki sesuatu yang visual seperti stencyl atau
construct2 - itu seperti kode - tetapi jauh lebih mudah daripada kode - di dalam
negara bagian.

Jadi sebenarnya ini adalah dua permintaan fitur!

• Satu untuk mesin negara (node)
• lain untuk kerangka kerja skrip visual yang menggantikan pembelajaran gdscript
  dengan drag and drop coding. Tetapi juga merupakan langkah yang bagus untuk belajar
  gdscript.

Pada akhirnya pengembang utama tahu apa yang terbaik untuk desain godot.

Pada Selasa, 26 Mei 2015 pukul 11:43, whoisda [email protected]
menulis:

Akan sangat bagus jika kita bisa menggunakan node dan event bersama-sama. Node dapat
menyatakan bahwa jika mengikuti logika sederhana dapat dicolokkan ke node lain
atau
dapat menjadi wadah untuk skrip/ blok/ lembar acara dengan cara ini kami tidak akan
memiliki
node yang sangat besar dan juga dapat berkolaborasi sebagai sebuah tim. Tapi ini mungkin
juga
banyak untuk pengembang. Masih idenya tampaknya sangat rapi.

—
Balas email ini secara langsung atau lihat di GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment -105446984
.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -105458142.

http://www.emanueleferonato.com/wp-content/uploads/2011/12/stencyl05.png

Apakah ini contoh kanonik dari "kode" stensil seperti apa? Jika ya, maka sepertinya itu ide yang mengerikan: sepertinya pengkodean standar dalam pembungkus visual untuk taman kanak-kanak. Ayolah, python sudah cukup mudah untuk dibaca oleh istri saya, jadi mengapa tidak berusaha mempelajari dasar-dasarnya?

Jika Anda berbicara pemrograman visual, maka apa yang sudah dimiliki Godot jauh lebih baik - grafik shader atau grafik animasi: kode yang dibungkus dengan node visual.
https://frenchdog.files.wordpress.com/2009/09/specular_reflexion_vops.jpg - contoh lain dari pemrograman berbasis simpul visual (Sidefx Houdini, atau XSI). Itu dewasa dan tidak terlihat seperti mainan anak-anak, juga mengingatkan saya pada simpul Godot.

Saya menyukai pendekatan construct2, tetapi setelah melihat lebih jauh ke awal - sepertinya pilihan yang lebih baik karena sejumlah alasan:

• Desain pemrograman tampaknya lebih populer daripada konstruk2
• Itu telah ditetapkan sebagai alat untuk membantu mengajar orang-orang bahasa pemrograman
• Ini adalah open source dan yang lain telah mengubahnya untuk mesin mereka di masa lalu

Pengembang Stencyl mengadopsi teknologi "goresan" open source. Ini bukan desain mereka.
https://scratch.mit.edu/about/
http://en.wikipedia.org/wiki/Scratch_ (bahasa_pemrograman)
http://wiki.scratch.mit.edu/wiki/Scratch_1.4_Source_Code

Contoh Scratch yang digunakan oleh mesin game lain yang ditargetkan untuk non-programmer:

• Stencyl (paling populer) http://www.stencyl.com/
  
• Craftstudio ( http://craftstud.io/ )
  
• google blockly ( https://developers.google.com/blockly/ )
• Yang paling dekat dengan Godot adalah aset pemrograman visual "Blox" Unity:
  
  https://www.youtube.com/watch?v=Nd6Qy5ZipSs&list=PLuaBtUXEKcdIAA7_yjFNcLXM5YOf3WE9k
  Alih-alih Lua, itu menghasilkan C#.
  dokumentasi lengkapnya ada di sini:
  http://www.plyoung.com/blox/
  dan dijual di sini: https://www.assetstore.unity3d.com/en/#!/content/12859

Ini mungkin tampak seperti ide yang mengerikan untuk programmer berpengalaman, tetapi ini adalah cara terbaik untuk mengajari non programmer cara menulis kode atau hanya memberdayakan mereka untuk memprogram tanpa mengetahui kata-kata ajaib atau sintaksis. Scratch membuat semuanya tersedia untuk drag and drop - memaksa struktur yang benar dengan petunjuk visual. Silakan tonton daftar putar video "Unity Blox" yang saya posting untuk melihatnya beraksi. Lebih dari apa pun, telah terbukti dalam praktik berulang kali. Sepertinya taruhan paling aman.

Saya setuju dengan @reduz pada poinnya bahwa yang satu bagus dalam desain level dan yang lainnya dalam skrip visual dan saya tidak lagi berdebat untuk menggunakan yang satu di atas yang lain.

Menggunakan keduanya sepertinya merupakan pendekatan terbaik. Jika bukan Unity blox, bahkan jika Anda melihat Playmaker, Anda akan melihat bahwa node benar-benar wadah di sana- tempat tindakan dapat ditumpuk - sangat mirip dengan stencyl. Anda drag dan drop mereka dari daftar!

"tetapi ini adalah cara terbaik untuk mengajari non-programmer cara menulis kode atau sekadar memberdayakan mereka untuk memprogram tanpa mengetahui kata-kata ajaibnya"

Lalu saya tidak mengerti audiens apa yang ditargetkan ini. Apakah Godot bertujuan untuk bersaing dengan anak-anak besar di pasar (Unreal Engine, Unity, dll.) atau mengajari anak-anak pemrograman/membuat game seperti yang dilakukan Scratch (https://scratch.mit.edu/)?

Saya tahu apa itu node (input -> fungsi dengan params -> output), saya tidak setuju dengan presentasinya.

Stencyl dan Playmaker mungkin hebat dalam mengajari anak-anak cara membuat kode, tetapi mereka telah berhasil digunakan oleh non-programmer (baik studio maupun indie) untuk membuat game yang sukses - dijual di platform yang berbeda.
Jika Anda menggolongkan Unity sebagai anak laki-laki besar, maka Anda harus tahu bahwa anak laki-laki besar juga melakukan pemrograman visual.
http://www.hutonggames.com/showcase.html

Saya pikir godot memiliki banyak fitur untuk digunakan oleh anak-anak besar. Beberapa fitur yang memungkinkan lebih kecil/indie dapat membantu adopsi mesin yang lebih cepat. Dan sifat open source dan lisensi ramping sangat menguntungkan untuk pemula.

@blurmind
Saya _not_ membantah pemrograman visual. Saya akan mengatakan Godot sudah memiliki apa yang dibutuhkannya (ShaderGraphs): pendekatan visual yang sama dapat diperluas ke pemrograman logika mesin negara, atau pemrograman umum. Apa yang saya lawan adalah menentang mengadopsi paradigma visual lain (~scratch) yang tidak menakut-nakuti anak-anak.

seperti yang disebutkan sebelumnya, ini bukan hanya untuk anak-anak. Tetapi jika bahkan anak-anak dapat memahami dan menggunakannya - maka saya pikir itu adalah hal yang baik. Bukan sesuatu yang memalukan.

Poin terbesar yang ingin saya sampaikan di sini adalah:

• urutan eksekusi tindakan harus jelas! Melakukan semua logika dengan node bisa menjadi sangat berantakan dengan sangat cepat. Jadi node harus digunakan untuk status imo.
• Pengembang Playmaker dengan sangat cerdik mengantisipasi masalah itu dan itulah sebabnya mereka membuatnya jadi node adalah wadah tindakan di mana - sangat mirip dengan Stencyl- Anda menyeret dan melepaskan Tindakan yang tersedia dari daftar:
  
  dan susun acara seperti itu

Apa yang Anda dapatkan adalah pengaturan simpul yang sangat bersih dan efisien!

Saya menyarankan agar Godot devs mencoba playmaker juga.
Mengganti tumpukan Acara dengan logika Stencyl akan membuat pendekatan godot jauh lebih fleksibel/kuat!.

Tidak harus hanya melalui pendekatan stensil. Saya pikir Anda dapat mengaktifkan programmer berpengalaman untuk melampirkan skrip gd ke node. Memiliki opsi untuk menggunakan pendekatan stencyl untuk membuat gdscripts akan sangat berharga. Ini akan mengundang banyak pengguna baru ke komunitas godot.

@blurmind
Oke, tapi itu sesuatu yang berbeda. Mudah digunakan tidak berarti harus terlihat seperti ditujukan untuk anak-anak.
Urutan eksekusi dan penyaringan yang dibantu dari input/output yang sesuai untuk node tertentu adalah masalah umum untuk alur kerja berbasis node. Perangkat lunak yang berbeda menyelesaikannya secara berbeda.

Anda harus bertanya pada diri sendiri - Apakah Anda ingin lebih banyak non-programmer menggunakan Godot? Apakah Anda ingin memungkinkan orang yang tidak memiliki pengalaman dengan gdscript untuk membuat sesuatu yang menyenangkan?

Jika jawabannya ya - maka cara terbaik untuk melakukannya adalah dengan memberi mereka pendekatan skrip visual.
Saya tidak menyarankan untuk membuat node terlihat seperti sesuatu yang dibuat untuk anak-anak.
Apa yang saya sarankan adalah untuk membagi ini menjadi dua proyek!

• Node digunakan sebagai mesin negara - seperti di Playmaker! Pemrogram dapat memberi nama setiap node dan melampirkan gdscripts padanya - dengan input dan output yang mereka atur. Jadi ini sama sekali bukan untuk anak-anak. Faktanya, ini adalah pendekatan yang jauh lebih fleksibel untuk programmer yang jauh lebih tidak berantakan.
• Lembar peristiwa seret dan lepas atau antarmuka blok sebagai cara alternatif untuk menghasilkan skrip GD. Jadi, alih-alih menulis GdScript untuk dilampirkan ke node, non-programmer dapat menumpuk tindakan dari daftar semua peristiwa yang tersedia di godot - seperti Playmaker. Untuk mengambil satu langkah lebih jauh dan berinovasi - daripada hanya menumpuk tindakan, akan lebih baik menggunakan blok seperti Stencyl.

Dengan cara ini Anda memiliki sesuatu yang berguna bagi programmer dan non-programmer. Mereka berdua dapat menggunakan mesin negara (node) dan non-programmer tidak harus segera mempelajari gdscript dan menggunakan gdBlocks sebagai gantinya untuk menghasilkan gdscript untuk sebuah node (sekali lagi - seperti di Playmaker).

@blurmind
Saya lebih suka itu. Juga konsisten dengan Shader node-graph vs Shader-text yang sudah ada di Godot.

SideFX Houdini memiliki sesuatu yang disebut VEX (https://goo.gl/TMWNKk) ("ekspresi vektor" bahasa seperti c yang dimaksudkan untuk aljabar vektor). Ini agak identik dengan gdScript. Juga memiliki sesuatu yang disebut "VOPs" (http://goo.gl/Qpn2OE) (Operator Vex) - pada dasarnya pembungkus visual dari subset VEX, yang terlihat sangat mirip dengan gambar simpul-grafik LeadWerks yang Anda rujuk di atas. Bahkan, VOP dapat diubah menjadi teks-skrip, jika perlu (tetapi tidak sebaliknya).

Koeksistensi keduanya cukup alami dan memungkinkan, bahkan non-programmer, untuk membuat kode yang sangat berantakan dan tidak efisien;)

Saya pribadi menyukai pendekatan Blueprint karena ini sangat desainer game
seperti, tapi saya bersikeras bahwa saya mungkin bias.

Saya mengunduh Stencyl dua jam yang lalu dan memainkannya. saya mungkin
salah, tapi saya pikir Stencyl adalah alat yang bagus untuk belajar karena bukan hanya
bagian pemrograman disederhanakan tetapi bagian mesin juga. Kombinasinya adalah
bagus karena ini adalah pendekatan pemrograman sederhana untuk mesin game sederhana.

Tapi Godot bukan mesin game sederhana (Setidaknya dibandingkan dengan Stencyl) jadi saya
tidak berpikir pemrograman yang disederhanakan akan berguna. Stencyl bergantung pada
banyak hal logika permainan harcoded yang tidak akan tersedia di
Godot, dan mencoba membuatnya tersedia akan bertentangan dengan tujuan Godot
menjadi mesin permainan tujuan yang sangat umum.

Pendekatan node dan grafik lebih menarik menurut saya karena itu
tingkat yang lebih rendah dan cara yang lebih fleksibel dalam melakukan sesuatu.

Pada Selasa, 26 Mei 2015 pukul 11:29, Vladimir Lopatin < [email protected]

menulis:

@blurymind https://github.com/blurymind
Saya lebih suka itu. Juga konsisten dengan grafik simpul Shader vs
Shader-text yang sudah ada di Godot.

SideFX Houdini memiliki sesuatu yang dingin VEX (https://goo.gl/TMWNKk) ("vektor
ekspresi" bahasa mirip-c yang dimaksudkan untuk aljabar vektor).
agak identik dengan gdScript. Juga memiliki sesuatu yang disebut "VOPs" (
http://goo.gl/Qpn2OE) (Operator Vex) - pada dasarnya pembungkus visual dari
bagian dari VEX, yang terlihat sangat mirip dengan grafik simpul LeadWerks yang Anda
dirujuk di atas. Bahkan, VOP dapat diubah menjadi skrip, jika perlu
(tapi tidak sebaliknya).

Ko-eksistensi keduanya cukup alami dan memungkinkan, bahkan
non-programmer, untuk membuat kode yang sangat berantakan dan tidak efisien ;)

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -105543845.

Bagaimana dengan action stack di Playmaker dan blox di Unity? Unity bukanlah mesin yang sangat sederhana.

Saya pikir stencyl bukan contoh yang bagus. Lebih baik mencari contoh di toko aset unity.

saya mencoba memahami playmaker tetapi gagal, bagaimana cara kerjanya?

Pada Selasa, 26 Mei 2015 pukul 12:16, Todor Imreorov [email protected]
menulis:

Bagaimana dengan action stack di Playmaker dan blox di Unity? Persatuan bukanlah
mesin yang sangat sederhana.

Saya pikir stencyl bukan contoh yang bagus. Lebih baik mencari
contoh di toko aset unity.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -105561760.

memeriksa tutorial playmaker, tetapi tampaknya mirip dengan stencyl di
perasaan bahwa itu datang dengan sejuta perilaku yang telah ditentukan sebelumnya

Pada Selasa, 26 Mei 2015 pukul 12:19, Juan Linietsky [email protected]
menulis:

saya mencoba memahami playmaker tetapi gagal, bagaimana cara kerjanya?

Pada Selasa, 26 Mei 2015 pukul 12:16, Todor Imreorov < [email protected]

menulis:

Bagaimana dengan action stack di Playmaker dan blox di Unity? Persatuan bukanlah
mesin yang sangat sederhana.

Saya pikir stencyl bukan contoh yang bagus. Lebih baik mencari
contoh di toko aset unity.

—
Balas email ini secara langsung atau lihat di GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment -105561760
.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -105563777.

_OkamStudio_

Yang paling dekat dalam cetak biru Unity ke U4 adalah uScript:
https://www.assetstore.unity3d.com/en/#!/content/1808

Orang-orang tampaknya lebih memilih Playmaker daripada uscript- karena lebih mudah untuk memahami logika yang telah diatur. Seperti yang Anda lihat dari tangkapan layar - ini menjadi sangat berantakan bahkan untuk logika sederhana.

@reduz @okamstudio ini playlist di playmaker:
https://www.youtube.com/watch?v=I9VwsVtbgFU&index=2&list=PLC759306A1E692A10
Saya pikir Anda harus benar-benar menggunakannya untuk sedikit. Anda dapat melakukan perilaku dan skrip yang telah ditentukan sebelumnya, tetapi playmaker juga memungkinkan Anda mengakses fitur inti mesin dan membuat perilaku tersebut dari awal sendiri.

Ya, playmaker adalah mesin negara dan persatuan datang dengan banyak perilaku yang telah ditentukan sebelumnya.
Godot juga memilikinya - mereka terpasang di mesin.
Saya masih percaya bahwa Anda benar-benar dapat membuat skrip/perilaku dari awal dengan menggunakan stencyl clone blox unity.

Saya pikir akhirnya Anda membutuhkan seorang programmer untuk membuat game yang tepat dan ide ini
hebat bahwa perancang game membuat game itu sendiri tetapi saya pikir itu banyak
pekerjaan yang tidak berguna dalam banyak kasus. tetapi jika kita memiliki lebih banyak
fitur untuk editor itu sendiri seperti desainer platformer yang orang lain
disebutkan dalam edisi lain atau hal berguna lainnya untuk mempermudah ui
lebih ramah.
Pada tanggal 26 Mei 2015 19:52, "Okam Studio" [email protected] menulis:

memeriksa tutorial playmaker, tetapi tampaknya mirip dengan stencyl di
perasaan bahwa itu datang dengan sejuta perilaku yang telah ditentukan sebelumnya

Pada Selasa, 26 Mei 2015 pukul 12:19, Juan Linietsky < [email protected]

menulis:

saya mencoba memahami playmaker tetapi gagal, bagaimana cara kerjanya?

Pada Selasa, 26 Mei 2015 pukul 12:16, Todor Imreorov <
[email protected]

menulis:

Bagaimana dengan action stack di Playmaker dan blox di Unity? Persatuan adalah
tidak a
mesin yang sangat sederhana.

Saya pikir stencyl bukan contoh yang bagus. Lebih baik mencari
contoh di toko aset unity.

—
Balas email ini secara langsung atau lihat di GitHub
<
https://github.com/okamstudio/godot/issues/1220#issuecomment -105561760
.

—
Balas email ini secara langsung atau lihat di GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment -105563777
.

_OkamStudio_

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -105565084.

berikut adalah review di unity asset store untuk uScript:

Alat yang bagus, tetapi sulit dipelajari jika non-programmer... tanggapan untuk permintaan bantuan di forum sangat lambat atau tidak ada sama sekali..

Apa pun yang akhirnya ada di Godot, saya pikir - jika mungkin - itu ide yang baik untuk mengizinkan konversi satu arah ke GDScript. Ini akan memungkinkan pengaturan cepat secara visual, oleh desainer dan seniman dan semacamnya, dan kemudian memungkinkan pembuat kode di tim untuk lebih men-tweak dan mengerjakan ulang tanpa harus menggunakan runcing-clicky.

@adolson Itu akan menjadi fitur yang sangat diinginkan :)

ini bisa dilakukan, dan juga bisa dilakukan dengan editor visual shader
(yang sebenarnya, menghasilkan kode shader)
tetapi saya pikir kode shader yang dihasilkan tidak akan dapat dibaca seperti yang Anda mungkin
berharap :P

Pada Selasa, 26 Mei 2015 pukul 18.33, [email protected] menulis:

@adolson https://github.com/adolson Itu akan sangat diinginkan
fitur :)

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -105670945.

@reduz Beberapa metadata diharapkan.
Berikut ini contoh konversi dari VOP -> konversi VEX, seperti yang ditunjukkan di atas:
:
Dan inilah daftar lengkap kode , yang, jika tidak, dalam VEX murni terlihat seperti ini:
@P += vektor({0,1,0}); // ambil Posisi dan tambahkan vektor (0,1,0)

Seperti yang Anda lihat, jumlah metadata signifikan, tetapi tidak sulit untuk memisahkan keduanya, mungkin menguraikannya secara semi atau otomatis penuh.

@reduz Itu benar. Aku tidak benar-benar memikirkan itu. Ini mungkin bukan jenis kode yang ingin digunakan oleh sebagian besar programmer. Saya dapat melihat label menjadi nama variabel dan semacamnya, tetapi saya tidak dapat melihat terlalu banyak hal lain untuk mengurangi masalah.

Meskipun saya tidak dapat berbicara untuk semua orang, jika saya melihat kode yang berantakan, saya mungkin mengambil beberapa bagian darinya, tetapi saya biasanya merasa ingin menulis ulang saja. Jadi, jika itu masalahnya, ini tidak akan berarti bagi saya secara pribadi.

Kalian benar-benar melalui keseluruhan pilihan. Saya telah menggunakan Construct 2 dan meskipun rapi, Anda tidak akan pernah bisa menyentuh kode apa pun untuk memperbaikinya dan opsinya agak terbatas. Pembaruan tilemap pada dasarnya menghilangkan prefab & karenanya juga membuat instance. Yang sangat saya sukai adalah PlayMaker untuk Unity.

Sesuatu tentang itu sangat mudah untuk tetap memahami ruang lingkup Anda dan apa yang perlu Anda lakukan. Ini adalah faktor yang sangat menarik, seluruh alasan saya suka menggunakan skriptor visual adalah karena hal ini. Saya lupa apa yang saya lakukan atau apa yang perlu saya lakukan dalam kode tekstual, tetapi melihat bagaimana segala sesuatu 'terhubung' memiliki manfaat paling mutlak bagi saya. NateWardog memposting contoh di tangkapan layar jauh lebih awal & blurrymind jauh lebih baru.

Saya katakan reduz, lakukanlah. Untuk saat ini, jika Anda ingin repot, saya akan memotret untuk 1.3 atau lebih baru dan itupun sebagian besar fokus pada sisi frontendnya. Kemudian ketika sudah siap nanti, fokuslah untuk membuatnya menghasilkan kode yang dapat dibaca seperti kaleng Blueprint, yang menurut saya akan sangat menantang. Tolong jangan meremehkan yang satu ini!

Berlangganan. Saya juga sangat tertarik dengan ini! Saya tahu beberapa skrip dan tidak keberatan menggunakannya ... tapi saya lebih suka menghubungkan node daripada itu jika memungkinkan! Sesuatu seperti batu bata logika di Blender Game Engine, yang bertindak sebagai pintasan visual untuk skrip Godot berfungsi sebagai alternatif untuk menulisnya dengan tangan... itu akan menjadi fitur yang bagus dan yang saya tunggu-tunggu.

skrip visual benar-benar menarik banyak orang kreatif atau orang yang tidak ingin belajar bahasa skrip baru seperti skrip gd. saya sedang melihat pembuat game sangat populer dan satu-satunya alasan yang paling banyak diberikan adalah mekanik skrip visual.

Skrip visual membosankan, bodoh, dan sulit digunakan.
Saya tidak pernah melihat implementasi yang baik. Orang visual harus menggambar grafik. Saya
tahu banyak orang tidak bisa menulis,
tapi ini tidak akan ada gunanya bagi mereka. Orang non-pemrogram tidak berarti
orang yang buta huruf.

Saya tidak tahu alat pembangun logika visual apa pun, yang merupakan sistem utama untuk
logika permainan di mesin apa pun.
Cara visual menyebalkan dalam banyak aspek. Orang visual biasanya mempertimbangkan
pemrograman sebagai "hal-hal teknologi"
berarti sesuatu yang nyata dari pipa ledeng dan kerja keras, dan ingin berada di atas
dia. sikap ini
biasanya karena beberapa masalah intelektual. Saya tidak berpikir orang-orang ini
bisa menjadi target audiens
pada dasarnya mereka membatasi kreativitas mereka.

Pada Kam, 14 Apr 2016 jam 08:33, Rémi Verschelde [email protected]
menulis:

Sunting: Saya melihat Anda mengubah "Pembuat RPG" menjadi "Pembuat Game", sekarang menjadi lebih banyak
akal :p Menghapus posting saya.

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung atau lihat di GitHub
https://github.com/godotengine/godot/issues/1220#issuecomment -209770726

Saya tidak mau, tetapi saya harus mengatakannya, tetapi itu adalah pandangan yang sangat sempit tentang alat skrip visual, Sergey. Adapun game yang telah sepenuhnya dibuat dengannya, beberapa mesin telah sepenuhnya memilih untuk tidak menggunakannya seperti Construct, jadi Anda tidak akan melihat game apa pun dari mesin itu yang dibuat dengan skrip biasa. Mesin lain (lebih waras, imo) memiliki plugin seperti Unity dan UE4. Saya pribadi sangat suka menggunakan uscript & PlayMaker di Unity di samping kode reguler saya karena sementara beberapa hal lebih mudah untuk dikodekan, banyak yang lebih mudah untuk skrip secara visual, terutama mesin negara karena dengan skrip visual seperti PM itu memberi Anda banyak umpan balik dengan breakpointsw jauh lebih mudah untuk melihat proyek dari pandangan yang lebih luas.

Hal nyata tentang skrip visual secara umum, itu adalah upaya yang sia-sia untuk
membuat pemrograman dapat diakses oleh non-programmer, yang sama sekali salah
mendekati.
Pemrograman visual lebih sulit daripada pemrograman teks biasa. Untuk membuatnya
lebih mudah Anda harus menulis banyak blok untuk setiap kasus dalam kehidupan secara tradisional
cara dan
biarkan orang-orang ini menggunakannya. Ini terbukti kurang efektif daripada meminta
programmer yang baik untuk menulis kode. Ungkapan "pemrograman bukanlah sebuah profesi,
semua orang bisa melakukannya" salah. Semua upaya pemrograman tanpa
pemrograman adalah pemborosan.

Adapun mesin negara - saya sedang berpikir untuk mengimplementasikan ini beberapa waktu
lalu, tapi itu tidak akan membantu program visual tinggi.
Ini dapat dengan mudah dilakukan untuk gim Anda menggunakan skrip alat dan editor simpul,
yang merupakan alat yang ampuh, banyak orang menggunakannya untuk alat permainan, seperti
editor dialog permainan.

Pada Kam, 14 April 2016 pukul 09:09, Aaron M [email protected] menulis:

Saya tidak ingin mengatakannya, tetapi itu adalah pandangan visual yang sangat sempit
alat skrip, Sergey. Adapun game yang telah sepenuhnya dibuat dengan mereka,
beberapa mesin telah sepenuhnya memilih untuk tidak menggunakannya seperti Construct, jadi Anda
tidak akan melihat game apa pun dari mesin itu yang dibuat dengan skrip biasa. Lainnya
(lebih waras, imo) mesin memiliki plugin seperti Unity dan UE4. saya sendiri
sangat suka menggunakan uscript & PlayMaker di Unity bersama reguler saya
kode karena sementara beberapa hal lebih mudah untuk dikodekan, banyak yang lebih mudah untuk
skrip keluar secara visual, terutama mesin negara karena dengan visual
scripter seperti PM itu memberi Anda banyak umpan balik dengan breakpointsw hanya saja
jauh lebih mudah untuk melihat proyek dari pandangan yang lebih luas.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung atau lihat di GitHub
https://github.com/godotengine/godot/issues/1220#issuecomment -209776732

Slapin, kamu benar. Tetapi Anda lupa bahwa pemrograman visual atau blok pemrograman memiliki tingkat kegagalan yang sangat rendah. Itu karena keterbatasan.
Ini pada dasarnya sama ketika Anda mengambil bahasa scripting yang sangat terbatas. Anda tidak dapat melakukan banyak kesalahan.

Saya pikir ini harus menjadi tujuan yang harus dicapai, bukan pertanyaan apakah Visual- atau Text-Scripting!

Jika Anda ingin membuat pemrograman lebih baik, buat alatnya lebih baik. Penyorotan kode, Penyelesaian Kode, Validasi Kode, Template Kode, juga. Jadikan debugger lebih baik dan buat Liveprogramming.
Saya selalu mencari lingkungan Liveprogramming yang stabil, tetapi sampai sekarang saya tidak menemukannya!

Jika Anda benar-benar ingin membuat Visual Scripting, buatlah seperti Stingray Engine. Anda dapat membuat CodeBlocks di Visual dan menghasilkan TextCode yang nantinya dapat Anda modifikasi, atau menulis TextCode yang nantinya dapat Anda gunakan sebagai Visual Blocks.

Saya tidak akan mengatakan itu sia-sia, tetapi saya akan mengatakan bahwa kita sedang berbicara tentang 2
produk yang sama sekali berbeda.

Jika Anda menjalankan studio, dan Anda membuat game dengan katakanlah 20-80 orang,
Anda menghabiskan 6 angka untuk biaya produksi setiap bulan, dan Anda membutuhkan
mesin untuk membuat game Anda, Anda menginginkan produk tertentu. Dalam hal ini, Anda
tidak peduli sama sekali tentang alat skrip visual, Anda peduli dengan yang lain
hal-hal, seperti seberapa produktif tim Anda dengan alat-alat mesin
(karena jika mereka melampaui jadwal selama satu bulan, Anda keluar ~$100rb). Itu
tim memiliki programmer, dan mereka akan jauh lebih produktif menulis kode
daripada menggunakan beberapa alat visual (lihat Vicious Engine untuk contohnya)

Di sisi lain jika Anda memiliki ide keren dan tidak benar-benar tahu caranya
tulis kode, Anda ingin produk lain, sesuatu untuk dilakukan prototipe cepat yang
Anda dapat berkeliling dan akhirnya memberikan kepada programmer untuk membuat yang sebenarnya
permainan.

Ini 2 produk yang berbeda, dan jika kita berdebat tentang mana yang lebih berharga
memiliki, kita harus mengakui itu. Saya akan mengatakan bahwa skrip visual
alat tidak benar-benar meningkatkan hingga lebih dari 1 orang membuat prototipe. Sebagai
segera setelah Anda ingin membuat permainan penuh, atau segera setelah tim Anda tumbuh menjadi 2-3
orang, Anda sudah membutuhkan bahasa pemrograman yang nyata. Jadi saya suka yang pertama
contoh lebih sebagai tujuan keseluruhan (kecuali jika Anda menginginkan produk ke-3, yaitu
"mesin yang dapat Anda gunakan untuk membuat game indie lengkap yang menghasilkan jutaan
tanpa menulis kode apa pun". Itu tidak ada).

Tapi kita bisa memiliki keduanya, dan saya tidak akan mengecilkan hati salah satunya. Sebuah visual
alat skrip akan membantu kami dalam jangka panjang, dengan membuat pengguna pemula
yang pada akhirnya akan bekerja di industri dan berada dalam posisi untuk memutuskan untuk
gunakan godot untuk game sungguhan, dan itu bagus. Juga, CTO Square Enix
bertanya kepada kami apakah mesinnya memiliki bahasa prototipe visual, jadi itu artinya
ada juga ceruk di perusahaan besar untuk hal semacam itu, mungkin yang
yang menghargai R&D dan memiliki tahapan panjang
praproduksi/prototyping/eksperimen dengan ide-ide baru, dll (dia juga mengatakan
kami bahwa game kami terlihat seperti game konsol dan bertanya (dua kali) negara mana
apakah kita pergi ke untuk belajar cara membuatnya :p).

Pada 14 April 2016 pukul 03:26, Sergey Lapin [email protected] menulis:

Hal nyata tentang skrip visual secara umum, itu adalah upaya yang sia-sia untuk
membuat pemrograman dapat diakses oleh non-programmer, yang sama sekali salah
mendekati.
Pemrograman visual lebih sulit daripada pemrograman teks biasa. Untuk membuatnya
lebih mudah Anda harus menulis banyak blok untuk setiap kasus dalam kehidupan secara tradisional
cara dan
biarkan orang-orang ini menggunakannya. Ini terbukti kurang efektif daripada meminta
programmer yang baik untuk menulis kode. Ungkapan "pemrograman bukanlah sebuah profesi,
semua orang bisa melakukannya" salah. Semua upaya pemrograman tanpa
pemrograman adalah pemborosan.

Adapun mesin negara - saya sedang berpikir untuk mengimplementasikan ini beberapa waktu
lalu, tapi itu tidak akan membantu program visual tinggi.
Ini dapat dengan mudah dilakukan untuk gim Anda menggunakan skrip alat dan editor simpul,
yang merupakan alat yang ampuh, banyak orang menggunakannya untuk alat permainan, seperti
editor dialog permainan.

Pada Kam, 14 April 2016 pukul 09:09, Aaron M [email protected] menulis:

Saya tidak ingin mengatakannya, tetapi itu adalah pandangan visual yang sangat sempit
alat skrip, Sergey. Adapun game yang telah sepenuhnya dibuat dengan
mereka,
beberapa mesin telah sepenuhnya memilih untuk tidak menggunakannya seperti Construct, jadi Anda
tidak akan melihat game apa pun dari mesin itu yang dibuat dengan skrip biasa. Lainnya
(lebih waras, imo) mesin memiliki plugin seperti Unity dan UE4. saya sendiri
sangat suka menggunakan uscript & PlayMaker di Unity bersama reguler saya
kode karena sementara beberapa hal lebih mudah untuk dikodekan, banyak yang lebih mudah untuk
skrip keluar secara visual, terutama mesin negara karena dengan visual
scripter seperti PM itu memberi Anda banyak umpan balik dengan breakpointsw itu
hanya
jauh lebih mudah untuk melihat proyek dari pandangan yang lebih luas.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung atau lihat di GitHub
< https://github.com/godotengine/godot/issues/1220#issuecomment -209776732

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung atau lihat di GitHub
https://github.com/godotengine/godot/issues/1220#issuecomment -209779422

Anda hanya berbicara melewati saya punto slapin, maksud saya, saya tidak pernah mengatakan apa-apa tentang desainer atau penyederhanaan, tetapi kemudahan penggunaan bahkan untuk programmer, yang telah saya alami kegunaannya. Ini tidak seperti Anda hanya bisa mengatakan itu buang-buang waktu ketika saya memiliki pengalaman anekdot yang menunjukkan sebaliknya. Saya lebih suka opsi yang tersedia _alongside_ scripting, Anda bertindak seperti saya hanya dapat memilih satu atau yang lain dan saya terpaksa menyerahkannya kepada artis saya. Tidak terjadi sama sekali.

Threadnya keren, banyak pendapat 😁

Milik saya sederhana. Kamu baik-baik saja!

Salah satu dari ide ini akan menjadi tambahan yang bagus untuk gdscript 😁

Saya berharap untuk mencobanya ketika mereka muncul.

Saya pikir gdscript juga bisa dilakukan dengan senang hati agar lebih ramah pengguna.

Beberapa node tidak didokumentasikan sepenuhnya. Banyak yang tidak memiliki deskripsi.
Godot dapat menggunakan beberapa fungsi pembantu untuk menyederhanakan pengembangan. Gamemaker gml adalah contoh yang bagus:
https://twitter.com/uheartbeast/status/724326557108461568

Saya pikir hal-hal dokumentasi adalah PITA utama di sini, dan hanya itu.
Pengembangannya sendiri cukup sederhana. Dokumentasi dan tutorial
benar-benar dibutuhkan. Jadi buat saja akun youtube Anda bermanfaat (atau blog, atau
posting saja di forum),
itu akan sangat membantu.

Pada Senin, 25 April 2016 pukul 09:35, Todor Imreorov [email protected]
menulis:

Saya pikir gdscript juga bisa dilakukan dengan senang hati agar lebih ramah pengguna.

Beberapa node tidak didokumentasikan sepenuhnya. Banyak yang tidak memiliki deskripsi.
Godot dapat menggunakan beberapa fungsi pembantu untuk menyederhanakan pengembangan.
Gamemaker gml adalah contoh yang bagus:
https://twitter.com/uheartbeast/status/724326557108461568

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung atau lihat di GitHub
https://github.com/godotengine/godot/issues/1220#issuecomment -214163012

Yah, saya punya beberapa pemikiran tentang ini.
Anda dapat membuat mesin lebih mudah untuk didekati dengan memasukkan sesuatu seperti skrip visual, dan itu akan bagus untuk semua seniman yang ingin masuk ke dalam pembuatan game tetapi tidak memiliki pengalaman pemrograman, tetapi itu mengundang sekumpulan orang lain--yaitu , orang-orang yang tidak memiliki keterampilan apa pun. Orang-orang yang pindah ke pemrograman dalam editor teks tidak akan pernah ada dalam agenda mereka, bahkan jika itu berarti permainan terakhir akan menderita. Orang-orang yang berpikir bahwa satu-satunya hal yang sulit dalam membuat game adalah pemrogramannya, dan bahwa dengan skrip visual, tiba-tiba batasan ini dicabut. Ini juga tidak jarang. Lihat saja semua mesin populer yang membuat hal-hal tertentu lebih mudah bagi non-programmer--banyak sekali shovelware. Saya tidak mengatakan Anda tidak boleh menyertakan skrip visual karena itu berarti kami berisiko mendapatkan shovelware, tetapi itu harus diterapkan dengan cara yang membuat orang-orang seperti ini tidak berpikir bahwa mereka hanya dapat menggunakan Godotengine untuk membuat shovelware tersebut.
Masalah saya yang lain adalah bahwa salah satu keunggulan Godotengine, dan banyak orang menyukai fitur ini, adalah ia bekerja sangat baik dengan git. Masalah dengan skrip visual adalah sering disimpan dalam beberapa format biner, dan itu adalah mimpi buruk untuk dikelola jika Anda menggunakan segala jenis revisi kode sumber. Jika Anda harus menerapkan skrip visual, maka itu harus disimpan dengan cara yang ramah teks. Dan jika itu tidak mungkin, sangat sulit. Saya lebih suka memiliki file proyek di Godotengine dalam format yang bersahabat dengan git daripada memiliki skrip visual yang tidak cocok dengan git.
Dan dilihat dari semua pekerjaan yang diperlukan untuk menerapkan sistem skrip visual, dan fakta bahwa Anda dapat membuat jenis game tertentu di Godotengine tanpa skrip visual tanpa kehilangan fungsionalitas, efisiensi, atau kinerja, apa salahnya jika hanya menerapkannya sebagai sebuah plugin? Saya tidak benar-benar melihat alasan mengapa itu harus menjadi bagian inti dari mesin.

Hanya untuk menambahkan 2 sen saya tentang skrip visual dan mengapa saya tidak menyukai ide itu:

Saya pikir kemampuan untuk menghubungkan node dalam file gdscript apa pun jauh lebih baik, dalam hal manajemen kode, dan kemahiran.

Misalnya, dengan skrip visual (atau menggunakan lembar acara yang mirip dengan C2), apa yang terjadi jika Anda memiliki lebih dari 1000 fungsi? Ini akan membuatnya jauh lebih buruk saya percaya untuk menavigasi melalui segala sesuatu. Saya sedang porting game HTML 5 Action RPG saya sekarang ke Godot (yang lebih dari 10rb + Baris kode dan lebih dari 500 fungsi). _(Ini pada dasarnya memiliki setiap fitur yang dimiliki Path of Exile, kecuali untuk animasi dan multipemain)_

Tidak mungkin ini bagi saya dengan skrip visual. Saya pikir kami, dan pengembang godot di sini harus lebih fokus pada fitur / pemampatan bug daripada lembar acara kode visual. Tapi itulah aku :)

Sunting: Seperti yang dikatakan beberapa orang lain, mungkin untuk proyek yang lebih kecil saya kira ... tapi sesuatu yang besar saya tidak bisa melihatnya berguna

Lembar acara di construct2 mendukung fungsi dan berfungsi sama seperti godots. Filter/kotak pencarian sederhana akan menyelesaikan semua fud yang Anda daftarkan.

Tetapi pengembang godot tidak ingin melakukan pendekatan lembar acara meskipun atm. Saya mendapat kesan bahwa itu lebih mungkin untuk mendapatkan sesuatu yang mirip dengan pendekatan cetak biru yang tidak nyata. Dengan cara itu pemrogram akan mendapat manfaat dari editor mesin negara yang ditambahkan ke gudang senjata mereka

Untuk mengatur kode skrip visual di vonstruct2 , Anda memasukkannya ke dalam grup yang dapat diciutkan. Ini adalah sesuatu yang bahkan gdscript tidak dapat melakukannya- Anda tidak dapat menciutkan blok kode. Jadi dalam beberapa hal, lembar acara memang memiliki keunggulan dibandingkan editor gdscript godots.

@reduz Saya melihat Data Murni dan cara mereka melakukannya sangat sederhana. Nah periksa ini

Seperti yang Anda lihat, mengetik "Bang" mengubah objek generik menjadi objek Bang.

Bagaimana jika visual scripting bisa menjadi perpanjangan dari GD Script. Cukup tempatkan node generik dan ketik Vector2 untuk ex dan itu akan menjadi objek Vector2. Jadi pada dasarnya setiap kelas/objek juga merupakan simpul.

Untuk menjalankan fungsi, saya pikir Anda bisa mendapatkan simpul lain yang bukan merupakan objek melainkan simpul proses dan Anda akan mengetikkan sesuatu seperti Vector2.dot dan simpul tersebut akan berubah menjadi simpul titik dengan 2 input dan 1 output.

skrip visual direncanakan di beberapa titik

Anda tidak mengecewakan :) <3

Karena sudah ada VisualScripting, apakah masalah ini harus ditutup?

Ya.

"Saya juga tersenyum dengan cara yang positif.
Karena akan sangat bagus bagi saya sebagai seorang gamer jika ada perusahaan sebesar Steam dengan banyak katalog game, open, dan DRM Free, yang dibuat oleh ribuan developer game yang hebat."
lihat saja gog, ini adalah toko yang menjual game gratis drm.

Menjawab di luar topik untuk pernyataan 2015, ayolah :)