Saya menggunakan Godot secara profesional selama lebih dari setahun.

Saya setuju dengan semua yang Anda katakan, kecuali:

Untuk beberapa orang, saya pikir kita harus menjaga cara saat ini

Jika kita memiliki kesempatan emas ini, mari kita rename semuanya. Itu termasuk Sprite2D dan MeshInstance3D.

Itu selalu lebih baik refactor menyakitkan penuh, banyak refactor menyakitkan parsial.

Berbicara tentang mengganti nama: https://github.com/godotengine/godot/issues/16863

@jahd2602 Saya tidak keberatan secara pribadi, kami dapat melakukan polling dalam kasus terburuk.

Saya pasti dapat melihat orang-orang terganggu dengan itu hanya karena fakta bahwa itu adalah inkonsistensi, tetapi kita setidaknya dapat melihat apakah mereka mayoritas atau minoritas.

@Zylann Saya tahu, jika kami memutuskan sesuatu di sini, kami akan memindahkannya ke sana.

Saya pikir sikap terhadap ruang nama picik. Masuk akal dari perspektif alur kerja mesin secara umum tetapi mengabaikan perspektif dari pembuat alat. Godot Unit Testing (GUT) oleh bitwes misalnya pecah karena konflik penamaan di salah satu update-nya. Ada kemungkinan hal ini dapat dihindari dengan namespace GUT khusus.

Saya juga ingin namespaces for Waiting And Testing (WAT) jadi saya bisa menggunakan nama kelas seperti Test (diakses melalui WAT.Test) sementara tidak menjalankan kerangka kerja lain (seperti GUT jika menggunakan GUT.Test) atau hanya skrip pengguna. Saya sudah mencoba beberapa kali menggunakan kelas WAT yang berisi semua skrip yang digunakan sebagai subkelas tapi itu hanya referensi siklik.

Jika kita ingin didorong untuk membuat alat dari dalam mesin, maka kita memerlukan alat untuk membuat alat tersebut di dalam Mesin meskipun itu tidak mutlak diperlukan untuk alur kerja mesin itu sendiri.

Singkatnya, sistem namespace khusus yang dapat diakses serta didefinisikan dari mesin (atau paling tidak skrip plugin) sehingga pembuat alat tidak berakhir berjalan di atas satu sama lain atau penggunaannya akan menjadi anugerah.

@CodeDarigan Saya mengerti itu memiliki manfaat dan saya tidak menyangkalnya, tetapi saya dengan tulus percaya bahwa biayanya lebih besar daripada mereka.

Tambahkan ke ini bahwa cukup banyak kami tidak memiliki keluhan signifikan dari pengguna GDScript, yang lebih memilih pendekatan saat ini, sehingga akan memaksa mereka ke worfklow yang tidak diinginkan dan mengetik lebih banyak kode dalam bahasa yang dimaksudkan untuk hanya menulis hal-hal cepat dan kotor dengan cepat. (Namun, pengguna C # tampaknya menginginkannya).

Inilah mengapa saya bermaksud bahwa mereka dapat ada sebagai metadata untuk binding bahasa skrip, dan kami bahkan dapat menambahkannya untuk GDNative C++. Hanya saja, jangan menambahkannya untuk mesin inti C++.

Navigasi -> Nagivagion3D
Apakah ini salah ketik?

@nitodico memang

@reduz Saya setuju dengan @jahd2602. Bahkan jika beberapa hal mungkin terlihat jelas, demi konsistensi, kita harus melakukan postfix dengan 2D atau 3D.

Saya masih memulai dengan Godot dan perubahan yang diusulkan terdengar masuk akal bagi saya -- menggunakan nama yang agak berbeda untuk varian 2D atau 3D dari sebuah node adalah sesuatu yang membuat saya sedikit kebingungan saat mempelajari yang mana akhirnya dan pindah ke Thing2D /Thing3D atau Thing/Thing3D terasa seperti peningkatan yang signifikan pada kejelasan dan pemahaman.

Tolong lakukan itu.

Tbh perubahan ini akan datang, jadi lebih baik melakukannya sekarang dan tetap melakukannya. Untuk 3d tidak ada banyak tuts jadi sekarang perubahan akan melakukan lebih sedikit kerusakan daripada dalam satu, dua tahun kemudian.

Mengenai material, alangkah baiknya jika ada beberapa jenis Legacy Material yang hanya menggunakan resource minimal, seperti difuse dan specular, ini akan berguna untuk game mobile 3D.

Saya juga mendukung penggantian nama menjadi 3D atau 2D secara eksplisit.

Mungkinkah nama aslinya masih ada sebagai alias untuk yang baru? Mereka akan disembunyikan dari editor sehingga nama lama tidak dapat digunakan (atau ditempatkan di bawah judul "usang"). Dengan begitu kode lama akan tetap berfungsi, tanpa perubahan dan tanpa memerlukan logika tambahan untuk mengonversi apa pun.

Peringatan dapat ditambahkan untuk kode menggunakan nama node yang tidak digunakan lagi dan kemudian dalam 4.1 atau 4.2 mereka dapat dihapus.

Jika ada dua versi dari sebuah simpul saya akan selalu menambahkan akhiran 2D/3D.

Juga, saya akan senang jika Label -> TextLabel. Saya menambahkan simpul sehingga saya dapat menampilkan beberapa teks, jadi saya mengetik teks di bilah pencarian dan tentu saja hanya RichTextLabel yang muncul yang mengingatkan saya bahwa simpul teks standar sebenarnya tidak memiliki Teks dalam namanya.

@Janders1800 begitulah cara kerjanya sekarang, semakin sedikit fitur yang Anda gunakan di SpatialMaterial, semakin kecil shader yang dibuatnya.

Saya orang 2d, jadi untuk node dengan aplikasi terutama 2d, menjaga nama node tanpa akhiran jika belum ada tampaknya baik-baik saja bagi saya. Ini sepertinya refactor yang lebih menyakitkan bagi pengguna 3D, tetapi sangat masuk akal di mana node tertentu hanya memiliki aplikasi 2d atau 3D untuk sebagian besar bahwa mereka mempertahankan nama yang lebih pendek untuk domain yang mereka maksudkan dan memiliki akhiran di tempat lain. Hal lain yang dapat disatukan akan menyenangkan untuk dilihat, khususnya Spatial .

Saya mendukung penggunaan akhiran 2D / 3D tanpa syarat juga.

Meskipun benar bahwa untuk beberapa node sepertinya kesempatan yang hilang untuk memiliki lebih banyak nama "alami", konsistensi menang.

Yang tidak saya sukai adalah StandardMaterial3D adalah yang non-ORM. Maksud saya adalah bahwa ORM lebih kuat didukung oleh standar (setidaknya RM, yang Anda miliki di glTF).

Tapi saya belum bisa menyarankan penamaan yang lebih baik.

Mungkin ini juga merupakan kesempatan untuk melakukan sesuatu tentang 'kanvas'. Saya menemukan konsep yang agak membingungkan di kali.

Saya tahu ini sulit, karena tidak memiliki padanan 3D: Adegan 3D hidup di node Spatial , tetapi kanvas dapat berisi campuran Node2D s dan Control s.

Namun, akan sangat bagus jika kita dapat mendefinisikan beberapa penamaan yang memungkinkan penggantian nama CanvasItemMaterial menjadi Material2D , sambil menjaganya tetap bermakna untuk 2D "murni" dan ranah GUI.

Saya tidak selalu menentang penggantian nama, tetapi nama aslinya masuk akal bagi saya, mungkin karena latar belakang saya.
Default dalam fisika atau teknik adalah "3D". Anda tidak mengatakan "tubuh kinematik 3D", Anda mengatakan "tubuh kinematik", kecuali jika Anda bekerja di ruang lain.
Namun, saya yakin tidak semua orang memiliki latar belakang yang sama atau bahkan setuju akan hal itu, karena bagaimanapun juga ini adalah mesin permainan dan tidak harus secara ketat mengikuti konvensi fisika atau teknik.

untuk kompatibilitas di masa mendatang, dalam gdscript

file gdscript...

memperluas Spasial
class_name Node3D

Dan seterusnya.

Pernahkah Anda berpikir untuk mengganti nama translation untuk simpul spasial menjadi position ?

@BeayemX Saya pikir terjemahan adalah istilah umum untuk ruang 3D, dan posisi umum untuk pengembang 2D :berpikir:

Saya tidak tahu apakah 4.0 akan menjadi yang terbaik untuk perubahan nama simpul, akan ada banyak hal yang harus ditangani dan ada banyak perubahan dari 2 menjadi 3, itu berarti mencela buku, video, kursus.
Bahkan dokumentasi tidak lengkap, dengan perubahan di pertengahan penyelesaian, perbaikan akan sangat memperlambat segalanya...

Saya mendukung penggantian nama node 3D seperti yang disarankan di sini. Saya tidak tahu seberapa besar masalah itu bagi pembuat tutorial. Paling tidak, memfaktorkan ulang basis kode yang ada seharusnya sepele. Di C# kita bahkan bisa menyalahgunakan ObsoleteAttribute dalam mode debug untuk membuatnya lebih mudah (meskipun tidak yakin apakah itu ide yang bagus):
[Obsolete("Use Node3D", error: true)] class Spatial { /* Nothing here */ }

Saya harap kami menambahkan ruang nama/kategori seperti yang dibahas di #18711. Saya ingin memisahkan C# API ke dalam ruang nama dan mungkin juga rakitan untuk memungkinkan pengguna memilih hanya yang mereka butuhkan.
Rencana saya untuk 4.0 adalah membuat kode sendiri tabel ruang nama jika tidak ada pilihan lain, tetapi saya lebih suka jika saya bisa mendapatkan informasi ini dari ClassDB.

@eon-s Saya rasa tidak... sementara translation secara teknis valid untuk mewakili koordinat, Godot adalah mesin pertama di mana saya melihat istilah yang berbeda digunakan di sini, jika tidak, saya selalu melihat position terlepas dari 2D atau 3D. Juga bagi saya translation dikaitkan dengan gerakan, dan bertentangan dengan istilah lain yang terkait dengan bahasa/transformasi, yang membuatnya aneh. Ini disebutkan di https://github.com/godotengine/godot/issues/16863 juga.

BTW, mengapa kita berencana untuk istirahat sesedikit mungkin? Saya mengerti mengapa orang tidak menginginkan lebih banyak kerusakan kompatibilitas, khususnya mereka yang membuat tutorial; tetapi jika kita tidak mengambil 4.0 sebagai peluang untuk mematahkan kompatibilitas, kapan kita akan melakukannya? #16863 sudah mengumpulkan banyak saran.

@neikeq tidak sabar menunggu 5.0? karena tidak ada fitur baru atau besar yang direncanakan, jika tidak orang akan berhenti membuat sesuatu dan membeli kursus untuk mesin yang mengubah bagian penting setiap 1 atau 2 tahun (untuk pembuat tutorial video ini berarti mengulang semua pekerjaan mereka) dan dengan beberapa bulan waktu peringatan ...

Saya mendukung penggantian nama untuk memiliki akhiran 2D/3D yang konsisten, dan saya setuju dengan banyak orang di utas ini bahwa itu harus dilakukan untuk semua node untuk konsistensi. Memiliki konvensi penamaan yang konsisten sangat membantu seseorang yang mempelajari mesin, atau seseorang yang berpindah dari sisi 2D ke 3D, atau sebaliknya.

@eon-s Tentunya menunggu hingga 5.0 berarti akan ada pekerjaan yang lebih besar yang perlu diperbarui?

Sebanyak tutorial yang indah untuk dimiliki, saya akan memilih untuk membuat mesin lebih mudah dipahami daripada membuatnya membingungkan demi tutorial yang ada. Semoga skrip fixit atau alias opsional (seperti yang telah dibahas di atas) dapat digunakan untuk memuluskan jalur peningkatan.

Saya menghargai perbedaan penamaan antara Node dan Spasial karena node Node tidak memiliki pengetahuan tentang ruang, memiliki Node, Node2D dan Node3D akan membingungkan. Kecuali Anda berencana untuk menyingkirkan Node, maka itu benar-benar masuk akal.

Saya karena hanya memiliki satu ranah 2D atau 3D harus menanggung dengan memiliki akhiran. Ini 2D saat ini dan kebingungan antara 2D dan 3D berakhir di sana.

Tolong jangan tambahkan akhiran 3D. Apakah itu benar-benar sepadan dengan sakit kepala untuk apa yang ditambahkannya? Apakah itu sepadan dengan biayanya? memperbarui semuanya atau memiliki tutorial yang sudah ketinggalan zaman? Tutorial youtube yang tidak dapat dimodifikasi dan ketinggalan zaman? Ini akan membawa lebih banyak kebingungan.

@dpalacio Saya menggunakan Godot hanya untuk beberapa bulan tapi saya pikir lebih jelas dan ringkas untuk menggunakan Node3D, Node2D, dan Node karena Spasial bertindak sebagai Node3D dan Node tidak memiliki informasi ruang. Saya pikir menambahkan sufiks untuk 3D akan jauh lebih mudah dipahami karena akan dinamai "berlawanan". Saya tahu itu tidak benar-benar berlawanan tetapi saya tidak tahu bagaimana mengekspresikannya dengan lebih baik karena bahasa Inggris bukan bahasa ibu saya. Masukan 3d versus 2d secara eksplisit tampak hebat bagi saya. Saya pikir ini akan sangat mudah bagi pemula, dan terlebih lagi bagi orang-orang yang memiliki kontak pertama dengan mesin game. Ruang nama juga bagus, terutama untuk proyek dan plugin besar. Nama yang saling bertentangan adalah sakit kepala. Sebagai pemula, saya pikir kerusakan kompatibilitas harus minimal dan otomatis karena sulit untuk terus mengubah proyek antar versi. Jika kita memiliki banyak perubahan, kita harus memiliki alat konversi otomatis dan dokumentasi untuk itu juga.

@neikeq ya, kategori harus diganti dengan namespace dan kita harus membuat yang tepat.

Persis apa yang saya pikirkan ketika saya mencoba Godot. OCD saya memberi tahu saya bahwa seharusnya begini.

Pernahkah Anda berpikir untuk mengganti nama translation untuk simpul spasial menjadi position ?

'posisi' terdengar lebih seperti posisi absolut daripada posisi relatif.
Menyebutnya posisi mungkin membantu pengembang baru tetapi pada akhirnya mereka akan menyadari bahwa itu harus disebut terjemahan.

Saya agak ragu dengan proposal ini sebagai seseorang yang menulis tutorial Godot dan menggunakan Godot untuk proyek saya yang berfitur lengkap.

Saya sepenuhnya mendukung perubahan nama node agar tetap konsisten, dan saya setuju dengan orang lain bahwa konsistensi itu penting, bahkan jika itu membuat segalanya mungkin sedikit lebih bertele-tele. Saya lebih suka harus menambahkan 3D atau 2D ke akhir/awal node jika itu membuat segalanya lebih konsisten dalam basis kode dan dokumentasi.

Berikut adalah beberapa node yang ingin saya ubah agar tetap konsisten:

• MeshInstance -> MeshInstance3D (agar tetap konsisten dengan MeshInstance2D )
• GridMap -> TileMap3D atau GridMap3D
• TileMap -> TileMap2D atau GridMap2D
• YSort -> YSort2D atau 2DSort (atau sesuatu untuk menunjukkan itu untuk 2D)
• ProximityGroup -> ProximityGroup3D
• GIProbe -> GIProbe3D (atau sesuatu untuk menunjukkan itu untuk 3D)
• ReflectionProbe -> ReflectionProbe3D (atau sesuatu untuk menunjukkan itu untuk 3D)
• SpatialMaterial -> PBRMaterial atau Godot3DMaterial atau StandardMaterial3D (hanya ide)
• Label -> TextLabel (Saya setuju dengan @MuffinManKen)

Berikut adalah pemikiran saya tentang proposal ini, dimulai dengan hal-hal positif:

Saya pikir perubahan ini akan membuat segalanya lebih mudah bagi mereka yang tidak memiliki pengalaman Godot, tetapi hanya mereka yang datang setelah perubahan ini dibuat. Terutama di sisi 3D, salah satu masalah terbesar yang saya temukan adalah sulitnya menemukan node yang Anda butuhkan, dan saya pikir mengganti nama node menggunakan skema penamaan yang konsisten akan membuat ini lebih mudah bagi semua orang.

Sering kali saya membantu orang lain dengan Godot, saya menemukan salah satu cara paling pasti untuk menemukan solusi adalah dengan melihat dokumentasi. Namun, karena nama node tidak selalu konsisten, menemukan halaman dokumentasi dapat menjadi sulit untuk node tertentu kecuali jika Anda sudah mengetahui nama node yang Anda cari. Perubahan dalam proposal ini akan membuat pencarian node yang benar menjadi lebih mudah.

Manfaat lain yang dapat saya lihat dengan perubahan ini adalah ia menetapkan standar tentang bagaimana node harus dinamai, yang dapat membantu pembuat plugin dan kontribusi Godot Engine di masa mendatang. Misalnya, jika saya membuat node decal (misalnya), maka dengan perubahan ini saya tahu saya harus menamainya seperti Decal3D bukan hanya Decal .
Ini mungkin juga membantu dengan penamaan kelas yang ditentukan GDScript/C#.

Ini juga akan membuat penulisan tutorial di masa depan sedikit lebih mudah, karena Anda tidak lagi harus menjelaskan bahwa Spatial pada dasarnya adalah Node2D dalam 3D.

Sekarang untuk negatifnya:

Salah satu masalah terbesar yang saya miliki dengan proposal ini adalah tampaknya terlalu cepat, terutama mengingat seberapa banyak Godot 3.0+ mengubah banyak hal belum lama ini. Saya pikir hanya beberapa game yang menggunakan Godot 3.0+ yang bahkan telah keluar, dan sangat sedikit game Godot 3D.
Banyak game 3D besar dan mengesankan di Godot Showcase masih belum dirilis, dan membuat perubahan besar seperti ini berarti proyek-proyek tersebut juga perlu diperbarui, yang selanjutnya menunda beberapa game Godot 3D yang sangat kuat.

Juga tutorial Godot 3.0+ masih keluar. Terutama di sisi 3D, segalanya mulai mendapatkan daya tarik. Sementara ini sebagian karena sisi 3D Godot menjadi lebih kuat di Godot 3.0+, saya khawatir banyak materi tutorial yang dibuat oleh penulis (atau sedang dikerjakan) tiba-tiba akan membutuhkan rewording besar-besaran untuk memperhitungkan perubahan nama. Ini akan memakan waktu lama untuk membuat tutorial baru, karena tutorial lama harus dihapus, dibuat ulang, atau ditulis ulang.

Perubahan penamaan juga akan membuat sumber daya yang ada yang bukan tutorial, hanya solusi sederhana yang ditemukan untuk masalah, tiba-tiba menjadi usang. Sementara sisi 2D Godot bisa dibilang cukup kuat dan mungkin bisa beradaptasi dengan cepat, komunitas yang menggunakan sisi 3D terasa lebih kecil. Dengan mengubah nama node, saya khawatir ini akan menghambat pertumbuhan pengguna 3D Godot dan kemampuan untuk menemukan solusi untuk masalah terkait 3D.

Saya setuju dengan @eon-s: tidak bisakah perubahan ini menunggu sebentar? Hal-hal sudah berubah cukup dramatis, setidaknya di basis kode, dengan Godot 4.0. Saya pikir menambahkan perubahan besar lainnya hanya akan membuat pengembangan lebih sulit dan mengatur ulang banyak kemajuan yang dibuat orang dengan sisi 3D Godot.

Setelah Godot 4.0 keluar, saya pikir mengubah nama node di versi 4.1 atau 5.0 akan sangat baik, tetapi menurut saya menambahkan perubahan besar seperti ini akan lebih berbahaya daripada membantu.

Satu hal yang mungkin membuat transisi ini lebih baik adalah adanya alias/masa transisi, mungkin dari Godot 4.0 ke Godot 4.1 misalnya. Ini tidak akan membuat tutorial dan sumber daya (terutama yang 3D) menjadi usang secara instan dan akan memberi setiap orang kesempatan untuk beradaptasi dengan perubahan yang akan datang sambil tetap dapat memanfaatkan perubahan di Godot 4.0.

Menggunakan alias/periode transisi akan memungkinkan perubahan yang melanggar kompatibilitas dibuat tanpa tiba-tiba memaksa semua orang untuk memperbarui sekaligus. Ini juga akan memungkinkan perubahan yang melanggar kompatibilitas dibuat lebih sering, karena secara teoritis setelah sistem siap untuk transisi, sistem dapat digunakan lagi untuk perubahan yang melanggar kompatibilitas di masa mendatang. Ini akan membuat segalanya lebih mudah ke depan dengan perubahan yang tercantum di #16863.

TLDR: Saya setuju dengan perubahan, saya pikir itu harus menunggu sampai Godot 4.1 atau sistem/periode transisi harus dibuat untuk memberi semua orang waktu untuk menyesuaikan diri dengan perubahan.

Terlepas dari bagaimana proposal ini berakhir: Saya pikir Godot 4.0 akan menjadi hebat dan saya menantikannya

@reduz saya katakan

Saya bukan penggemar berat membuat semua simpul 3D diakhiri dengan "3D", tapi tentu saja, jika semua orang menginginkannya. Saya pikir tidak apa-apa menyimpan nama yang berbeda daripada selalu memiliki akhiran (mis: TileMap dan GridMap)

Saya lebih suka "posisi" daripada "terjemahan". Yang terakhir dapat dikacaukan dengan lokalisasi & bahasa, dan yang pertama segera jelas dan ramah bagi pemula. Namun, bukankah Godot sudah menggunakan "asal" di sebagian besar tempat untuk ini?

Saya juga setuju dengan @neikeq bahwa layak untuk merusak kompatibilitas jika itu adalah perubahan yang bermanfaat untuk proyek baru. Saya pribadi akan senang melihat sebagian besar hal di #16863 diimplementasikan.

(btw mengapa Sprite3D ada padahal itu hanya quad mesh?)

@TwistedTwigleg Baca posting saya, proyek 3.0 akan terbuka dengan baik di 4.0 jika sistem kompatibilitas internal ditambahkan ..

Perubahan yang bagus, sebagai seorang programmer, saya senang melihat nama untuk pasangannya sesimetris mungkin

Bisakah Anda menjelaskan apa arti tekstur gaya ORM secara lebih rinci?

@reduz adalah satu-satunya perbedaan antara materi spasial standar dan yang ORM, bahwa Anda hanya memiliki satu saluran tekstur (bukan 3 seperti saat ini) dengan ORM? Apakah Anda masih memiliki akses ke parameter yang sama (dalam logam dan kekasaran) seperti specular dan pengganda? Tidak sering digunakan tetapi terkadang digunakan untuk men-tweak.

Saya menyukai ide itu, tetapi bertanya-tanya apakah itu berlebihan untuk memiliki 2 jenis material untuk perubahan sekecil itu. Mungkinkah ada sakelar untuk beralih antara 1 saluran tekstur untuk mode ORM atau 3 untuk gaya yang ada, menggunakan satu bahan?

Saya juga baru-baru ini menempatkan saluran kedalaman (tinggi) ke saluran alfa peta ORM saya untuk mendapatkan lebih banyak jarak tempuh dari tekstur. Kemudian Anda dapat melakukan sebagian besar tekstur hanya dengan menggunakan 3 tekstur...albedo/normal/ORM(H). Ini bisa bermanfaat untuk ditambahkan secara default (kecuali kami mendapatkan opsi 16bit untuk peta ketinggian, di mana Anda ingin menggunakan yang terpisah). Jika 4.0 akhirnya mendapatkan tessellation/displacement, saluran ketinggian akan jauh lebih penting daripada saat ini.

Dan berbicara tentang itu, itu juga akan menjadi kesempatan yang baik untuk mengubah penamaan saluran DEPTH ke HEIGHT di 4.0 dan membuatnya menggunakan kebalikan dari apa yang saat ini digunakan (yaitu putih adalah permukaan yang ditinggikan dan hitam tersembunyi). Ini akan membuatnya sejalan dengan penyaji dan mesin permainan lainnya, dan yang lebih penting lagi dengan alat seperti Substance, Quixel, dan Marmoset.

Saya lebih suka sufiks eksplisit untuk node 2D dan 3D, dan tidak ada sufiks jika tidak berlaku. Saya juga ingin node "Kontrol" dipisahkan sepenuhnya untuk node "Node2D" (keduanya saat ini dikelompokkan di bawah "CanvasItem").

Tentang translation versus position , saya akan memilih yang pertama dalam 2D ​​dan 3D.

position terlihat lebih ramah, tetapi berhenti masuk akal setelah leluhur memiliki beberapa rotasi atau skala.

Mengenai kompatibilitas, tahap transisi harus berlangsung untuk semua rilis 4.x untuk memberikan banyak atau waktu untuk tutorial, pengguna, dan proyek. Nama-nama baru harus menjadi warga negara kelas satu dan didorong, tetapi yang lama harus bekerja, dengan beberapa mekanisme editor untuk memberi tahu orang-orang tentang perubahan itu.

Saya benar-benar mendukung perubahan yang disarankan selama itu dilakukan dengan cara yang memudahkan pengguna akhir untuk memperbarui kode yang ada--baik kode mereka sendiri atau dari tutorial dan dokumentasi yang ada--melalui semacam alat seperti yang disebutkan. Karena kekurangan alat seperti itu, saya cenderung setuju bahwa kita akan segera menumpuknya setelah perubahan besar di v2 ke v3.

@TwistedTwigleg tentang rilis game 3d, itu karena kami menunggu 4.0 dan Vulcan

Saya juga akan meninjau Control nama node... dan dokumentasi sebaris.

Terkadang saya bertanya-tanya apa perbedaan antara AcceptDialog dan ConfirmationDialog , dan sama dengan PopupPanel , PopupDialog , PopupMenu ... harap ini membantu!

Sebagai tutor dan kontributor dokumen, saya akan mengatakan silakan! Saya tidak keberatan memproduksi lebih banyak konten jika perubahan memudahkan semua orang untuk belajar dan memahami mesin di masa depan. Lebih baik lakukan perubahan seperti ini secepatnya juga.

Datang terlambat ke pesta, tetapi beberapa klarifikasi agar semuanya tetap terkendali:

• Harap beri komentar hanya tentang proposal untuk mengganti nama node, dan implikasi teknisnya tentang cara menjaga kompatibilitas, dampaknya pada proyek yang ada, tutorial, pembuat konten, dll.
• Ini bukan tempat untuk membahas poin-poin spesifik dalam API yang harus dipertimbangkan untuk penggantian nama. Jika kami memutuskan untuk menggunakan penggantian nama besar-besaran ini, kami akan meninjau seluruh API dalam spreadsheet untuk memastikan bahwa kami memiliki nama yang konsisten. Untuk hal-hal tertentu seperti metode, properti, atau kelas yang harus diganti namanya di luar apa yang dibahas di sini, lihat #16863.
• @RandomShaper @fracteed @fire @reduz Silakan pindahkan diskusi tentang materi standar ke masalah khusus.

Halo,
Mengapa tidak mengikuti praktik API lain dan membuat dekorator Usang/Usang untuk kelas (atau bahkan metode), yaitu nama lama hanyalah alias/penunjuk ke yang baru. Ini akan menghentikan perubahan yang melanggar dan memungkinkan nama-nama tersebut dihapus di versi 5 sehingga lebih sedikit orang yang akan terpengaruh atau bahkan menyadarinya.

Menggunakan dekorator juga dapat memberikan dua manfaat lain:

1. IDE dapat dengan mudah mengambil tag ini dan menampilkannya di jendela pemilihan simpul, misalnya, daripada hanya mengatakan 'Spasial', ia bisa membaca 'Spasial (penggunaan Node3D usang)'.

2. Dekorator kemudian bisa menjadi peringatan bawaan yang ditampilkan di editor kode.

Plus itu tidak menghentikan siapa pun membuat alat penggantian nama ...

Beberapa pemikiran:

Saya setuju dengan penggantian nama node, serta beberapa metode dan properti (lihat daftar saat ini di #16863) untuk meningkatkan konsistensi dan membuat API lebih mudah dipelajari dan digunakan. Memperjelas perbedaan 2D / 3D tampaknya merupakan ide yang bagus, dan jika dilakukan harus dilakukan secara konsisten (misalnya juga MeshInstance3D seperti yang disebutkan). Saya menyarankan agar kita menggunakan spreadsheet untuk mendaftar semua Node saat ini dan apa nama baru mereka di 4.0 seharusnya - dan kita dapat bersepeda di sana tentang node tertentu seperti TileMap/GridMap. Saya akan membuat spreadsheet ini dalam beberapa hari mendatang jika kami mengonfirmasi bahwa ini adalah cara yang kami inginkan.

Namun, kita harus berusaha untuk membatasi kerusakan kompatibilitas sebanyak yang kita bisa. Seperti yang disebutkan Juan, kami dapat memiliki penggantian nama kompatibilitas di internal mesin sehingga adegan lama dapat dimuat dan dikonversi, tetapi itu tidak cukup.

Sebagai @RandomShaper dan @chucklepie disebutkan, kita harus menambahkan alias usang untuk semua node, metode, properti, konstanta, sinyal, dll yang kami mengubah nama, dengan dekorator properti / metadata yang akan menandakan mereka sebagai usang dan mendorong pengguna untuk perubahan kode mereka. Menggunakan informasi ini di IDE harus memungkinkan pengguna untuk mengikuti tutorial 3.x di 4.0 tanpa masalah, sambil belajar dengan mudah tentang nama-nama baru saat mereka pergi.

Untuk melakukannya, kita memerlukan metode pembantu yang memungkinkan kita mendefinisikan alias yang tidak digunakan lagi saat mendaftarkan binding. #23023 adalah upaya pertama untuk menambahkan antarmuka seperti itu, tetapi masih perlu ditinjau, digabungkan, dan mungkin diperluas jika tidak cukup untuk apa yang kita perlukan di 4.0. Alias ​​​​yang tidak digunakan lagi itu dapat disimpan untuk seluruh siklus rilis 4.x, dan dijatuhkan di 5.0.
Saya akan menentang penggantian nama yang melanggar kompatibilitas sampai kami memiliki antarmuka ini dirancang dan digabungkan dengan baik, jadi siapa pun yang tertarik dengan ini dipersilakan untuk mencoba PR ini dan menyarankan perubahan jika diperlukan.

Adapun ketika , saya bersikeras bahwa jika kita ingin merusak kompatibilitas lagi, ini sekarang. Menunggu 5.0 tidak masuk akal, karena akan membuat lebih banyak konten menjadi usang begitu kita mencapai 5.0, dan itu tidak akan membantu menggambarkan Godot sebagai alat pengembangan yang stabil jika kita merusak kompatibilitas dengan (semoga) banyak game hebat yang sedang dikembangkan dengan Godot 4 .x.

Basis pengguna Godot kurang lebih berlipat ganda setiap tahun, sehingga setiap tahun yang berlalu membuat pemfaktoran ulang menjadi kurang realistis, karena pada akhirnya kelembaman basis pengguna yang besar melebihi manfaat dari melanggar kompatibilitas. Jika mesin lain seperti Unity atau Unreal tampaknya relatif stabil dalam hal API dibandingkan dengan Godot, itu bukan karena mereka tidak memiliki hal-hal yang ingin mereka refactor atau rename, tetapi karena mereka tidak mampu melakukannya. Kami masih bisa, untuk saat ini, jadi kami harus menggunakan kesempatan itu. Itu sama untuk Godot 3.0 dan komunitas keluar darinya relatif tanpa cedera, meskipun kami memiliki sebagian kecil pengguna yang tetap menggunakan 2.1 karena mereka tidak mampu melakukan porting ke 3.0. Untuk 4.0, cakupan perubahan tersebut diharapkan akan jauh lebih sedikit, dan pekerjaan porting apa pun harus langsung dilakukan, tetapi komunitas telah tumbuh berlipat ganda sementara itu, sehingga dampak dari kerusakan compat akan sama besar atau lebih besar daripada 3.0 di istilah gambar/akumulasi gangguan pengguna :)

Saya pendukung besar melanggar kompatibilitas.
Mengapa ini tidak menjadi masalah: jika pengembang mengeluarkan game mereka di versi yang lebih lama, kemudian terus mengembangkan versi mesin yang lebih lama, tidak ada yang memaksa pengembang untuk bermigrasi ke versi baru. Juga: tetap tawarkan versi yang lebih lama untuk diunduh persis untuk tujuan ini.
Proyek baru dapat dimulai dalam versi baru mesin dan kemudian tergantung pada apakah pengembang memiliki kesabaran untuk mempelajari kembali cara kerja mesin.
Dalam hal meningkatkan kegunaan mesin, kesabaran untuk mempelajari kembali seharusnya tidak menjadi masalah, jika tujuannya adalah untuk menjadi mesin yang paling ramah pengguna atau bertenaga.

Sedangkan untuk rename, ada baiknya mengurangi learning-curve jika ada pola dalam materi yang akan dipelajari. Misalnya, Node2D vs Node3D, dll untuk semua node lainnya. Jika terlihat seperti bebek, Anda tahu bagaimana kelanjutannya, kemungkinan besar itu bebek, atau simpul dalam hal ini.
Otak manusia bekerja sebagai komputer kuantum yang mengoptimalkan, yang belajar dengan menghubungkan keadaan energi terendah dari sistem satu sama lain untuk menciptakan jalur logis di antara ide-ide. Jika ide-ide yang akan dipelajari serupa, tingkat energi terendah mereka lebih dekat satu sama lain, yang membuatnya lebih mudah untuk menghubungkan (dan mengingat) mereka, yang menjelaskan mengapa lebih mudah bagi siswa untuk memahami 3D jika mereka telah diajarkan 2D sebelumnya . Jika nama node mencerminkan kesamaan di antara mereka, akan lebih mudah untuk mempelajari dan memahami bagaimana tipe baru harus digunakan jika pengetahuan ada pada tipe yang sama.

Saya katakan lanjutkan dan refactor dan hancurkan kompatibilitas dengan cara apa pun yang Anda inginkan. Bahkan jika Anda kehilangan beberapa pengguna, Anda akan mendapatkan lebih banyak lagi dengan meningkatkan keramahan pengguna dan mengurangi kurva pembelajaran.

Sehubungan dengan ini, ambil Blender 2.80 misalnya. Bandingkan tampilan dan perilakunya sekarang dengan sebelumnya. Ini adalah perubahan besar yang memaksa banyak pengembang untuk mempelajari kembali cara kerja perangkat lunak. Sekarang pikirkan berapa banyak pengguna yang dimiliki Blender. Dibandingkan dengan Godot, mereka sangat besar, namun mereka mengubah perangkat lunak mereka secara drastis. Mengapa? Karena dalam jangka panjang, selalu lebih menguntungkan untuk mengurangi kurva pembelajaran dan meningkatkan keramahan pengguna, bahkan jika itu berarti kehilangan beberapa pengguna yang tidak memiliki kesabaran untuk beralih ke alur kerja baru.

Pada keseimbangan saya tidak mendukung perubahan yang melanggar dalam kasus ini.

Saya dapat memahami rasa frustrasi yang dirasakan dengan konvensi penamaan yang telah tumbuh secara organik, tetapi saya tidak melihat ada yang cukup membenarkan perubahan luas dan melanggar.

Saya siap untuk mencela API yang ingin kami tinggalkan (dan menandainya pada waktu kompilasi & dalam dokumen), tetapi idealnya nama simpul lama akan terus berfungsi seperti sebelumnya.

Mungkin, dalam waktu beberapa tahun, kita dapat menanyakan apakah sudah waktunya untuk menghentikan nama node lama karena telah menjadi sama sekali tidak menyakitkan. Sampai saat itu saran saya adalah menambahkan nama baru sesuai keinginan (saya tidak memiliki pendapat yang kuat tentang itu) dan hindari melanggar kompatibilitas ke belakang.

@fracteed Sebenarnya memiliki kedalaman di saluran tekstur lain mungkin bukan ide yang bagus, karena pemetaan paralaks melakukan banyak ketukan pada tekstur itu, memaksa untuk mendapatkan RGB yang tidak perlu setiap saat. Jika Anda menggunakan tekstur skala abu-abu tunggal, Godot akan memampatkannya menjadi setengah ukuran, menghemat beberapa bandwidth.

Memiliki mode ORM dalam materi standar mungkin merupakan ide yang bagus juga, perlu memeriksanya.

@chucklepie Masalahnya adalah tidak semua bahasa mendukung alias kelas seperti typedef. C# adalah salah satunya.

@reduz ah, saya tidak menyadarinya, senang mengetahuinya. Masalah yang lebih penting adalah mengalihkan saluran kedalaman ke ketinggian untuk 4.0, jadi semoga Anda mempertimbangkan untuk mengubahnya.

mengedit. maaf Akien, baru lihat komentarmu setelah memposting ini...

@neikeq Masalahnya adalah tidak semua bahasa mendukung alias kelas seperti typedef. C# adalah salah satunya.

Saya tidak tahu bagaimana pustaka C++ asli diimplementasikan, tetapi saya lebih mengacu pada mekanisme untuk melakukan dekorasi ini pada level C++ asli sehingga tidak masalah apa pengikatan bahasa hulu. Jika itu tidak memungkinkan, maka ikatan untuk setiap bahasa dapat dengan mudah disesuaikan ke suite (misalnya menggunakan atribut dalam C#, dll).

@ gerald1248 Baca posting saya, tidak ada tempat yang saya sebutkan itu akan rusak, proyek yang dibuat di 3.x akan terus bekerja dengan menggunakan alias saat memuat dan di skrip. Menggunakannya akan memicu peringatan penghentian, tetapi proyek Anda akan terus berfungsi.

Saya penggemar berat

Navigasi -> Nagivagion3D

ganti nama. Saya mendukung permintaan ini!

@reduz berkata:
@TwistedTwigleg Baca posting saya, proyek 3.0 akan terbuka dengan baik di 4.0 jika sistem kompatibilitas internal ditambahkan ..

Sayang sekali, saya melewatkan bagian posting itu.

Sistem kompatibilitas internal akan membantu migrasi, dan pasti menempatkan saya lebih pada sisi "buat perubahan", terutama jika dikombinasikan dengan sesuatu seperti #23023. Mengetahui sesuatu yang direncanakan untuk proyek sebelum perubahan ini baik untuk didengar dan meredakan banyak kekhawatiran yang saya miliki tentang proposal ini.

@Norrox berkata:
@TwistedTwigleg tentang rilis game 3d, itu karena kami menunggu 4.0 dan Vulcan

Itu adil.
Terutama mengingat peningkatan pada sisi 3D Godot yang hadir di Godot 4.0, menunggu mungkin bukan hal yang buruk untuk proyek berat 3D.

diferensiasi 3d dan 2d sudah konsistensi jelas . Node 3d berwarna merah muda, node 2d berwarna biru, dan node ui berwarna hijau. akan selalu ada pengguna yang memiliki masalah dengan penamaan. ini adalah masalah yang tidak pernah berakhir dan merupakan masalah yang berlipat ganda berdasarkan ukuran komunitas.

sehubungan dengan perubahan yang disarankan dalam OP: node 2d sudah memiliki akhiran "2D" yang diterapkan, yang _secara inheren berarti rekan-rekan mereka adalah 3d_.

namun, saya mendukung perubahan seperti Label menjadi TextLabel . ( @MuffinManKen membuat poin yang bagus)

Saya mendukung penuh pada dasarnya semua yang ada di sini, tetapi sehubungan dengan pertanyaan "Sprite2D/Sprite3D", saya akan menyarankan untuk meninggalkan Sprite sebagai Sprite, jika tidak ada alasan lain selain sufiks 2D yang menambah jumlah kekacauan, IMO.

Seperti @girng mengatakan, diferensiasi 2D / 3D sudah cukup jelas karena warna-coding, jadi kita tidak perlu berusaha keras kebingungan menghindari. Dari perspektif pengembang Godot, saya pribadi tidak akan menikmati -2D ditempelkan ke setiap node yang tidak diganti namanya dalam proyek saya. :D

Apakah kode warna itu membantu orang dengan berbagai bentuk buta warna?
Ini jelas tidak membantu saat Anda mengetik kode (sebagai lawan menambahkan node dari dialog).

@reduz terima kasih atas balasan Anda. Saya menyadari itu untuk versi utama dan dengan demikian sepenuhnya baik-baik saja dalam arti semver. Secara pribadi saya akan menghindari membuat perubahan seperti ini bahkan untuk versi utama, tetapi saya sadar Anda memiliki pemahaman yang lebih baik tentang apakah ini akan menjadi masalah atau tidak. Saya hanya melihat sejarah perubahan besar di seluruh versi utama (python2 ke python3 misalnya) dan biasanya saya lebih suka hidup dengan inkonsistensi (atau nama node baru ditambah node lama yang sudah usang). Either way saya mencintai Godot dan akan terus menggunakannya, apa pun perubahan yang melanggar mungkin ada.

Tapi sekali lagi, jangan ragu untuk menyarankan jika Anda lebih suka sesuatu yang lebih eksplisit dan membuat semuanya selalu 2D/3D.

eksplisit lebih baik daripada implisit.

@girng @AlexHoratio Node yang memiliki warna berbeda di editor tidak membantu saat Anda menulis kode. Saya pikir di sinilah kebingungan muncul.

(Saya masih tidak mengerti mengapa Sprite3D perlu ada sama sekali, mesin lain hanya menggunakan mesh quad untuk tujuan yang sama, akan lebih mudah jika Sprite secara eksklusif merupakan istilah 2D).

@gimg , @AlexHoratio Jangan lupa bahwa 4,5% dari populasi juga buta warna :stuck_out_tongue:

Saya pikir mengganti nama adalah ide yang bagus.
Transisi dari 2D ke 3D akan menjadi jauh lebih mudah. Setidaknya untuk orang yang memulai dengan 2D (dan mungkin juga sebaliknya)

jelas ada masalah, dan komunitas menganggap itu ide yang bagus. saya hanya bias dengan godot dan terlalu terikat secara emosional. berada dalam keadaan ini menghasilkan pemikiran yang tidak benar-benar masuk akal bagi orang lain, tetapi masuk akal bagi saya, dengan cara yang indah . Sulit untuk dijelaskan. terima kasih telah membiarkan saya menyuarakan pikiran saya

Saya setuju dengan konsensus umum di sini bahwa mengganti nama mereka untuk konsistensi bermanfaat. Saat ini dapat memberikan kesan eksternal bahwa satu set node adalah "kelas pertama" dan yang lainnya adalah "kelas kedua", atau bahkan mungkin diretas berdasarkan yang pertama.

Saya pribadi berpikir Sprite -> Sprite2D akan menjadi korban malang dari penggantian nama eksplisit yang sepenuhnya ketat, tetapi saya kira saya selalu dapat secara manual mengganti namanya menjadi Sprite di setiap adegan yang saya buat sampai saya lelah itu.

Saya pikir itu tidak masuk akal bahwa CanvasLayer dan CanvasItem tidak dikelompokkan, dan Node2D ada di dalam CanvasItem dengan Kontrol, seperti yang ditunjukkan orang lain.

Saya tahu @akien-mga mengatakan bahwa ini hanya untuk mengganti nama node, tapi saya pikir setidaknya perdebatan tentang position vs translation ikut bermain di sini. Saya pikir tujuan mengganti nama node agak datar jika API mereka berbeda secara signifikan (kecuali perbedaan antara sistem koordinat dan sejenisnya,) jadi mereka pasti harus sama, apa pun itu. Saya akan memilih "posisi" sebagai cara untuk pergi ke sini, ada komentar tentang itu menyesatkan dibandingkan dengan "terjemahan". Saya akan mengatakan bahwa "terjemahan" menyesatkan karena menyiratkan transformasi atau gerakan daripada sekadar menjadi koordinat. Posisi secara intuitif relatif, imo (Anda tidak meluruskan kursi Anda sehubungan dengan arah kompas, Anda melakukannya sehubungan dengan dinding ruangan.)

Saya pikir variabel harus diberi nama posisi untuk keduanya, tetapi fungsi translate harus tetap, mengubah move_local fungsi dalam Node2D menjadi translate_local , dokumentasi bahkan menyebutnya menerjemahkan. Saya akan tetap menggunakan move untuk simpul terkait fisika, untuk membedakan antara gerak fisika dan terjemahan geometris.

Banyak dari paruh kedua ini juga relevan dengan #16863

Juga @reduz , saya pikir ketika C# mendapatkan fungsionalitas di mesin, semakin banyak orang akan menginginkan ruang nama untuk C#, dan begitu mereka berada di C#, saya dapat membayangkan banyak pengguna gdscript ingin menggunakannya dan tidak harus beralih bahasa untuk fungsionalitas. Saya pikir ruang nama benar-benar penting untuk dukungan C# akhirnya, untuk gdscript manfaatnya jauh lebih tidak dramatis tetapi itu akan membuat paket plug and play menjadi mungkin tanpa khawatir pengguna.

Saya baru saja memikirkan sebuah ide, jika ini diterapkan, kita dapat memiliki pengaturan editor yang disebut "Nama node sederhana", yang berarti bahwa node yang baru dibuat tidak memiliki akhiran dalam namanya, misalnya, membuat "Whatever2D" baru akan mengaturnya nama menjadi "Terserah" tetapi skrip pada simpul itu masih akan mengatakan "memperpanjang Apapun2D" dll. Ini akan sama dengan membuat simpul kemudian mengganti namanya secara manual.

Ini akan menghindari kekacauan melihat nama default "2D" atau "3D" di Hierarki jika pengguna memilih untuk mengaktifkannya, tetapi tetap akan membuat kode lebih konsisten dan eksplisit. Tanpa node 3D yang berisi "3D", ini akan membingungkan, tetapi akan masuk akal dengan "3D" di akhir secara default.

@aaronfranke Saya pikir itu ide yang cukup solid. Sepertinya kompromi yang memungkinkan untuk menjaga basis kode tetap konsisten dan jelas sambil memungkinkan pengguna untuk menjaga kekacauan yang berlebihan dari hierarki mereka. Saya pikir banyak keberatan terhadap gagasan penggantian nama berasal dari efeknya pada hierarki, daripada keberatan terhadap nama itu sendiri.

@aaronfranke Saya tidak suka menjadi orang yang merusak ide yang masuk akal, tetapi nama simpul yang berbeda antara sistem yang berbeda akan membuat berbagi file skrip gd menjadi tidak mungkin. Karena semua plugin diekspor sebagai file dan adegan gscript mentah, mereka akan berhenti bekerja, jika dikembangkan pada sistem dengan pemetaan node yang berbeda. Untuk menghindari hal ini, semua file gdscript dan file adegan perlu menyertakan pemetaan nama node untuk menerjemahkan file untuk sistem baru. Saya cukup yakin bahwa overhead semacam ini sangat tidak disukai @reduz.

@aspenforest Saya tidak berpikir menambahkan pemetaan akan menjadi overhead yang besar tapi mungkin saya naif karena saya tidak tahu arsitektur mesinnya

Apa yang dapat dengan mudah dibuat dari ide @aaronfranke adalah dengan mengganti nama node pada pembuatan. Mirip dengan pengaturan yang ada di ProjectSettings yang mengubah nama simpul yang baru dibuat menjadi snake_case atau spine-case (jadi simpul MeshInstance akan secara otomatis dinamai mesh_instance alih-alih MeshInstance ), pengaturan lain dapat ditambahkan untuk akhiran simpul, yang akan menghapus akhiran "2D" atau "3D" dari nama simpul (jadi simpul Sprite2D baru diberi nama hanya Sprite ).

Tidak ada yang pernah mengeluh tentang KinematicBody2D atau Particles2D dan sejenisnya memiliki akhiran "2D" yang tidak perlu, jadi saya tidak mengerti mengapa kita harus menambahkan fitur untuk mengatasi penambahan akhiran "3D" pada rekan-rekan mereka ... Jika pengguna benar-benar tidak ingin sufiks ini ada di tempat pertama, maka proposal ini mungkin harus dibuang, tidak bekerja dengan cara untuk mengganti nama node di IDE untuk beberapa alasan kosmetik ...

@akien-mga ini tidak akan banyak "mengatasi" nama simpul baru, bagi saya ini lebih merupakan saus di atas, sesuatu yang hanya non-retas dengan skema penamaan yang konsisten. Saya ingin sufiks di sana, untuk saat saya mengkode, menambahkan node, atau mencari dokumentasi. Tapi begitu mereka berada di sebuah adegan, saya tahu apa itu, dan banyak hal akan mendapatkan nama khusus.

Jika harus memilih antara membuat nama konsisten dan mendapatkan fitur editor untuk membuat nama menjadi sederhana, saya akan memilih yang pertama, tapi saya pikir @aaronfranke mendapatkan fakta bahwa setiap keberatan terhadap proposal ini pada dasarnya kosmetik, dan sarannya membahas bahwa meskipun tidak mengorbankan konsistensi di bawah tanah, ide ini sebenarnya.

Saya benar-benar berpikir bahwa menambahkan fitur editor akan menjadi masalah/pr sendiri, bukan sesuatu yang diperlukan untuk memasukkan ini.

Saya awalnya menghindari SpatialMaterial karena memiliki nama yang aneh. Tapi itu kelas yang sangat kuat. Alih-alih, saya baru mulai belajar cara membuat kode shader dengan albedo+ao+normal yang dipetakan triplanar. Kemudian saya menemukan semua pekerjaan yang telah saya lakukan sia-sia karena saya dapat melakukan semua itu di SpatialMaterial dan kemudian mengubahnya menjadi kode dan mendapatkan hasil yang lebih baik. Jadi butuh nama yang lebih ramah.

+1 untuk nama 2D/3D eksplisit.

Saya memiliki pertanyaan tentang satu simpul yang saya anggap dapat ditandai untuk dihentikan di masa mendatang, dan keberadaan siapa yang dapat saya bayangkan mungkin membingungkan dari sudut pandang penamaan. Sejak sistem animasi baru dijatuhkan, kami sekarang memiliki dua node, satu bernama AnimationTree dan AnimationTreePlayer yang pada dasarnya tidak memiliki hubungan satu sama lain sama sekali. Adakah pemikiran tentang apa yang mungkin menjadi cara terbaik untuk mengatasi ini?

@SaracenOne Ini bukan tempat yang tepat untuk mengajukan pertanyaan seperti itu. Maaf. Utas ini hanya untuk membahas sufiks 2D/3D saja.

Ada masalah lain untuk membahas perubahan nama secara lebih umum https://github.com/godotengine/godot/issues/16863

Saya memiliki pemikiran yang mungkin berada di luar cakupan kerusakan compat yang dapat diterima untuk 4.0, dan oleh karena itu mungkin tidak layak/tidak dapat diterima, tetapi saya pikir saya akan menyebutkannya untuk melihat apakah seseorang yang lebih berpengalaman daripada saya peduli untuk berkomentar.

Saya membayangkan bahwa semua node 2D/3D ini dapat mewarisi dari satu jenis node yaitu 2D atau 3D. API untuk simpul semacam itu akan berisi semua fungsi yang Anda harapkan untuk salah satu versi, dan implementasinya akan bergantung pada apakah yang satu ini 2D atau 3D.

Secara teori, sistem seperti itu dapat:

1. Pastikan bahwa kami membuat API yang konsisten antara rekanan 2D/3D. Ini adalah keuntungan dan kerugian seperti yang saya lihat, karena meskipun konsistensi ini mungkin ada hal-hal yang tidak perlu untuk dimasukkan dalam satu tetapi di yang lain.
2. Permudah dua jenis yang berbeda untuk berinteraksi, atau buat skrip khusus yang ingin Anda lampirkan ke versi 2D dan 3D dari sebuah node.

Akan lebih baik untuk menghindari situasi di mana "SomeClass2D memiliki x, y, dan z diimplementasikan tetapi tidak ada yang seperti itu untuk SomeClass3D" dan itu menyelesaikan masalah penamaan dengan cara yang berbeda. Ini mungkin sangat bodoh karena beberapa alasan yang tidak saya pikirkan saat ini, tetapi saya pikir saya akan membuangnya.

@vortexofdoom Itu sudah terjadi. Node2D diwarisi oleh semua node 2D, dan Spasial diwarisi oleh semua node 3D. Pertanyaannya adalah apa yang harus disebut semuanya.

Dan, yang lebih penting, keduanya Spatial dan Node2D mewarisi dari Node .

Saya akan mengatakan masih ada sesuatu dalam ide @vortexofdoom yang tidak tercakup hanya oleh hierarki kelas, tetapi saya tidak dapat menentukan dengan tepat apa itu.

Hanya ingin tahu: apakah menurut Anda akan bermanfaat untuk menambahkan akhiran - Res ke semua kelas turunan Resource ?

@aaronfranke Saya mengacu pada gagasan memiliki SATU dari setiap jenis simpul (hanya KinematicBody atau Sprite), dan yang teratas adalah semacam Node2D3D yang menentukan perilaku mereka. Maaf jika itu tidak dijelaskan dengan baik. Jadi daripada memiliki hierarki 2D dan hierarki 3D, kita akan memiliki hierarki 2D/3D. Itu sebabnya saya mengatakan itu akan menjadi refactor yang lebih besar daripada yang mungkin dapat diterima.

Ini _bisa_ bekerja dengan membuat tipe dasar tidak dapat digunakan sendiri, tetapi perlu diimplementasikan sebagai 2D/3D agar mereka menjadi simpul nyata, dalam hal ini kita kembali ke titik awal pada nama simpul tetapi pewarisannya lebih secara otomatis langsung dan terkait antara 2D dan 3D dan interaksi antara sistem akan tetap lebih bagus (saya pikir).

@vortexofdoom Tapi sebenarnya tidak ada yang dibagi antara 2D dan 3D. Mereka mungkin memiliki beberapa jenis simpul yang sama dan memiliki nama metode yang sama, tetapi hampir semua implementasinya benar-benar berbeda. Berbagi paling banyak yang saya harapkan adalah antarmuka, karena ide Anda akan melibatkan if (is2d) { do 2d stuff } else { do 3d stuff } dan akan membuat file kode dua kali lebih panjang dan sangat tidak dapat dibaca tanpa manfaat.

Kelayakan kelas tunggal dengan perilaku variabel pasti bergantung pada seberapa banyak beban berat yang dapat dilakukan oleh simpul 2D/3D tingkat atas, mengirimkan abstraksi lebih jauh ke bawah. Menumbuk kelas seperti yang ada sekarang bersama-sama pasti tidak akan sebanding dengan masalahnya, saya yakin. Saya tidak keberatan menggunakan antarmuka untuk menyelesaikan reorganisasi, itu masih akan menegakkan setidaknya beberapa tingkat standarisasi untuk jenis yang berbeda.

Idenya didorong oleh keinginan menganggur bahwa saya dapat mewarisi dari versi umum dari sebuah node sehingga saya tidak perlu mengimplementasikan semuanya dua kali dalam sebuah proyek di mana saya menjalankan versi 2D dan 3D secara paralel. Saat ini, Anda harus mewarisi dari node dan melakukan casting untuk melakukannya dengan cara apa pun, karena node adalah satu-satunya nenek moyang yang sama.

Saya pikir Node2D3D (saya sadar betapa konyolnya kedengarannya) akan memiliki nilai meskipun hanya sebagai cara untuk membuat kedua sistem koordinat bermain lebih baik satu sama lain, tetapi itu mendekati pertanyaan desain yang berbeda sama sekali daripada thread ini. Maaf menyimpang.

@RandomShaper Saya pasti bisa melihat manfaatnya, terutama jika kita memiliki opsi nama sederhana itu.

Meninggalkan komentar saya untuk anak cucu, tetapi saya menarik kembali saran saya demi skema penamaan 2D/3D yang ketat sambil membiarkan hierarki sebagian besar apa adanya.

Alasannya adalah bahwa mengganti nama semua node akan membebaskan semua nama kelas tersebut untuk digunakan pengguna, yang berarti bahwa saya dapat mengimplementasikan fungsionalitas yang saya cari dengan membuat set kelas saya sendiri seperti KinematicBody atau CollisionObject yang dapat menarik fungsionalitas yang relevan dan menyebarkannya.

Tetapi bahkan di luar kasus tepi itu, itu akan memungkinkan Anda untuk membuat kelas seperti Area alih-alih membuat sesuatu seperti RoomGroup sebagai contoh cepat.

Saya cukup senang bahwa ini sedang dibahas. Saya berharap itu selesai.

Tidak tahu apakah itu telah dikatakan, tetapi jika hal-hal akan diganti namanya untuk konsistensi, sebaiknya lakukan dengan konsistensi penuh (semanusiawi mungkin) dan juga ganti nama metode tertentu.

Contoh:

Geometry.get_closest_point_to_segment()    # <-- this is the 3D version
Geometry.get_closest_point_to_segment_2d()

Selain node dan metode, bagaimana dengan struktur data? Saya berasumsi bahwa Transform akan diganti namanya menjadi Transform3D agar sesuai dengan Transform2D , tetapi Basis mungkin tidak perlu Basis3D karena tidak ada Basis2D karena semuanya termasuk dalam Transform2D .

@RandomShaper

Hanya ingin tahu: apakah menurut Anda akan bermanfaat untuk menambahkan akhiran - Res ke semua kelas turunan Resource ?

Tampaknya agak terlalu sedikit bang untuk uang. Saya lebih suka memilih untuk memasukkan Sumberdaya dalam saran saya (#31054) untuk penyorotan kode, tbh. Memiliki mereka pada warna yang berbeda akan mencerminkan tipe dasarnya segera setelah Anda selesai mengetik nama kelas (seperti dengan tipe bawaan seperti Vektor dan AABB).

Bagaimana dengan proyek terpisah untuk 2D dan 3D.

(Pada gambar saran untuk mengganti 2d dengan UI dan 3d dengan Scene).

Ketika Anda memulai proyek, Anda memilih mana yang akan Anda kerjakan.
Tidak ada lagi sufiks (2D, 3D) yang diperlukan dalam nama kelas.

Jadi dengan cara itu jenis namespace dibuat, dan tidak ada lagi campuran di antara jenis-jenis itu:

menggunakan Godot2D;
menggunakan Godot3D;

Ketika Anda berada di proyek 3d atau 2d - klik pada UI Anda sudah mendapatkan jendela UI (2D) untuk mengedit GUI, ketika mengklik Scene - Anda berada di tempat kejadian (2d atau 3d tergantung pada jenis proyek).

Jadi dengan cara itu kami mempertahankan mode 2d untuk UI di proyek apa pun, tetapi Scene membuka jendela 2d atau 3d

Di jendela ini hanya akan tersedia entitas yang terkait dengan jenis proyek (2d atau 3d) atau dibagikan jika mereka menggunakan keduanya

Saat Anda dalam mode UI, menambahkan node baru menunjukkan jendela ini hanya dengan komponen yang terkait dengan UI.
Saat dalam mode Scene kontrol UI tidak ditampilkan, hanya hal-hal yang dapat Anda terapkan ke scene

@dmitryuck Untuk gambar yang Anda posting, tombol 2D selalu diperlukan, karena bahkan game 3D perlu menggunakan mode 2D Godot untuk UI dan lainnya. Dan itu diinginkan untuk dapat mencampur 2D dan 3D pula. Secara teknis game 2D tidak perlu menggunakan tombol 3D, tetapi hampir tidak perlu menyembunyikannya.

Saya menyarankan di atas bahwa kita dapat membuat nama simpul diubah secara kosmetik dalam hierarki untuk menghindari sufiks yang tidak perlu secara visual, tetapi akan lebih baik jika kodenya selalu eksplisit.

@aaronfranke Saya telah menambahkan sedikit penjelasan luas tentang apa yang saya maksud di komentar saya sebelumnya.

Saya pikir menampilkan nama node secara berbeda tergantung pada keadaan akan menambah kebingungan.

Orang harus dapat memahami skrip dan pohon adegan pada pandangan pertama. Saya pikir itu suatu keharusan untuk kolaborasi, tutorial yang jelas, dll.

@dmitryuck Beberapa proyek memerlukan pencampuran 2D dan 3D, dan beberapa game memiliki UI dalam 3D.

@Skaruts beralih ke tampilan 2d dalam adegan 3d dimungkinkan dengan menerapkan komponen seperti di editor ini

Mode UI, tentu saja, harus ada di kedua jenis proyek, tetapi mungkin jendela terpisah dengan alat yang dibuat khusus untuk UI seperti kisi, gertakan yang disempurnakan, penggaris, dan sebagainya.

@reduz Mengganti nama adalah hal yang baik, tetapi harus ada masa transisi yang lama misalnya dari 4.0 ke 5.0, karena ini banyak tutorial dan jawaban yang https://godotengine.org/qa

@xxmatxx Saya lebih suka jika transisi singkat untuk berhenti menyeret nama lama 'apa yang akan terjadi'.
Juga, saya akan memastikan untuk mendokumentasikan perubahan dengan baik dan memastikan orang yang baru saja terjebak di Godot tahu tentang perubahan tersebut. Peringatan dalam editor yang memberi tahu Anda bahwa Anda menggunakan versi nama node yang sudah tidak digunakan lagi juga akan berguna jika beberapa orang melupakannya.

Saya setuju, semakin lama waktu yang dibutuhkan, semakin lama akan memiliki kesempatan untuk membingungkan orang. Tutorial dan dokumen tidak akan segera ketinggalan zaman jika, seperti yang disarankan @AtomaFajrovulpo , untuk jangka waktu tertentu editor masih mengizinkan hal-hal yang sudah usang tetapi mengeluarkan peringatan. Sesuatu di sepanjang baris ini saya kira:

Node type 'Spatial' is deprecated and replaced by 'Node3D'. 

dan

Method 'clip_polygon()' is deprecated and replaced by 'clip_polygon_3d()'. 

Saya menemukan kemarin bahwa konstanta tidak semuanya mengikuti kasus yang sama. Misalnya ada Color.black dan Vector3.UP . Bukankah ini harus dibuat konsisten untuk 4.0?

@BenjaminNavarro Mengubah konstanta Warna menjadi huruf besar juga dibahas di bagian bawah https://github.com/godotengine/godot/pull/14704.

Juga, penggantian nama metode/sinyal/konstan harus didiskusikan di #16863, karena masalah ini khusus tentang nama node.

@Calinou Terima kasih, saya cukup yakin ada masalah lain tetapi tidak dapat menemukannya.

Saya lebih suka mengganti nama di 4.0 dan menyelesaikannya kemudian mengetahui itu akan datang nanti setelah proyek yang saya kerjakan semakin berkembang.

jika rilis besar bukan waktu untuk melakukannya, apa.

SemVer: Diberikan nomor versi MAJOR.MINOR.PATCH, tambahkan:
Versi UTAMA saat Anda membuat perubahan API yang tidak kompatibel,
Versi MINOR saat Anda menambahkan fungsionalitas dengan cara yang kompatibel ke belakang, dan
Versi PATCH saat Anda melakukan perbaikan bug yang kompatibel dengan versi sebelumnya.

Seberapa jauh Anda akan pergi dengan ini?

Akankah GridMap kemudian menjadi TileMap3D, dan Tilemap Tilemap2D misalnya ?

Juga, node2D dan node3D tampak agak umum, mengapa tidak memiliki Spatial2D dan Spatial3D?

Saya pikir perbedaan UX yang besar juga adalah memiliki kontrol, node2D dan spasial, apa pun namanya, dapat diakses langsung di bawah node dalam dialog node baru, meskipun node2D dan kontrol mewarisi dari CanvasItem. Anda tidak dapat menambahkan CanvasItem langsung ke pohon, jadi mungkin itu tidak akan terlihat dalam dialog itu.

Dan sejauh metode berjalan, saya kira tidak perlu menambahkan postfix 2D atau 3D pada itu, karena Anda tahu apa yang Anda sebut mereka kan?

Saya masih berharap untuk membuat beberapa pembaruan yang bermanfaat, seperti mengatasi lambatnya impor sumber daya, dan optimalisasi kinerja skrip GD. Saat ini, dibutuhkan sekitar satu jam untuk mengimpor sumber daya 1G. Jika Anda mengimpor sumber daya 10G, Anda harus duduk di depan komputer dan tidur selama dua hari. Namun, browser sistem file editor sumber daya dari impor 700M-1G sekarang rusak, dan tidak ada yang akan ditampilkan. Daftar file, ini mungkin kekurangan dari editor itu sendiri, jadi saya pikir mengoptimalkan dan menyelesaikan masalah yang ada adalah cara yang lebih baik untuk Godot. Jika saya hanya dapat mengimpor 100-500 juta sumber daya, maka ditakdirkan bahwa Godot tidak dapat mengembangkan game besar, Tetapi jalan saya sekarang terhalang dan saya tidak dapat bergerak maju. Semoga versi berikutnya akan menyelesaikan masalah seperti itu, saya berharap Godot lebih baik dan lebih baik!

@qq715152910 Tolong jangan mengomentari utas panjang dengan informasi yang sama sekali tidak terkait. Setiap orang yang telah mengomentari masalah ini akan menerima ping dan komentar Anda tidak ada hubungannya dengan proposal untuk mengganti nama node. Akibatnya, saya akan menyembunyikan komentar Anda.

Saya akan memberikan pendapat kami tentang beberapa penggantian nama yang akan berguna bagi kami (Kami menggunakan C# terutama)

Penggantian nama yang sangat kami sarankan:

1. Transform.origin -> transform.origin

(Membuat akses ke properti transformasi huruf kecil)

Mengapa?
Misalnya spasial memiliki Transform yang dapat kita akses, tetapi berkali-kali kita menulis "this.Transform.origin" untuk keterbacaan yang lebih baik, jika kita mengubah "Transform" menjadi "transform", kita tidak perlu menggunakan "ini" semua waktu. Itu pendapat pribadi kami.

1. Kami juga mendukung perubahan "Label" menjadi sesuatu seperti "TextLabel". Atau setidaknya ketika kita mencari berdasarkan "teks" saat menambahkan simpul baru, "Label" akan muncul, karena itu benar-benar terkait.

2. Konstanta untuk beberapa warna yang telah ditentukan sebelumnya harus diakses dengan Color bertentangan dengan Colors .

Untuk sisa usulan penggantian nama, kami menantikan apa yang menurut komunitas lebih baik.

AtlasTexture -> TextureAtlas

Dinamakan AtlasTexture karena mengikuti konvensi <Type>Texture biasa di mana <Type> dapat menjadi Image , Viewport , Stream , …

AtlasTexture -> TextureAtlas

Dinamakan AtlasTexture karena mengikuti konvensi <Type>Texture biasa di mana <Type> dapat menjadi Image , Viewport , Stream , …

Ini yang muncul ketika saya mengetik "Atlas".

Inilah yang terjadi ketika kita mengetik Tekstur:

Sunting: Kami mengerti mengapa konvensi itu. Pada tangkapan layar ke-2, AtlasTexture sangat di bawah dengan hal-hal lain yang mengikuti konvensi <Type>Texture . Setelah itu, poin itu dihapus dari posting kami sebelumnya. Untuk kasus khusus ini masih belum terlalu ramah pelengkapan otomatis. Tapi kami menerimanya. .

@bigmonte The Transform struct akan mungkin diubah namanya menjadi Transform3D di Godot 4.0 per masalah ini, sehingga Anda tidak lagi perlu this. untuk membuatnya jelas bahwa itu sebuah properti.

EDIT: https://github.com/godotengine/godot/pull/38430

Konstanta untuk beberapa warna yang telah ditentukan sebelumnya harus diakses dengan Color bertentangan dengan Colors .

Saya orang yang mengusulkan itu sejak awal, dan saya sangat tidak setuju. Lebih baik memisahkannya, karena ini meningkatkan kemampuan menemukan anggota statis Color (saat ini Color8 , ColorN , dan FromHsv ) saat menggunakan pelengkapan otomatis di berbagai IDE. Saya juga mempertimbangkan untuk mengusulkan penggantian nama Color.red etc -> Colors.RED di GDScript untuk konsistensi.

Omong-omong, saya pikir Anda sedang mencari #16863.